Optimized Link State Routing Protocol
Version 2 (OLSRv2)

What is OLSRv2?

The Optimized Link State Routing Protocol Version 2 (OLSRv2) is a proactive link-state routing protocol for Mobile Ad Hoc Networks (MANETs), specified in IETF RFC 7181. It is the successor to the original OLSR protocol (RFC 3626).

In a MANET, wireless nodes communicate without fixed infrastructure. Nodes act as both hosts and routers, forwarding packets for one another. As nodes move, links form and break. A routing protocol must continuously track these changes and maintain paths between all pairs of nodes.

OLSRv2 is proactive: every node maintains a routing table to every known destination at all times. There is no route-discovery delay when data needs to be sent. This makes OLSRv2 suitable for latency-sensitive applications such as voice, video, and tactical command-and-control traffic.

Improvements over OLSR v1

• Advanced link metrics – Routes can be computed using quality-aware metrics (signal strength, loss rate, latency), rather than just hop count.
• Generalized message format – OLSRv2 uses RFC 5444, a standardized and extensible packet format shared across MANET protocols.
• Reduced control overhead – Improved MPR selection and message suppression rules reduce unnecessary transmissions.
• Modular neighbor discovery – OLSRv2 delegates neighbor discovery to NHDP (RFC 6130), a standalone protocol that can be reused by other routing protocols.

Protocol Architecture

OLSRv2 operates as a layered system. NHDP discovers neighbors and evaluates link quality. OLSRv2 builds on this information to construct a network-wide topology map and compute routes.

How OLSRv2 Works

Neighbor Discovery (NHDP)

Before OLSRv2 can build a topology map, each node must know its immediate neighbors and the neighbors of those neighbors. The Neighbor Discovery Protocol (NHDP, RFC 6130) handles this.

Each node periodically broadcasts HELLO messages on every interface. HELLO messages are link-local (hop limit = 1) and are never forwarded. A HELLO message contains:

• The sender’s own addresses
• The addresses of all known neighbors and their link status
• Link metric values (if link quality is enabled)

When node A receives a HELLO message from node B, it records B as a one-hop neighbor. Links transition through the following states:

NHDP Link State Definitions

Multipoint Relays (MPR)

MPRs are the central optimization in OLSRv2. In a naive approach, every node retransmits every broadcast message, creating an exponential flood of redundant traffic. MPRs solve this.

Each node selects a small subset of its one-hop symmetric neighbors as its Multipoint Relays. The selection rule: the MPR set must cover every two-hop neighbor. Only MPRs retransmit broadcast messages from the selecting node. All other neighbors receive the message but do not forward it.

Flooding MPRs

• Responsible for efficient dissemination of control messages across the network
• Retransmit broadcast messages such as Topology Control (TC) messages
• Only selected nodes forward these messages, instead of all nodes
• Significantly reduce redundant transmissions compared to pure flooding
• Improve bandwidth efficiency and reduce network congestion

Routing MPRs

• Routing MPRs are used to optimize route computation and topology representation.
• A node advertises only its Routing MPR selectors in TC messages.
• This reduces the amount of topology information shared across the network.
• It minimizes routing table complexity in large networks.

Willingness Values

Nodes advertise a willingness value from 0 to 15 to indicate how ready they are to serve as an MPR.

Topology Control (TC) Messages

While HELLO messages are local, TC messages carry topology information across the entire network. A node generates TC messages only if at least one neighbor has selected it as an MPR (i.e., it has MPR selectors).

Each TC message contains:

• The originator’s address
• The set of neighbors that selected this node as an MPR (the advertised neighbor set)
• An Advertised Neighbor Sequence Number (ANSN) that increments whenever the set changes
• Validity time and transmission interval

TC messages are flooded network-wide via Flooding MPRs. The TC Hop Limit (default 255) controls propagation range. When a node receives a TC message, it updates its topology information base and recomputes routes.

Triggered TC messages are sent immediately (subject to jitter) when topology changes, rather than waiting for the next periodic interval. This accelerates convergence after link failures.

Routing Table Computation

Each node assembles a topology graph from three sources:

