|
Fault Tolerant Re-Routing Middleware for TinyOS |
||
|
|
||
|
General Information This archive contains a system of TinyOS modules which can be used with your application to add fault tolerant re-routing to the network. The system will monitor radio transmissions and if it believes a transmission was unsuccessful it will re-route the packet through another node automatically. The system will learn as time goes on which nodes are good routing partners for other nodes and make its selections accordingly. It is able to deal with both momentary failures and permanent failures of nodes in the network. The system does not require any ACK packets to be sent by the MAC layer, but will send its own ACKs from the base station (node 0) to nodes that are within one hop of the base station. It has been tested with TinyOS Version 1.1.15 and 1.1.11 using the /Route/ and /MINT/ routers. The software takes on a Middleware approach by making it quicker and easier to get a TinyOS application in addition to its fault tolerant properties. Included Files Modules: |
||
|
App.nc |
This is an example application that has been provided to demonstrate how the software works. It simply has each node a sample on its sensor port once a minute and forward it through the network to the base station which reports what value it heard from each node. |
|
|
rerouting.nc |
This module contains the rerouting functionality. It is here that messages are saved to a queue until the node is assured that the message is continuing through the network towards the base station. Messages in the queue will be re-routed after a certain time interval up to a set number of times. |
|
|
Control.nc |
This module acts as the go between for the rerouting module with the radio stack and router. The rerouting module does not directly communicate with the radio stack, it must go through the control module which will ensure that the radio is available. The control module is also responsible for passing data to the rerouting module as necessary, this includes incoming messages on both the INTERCEPT (node is the intended recipient) and SNOOP (node is not the intended recipient but hears the message anyway) ports. It is through this SNOOP port that we are able to request that nodes who are not the established parent in the routing tree re-route messages for other nodes. |
|
|
Interfaces: |
||
|
reroutingINT.nc |
This is the interface that is used by the Application in order to send messages using the rerouting software. This interface should be used by your application to send and receive messages. |
|
|
InputOutput.nc |
This is the interface between the rerouting module and the control module. It should not be used by your application. It contains a number of methods for the Control module and rerouting module to pass data back and fourth. |
|
|
From these interfaces we see that in this setup ALL lower level communication (radio stack, router) is done through the Control module. Neither the rerouting module or application communicate directly with the lower layers. Furthermore the application does not directly communicate with the Control module as everything passes through the rerouting module. This can be though of as a simple 4 layered approach. The top layer is the application, below that is the rerouting module followed by the Control module. Finally the bottom layer includes the TinyOS radio stack and router. |
||
|
Wiring Files: |
||
|
wireRec.nc |
This wiring file handles connecting the modules which are involved in receiving data messages from the radio stack. |
|
|
wireSnd.nc |
This wiring file handles connecting the modules which are involved in sending data messages from the radio stack. |
|
|
middleware.nc |
This is the wiring file that connects the entire system together. It includes the "components" from wireRec and WireSnd in addition to the Control, rerouting and App modules. This is the only module that you should need to edit if you wish to connect further TinyOS interfaces to your Application. |
|
|
Message Format: |
||
|
FTMsg.h |
This is the header file specifying the message format that is used by the rerouting software modules. It allows each message to contain up to 18 bytes from the applcation. This is down from 21 bytes which would be available without the three byte overhead that is used by the rerouting software. It may be modified without breaking functionality so long as the three one byte fields "levlen", "origsrc", and "faultt" remain. |
|
|
Getting Started Using this software should be very straightforward provided that you have a working installation of the TinyOS 1.1.x tree from http://www.tinyos.net.
|
||
|
0 - |
Download the archive available here. |
|
|
1 - |
Extract this archive into the /tinyos-1.x/apps/$your_application_here$/ folder |
|
|
2 - |
Test that everything is working by building the included sample application: make <pc/mica2/...> |
|
|
2.1 - |
We suggest testing the application in TOSSIM or TinyVIZ to see how the application is working, this will require the "temp" debug option to be enabled: export DBG=temp |
|
|
3 - |
Develop your own application to replace the existing App.nc by either modifying or replacing the included App. You will need to modify only the middleware.nc wiring file in order to wire your new, probably more complex, application to the rerouting software. Be sure that your application USES the reroutingINT interface and sends and receives its messages using this interface. |
|
|
4 - |
Modify the retryThresh and Timer_Length parameters in the rerouting.nc file to suit your needs. Increasing the retryThresh gives a higher probability of the message making it through to node 0. Decreasing the Timer_Length parameter will decrease the latency from the originating node to node 0 but could result in wasted transmissions (and energy) due to timing out to quickly. |
|
|
Further Information For further information please contact: Michael Gregoire: mgregoir 'at' ecs 'dot' umass 'dot' edu Israel Koren: koren 'at' ecs 'dot' umass 'dot' edu
Links UMass Amherst - Department of Electrical and Computer Engineering
The Percom 2007 paper above has been copyrighted to the IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or propmotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE. |
||
