2010/2011 WSN course - Final Project

Development of a 6LoWPAN Adaptation Layer for a Jennic JN5139 Module

Project Details

Goal
The integration of Jennic JN5139 Module as an end-node in a MicaZ (TinyOS) 6LoWPAN network. This project objective is to implement parts of the 6LoWPAN stack on top of 802.15.4 PHY and MAC in a Jennic JN51xx module. The aforementioned is a 2.4GHz IEEE 802.14.5 compliant module, with limited processing and memory capabilities. The aim is to be able to use a Jennic node as an end-node in a 6LoWPAN Network; as such no routing will be implemented as part of the 6LoWPAN stack.

Assigned to: Rui Santos, MEEC.

Introduction

With the evolution and crescent growth of Sensor Networks, not only for Industrial environments but also in Residential ones, hardware companies are constantly developing new devices (more powerful, less energy consuming) and evolving their communication protocols to better suit this new requirements.
Also, with the expansion of the number of Internet connected devices (increasing number of mobile phones, PDA, tablets) and the inevitable global implementation of. IPv6, and all the perks associated with it, provides the Sensor Networks with the necessary space to the application of The Internet of Things to WSN.
With that in mind, 6LoWPAN (IPv6 over Low power WPAN), under by the IETF Group with the same name, might be the future standard in that field.
Being able to implement LoWPANs running multiple hardware platforms and still inter-operate by running the same protocol it is very desirable. When creating a network, there is no longer the limitation of using the same company hardware to guarantee that all nodes could run properly. 6LoWPAN provides that and much more, as explained later on.
This work is about 6LoWPAN and its feature of interoperability between different hardware running that same protocol.

6LoWPAN - IPv6 over Low power Wireless Personal Area Network

The eminent change of the IP from IPv4 to IPv6, will increase the range of addresses available in the Internet. Also, with this expansion, NAT (Network Address Translation) will become unnecessary. Another goal is to make system configuration and managing less time consuming.
In a LoWPAN, to be able to communicate with any sensor in the network directly from any point in the Internet seems very interesting. And with this growth of addresses, every node can have a unique address. To be able to integrate LoWPAN devices into existing IP-structures it's a great benefit.
The answer is 6LoWPAN. The 6LoWPAN IEFT Group started working in an adaptation layer to work over de IEEE 802.14.5 standard and enable IPv6 communication, in limited hardware such as those present in WSN. It is specified by RFC 4944, and the problem statement by RFC 4919.
This adaptation Layer provides Header Compression, Fragmentation and Routing capabilities.

TinyOS

Is an open source operating system, developed by the University of California, Berkeley in cooperation with Intel Research and Crossbow Technology, being mainly oriented for wireless sensor networks, with limited process and memory capabilities. It is considered in this assignment, since the test environment is a TinyOS network.

BLIP
BLIP, the Berkeley Low-power IP stack, is the 6LoWPAN stack for TinyOS. The version available at the Tagus-SensorNet, where this project is to be tested, is running a Blip 1.x version, which uses 6lowpan/HC-01 header compression. The current version, Blip 2.0 is a reimplementation of IPv6 in TinyOS, using the more recent 6lowpan/HC-06 header compression.

Jennic

Recently acquired by NXP, Jennic is a company oriented for Low Power RF like wireless sensor networks, with a portfolio of wireless micro-controllers, modules and design/developer tools. They provide a few protocol stacks, such as IEEE 802.15.4, Zigbee Pro, 6LoWPAN (over JenNet) and JenNet (a proprietary network protocol stack designed to work with Jennic family of wireless micro-controllers and modules).

6LoWPAN over Jennet
Quoting from Jennic: Jennic's implementation of 6LoWPAN provides a wireless connectivity solution based on Jennic's proprietary JenNet protocol and the industry-standard IEEE 802.15.4 protocol at 2.4 GHz, enabling embedded devices to communicate wirelessly using IPv6 (Internet Protocol version 6).
Although called 6LoWPAN, the use of the proprietary protocol JenNet, make the stack unusable in networks running 6LoWPAN Standard. Associated to the fact that there is no access to the source code, implementing the protocol based in the Jennic implementation it is not possible.

Figure 1 - Jennic 6LoWPAN Stack vs. IETF 6LoWPAN Stack.

With this work, it is intended to implement part of the 6LoWPAN network stack, directly over the IEEE 802.15.4 Standard, without the JenNet support layer, creating an almost standard (almost, because TinyOS network used for testing is based in an old 6LoWPAN Header Compression Draft) operating 6LoWPAN in the Jennic hardware.

Project

As previously refered, it is pretend to implement part of the 6LoWPAN network stack, directly over the IEEE802.15.4 standard, without the JenNet support layer, creating an almost standard (almost, because TinyOS network used for testing is based in an old 6LoWPAN Header Compression Draft) operating 6LoWPAN in the Jennic hardware, using the Jennic IEEE 802.15.4 API (standard compliant). The target of this project is the Jennic JN5139 Module.

Figure 2 - JN5139 Module.

Its main features are:

16MHz 32-bit RISC CPU;
96kB RAM, 192kB ROM;
4-input 12-bit ADC, 2 11-bit DACs, 2 comparators, temperature sensor;
2 Application timer/counters, 3 system timers;
2 UARTs (one for in-system debug);
SPI port with 5 selects;
2-wire serial interface;
21 GPIO.

