OLSR Simulation and Implementation

1. OLSR Simulation and Implementation Christopher Dearlove chris.dearlove@baesystems.com Slide 1

2. Overview Requirements. Design Decisions. Software Organisation. Compliance, Limitations and Extensions. Simulation Example. Ground Sensor Network Demonstration. Additional Requirements. Slide 2

3. OLSR Simulation and Implementation Requirements • A framework for a generic AHRP. • An implementation of OLSR within this framework. • To be usable to simulate AHRP, e.g. in OPNET. • To be usable to implement AHRP in real time on e.g. Linux platform. (Laptop or PDA using IEEE 802.11b WLAN.) • To include IPv4 and IPv6 options. • To be able to interwork with other implementations of OLSR. • To add some compliant proprietary extensions to OLSR. • To allow extension to modified versions of OLSR. • To support dynamic parameters. Slide 3

4. Software Design Decisions Code to be written in standard C++. To use object oriented design. OLSR code to be independent of OPNET and Linux. OPNET and Linux specific “wrappers” for code. Separate compilation for IPv4 and IPv6. Various reporting features. Slide 4

5. Ahrp Olsr Ahrp_Factory packet_received() routing_failure() link_layer_notification() timeout() packet_received() routing_failure() link_layer_notification() timeout() 1 «registration» register_creation() create() «creation» «creation» Secure_Olsr Aodv Wrapper AHRP and OLSR Classes and Creation Classes in black exist Classes in red are hypothetical Slide 5

6. Olsr Ahrp Routing_Table Linux_Routing_Table Linux_Packet_Handler Packet_Handler allocate() send() allocate() send() 1 1 1 1 1 add() replace() remove() add() replace() remove() 1 1 1 1 Linux_Wrapper 1 1 AHRP and OLSR Class Usage Slide 6

7. OLSR Software (1) Initial implementation of OLSRv5, then converted to OLSRv7, then finally to OLSRv11 (RFC 3626). Some observations from use provided to OLSR authors. Designed to be fully compliant with OLSR 3626, including • Multiple interfaces. • Host and network associations (including dynamic changes). • Link layer notification and link quality. • All parameters are configurable (including dynamically). • IPv4 and IPv6 (separate compilation). Slide 7

8. OLSR Software (2) Current limitations • Does not piggyback messages, but will process received piggybacked messages. • No packet size control or message fragmentation, but will handle fragmented messages. Extensions (all optional) • Minimum message intervals. • MPR Set reuse. • Link layer notification details. • Use HELLO messages to update Interface Association Set and MID messages to change Two Hop Neighbour Set. Slide 8

9. Minimum intervals as proportion of normal message interval (link layer notification, medium power, high mobility) zero (fully reactive) quarter interval half interval zero (fully reactive) quarter interval half interval Delivery performance Receive overhead per node 100% 50 80% 40 60% 30 proportion of data received mean overhead (kbyte/s) 40% 20 20% 10 0% 0 10 30 50 10 30 50 number of nodes number of nodes OLSR Simulation Example Slide 9

10. OLSR Implementation Current wrapper is for Linux. Demonstrated on small mobile networks of laptops and PDAs. Particular current interest in sensor networks • Initially stationary. • Later to add mobile autonomous platform nodes. Used in • Operational trials of a BAE SYSTEMS First Generation Unattended Ground Sensor Network in both open terrain and urban environments. • Collaborative B2NCW (Building Blocks for Network Centric Warfare) programme. (Also looking at reactive protocols.) Slide 10

11. Ground sensor node (low power ARM based processor with WLAN, acoustic interface, geo-phone sensor and GPS) Universal camera node Demonstration network integrated with an in-service sounding ranging system Tactical Network access First Generation UnattendedGround Sensor Network Avionics Group Sensor Systems Division Slide 11

12. S4 S3 GW1 S0 S2 Example of network topology, as seen from S0 C0 S1 M1 Packet receptions at S0 during demonstration 1.2 1 0.8 0.6 0.4 0.2 0 00:00:00 01:12:00 02:24:00 03:36:00 Sensor Network Trial Results Mean hop counts from S0 Sensor 1 (S1) 1.74 Sensor 2 (S2) 1.07 Sensor 3 (S3) 1.01 Sensor 4 (S4) 2.75 Controller 0 (C0) 1.01 Gateway 1 (GW1) 1.54 Monitor 1 (M1) 1.02 The non-integer values demonstrate OLSR network reconfiguration during demonstration Slide 12

13. Additional Requirements The following have been identified as of interest in the development of ad hoc networks, and OLSR in particular • Security. • Low power operation (including power control). • Covertness (possibly including reactive capability). • Multicast. • Addressing issues (including IPv6). • External gateway issues (aggregation, dynamism). Slide 13

14. Conclusions Key points • Generic ad hoc routing protocol framework. • Flexible implementation of OLSR. • Minimum interval extension for highly mobile network. • Field trials of ad hoc sensor network. • Additional requirements, especially security. Slide 14

15. Contact and Acknowledgements Christopher Dearlove BAE SYSTEMS Advanced Technology Centre Great Baddow, Chelmsford, Essex, CM2 8HN, UK. +44 1245 242194 chris.dearlove@baesystems.com The author gratefully acknowledges the support of his colleagues in BAE SYSTEMS plc, Ericsson Microwave Systems AB and Ericsson Telebit A/S, and the support from the UK, Swedish and Danish MoDs under the EUCLID/Eurofinder programme, Project RTP6.22 (B2NCW). The First Generation Unattended Ground Sensor Network Concept Demonstration was undertaken on behalf of BAESYSTEMS Avionics Group Sensor Systems Division. Slide 15