Posted 2014-03-31, updated 2014-12-14
We've come a long way since the Great Duck Island paper introduced many people to low-power wireless sensor networking. The IETF has been standardizing the protocols required to operate these networks: 6LoWPAN, RPL, CoAP, and currently 6TiSCH for interoperability and efficiency. It's time to adapt standard management and monitoring interfaces to LLNs, too. These pages describe the development and use of free and open tools to support this effort.
There is considerable interest in use of CoAP for network configuration and monitoring since it already is used in LLN nodes for application-level communication. van der Stok, et al. have proposed use of CoAP in their CoAP Management Interface (COMI) draft, which is like a RESTCONF simplified for constrained devices. We assume that the eventual IETF solution is based on these works.
It looks like a rough concensus is developing, so how about some running code? Let's break down the problem into pieces, experiment with simple solutions, and see where it leads. The drawing below shows the hardware elements and communication links between them, as well as the highest-level components of RESTCONF.
We need to consider operating system support before choosing a device. There are two main choices: Contiki and OpenWSN. Contiki is more widely used, but OpenWSN is leading the effort to define 6TiSCH, which provides a promising future. We plan to start with OpenWSN because we are familiar with it, but certainly it would be interesting to try Contiki, too.
OpenMote and TelosB are supported by both operating systems. However, TelosB includes only 10K RAM and 48K ROM. It will be challenging to implement RESTCONF within these constraints. OpenMote is a Cortex-M3 device with 32K RAM and 512K ROM, and essentially makes the TelosB-class obsolete. OpenMote's XBee format makes hardware integration easier, too.
Each node is a RESTCONF server, and so must provide a configuration interface and storage, as well as push state notifications back to a client. Both OpenWSN and Contiki provide a CoAP implementation. The NETCONF Light draft may provide hints for a reasonable implementation.
There are many options for the border router, ranging from a laptop to a high end wireless mote like a RedBee Econotag. We plan to start with Linux-capable devices for simplicity -- first a laptop, and then step down to a compact, low-cost BeagleBone. Beyond these devices, it would be interesting to try something like the Freetronics EtherDue, an Arduino Due with Ethernet. Riot-OS supports the Due itself, but integration of Ethernet may require some work.
Since we plan to use OpenWSN on the mote, we will use OpenVisualizer on the Linux-based border router. However, it should be possible to pare down this implementation to provide support only for its HDLC-based serial communication. Such an implementation will be required for use on the EtherDue. Perhaps we can adapt Contiki's tunslip tool for this purpose.
We have no immediate plan to implement either a RESTCONF client or server for this device. However, a border router has interesting state to report, like packet traffic statistics, and it also may be used to configure the wireless nodes, particularly when first forming a network.
There are many, many options for the network monitoring tool. First, we plan to use Shinken for its modular, Python-based implementation and Nagios compatibility. Next, we plan to use the Kaji project's integration of the Adagios UI. We expect it will provide an attractive interface for RESTCONF configuration.
ncclient is a Python-based NETCONF client, and is under active development. We may be able to use some elements of the implementation within Kaji. In addition, we plan to continue to use and develop our SOS CoAP library.
From here, there are many details to address, like how exactly to adapt RESTCONF to CoAP. See the other pages in the LLN Monitoring section of the web site, available from the menu at the top of this page.