Hubbry Logo
Optimized Link State Routing ProtocolOptimized Link State Routing ProtocolMain
Open search
Optimized Link State Routing Protocol
Community hub
Optimized Link State Routing Protocol
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Optimized Link State Routing Protocol
Optimized Link State Routing Protocol
Optimized Link State Routing Protocol
View on Wikipedia
from Wikipedia
Diagram of OLSR data flow.

The Optimized Link State Routing Protocol (OLSR)[1] is an IP routing protocol optimized for mobile ad hoc networks, which can also be used on other wireless ad hoc networks. OLSR is a proactive link-state routing protocol, which uses hello and topology control (TC) messages to discover and then disseminate link state information throughout the mobile ad hoc network. Individual nodes use this topology information to compute next hop destinations for all nodes in the network using shortest hop forwarding paths.

Features specific to OLSR

[edit]

Link-state routing protocols such as Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) elect a designated router on every link to perform flooding of topology information. In wireless ad hoc networks, there is different notion of a link, packets can and do go out the same interface; hence, a different approach is needed in order to optimize the flooding process. Using Hello messages the OLSR protocol at each node discovers 2-hop neighbor information and performs a distributed election of a set of multipoint relays (MPRs). Nodes select MPRs such that there exists a path to each of its 2-hop neighbors via a node selected as an MPR. These MPR nodes then source and forward TC messages that contain the MPR selectors. This functioning of MPRs makes OLSR unique from other link state routing protocols in a few different ways: The forwarding path for TC messages is not shared among all nodes but varies depending on the source, only a subset of nodes source link state information, not all links of a node are advertised but only those that represent MPR selections.

Since link-state routing requires the topology database to be synchronized across the network, OSPF and IS-IS perform topology flooding using a reliable algorithm. Such an algorithm is very difficult to design for ad hoc wireless networks, so OLSR doesn't bother with reliability; it simply floods topology data often enough to make sure that the database does not remain unsynchronized for extended periods of time.

Multipoint relays

[edit]

Multipoint relays (MPRs) relay messages between nodes. They also have the main role in routing and selecting the proper route from any source to any desired destination node.

MPRs advertise link-state information for their MPR selectors (a node selected as a MPR) periodically in their control messages. MPRs are also used to form a route from a given node to any destination in route calculation. Each node periodically broadcasts a Hello message for the link sensing, neighbor detection and MPR selection processes.[2]

Benefits

[edit]

Being a proactive protocol, routes to all destinations within the network are known and maintained before use. Having the routes available within the standard routing table can be useful for some systems and network applications as there is no route discovery delay associated with finding a new route.

The routing overhead generated, while generally greater than that of a reactive protocol, does not increase with the number of routes being created.

Default and network routes can be injected into the system by Host and Network Association (HNA) messages allowing for connection to the internet or other networks within the OLSR MANET cloud. Network routes are something reactive protocols do not currently execute well.

Timeout values and validity information is contained within the messages conveying information allowing for differing timer values to be used at differing nodes.

Criticisms

[edit]

The original definition of OLSR does not include any provisions for sensing of link quality; it simply assumes that a link is up if a number of hello packets have been received recently. This assumes that links are bi-modal (either working or failed), which is not necessarily the case on wireless networks, where links often exhibit intermediate rates of packet loss. Implementations such as the open source OLSRd (commonly used on Linux-based mesh routers) have been extended (as of v. 0.4.8) with link quality sensing.

Being a proactive protocol, OLSR uses power and network resources in order to propagate data about possibly unused routes. While this is not a problem for wired access points, and laptops, it makes OLSR unsuitable for sensor networks that try to sleep most of the time. For small scale wired access points with low CPU power, the open source OLSRd project showed that large scale mesh networks can run with OLSRd on thousands of nodes with very little CPU power on 200 MHz embedded devices. [citation needed]

Being a link-state protocol, OLSR requires a reasonably large amount of bandwidth and CPU power to compute optimal paths in the network. In the typical networks where OLSR is used (which rarely exceed a few hundreds of nodes), this does not appear to be a problem.

By only using MPRs to flood topology information, OLSR removes some of the redundancy of the flooding process, which may be a problem in networks with moderate to large packet loss rates[3] – however the MPR mechanism is self-pruning (which means that in case of packet losses, some nodes that would not have retransmitted a packet, may do so).

Messages

[edit]

OLSR makes use of "Hello" messages to find its one hop neighbors and its two hop neighbors through their responses. The sender can then select its multipoint relays (MPR) based on the one hop node that offers the best routes to the two hop nodes. Each node has also an MPR selector set, which enumerates nodes that have selected it as an MPR node. OLSR uses topology control (TC) messages along with MPR forwarding to disseminate neighbor information throughout the network. Host and network association (HNA) messages are used by OLSR to disseminate network route advertisements in the same way TC messages advertise host routes.

Hello

[edit]

Topology control (TC)

[edit]

Other approaches

[edit]

The problem of routing in ad hoc wireless networks is actively being researched, and OLSR is but one of several proposed solutions. To many, it is not clear whether a whole new protocol is needed, or whether OSPF could be extended with support for wireless interfaces.[4][5]

In bandwidth- and power-starved environments, it is interesting to keep the network silent when there is no traffic to be routed. Reactive routing protocols do not maintain routes, but build them on demand. As link-state protocols require database synchronisation, such protocols typically use the distance vector approach, as in AODV and DSDV, or more ad hoc approaches that do not necessarily build optimal paths, such as Dynamic Source Routing.

For more information see the list of ad hoc routing protocols.

OLSR version 2

[edit]

OLSRv2 was published by the IETF in April 2014 as a standards-track protocol.[6] It maintains many of the key features of the original including MPR selection and dissemination. Key differences are the flexibility and modular design using shared components: packet format packetbb, and neighborhood discovery protocol NHDP. These components are being designed to be common among next generation IETF MANET protocols. Differences in the handling of multiple address and interface enabled nodes is also present between OLSR and OLSRv2.

Implementations

[edit]
  • OLSR.ORG – Downloadable code for OLSR on Linux, Windows, Mac OS X, FreeBSD, NetBSD and OpenBSD systems. Features a great deal of documentation, including an informative survey of related work.
  • NRL-OLSR – Open source code of NRL-OLSR. Works on Windows, MacOS, Linux, and various embedded PDA systems such as Arm/Zaurus and PocketPC as well as simulation environments ns2 and OPNET., http://cs.itd.nrl.navy.mil/focus/ Archived 2011-09-10 at the Wayback Machine
  • SOURCEFORGE.NET-OLSR – Created by MOVIQUITY and based on studies within the project Workpad, it offers a code in C# to deploy a MANET (Ad Hoc, Meshnet) with protocol OLSR. Developed for WM 6, Win XP and can be adapted to other platforms using .Net Framework and Compact. https://sourceforge.net/projects/wmolsr/

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Optimized Link State Routing Protocol

