Skip to main content

OLSR PATCH FOR NS2

 

UM-OLSR

UM-OLSR is an implementation of the OLSR (Optimized Link State Routing) protocol for the ns-2 Network Simulator. The code is released under the terms of the GNU General Public License (GPL). Due to lack of time this project is not maintained by myself any more, feel free to take over the task of maintenance if you are interested.

UM-OLSR complies with IETF RFC 3626 and supports all core functionalities of OLSR plus the link-layer feedback option. The software has been successfully tested on ns-2, and patches for several versions of the simulator are provided. It is widely employed by the wireless communications research community, as the high number of references in research papers reveal. In addition, it was ported to ns-3 by Gustavo Carneiro (INESC Porto) and to Omnet++ by Alfonso Ariza (Universidad de Málaga). Thus, you can also run OLSR simulations in modern network simulators.
      

Features

Compliant with core OLSR (as described in RFC 3626).
Support for link-layer feedback.
Highly configurable from TCL scripts, i.e., without the need of recompiling the whole simulator. You can:
Activate/deactivate debug mode.
Change the interval at which every message type is sent.
Change nodes’ willingness for forwarding data packets on behalf of other nodes.
Print whatever data structure managed by a node at a certain time.

Download

The source code of UM-OLSR in hosted on SourceForge.net: download.

Contributed patches

Here you can find a sample script for configuring a simulation, as well as some UM-OLSR patches for different versions of ns-2 that were contributed by different people. Thanks a lot to all of them.

olsr_example.tcl
um-olsr-2.33_v0.8.8.patch by Damian Philipp.
um-olsr-2.34_v0.8.8.patch by Damian Philipp.
um-olsr-2.35_v0.8.8.patch by Andrey Lyubimov.

Installation

I assume that you have downloaded and unpackaged the allinone distribution of ns-2 (any of the versions supported by UM-OLSR). Copy um-olsr-0.8.8.tgz (substitute “0.8.8″ for your UM-OLSR version number) into ns-allinone-2.29/ns-2.29/ (substitute “2.29″ for your ns-2 version number), and then do:$ cd ns-allinone-2.29/ns-2.29/ $ tar zxvf um-olsr-0.8.8.tgz $ ln -s ./um-olsr-0.8.8 ./olsr $ patch -p1 < olsr/um-olsr_ns-2.29_v0.8.8.patch

If you had not installed ns-2 yet, then do the following:
$ cd ..
$ ./install
On the other hand, if you are installing UM-OLSR on a running installation of ns-2:
$ ./configure
$ make distclean
$ ./configure
$ make
Note that the code should work on most ns-2 releases, but only patches for some versions are provided. If you need UM-OLSR on a different ns-2 version, just create the appropriate patch and share it if you want.
Using UM-OLSR can be used like any other routing agent in ns-2, so you can use the node-configcommand to attach an OLSR routing agent to the mobile nodes which are to be created.$ns_ node-config -adhocRouting OLSR
After creating your mobile nodes, you can configure each UM-OLSR routing agent individually or all at once. But first we will see the available configuration options and their default value.
debug_ : Print debugging messages on stdout (false).
use_mac_ : Enable link-layer feedback (false).
willingness_ : Set the willingness for forwarding data packets on behalf of other nodes (WILL_DEFAULT = 3).
hello_ival_ : Set the interval of HELLO messages transmission (2 sec).
tc_ival_ : Set the interval of TC messages transmission (5 sec).
mid_ival_ : Set the interval of MID messages transmission (5 sec). This has no actual effect in the simulation, since multiple interfaces are not supported.

In oder to configure all agents, write sentences like these:
Agent/OLSR set debug_ true
Agent/OLSR set hello_ival_ 3
In order to configure a single agent:
set ra [$mobilenode agent 255]
$ra set use_mac_ true
$ra set tc_ival_ 6
By default, every UM-OLSR packet may piggyback up to 4 OLSR messages. You can change this value by redefining the OLSR_MAX_MSGS constant and recompiling the simulator. For the simulation results, the length of IPv4 addresses are assumed by default. If you prefer the length of IPv6 addresses, define OLSR_IPv6 and compile again.
           Once you have performed a simulation, you get a trace file where you can see what happened during the execution. Let us see with some examples the format of the traces generated by UM-OLSR. Following examples use the classic notation of ns-2 trace files. However, “tagged” and “new trace” formats are also supported.
s 21.537326976 _0_ RTR  --- 98 OLSR 56 [0 0 0 0] -------
 [0:255 -1:255 32 0] [1 12 [HELLO 0 0 12]]
The line above indicates that node 0 is sending an OLSR packet (size = 56 bytes) which contains one HELLO message. Specific information about the OLSR packet is by the end of the line (inside the final brackets): number of contained messages, packet sequence number, and the list of OLSR messages. Then we find information about the messages themselves: type, originator address, hop count and message sequence number.
r 13.833447485 _2_ RTR  --- 45 OLSR 84 [0 ffffffff 1 800] -------
 [1:255 -1:255 32 0] [2 10 [HELLO 1 0 10][TC 1 0 11]]

The example above shows the reception of a packet which piggybacks two messages, one HELLO and one TC. Information about each one is also shown. If you need further details about the ns-2 trace formats, please see the ns-2 manual.

courtesy:mohit p thahiliani

Comments

Popular posts from this blog

Link State Routing Protocol

Link state routing is a method in which each router shares its neighborhood’s knowledge with every other router on the internetwork. In this algorithm, each router in the network understands the network topology and then makes a routing table depending on this topology. Each router will share data about its connection to its neighbor, who will, consecutively, reproduce the data to its neighbors, etc. This appears just before all routers have constructed a topology of the network. In LSP, each node transmits its IP address and the MAC to its neighbor with its signature. Neighbors determine the signature and maintain a record of the combining IP address and the MAC. The Neighbor Lookup Protocol (NLP) of LSP derives and maintains the MAC and IP address of every network frame accepted by a node. The extracted data can support the mapping of MACs and IP addresses. The link-state flooding algorithm prevents the general issues of broadcast in the existence of loops by having every node mainta

Windows 11

Windows has always existed to be a stage for the world’s innovation. It’s been the backbone of global businesses and where scrappy startups became household names. The web was born and grew up on Windows. It’s the place where many of us wrote our first email, played our first PC game and wrote our first line of code. Windows is the place people go to create, to connect, to learn and to achieve – a platform over a billion people today rely on. The responsibility of designing for that many people is one we don’t take lightly. The past 18 months brought an incredible shift in how we used our PCs; we went from fitting the PC into our lives to trying to fit our whole lives into the PC. Our devices weren’t just where we went for meetings, classes and to get things done, but where we came to play games with friends, binge watch our favorite shows and, perhaps most meaningfully, connect with one another. In the process we found ourselves recreating the office banter, the hallway chatter, worko

Matter: A next generation home standard

The smart home is evolving. To date, if you've wanted to get into developing a smart home, you've had to deal with the multitude of smart home ecosystems, and making sure that each device you buy is compatible. That, however, may soon change — thanks to new smart home standard called Matter. Matter isn't available just yet, but when it is finally released, it could completely change how you buy smart home products, for the better. All of the best smart home devices could soon support the standard, helping them all work together nicely, and ensuring that no matter what products you buy, you'll be able to use them. Matter is basically the name of a new smart home connectivity standard . But this standard is a little unlike others. That's because of the fact that it's being developed by the Connectivity Standards Alliance, which counts hundreds of companies as members. That includes the likes of Google, Alexa, and Apple. So, whether you prefer to use Google Assista