\section{Testbed Overview}\label{4-Testbed Overview}

In this section, we explain our methodology building a testbed in order to study the behavior of DSR operating in a real environment. Furthermore, we will provide an analysis of the results of our experiments as well as of the effect that varying signal propagation conditions in a real-world environment had on the performance of our protocol.

  In designing the testbed, our primary objective was to establish a set of scenarios and conditions against which the DSR protocol could be challenged. We decided to deploy our experiments in an in-building testbed because it constitutes an inherently more predictable environment where the signal propagation is not so strongly affected by varying weather conditions or the presence of obstacles. By setting our testbed in an indoor scenario, we were able to minimize the presence of undesirable effects such as multi-path signal propagation -reflection, refraction or diffraction with obstacles- that might difficult in great manner the extraction of conclusions in the evaluation process. The testbed was deployed in a seminar room of the computer science institute at the FU Berlin. The room was cleared over desk height and the wireless nodes were located on tables in order to provide a transmission scenario with good transmission conditions. 

The hardware used for the development and testbed of the DSR protocol was the ScatterWeb Modular Sensor Board (MSB), designed at the Free University (FU) Berlin. The MSB features the 16-bit microcontroller MSP430F1612 from Texas Instruments, which is equipped with 52kB flash memory and 5kB RAM. In order to communicate with other nodes each board comes with a radio transceiver, the broadcast oriented Chipcon CC1020 [2, 3], which makes use of the ISM band at 869.525 MHz. The CC1020 transceiver allows monitoring the signal strength at reception, and its transmission power can be set manually via software.

In selecting how many nodes were to be used in the testbed, we decided to include enough nodes to create interesting topologies where multi-hop behaviour can be observed, while keeping the network small enough to be easily manageable. Each node in the network makes use of the DSR routing protocol in order to discover and maintain the routes to other destination nodes in the network. 

When studying the behaviour of a routing protocol, a plethora of metrics can be chosen -e.g: Packet Delivery Ratio, Delivery Latency, Normalized Packet Overhead or Forwarding Efficiency- depending on the aspects of interest of the design area whose performance is required to be evaluated.  We decided to investigate the behaviour of the Packet Delivery Ratio as main metric in our testbed, as we are interested in measuring both the correctness and completeness of our protocol version. The Packet Delivery Ratio is important given that it provides a description of the loss rate that will be seen by the upper transport layers, which in last term affects the maximum throughput achievable by the network. An analysis of the performance of other metrics, such as the Routing Overhead generated by the protocol, is a subject of further study.

In order to simulate the data transmission packets that would be originated by an upper transport layer protocol, we implemented a traffic generator whose input parameters to be specified by the user are: the destination node address, the number of packets to be transmitted and the interpacket interval.
The main goal of the first experiment was to investigate the influence that the payload size has over the packet loss rate. For that purpose, we deployed a single hop transmission scenario making use of two wireless nodes, sender and receiver, which were placed confronting each other. As previously explained, the transceiver transmission power of the nodes can be manually set by the use of commands, ranging the possible values between 0x00 and 0xff. We set both nodes to an intermediate transmission power level (0x0f) and located them using an internode distance (1m) so that the communication between them was ensured. Two parameters were varied along the testbed experimentation process: the interval between successive packet transmissions (0.25 and 0.5 secs) and the payload data size (30, 50, 70 and 100 bytes). For each set of experiment conditions the initiator node transmitted 500 packets of a given fixed payload size and at a certain rate, which is directly defined by the interpacket interval. We expected that increasingly higher data packet sizes would be reflected in a poorer behavior of the packet delivery ratio. As the number of bytes to be delivered per packet increases, so it does the overall network congestion, which in last term would lead to a higher data packet loss probability. The same reasoning would apply if a smaller interval between packet transmissions is used, as it results in a higher data rate in the network, and therefore the expectable number of received data packets would noticeably decrease.
\begin{table*}[t]
\begin{center}
\textbf{Table VI} DSR Packet Delivery Ratio performance under varying Data Payload Size
\end{center}
\centering
\begin{tabular}{l|l|l}
\hline
& \multicolumn{2}{|c}{Interpacket Interval}\\ \cline{2-3}
 \raisebox{1.5ex}[0cm][0cm]{Payload}