View on Grokipedia
from Grokipedia
The Optimized Link State Routing Protocol (OLSR) is a proactive routing protocol developed for mobile ad hoc networks (MANETs), which optimizes the classical link-state algorithm by employing multipoint relays (MPRs) to minimize the overhead of flooding control messages and enable efficient topology dissemination. OLSR maintains routes to all destinations in the network by periodically exchanging topology information, providing shortest-path routes in terms of hop count, and is particularly suited for large, dense networks with high mobility and random traffic patterns. At its core, OLSR operates through a set of control messages: HELLO messages for local link sensing and neighbor discovery, Topology Control (TC) messages for broadcasting via MPRs, and Multiple Interface Declaration (MID) messages to handle nodes with multiple interfaces. Each node selects a subset of its one-hop symmetric neighbors as MPRs to cover all two-hop neighbors, ensuring that only these MPRs retransmit TC messages, which significantly reduces redundant transmissions compared to pure flooding protocols. This MPR mechanism, combined with partial link-state reporting (focusing on links to MPR selectors), allows OLSR to compute optimal routes using a shortest-path algorithm like Dijkstra's while keeping control traffic low. OLSR's design emphasizes scalability and efficiency, supporting features such as sequence numbers for message freshness, configurable emission intervals (e.g., TC messages every 5 seconds), and independence from underlying link layers, making it adaptable to various wireless environments. It provides loop-free routing and supports extensions like power-aware operation or integration with external networks, though it assumes bidirectional links and does not inherently handle unidirectional connectivity. The protocol has evolved with OLSR version 2 (OLSRv2), standardized in 2014, which builds on the original by incorporating link metrics for path cost optimization beyond hop count, adopting a generalized packet format from RFC 5444 for flexibility, and separating flooding and routing MPRs to further enhance efficiency in diverse MANET scenarios. OLSRv2 also leverages the MANET Neighborhood Discovery Protocol (NHDP) for neighbor detection, reducing redundancy in message types and improving modularity for future extensions.

Introduction and Background

Overview

The Optimized Link State Routing Protocol (OLSR) is an (IGP) optimized for mobile ad-hoc networks (MANETs), supporting both Internet Protocol version 4 (IPv4) and version 6 (). Developed as a proactive, table-driven , OLSR enables nodes to maintain current knowledge of the network through regular dissemination of link-state information. The protocol's primary goal is to reduce the communication overhead inherent in traditional link-state flooding, achieved via selective relaying that limits redundant message transmissions while preserving route optimality based on minimum hop count. This optimization makes OLSR particularly suitable for large and dense wireless networks where mobility and bandwidth constraints are prevalent. Standardized as an experimental protocol in RFC 3626 in October 2003, OLSR's high-level architecture involves periodic broadcasts of topology updates without requiring a centralized authority, allowing decentralized route computation across the network.

Historical Development

The Optimized Link State Routing Protocol (OLSR) originated from research conducted between 2001 and 2003 at the Institut National de Recherche en Informatique et en Automatique (INRIA) in France, led by Thomas Clausen and Philippe Jacquet, along with collaborators Paul Muhlethaler, Anis Laouiti, Amir Qayyum, and Laurent Viennot. The foundational work was presented in the paper "Optimized Link State Routing Protocol for Ad Hoc Networks," delivered at the IEEE International Multi-Topic Conference (INMIC) in Lahore, Pakistan, on December 30, 2001. The paper, which received the Best Paper award at the conference, introduced OLSR as a proactive routing solution tailored for mobile ad hoc networks (MANETs), emphasizing optimizations to classical link-state algorithms. The primary motivation for developing OLSR stemmed from the inefficiencies of traditional link-state protocols, such as OSPF, in dynamic environments. In MANETs, where topologies change rapidly due to node mobility, conventional flooding mechanisms generate excessive control traffic overhead, consuming limited bandwidth and increasing latency. Researchers at INRIA sought to address this by introducing multipoint relaying to minimize redundant message retransmissions while preserving the benefits of link-state routing, such as shortest-path route computation. This focus on for large, dense networks arose amid growing interest in self-organizing systems for applications like and in the early 2000s. A key milestone occurred in October 2003, when OLSR was standardized as an experimental protocol in RFC 3626 by the (IETF). This document, authored primarily by Clausen and Jacquet under the IETF Mobile Ad-hoc Networks (MANET) , chartered in 1997 to advance routing protocols for dynamic networks, formalized the protocol's specifications and facilitated its evaluation in real-world deployments. Subsequent developments within the IETF MANET WG led to refinements, culminating in the specification of OLSR version 2 (OLSRv2) in RFC 7181, published in April 2014, which incorporated enhancements for greater flexibility and security in modern MANET scenarios. These updates built on the original protocol's core principles, responding to practical implementation feedback and evolving network requirements without altering its foundational optimizations.

Fundamentals of OLSR

Link-state routing is a class of routing protocols in which each node in the network independently calculates the best paths to all other nodes by maintaining a complete map of the network topology. In this approach, nodes flood information about their local links—such as connectivity and costs—to all other nodes, enabling each to construct an identical representation of the entire network graph. This global view allows for the computation of shortest paths using graph algorithms, contrasting with protocols that rely on partial, neighbor-only information. The key steps in link-state routing include link discovery, where nodes detect and advertise their direct connections; topology dissemination, involving the flooding of link-state updates to propagate this information network-wide; and route , where each node uses the aggregated to determine optimal paths. Link discovery typically occurs through periodic hello messages or event-triggered probes to identify neighbors and link states. During dissemination, updates are reliably flooded to ensure synchronization, often using sequence numbers to detect duplicates and acknowledgments for reliability. Finally, route calculation employs a shortest-path on the graph to populate forwarding tables. A cornerstone of link-state route calculation is Dijkstra's shortest path first (SPF) algorithm, which computes the minimum-cost paths from a source node to all others in a weighted graph with non-negative edge weights. The algorithm maintains a of tentative distances and iteratively selects the node with the smallest known distance, relaxing its outgoing edges to update neighbors' distances if shorter paths are found. This process continues until all nodes are processed, yielding the rooted at the source. To illustrate, consider the following high-level pseudocode for Dijkstra's algorithm, assuming a graph represented as an adjacency list where dist[v] tracks the shortest distance to vertex v, prev[v] records predecessors, and a priority queue orders nodes by current distance:

