Deprecated: Non-static method Configure::read() should not be called statically, assuming $this from incompatible context in /var/www/mchannel/cake/libs/view/view.php on line 661

JOLSR

The base: OLSR

The Optimized Link State Routing Protocol (OLSR) is developed for mobile ad hoc networks. It operates as a table driven, proactive protocol, i.e., exchanges topology information with other nodes of the network regularly. Each node selects a set of its neighbor nodes as "multipoint relays" (MPR). In OLSR, only nodes, selected as such MPRs, are responsible for forwarding control traffic, intended for diffusion into the entire network. MPRs provide an efficient mechanism for flooding control traffic by reducing the number of transmissions required.

Nodes, selected as MPRs, also have a special responsibility when declaring link state information in the network. Indeed, the only requirement for OLSR to provide shortest path routes to all destinations is that MPR nodes declare link-state information for their MPR selectors. Additional available link-state information may be utilized, e.g., for redundancy.

Nodes which have been selected as multipoint relays by some neighbor node(s) announce this information periodically in their control messages. Thereby a node announces to the network, that it has reachability to the nodes which have selected it as an MPR. In route calculation, the MPRs are used to form the route from a given node to any destination in the network. Furthermore, the protocol uses the MPRs to facilitate efficient flooding of control messages in the network.

A node selects MPRs from among its one hop neighbors with "symmetric", i.e., bi-directional, linkages. Therefore, selecting the route through MPRs automatically avoids the problems associated with data packet transfer over uni-directional links (such as the problem of not getting link-layer acknowledgments for data packets at each hop, for link-layers employing this technique for unicast traffic).

OLSR is developed to work independently from other protocols. Likewise, OLSR makes no assumptions about the underlying link-layer.

OLSR inherits the concept of forwarding and relaying from HIPERLAN (a MAC layer protocol) which is standardized by ETSI. The protocol is developed in the IPANEMA project (part of the Euclid program) and in the PRIMA project (part of the RNRT program).

rfc3626

What is jOLSR?

jOLSR is an application level implementation of the OLSR routing protocol written in Java. Of course, the goal of jOLSR is not to be a fully compliant implementation of the standard, but an implementation which follows its basic functionalities. In any case, jOLSR implements nearly all components of the core functionality of OLSR. Although the core functionality also includes support for multiple interface addresses, this feature is not provided in the current version of jOLSR in order to simplify the implementation.

jOLSR stores network information in different tables similarly to OLSR specification: Neighborhood information base (NIB) stores neighbor information; Local Link Information Base (LLIB) keeps updated information about the state of links to the neighbors; Topology Information Base (TIB) maintains information of the network topology to perform routing calculation.

Some modifications have been added to the basic specification of OLSR to provide topology and group membership information to the upper multicast protocol. The multicast protocol,
Deprecated: Non-static method Router::url() should not be called statically, assuming $this from incompatible context in /var/www/mchannel/cake/libs/view/helper.php on line 178

Deprecated: Non-static method Router::getInstance() should not be called statically, assuming $this from incompatible context in /var/www/mchannel/cake/libs/router.php on line 752

Deprecated: Non-static method Inflector::underscore() should not be called statically, assuming $this from incompatible context in /var/www/mchannel/cake/libs/router.php on line 920
OMOLSR, will benefit from this information in order to avoid flooding the network with unnecessary control packets. The main changes are the following:

TC messages now include a list of multicast groups that are joined by the sending node.
A new table called Multicast Groups Table stores the information about multicast groups received in TC messages. With this information, a partial representation of the network, similar to a graph, is computed when a change is detected in the different tables.

TC Message Modification

Deprecated: Non-static method Configure::read() should not be called statically, assuming $this from incompatible context in /var/www/mchannel/cake/libs/view/helpers/html.php on line 438

OLSR and jOLSR send two different types of control messages, HELLO and TC (Topology Control) messages. HELLO messages permit a node to know its one-hop and two-hop neighbors, since each node sends information about its local neighborhood. Based on this information, the node can select its multipoint relays (MPR) which will be in charge of performing controlled flooding. TC Messages are sent to all the nodes in the network thanks to this controlled flooding mechanism, and disseminate topology information of the local node to all nodes in the network.

In both OLSR and jOLSR, TC messages are sent periodically from one node to the rest of the network, so all nodes can compute its topology table. We have realized that by adding little information in TC messages, we can disseminate information easily to all nodes in the network. This is in fact really useful since the multicast routing protocol needs information about the multicast groups joined by each node.

Therefore, we propose to attach the multicast address of the groups joined by the local node in TC messages, as we can see in the figure. The attached information about the groups is retrieved from the multicast group table.

Multicast Group Table

The Multicast Group Table keeps the information about the multicast groups joined by each node. This information is updated when the local node decides to join a new group or when it receives a new TC Message. The table keeps a set of the joined multicast groups for each node in the network. The information in this table is used by the upper multicast routing protocol and changes in the table are reported as membership events to the application. When a change is detected in the neighbor table, in the topology table or in the multicast groups table, a graph containing the members of the group is computed. The multicast protocol will receive a new event with the information of this graph.

In order to calculate the graph with the members of the group, we obtain an approximate representation of the network by creating a network graph from the information stored in the topology table. Then we check in the Multicast Group Table which nodes belong to which group, so we create an event for each different group in the table. The graph can then be used by the multicast protocol for retrieving updated membership information.