&0.25 sec& 0.5 sec\\ \hline
30 bytes&  100\%\  &100\%\ \\ \hline
50 bytes&  100\%\  &100\%\ \\ \hline
75 bytes&  99,6\%\ &99,4\%\ \\ \hline
100 bytes& 99,2\%\ &98,8\%\ \\ \hline
\end{tabular}
\end{table*}
  The experiment results obtained meet our expectations (see Table VI), although not in the extent that we had anticipated. The number of correctly delivered packets decreased when the protocol was confronted with higher data payload sizes and shorter period between successive packet transmissions. However, the degree of decrease observed was much lower than expected, as the protocol was able to deliver the majority of the packets even at the highest data rate and payload size 98.8\%\ . This is mainly due to the reduced number of nodes used in our testbed. As the network topology selected to run the experiment consists only of two nodes, we were not able to stress the protocol to a situation of congestion were packet collisions occur frequently. We can conclude that there is an inverse relationship between the packet delivery ratio and the mentioned parameters. However, further experimentation is required using more demanding topologies with a much higher number of deployed nodes. An additional unexpected observation that we gathered while running our experiment was that the transmission of data packets suffered from a delay proportional to the payload size of the data packets.\newline As the data payload size was increased, the period of time required to transmit the packet incremented as well. This led to very low packet rates in the scenarios with the highest size values (70, 100 bytes), where the transmission of the total amount of packets required over 5 minutes. Such a delay might be due to limitations in the maximum transfer data rate achieved by the CC1020 node transceiver, although further work will be required to investigate in more depth the causes that lead to high packet transmission delays.

  The second experiment had as main objective to determine until which extent the packet delivery ratio is affected by the length of the route between sender and destination. We expected that the packet loss probability would rapidly increase with the number of hops. As the length of the chain through which the sender and destination node communicate is increased, the protocol is subjected to more demanding transmission conditions, where undesirable events such as packet collisions or fading might happen more frequently. As a consequence, we believed that the probability that a failure takes place -either during the discovery of a route along the network or in the data packet delivery- would get higher, and consequently the packet delivery ratio would decrease as longer multi-hop scenarios were established. 
\begin{figure*}[t]
\centering
\includegraphics[width=3in]{chain}
\begin{center}
\textbf{Figure 3 } Chain Topology
\end{center}  
\end{figure*}
\begin{figure*}[t]
\centering
\includegraphics[width=4in]{matlab}
\begin{center}
\textbf{Figure 4 } Packet Delivery Ratio as a function of number of hops with varying interpacket intervals.

Data Packets with fixed Payload Size of 50 bytes.
\end{center}
\end{figure*}
  In order to confirm our expectations we deployed a network with a chain topology comprising 5 wireless nodes, were each node was only able to communicate directly with its previous and next hop (Figure 3 provides a logical overview of the network topology).

  Given that we made use of a heterogeneous set of wireless nodes with different transmission hardware -two of them featuring an antenna at the transceiver, while three of them lacking of it- prior to conducting the experiment it was necessary to make a previous analysis in order to determine the appropriate configuration of our nodes in the network. The transmission power at each node was set to a very low level (0x01) and the internodal distances were established in order to ensure that each deployed node had direct transmission only with its predecessor and successor in the chain. This was achieved by positioning the nodes as far from each other as possible, while still allowing them to successfully send ping packets to their adjacent neighbours in the chain. We ran the experiment progressively increasing the number of hops between the initiator and the destination node, ranging from 1 until 4 hops, and for each chain size two different interpacket intervals were tested (0.25 and 0.5 secs). During each run, the network was subjected a workload of 500 packets of a given fixed payload data size -established to a value of 50 bytes- being transferred from the originator to the destination -which corresponded to the first and last nodes of the chain respectively. 

  Figure 4 shows the packet delivery ratio achieved by our protocol for each number of hops using two different interpacket transmission periods. The protocol delivered 100\%\ of the packets in the single-hop chain, regardless of the data rate. However, we observe that the number of delivered packets reduces at a fast step as the number of hops between sender and receiver is increased. Actually, we can deduce from the results that the existing inverse relationship between the packet delivery ratio and the route length follows a non-linear pattern, which would approximate well when using a quadratic estimation. Additionally, it is remarkable as well that the use of higher data rates in the experiment had a negative impact on the packet delivery ratio. The routing protocol showed a poorer performance when confronted with a workload with lower spacing between consecutive packet transmissions. While in the two-hop chain scenario our protocol was able to transmit approximately 68 \%\ of the packets using a packet interval of 0.5 secs, only around 48\%\ were successfully delivered when the lowest interpacket period was utilized.

  During our second testbed we found that in several occasions the Send Buffer suffered of overflowing, especially when the protocol was subjected to high workloads in multi-hop scenarios. As we previously mentioned in Section 2, our version of the DSR protocol implements the Send Buffer -where the data packets are temporarily stored until the required route to a given destination is discovered- as a static structure with a predefined limited number of entries. Once a Route Discovery to a given destination is performed, the successive data packets to be delivered to the same target node are directly stored in the Send Buffer. It has been previously indicated that when the routing protocol is confronted with a more demanding multi-hop scenario there is a greater probability that a Route Discovery fails. When a Route Discovery isn't successfully performed, a new process must be initiated at the sender node, and in the meantime additional entries are stored in the Send Buffer waiting for a route to be discovered. The Send Buffer entries to a certain destination are deleted either after a successful discovery and packet transmission is performed or if the number of Route Discovery attempts exceeds the maximum established. Therefore, as the probability of Route Discovery failure increases in multi-hop topology scenarios, so it does the average lapse of time until the data entries are deleted from the Send Buffer, which in last term leads to frequent overflows in case the highest data rate is being used at the traffic generator.