Initialize dist[source] = 0, dist[others] = infinity Initialize prev[all] = undefined Create priority queue Q, insert all nodes with their dist values While Q is not empty: u = extract min from Q (node with smallest dist[u]) If dist[u] == infinity, break For each neighbor v of u: alt = dist[u] + weight(u, v) If alt < dist[v]: dist[v] = alt prev[v] = u Update priority key of v in Q to alt

Initialize dist[source] = 0, dist[others] = infinity Initialize prev[all] = undefined Create priority queue Q, insert all nodes with their dist values While Q is not empty: u = extract min from Q (node with smallest dist[u]) If dist[u] == infinity, break For each neighbor v of u: alt = dist[u] + weight(u, v) If alt < dist[v]: dist[v] = alt prev[v] = u Update priority key of v in Q to alt

This implementation achieves a time complexity of O((V+E)log⁡V)O((V + E) \log V), where VV is the number of nodes (vertices) and EE is the number of edges, using a for the . Compared to distance-vector routing protocols like the (), which propagate distance estimates hop-by-hop and can suffer from slow convergence due to issues like count-to-infinity, link-state protocols offer faster convergence by leveraging complete knowledge for immediate recomputation upon changes. However, this comes at the cost of higher overhead from flooding link-state updates, which scales with network size and requires more bandwidth and processing than the periodic vector exchanges in distance-vector methods. OLSR builds on these principles by optimizing the flooding process through multipoint relays to reduce overhead in mobile ad-hoc networks.

Application in Mobile Ad-hoc Networks

Mobile Ad-hoc Networks (MANETs) are characterized by their decentralized architecture, where nodes operate without fixed infrastructure, relying on communication in a multi-hop fashion. These networks exhibit dynamic topologies due to node mobility, which causes frequent changes in connectivity, alongside constraints such as limited bandwidth from links and power limitations from battery-operated devices. Routing in MANETs faces significant challenges stemming from these traits, including rapid link failures and formations that demand constant topology updates. Traditional flooding mechanisms can lead to broadcast storms, overwhelming the scarce bandwidth with redundant control messages, while scalability issues arise in dense networks where the volume of routing information grows exponentially. Proactive routing protocols, such as OLSR, are particularly well-suited to MANETs because they maintain pre-computed routes through periodic exchanges, ensuring low-latency path availability for real-time applications like or emergency communications. This approach avoids the delays of on-demand route discovery, which can be prohibitive in highly mobile environments requiring immediate data transmission. OLSR addresses MANET challenges by optimizing link-state dissemination to provide partial views, enabling efficient handling of mobility without the overhead of full network floods. Through techniques like multipoint relays, it minimizes message retransmissions, conserving bandwidth and power while adapting to changes in decentralized settings.

Core Mechanisms

Neighbor Sensing and Discovery

In the Optimized Link State Routing Protocol (OLSR), neighbor sensing and discovery form the foundational mechanism for nodes to detect and maintain awareness of their immediate vicinity in mobile ad-hoc networks. Nodes periodically broadcast Hello messages on each interface to announce their presence and gather information about one-hop neighbors, which are nodes directly reachable via a wireless link. These broadcasts occur at fixed intervals defined by the HELLO_INTERVAL parameter, with a default value of 2 seconds, ensuring timely updates while minimizing overhead. Through these messages, nodes also learn about two-hop neighbors by receiving lists of neighboring nodes from their one-hop peers, enabling a localized view of without full global flooding. OLSR classifies detected links and neighbors into distinct types to reflect the quality and directionality of connectivity. A symmetric link exists when two nodes can hear each other's transmissions, confirming bidirectional communication, whereas an asymmetric link indicates a unidirectional connection where one node detects the other but not vice versa. Neighbors are further categorized based on link type and , including symmetric neighbors (fully bidirectional), asymmetric neighbors (one-way detection), and MPR neighbors (designated for efficient relaying). Each node advertises its willingness to serve in like MPR selection using a scale from 0 to 7, where 0 (WILL_NEVER) indicates refusal to forward messages, 7 (WILL_ALWAYS) signals maximum availability, and the default value of 3 (WILL_DEFAULT) represents standard participation. Maintenance of the two-hop neighborhood relies on continuous updates from Hello messages, where each node tracks the neighbors of its one-hop neighbors to build a partial map. This information includes the identities and link statuses of two-hop nodes, stored with a validity derived from the message's Vtime field, typically set to three times the HELLO_INTERVAL to account for potential delays. Accurate two-hop knowledge supports subsequent optimizations by providing data on potential relay paths, while discarding outdated entries prevents stale information from propagating. To enhance reliability, OLSR incorporates hysteresis thresholds in link quality sensing, which prevent frequent status fluctuations due to transient signal variations. A link is promoted to symmetric only if the received signal quality exceeds the high threshold (default 0.8), and demoted if it falls below the low threshold (default 0.3), introducing a buffer against and mobility-induced changes. This mechanism, applied during Hello message processing, ensures stable neighbor detection in dynamic environments.

Multipoint Relay Selection

The Multipoint Relay (MPR) mechanism in the Optimized Link State Routing Protocol (OLSR) serves as a core optimization for efficient flooding of control messages in mobile ad-hoc networks. An MPR is defined as a of a node's symmetric one-hop neighbors selected to retransmit all broadcast messages received from that node, provided the messages are not duplicates and have a time-to-live greater than one. This selection ensures that every strict two-hop symmetric neighbor of the node is covered—meaning it receives the message either directly as an MPR or through another MPR—while minimizing redundancy and the number of selected relays. The MPR selection algorithm employs a greedy to compute this minimal covering set locally at each node, based on from neighbor sensing that identifies symmetric one-hop and two-hop neighbors. Each node assigns a willingness value (ranging from 0 to 7, where 0 is WILL_NEVER and 7 is WILL_ALWAYS, with the default being 3 or WILL_DEFAULT) to indicate its preference for acting as an MPR; higher values prioritize selection in ties. The algorithm proceeds as follows for each interface:
  1. Include all symmetric one-hop neighbors with willingness WILL_ALWAYS in the MPR set.
  2. Compute the degree D(y)D(y) for each symmetric one-hop neighbor yy, defined as the number of symmetric neighbors of node y, excluding all members of N (the one-hop neighbors) and the node performing the computation.
  3. Add to the MPR set any symmetric one-hop neighbor yy that provides the only path to at least one strict two-hop neighbor; remove those covered two-hop neighbors from consideration.
  4. While uncovered strict two-hop neighbors remain:
    • For each symmetric one-hop neighbor yy not yet in the MPR set, compute its reachability NwN_w as the number of uncovered strict two-hop neighbors it can reach.
    • Select the yy with the highest willingness that maximizes NwN_w; break ties by choosing the one with the highest D(y)D(y).
    • Add the selected yy to the MPR set and remove the newly covered two-hop neighbors.
  5. Union the MPR sets across all interfaces of the node.
  6. If any MPR has willingness less than WILL_ALWAYS, attempt to remove it and recompute to check if coverage is maintained without it.
