Optimization on OLSR Protocol for LowerRouting Overhead

Yong Xue, Hong Jiang, and Hui Hu

Southwest University of Science and Technology,Mianyang 621010, Sichuan, P.R. China

belat@163.com

Abstract. The optimized link state routing (OLSR) designed by theIETF’s mobile ad hoc networks (MANET) working group is one of thefour base routing protocols for ad hoc networks. This protocol is a tabledriven, proactive protocol. It is particularly suitable for large and densemobile networks with less latency. However, high routing overhead isa dominant disadvantage as comparing with reactive protocols. In thispaper, an optimizing scheme on OLSR by reducing the average size ofHELLO messages, as well as the size and the amount number of TCmessages is proposed. After analyzing and computing the overhead ofthe optimized OLSR protocol, which is implemented and simulated onNS-2 in different scenarios, the simulation results indicate that its routingoverhead is reduced; meanwhile, the latency and the average end-to-enddelay are still maintained in a low level without any change.

1 Introduction

Mobile ad hoc networks are infrastructure-less networks where mobile nodescommunicate wirelessly and the network topology changes constantly. The nodesorganize themselves to route packets in a multi-hop fashion from a source to adestination. Reactive and proactive routing protocols have been proposed in theliterature. On the one hand, proactive protocols find and maintain paths to everydestination before they are actually required, which creates additional overhead.On the other hand, reactive protocols find paths only when they are actuallyrequired, without creating additional overhead [1]. Moreover, there are otherprotocols, such as, hybrid protocols, combining the benefits of both protocolsby working proactive in the local neighborhood of a node and reactive for nodesfurther away [2].

OLSR is a proactive protocol and has higher overhead than reactive protocolsand most other proactive protocols, although it has advantages in large and densenetwork with less latency and average end-to-end delay, which characteristicis shown by figures in section 2. Studying the routing protocols overhead isnecessary, especially in large and dense ad hoc networks, while many theoreticalanalysis on overhead and performance have been done for OLSR.

In this paper, we present an approach specifically designed to minimize rout-ing overhead of the OLSR, it differs from existing literature on the study per-formance of the OLSR in which some performance of latency and delay were

G. Wang et al. (Eds.): RSKT 2008, LNAI 5009, pp. 723–730, 2008.c© Springer-Verlag Berlin Heidelberg 2008

724 Y. Xue, H. Jiang, and H. Hu

partial sacrificed for minimizing routing overhead. Fish Eye approach is adaptedto large networks in which the amount number of TC (Topology Control) mes-sage is reduced by defining three zones encircled one node with deferent radiusand broadcasting frequency, but the number of invalid routes increases suchthat more time must be spent on updating topology message list and foundnew routes [3]. Hierarchical OLSR need select some node to build up backbonesubnet supporting point-to-point wireless [4].

In this paper, some novel approaches are presented for enhancing the perfor-mance of OLSR which mainly comprises three ways to optimize OLSR protocol.At first, the size of HELLO message is shorted by comparing the link-states ofneighbor set with the current ones so that only changed links and MPRs (MultiPoint Relays) are transmitted. Second, the first TC message is no longer gener-ated by node N, but is calculated and generated by its MPRs, so the amountnumber of TC message is decreased. Last, in the original protocol a node broad-casts link-state information between itself and its MPR selectors, in which TCmessage has redundant information when two nodes are selected as MPR byeach other. The one link-state information is broadcasted by TC message twicetimes, so we select one of those nodes to advertise it.

For the experiments, the latest release of NS-2 (NS-2.29) is used. NS-2 is adiscrete event simulator widely used in the networking research community. Ingeneral, the NS-2 installation will include all software extensions. It containsa detailed model of the physical and link layer behavior of a wireless networkbased on the 802.11 specifications and allows arbitrary movement of nodes withina network area. The new scheme presented in this paper is implemented andsimulated on NS-2, several performance metrics were measured by varying themaximum speed of mobile hosts, routing overhead, latency and average end-to-end delay, etc., those performance metrics are analyzed and compared betweenoriginal OLSR protocol and optimized one.

This paper is organized as follows. In Section 2, we give a brief description ofOLSR’s main operations. In Section 3, we illustrate the new optimization schemefor reducing the overhead of OLSR protocol, and how to compute the overheadof OLSR. The performance of optimized protocol is validated in Section 4 byconfrontation with simulation results. Finally, we conclude in Section 5.

2 The OLSR Protocol

The protocol is an optimization of the classical link state algorithm tailoredto the requirements of a mobile wireless LAN. In the protocol, MPRs are se-lected nodes which forward broadcast messages during the flooding process.This technique substantially reduces the message overhead as compared to aclassical flooding mechanism, where every node retransmits each message whenit receives the first copy of the message. In OLSR, link-state information is gen-erated only by nodes elected as MPRs. Thus, a second optimization is achievedby minimizing the number of control messages flooded in the network. As a thirdoptimization, an MPR node may chose to report only links between itself and its

