OLSR Performance Measurement in a Military Mobile Ad-hoc Network

Transcription

1 OLSR Performance Measurement in a Military Mobile d-hoc Network Thierry Plesse ½, Jerome Lecomte ½, Cedric djih ¾, Marc Badel ¾, Philippe Jacquet ¾, nis Laouiti ¾, Pascale Minet ¾, Paul Muhlethaler ¾, dokoe Plakoo ¾ ½ G/CELR, BP 7419, Bruz Cedex, France. ¾ INRI, BP 105, Rocquencourt, Le Chesnay Cedex, France. Keywords: Mobile ad-hoc network, MNET routing, mobile military applications, performance measurement. bstract: Wireless ad-hoc networks are autonomous, self-configurating and adaptive. Thus, such networks are excellent candidates for military tactical networks, where their ability to be operational rapidly and without any centralized entity is essential. s radio coverage is usually limited, multihop routing is often needed; this is achieved by an ad-hoc routing protocol supporting nodes mobility. In this paper, we present performance measurements of the OLSR (Optimized Link State Routing) protocol routing, presented at the IETF MNET (Mobile d-hoc NETwork) working group for ad-hoc networks. The measurements are performed at CELR site on a platform representative of military scenarios in urban areas. It consists of ten routers, eight Ps and laptops using a IEEE b radio interface and implementing OLSR v7. Some nodes are mobile within vehicles. The emphasis of the measurements is on the performance of the network (route repair, network convergence speed, user traffic performance) in presence of this mobility. 1 Introduction Wireless ad-hoc networks are autonomous, selfconfigurating and adaptive networks. s radio coverage is usually limited, multihop routing is often needed; this is achieved by an ad-hoc routing protocol, which automatically discovers the neighbors and sets up routes. Such networks also support mobility, as the informations about routes and topology are constantly updated. Thus, they are excellent candidates for military tactical networks, where their ability to be operational rapidly and without any centralized entity is essential. In this paper, we focus on performance measurement of the OLSR (Optimized Link State Routing) protocol in scenarios representative of military applications in urban areas. This paper is organized as follows. In section 2 we define the military requirements with regard to tactical networks. In section 3, we describe the OLSR (Optimized Link State Routing) protocol routing, presented at the IETF MNET (Mobile d-hoc NETwork) working group for ad-hoc networks. Section 4 presents the MNET/OLSR platform actually implemented at CELR with 18 nodes. Some nodes are mobile within vehicles. This platform aims at evaluating the potential benefits of mobile ad-hoc networks in military tactical applications. Section 5 reports measures of user traffic performances and shows how TCP and UP traffic share the available bandwidth. In Section 6, we study the impact of mobility on route availability and user traffic performances. Finally, we conclude the paper in section 7. 2 Tactical Networks For several years, the concept of battlefield numerisation has made information control a determining stake for the armed forces. This concept requires an architecture of meshed network, adapting automatically to variable topologies. Such a network performs auto-configuration, and dynamic routing. It detects the presence of a new node, the absence of another one and supports nodes mobility. Networks meeting, wholly or partly, these requirements are under development in the civil world: Mobile d-hoc NETworks (MNETs). The convergence of the Internet Revolution, which has brought the IP protocol to maturity on the civilian market, and the increasing needs of interoperability for data transmission architectures on the battlefield for joint and allied forces has made the use of COTS technologies and products in Telecommunications protocols a major issue for efense C3I systems. The effort known as MNET (Mobile dhoc NETwork), led by the Internet Engineering Task Force (IETF), to bring new promising answers to technical issues raised by mobile context about IP network, specifically relative to availability and reliability, is of great interest for military applications. The tactical environment is characterized mainly by the need for: Mobile nodes, elay constraints with priorities, Reliability and availability, Security, Unicast and multicast traffic, ifferent kinds of traffic : data, voice, video, Interoperability between forces and with allied units. In military scenarios, nothing can ensure that all communicating nodes are one-hop away due to the inherent nature

