1. 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

2. 2 Outline  Introduction  Background  Motivation  Objectives  Framework  Tests & Results  Conclusions & Future Work

3. 3 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)

4. 4 Background (1/6)  Ad Hoc Networking Networks without infrastructure All nodes are capable of moving Nodes work as routers No wire connections Flexible topology

5. 5 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

6. 6 Background (3/6)  Problems Routing is very hard!  Nodes are constantly changing Security  Vulnerabilities… Small devices  Batteries, little computing power…

7. 7 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

8. 8 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

9. 9 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

10. 10 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

11. 11 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

12. 12 Objectives (2/2) ■ My work ■ Mixed work ■ Not implemented yet

13. 13 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

14. 14 Framework (2/4)  The Ad Hoc Framework block diagram

15. 15 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

16. 16 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

17. 17 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

18. 18 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

19. 19 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

20. 20 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

21. 21 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

22. 22 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

23. 23 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

24. 24 Thank you!, Kiitos!, ¡Gracias!  Any questions?