1. Local neighbor information – direct links discovered by NHDP
2. Two-hop neighbor information – from HELLO messages
3. Topology information – from received TC messages (remote links)

A shortest-path algorithm (Dijkstra) computes the best route to every known destination, using link metrics as edge weights. The resulting routes are installed in the IP forwarding table.

Whenever a TC message arrives or a local link changes, routes are recomputed.

Key Protocol Features

Applications and Use Cases

Military Tactical Networks

Battlefield MANETs

Infantry squads, armored vehicles, and command posts form ad-hoc networks with no fixed infrastructure. Nodes move continuously; links break and reform as terrain, distance, and jamming conditions change. OLSRv2’s proactive routing means routes are pre-computed and immediately available. When a soldier sends a situational awareness update or calls for fire support, there is no route-discovery delay.

Multi-Echelon Command Networks

A battalion-level network often has company-level clusters connected by relay nodes – vehicles with high-power radios or elevated antennas. This structure maps directly to the multi-cluster topology that OLSRv2 handles naturally. Relay nodes are configured with WILL_ALWAYS to guarantee MPR selection, while low-power sensors or dismounted radios use WILL_NEVER to avoid relaying traffic. This mirrors the military command hierarchy.

Spectrum Efficiency and Electronic Warfare

MPR-based flooding reduces the number of radio transmissions compared to pure flooding. In a 50-node network with average degree 8, MPR flooding can cut retransmissions by more than half. In congested RF environments – urban operations, proximity to hostile electronic warfare – this reduction is operationally significant. Fewer transmissions mean a smaller electronic signature and reduced risk of detection or direction-finding by adversaries.

Resilience to Node Loss

When a relay node is destroyed, disabled, or moves out of range, OLSRv2 detects the link failure via NHDP within approximately 6 seconds (3 × HELLO interval). It generates triggered TC messages and recomputes routes across the surviving topology. The protocol recovers without manual intervention, maintaining connectivity through any available alternate paths.

Coalition Interoperability

OLSRv2 is an IETF standard built on the generalized MANET packet format (RFC 5444). This standardization enables interoperability across different radio platforms, vendors, and coalition partner forces. Multiple nations can contribute nodes to a shared tactical network using off-the-shelf OLSRv2 implementations.

Other Applications

Simulating OLSRv2 in NetSim

NetSim Pro v15.0 implements OLSRv2 with full compliance to RFC 7181 (OLSRv2) and RFC 6130 (NHDP). The implementation spans 19 source files covering the complete protocol stack: NHDP neighbor discovery, HELLO message generation and processing, link quality hysteresis, MPR selection (both flooding and routing variants), TC message generation and propagation, topology information bases, and Dijkstra-based routing table computation.

Users can configure all protocol parameters through the NetSim GUI or directly in the XML configuration file.

Example: OLSRv2 Multi-Cluster MANET

The built-in example demonstrates OLSRv2 in a 15-node pure wireless MANET arranged as three clusters connected by relay nodes.

Scenario Configuration

• Nodes: 15 wireless nodes, IEEE 802.11g
• Propagation: Range-based pathloss, 250 m fixed range
• Routing protocol: OLSRv2 with NHDP
• Simulation time: 300 seconds
• Traffic: Four CBR/UDP flows starting at t = 20 s
• Mobility: File-based – only Node 5 moves; all others are static

Three-Phase Simulation

The simulation runs through three distinct phases, each triggered by a position change of Node 5.

Configuration Parameters

The following table lists all OLSRv2 parameters configurable in NetSim.

References

• RFC 7181   T. Clausen et al., “The Optimized Link State Routing Protocol Version 2 (OLSRv2),” IETF, April 2014.
• RFC 6130   T. Clausen, C. Dearlove, J. Dean, “MANET Neighborhood Discovery Protocol (NHDP),” IETF, April 2011.
• RFC 5444   T. Clausen et al., “Generalized MANET Packet/Message Format,” IETF, February 2009.
• RFC 5148   T. Clausen, C. Dearlove, B. Adamson, “Jitter Considerations in MANETs,” IETF, February 2008.
• RFC 3626   T. Clausen, P. Jacquet, “Optimized Link State Routing Protocol (OLSR),” IETF, October 2003.