This process, detailed in pseudocode form below for clarity, ensures complete coverage with typically few MPRs (often 2–3 in average topologies):

MPR_set = empty N2 = set of strict 2-hop symmetric neighbors (excluding self, symmetric 1-hop, WILL_NEVER nodes) for each symmetric 1-hop neighbor y: if willingness(y) == WILL_ALWAYS: add y to MPR_set remove from N2 all 2-hop neighbors covered by y for each symmetric 1-hop neighbor y: if y is the only neighbor reaching some z in N2: add y to MPR_set remove from N2 all 2-hop neighbors covered by y while N2 is not empty: for each symmetric 1-hop neighbor y not in MPR_set: compute N_w(y) = number of nodes in N2 reachable via y compute D(y) = degree excluding N and self select y with max willingness, then max N_w(y), then max D(y) add y to MPR_set remove from N2 all 2-hop neighbors covered by y // Optional optimization: remove non-essential MPRs with willingness < WILL_ALWAYS for each y in MPR_set where willingness(y) < WILL_ALWAYS: temporarily remove y if N2 coverage remains complete after recompute: keep removed else: restore y

MPR_set = empty N2 = set of strict 2-hop symmetric neighbors (excluding self, symmetric 1-hop, WILL_NEVER nodes) for each symmetric 1-hop neighbor y: if willingness(y) == WILL_ALWAYS: add y to MPR_set remove from N2 all 2-hop neighbors covered by y for each symmetric 1-hop neighbor y: if y is the only neighbor reaching some z in N2: add y to MPR_set remove from N2 all 2-hop neighbors covered by y while N2 is not empty: for each symmetric 1-hop neighbor y not in MPR_set: compute N_w(y) = number of nodes in N2 reachable via y compute D(y) = degree excluding N and self select y with max willingness, then max N_w(y), then max D(y) add y to MPR_set remove from N2 all 2-hop neighbors covered by y // Optional optimization: remove non-essential MPRs with willingness < WILL_ALWAYS for each y in MPR_set where willingness(y) < WILL_ALWAYS: temporarily remove y if N2 coverage remains complete after recompute: keep removed else: restore y

The algorithm's greedy nature guarantees coverage but does not always yield the absolute minimum set, as finding the optimal is NP-complete; however, it performs well in practice. By restricting retransmissions to MPRs only, this mechanism substantially reduces control traffic overhead compared to classical flooding protocols, where every node might retransmit messages. In dense networks with NN nodes, naive flooding can result in O(N2)O(N^2) total message transmissions due to high connectivity and redundancy, whereas OLSR's MPR-based flooding approximates O(N)O(N) transmissions per broadcast by forming an efficient . Simulations indicate reductions by several orders of magnitude in message count, enhancing for large networks while maintaining .

Topology Management

Topology Control Process

In the Optimized Link State Routing Protocol (OLSR), the topology control process ensures the dissemination of essential network topology information across all nodes while minimizing overhead through the use of multipoint relays (MPRs). Nodes selected as multipoint relays (MPRs) by their neighbors originate Topology Control (TC) messages to advertise their connectivity to these neighbors (the MPR selectors). These messages are generated periodically at intervals defined by the TC_INTERVAL parameter, which defaults to 5 seconds, allowing nodes to maintain an up-to-date partial view of the network topology without the need for complete link-state flooding. By focusing solely on the MPR selector sets, TC messages provide a partial topology representation, where each node learns the advertised neighbors of distant nodes rather than the full set of links, significantly reducing message size and transmission frequency compared to traditional link-state protocols. The flooding of TC messages is optimized by leveraging the MPR mechanism, where only MPR nodes retransmit the messages to cover the two-hop neighborhood efficiently, preventing unnecessary broadcasts. This process employs the default forwarding algorithm, which relies on multipoint relays (MPRs) to forward packets, ensuring reliable propagation across the network while limiting redundancy. To further enhance efficiency, OLSR implements duplicate set detection, maintaining a per-originator duplicate set that tracks recently received TC messages based on their originator address and sequence number. If a duplicate is detected—through the message sequence number—the message is discarded, avoiding retransmissions and conserving bandwidth. The Advertised Neighbor Sequence Number (ANSN), which increments whenever changes occur in the advertised neighbor set, helps determine if the topology information is newer. This controlled dissemination results in each node constructing a partial graph sufficient for decisions, as the MPR-based advertisements provide connectivity information up to multiple away. The TC message format, which includes fields for the originator, ANSN, and the list of advertised neighbors, supports this process by enabling precise updates and validations. Overall, the topology control process balances accuracy and efficiency, making OLSR suitable for dynamic mobile ad-hoc networks where full topology broadcasts would be prohibitive.

Routing Table Computation