Optimization on OLSR Protocol for Lower Routing Overhead 725

MPR selectors. Hence, as contrary to the classic link state algorithm, partial linkstate information is distributed in the network. This information is then used forroute calculation [5]. The two main OLSR functionalities, Neighbor Discoveryand Topology Dissemination, are now detailed as follows.

2.1 Neighbor Discovery

A node must perform link sensing on each interface, in order to detect links be-tween the interface and neighbor interfaces. Furthermore, a node must advertiseits entire symmetric 1-top neighborhood on each interface in order to performneighbor detection. Hence, for a give interface, a HELLO message will contain alist of links on that interface (with associated link types), as well as a list of theentire neighborhood. In principle, a HELLO message serves three independenttasks: Link sensing, Neighbor detection, MPR selection signaling.

Three tasks are all based on periodic information exchange within neigh-borhood nodes, and serve the common purpose of ”local topology discovery”.A HELLO message is therefore generated based on the information stored inthe Local link Set, the Neighbor Set and the MPR Set form the local linkinformation base.

The major improvement on OLSR in our work is focused on optimizing theformat of HELLO message and the tactics of operating mode, so the more knowl-edge should be introduced about HELLO message format in detail. The proposedformat of a HELLO message is shown in RFC 3626 (omitting packet, IP andUDP headers).

The data-portion of the general packet format with the ”Message Type” setto HELLO MESSAGE. Reserved field must be set to ”0000000000000” to be incompliance with this specification. HTime field specifies the HELLO emissioninterval used by the node. Willingness field specifies the willingness of a node tocarry and forward traffic for other nodes. Link Code field specifies informationabout the link between the interface of the sender and the following list ofneighbor, the analysis and the improvement will be show more detailed in section3. Link Message Size counted in bytes and measured from the beginning ofthe ”Link Code” field and until the next ”Link Code” field. Neighbor InterfaceAddress is the address of an interface of a neighbor node.

2.2 Topology Dissemination

Each node of the network maintains topological information about the networkobtained by means of TC messages. The nodes which were selected as a MPR bysome of the neighbour nodes broadcast the TC message at every ”TC interval”.The TC message originated from one node to declare the set of nodes whichhaving been selected as MPR. The TC messages are flooded to all networknodes and take advantage of MPRs to reduce the number of retransmissions.To optimize flooding, the OLSR forwarding rule is used: Any node forwards abroadcast message only if it is received for the first time from anode having beenselected as MPR.

726 Y. Xue, H. Jiang, and H. Hu

Thus, a node is reachable either directly or via its MPRs. The neighbor infor-mation and the topology information are refreshed periodically, and they enableeach node to compute the routes to all known destinations. These routes arecomputed with Dijkstra’s shortest path algorithm. Hence, they are optimal asconcerns the number of hops.

3 Optimization on OLSR Protocol

The optimization schemes presented in this paper mainly comprise three aspectsby reducing the size of HELLO message, the amount number and the averagesize of TC message.

3.1 A Novel Operating Tactics about HELLO Messages

In HELLO interval a list of the entire neighborhood is transmitted periodically,because the HELLO message contains a lot of link-states and generated in highfrequency, which results very high overhead, especially, in high density of nodesscenarios. For reducing the size of HELLO messages we present a novel ”neighbortuples” by which it is not necessary for HELLO messages to transmit the entireneighborhood in every HELLO interval.

In OLSR a node records a set of ”neighbor tuples” (N neighbor main addr,N status, N willingness), describing neighbors. N neighbor main addr is themain address of a neighbor, N status specifies if the node is NOT SYM or SYM.N willingness in an integer between 0 and 7, and specifies the node’s willing-ness to carry traffic on behalf of other nodes. The new ”neighbor tuples” addsa field named N modified which is a signal for indicating whether the link-stateis modified between the two periods.

Based on the mended neighbor tuples the generating and processing of HELLOmessage can be designed as below operations:

HELLO Message Generation. A node N broadcasts its link-states once per“HELLO interval”, but not the entire neighborhood, just only include the linksand neighbor nodes information which have modified in a “HELLO interval” bychecking the field of N modified in the neighbor tuples.

HELLO Message Processing. When a node received a HELLO message fromits neighbor node, at first, search the field of Original Address of the packet tofind whether the node of sender has been added in the neighbor set. If theinformation of sender do not exist in the table, then attaches a item and fillsthe every field with neighbor information, which means the node is a new joinedneighbor node, and transmits the entire neighborhood messages to the node ofsender. Otherwise, for an older neighbor it is not necessary to transmit the entireNeighbor set, but just the information of node which link-state or attribute ofMPR has changed.

