# An Efficient Routing Protocol with Overload Control for Group Mobility in Delay-Tolerant Networking
## 3 A Proposed Routing Protocol with Overload Control for Group Mobility  
In this paper, we propose a routing protocol for group mobility. Depending on the relationship of the group of contact node \(x\), the group of contact node \(y\), and the group of destination node \(z\) of a considered message, the message forwarding condition of the proposed protocol is classified as Cases 1, 2, 3, 4, and 5. Then, the forwarding of the proposed protocol operates as follows:Case 1. If contact nodes \(x\) and \(y\) belong to the same group \(A\) and also destination node \(z\) belongs to the same group \(A\), a message is forwarded to node \(y\) if \(P(y,z)>P(x,z)\). * Case 2. If contact nodes \(x\) and \(y\) belong to the same group \(A\) but destination node \(z\) belongs to different group \(B\), a message is forwarded to node \(y\) if \(P(y,z)>P(x,z)\) AND \(P_{g}(y,\mathbf{G}_{B})>P_{g}(x,\mathbf{G}_{B})\). * Case 3. If contact nodes \(x\) and \(y\) belong to groups \(A\) and \(B\), respectively, and destination node \(z\) belongs to the same group \(B\) with node \(y\), a message is forwarded to node \(y\) if \(P(y,z)>T_{p}\) OR \(P_{g}(y,\mathbf{G}_{B})>T_{p}\), where the message dissemination promotion threshold, \(T_{p}\), is generally set as a small value to promote the dissemination of a message. * Case 4. If contact nodes \(x\) and \(y\) belong to groups \(A\) and \(B\), respectively, and destination node \(z\) belongs to group \(A\), a message is forwarded to node \(y\) if \(P(y,z)>T_{r}\) AND \(P_{g}(y,\mathbf{G}_{A})>T_{r}\), where the message dissemination restriction threshold, \(T_{r}\), is generally set as a large value to restrict the dissemination of a message. * Case 5. If contact nodes \(x\) and \(y\) belong to groups \(A\) and \(B\), respectively, and destination node \(z\) belongs to group \(C\), a message is forwarded to node \(z\) if \(P(y,z)>P(x,z)\) AND \(P_{g}(y,\mathbf{G}_{C})>P_{g}(x,\mathbf{G}_{C})\). The basic rationale of the proposed forwarding condition is to use both individual delivery predictability and group delivery predictability together to make a forwarding decision efficiently if the group of a destination node is different from either a group of contact node \(x\) or a group of contact node \(y\). Additionally, when a group of contact node \(x\) and a group of contact node \(y\) are different from each other, if a group of destination node \(z\) is the same as the group of contact node \(y\) only, the message dissemination is promoted. On the other hand, if a group of destination node \(z\) is the same as the group of contact node \(x\) only, the message dissemination is restricted. Table 1 summarizes the forwarding conditions of the proposed protocol for Cases 1 to 5. In addition to forwarding conditions proposed above, overload control is newly proposed in this paper. In DTN, messages are forwarded through opportunistic contacts and forwarding nodes are not aware of whether the generated message was delivered to a destination node successfully or not. Therefore, unnecessary forwarding of messages may occur even though the messages are delivered to destination nodes successfully already. To reduce this unnecessary forwarding of messages after successful delivery, a _vaccine scheme_ was proposed in [24], where if a message is delivered to a destination node, an anti-packet for the delivered message is generated at a forwarding node. Then, the forwarding node does not receive the same message anymore, and it shares the anti-packet information with all contact nodes, and contact nodes remove the already delivered messages if they have them. Otherwise, they do not receive the message anymore. In this paper, we adopt an approach of the vaccine scheme [24] for overload control and extend the approach to reduce overload further. Firstly, if a message is delivered to a destination node, the \"delivery state of a message to a destination node\", which acts similarly as an anti-packet in [24], is recorded at the overload control table of the forwarding node as \"delivered\".