2 of the radio propagation. In that case, ad-hoc multihop architecture is one of the best approaches to solve the connectivity problem. n architecture with a distributed control is essential. network should work (even in a downgraded mode) without any centralized function. No node should be indispensable and centralized functions should be limited to optimization capabilities. utonomous packet radio networks are essential because of their ability to be operational rapidly and without any infrastructure. Military requirements and constraints make MNET more pertinent relatively to the Below of Brigade echelon. 3 OLSR Routing Protocol 3.1 MNET Routing Protocols s radio coverage is usually limited, multihop routing is often needed. ll routing protocols proposed in the IETF MNET working group address the problem of unicast routing, while taking into account the features of wireless, multihop, mobile ad-hoc networks. Such protocols are proactive or reactive. With reactive protocols, a node discovers routes ondemand and maintains only active ones. Thus, a route is discovered whenever a node needs to communicate with a node for which a route is not available. This discovery mechanism is based on pure flooding [1] in the network. The advantage of reactive protocols is that no control message is needed for non-active routes. The drawback is the latency when establishing a route. Two reactive protocols are on the standard track: OV [2] and SR [3]. With proactive protocols, each node maintains the routes to all other nodes in the network by periodic exchange of control messages. When a node needs to send a packet to any other node in the network, the route is immediately available. The main advantage of proactive protocols is that they do not introduce a delay before sending data. Furthermore, these protocols are useful for traffic patterns where a large subset of nodes is communicating with another large subset of nodes, and where the [source, destination] pairs are changing over time. Two proactive protocols are on the standard track: OLSR [7] and TBRPF [5]. Proactive protocols are particularly well suited for military applications since all nodes know the network topology and also these routing protocols can be used without modifying the network protocol stack. 3.2 OLSR OLSR (Optimized Link State Routing) is an optimization of a pure link state routing protocol. It is based on the concept of multipoint relays (MPRs) [8]. First, using multipoint relays reduces the size of the control messages: rather than declaring all its links to all nodes in the network, a node declares only the set of links with its neighbors that are its multipoint relays. The use of MPRs also minimizes flooding of control traffic. Indeed only multipoint relays forward control messages. This technique significantly reduces the number of retransmissions of broadcast control messages [6, 8]. The two main OLSR functionalities, Neighbor iscovery and Topology issemination, are now detailed Neighbor iscovery Each node must detect the neighbor nodes with which it has a direct link. For this, each node periodically broadcasts Hello messages, containing the list of neighbors known to the node and their link status. The link status can be either symmetric (if communication is possible in both directions), asymmetric (if communication is only possible in one direction), multipoint relay (if the link is symmetric and the sender of the Hello message has selected this node as a multipoint relay), or lost (if the link has been lost). The Hello messages are received by all one-hop neighbors, but are not forwarded. They are broadcast once per refreshing period Hello interval. Thus, Hello messages enable each node to discover its one-hop neighbors, as well as its two-hop neighbors. This neighborhood and two-hop neighborhood information has an associated holding time, after which it is no longer valid. On the basis of this information, each node independently selects its own set of multipoint relays among its onehop neighbors in such a way that the multipoint relays cover (in terms of radio range) all two-hop neighbors (see [8] for an algorithm example). The multipoint relay set is computed whenever a change in the one-hop or two-hop neighborhoodis detected. Inaddition, eachnodeñ maintains its MPR selector set. This set contains the nodes which have selected Ñ as a multipoint relay. Node Ñ only forwards broadcast messages received from one of its MPR selectors Topology issemination Each node of the network maintains topological information about the network obtained by means of TC (Topology control) messages. Each node Ñ selected as a multipoint relay, broadcasts a TC message at least every TC interval. The TC message originated from node Ñ declares the MPR selectors of Ñ. If a change occurs in the MPR selector set, the next TC can be sent earlier. The TC messages are flooded to all nodes in the network and take advantage of MPRs to reduce the number of retransmissions. Thus, a node is reachable either directly or via its MPRs. This topological information collected in each node has also an associated holding time. The neighbor information and the topology information are refreshed periodically, and they enable each node to compute the routes to all known destinations. These routes are computed with ijkstra s shortest path algorithm [1]. Hence, they are optimal as concerns the number of hops. The routing table is computed whenever there is a change in neighborhood or topology information.

