User Documentation

Overview

There are two main uses for RNS algorithm. It can be used as a support for routing protocols, allowing them to manage resources wisely. It can also be used with applications that have a specified area of appliance, limited by sensor’s range or optimal nodes scatter. Status of a node can be checked by running IsRedundant function.

RNS Installation

RNS class is a template class. Template argument should be adjusted to the identification type used by protocol or application. In ns-3 the most widely used identification type is Ip address, so normally the template argument should be Ipv4Address.

After deciding what the RNS algorithm identification type is, all that has to be done is aggregate RNS module to the node, using provided helper functions. Then a pointer to the aggregated module can be obtained by using GetObject function.

RNS Algorithm Trigger

RNS is a complicated and therefore resource-consuming algorithm. It should be run wisely no to waste node’s energy resources. Below all posibilities of the algorithm being run are shown. Please, pay attention to the fact, the position of the node is checked only on certain occasions and doesn’t always trigger the algorithm.

External Neighbor Update

Neighbors table can be updated by routing protocol or application using RNS. In such case several conditions are checked to make sure that it is necessary to trigger RNS algorithm. If any of the conditions below is matched, then the algorithm is NOT going to be run:

1. If the protocol or application updating the entry doesn’t provide position information (PositionInHeader attribute set to false).

2. If the node is redundant and the received update doesn’t concern any of its Related Redundant Nodes.

3. If update did not bring any changes to Neighbors table and node’s position hasn’t changed either.

RNS Header Update

If the node is not redundant or its position has changed, any update triggers RNS algorithm. Alternatively, if the node is redundant and the update concerns one of its Related Redundant Nodes, then the algorithm is trigerred as well.

Periodic Update

Whenever UpdateTimer expires after the amount of time specified by UpdateInterval attribute and if either position or range of the node has changed, then the algorithm is run. The RNS header will be broadcast unless protocol handles it (EventTriggerredBroadcast or ProtocolPeriodicUpdate set to true).

Range or Position Change

If SetR() function is called, while ConnectivityMaintenanceMode is turned off, the new range is compared with the previous one. If the range changes, then the RNS algorithm is run and in case it has changed an RNS Header is broadcasted.

Manual Trigger

This option is not recommended, but has been made accessible in case users decide that the functionality provided by RNS class is not sufficient.

The actual RNS algorithm can be run by calling the AmIRedundant function explicitly. The function returns true if the node has been found redundant or false otherwise. The return value has to be manually set in RNS module by using SetRedundant function.

Cooperation with routing protocol

RNS routing table can and should be updated by the routing protocol used by the node. Update can be performed using UpdateNeighbor function. This function takes as an argument a Neighbor object, which has to be created by the protocol.

Even if protocol provides only an ID of its neighbors or it doesn’t use UpdateNeighbor at all, RNS will use it to broadcast and forward its own headers and thus it will be able to obtain information necessary for its work.

Typically, if RNS is used as a support for Routing Protocol it will be run with ConnectivityMaintenanceMode enabled and the range will be automatically obtained from PropagationLossModel.

Supported Routing Protocols

Currently the only supported routing protocol is DSDV (Destination-Sequenced Distance Vector routing).

RNS Header Broadcast Control

RNS header is sent on the following occasions:

  • redundancy status has changed,
  • UpdateTimer has expired,
  • received header has to be forwarded to two-hops neighbors of the originating node.

There are two attributes that allow partially passing the control over sending RNS broadcast to the routing protocol:

  • EventTrigerredBroadcast will prevent RNS broadcast from being sent even if the node has changed its status.
  • ProtocolPeriodicUpdate will prevent RNS broadcast if node’s position, range or status haven’t changed even if UpdateTimer has expired.

Cooperation with Applications

Applications will probably not use ConnectivityMaintenanceMode and will provide RNS with its range by using SetR function.

If the range passed to the RNS module is similar or larger than node’s radio range connectivity difficulties should be expected.

Attributes summary

Test should be set to false unless test are being run without RNS module being aggregated to any real node.

ConnectivityMaintenanceMode should be set to true if the task of RNS module is to switch off the nodes which are not necessary for maintaining network’s connectivity. In this case node’s range is estimated automatically using the aggragated PropagationLossModel and Phy. Furthermore, the range is divided by two (see Redundancy vs Connectivity).

If RNS is being used with an application that provides its own range definition, then this attribute should be turned to false.

EventTriggerredBroadcast should be used if protocol is allowed to send messages only in some specified time windows. Using this option will prevent RNS from sending broadcasts and will rely on the protocol to do it.

This option should not be mixed with ProtocolPeriodicUpdate parameter, which is detected automatically, based on the recognized protocol type. This parameter will only prevent sending periodic broadcasts if no important data has changed. All broadcasts caused by status, position or range changes will still work.

UpdateInterval determines the frequency of automatic broadcast mesages sending. They are used in case of protocol not using any means of periodic updates that could be used to maintain up-to-date neighbors tables. Periodic broadcast can be skipped if EventTrigerredBroadcast attribute or ProtocolPeriodicUpdate parameter are set.

MaxEntryAge specifies the time after which an entry in neighbors table will be considered out-of-date. This mechanism protects RNS algorithm from taking dead nodes into consideration.

Note, that setting MaxEntryAge to a higher value than UpdateInterval is formally allowed but makes little sense.

UpdateIntervalTimeScatter can be used if collisions between nodes are expected in the channel. Periodic broadcast messages will be sent at a random moment from UpdateInterval - UpdateIntervalTimeScatter to UpdateInterval + UpdateIntervalTimeScatter.

If ConnectivityMaintenanceMode is used then RangeEstimationAccuracy attribute will determine the accuracy at which range of the node will be estimated.