« Previous - Version 16/17 (diff) - Next » - Current version
6lowpan group from 18-748 -, 05/09/2010 03:18 pm


For information on how to install 6LoWPAN, refer to the 6LoWPAN Installation guide.

For information on how to program firefly nodes with the Nano-RK 6LoWPAN API refer to the 6LoWPAN API.

In this project we attempt to bring the full IPv6 stack to the nano-rk operating system by
implementing 6LoWPAN, a standard which enables the use of IPv6 over wireless embedded

The benefits of using 6LoWPAN include:
  • Open, long-lived, reliable standards
  • Easy learning curve
  • Transparent Internet integration
  • Network maintainability
  • Global scalability
  • End-to-end data flows
More information about 6LoWPAN can be found at:


The overall architecture of 6LoWPAN is described in the picture below.
Currently we have only implemented a Simple LoWPAN (a network with only one Edge router).

Image(architecture.png, 400px)
(Source: "Overall, there are two main parts in implementing 6LoWPAN: the nodes in the network and the Edge Router.

Node Architecture

One of the primary aspects of a wireless network system is routing. We decided from the recommendation of the 6LoWPAN specification to
implement the RPL routing protocol from the ROLL (Routing Over Low power and Lossy networks) working group.

Unlike the MANET routing protocols which perform well for adhoc networks, RPL is optimized for upstream and downstream routing to/from a
root node, a paradigm more closely aligned for networks connected to the internet. More info about RPL can be found in the
RPL IETF draft ([http://tools.ietf.org/html/draft-ietf-roll-rpl-07":http://6lowpan.net])).

Image(rpl.png, 400px)
(Source: "The routing packets of RPL are all sent via ICMPv6 packets. When a node receives a packet not belonging to itself it consults the RPL
module to determine where to forward the packet. From the recommendation of the 6LoWPAN spec we also decided to route over IP addresses
("Route-Over") instead of forwarding with MAC addresses ("Mesh-Under") as it is simpler to implement.

Our overall node architecture is thus described in the picture below.

[[Image(node.png, 200px)":http://6lowpan.net])]

Edge Router Architecture

The main purpose of the edge router is to take any incoming IPv6 packets and convert it to 6LoWPAN packets and take any outgoing 6LoWPAN
packets and convert it to IPv6 packets. Because of it's tight integration with IPv6 it is necessary to implement a 6LoWPAN network driver.

Image(edge.png, 400px)

We also decided that it is probably best to have most of the edge router logic running in user space so that we did not crash the kernel
whenever a bug occurred. This also has the added benefit of being able to debug using user-space debugging tools such as gdb. Thus, we have
a separate user-space process which communicates with the 6LoWPAN network driver via netlink sockets. This user-space process is responsible
for most of the heavy edge router stuff:
  • compression/decompression
  • fragmentation/defragmentation
  • routing tables
  • acting as the root RPL node
  • bootstrapping

From this user-space process, the edge router communicates with the nodes by setting up a slipstream communication link with a spare node which
acts like a radio. All packets which the edge router wants to send to the network are just sent to this node over slipstream and the node then
sends the packets over bmac on behalf of the edge router. Similarly any packets received by the node via bmac are forwarded to the user-space
process. The node connected via slipstream does no more than act like a radio. We designed it in this way so that all functionality of the
edge router is encapsulated in the user-space process.


There still remains a bunch of work to be done in order to make 6LoWPAN more robust/efficient. Here is a short
list of several things which need work.

  • Architecture
    • Extended LoWPAN
    • Security
    • Mobility
  • Edge Router
    • More header compression
    • Fragmentation
    • Remove lost packets
  • Node
    • Remove race conditions
    • Make RPL more robust
    • Add checksumming on node

architecture.png (106.7 kB) 6lowpan group from 18-748 -, 05/04/2010 04:27 pm

rpl.png (118.3 kB) 6lowpan group from 18-748 -, 05/04/2010 05:01 pm

node.png (6.5 kB) 6lowpan group from 18-748 -, 05/04/2010 05:12 pm

edge.png (13.3 kB) 6lowpan group from 18-748 -, 05/04/2010 07:44 pm