Tags:
create new tag
, view all tags
The network layer is capable of facilitating multi-hop communication through routing and congestion control. Essentially, it enables a form of end-to-end capability for wireless sensor networks. In order to achieve this, the network layer frame (payload) contains an (initial) source and (final) destination component which the network layer can match to its routing table to determine the next hop, if routing is enabled. In addition to this basic routing functionality, the network layer is the ideal container for congestion control and other more advanced routing algorithms. When running WiSeNeT, congestion control and routing can be enabled by parsing the --cc and --routing arguments respectively at the command line.

  • Figure 10: Network layer landscape:
    f10.png

There are two main threads in the network layer with clearly defined purposes (Figure 10):

  • 1. Network Send manages the downwards (outbound) traffic flow (from A2N_queue to N2L_queue).
  • 2. Network Receive manages the upwards (inbound) traffic flow (from L2N_queue to N2A_queue), and can re-route packets if routing is enabled (that is, put it back onto the N2L_queue).
If routing is enabled, then the network layer will read the corresponding node’s preset routing table, which can be created by the auxiliary Create RT function (see below). This is read into a dictionary variable, which effectively becomes the node’s dynamic routing table, and can be modified by other routing or congestion control algorithms. In its base implementation, routing under WiSeNeT is simply concerned with re-routing packets to the appropriate next hop. If routing is enabled but there is no corresponding routing table file available to read from, the network layer will switch off routing automatically. Unlike the link layer (which only passes the received packet upwards if rxnode is the node’s address), the network layer is primarily concerned with the packet TYPE. If the packet received is a TYPE_DATA packet, then if the destination is the node’s address (as opposed to rxnode), then pass it up to the link layer; otherwise, if routing is enabled, determine the next hop from the routing table (that is, find the next rxnode), and pass it back down to the link layer. If it is a TYPE_ROUTING packet, then if the destination is the node’s address, process the routing packet according to the routing or congestion control algorithms in place. One of the major differences between the existing testbed and WiSeNeT is that there is no longer a need to put the testbed in mesh mode or direct mode (which effectively adds or removes the network layer) – the network layer is now an integral part of the testbed, however by switching on or off routing or congestion control, the network layer’s role can be changed.

The novelty of modularity in WiSeNeT is best shown when testing congestion control or other routing algorithms in the network layer. Currently in SVN revision 170 of WiSeNeT, a sample implementation of the Lotka-Volterra Congestion Control algorithm has been implemented in the network layer as a means to check the operation of the testbed. Due to the requirements of LVCC, a number of extra functions have been built into the link layer to obtain the information required by the algorithm (such as the number of active children), without affecting the core functionality of the testbed. These functions can be accessed by the network layer through specific interfaces into those functions (shown in Figure 10 as interfacing to the congestion control function). In order to test and implement another algorithm, it is no longer necessary to recreate and remould the entire testbed to suit. A standard network layer template with just the base functions as well as sections of code set aside for these algorithms has been provided in the /templates/ folder – the new algorithm can therefore be programmed into a copy of this network layer template. As was done in the sample LVCC implementation and as suggested by the network layer template, it is recommended that congestion control or other routing algorithms be coded through a daemon thread. To implement it, it is as simple as swapping the existing network layer Python file with the new network layer file (Figure 11).

  • Figure 11: Network layer modularity:
    f11.png
Topic revision: r3 - 2012-01-20 - XiaohongWu
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback