## 3 Dual-Stack Single-Radio Communication Architecture (DSSRCA)
### Experimental Evaluation
#### 3.4.2 Reliable Protocol Experimentation  
As mentioned, these experiments were performed on a long seaside walkway. Besides natural obstacles such as poles and trees, it is in an urban area and the environment poses possible interference from other wireless technologies (e.g., WiFi)-which is good for testing the proposed re-transmission mechanism. In this experiment, the MDC took about 9 min, at speeds between 4 and 8 m/s, to move 1400 m away from the sink and then return to it. It was configured to transmit one message per second. The message was composed of telemetry information with a payload of 32 bytes: 128 bits for the geographical coordinates and 128 bits for speeds north and west. The sink not only records the received telemetry data, but also transmits a ping message to the MDC to monitor the link. Figure 8: data collected from the reliable protocol evaluation. Figure 7: Sensor messages latency in the bicycle experiment. During the experiment, 489 messages were transmitted by the MDC and received by the Sink. Figure 8 plots the three variables that are directly associated with the performance of the proposed re-transmission algorithm. The _Transmission_ variable denotes the total number of messages that were transmitted, including those delivered and the re-transmissions attempts. The _Deliverables_ variable is the number of messages successfully delivered and _Re-transmissions_ is the number of failed re-transmissions that did not receive the ACK. The graph shows the average of these three variables at every 200 m.  
It can be observed in the graph that in the first 900 m the number of delivered messages is considerably satisfactory. Then it started dropping until it reach its lowest point, contrasted with the increase in the re-transmissions (which reaches its highest level). When the MDC starts moving back there is a peak in the total number of delivered messages. This large number of messages includes those previously generated (and buffered), but that could not have been delivered due to the long distance from the sink. It is important to note that the re-transmissions mentioned above are in the application layer, not in the link layer. The link layer re-transmissions can be performed automatically by the MRF24J40 MC hardware using an _ack_ at the MAC level. Such feature remained active during all of the experiments. In order to measure the data rate, in another experiment we placed the MDC close to the sink and performed a 10 MB mission file download. This experiment was repeated several times using different block sizes. Whenever the 6 LowPan receives a message (block) from the application to transmit (in this case at the Sink node), the message is typically divided into multiple fragments in order to fit the 127 bytes of the 802.15.4 maximum transmission unit (MTU). The MTU has 75 bytes available for payload in the first fragment and about 85 bytes for the remainder ones. A MAC-ACK is sent for any fragment correctly received in the destination node. If any single fragment is lost, it will not be re-transmitted, and all others already received will be discarded. It can be observed in Figure 9 that the data rate initially increases, since using bigger message blocks imply less confirmation messages at the application level. It is possible to notice a slight drop in the data rate from 500 to 600 bytes before it saturates. This comes from increasing the number of required fragments from 6 directly to 8, and increasing the number of fragments enhances exponentialy the probability of transmission failures. The tendency for saturation in the long run with transmission blocks bigger than 500 bytes can be observed in the tendency curve (the thin line that is not in the legend). In addition, it can also be observed in the figure that the use of windows size higher than one has a negative effect on the data rate. This occurs because when the UAV tries to transmit the application-level acknowledgment, the Sink tries to transmit the next message that is allocated in the transmission window.