IP Communication for microcontroller based

embedded systems
Thalita Drumond
Pierre-Hugues Husson
Clément Péron

16/03/2012

1
1 Introduction
The Open System Interconnection Model has been proposed by the International
Organisation for Standardization in order to standardize and characterize features of
a communication system.The OSI framework architecture is composed by 7 layers, as
shown in the picture below. For most of developers the Media layers are invisible, but in
the design of embedded systems these layers are the most important. If they are over-
sized, they can be expensive, requesting too much overhead or not be friendly in electricity
consumption. On the contrary, they can limit the bandwidth, be unsafe, limit the number
of connected devices, etc.
Having these constraints in mind, this article introduces some IP communication
technologies for constrained embedded systems, together with practical examples of each
one, aiming to provide enough information to someone needing to choose whether to use
them in a project.

Figure 1  by Dino Korah, English Wikipedia

2
2 IPv4/IPv6
2.1 IPv4

2.1.1 Introduction

Internet Protocol is a network standard, corresponding to the layer 3 of the OSI

framework. IPv4 is the rst version and has been used for Internet. Still today, Ipv4 is
widely deployed and the major point is that is source and destination address use 32 bits.

2.1.2 Header

 Version (4 bits) : IP Version : 4

 Internet Header length (4 bits) : number of 4 octets words. (5<IHL<15)
 Type of service or Dierentiated Services Code Point (8 bits) : 3 bits for Quality of
services and 5 bits for ce champ permet de distinguer diérentes qualité de service
diérenciant la manière dont les paquets sont traités. Composé de 3 bits de priorité
(donc 8 niveaux) et trois indicateurs permettant de diérencier le débit, le délai ou
la abilité.
 Total Lenght (16 bits) : nombre total d'octets du datagramme, en-tête IP comprise.
Donc, la valeur maximale est (216)-1 octets.
 Identication (16 bits) : number to identify the fragments of the same package.
 Flags (3 bits) :

1. Not use