In the Optimized Link State Routing Protocol (OLSR), nodes compute their routing tables using partial topology information gathered from Topology Control (TC) messages, which are stored in the node's Topology Set. This set contains tuples representing reachable destinations, their last-hop addresses (typically Multipoint Relays or MPRs), sequence numbers, and timestamps, forming a directed graph that captures only essential links for routing without full link-state flooding. The core of the computation involves applying Dijkstra's shortest path algorithm to a partial graph constructed from the node's local link and the Set, where vertices represent network nodes and directed edges include local one-hop links and paths advertised via multipoint relays (MPRs) in the Set. The algorithm calculates the minimum hop-count paths from the local node to all destinations, treating MPRs as intermediate hops to ensure efficient, loop-free routes that leverage the protocol's optimization for reduced overhead. This approach yields hop-by-hop forwarding decisions optimized for mobile ad-hoc networks, with the graph's partial nature minimizing compared to full link-state protocols. Routing table entries are populated with the results of this calculation, including the destination address (R_dest_addr), the next-hop address (R_next_addr, often a direct neighbor or MPR), the hop distance (R_dist), and the local interface address (R_iface_addr) for outgoing packets. Each entry corresponds to a known destination from the , enabling precise while supporting dynamic topology changes. Updates to the are triggered by changes in the node's local information bases, such as the receipt of new TC messages updating the Topology Set, or modifications to the Link Set, Neighbor Set, Two-hop Neighbor Set, or Multiple Interface Declaration (MID) associations. To enhance efficiency, implementations may perform incremental recomputations rather than full recalculations, only re-running Dijkstra's on affected subgraphs when partial updates occur. For nodes with multiple radio interfaces, the computation incorporates MID messages to map secondary interface addresses to the node's main , ensuring entries specify the correct local interface (R_iface_addr) for transmission. This per-interface handling allows OLSR to support diverse hardware configurations, maintaining accurate path selections across the network.

Message Formats and Exchange

Hello Messages

Hello messages in the Optimized Link State Routing Protocol (OLSR) are periodic broadcasts used to detect and maintain information about local links and neighbors within a node's one-hop range. These messages enable nodes to sense bidirectional or unidirectional links and contribute to the broader process of neighbor discovery by advertising local connectivity details. The structure of a Hello message consists of the standard OLSR common header followed by Hello-specific fields. The common header includes a message type field set to 1 (indicating HELLO_MESSAGE), a Vtime field (1 byte) specifying the message's validity duration in a scaled format (calculated as C * (1 + a/16) * 2^b seconds, where C=0.0625 seconds, a is the 4-bit mantissa, and b is the 4-bit exponent), a message size field (2 bytes) denoting the length from the message type to the end of the message or the next message type, the originator address (4 bytes for IPv4, representing the sender's main interface address), a time-to-live field set to 1 (1 byte), a hop count initialized to 0 (1 byte), and a message sequence number (2 bytes) that increments for each new message from the originator to detect duplicates. The Hello-specific portion begins with a reserved field (2 bytes, set to 0), followed by the Htime field (1 byte) indicating the interval between Hello emissions in a similar scaled format, and the willingness field (1 byte) expressing the sender's readiness to forward traffic on a scale from 0 (WILL_NEVER) to 7 (WILL_ALWAYS), with a default of 3 (WILL_DEFAULT). This is succeeded by one or more link messages, each comprising a link code field (1 byte), a reserved byte (set to 0), a link message size field (2 bytes) for the length of that link message, and a variable number of neighbor interface addresses (4 bytes each for IPv4). The link code field (8 bits) encodes critical link attributes: the high-order 2 bits represent the link type—0 for unspecified (UNSPEC_LINK), 1 for asymmetric (ASYM_LINK), 2 for symmetric (SYM_LINK), or 3 for lost (LOST_LINK)—while the low-order 2 bits indicate the neighbor type—0 for not a neighbor (NOT_NEIGH), 1 for symmetric neighbor (SYM_NEIGH), or 2 for multipoint relay neighbor (MPR_NEIGH), with value 3 reserved for neighbor type. Each link message lists the addresses of interfaces detected on the corresponding link, allowing the receiver to update its local link information base. Although OLSR version 1 (defined in RFC 3626) uses 4-byte IPv4 addresses, extensions in subsequent implementations support IPv6 by replacing these with 16-byte addresses while preserving the overall format. Hello messages are transmitted periodically at intervals defined by the Htime field, typically every 2 seconds by default, and are broadcast on the interface from which they are sent to reach all potential one-hop neighbors; however, for asymmetric links, they may be sent via to the specific neighbor interface to confirm directionality. The validity time of link and neighbor information derived from a Hello message is set to the value indicated by Vtime, defaulting to three times the Hello interval (e.g., 6 seconds if HELLO_INTERVAL is 2 seconds), after which the information expires unless refreshed. For illustration, a basic Hello message with one symmetric link to a single neighbor might appear in byte layout as follows (assuming IPv4 and default values; actual sizes vary with multiple links):

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Length | Packet Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Vtime | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL | Hop Count | Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Reserved](/page/Reserved) | Htime | Willingness | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Code |[Reserved](/page/Reserved)| Link Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Length | Packet Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Vtime | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL | Hop Count | Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Reserved](/page/Reserved) | Htime | Willingness | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Code |[Reserved](/page/Reserved)| Link Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This layout shows the common header (top) followed by the Hello body (bottom), with the link code set to 129 (binary 10000001 for SYM_LINK and SYM_NEIGH) and the neighbor address filled accordingly.

Topology Control Messages

Topology Control (TC) messages in the Optimized Link State Routing Protocol (OLSR) are periodic broadcasts that disseminate topological information beyond the local neighborhood, enabling nodes to maintain a global view of the network structure. These messages are generated exclusively by nodes selected as multipoint relays (MPRs) and contain details about the MPR selectors of the originator, allowing recipients to update their topology information. By restricting propagation to MPRs, TC messages reduce control overhead compared to flooding all link-state updates. The structure of a TC message begins with a common header shared by all OLSR control messages, followed by TC-specific fields. The common header includes the Message Type field set to 2 (indicating TC_MESSAGE), the Vtime field set to TOP_HOLD_TIME (defining the validity duration of the advertised information, typically 15 seconds (3 * default TC_INTERVAL of 5 seconds) scaled by C (validity time factor)), the Message Size (total bytes of the message), the Originator Address (the main IP address of the sending node), Time To Live (initialized to 255 and decremented by 1 at each hop), Hop Count (starting at 0), and the Message Sequence Number (a unique incrementing identifier for the message from the originator). Following the header, the TC-specific portion consists of the Advertised Neighbor Sequence Number (ANSN), a 16-bit unsigned integer, and a variable number of Advertised Neighbor Main Address fields, each a 32-bit IPv4 address (or 128-bit IPv6 address in extended variants) representing the main addresses of nodes that have selected the originator as an MPR. If the list of advertised neighbors exceeds the maximum message size, multiple TC messages are generated to cover all entries. The ANSN field serves a critical role in ensuring the freshness of information. It is incremented by 1 ( 65536) each time the originator's set of MPR selectors changes, such as when a node adds or removes the originator from its MPR selector set due to link status updates or neighbor changes. Upon receiving a TC , a node compares the incoming ANSN with its locally stored value for the originator; if the new ANSN is greater, the node accepts the as valid and updates its , discarding it otherwise to avoid processing stale data. This mechanism prevents the propagation of outdated views that could lead to inconsistencies. Propagation of TC messages follows OLSR's optimized flooding rules to minimize redundancy. Only nodes designated as MPRs by their neighbors are responsible for forwarding TC messages; non-MPR nodes discard them after processing. When an MPR receives a TC message, it checks if the message has been seen before by examining the originator's sequence number and ; if novel, it sets the DUPLICATE_SET for the message's to prevent further retransmissions from other interfaces and then rebroadcasts it with the hop count incremented. This MPR-based relaying ensures that each TC message traverses the network via a minimal set of paths, typically reaching all nodes with O(N) overhead in a network of N nodes. Extensions to the base TC message format in OLSR version 1 accommodate evolving network requirements. For support, addresses in the header and advertised neighbor fields are expanded to 128 bits, with packet and message sizes adjusted accordingly to fit MTU constraints, while maintaining compatibility through optional IPv6 message types. Additionally, to handle multiple topologies or interfaces, the protocol introduces the TC_REDUNDANCY parameter (default 0), which controls the inclusion of extra neighbor addresses in TC messages for enhanced redundancy, allowing announcement of the MPR set (if 1) or full symmetric 1-hop neighborhood (if 2) in addition to MPR selectors. These messages contribute to the broader topology control process by providing the data needed for global route computations.