Approach

The goal is to develop a 6LoWPAN Adaptation Layer. Since the available JenNet proprietary IP Protocol is not available, the 6LoWPAN was developed from scratch, based on the IEEE 802.15.4 code. For development, all code was based on the IETF 6LoWPAN HC 01 Draft, being the main focus the functions that allow the Jennic to interact with the test network.

Implementation Stages

The first step then, was to correctly implement the 6LoWPAN Header Compression/Decompression method for the IPHC Header Compression, since all messages transmitted in the the test environment use this Header Compression.
After that and by analysing the network message exchange protocol and focusing on the tests that would be executed to demonstrate that the implementation was working correctly, a list of implementation stages was made.
After IPHC implementation, functions to identify message types were implemented next, beginning with those for the ICMPv6 type, necessary for the correct identification of the hardware on the test network.
Next, at an upper layer level was implemented the UDP message parsing function for the implemented tool, netcat6. Here, NHC Header Compression was implemented for the transmission of UDP messages between Jennic and the test network.

Software Running Stages
On System Initialization, the Jennic IEEE 802.15.4 Stack, the radio and Integrated Peripherals (temperature sensor and the DIO for led are set) are initialized. A Router Solicitation Message is sent to all neighbour routers, so that the Jennic can register in the Network.
This corresponds to the following message exchange:

Router Solicitation (Jennic);
Router Advertise (MicaZ);
No Next Header (Jennic).

Upon receiving an incoming packet, the stack identifies if it is the right format (an IEEE 802.15.4 packet). The IEEE 802.15.4 Layer separates the Header from the payload and passes it into the 6LoWPAN Layer. Then the 6LoWPAN Header is decode/decompresses and an IPv6 message is obtained and passed to the IPv6 Layer for interpretation.
For UDP messages, there is a dedicated function that deals with UDP. After this, an appropriated response is generated, the packet passed to the lower layer for 6LoWPAN Encoding/Compression e finally to the IEEE 802.15.4 to be sent.
One interesting feature is the memory allocation in the Lower Layer (IEEE 802.15.4) requested by the upper (IPv6) Layer, on packet formation. The same buffer is used to put the information added by each Layer on the way down, avoiding the use of intermediary buffers, and keeping the memory requirements to a minimum.
After this, the Jennic waits for activity on the radio.
The description of the program, divided by the stack layers, are represented on Figure 5 and 6.
All Figures are connected by the coloured arrows.

Figure 3 - Software Architecture.

 
Figure 4 - Program Evolution on incoming Messages (divided by Stack Layers).

Figure 5 - Program Evolution when sending Messages (divided by Stack Layers).

Implementation Test

To test the implemented application on a really life environment, the Jennic was connected to the TinyOS Network as represented on the following image:

Jennic provides a SDK Toolchain (CodeBlocks), plus the necessary Libraries for Application Development. Also, to upload the binary to the Jennic hardware the Flash Programmer is available as a standalone program. All links available in the Download Section.

To test the development, in the Download Section there is also a .zip with the source code, the codeblock project files (.cbp) and a compiled binary for the JN5139.
To use the binary, simply use the Flash Programmer to upload it to the hardware. Put the Jennic in programming mode, select the correct COM Port and the path to the binary, mark the connect box.
If everything went correctly, in the Device field should be filled, so as the Flash and de MAC Address. Then press Program.
If the objective is to edit the code, after installing the SDK and Libraries, simply extract the content to the Application folder (default should be: C:\Jennic\cygwin\jennic\SDK\Application\) and open the .cbp with CodeBlocks.

A simple test to the implementation can be made by opening a terminal window in the computer with the IPBaseStation and type:

ping6 fec0::X (where x is the short address of the module)

The netcat, as implemented, opens an UDP port to send/receive UDP packets. The Jennic Module receives an UDP message, executes de parsing and responds accordingly. An example of a netcat:

netcat -6 -u fec0::x port

Figure 7 - netcat example.

The option -6 forces the IPv6 mode, -u for UDP, x is the Module Address and port is the connection port (TinyOS uses port 2000 for this tool and so does Jennic). Type help for the available options.

help	Lists all available methods.
echo "message"	Returns the echo "message"
temp	Returns temperature from on on-board temperature sensor.
led [options]	Display current led state. Options: on/off to turn led on/off.

TinyOS Tweaks and Tricks

During analysis of the TinyOS network some discrepancies to the IETF 6LoWPAN HC 01 Draft, with caused some delay on the development.
When analysing message exchange it was noted that TinyOS uses FF02::AA01 and FF02::A402 for Router Advertise Address and Router Solicitation Addresses instead of FF02::1 (all nodes) and FF02::2 (all routers) in the multicast address as used in IPv6.
But this modifications were made at the IEEE 802.15.4 Layer of TinyOS, not affecting the Checksum as initially considered.
The other situation is related to the NHC Header Compression rules, as stated by the draft. The Draft states that an NHC ID Bit = 0 identifies a Next Header type 0x11 (UDP). TinyOS implements the exact opposite.
To guarantee interoperability between Jennic and TinyOS, it was set that a NHC ID Bit = 1 identified the UDP Header, and the multicast addresses set as TinyOS.