3 4 OLSR Platform CELR (French Mo / G) works on the concept of ad hoc networks for the preparation of the future. These studies interest military programs like Soldier of the Future, and could be fully integrated in RH project (High ata Bit Rate Radio), for Navy and Land tactical networks. The objective of MNET/OLSR CELR tesbed is to evaluate and demonstrate the potential benefits of MNET advances in military tactical applications, with a special focus on performances and reliability. The CELR MNET platform, illustrated by Figure 1, is an actual network using b radio technology (WiFi) consisting of 18 MNET/OLSR nodes (10 routers, 4 VIO laptops, 4 ipq Ps) cards are run in adhoc demo mode (not standard WiFi IBSS), and without RTS/CTS, except when explicitly indicated (section 5.2). These nodes implement OLSR routing protocol (draft version 7, not RFC 3626). This platform has been built at the end of ecember In this section, we focus on the bandwidth available between any two nodes in the multihop network. The topology of the platform is illustrated by Figure 2. The platform topology is later changed, as mobile nodes are added, as examplified in Section 6. We consider TCP flows and measure with Netperf the bandwidth obtained at the destination node. The experiment duration is 60 seconds (based on initial tests ranging from 10 to 180 seconds, 60 seconds found out to be enough for obtaining reproductible results). We study the influence of different parameters such as the presence of other traffics (at the source, at the destination or more generally in the network), the use of the RTS/CTS option and the spatial reuse. Figure 2. Topology of the network in the static experiments. 5.1 Bandwidth sharing between several TCP flows Figure 1. CELR MNET platform. The implementation used in the platform uses an hysteresis mechanism, based on received power measurements, which is the one experimented in [9]: Before a link to another node is accepted, the receive power of the corresponding HELLO, must be above a threshold, which is set to -85 dbm in our experiments. s long as it is above a (lower) threshold, here equal to - 94 dbm, and it is correctly refreshed, the link is considered valid. We have checked that in the presence of topology changes (e.g. node appearance or disappearance, node mobility), the OLSR protocol detects these changes and updates the routes accordingly in order to maintain the shortest route to any destination in the network. The platform being validated, we have performed some performance measurements. The measurements concerning the bandwidth offered to user flows are detailed in the sections 5 for the static case and 6 for mobile nodes. 5 Bandwidth measurements for TCP flows We first study how the available bandwidth is shared between coexisting TCP flows. In the experiment reported in Table 1, two sources send TCP flows to the same destination. src dest route hop throughput number r03 r02 r03 r Mbps r08 r02 r08 r06 r04 r Mbps r08 r02 r08 r06 r04 r Mbps r07 r02 r07 r06 r04 r Mbps r09 r02 r09 r03 r Mbps r05 r02 r05 r04 r Mbps r09 r02 r09 r03 r Mbps r08 r02 r08 r06 r04 r Mbps Table 1. Throughput: several TCP flows. Table 1 shows that the traffic from source r03, one-hop away, is favored with regard to the traffic of source r08, three-hop away. The TCP flow with the smallest number of hops is favored, as also experienced in [9]. It also shows that when both r08 and r07 send TCP flows to r02, three-hop away, both receive approximatively the same part of the bandwith. We observe that when both TCP sources are at the same hop number from the destination, the bandwidth sharing is generally fair. However, we notice an unfair bandwidth sharing, even though both sources