Multiple Interface Declaration (MID) Messages

MID messages (type 3) are used by nodes with multiple interfaces to declare all their interface addresses in the network, ensuring that other nodes can reach them via any interface. The format includes the common header (Vtime set for MID_HOLD_TIME, default 6 seconds; TTL=255) followed by a list of interface address blocks, each with a sequence number and variable IPv4 addresses. MID messages are generated periodically (default 5 seconds) by multi-interface nodes and flooded via MPRs, similar to TC messages.

Host and Network Association (HNA) Messages

HNA messages (type 4) allow nodes to announce connectivity to external networks or hosts, associating them with the node's main address for routing purposes. The structure features the common header (Vtime for HNA_HOLD_TIME, default 15 seconds; TTL=255) followed by address blocks, each containing a network address, mask (for IPv4), and validity time. These are originated by gateway nodes and propagated via MPR flooding to inform the network of external routes. In OLSR version 2 (OLSRv2, RFC 7181), message formats and exchange mechanisms are significantly updated to use the generalized packet and message format from RFC 5444, providing greater flexibility for TLVs (Type-Length-Value) and modularity. HELLO functions are replaced by NHDP messages, while TC is generalized with metric support and separate flooding/routing topologies, reducing redundancy and enabling natively without address size adjustments.

Optimizations and Performance

Key Optimizations

OLSR employs message bundling to enhance efficiency by packing multiple control messages, such as HELLO and topology control (TC) messages, into a single IP packet, thereby reducing the overhead from repeated IP and UDP headers and allowing utilization up to the (MTU) size. This technique minimizes the number of transmissions while maintaining the protocol's extensibility for different message types. To mitigate frequent link state changes due to transient signal fluctuations in environments, OLSR incorporates link in neighbor sensing, where a link is considered "up" only if the estimated quality exceeds a high threshold (e.g., 0.7) and "down" if it falls below a low threshold (e.g., 0.5), preventing unnecessary updates and . These thresholds, adjustable via parameters like HYST_THRESHOLD_HIGH and HYST_THRESHOLD_LOW, are scaled by a factor (default 0.5) to balance responsiveness and stability. Forwarding of control messages in OLSR includes delayed transmission with random jitter in the range [0, MAXJITTER] (default 0.1 seconds) to desynchronize node transmissions, aggregate duplicate messages, and reduce the likelihood of collisions in dense networks. This jitter is applied before emitting periodic messages, ensuring the actual interval varies slightly from the nominal value without significantly impacting convergence. OLSR's control overhead scales favorably with network size through techniques like multipoint relay reduction, highlighting its improved over classical link-state protocols.

Benefits and Advantages

OLSR significantly reduces control overhead compared to traditional link-state protocols by employing multipoint relays (MPRs) to limit the flooding of topology control messages, avoiding redundant retransmissions across the network. The proactive maintenance of routing tables in OLSR enables fast convergence, with the MPR-based mechanism reducing in message flooding and providing immediately available routes without on-demand discovery delays. This characteristic makes OLSR particularly advantageous for time-sensitive applications like VoIP and video streaming in mobile ad hoc networks (MANETs), where low latency and stable connectivity are critical. Furthermore, OLSR inherently supports loop-free via its shortest-path on a derived from complete information, ensuring reliable path selection without cycles. In comparative evaluations, OLSR demonstrates efficiency advantages over reactive protocols like AODV in resource-constrained settings, particularly in terms of bandwidth usage.

Limitations and Enhancements

Criticisms and Challenges

The Optimized Link State Routing Protocol (OLSR) version 1 lacks built-in mechanisms, relying on implicit trust among nodes without verifying message origins or . This vulnerability exposes the protocol to spoofing attacks, where malicious nodes can fabricate or impersonate HELLO messages to falsely advertise links and gain selection as multipoint relays (MPRs), thereby redirecting or disrupting symmetric links. Furthermore, OLSR is susceptible to attacks, in which adversaries tunnel HELLO and topology control (TC) messages between distant network regions to create artificial shortcuts, misleading legitimate nodes about and compromising routing decisions. Blackhole attacks also pose a significant , as malicious nodes advertise false shortest paths via spoofed HELLO messages to attract , only to drop packets and degrade network performance. Scalability limitations in OLSR arise from its proactive nature, where control message overhead increases substantially with network density, as higher node counts lead to more frequent HELLO and TC exchanges that saturate bandwidth. In large-scale topologies, the protocol's flat routing structure can result in excessive control traffic, hindering efficient topology discovery without hierarchical adaptations. Highly mobile environments exacerbate these issues, as rapid topology changes trigger excessive control traffic updates, reducing overall efficiency without hierarchical adaptations. Power consumption represents another challenge for OLSR, particularly in battery-constrained sensor networks, where the frequent periodic transmission of HELLO and TC messages leads to significant energy drain on nodes. This overhead is amplified in dynamic scenarios, as constant neighborhood sensing and topology dissemination prevent nodes from entering low-power states, shortening operational lifespan. Empirical simulations highlight performance degradation in OLSR under high-mobility conditions, with increased end-to-end latency observed due to delayed route recovery following link partitions or topology shifts. These issues underscore the protocol's challenges in maintaining low-latency routing amid frequent disruptions. Later versions, such as OLSRv2, introduce mitigations for some of these vulnerabilities.

