Design and Implementation of the
OLSR Protocol in an Ad Hoc
Framework
Juan Gutiérrez Plaza
Supervisor: Raimo Kantola
Instructor: José Costa Requena
Networking Laboratory - Helsinki University of Technology
October 2003
Outline







Introduction
Background
Motivation
Objectives
Framework
Tests & Results
Conclusions & Future Work
2
Introduction

Ad Hoc Networks




Ad Hoc: For this and only this purpose
Networks without infrastructure
This Master’s Thesis analyses Ad
Hoc networks
It proposes a solution for Ad Hoc
problems (e.g. routing problem)
3
Background (1/6)

Ad Hoc Networking





Networks without infrastructure
All nodes are capable of moving
Nodes work as routers
No wire connections
Flexible topology
4
Background (2/6)


Ad Hoc networking is being studied
deeply
Very important applications




Maritime communications
Conferences and congresses
Military applications
Advantages



Networks without geographical constraints in
fixed networks
Flexible topology for a variety of applications
No wire connections
5
Background (3/6)

Problems

Routing is very hard!


Security


Nodes are constantly changing
Vulnerabilities…
Small devices

Batteries, little computing power…
6
Background (4/6)

Type of routing protocols



Pro-active
 Routes are known beforehand
 DSDV, OLSR…
Re-active
 Routes are searched for only when needed
 DSR, AODV, TORA…
Hybrid
 Mix pro and re-active solutions
 ZRP
7
Background (5/6)

The OLSR Protocol (1/2)

Proactive protocol



Link state based (routes are known
beforehand)
Exchange topology information with
other nodes of the network regularly
Based on Multi Point Relays (MPRs)
MPRs minimize flooding
 Selected nodes which forward broadcast
messages during the flooding process

8
Background (6/6)

The OLSR Protocol (2/2)

MPRs (continued)


MPRs of a given node
must cover all two hop
nodes away from the
initial node
Type of control messages


Hello. Neighbour sensing
TC. Topology Control. This
messages are forwarded
like usual broadcast
messages
9
Motivation

Creating an Ad Hoc Framework
architecture based on
multiprotocol nodes




Nodes run different routing protocols
Protocols collaborate during the lifetime
of the Ad Hoc network
Studying pro and re-active protocols
working together
Exploring new algorithms for Ad Hoc
networks
10
Objectives (1/2)


Implementing the OLSR Protocol
Designing and implementing some
modules of the framework





The Common Cache
The Registry
The Common Cache Registry Server
(CCRS)
Running OLSR and AODV in the
same node
Reaching nodes in different types of
networks
11
Objectives (2/2)
■ My work
■ Mixed work
■ Not implemented yet
12
Framework (1/4)


Complete routing architecture for
Ad Hoc networks
Modules


Independent routing module
Common Ad Hoc module
Common Cache Register Server (CCRS)
 Common Registry
 Common Cache
 Control Logic


Kernel Routing Table
13
Framework (2/4)

The Ad Hoc Framework block diagram
14
Framework (3/4)

Objectives




Collecting information from each
protocol
Evaluating this information
Choosing the best values for protocol
parameters in order to improve the
performance
Sending and receiving packets of other
nodes running a different protocol
15
Framework (4/4)

Operations






Register a protocol
Unregister a protocol
Add a new route
Delete a route
Get a protocol configuration
Set a protocol configuration
16
Tests & Results (1/5)

Configuration





6 nodes (5 iPAQs and 1 laptop)
All nodes were running a GNU/Linux
operating system
One MANET interface per node
OLSR and/or AODV
Inside the Electrical & Communications
Department building
17
Tests & Results (2/5)

Test 1

Fully meshed nodes
running OLSR
 Excellent behaviour
 Maximum time for
discovering a route: 7 s
 Average delay: 3.117 ms
 0% packet lost
 Incoming control packet
load: ~0.9 KB
 No broken links
18
Tests & Results (3/5)

Test 2

Nodes aligned within node range coverage
running only OLSR
 Ping from the first node to the last node
 Many broken links
 Strange behaviour (interference or bugs?)
 12% packet lost
 Average delay: 27.7 ms
 Maximum time for discovering a route: 15 s
 Incoming control packet load: ~0.4 B
19
Tests & Results (4/5)

Test 3


Nodes connected through a single intermediate
node
OLSR





Excellent behaviour
Maximum time for discovering a route: 15 s
2% packet lost
Incoming control packet load: ~0.5 B
Some broken links
20
Tests & Results (5/5)

OLSR+AODV



AODV couldn’t find OLSR nodes but OLSR nodes
could find AODV nodes
Very good behaviour (similar to previous case)
Common modules worked very well and central
node managed perfectly both protocols
21
Conclusions & Future Work (1/2)

Conclusions




OLSR works quite well with static nodes
The behaviour is worse when nodes are
moving (links are broken)
With several hops the protocol has a
strange behaviour (interferences or
bugs?), the behaviour is different every
time the test is performed
Framework improves the performance
of protocols running alone
22
Conclusions & Future Work (2/2)

Future work



Implementing the Control Logic module
Studying if the Control Logic algorithm
can be satisfied by devices with
reduced computational power (e.g.
iPAQs)
Deeper study of the cooperation of
protocols in the framework and their
performance
23
Thank you!, Kiitos!, ¡Gracias!

Any questions?
24