Beruflich Dokumente
Kultur Dokumente
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.
2
2 IPv4/IPv6
2.1 IPv4
2.1.1 Introduction
2.1.2 Header
1. Not use
2. DF (Don't Fragment) : At 1, If the packet size is more thant the MTU the
packet is rejected.
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
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.
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.
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).
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.
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.
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.
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.
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.
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