## 4 Receiver-Triggered Handshake Protocol
### Functional Requirements  
The following functional elements have been developed for the protocol to satisfy the performance objectives shown in Figure 3.  
(1) Roles of nodes  
In _Epidemic Routing_ and _Spray and Wait_, both source nodes and relay nodes have the same role with the result that victim terminals are burdened with large processing and transmission loads. We have taken note of the presence of a rescue team in a disaster area. Rescue team members can physically carry information to shelters. Therefore, we define a category of carrier terminals. The objective is to reduce power consumption of victim terminals. To sum up, we differentiate three types of terminals: victim terminal, carrier terminal and shelter terminal. This makes it possible to discriminate nodes when bundles are exchanged. By preventing copies of messages from being sent to victim terminals, which do not need to carry information for other terminals, it is possible to suppress power consumption of victim terminals.  
(2) Number of bundle copies made by a source terminal  
In _Epidemic Routing_, a source terminal sends bundle copies to all terminals to which it is connected. This results in many unnecessary copies, and can cause network congestion. _Spray and Wait_ can limit the number of copies made by a source terminal but it is difficult to determine the appropriate upper bound on the number of copies in a disaster situation. In our proposed protocol, a source terminal (victim terminal) makes only one copy.  
(3) Number of bundle copies made by a relay node  
In _Epidemic Routing_, not only source terminals but also relay nodes send copies to all nodes to which they are connected. In _Spray and Wait_, a relay node sends data to only the destination node, and so no copies are made. Our proposed protocol assumes that carriers have dedicated mobile terminals with ample battery capacity. Therefore, no restriction regarding making copies needs to be imposed on carrier terminals.  
(4) Number of hops needed to reach the destination  
Limiting the number of hops lowers the delivery rate. On the other hand, if the number of hops is not restricted, many bundle copies may be generated, which may lead to network congestion. In our proposed protocol, the latter problem is solved by adopting (6) below. Therefore, the number of hops is made unlimited in the interest of enhancing the delivery rate.  
(5) Method of deleting bundle copies  
In _Epidemic Routing_ and _Spray and Wait_, terminals that have bundle copies delete them in one of the following two ways. The first way is that, when a bundle reaches its destination terminal, the destination terminal sends back a reception complete bundle. Terminals that have received this bundle delete theoriginal bundle they hold. The second way is using TTL (Time To Live). However, in either case, the storage units of relay nodes can overflow. To solve this problem, the proposed protocol defines a control bundle that indicates reception complete. When a carrier terminal (which is a relay node) receives a bundle, it sends back this control bundle. When a carrier terminal receives this control bundle, it deletes the original bundle.  
(6) Trigger for communication  
In the existing methods, a terminal that wants to send a bundle sends a hello message periodically, and terminals that have received this message send back acknowledgement. This is how communication starts between the sending terminal and other terminals. In a disaster situation, it is victim terminals that attempt to send safety confirmation information. If they were to send hello messages periodically, they would consume battery charge quickly. To solve this problem, in our proposed method, communication is triggered by the receiving terminal.  
Technical differences between the proposed method and the existing methods discussed above are summarized in Table 2.