OLSR Version 2 Updates

The Optimized Link State Routing Protocol version 2 (OLSRv2) was standardized in RFC 7181 as a Proposed Standard in April 2014, marking a significant evolution from version 1 by adopting a based on the Generalized MANET Packet/Message Format defined in RFC 5444 and Type-Length-Value (TLV) extensions from RFC 5497. This approach replaces the single-message structure of OLSRv1 with extensible, separate message types, enabling greater flexibility and easier integration of new features without overhauling the core protocol. OLSRv2 maintains the fundamental principles of multipoint relay (MPR) selection and partial link-state dissemination while enhancing adaptability for diverse network environments, such as mobile ad hoc networks (MANETs). Key changes in OLSRv2 include the introduction of distinct message types for specific functions, such as Link Sensing messages (replacing HELLO) for neighbor discovery and for efficient advertisement, which support native and multiple interfaces per router through integration with the MANET Neighborhood Discovery Protocol in RFC 6130. These modifications allow routers to handle complex topologies more effectively, with Link Sensing messages carrying TLVs for link quality indicators and aggregating multiple IP addresses into compact formats to reduce overhead. Additionally, OLSRv2 natively supports multiple interfaces, enabling routers to operate across diverse link layers without protocol modifications. Enhancements in OLSRv2 address security and performance needs by incorporating hooks for and other cryptographic mechanisms, including Integrity Check Values (ICVs) for message authentication and optional via external security protocols, as outlined in Section 23 of RFC 7181. It also improves handling of dynamic link metrics, such as the Expected Transmission (ETX), through dedicated LINK_METRIC TLVs that allow routers to select paths based on rather than hop alone, thereby optimizing in lossy or variable environments. These features provide a foundation for advanced optimizations while preserving low computational overhead. OLSRv2 is not directly interoperable with OLSRv1 due to fundamental differences in message formats and processing, and RFC 7181 does not obsolete RFC 3626, leaving v1 available for legacy experimentation; migration strategies typically involve phased rollouts in segmented networks or parallel operation until full transition. This design choice addresses several criticisms of v1, such as limited extensibility and IPv4-only support, without requiring immediate upgrades in mixed environments. As of 2025, ongoing developments include the IETF draft for responsive use of OLSRv2, which aims to improve adaptability to rapid changes in network conditions, and proposed -aware variants tailored for flying networks (FANETs) that optimize MPR selection based on computing power and constraints.

Implementations and Comparisons

Software Implementations

One of the earliest implementations of the protocol was UM-OLSR, a user-mode extension designed for testing and simulation purposes within the NS-2 network simulator. This implementation complies with RFC 3626 and includes core OLSR functionalities such as multi-point relay selection, along with optional link-layer feedback support, making it suitable for configurable topology experiments in a simulated environment. The most widely adopted open-source implementation is OLSRd, a daemon developed by the OLSR.org project that runs on and embedded systems such as routers in mesh networks. OLSRd supports plugin extensions for advanced metrics, including fish-eye state reduction for scalable awareness and Expected Transmission Count (ETX) for link quality assessment, enabling optimizations in dynamic environments. It has been extensively deployed in community mesh networks like Freifunk, where it facilitates proactive routing over multiple interfaces in large-scale wireless setups. Another notable open-source variant is NRL-OLSR, developed by the U.S. Naval Research Laboratory using the Protolib toolkit for cross-platform compatibility across Windows, macOS, , and embedded devices. This implementation adheres to RFC 3626 and includes tools for network testing and visualization, supporting real-world evaluations of OLSR performance in mobile ad-hoc scenarios. For and , OLSR is integrated into discrete-event simulators like ns-3, where the built-in OLSR model allows researchers to evaluate protocol behavior under varied topologies, mobility patterns, and traffic loads without hardware dependencies. Similarly, extensions like UM-OLSR in NS-2 provide a foundation for comparative analyses, though ns-3's native support offers more modern for large-scale studies. Implementations of OLSR version 2 (OLSRv2) include the OLSR.org Network Framework (OONF), an open-source project extending the OLSRd to support RFC 7181 features such as link metrics and the generalized packet format from RFC 5444. OONF is designed for deployment in embedded systems and has been used in experimental MANET setups as of 2025.

Comparison with Alternative Protocols

OLSR, as a proactive , maintains complete information at all nodes through periodic exchanges, enabling immediate route availability and lower latency compared to reactive protocols like AODV and DSR, which rely on on-demand route discovery that can introduce delays during initial . This proactive nature results in faster convergence times for OLSR, typically under 1 second in stable , versus 2-5 seconds for AODV and DSR in route request floods. However, OLSR generates consistent control overhead from hello and control messages, often 10-20% of total traffic in moderate mobility scenarios, while reactive protocols exhibit lower average overhead (5-15%) but with bursts during discovery phases that can exceed 30% under high load. Simulations in networks of 50 nodes demonstrate these trade-offs, as shown in the following table of representative metrics from literature (for 50 nodes at 0 m/s and 10 m/s speeds, using NS-2 simulator).
MetricOLSR (0 m/s / 10 m/s)AODV (0 m/s / 10 m/s)DSR (0 m/s / 10 m/s)
End-to-End Delay (ms)44 / 3068 / 10254 / 41
Packet Delivery Ratio (%)93 / 7299 / 98100 / 95
Routing Overhead (% packets)~0 / ~0~0 / ~0~0 / ~0
These results highlight OLSR's advantage in delay-sensitive applications but potential in dynamic environments due to outdated . Compared to other proactive protocols like TBRPF and DSDV, OLSR's Multi-Point Relay (MPR) mechanism reduces message redundancy, but evaluations show TBRPF achieving lower control overhead than OLSR in dense due to its tree-based partial topology sharing. In evaluations using relay node set frameworks, TBRPF demonstrated superior in maintenance overhead for networks up to 100 nodes, though OLSR offered better in sparse graphs. Against DSDV, OLSR avoids the looping issues of distance-vector updates and supports larger networks with lower overhead through optimized flooding. In contrast to hybrid protocols such as ZRP, which combine proactive routing within local zones and reactive queries beyond, OLSR's fully proactive strategy excels in uniformly mobile networks where frequent global route updates are beneficial, yielding higher throughput in dense, connected scenarios. However, ZRP adapts better to partitioned networks by confining proactive overhead to zones, reducing overall message volume in fragmented topologies compared to OLSR's global broadcasts. This makes OLSR less suitable for highly variable connectivity, where ZRP's hybrid design mitigates unnecessary flooding. Studies evaluating OLSR against RPL in IoT contexts indicate OLSR's potential strengths in high-mobility environments, such as vehicular or drone networks, due to its link-state optimizations, while RPL's destination-oriented DAG structure is more energy-efficient for low-power, static IoT deployments with minimized repairs in lossy links. This highlights OLSR's suitability for dynamic but power-tolerant applications.

