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: each node keeps a routing table to each known destination at all times. When a node has data to send, there is no route-discovery delay. This makes OLSRv2 suitable for latency-sensitive applications such as voice, video, and tactical command-and-control traffic.
Improvements over OLSR v1
- Quality-aware link metrics: OLSRv2 can compute routes with quality-aware metrics (signal strength, loss rate, latency), not only 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 each interface. HELLO messages are link-local (hop limit = 1), and nodes never forward them. A HELLO message contains:
- The sender’s own addresses
- The addresses of all known neighbors and their link status
- Link metric values (if you enable link quality)
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
The node detected the link recently and is evaluating it. Bidirectional communication is not yet confirmed, and the link is not usable for routing. The link changes to SYMMETRIC only when the link quality reaches or exceeds HYST_ACCEPT.
The node detected a unidirectional link: node A received a HELLO message from node B, but B did not yet confirm reception from A. The link is not usable for data transmission.
Bidirectional communication is confirmed, and the link quality meets the acceptance threshold. This link is fully usable for data forwarding and MPR selection.
A previously symmetric link is no longer valid. This occurs when no HELLO message arrives within the timeout period, or when the link quality drops below HYST_REJECT. NHDP removes the link from active routing.
NHDP also discovers two-hop neighbors: when node A receives B’s HELLO listing neighbor C, node A records C as a two-hop neighbor that it can reach through B. MPR selection uses this information.
Link quality hysteresis stops the rapid state flapping of marginal links. NHDP accepts a new link only when its quality reaches or exceeds HYST_ACCEPT. It drops an existing link only when its quality falls below HYST_REJECT. This dead-band mechanism keeps the routes stable.
| Parameter | Meaning |
|---|---|
| HYST_ACCEPT | Minimum link quality required for a link to become usable. |
| HYST_REJECT | If link quality drops below this value, the link becomes unusable. |
| INITIAL_QUALITY | The starting quality assigned to a newly discovered link. |
| INITIAL_PENDING | Determines whether a new link is temporarily unusable until its quality is verified. |
true → wait until quality ≥ HYST_ACCEPT
false → link can be used immediately
Multipoint Relays (MPR)
MPRs are the central optimization in OLSRv2. In a simple approach, each node retransmits each broadcast message, which creates an exponential flood of redundant traffic. MPRs solve this problem.
Each node selects a small subset of its one-hop symmetric neighbors as its Multipoint Relays. The selection rule is that the MPR set must cover each 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
- Spread control messages efficiently across the network
- Retransmit broadcast messages such as Topology Control (TC) messages
- Only selected nodes forward these messages, instead of all nodes
- Send far fewer redundant transmissions than pure flooding
- Improve bandwidth efficiency and reduce network congestion
Routing MPRs
- Routing MPRs 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.
| Value | Name | Meaning |
|---|---|---|
| 0 | WILL_NEVER | Never selected as MPR. Does not relay. |
| 7 | WILL_DEFAULT | Default willingness, normal relay capability. |
| 15 | WILL_ALWAYS | Always selected as MPR when possible (e.g., backbone relays). |
Topology Control (TC) Messages
HELLO messages are local, but TC messages carry topology information across the full network. A node generates TC messages only if at least one neighbor selected it as an MPR (that is, if 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
Flooding MPRs flood TC messages across the network. 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.
When the topology changes, a node sends triggered TC messages immediately (with jitter). It does not wait for the next periodic interval. This makes convergence faster after link failures.
Routing Table Computation
Each node assembles a topology graph from three sources:
- Local neighbor information: direct links discovered by NHDP
- Two-hop neighbor information: from HELLO messages
- Topology information: from received TC messages (remote links)
A shortest-path algorithm (Dijkstra) computes the best route to each known destination, with link metrics as edge weights. The node installs the routes in the IP forwarding table.
When a TC message arrives or a local link changes, the node computes the routes again.
Key Protocol Features
| Feature | Description |
|---|---|
| Link Metrics | OLSRv2 moves beyond simple hop-count routing. Link metrics capture the actual quality of a wireless link: signal strength, packet loss rate or estimated throughput. OLSRv2 compresses the metrics into a 12-bit representation (4-bit exponent, 8-bit mantissa) for efficient transmission. OLSRv2 tracks the incoming and outgoing metrics of each link, so it captures asymmetric link quality. |
| Link Quality Hysteresis |
Wireless links near the edge of communication range tend to flicker. Without
hysteresis, a marginal link
would toggle between SYMMETRIC and LOST every few seconds, triggering continuous TC
updates and route
flaps. OLSRv2 addresses this with a dead-band mechanism:
|
| TC Hop Limit | The TC Hop Limit controls how far topology information propagates. The default value of 255 means TC messages reach the entire network. In large networks, reducing the hop limit restricts topology knowledge to a local radius, trading global reachability for reduced overhead. This is useful when nodes communicate primarily with nearby peers. |
| Jitter (RFC 5148) | When multiple nodes start simultaneously, their periodic HELLO and TC messages can collide. OLSRv2 adds a random jitter (up to HP_MAXJITTER for HELLO, TP_MAXJITTER for TC) to each transmission, spreading messages over time and reducing collisions. |
Applications and Use Cases
Military Tactical Networks
OLSRv2 suits the conditions of military operations: mobile nodes, no infrastructure, unreliable links and a need for low-latency communication. Its proactive routing, spectrum efficiency and role-based configuration make it a strong candidate for tactical networks.
Battlefield MANETs
Infantry squads, armored vehicles, and command posts form ad-hoc networks with no fixed infrastructure. Nodes move continuously, and links break and reform as terrain, distance and jamming conditions change. With proactive routing, OLSRv2 computes the routes in advance, so they are 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 use WILL_ALWAYS, so that they are always selected as MPRs. Low-power sensors or dismounted radios use WILL_NEVER, so that they do not relay 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, such as urban operations or areas near 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, and keeps connectivity through the 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
| Application | Description |
|---|---|
| Emergency Response | First responders deploy portable radios in disaster zones where cell infrastructure is destroyed. OLSRv2 provides instant mesh connectivity. |
| Vehicular Networks (VANETs) | Vehicle-to-vehicle communication for convoy management, platoon coordination, and traffic safety. |
| Unmanned Systems | Swarms of UAVs or ground robots form mesh networks for surveillance, reconnaissance, and search-and-rescue. |
| Rural Connectivity | Community mesh networks in areas without telecom infrastructure. |
| Industrial IoT | Factory floors, mining operations, or construction sites where wired infrastructure is impractical. |
Simulating OLSRv2 in NetSim
NetSim Pro v15.0 implements OLSRv2 in full compliance with RFC 7181 (OLSRv2) and RFC 6130 (NHDP). The implementation has 19 source files that cover the complete protocol stack:
- NHDP neighbor discovery
- HELLO message generation and processing
- link quality hysteresis
- MPR selection (flooding and routing variants)
- TC message generation and propagation
- topology information bases
- 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 shows 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, and all others are static
Three-Phase Simulation
The simulation has three phases. A position change of Node 5 starts each phase.
Node 5 is at position (300, 950), within 220 m of Node 7. The link 5–7 is active, connecting Clusters A and B. All 22 links are operational, and all four traffic flows are active.
NHDP converges within approximately 14 s (7-hop diameter × 2 s HELLO interval). TC messages propagate through MPRs, and the routing tables are complete by t ≈ 20 s.
At t = 50 s, Node 5 moves 50 m north to (300, 1000). The distance to Node 7 increases from 220 m to 270 m, exceeding the 250 m range. Link 5–7 breaks.
The only remaining physical connection between Cluster A and B is through Node 6 (distance 228 m, within range). But Node 6 has WILL_NEVER = 0. No node selects it as an MPR, and it does not relay TC messages or forward data packets. Clusters A and B+C are therefore disconnected for all transit traffic.
NHDP detects the loss within ~6 s. Triggered TC messages propagate, and the nodes update their routing tables. Flows F2, F3, and F4 (which cross the A–B bridge) break. Flow F1, which stays within Clusters B+C, remains unaffected.
At t = 150 s, Node 5 returns to (300, 950). Link 5–7 reforms. NHDP re-establishes the symmetric link within ~4 s (two HELLO exchanges).
Triggered TC messages propagate, the nodes compute their routing tables again, and all four flows recover. The Phase 3 metrics match Phase 1, which confirms full protocol recovery.
Configuration Parameters
The following table lists all OLSRv2 parameters configurable in NetSim.
| Parameter | Default | Description |
|---|---|---|
| Hello Interval | 2 s | Time between consecutive HELLO messages |
| Hello Min Interval | 0.5 s | Minimum time between two HELLO transmissions |
| HP Maxjitter | 0.5 s | Random jitter added to HELLO timing |
| TC Interval | 5 s | Time between periodic TC messages |
| TC Min Interval | 1.25 s | Minimum time between two TC transmissions |
| TP Maxjitter | 0.5 s | Random jitter added to TC timing |
| TC Hop Limit | 255 | Maximum hops a TC message can travel |
| T Hold Time | 15 s | How long topology info from TCs remains valid |
| A Hold Time | 15 s | How long advertised neighbor info is retained |
| Willingness | 7 | MPR willingness value (0–15) |
| Link Quality | Disabled | Enable link quality metrics for routing |
| Hyst Accept | 0.8 | Quality threshold to accept a pending link |
| Hyst Reject | 0.3 | Quality threshold to drop an existing link |
| Initial Quality | 1.0 | Quality assigned to a newly discovered link |
| Initial Pending | false | Whether new links start in PENDING state |
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.