\begin{figure*}[t]
\centering
\includegraphics[width=2in]{meshed}
\begin{center}
\textbf{Figure 5 } Meshed Topology
\end{center}  
\end{figure*}
  Buffer overflowing is an extremely undesirable situation that should be prevented by our protocol, given that the data packets that cannot be stored will be directly discarded before being previously transmitted, being perceived by the upper layer transport protocols as packet delivery failures. One solution would be for DSR to implement the Send Buffer as a dynamic structure where the entries are created as required during the routing procedure. The drawback of this solution is that it incurs in higher complexity in the wireless node memory management process, which usually present important restrictions in terms of storage capacity. A second and more sophisticated approach would be the implementation of the Send Buffer as a priority queue, where entries of low-priority packets can be overwritten by newly received data packets petitions with higher priority in situations of overflowing.

  Finally, we decided to run a third experiment in order to determine how the protocol reacts to networks where it is possible to establish different possible routes between sender and destination. For that purpose, we deployed a topology in which a number of intermediate nodes are placed between sender and destination (see Figure 5).\newline The testbed comprised 5 wireless nodes: 2 nodes (A, E) located at each far side of the network constituted the initiator and target node, while 3 nodes (B, C, D) where positioned in the central region of the experiment. As in the previous experiments, the packet delivery ratio was measured by generating a workload of 500 data packets of fixed payload size(50 bytes)transmitted from sender to destination. This time, the only parameter that was varied along the experiment was the interpacket interval(0.25 and 0.5 secs), in order to produce traffic with a higher data rates.

  Table VII shows the fraction of the transmitted packets that were successfully delivered by the routing protocol when subjected to varying data rates. As it can be observed, the protocol performance is dramatically reduced when subjected to a topology with multiple possible routes between sender and destination, achieving a maximum delivery ratio of 26.6\%\.\newline This can be explained by the fact that the Request packets that are transmitted by the initiator node in order to perform the Route Discoveries are simultaneously received by the intermediate nodes of the network, which in turn update and forward again the Request packet. Given that the packet processing time is almost identical in the intermediate nodes, the updated packets are broadcast almost simultaneously, increasing the congestion of the shared wireless medium and thus the probability of collisions.\newline Such an increment in the probability that the Request packets collide while being forwarded through the network has logically a direct negative impact in the Route Discovery success rate and in last term in the fraction of packets that can be successfully delivered to their destination. While running the experiments, we observed that the discovered routes did not always correspond to shortest path sequences, which in the studied topology would be composed of two hops.
\begin{table*}[t]
\begin{center}
    \textbf{Table VII} Packet Delivery Ratio performance under varying interpacket intervals

using multiple intermediate nodes topology
\end{center}
\centering
\begin{tabular}{l|l|l}
\hline
& \multicolumn{2}{|c}{Interpacket Interval}\\ \cline{2-3}
 \raisebox{1.5ex}[0cm][0cm]{Payload}
&0.25 sec& 0.5 sec\\ \hline
50 bytes&  16.6\%\  &26.6\%\ \\ \hline
\end{tabular}
\end{table*}
  Actually, in many cases the Request packet had been forwarded along several intermediate nodes before reaching the target, the routes containing sometimes 4 or even the total amount of deployed nodes in the discovered stored sequence. This lack of optimization in the route discovery process is in part due to the fact that our protocol does not implement a methodology in order to select the shortest route to a destination. As no Route Cache is available in our DSR version, our protocol is not able to store several possible routes to a given destination, being the sequence contained in the first received Request packet the one used for the packet transmission.\newline An additional interesting result of the experiment is that the protocol shows a better performance when utilizing the highest data rate (4 packets/sec). Such a behavior can be explained by analyzing the way our protocol performs the Route Discovery process.
  As it has been previously explained, our protocol implementation allows only a single active Route Discovery per destination node, being possible to have several Send Buffer entries addressed to the same destination node waiting for a single ROUTE REPLY. If the interpacket interval is set to a value lower than the Round Trip Time (RTT) of the network, a number of data packets can be directly stored in the Send Buffer without starting a new Route Discovery process, thus saving a great deal of routing overhead. Therefore, using the highest data rate incurs in smaller amount of Route Request packets circulating throughout the network, which in last term leads to a less congested network with lower packet collision probability and better packet delivery ratio.