References

  1. https://datatracker.ietf.org/doc/rfc3626/
  2. https://datatracker.ietf.org/doc/rfc7181/
  3. https://www.rfc-editor.org/rfc/rfc3626.html
  4. https://www.epizeuxis.net/index.php/topics/olsr-optimized-link-state-routing/
  5. https://datatracker.ietf.org/doc/html/rfc2328
  6. https://dl.acm.org/doi/10.1145/800092.802981
  7. https://www.cs.yale.edu/homes/lans/readings/routing/dijkstra-routing-1959.pdf
  8. https://web.stanford.edu/class/archive/cs/cs161/cs161.1166/lectures/lecture12.pdf
  9. https://datatracker.ietf.org/doc/html/rfc1058
  10. https://www.rfc-editor.org/rfc/rfc2501.html
  11. https://www.ijeat.org/wp-content/uploads/papers/v6i4/D4927046417.pdf
  12. https://sites.cs.ucsb.edu/~ebelding/courses/284/papers/clausen_olsr.pdf
  13. https://datatracker.ietf.org/doc/html/rfc3626#section-18.2
  14. https://datatracker.ietf.org/doc/html/rfc3626#section-6
  15. https://datatracker.ietf.org/doc/html/rfc3626#section-4.3.1
  16. https://datatracker.ietf.org/doc/html/rfc3626#section-18.8
  17. https://datatracker.ietf.org/doc/html/rfc3626#section-8.2
  18. https://datatracker.ietf.org/doc/html/rfc3626#section-8.2.1
  19. https://datatracker.ietf.org/doc/html/rfc3626#section-14
  20. https://datatracker.ietf.org/doc/html/rfc3626#section-18.7
  21. https://datatracker.ietf.org/doc/html/rfc3626
  22. https://datatracker.ietf.org/doc/html/rfc3626#section-9.2
  23. https://datatracker.ietf.org/doc/html/rfc3626#section-9.3
  24. https://datatracker.ietf.org/doc/html/rfc3626#section-9.4
  25. https://datatracker.ietf.org/doc/html/rfc3626#section-3.4
  26. https://datatracker.ietf.org/doc/html/rfc3626#section-9.1
  27. https://datatracker.ietf.org/doc/html/rfc3626#section-10
  28. https://datatracker.ietf.org/doc/html/rfc3626#section-4.4
  29. https://datatracker.ietf.org/doc/html/rfc3626#section-8.5
  30. https://datatracker.ietf.org/doc/html/rfc3626#section-5
  31. https://datatracker.ietf.org/doc/html/rfc7181
  32. https://datatracker.ietf.org/doc/html/rfc3626#section-3.3
  33. https://datatracker.ietf.org/doc/html/rfc3626#section-3
  34. https://datatracker.ietf.org/doc/html/rfc3626#section-14.3
  35. https://datatracker.ietf.org/doc/html/rfc3626#section-3.5
  36. https://datatracker.ietf.org/doc/html/rfc3626#section-18.9
  37. https://ieeexplore.ieee.org/document/995315
  38. https://ieeexplore.ieee.org/document/9837613/
  39. https://www.noveltyjournals.com/upload/paper/Comparative%20Performance%20Analysis-303.pdf
  40. https://dl.ifip.org/index.html/db/conf/ifiptm/ifiptm2007/AdnaneJBM07.pdf
  41. https://link.springer.com/article/10.1007/BF02826773
  42. https://link.springer.com/article/10.1007/s11277-020-07881-3
  43. http://www.cs.ucl.ac.uk/fileadmin/UCL-CS/research/Research_Notes/Archive/rn_06_06.pdf
  44. https://inria.hal.science/hal-00654552/document
  45. https://www.mdpi.com/2227-9717/11/5/1419
  46. https://online-journals.org/index.php/i-jim/article/download/26663/10555/88813
  47. https://datatracker.ietf.org/doc/draft-dearlove-manet-olsrv2-responsive/
  48. https://dl.acm.org/doi/10.1145/3708657.3708671
  49. https://oa.upm.es/40790/8/PFC_MIGUEL_BAGHDAD_AJAOUD_BARRANTES.pdf
  50. https://koayyongcett.medium.com/installation-of-ns2-with-um-olsr-in-ubuntu-16-04-8cb0696b43fd
  51. https://sourceforge.net/projects/olsrd/
  52. https://github.com/OLSR/olsrd
  53. https://www.open-mesh.org/projects/open-mesh/wiki/The-olsr-story
  54. https://github.com/USNavalResearchLaboratory/nrlolsr
  55. https://www.nrl.navy.mil/Our-Work/Areas-of-Research/Information-Technology/NCS/OLSR/
  56. https://www.nsnam.org/docs/models/html/olsr.html
  57. https://ns3simulation.com/how-to-implement-olsr-protocol-in-ns3/
  58. https://github.com/OLSR/OONF
  59. https://www.researchgate.net/publication/326837665_Performance_Comparison_of_DSDV_OLSR_AODV_and_DSR_for_Mobile_Ad_hoc_Networks
  60. https://rucore.libraries.rutgers.edu/rutgers-lib/25413/PDF/1/play/
  61. https://www.researchgate.net/publication/338541644_Comparison_of_Two_Proactive_Protocols_OLSR_and_TBRPF_using_the_RNS_Relay_Node_Set_Framework
  62. https://www.ijert.org/research/performance-comparison-of-aodv-dsr-dsdv-and-olsr-manet-routing-protocols-IJERTV5IS100173.pdf
  63. https://ijret.org/volumes/2013v02/i08/IJRET20130208058.pdf
  64. http://www.ijlera.com/papers/v2-i9/7.201708455.pdf
Add your contribution
Related Hubs
User Avatar
No comments yet.