Finger2IPv6

Finger2IPv6 is included in the standard library of applications included with the tinyOS development git, on GitHub.

Background Information

Finger2 by Themistoklis Bourdenas was a policy programming engine built for tinyOS. Policy programming enables autonomic and customized behavior in wireless sensor networks (WSN). It augments basic subroutines with extensible control logic. In WSN based on the tinyOS platform, state introspection and debugging is challenging and opaque; instrumentation embedded in WSN application nesC code is required, and the process of collecting data is difficult.

To date, most WSN applications had been designed for one specific application, using programming designed to fulfill one limited role only. Policy programming enabled these same hardware devices’ programming to become more adaptable and more flexible in changing circumstances while maintaining overall system autonomy and availability.

Project Objective

The blip2.0 IPv6 network stack in tinyOS was integrated with the Finger2 policy engine and a UDP shell, allowing policy debugging to occur with real sensor hardware. This surmounted some of the major design shortfalls with TOSServ. It was also required to enable policy debugging and introspection to occur by logging onto actual motes and directly entering commands into their shell. Feedback was returned to the same terminal session in real time. Getting an edge router working to marshal interoperable traffic between the 802.15.4 6LoWPAN based sensor motes wireless radio and wired/wireless external IPv6 networks was an important prerequisite. The result was an interactive policy programming environment that works in real deployments.

Main Development Products

- Policy programming could now occur on real wireless sensor devices that supported the blip stack.

- The Policy IDE and Finger2 development was made compliant modern Internet standards by using IPv6 and 6LoWPAN, a major improvement over link-layer based communication previously used in older iterations (using the AMSend tinyOS radio interface).

- The usage of IPv6 enabled UDP protocols to be used, which allowed policy programming based wireless sensor networks to be interoperable with other networks, and desktop computing environments.

- Interactive policy programming directly on wireless sensor devices was now possible.

Architectural Overview

The core architecture of Finger2 was not modified in order to work with the new UDP shell. Rather, the commands that were invoked within of Finger2 (specifically the version used with Policy IDE) were architected to be invoked via the UDP shell provisions that came along with the blip network stack. IPv6 UDP packets reaching the sensor mote via 6LoWPAN were generated as a result of direct console interactions. This was done using the IPv6 version of NetCat (nc6). A local network interface on the desktop side was used to route packets through a wireless sensor mote that had been programmed as an edge router. This was included in the tinyOS sample applications library, called PPPRouter. This router, also running a UDP shell, provided the interface between IPv6 traffic on desktop networks, and the 6LoWPAN wireless sensor networks. The result was that all sensor nodes had IPv6 addresses, and seamless interoperability between the internet, desktop networks (via Network Address Translation), and wireless sensor networks was possible.

Conclusions and Future Work

Being able to perform policy programming directly on sensor motes interactively opens the field for much advancement in policy programming. This means that provided the capabilities of the devices to be programmed can be known, policies can be written for them and debugged directly in situ. A major advancement in this regard would be the creation of a policy programming discovery component, dubbed SupportDiscovery. This concept can be seen in the corresponding SupportDiscovery page. Primarily, where Finger2IPv6 falls short is the architecture used to get debug messages back to the UDP console. Because of the tinyOS ‘wiring’ architectural model, any components that have debugging messages that need to get back to the console must be wired into the UDP shell. This was done with limited parts of Finger2’s core components in order to get sufficient data back to the user to perform rudimentary debugging operations. Getting more of this data back to the shell would require more components to be wired in. This might increase the size of the binary; reduce performance, or any number of untested and unpredictable effects. Therefore, a major point of future work for Finger2IPv6 would be testing the existing architecture with more debug output, and performance benchmarking. Perhaps if the findings yield that this extra wiring causes code bloat or performance problems, the introduction of a more efficient architecture for moving debugging messages back into the console, may be necessary. Perhaps the current implementation is lightweight enough for this to work, however, and this should be thoroughly tested. The additional debug messages would allow the introspection and debugging capabilities to become more robust. Moreover, integrating Policy IDE with the new Finger2IPv6 would be an important short-term goal. By using the UDP communication facilities provided by Finger2IPv6 instead of the XML-based Remote Procedure Call architecture used by the TOSServ client, one could very easily connect the Policy IDE to work with real sensor devices, providing a useful graphical frontend for policy programming.