4 are two-hop away. Router r02 receives from r09 at 0.02 Mbps, whereas router r02 receives from r05 at 1.52 Mbps. This experiment is repeated and we obtain similar results. Even when router r09 is the only one to send TCP flow to router r02, the throughput is limited (i.e Mbps), whereas router r05 gets the same bandwidth as before. This evidences some deep effects in the lower layers, which we were unable to analyze for lack of fine-grained measurements at MC layer or packet level. This explains the unfairness observed in the previous scenario. Similar unfairness phenomenons, observed in simulations, have been analysed, on the other hand, in great detail in [10] for instance. In the last case, we observe an unexpected unfair bandwidth sharing when one source r09 is two-hop away and the other source r08 is three-hop away. Even though r09 is near, it receives a bandwith worse than r08: r09 receives 0.22 Mbps vs 0.37 Mbps for r08. In specific cases, a pair of far nodes can get a better bandwidth than a pair of closer ones (with better signal/noise ratio): this may be an effect of multipath propagation. We have also measured the bandwidth obtained in case of one source opening N independent TCP flows to N different destinations. We have obtained similar results to the ones reported in Table 1, except that the unfairness is more important with N-to-1 traffic. 5.2 Spatial reuse In this subsection, we study the spatial reuse of the bandwidth as provided by the IEEE b medium access protocol. In the first experiment, we consider two source nodes r07 and r03 that are two-hop away. Each source sends one TCP flow to a one-hop destination. src dest throughput throughput throughput with without if alone RTS/CTS RTS/CTS r07 r Mbps 5.1 Mbps 5 Mbps r03 r Mbps 3.6 Mbps 4 Mbps Table 2. TCP Throughput: two-hop away sources. Table 2 shows that without RTS/CTS the two TCP flows coexist without any mutual perturbation. Both of them obtain approximatively the same throughput as the one obtained if each of them were the only TCP flow. This allows to conclude to a good spatial reuse without RTS/CTS. When the RTS/CTS option is used, we observe that the usual throughput decreases for both TCP flows. This is due to extra delays in the protocol, where a node has to send a Request To Send packet and has to wait for a Clear To Send reply before transmitting a unicast data packet. We have also observed that the RTS/CTS option, designed to cope with hidden nodes, does not improve fairness in our limited examples ; other experiments are necessary. In the second experiment, whose results are reported in Table 3, we go further in experimenting with spatial reuse. The option RTS/CTS being switched off, two sources that are neighbors (here r04 and r06), send a TCP flow to a onehop destination. The expectation is that, being neighbors, the sources cannot transmit at the same time. Both flows receive a slightly smaller throughput than if each of them were alone, each of them loses less than 15% of throughput, with aggregated bandwidth equal to 5.4 Mbps, showing that the interference between the nodes is minimal, although both pairs cannot transmit with the observed maximal bandwidth (5 Mbps). src dest throughput throughput without RTS/CTS if alone r06 r Mbps 3 Mbps r04 r Mbps 3.4 Mbps Table 3. TCP Throughput: one-hop away sources. 5.3 Mix of TCP and UP traffics In this subsection, we study the bandwidth sharing between coexisting TCP and UP traffics. We first assume that a source (here r02) sends both UP traffic and TCP traffic to a same destination (here r08). We measure the bandwidth obtained by each flow. Results are reported in Table 4. They show that the bandwidth part received by the UP flow is much higher than the one obtained by the TCP flow. For example, the UP flow receives a bandwidth part up to 150 times more than the one obtained by the TCP flow (this is obtained for a source rate of 5 Mbps). For instance, at a source rate of 500 kbps, UP traffic receives a bandwidth part 9 times more than TCP. This phenomenon is naturally expected and observed, as TCP control congestion reduces the TCP transmission window on congestion signaled by packet losses, or time-outs. This result is a reference point for the next experiment. src dest r02 r08 r02 r08 route r02 r03 r09 r08 r02 r03 r09 r08 hop number 3 3 traffic UP TCP throughput 430 kbps 2.8 kbps for 5 Mbps for 1 Mbps 400 kbps 12.6 kbps for 500 kbps 355 kbps 39.1 kbps for 250kbps 213 kbps 170 kbps for 125 kbps 119 kbps 303 kbps Table 4. Throughput: same source for TCP and UP traffics. We now assume that the destination of the UP flow is the source of the TCP flow and vice-versa. We measure the bandwidth obtained by each traffic. Results are reported in Table Results 5. show that UP traffic is still highly favored with regard to TCP traffic. The only interesting point is that with UP rate equal to 250 kbps, the TCP goodput is 343 kbps, this time, twice as much as before ; however a deeper analysis of TCP competition with UP on a network is necessary to explain the causes. 6 Influence of mobility In this section, we study the impact of mobility on the received signal power and on the bandwidth available between any two nodes in the multihop network. TCP or UP

5 src dest r02 r08 r08 r02 route r02 r03 r09 r08 r08 r06 r04 r02 hop number 3 3 traffic UP TCP throughput 343 kbps 2.6 kbps for 5 Mbps for 1 Mbps 443 kbps 6.1 kbps for 500 kbps 390 kbps 34.5 kbps for 250 kbps 224 kbps 343 kbps for 125 kbp 106 kbps 469 kbps Next hop (to destination) vaio3 vaio2 vaio1 0 R09 R08 R07 R06 R05 R04 R03 Next-hop vs time R02 Table 5. Throughput: reverse sources for TCP and UP. R01 No route traffic is sent to or from a mobile node while it is moving. We have conducted different experiments considering different mobility types (pedestrian, vehicle) and different scenarios. Results reported in this section correspond to vehicle mobility. The routers are immobile inside the building, and laptops (VIO1, VIO2 and VIO3) are placed outside. The mobile node, VIO3, is embedded in a moving vehicle. Router r02 sends UP traffic to VIO1, VIO2 and VIO3. The trajectory of VIO3 consists in a loop around the central tower hosting the platform. The topology of the network is illustrated on Figure 3. It shows in dotted lines the links of the mobile VIO3 to the network which appear at different times (only one of which is used by VIO3 to reach R02 at any time). istance (to destination) Figure 4. Next hop, VIO1 istance vs time Figure 5. istance, VIO3 vaio2 Next-hop vs time vaio1 0 R09 Next hop (to destination) R08 R07 R06 R05 R04 R03 R02 R01 No route Figure 6. Next hop, VIO3 Figure 3. Topology of the network during the mobility experiments. We can see from Figure 4 also, that almost at all times the VIO1 routes go through VIO2. Figures 5 and 6 depict on VIO3 the variations of respectively the number of hops and the next hop to reach destination r02. We distinguish the following time intervals: for time Ø ¾½ the next hop is r07, the distance increases from 4 to 5; for time ¾½ Ø ¾¾ there is a short time while the route is lost. This is due to a topology change leading to a route update. for ¾¾ Ø, the router r02, in the tower, is in range of VIO3 for about 15 seconds, after what r03 becomes directly reachable for a few seconds. for Ø, there is a network connectivity problem. In fact the mobile is no longer in useful range of other nodes, as suggested by the power measurements, which show that r03 is reachable only for brief durations: either the link is asymmetric, or there is packet loss, or a combination of those (which are expected, approaching range limit). for Ø ½¼, the distance to r02 increases from 2 to 7, the next hop is successively r03, r02, r03 and VIO1. for ½¼ Ø ½¼, there is a short time while the route

