Proactive routing protocols for wireless multi-hop networks

Proactive routing protocols take a totally different approach than reactive routing protocols, as they are based on periodic exchange of control messages. Some of these messages (which are similar to AODV “Hello” messages) are exchanged locally between network nodes to provide participating network nodes the information about their local neighbourhood. Beside these locally exchanged messages, there are types of messages that are sent to the entire network in order to exchange knowledge of network topology among the nodes in the network. By using this information, each and every node in the network can construct the topology of the whole network and have the optimized routing information to all the nodes in the network.

Since the routing information is already available whenever data packets need to be sent, there is no routing delay and no packet loss of buffer overrun due to this delay.

However, since the routing information is calculated beforehand, periodic topology

Chapter 2: Technical Backgrounds

25

updates cause additional overhead even when the routing information is not needed or when there is no data traffic for routing.

Among the available proactive routing protocols such as Destination-Sequenced Distance Vector routing (DSDV) [23], Optimized Link State Routing (OLSR) [24]-[25], the OLSR protocol is perhaps the most commonly used and widely mentioned in the literature.

Overview of Optimized Link State Routing (OLSR) routing protocol [24]-[25]

OLSR is an efficient proactive routing protocol for wireless multi-hop networks.

As its name suggests, OLSR uses the link-state scheme to diffuse and calculate routing information. However, instead of flooding the link-state information throughout the network, in order to preserve network bandwidth, OLSR-enable nodes elect a subset of their directly connected neighbours as their Multipoint Relays (MPR). By using these MPRs as their communication gateway for both routing information and data exchange to the rest of the network, OLSR greatly reduces the routing messaging overhead. OLSR MPR, neighbour sensing, MPR selection, MPR information declaration and routing table calculation will be discussed next to give an overview of OLSR protocol.

 OLSR Multipoint relays (MPR)

The motivation behind multipoint relays is to minimize the flooding broadcast of routing packets in the network by reducing the duplicate retransmissions in the same region. Each node selects its multipoint relays, i.e., the multipoint relay set, among its one hop neighbours so that the set of selected nodes covers all the nodes that are two hops away. These multipoint relays of a node 𝑁, called 𝑀𝑃𝑅(𝑁), are a subset of 𝑁’s bidirectional neighbours in which every node in the two hop neighbourhood of 𝑁 must have a bidirectional link towards 𝑀𝑃𝑅(𝑁).

Chapter 2: Technical Backgrounds

26

Routing packet propagation

a. Flooding a packet in a wireless multi-hop network without MPRs.

Routing packet propagation MPR

b. Flooding a packet in a wireless multi-hop network with MPRs (solid filled nodes).

Figure 2.5: Flooding a packet in a wireless multi-hop network with and without MPRs

Only nodes in 𝑀𝑃𝑅(𝑁) process and retransmit the routing information received from node 𝑁. Other neighbours of 𝑁 process the packet, but do not retransmit the packet.

Figure 2.5 illustrates the significant reduction of duplicated packets by using MPR when

Chapter 2: Technical Backgrounds

27

flooding the routing information in a wireless multi-hop scenario. OLSR-enable nodes also use these multipoint relays to calculate routes to other nodes in the network.

 Neighbour sensing

To discover bidirectional neighbours in the neighbourhood, each node periodically broadcasts its “Hello” messages. The TTL of these “Hello” messages is set to 1 so that they can be received by all one hop neighbour, but they are not retransmitted any further. A “Hello” message contains the list of addresses of all the bidirectional neighbours of the transmitted node and the list of addresses of the neighbours which are heard by this node (a Hello has been previously received) but the link is not yet bidirectional.

When receiving a “Hello” message from a neighbour, if a node finds its own address in the Hello message, it considers the link to the sender node as a bidirectional link.

Since the “Hello” message contains information about the one hop neighbours of a node, it allows each node to learn the knowledge of its neighbours of up to two hops.

Based on the exchange of “Hello” messages, each node maintains a neighbour table about its one hop neighbours and a list of two hop neighbours that these one hop neighbours give access to. Each of the one hop neighbours in the neighbour table is marked with a link status of either unidirectional, bidirectional or MPR (the selection of MPR will be discussed later). Each entry in the neighbour table also would be removed if its associated holding time expires.

 MPR selection

Each node in the network selects its own MPR set independently so that all the members of the MPR set cover the entire two hop neighbour set of the node. The MPR set does not need to be optimal, but it should be small enough for the benefit of the multipoint relays.

The MPR set is recalculated when a change in the neighbourhood is detected (either a bidirectional neighbour fails or a new bidirectional neighbour is added) or when there is a change in the two hop neighbour set (with a bidirectional link).

Chapter 2: Technical Backgrounds

28

After it is calculated, the MPR set information is also embedded into the “Hello”

messages so that the MPRs can receive this information as well. When a node receives a

“Hello” message with itself as a MPR, it adds the sending neighbour into its MPR selector table.

 MPR information declaration

In order to build the topology table, a “Topology Control” (TC) message is sent periodically by each node in the network to declare its MPR Selector set. The TC message contains the list of neighbours who have selected the sender node as a multipoint relay. The TC messages are forwarded as broadcast messages to the entire network. A node with an empty MPR selector set, i.e. no other node selects it as a multipoint relay, does not generate any TC message. A TC message could be sent earlier than the predefined interval if there is a change in its MPR Selector set during this duration.

Upon receiving these TC messages, each node in the network populates its topology table with the multipoint relays of other nodes obtained from the received TC messages. Each entry in the topology table also has a holding time after which the entry is removed.

Each entry in the topology table consists of a pair of addresses [last-hop, node]

where the node is the address of the MPR selector in the received TC message and last-hop is the originator of the TC message. This information in the topology table is then used to calculate the routing table at each node.

 Routing table calculation

The routing table is calculated independently at each node from its topology table and neighbour table and contains all the routing information for the node to reach other nodes in the network.

Since the entries in the topology table are in the form of pairs of [last-hop, node]

addresses, the routing table is constructed by tracking the connected pairs of nodes in the topology table. The tracking starts from the source node, through its neighbours (specified in the neighbour table) and spreading outwards to all the possible destination nodes in the network. In order to restrict to the optimal paths, the source node selects the

Chapter 2: Technical Backgrounds

29

connected pairs on the minimal path only. Each of the final route entries in the routing table consists of the destination address, next hop address, and the estimated distance to the destination.

Since the routing table is calculated based on the information contained in the neighbour and the topology tables, if there is any change in either of these tables, the routing table is recalculated to update the routing information. It is remarked that the recalculation of the routing table is the result of the changes in the neighbour table or the topology table, this recalculation does not generate any packet to be transmitted.