When any link-state between the node N and its neighbors is changed in aslot of broadcasting the HELLO messages, the corresponding N modified field of

Optimization on OLSR Protocol for Lower Routing Overhead 727

“neighbor tuples” would be modified to one, which means the link-state shouldbe updated and advertised to its neighbors. As soon as the changed link-statesare broadcasted, the corresponding N modified field would be reseted to zero.

3.2 Reduction of the Amount Number of TC Messages

An advertised link set is put in a TC message and transmitted to all neighborsof a node, only the nodes which were selector as a MPR by the sender node areresponsible for forwarding control traffic. In actually, the entire information oflink-states of one node and its MPR Selector has been gotten by MPRs throughHELLO message excepting which link-states are between neighbor node and itsMPR Selector, if we can indicate it by the Link Code field of HELLO message,then the first TC messages which broadcasts by a node to its all neighbors can beabolished , in result, the MPRs replace their MPR Selectors to disseminate theTC messages by mining the related information form HELLO messages, becausethe refreshing frequency of HELLO messages is higher than TC messages at leasttwice times, which can ensure that the link-state information is up to date.

For achieving the goal, we add a new Neighbor Types to Link Code field ofHELLO message, which named SEL NEIGH for indicating whether the senderis a MPR selected by its neighbor node. Then every MPR can build up the TCmessages including the link-states between its MPR selectors and themselvesMPR selectors, of course, the Original Address of TC messages must be theMPR selectors’.

3.3 Reduced on the Size of TC Messages

Through the ”link types” a node can get whether it and its neighbor nodes aremutual MPR, if two node select its neighbor node as MPR each other, whenthe TC messages is building just one node which is chose to disseminate thelink-state between themselves. The choice of node can simply be decided bycomparing their address, although the effect on the whole overhead of routingprotocol is small, but it has not any side effect also.

3.4 The Overhead Computation of Optimized OLSR Protocol

At first, we compute the overhead of original OLSR protocol, define some inputparameters which characterize the ad hoc network configuration and can be seenas specifications.

The OLSR protocol configuration and scenario parameters include:

1. hdrHello, hdrTC , hdrmsg, hdrpck: size of OLSR message header and packetheader.

2. fH , fTC : frequency of sending HELLO and TC.3. N : total number of nodes.4. M : total number of MPR nodes.5. S: average number of retransmissions per TC message, including the first

transmission by the originator.

728 Y. Xue, H. Jiang, and H. Hu

6. n, m: average number of neighbor per node and MPR selectors per MPR,respectively.

The overhead of OLSR is defined as the average bandwidth, in bytes/s, thebandwidth can be decomposed to, on one hand, the bandwidth used for send-ing and receiving HELLO messages: OsendH , OrecvH ; on the other hand, thebandwidth used for sending and receiving TC messages: OsendTC , OrecvTC . LetszH , szTC and respectively be the average HELLO and TC packet sizes. As eachOLSR packet only has one OLSR message:

OsendH = fH · szH

OsendTC = OrecvTC = fTC · S · szTC

OrecvH = fH · n · szH

Thus, the overhead of the OLSR protocol is equal to:

OOLSR = fH (N + 1) szH + 2 · fTC · S · szTC

Let szaddr, szlinkcode, respectively be the address size and link code size. Thelink code is either symmetric, asymmetric, multipoint relay or lost. When thesimulated network comes to a stable state, it should only have two kinds of linktype (in the optimized protocol it adds to three kinds): symmetric and MPRlinks [3]. Thus the average number of link codes advertised in each HELLOmessages is 2.

In OLSR protocol minimizes the overhead of TC message by using MessageGrouping, through this means many TC messages are grouped into one singleOLSR packet. Therefore, only one packet header is needed for many TC messagesinstead of one packet header for each TC message. The packet header and IPheader are less but number of TC messages exchanged is unchanged, thus theoverhead of due to HELLO and TC messages is:

OTC = 2 · fTC · S · (m · szaddr + hdrTC + hdrmsg) + 2 · f ′TC · S · (hdrpck + hdrIP )

OH = fH (n + 1) (n · szaddr + 2 · szlinkcode + hdrH + hdrmsg + hdrpck + hdrIP )

f ′TC is a coefficient related to the number of TC message received by one node

in period of 1/fTC , which is smaller than fTC .In the optimized OLSR protocol the first TC message is constructed and

broadcasted by the MPR instead of MPR selector, so the S in the overhead ofOTC decreases to S−1, and the items of n ·szaddr of 2 ·szlinkcode will be removedin a relatively stabile network scenario, but when the node move constantly itmaybe reach to 3 · szlinkcode.

Now we can give the reduced overhead of the optimized protocol in a relativelystabile network scenario by putting the values of size of different packet headersinto above equations:

OTC reduce 2 · fTC · (4m + 16) bytes for one node in every period of 1/fTC .OH reduce fH ·(n + 1) (4m + 16) bytes for one node in every period of 1/fTC .

Mostly, fH would be chose by 2 seconds, and fTC by 5, thus, the gain broughtby OH is always several times than OTC ’s by a simply computation.

Optimization on OLSR Protocol for Lower Routing Overhead 729

4 Simulation Results

Every scenario, static and mobile, was generated using the node-movement gen-erator setdest, provided with NS-2. In order to allow for fair performance com-parisons, the same scenarios were always utilized when evaluating each strategy.Each experimental stage is described next. We compute the overhead generatedby OLSR as the number of bytes per second sent or received by an OLSR nodeat the IP level.

Simulation parameters of ship nodes are adopted as follows:Network Type: 802.11, Transmission range: 250m, Field Size: 1500 × 1500,

Node Type: Static, HELLO message rate: Every 2 seconds, TC message rate:Every 5 seconds, Throughput: 2Mbps.

The density of nodes should have a significant influence on the routing proto-cols performance. In general, low density may cause the network to be frequentlydisconnected and high density increases the contention, resulting in a low per-node throughput. In simulations, the number of nodes per simulation area isincreased from 100 to 180 nodes with the rest of the simulation parameters re-main unchanged. The goal is to study how the optimized protocol improves theoverhead comparing to the original protocol in different node densities.

Fig. 1. Results of comparing routing overhead of two protocols

Fig.1.(a) shows the result of simulation, as a whole, the average routing over-head of the optimized protocol decrease to 83% approximately according to theoriginal protocol, which verified the validity of the optimization approach forOLSR protocol. From the another Fig.1.(b), it can be seen that result is notvery good comparing with the last figure’s in mobile scenario, especially, whenthe node moving with speed of 25m/s, the overhead of new protocol just de-creases 4% approximately, obviously, the cause is the average size of HELLOmessages increasing as a result of the neighborhood changing more frequently.In the whole process of simulation the average end-to-end delay and latency havenot almost any different between two protocols.

730 Y. Xue, H. Jiang, and H. Hu

5 Conclusion

In this paper, We have presented an optimizing approach to reduce the overheadthrough rebuilding the format and operating tactic of HELLO and TC messages.In the most case, it can decrease the routing overhead about 17% , and someextreme case, maybe less than that greatly. But we just studied an especialapplication of OLSR in which have not considered any redundancy, in fact OLSRprotocol designed many schemes which have various information redundancy,such as number of MPRs and more link-states information encapsulated intoTC message [6], in that case, the overhead problem is become more prominent.Through the reference [3] we can know in a large network with high density,the proportion of OH in whole overhead is become preponderant, because in ouroptimization the gain brought by OH is larger than OTC greatly, the optimizedOLSR protocol must more suitable to large network.

Although so many works have been done for reducing the overhead of OLSRprotocol, Comparing to the other routing protocol, which still cost much widthfor routing; maybe using more advanced technology to construct backbone netin ad hoc network is a feasible approach.

This paper is supported by Defense Basic Research project under grantA3120060264 and SWSUT project under grant 06zx3106

References

1. Lye, P.C., McEachen, J.C.: A Comparison of Optimized Link State Routing withTraditional Routing Protocols in Marine Wireless Ad-hoc and Sensor Networks. In:40th Annual Hawaii International Conference on System Sciences, pp. 293b–293b.IEEE Press, New York (2007)

2. Costa-Requena, J., Vadar, T., Kantola, R., Beijar, N.: AODV-OLSR scalable ad hocrouting proposal. In: Wireless Pervasive Computing, 2006 1st International Sympo-sium, pp. 5–15. IEEE Press, New York (2006)

3. Nguyen, D., Minet, P.: Scalability of the OLSR Protocol with the Fish Eye Exten-sion.Networking. In: 6th International Conference on Networking, pp. 88–95. IEEEPress, New York (2006)

4. Ge, Y., Lamont, L., Villasenor, L.: Hierarchical OLSR - A Scalable Proactive Rout-ing Protocol for Heterogeneous Ad Hoc Networks. In: Wireless And Mobile Comput-ing, Networking And Communications, vol. 3, pp. 17–23. IEEE Computer SocietyPress, Los Alamitos (2005)

5. Optimized Link State Routing Protocol, http://www.ietf.org/rfc/rfc3626.txt6. Villanueva-Pena, P.E., Kunz, T., Dhakal, P.: Extending Network Knowledge: Mak-

ing OLSR a Quality of Service Conducive Protocol. In: 2006 international conferenceon Wireless communications and mobile computing, pp. 103–108. ACM Press, NewYork (2006)