6 is lost; as the routes switch from VIO1 to VIO2, which is closer to the other routers of the network. for Ø ½¼, the next hop is successively VIO2 and r09. Signal (db) Signal (db) Figure 7. Signal vs time, VIO3-95 R02 R03 R07 R09 vaio1 vaio2 Figure 8. Signal vs time, VIO3 Figures 7 and 8 show the variations of the received power on VIO3. We observe that the node chosen as next hop during a time interval is received with appropriate power. n interesting phenomenon occurs when considering the routes of VIO1 on Figure 4 (together with the graphs of VIO3 on Figure 6 and the topology on Figure 3): before time 54 and after time 72, VIO3 is in fact within range of R02 or R03, and VIO1. Then the routes of VIO1 (which can reach the network only through VIO2 the rest of the time), switch to VIO3 for a number of destinations, and VIO2 itself goes through the path VIO2 VIO1 VIO3 R02 to reach R02 (and R09 does the same), having found a shortest path, which is entirely outside and around the building. In general, this experiment shows the good behavior of the OLSR protocol with mobility, although short network outages indicate that parameters could be better tuned. Here OLSR reconstructs the routing tables proactively, it would be interesting to compare with the reactive approach, using link failure and ring expension repairing for instance. 7 Conclusion Mobile ad-hoc networks are autonomous, self-adaptive and support mobility. These qualities make them essen- tial for military applications. To succeed, these networks must achieve good performance. That is the reason why we have built a MNET platform to quantitatively evaluate the behavior of such networks. The overall results show that the OLSR protocol and its implementation provide ad-hoc network connectivity and routing, with good performance. The measurements have highlighted different aspects of performance of the network: high variability of the performance depending on the hop number, unfairness depending on the hop number and on traffic nature (TCP or UP) but also topology. This suggests that quality of service features could complement greatly the protocol. On the other hand, the studied scenario did not show RTS/CTS efficiency. In scenario with mobility, the adaptativeness of the OLSR protocol was evidenced, with appropriate changes of routes. The power measurements show that nevertheless with mobility links can change greatly with time and additionnally the delays introduced in the routing changes, both show that some tuning of parameters (like message emission intervals) of the OLSR protocol might improve the performance and are subject of further work. In general, the measurements performed on this platform allow to conclude that OLSR routing seems to be well adapted to military mobile ad-hoc networks. Further work is needed to introduce quality of service in such networks and to allow service differentiation. Security and multicast traffics are further issues for MNETs in military context. References [1]. S. Tanenbaum, Computer Networks, Prentice Hall, [2] C. Perkins, E. Belding-Royer, S. as, OV d hoc On-emand istance Vector Routing, IETF: The Internet Engineering Task Force, July 2003, RFC 3561, work in progress. [3]. Johnson,. Maltz, Y-C. Hu, The ynamic Source Routing Protocol for Mobile d Hoc Networks (SR) IETF: The Internet Engineering Task Force, pril 2003, draft-ietf-manet-dsr-09.txt, work in progress. [4] J. Moy, Open Shortest Path First (OSPF) Version 2, IETF: The Internet Engineering Task Force, January 1998, RFC [5] R.G.Ogier,M.Lewis,F.L.Templin,Topology issemination Based on Reverse-Path Forwarding (TBRPF), IETF: The Internet Engineering Task Force, November 2003, RFC. [6] P. Jacquet, P. Muhletaler,. Qayyum,. Laouiti, T. Clausen, L. Viennot, Optimized Link State Routing Protocol, IEEE INMIC, ecember 2001, Pakistan. [7] C. djih, T. Clausen, P. Jacquet,. Laouiti, P. Minet, P. Muhlethaler,. Qayyum, L. Viennot, Optimized Link State Routing Protocol, IETF: The Internet Engineering Task Force, October 2003, RFC [8]. Qayyum,. Laouiti, L. Viennot, Multipoint relaying technique for flooding broadcast messages in mobile wireless networks, HICSS: Hawai International Conference on System Sciences, January 2002, Hawai, US. [9]. Laouiti and C. djih, Mesures des performances du protocole OLSR, IEEE SETIT 2003 Tunisia March 2003 (in French). [10] Y. Wang and J. J. Garcia-Luna-ceves, Channel Sharing among Competing Flows in d Hoc Networks, Proc. of IEEE Symposium on Computers and Communications (ISCC 03), Kemer - ntalya, Turkey, June 30 - July