2. DF (Don't Fragment) : At 1, If the packet size is more thant the MTU the
packet is rejected.

3. MF (More Fragments) : At 1, inform that the packet is fragmented and over

packet arrive. Else inform that the packet isn't fragmented or it's the last
fragment.

 Fragment oset (13 bits) : position of the fragment relative to the start packet, in
number of 8 octets words.
 Time To Live (8 bits) : Initialized by the transmititer, it's decremented at each
node. When TTL = 0, the packet is dropped and an ICMP message is sent.
 Protocole (8 bits) : Denes the protocol used in the data portion of the IP datagram.

3
  Checksum (16 bits) : used for error-checking of the header.
 Source adress (32 bits) : IP adress of the transmitter.
 Destination adress (32) : IP adress of the receiver.
 Options, Padding : Optional.

2.2 IPv6

2.3 Presentation

Since the 3rd february 2011 the attribution of public IPV4 adress on internet is sat-
urated. That's why we have to use a new version of IP with a source and destination
adresses on 128 bits. This have a new header with a xe size and don't have a checksum.
So IPv6 is more simple but can allow more devices on the same network.

2.3.1 Header

 Version (4 bits) : Ip Version : 6.

 Trac Class (8 bits) : look like to ToS or DSCP in IPv4
 Flow Label (20 bits) : similar to ToS or DSCP.
 Payload Lenght (16 bits) : equal to total lenght but without the size of the header.
 Next Header (8 bits) : same as Protocol in IPv4.
 Hop Limit (8 bits) : equal to TTL in IPv4.
 Source adress (128 bits) : same as IPv4.
 Destination adress (128 bits) : same as IPv4.

2.4 Stack TCP/IP

The most easy is to use an OS with an IP stack integrated like The Contiki OS or an
embedded Linux but if the OS doesn't have one like FreeRTOS or ChibiOS and if you
don't want to program all the ip protocol then you can use a TCP/IP stack. There are
lots of libraries some are free and open-source and they can manage ipv4, ipv6 or both.
The most popular of them are uIP and LwIP .

4
 If you have a very tiny microcontroller and just need a basic communication you can
use uIP or UIPv6 if you need IPv6. But if you have tens of RAM and 40kb ROM free
use LwIP, it's more powerfull and include ARP, DHCP, DNS, etc..

2.5 Conclusion

IPv6 can allow much bigger network, packet and header is easier than IPv4. Moreover,
you don't have to recalculate the checksum at each router but Ipv4 is more present, the
size of the network are already huge for embedded system without internet connection.
So choose a protocol is not simple as it's look like. You have to choose between a light-
complex IPv4 or a simple-huge IPv6. So why don't have a simple IPv6 on a light IPv4
that's why we will continue on the 6LoWPAN.

3 6LoWPAN
3.1 Introduction

6LoWPAN is a IETF standard that implements the transmission of IPv6 packets over
IEEE 802.15.4 networks. The 6LoWPAN name stands for IIPv6 over low-power wireless
personal area networks. The fact is that IPv6 MTU is 1280B while the 802.15.4 MTU
is only of 127B, so there is an obvious need of some adaption layer between the two.
The 6LoWPAN standard performs this role, dening frame formats, fragmentation and
compression strategies.

5
 The main interest of the 6LoWPAN is the fact that it brings IP to the embedded
world, allowing interconnection of LoWPANs with other IP networks, like the Internet.
That is why 6LoWPAN sometimes is mentioned as being the Internet of things. Bringing
IP over LoWPANs brings not only the Internet but also all the higher layer utilities and
applications already implemented for IP. The applications of 6LoWPAN are diverse, and
include : home/building automation, health care appliances, environment monitoring,
among many others.
In this section of the document will explain about the the header compression mech-
anisms, the routing possibilities, the integration with other IP networks and nally show
some existent solutions allowing the implementation of 6LoWPAN.

3.2 Header format

A 6LoWPAN header starts with a dispatch value that determines the header type,
for instance a a compressed IPv6 header, a regular IPv6 header. The possible headers are
shown in the following picture.

Pattern Header Type

+------------+-----------------------------------------------+
| 00 xxxxxx | NALP - Not a LoWPAN frame |
| 01 000001 | IPv6 - Uncompressed IPv6 Addresses |
| 01 000010 | LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6 |
| 01 000011 | reserved - Reserved for future use |
| ... | reserved - Reserved for future use |
| 01 001111 | reserved - Reserved for future use |
| 01 010000 | LOWPAN_BC0 - LOWPAN_BC0 broadcast |
| 01 010001 | reserved - Reserved for future use |
| ... | reserved - Reserved for future use |
| 01 111110 | reserved - Reserved for future use |
| 01 111111 | ESC - Additional Dispatch byte follows |
| 10 xxxxxx | MESH - Mesh Header |
| 11 000xxx | FRAG1 - Fragmentation Header (first) |
| 11 001000 | reserved - Reserved for future use |
| ... | reserved - Reserved for future use |
| 11 011111 | reserved - Reserved for future use |
| 11 100xxx | FRAGN - Fragmentation Header (subsequent)|
| 11 101000 | reserved - Reserved for future use |
| ... | reserved - Reserved for future use |
| 11 111111 | reserved - Reserved for future use |
+------------+-----------------------------------------------+
from Montenegro, et al., RFC4944, ITEF.

The mesh and fragmentation headers are an exception since they don't use all the dispatch
bits to be identied (not used bits marked as xxx in the chart above). The x bits are used
by other elds specic to each header.

6
 There is a constraint on the order of the headers, if more than one is used in the same
packet : broadcast header, mesh header, fragmentation header, then the IPv6 header
(compressed or not).

3.3 Header compression and fragmentation

The 6LoWPAN frame is included as payload for a 802.15.4 data frame. For doing
so, two strategies are possible : rst header compression, and then, if needed, packet
fragmentation.
The compression standard dened in the RFC4944 is said to be stateless, which means
that the headers do not carry any information that is a common state to all PAN members.
This makes the compression really ecient in intraPAN communications, but it does not
work as well for communications with dierent networks. For example, an IPv6 complete
address has 128 bits. Inside a LoWPAN, the network prex will be the same for all devices,
so there is no need to transmit the whole 64 bits address (the same logic does not apply for
communications between dierent networks, where the whole address might be needed to
identify a network member). Another principle is eliminating redundant information. For
example, if the host ID part of the IPv6 address can be inferred from the MAC address,
it is elided from the header.
Using analogous reasoning, most elds inside the IPv6 headers are compressed, except
the Hop Limit, which is always carried in 8 bits. If UDP is used as transport layer, the
standard provides a compression standard of its headers too.
If there is need of packet fragmentation, a fragmentation header is included before
the IPv6 compressed header. It contains the datagram size, a datagram tag to identify
the fragments corresponding to the same original unfragmented packet, and a datagram
oset of the the current fragment relative to the beginning of the orginal packet. In the
rst fragment the oset is always zero, then the oset eld is elided from the header. A
dierent dispatch value identies if the packet is a rst fragment or a general fragment.

3.4 Routing and mesh header

As it is still IP, it is possible to implement any routing protocols currently used over
IP, and 6LoWPAN does not dene any specic routing protocol. Nevertheless, 6LoW-
PAN devices are usually really short in memory and/or may have constrained processing
capabilities, which complicates managing and storing routing tables in the usual way.
Another factor that adds complexity to the routing is that many of these devices can en-
ter in stand-by mode. It may be needed to send a wake-up message to the device before
sending the actually useful data.
There has been some eots in creating a routing protocol adapted to these conditions.
For instance, there is a group on IETF currently working on a protocol named ROLL :
routing over low power and lossy networks.
Alongside with IP routing, there is a level 2 routing allowed by 6LoWPAN, also called
mesh-under. To provide this possibility, the 6LoWPAN frame gets an extra header,
before the fragmentation header : the mesh header. It contains a hop limit, source and
destination addresses (802.15.4 addresses). This allows a mesh topology by forwarding
packets in level 2, going hop by hop until the nal destination is reached, or the hop limit

7
reaches zero (the packet is dropped then). There is also an optional broadcast header,
identied by an specic dispatch value. It contains a packet sequence number permitting
identify the broadcast and detect the reception of duplicate packets. Conversely, the
standard does not give any further denitions on routing possibilities.

3.5 Integration with other IP networks

To connect a 6LoWPAN to another IP network, one of the devices must act as a

gateway, usually called edge router. In a general view, it will get the compressed packets
and uncompress them so they can be understood in regular IP networks. With the arriving
packets, the router has to compress them before forwarding to the 6LoWPAN destination
device. Dierent translations between packets might be needed, depending on the special
6LoWPAN headers used before the IPv6 header, and on whether the next IP network
is also a 6LoWPAN or not. The edge router must provide the physical transition if the
interface is with another kind of wireless network or a cabled network.

3.6 Available solutions

If the stack is implemented by a microcontroller, any 802.15.4 transceiver could be used

as physical support, even an Xbee (usually destined to be used with Zigbee protocol). The
6LoWPAN stack has been implemented for some embedded operational systems, such as
ContikiOS and TinyOS. There is also the commercial Nanostack, from Sensinode, that is
build over a FreeRTOS kernel. Sensinode also provides the Nanorouter, which is a software
to implement an edge router device. Links to these solutions are in the references section.
ContikiOS is open source, and its website provides pre-compiled binaries for the Tmote
Sky/TelosB and Atmel AVR Raven. Sky/TelosB is a mote containing a mixed signal
microcontroller by TI and a 802.15.4 transceiver Chipcon CC2420. The AVR Raven
has similar structure, but the microcontroller is a simple 8-bit AVR and the transceiver
is the AT86RF230. There is also the option of using SoC containing both the AVR
microcontroler and the transceiver.
TinyOS 2.x has a library thath partily implements 6LoWPAN. Among the missing
features, the mesh-networking capabilities have not yet been fully implemented.

8
 The Sensinode's Nanostack is adapted to be used with some Texas Instruments SoCs :
CC2430, CC2530, CC1110, CC1180, CC430. The Nanostack and Nanorouter are comer-
cial and not opensource.

4 CoAP : Constrained Application Protocol

4.1 A web-oriented protocol

CoAP, created by the CoRE (Constrained RESTful Environments) workgroup is a

RESTful protocol, meaning it meets several requirements : It's a client/server model, the
communication between the client and the server is mostly stateless, every transmission
between the client and the server features all the session informations. everything is
available through a URI, only a few number of actions are available.
Also, the CoAP protocol is meant to be interconnected with the web, and includes
means of accessing to the Web, and to be accessed from the Web.

4.2 An embedded protocol with some extra features

But CoAP is a protocol for embedded systems, so it fullls some other requirements.
First one is the use of a datagram protocol (UDP), rather than a streaming protocol like
TCP, so there is no need to keep big packets in memory for fragmentation, or for non
critical packets. Another aspect is that it's a binary protocol, which is easier to process
than just strings.
The CoAP draft also gives recommandations for the 802.15.4 protocol, to improve
eciency by preventing fragmenting packets.
Even though CoAP is using UDP, it can enable reliable communication through ac-
knowledges and message IDs, but it can operate too in multicast mode, to enable more
ecient communication in network of devices. Thanks to multicast, it has also the ability
to automatically detect services available on a network.
Some users will need some security in their communication. For those cases, CoAP is
capable of using IPSec or DTLS as sub-layers to ensure that protection.

4.3 Simple headers, various options

The headers of a standard CoAP packet are simple, and the protocol is relying on
options, rather than xed parameters. The header species the version of the protocol, the
type of packet Conrmable (needs ACK), non Conrmable, Acknowledge, or Reset, the
number of options, the code of the action, based on the Web semantics like GET/POST
commands, and OK/Bad option/Not found/... answer, and nally there is the message-id
to prevent messages from being interprted multiple times. And then comes the options.
There are two sorts of options, the Critical and the Elective types. The Critical ones
are options that can't be ignored by the server. If they appear and the server doesn't
understand it, then it sends a reset to the client. The Elective ones are non-vital options,
which can be silently ignored.
Most of the options are coming from the Web world, like Uri-Host/Uri-Port/Uri-
Path/Uri-Query which specify all the parts of the URI, splited on the request side for eas-

9
ier implementation, Content-Type and Accept which are the exact equivalent of the same
properties in HTTP. Some caching possibility are also available, through the ETag/Max-
Age/If-Match/If-None-Match options, making CoAP a good binary match to HTTP with
most of the useful features.
But there are also more unusual options, like Proxy-Uri, which are specially intented
for the cross-communication with the the Web, or Token to match the requests and the
answers.
Finally, the size of the packets are known by the lower layer, namely UDP/6lowpan,
so the extra bytes are known to be the payload, there is no repetition of the size of the
data.

4.4 Additional features

CoAP also features a way of discovering services on a server : the server must respond
on port 5683 and can support the CoRE Link Format of discoverable standard to nd
CoAP end-points.
Another feature is the avaibility of publication/subscription methods, to enable asyn-
chronous communication, and event-based devices.

5 Conclusion
Using the protocols explained here 6lowpan and CoAP, with an internet connection
through IPv6, it's possible to establish a connection from anywhere to a micro-controller,
using standard protocols, with lower cpu power and memory consumption than with
usual HTTP protocol.

6 References
 RFC4944 - Transmission of IPv6 Packets over IEEE 802.15.4 Networks. IETF.
 IP-based Wireless Sensor Networking : Secure, Reliable, Low-Power IP Connectivity
for IEEE 802.15.4 Networks. ArchRock Corporation.
 6LoWPAN : Incorporating IEEE 802.15.4 into the IP architecture. Jonathan Hui,
David Culler and Samita Chakrabarti for IPSO Alliance.
 Introduction to 6LoWPAN - Book slides and exercises. Zach Shelby and Carsten.
 Contiki OS
 A 6lowpan Implementation for TinyOS 2.0. Matús Harvan, Jürgen Schönwälder.
 TinyOS 6LoWPAN Readme
 Sensinode Products
 Atmel AVR Raven
 Sky/TelosB
 CoAP draft
 Best practice to map HTTP to CoAP and viceversa
 lwIP - A Lightweight TCP/IP stack
 IPv4 Specication
 IPv6 Specication

10