that are needed to setup OLSR network will also be described and the ... time, ad hoc wireless network must be capable to self organize and self configure itself.
Inter-working of OLSR implementations on different platforms 1,3 1
S.Suhaimi, 2,3S.R Azzuhri, 3K. Daniel Wong, 2Norfizah Md. Ali
Sultan Idris Education University, 2University of Malaya, 3 Malaysia University of Science and Technology
Abstract- Optimized Link State Protocol (OLSR) is a popular mobile ad-hoc network protocol. This paper discusses a multi-platform deployment of OLSR on multiple environments including the Linux platform, Windows platform and also PDA platform. Requirements that are needed to setup OLSR network will also be described and the comparison of the OLSR implementation on a different platform is discussed further
bandwidth and energy. The protocol itself must be capable of keeping the routing table small in order to decrease the network overhead [2]. Generally, routing protocol needs distributed operation (host can enter and leave anytime), loop-freedom (host send information uselessly creating overhead), demand-based operation, proactive operation, security, “sleep” period operation, unidirectional link support [1].
Keywords: multipoint relay, ad-hoc, cross platform, OLSR I. INTRODUCTION Mobile ad-hoc network is a type of "spontaneous network" which has gaining its popularity among mobile user nowadays. It is useful when dealing with wireless devices in which some of the devices are part of the network, in which only for the duration of a communications session. Hence, the need for a dynamic network topology is eminent. A "Mobile Ad hoc Network" is generally known as MANET [4]. MANET consists of mobile platforms for example a router with multiple hosts and wireless communications devices. It is simply referred to as 'node', and frees to move arbitrarily. The node may be located in airplanes, ships, trucks, cars, perhaps even on people or very small devices. There may be multiple hosts per router. MANET is an autonomous system of mobile nodes. The system may operate in isolation, or may have gateways to and interface with a fixed network. OLSR is a proactive routing protocol for mobile ad hoc networks. The protocol inherits the stability of a link state algorithm and has the advantage of having routes that immediately available when needed due to its proactive nature. OLSR is an optimization over the classical link state protocol, tailored for mobile ad hoc networks. OLSR is designed to work in a completely distributed manner and does not depend on any central entity. The protocol does not require reliable transmission of control messages. Each node sends control messages periodically and therefore sustain a reasonable loss of some such messages. Such losses occur frequently in radio networks due to collisions or other transmission problems. Due to the fact that the mobile structure is changing all the time, ad hoc wireless network must be capable to self organize and self configure itself. The routing protocols for ad hoc wireless of several hosts have limited sources, such as
II. OPTIMIZED LINK STATE ROUTING The Optimized Link State Routing Protocol (OLSR) is a protocol that is developed for mobile ad hoc network (MANET). It is a variation of traditional link state routing, modified for improved operation in ad hoc network. It was operated as a table driven and proactive routing protocol such as the node in MANET exchange the topology information with other nodes regularly. The routes in the proactive protocol are always immediately available when needed [3]. The key feature of this protocol is multipoint relays (MPRs). It has topological changes that cause floods of the topological information to all available hosts in the network. Therefore, the multipoint relays (MPRs) are used to reduce the overhead of network floods and size of link state update. Every node selects a set of its neighbour node as multipoint relays (MPRs). Only MPRs nodes are responsible for forwarding control traffic. MPRs node will only declare link-state information when the requirement for OLSR provide the shortest path information message [1]. The node which neighbour selected as MPR, announce this information periodically in their ‘Control Message’. In route calculation, MPRs are used to form the route from a given node to any destination in the network. It also used to facilitate efficient flooding of Control Message in the network. OLSR use two kinds of Control Messages; Hello Messages and Topology Control (TC) messages [4]. Hello Messages will only sent information one hops away. It is used to find the information about the link status and the host’s neighbours. With the Hello Messages the Multipoint Relay (MPR) selector is set to construct and describe to which neighbours that has chosen this host to act as MPR and from this information the host can calculate its own set of the MPRs [4].
978-1-4244-2108-4/08/$25.00 © 2008 IEEE
1
On the other hand, the Topology Control messages broadcasted throughout the entire network. It is used in broadcasting information about own advertised neighbours which includes at least the MPR selector list. However, the TC messages are broadcasted periodically and only the MPR hosts can forward the TC messages [1].
these MPR selector neighbour nodes is assumed to be retransmitted by the node. This set can change over time (for example when a node selects another MPR-set) and is indicated by the selector nodes in their HELLO messages. Each node has a specific "Multipoint relay Selector Sequence Number" (MSSN) associated with this set. Whenever its MPR selector set is updated, the node also increments it’s MSSN.
2.1 OLSR Procedures The multipoint relays idea is to minimize the overhead of flooding messages in the network by reducing duplicate retransmissions in the same region. Each node in the network selects a set of nodes in its neighbourhood which may retransmit its messages. This set of selected neighbour nodes is called the "Multipoint Relay" (MPR) set of that node. The neighbours of A node which are *NOT* in its MPR set, receive and process broadcast messages but do not retransmit broadcast messages received from A node.
Reference node 1-hop neighbors 2-hop neighbors
2-hop neighbors
Figure 2: MPR Selection
m1 Reference node (A)
A
m2
1-hop neighbors
m3
Figure 1: 1-hop neighbors and 2-hop neighbors.
Each node selects its MPR set among its one hop neighbours (Figure 1). This set is selected such that it covers (in terms of radio range) all nodes that are two hops away (Figure 1). The neighbourhood of any A node can be defined as the set of nodes which have a symmetric link to A node. The 2-hop neighbourhood of A node can be defined as the set of nodes which do not have a symmetric link to A node but have a symmetric link to the neighbourhood of A node. The MPR set of A node, denoted as MPR (A). It is then an arbitrary subset of the neighbourhood of A node which satisfies the condition in which every node in the 2-hop neighbourhood of A node must have a symmetric link toward MPR (A). The smaller the MPR set is, the more optimal is the routing protocol gives an analysis and example about MPR selection algorithms. Each node maintains information about a set of its neighbours. This is the set of neighbours, called the "Multipoint Relay Selector set" (MPR selector set), which have selected the node as a MPR (Figure 2). A node obtains this information from the periodic HELLO messages received from the neighbours. A node broadcast message is then intended to be diffused in the whole network, coming from
OLSR relies on selection of MPRs, and calculates routes through these nodes. For instance, MPR nodes are selected as intermediate nodes in the path between a source and a destination. To enable this, each node in the network periodically broadcast the information describing which neighbours have selected it as a MPR. Upon receipt of this "MPR Selector" information, each node calculates or updates the route to each known destination. So principally, the route is a sequence of hops through the MPRs from source to the destination. MPRs are selected among the one hop neighbours with "symmetric" for example bi-directional link. Hence, selecting the route through MPRs automatically avoids the problems associated with data packet transfer on uni-directional links such as the problem of not getting an acknowledgment for the data packets at each hop. III. OLSR DEPLOYMENT The OLSRd was developed by Andreas Tonnesen at University Graduate Centre (UNIK), located at Oslo, Norway. The OLSRd project is still being developed and from time to time, the stable version has been released. The OLSR software is downloaded through www.olsr.org web site for both Linux and Windows binary. The PDA software (OLSR CE) can be download from the third party source at http://www.grc.upv.es/calafate/olsr/olsr.htm.. The latest release source, version 0.4.10 was used in this testbed setup for Linux and Windows platform and version 1.2.0 for PDAs. The OLSR testbed setup was separated into three different platforms; on Linux, Windows XP and Windows Mobile (PDA) platform. On the Linux platform, all the nodes were upgraded into the latest kernel, version 2.6.19 which can be downloaded from the FTP site. Windows XP Home Edition was used instead of Windows XP pro because it's considered suffice MANET to work. For experiments to be successful, three notebooks were used in the testbed. All PDAs were installed with Windows Mobile 5.0 (Table 1).
978-1-4244-2108-4/08/$25.00 © 2008 IEEE
2
Processor
Memory Storage
Dell Latitude
Acer Aspire
HP iPAQ
D500
5580
rw6828
Intel Pentium M
Intel Core 2 Duo
Intel PXA272
Processor 100
Processor 1.66
Processor 416
MHz
GHz
MHz
256 MB RAM
512 MB RAM
40 GB HDD
80 GB HDD
Intel Pro/100 VE
Intel PRO/Wireless
Network
3945ABG Network
Connection
Connection
64 MB RAM 1 GB Memory Card HP iPAQ Wi-Fi Wireless Adapter (IEEE802.11B)
Figure 3: Connectivity between all nodes (Linux platform)
Network Adapter
Intel Pro/Wireless LAN 2100 3A Mini PCI Adapter
Other Device
Marvell Yukon 88E8038 PCI-E Fast Ethernet Controller
COMBO Drive
Tri-Band (900/1,800,1900 MHz) GSM/GPRS/EDG E Wireless radio Bluetooth
CDRW Drive Bluetooth
Table1: List of nodes with hardware specification. For testing purpose, all three notebooks that on the Linux platform were configured with IPv6 address. The entire nodes are capable to detect and communicate with each other. The nodes establish a network where infrastructure does not exist or where services are not required. All nodes were interconnected with each other running on OLSR daemon (Figure 3). The IEEE 802.11 Ad-hoc mode does not support for multihop where OLSR does have. To prove this in real situation, we have setup the testbed where the Acer node is located out of range with Telco3 node, while the Telco2 is located at the centre. When the Acer node wants to communicate with Telco3 node, it will go through the Telco2 node. From the experiment, it proves that the Acer node can communicate to Telco3 node through Telco2 node, where the Acer node and Telco3 node is out of radio range communication. The testbed is shown in Figure 4. In realistic, all nodes must be moved faraway from each others. To move all the nodes (out of range) in the experimental lab was a difficult task, when it was handled individually. One of the Linux service, 'ip6tables' was used to make the network match with the environment need. This ip6tables is used to set up, maintain, and inspect the tables of IPv6 packet filter rules in the Linux kernel. Several different tables may be defined. Each table contains a number of built-in chains and may also contain user-defined chains. Each chain is a list of rules which can match a set of packets. Each rule specifies what to do with a packet that matches. This is called a `target', which may be a jump to a user-defined chain in the same table.
Figure 4: Multihop on Linux platform On the other hand, a firewall rule specifies criteria for a packet, and a target. If the packet does not match, the next rule in the chain is the examined; if it does match, then the next rule is specified by the value of the target, which can be the name of a user-defined chain or one of the special values ACCEPT, DROP, QUEUE, or RETURN. The main thing that it should know is the MAC address for the nodes. In this testbed, packet drops are expected from the end node and at the starting node via the routing tables and vice versa. ip6tables on telco1 are used in order to prevent packets from going directly from Acer to Telco3 as follow:, filter all out-going packets with MAC address of telco3 (# ip6tables -A INPUT –m mac –mac-source -j 00:18:DE:95:52:2B –j DROP). Equally, Telco3 are doing the same things to avoid the packet directly to Acer. This forces the traffic between Acer and Telco3 to go through Telco2 to their destination. At the routing table, centre node (telco2) can be seen. From the experiment done, it shows the same result as before. Therefore, same implementation was expected for windows and PDA platform; in which the connection using 3 PDA devices and all nodes in IPv4 have already been tests.
978-1-4244-2108-4/08/$25.00 © 2008 IEEE
3
others successfully. The collections of the experiment result are shown as table below (Table3).
Platform
Figure 6: Multiple platform on OLSR network The experiment done was using at least two nodes from each platform because the OLSR connection did not work if it is used in a single node. The network setup for multiple platforms is shown as in Figure 6. OLSR
IP
configuratio
configurat
n
ion
Operatin g system
Other
Acer
Configuratio
IPv4 and
Core 6
n on IPv6
IPv6 addresses Install with
Telco1
Linux Platform
Install with Fedora
Fedora
Configuratio
IPv4 and
Core 5
n on IPv6
IPv6
Telco2
Windows
Configuratio
Install with
XP
n on IPv4
IPv4 only
Telco3
Windows Platform
addresses
Windows
Configuratio
Install with
XP
n on IPv4
IPv4 only
Configuratio
Install with
n on IPv4
IPv4 only
Configuratio
Install with
n on IPv4
IPv4 only
DW1
Mobile 5.0 Windows
DW2
PDA Platform
Windows
Mobile 5.0
software
Linux Platform
Windows
PDA
Platform
Platform
Nodes
Acer
Telco1
Telco2
Telco3
DW1
DW2
Acer
IPv4/IPv6
IPv4/IPv6
IPv4
IPv4
IPv4
IPv4
Telco1
IPv4/IPv6
IPv4/IPv6
IPv4
IPv4
IPv4
IPv4
Telco2
IPv4
IPv4
IPv4
IPv4
IPv4
IPv4
Telco3
IPv4
IPv4
IPv4
IPv4
IPv4
IPv4
DW1
IPv4
IPv4
IPv4
IPv4
IPv4
IPv4
DW2
IPv4
IPv4
IPv4
IPv4
IPv4
IPv4
Table3: “Ping” result for all nodes Generally, all nodes are able to communicate on IPv4 although the OLSR configuration on the Linux platform is set for IPv6. It is because the nodes in this platform have been configuring with IPv4 address on the wireless adapter (Table2). The test done did not use IPv6 on Windows and PDA platform because the OLSR software for that platform at this time is disabled for the IPv6.
Wireshar k ip6table
Wireshar k ip6table
Ethereal
Ethereal
Table2: List of nodes with software specification. The experiment shows that the entire nodes in OLSR network are well functioning and it can communicate each
3.1 Network Configuration OLSR nodes on Linux platform must have the latest update kernel from the ftp site and must be installed with the gcc. All the nodes should be enablied with the IPv6. The experiment was set using the global IPv6 addresses in order to enhance and manage the network. It is also can be set with the site-local IPv6 addresses. The wireless interface on each host should be configuring with the same ESSID. It must be configure in the card with “ad-hoc” mode. On the other hand, it is compulsory to release the UDP/698 from blocking. In which, the package in OLSR is actually communicating using UDP protocol. It used the port 698 (port number) that has been assigned by AINA for exclusive usage by the OLSR protocol. In addition, when all the networks are well configured, it is then move on to the next step in which to configure the olsrd.conf file. The main option that have to be changed is the debug level (0 – 9) which can be seen through the process where the OLSR runs. Next is the IP version (6) and lastly is the wireless interface name (eth1). The details about the configuration can be found at the olsrd.conf document. It is also can be enhance depend on the need of the user. The interface for the wireless is different between each others and it should be verified that it will be used for the OLSR. For example, if the nodes have a connection with Ethernet and wireless adapter therefore in default, eth0 is for the wire and eth1 for the wireless. If the nodes used more than two network adapters, it must confirm which the wireless adapter that it will use for the OLSR. It must be certain that the
978-1-4244-2108-4/08/$25.00 © 2008 IEEE
4
interface at the olsrd.conf file is correct. The entire configuration is shown in Table 4.
Acer / Telco2 / Telco3 /etc/sysconfig/network … NETWORKING_IPV6=yes /etc/sysconfig/network_scripts/ifcfgeth1 … MODE=Ad-Hoc ESSID=olsr CHANNEL=1 RATE=11M
/etc/olsrd.conf DEBUG 3 IPVERSION 6 … INTERFACE “eth1” { ... Ip6AddrType global Ip6MulticastGlobal ff0e::1 … }
Table 4: The configuration for Linux platform The configuration on Windows and PDA platform is much easier compare to the Linux platform. It is because, the OLSR software on both platforms are using GUI (Graphical User Interface). It does not show the details about the installation process at the backside and it is not necessary to know about the script, which is better for those who are not interested with command instruction. Before the installation begins, the wireless network must be configured first. It is because the OLSR software will detect and capture the IP that was set during the installation. 3.2 Methodology After the installation and configuration done, the OLSR command will start with “olsrd” on the terminal for the Linux. It will then show the entire process base on the debug configuration setting that has set at olsrd.conf file. If it chooses more big number like 2, 3 until 9, it will show more detail about the process. It also can check the routing table using “route” command. In windows platform, to run the windows process, clicks the “OLSR switch” shortcut icon on the desktop windows and then makes some simple configuration using GUI. After that, run the process using click “Start” button. The result will show at the output, route and node tab in the interface. If it need more detail about the OLSR process, we just choose big number at the debug option. However, it is different on PDA where the software icon is not displayed. It finds the software through search application to get the software itself. It will prompt windows interface to make some configuration after the run of the process. The debug information will store as a file at \temp\trace.txt as a default and it also can be set similar with Windows and Linux platform at the debug option. This experiment used “ping” or “ping6” command on all platforms whenever it needs to know either the connection was successful or not. Wireshark network analyzer on Linux platform and ethereal network analyzer on Windows platform are purposely used to monitor the network behaviours. IV. RESULT ANALYSIS As referred to the experiment that has been done, it shows that the OLSR was designed to work in a completely
distributed manner and does not depend on any central entity that has discussed before. In other cases, it did not work as a single node when the network was designs in the different platform but it will work when another connection in the same platform were made. OLSR is a flat routing protocol; that does not need central administrative system to handle its routing process. The reactiveness to the topological changes can be adjusted by changing the time interval for broadcasting the Hello messages. In which it increases the protocols suitability for ad hoc network with the rapid changes of the source and destination pairs. Due to the simplicity or OLSR routing protocol in interfaces, it is easy to integrate the routing protocol in the existing operating systems without changing the format of the header of the IP messages. OLSR is proposed for the application that does not allow the long delays in the transmission of the data packets. Therefore, a dense network is the best working environment for OLSR protocol, in which a large number nodes can be concentrate through it communication. OLSR provides multiple OLSR interface addresses and external routing information in which can be functions as gateways to another possible network. From the testbed, it will then make some comparison between Linux, Windows and PDA platform. All the comparison is shown on the Table5.
LINUX
Windows
PDA
1. The OLSR software support both IPv4 and IPv6 2. It has to install the gcc software for compiling the OLSR and GTK2.0 development libraries when it needs to compile the GUI front-end. 3. Installation is quite difficult because it used command 4. It needs to configure the script on olsrd.conf file. 5. It runs using terminal and need to open many terminals to see the output, “ping” and routing table. 6. It can monitor the network activities using wireshark 7. It can work on both IPv4 and
1. The OLSR software support IPv4 only 2. It does not need to update the latest version of windows and can work on windows XP professional and home edition. 3. The installation is easy because it used GUI interface. 4. It does not need to know about the script. 5. It runs on a single interface to see the setting, output, route and node list. 6. It can test the connection using “ping” at command mode. 7. It also can see the network activity using ethereal on windows 8. User did not know the background
1. The OLSR software support IPv4 only 2. It is hard to find the source that can run on windows mobile 5.0 and used the 3rd party OLSR software. 3. It not needs to update the latest version of windows. 4. Installation easy because it used GUI interface. 5. It is hard to find the execute file to run the OLSR 6. It does not need to know about the script 7. It can not display the process installation
978-1-4244-2108-4/08/$25.00 © 2008 IEEE
5
IPv6 although we have set on the script for IPv6. It should be communicate either on IPv6 network or IPv4 network when we set for both IP addresses. 8. Compulsory to release the UDP/698 from blocking. 9. Need to set same ESSID, CHANNEL and RATE on network configuration. 10. Must set MODE to Ad-Hoc
process during installations. 9. Set the network into computer-tocomputer (ad-hoc) network only on the wireless configuration 10. It need to set same network SSID 11. It need to set to allow incoming echo request in windows firewall
and during the running process. 8. It only can be test using “ping” 9. Do not know the background process 10. Set this is a device-todevice (adhoc) connection 11. Need to set same at the network name
REFERENCES [1]
[2]
[3]
[4]
[5] [6]
H. Aleksandr. “Comparing AODV and OLSR Routing Protocols”.Telecommunication Software and Multimedia Laboratory. Helsinki University of Technology. Sjokulla, April 2004. Laoutti, P. Muhlethaler, A. Najid and E. Plakoo. “Simulation Results of the OLSR Routing Protocol for Wireless Network”. 1st Mediterranean Ad-Hoc Networks workshop (Med-Hoc-Net). Sardegna, Italy, 2002. P. Jacquet, A. Laouitti, P. Minet and L. Viennot. “Performance Analysis of OLSR Multipoint Relay Flooding in Two Ad-Hoc Wireless Network Models”. Research Report – 4260. RSRCP journal special issue on mobility and internet. INRIA, September 2001. T. Andreas. “Implementing and Extending the Optimized Link State Routing Protocol”. Department of Informatics, University of Oslo. Oslo, August 2004. C. Guillaume and F. Eric. “Ananas: A New Ad hoc Network Architectural Scheme”. INRIA Research Report – 4354. January 2002. P. Jacquet, P. Muhlethaler, A. Qayyum, A. Laouiti, L. Viennot, T. Clausen. “Optimized Link State Routing Protocol”. Internet draft INRIA Rocquencourt. France, March 2001.
Table5: Comparison table between PDA, Windows and Linux for the installation and the implementation of the OLSR. The comparison of the OLSR implementation in which platform is the best depends on the purpose and the background of the user. If the user needs to learn detail about the OLSR and familiar with the Linux environment, they should choose to develop on the Linux platform rather than Windows or other GUI-enable platform. V. CONCLUSION As proactive protocol, OLSR reduce the control overhead in which it forces the MPR to propagate the updates of the link state. OLSR does not need to do extra work for the discovery of the route; hence it provides low single packet transmission latency. Therefore, the reactivity of the detecting topological changes in OLSR can be improved by shortening the time interval of periodic control messages. On the other hand, OLSR can immediately know the status of the link and it can possibly extend the quality of service information to such protocol, so that the host knows in advantage the quality of the route. In addition, OLSR showed good performance with the constantly changing host, hence the network structure is always changing. OLSR has the fixed upper bound for the overhead in a network regardless to the network’s traffic. OLSR also has advantage in networks with high density and highly sporadic traffic. However, their scalability is limited when network size increases and their routing table size grow nonlinearly and the control messages can block the actual data packet [1]. The storage complexity of the OLSR protocols is however related on the total of the host in the network. It has to have all the possible routes in Routing Table. The OLSR therefore, must keep the topology information in the topology set, MPR information in MPR selector set and also update the state information about the links and neighbours. OLSR on the other hand, must maintain the information about the hosts that it does not need.
978-1-4244-2108-4/08/$25.00 © 2008 IEEE
6
