CASE 2013 - 6lowpan

6LoWPAN
IPv6 for Wireless Sensor Network
SASE 2013
Ing. Ana Diedrichs
UTN - Mendoza - Argentina
ana.diedrichs@gridtics.frm.utn.edu.ar
This work is licensed under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. To view a
copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/ or send a letter to Creative Commons, 171
Second Street, Suite 300, San Francisco, California, 94105, USA

Contenidos
• Introducción, Motivation
• Introducción a 6LoWPAN
• Formato de 6LoWPAN
• Neighbor Discovery: descubriendo nodos
vecinos
• Introducción a Routing
• Capa de aplicación
• Implementación de 6loWPAN

Internet of Things (IoT):
el alcance del Internet de las Cosas

5
Internet of Things: aplicaciones

Internet (v4) Regional Registry Exhaustion
Addresses Challenge
IANA Unallocated Address Pool Exhaustion: 03-Feb-2011
"Exhaustion" when the pool of available addresses in each RIR reaches the last /8 threshold.

IP next generation
IPv6
Espacio de direcciones: 128 bits (2128
) (ipv4 32 bis)
3.4×1038
= 340282366920938463463374607431768211456 addr.
Hay ~ 1025
granos de arena en la tierra
¡¡Podríamos conectar un trillón de objetos en internet!!
Encabezado de tamaño fijo (Fix size Header)
* No hay fragmentación en el camino (routers)
* Se pueden añadir cabeceras extras
Unicast, Multicast y Anycast (NO Broadcast)
Configuración de las direcciones Stateless y stateful

Internet of Things: el desafío de la interconexión
Conectar millones de objetos/cosas de forma cableada (no inalámbrica) sería muy
costoso. A modo de ejemplo
Electrical wall socket + installation = $50
Cat5 socket + installation = $150
1 Trillon nodes >> 1000 DGP Argentina
Comparaciones entre distintas tecnologías wireless
Technology RangeRange SpeedSpeed Power UsePower Use CostCost
Wifi 100 mts. 10-100 Mb/s High $$$
Bluetooth 10-100 mts. 1-3 Mb/s Medium $$
802.15.4 10-100 mts. 0,25-Mb/s Low $

Evolución de las Wireless Sensor Networks
ScalabilityPrice
Cabling
Cables
Proprietary
radio + network
20001980s 2006
Vendor
lock-in
Increased
Productivity
ZigBee
Complex
middleware
6lowpan
Internet
Open development
and portability
Z-Wave, prop.
ISM etc.
ZigBee and
WHART
Any vendor
6lowpan
ISA100
2008 ->

Beneficios de la tecnología 6LoWPAN
IPv6 over Low-Power Wireless Personal Area Networks
• Low-power RF + IPv6 = The Wireless Embedded Internet
• 6LoWPAN lo hace posible
• Los beneficios de 6-lowPAN incluyen:
– El uso de un estándar abierto, confiable y standards
– Fácil curva de aprendizaje
– Integración transparente con internet
– Mantenimiento de la red
– Escalabilidad global
– Flujo de datos End-to-end
– El uso de la infraestructura existente de internet

¿Qué es 6LoWPAN?
• IPv6 sobre Low-Power wireless Area Networks
• Definido en estándares IETF
– RFC 4919, 4944
– draft-ietf-6lowpan-hc and -nd
– draft-ietf-roll-rpl
• Compresión de cabecera sin estado (Stateless header compression)
• Enables a standard socket API
• Uso mínimo de código y memoria
• Integración punto a punto con internet
– Múltiples opciones de topología (802.15.4, Bluetooth,etc)
Permite adaptar un protocolo como IPV6 a cualquier PAN compuesta con dispositivos de recursos limitados y
bajo consumo energético

Grandes desafíos en las LoWPAN's
Dificultades en la implementación en sistemas embebidos debido a:
-Alimentación y duty-cycle: dispositivos inalámbricos alimentados por
baterías necesitan mantener ciclos cortos de actividad y permanecer en
modo bajo consumo el tiempo restante.
-Tamaño de la trama (frame): Protocolos actuales de internet requieren
enlaces que manejen tramas grandes
-Multicast: usualmente los dispositivos inalámbricos embebidos no
soportan multicast.
-Confiabilidad: Los protocolos de internet no están optimizados para
LoWPANs (low-power wireless and lossy networks).
-Web Services: Hoy en día los principales servicios de internet se
apoyan en web services haciendo uso en su mayoría de TCP.
-Gestión de la red: gestionar la red vía SNMP o web services

16
Arquitectura
• Las LoWPANs son stub networks: no tienen conocimiento de otras redes,
no “transportan” tráfico de otras redes a través de ellas y para comunicarse
con otras redes tienen “ciertos puntos de salida” (edge routers) definidos.
Una analogía es comparar la lowPAN con una isla de la que pueden salir
uno o varios puentes.
Tipos de configuraciones posibles con 6lowPAN
• Simple LoWPAN
– Un Edge Router (router de borde)
• Extended LoWPAN
– Varios Edge Routers compartiendo un enlace en común (backbone)
• Ad-hoc LoWPAN
– No hay routers en la LowPAN
Problemas de integración con internet
– Unidad máxima de transmisión (MTU)
– Protocolos de aplicación
– Interconectividad con IPv4 (transición)
– Firewalls y NATs
– Seguridad
IPv6-LoWPAN Router Edge Stack

18
El formato de 6LoWPAN
• 6LoWPAN es una adaptación del formato de cabecera de
IPV6
– Permite el uso de IPV6 en redes inalámbricas de bajo consumo
– Compresión de cabecera IPv6
– Compresión de cabecera UDP
• Formato inicialmente definido en RFC4944
• Actualizado en draft-ietf-6lowpan-hc

19
Características de 6loWPAN
• Trabaja bien en conjunto a capas de enlace de bajo consumo
como IEEE 802.15.4, narrowband ISM y bluetooth
• Soporte para direccionamiento de 64-bit y 16-bit usado en
802.15.4
• Compresión de cabecera eficiente
– Cabeceras base y de extensión de IPv6, cabecera de UDP
• Autoconfiguración de la red usando neighbor discovery
• Unicast, multicast and broadcast support
– Multicast is compressed and mapped to broadcast
• Fragmentación
– 1280 byte IPv6 MTU -> 127 byte 802.15.4 frames
• Soporte para IP routing (e.g. IETF RPL)
• Soporte para el uso de link-layer mesh (e.g. 802.15.5)

20
The 6LoWPAN Format
• 6LoWPAN makes use of IPv6 address compression
• RFC4944 Features:
– Basic LoWPAN header format
– HC1 (IPv6 header) and HC2 (UDP header) compression formats
– Stateless compression mechanism
– Fragmentation & reassembly
– Mesh header feature (depreciation planned)
– Multicast mapping to 16-bit address space
• draft-ietf-6lowpan-hc Features:
– New HC (IPv6 header) and NHC (Next-header) compression
– Support for global address compression (with contexts)
– Support for IPv6 option header compression
– Support for compact multicast address compression

22
Link-LocalSite-LocalGlobal
Unicast Address Scope
Local-link : fe80::/64
Local-Site : fec0::/64
Global : 2000::/3
Direcciones IPv6

Direccionamiento en IPv6
• Stateless Address Autoconfiguration (SAA)
• Prefix (64 bits) + Subfix (64bits)
• Prefix: (indica el alcance de una dirección)
• Local link (prefijo fe80::)
• Global Link (prefix: Router Advertisement – Router Solicitation)
• Subfix:
• EUI64 64-bit (Global Identifier - IEEE)
• Ejemplo de una interfaz wlan0 de una notebook conectada a
una red ipv6 (dirección local y dirección global)
wlan0 Link encap:Ethernet HWaddr 00:25:d3:67:79:ad
inet6 addr: 2001:1291:200:829e:225:d3ff:fe67:79ad/64 Scope:Global
inet6 addr: fe80::225:d3ff:fe67:79ad/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10732 errors:0 dropped:0 overruns:0 frame:0
TX packets:9573 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:7807052 (7.8 MB) TX bytes:1175527 (1.1 MB)

24
Dispatch
el primer byte del Payload
Bit Pattern Header Type Reference
00 xxxxxx NALP - Not a LoWPAN frame [RFC4944]
01 000000 Reserved as a replacement value for ESC [RFC6282]
01 000001 IPv6 - uncompressed IPv6 Addresses [RFC4944]
01 000010 LOWPAN_HC1 - compressed IPv6 [RFC4944]
01 000011 to 01001111 reserved for future use
01 010000 LOWPAN_BC0 - broadcast [RFC4944]
01 1xxxxx LOWPAN_IPHC [RFC6282]
10 xxxxxx MESH - Mesh header [RFC4944]
11 000xxx FRAG1 -- Fragmentation Header (first) [RFC4944]
11 100xxx FRAGN -- Fragmentation Header (subseq) [RFC4944]
(http://www.iana.org/assignments/6lowpan-parameters/)

25
IPv6/UDP Headers
Cabeceras sin comprimir
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 0 0 1|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flow Label cont| Payload Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | |
+-+-+-+-+-+-+-+-+ +
| |
+ +
| Source Address |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ +
| |
+ +
| Destination Address |
+ +
| |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source Port | Destination P.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest. P. cont| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum cont | UDP Payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6
UDP
Payload

26
IP Header Compression (HC1 and HC2)
No se utilizan técnicas del tipo gzip (compresión de archivos)
No es una técnica punto a punto ya que la dirección IP es requerida por los
routers
Stateless compression
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 1 0 0 0 0 1 0|SAE|DAE|C|NH |0 | Non-Compressed fields...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
__dispatch __/ _ HC1 header_/
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 1 0 0 0 0 1 0|SAE|DAE|C|NH |1 |S|D|L|__________| N.-C. fields...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
__ dispatch__/ _ HC1 header_/ _ HC2 header_/
C = Class and Flow Label
SAE/DAE = Source/Destination Address Encoding
NH = Next Header
S/D = Source/Destination Port Compression (61616 + 16)
L= whenever the length es compressed
Never Compressed Hop Limit and UDP Checksum

27
LoWPAN UDP/IPv6 Headers
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dispatch with LOWPAN_IPHC | LOWPAN_NHC | Src | Dst |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Checksum | UDP Payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 UDP
Payload
6 Bytes!
LoWPAN
draft-ietf-6lowpan-hc

28
IP Header Compression (IPHC)
Most of the time is used Global Routeable Ipv6 Addresses.
Base Header
+-------------------------------------+------------------------
| Dispatch + LOWPAN_IPHC (2-3 octets) | Compressed IPv6 Header
+-------------------------------------+------------------------
LOWPAN_IPHC Encoding
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
TF = Traffic Class, Flow Label
NH = Next Header Flag
HLIM = Hop Limit
CID = Context Identifier Extension
SAC = Source Address Compression
SAM = Source Address Mode
M = Multicast Compression
DAC = Destination Address Compression
DAM = Destination Address Mode draft-ietf-6lowpan-hc

30
Fragmentación
• IPv6 requiere que las capas inferiores toleren un MTU
(Minimum Transmission Units) mínimo de 1280 bytes.
• IEEE 802.15.4 deja aproximadamente 80-100 bytes de
payload
• RFC4944 define la forma de fragmentar y reensamblar IPv6
• La performance de paquetes IPV6 fragmentados sobre
lowPANs es muy pobre.
– Fragmentos perdidos causan la retransmisión de todo el
paquete
– Bajo ancho de banda y gran delay, propio de los canales
inalámbricos
– Protocolos de aplicación de 6LoWPAN deberían evitar la
fragmentación
– Compression should be used on existing IP application protocols
when used over 6LoWPAN if possible
• Fragment recovery is currently under IETF consideration

31
Fragmentación
Initial Fragment
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 0| datagram_size | datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Following Fragments
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 0| datagram_size | datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|datagram_offset|
+-+-+-+-+-+-+-+-+

34
IPv6 Neighbor Discovery
• IPv6 es el formato - ND es el cerebro
– “One-hop routing protocol” definido en RFC4861
• Encontrar vecinos
– Neighbor Solicitation / Neighbor Advertisement
• Encontrando routers
– Router Solicitation / Router Advertisement
• Stateless Address Autoconfiguration using NS/NA
– Detecting Addresses Duplication (DAD) using NS/NA
• Neighbor Unreachability Detection (NUD) using NS/NA
• DHCPv6 puede ser usado en conjunto con ND
• Requisitos:
– Link-layer Multicast
– Relación transitiva entre vecinos

35
Multicast Address:
All nodes : ff02::1/128
All routers : ff02::2/128
IPv6 Neighbor Discovery

37
Diseminación del prefijo (prefix)
• En las redes IPV6 normales, RAs (router advertisement) son
enviados basados en la información del prefijo configurada en
la interfaz del router
• En ND para 6LoWPAN RAs son también utilizados para
diseminar automáticamente información del router a través de
múltiples hops.

38
Un ejemplo de direccionamiento

39
Detectando direcciones duplicadas en
6loWPAN
• El Router Edge (router de borde) mantiene una tabla
(whiteboard)
– Los nodos deben registrarse en la whiteboard
New ICMP type: Node Registration (NR)
New ICMP type: Node Confirmation (NC)
• Node registration permite
– Detección de Host/routers inalcanzables
– Resolución de direcciones (a priori)
– Detección de direcciones duplicadas
Los registros son
– Refrescados períodicamente con un nuevo mensaje NR

40
Typical 6LoWPAN-ND Exchange

41
NR/NC Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (NR)/(NC)| Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TID | Status |P|_____________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Lifetime | Advertising Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Owner Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+

42
El Whiteboard
• El whiteboard es usado en la LoWPAN para:
– Detección de direcciones duplicadas en la LoWPAN (= prefijo)
– Lidiar con mobilidad (caso de las Extended LoWPANs)
– Localizar nodos

44
6LoWPAN Routing
Multihop Mesh Topology
• Link Layer Forwarding (Mesh Under) :
– Link Layer mesh (e.g. 802.15.5 )
– LoWPAN mesh (RFC but not forward algorithm)
• IP Layer Routing (Route Over):
• Routing in a LoWPAN
– Single-interface routing
– Flat address space (exact-match)
– Stub network (no transit routing)

45
Tipos de protocolos de ruteo
• Clases de algoritmos
– Basados en vectores de distancia (ej: AODV)
Cada enlace es asociado con un costo que es usado para
encontrar la ruta más corta hacia el destino. Cada router guarda
en su tabla de ruteo información del costo de los enlaces hacia
cada uno de sus vecinos a un salto.
– Basados en el estado del enlace
Cada nodo tiene información completa sobre la red, usualmente
gracias al broadcast/difusión. El nodo calcula un árbol con los
caminos más cortos hacia cada destino.
• Respecto al descubrimiento de nuevas rutas un algoritmo de
ruteo puede ser:
– Proactivo
La información de ruteo es adquirida antes de ser necesitada.
– Reactivo
La información de ruteo es descubierta dinámicamente cada vez
que es necesitada.

46
Protocolos para 6LoWPAN
• IP es independiente del protocolo de ruteo utilizado
– Reenvía basandose en tablas de ruteo
• Así también 6LoWPAN es independiente del protocolo de ruteo
• Consideraciones especiales para rutear sobre LoWPANs
– Una sola interfaz de enrutamiento, topologías planas
– Tecnologías inalámbricas de bajo consumo y con pérdidas (LowPANs)
– Flujos de datos específicos de aplicaciones embebidas
• Los protocolos MANET son útiles en algunos casos de redes ad-
hoc, e.g. AODV, DYMO
• Nuevo WG (working group) de IETF
– Routing over low-power and lossy networks (ROLL)
– Desarrollado específicamente para aplicaciones embebidas
– Protocolo en progreso: RPL (pronunciado como “Ripple”), es un
enfoque de ruteo proactivo por vector de distancia. Ver el draft de la
IETF (draft-ietf-roll-rpl)

48
Application Formats and Protocols

49
Introducción
• Los procesos de las aplicaciones se comunican sobre IP
usando la perspectiva de internet socket
• 6LoWPAN también utiliza el paradigma de los socket
• Los protocolos de aplicación usados con 6LoWPAN tienen
requerimientos de diseño especiales

50
Socket API
• La Socket API provee un acceso para comunicaciones de
datos entre aplicaciones
• Interfaz bien conocida para la manipulación de flujos de datos y
gestión de buffers via socket
• Soporte para mensajes de control
• Los comandos incluyen:
– socket, bind, send, read, close etc.
• Ejemplos de APIs de sockets
– Berkeley sockets in *nix systems
– Mac OSX (Darwin)
– Contiki uIP (Pseudo socket approach)

51
Paradigma punto a punto (End-to-end)

52
Protocolos y formatos de aplicación

53
Protocolos personalizados
• Es la solución más común hoy en día
• Los datos de la aplicación son codificados en
binario y específicos para la aplicación
• El protocolo de la aplicación utiliza un puerto
UDP específico
• Como 6LoWPAN permite comunicaciones
IPv6 punto a punto, no es un problema
• Ventaja:
– Compacto, eficiente, puede tener seguridad
integrada, punto a punto
• Desventaja:
– Se requiere una aplicación específica del lado
del servidor, poco reusable, curva de
aprendizaje costosa, baja interoperabilidad
L2/DLL
IPv6 / 6lowpan
UDP
L1/PHY
Custom Protocol

54
XML/HTTP
• Es la combinación per se para
comunicaciones entre servidores
• El formato XML es muy conocido
• Todos los servers “hablan” HTTP/XML
• Útil para RPC, eventos publicar/suscribir
• Paradigma SOAP o REST
• Advantages:
– Conocido formato XML
– Secuencia de mensajes formales
– Amplio soporte en internet
• Disadvantages:
– Ineficiente, complejo
• Solución: Embedded web-service: servicios
web embebidos (por ej. CoAP)
L2/DLL
IP
HTTP
L1/PHY
SOAP
XML Messages
TCP

55
Implementaciones posibles de 6lowPAN

¿Cómo integramos 6lowPAN en dispositivos
embebidos?
• Desafíos:
– Carencia de interfaces estándares (no USB or PCMCIA)
– No existen sistemas operativos estándares
– Limitaciones en el consumo energético
– Limitaciones de precio de mercado
• System-on-a-chip model
– Todo en un sólo chip
+ Máxima integración
+ Menor precio y menor tamaño
- Dificultades en el desarrollo
- Poca o escasa portabilidad
Ejemplos:
TI CC2530,
ATMEGA 128RF
Jennic JN5139.

Chip Models
• Solución en 2 chips
– La radio separada del micro
+ Libre elección del uC
+ Mayor portabilidad
- Más caro
- Integración de la aplicación en el stack
Ejemplos: TI CC2520, Atmel AT86RF231.
• Solución del procesador de red
– El stack de la red en la radio
+ Libre elección del uC
+ Aplicación independiente del stack
+ Fácil integración
- Solución cara
Ejemplo: TI CC1180.

58
Protocols Stacks
• Contiki
– Low-Power uIPv6/RPL Network
• Tiny OS
– BLIP, the Berkeley Low-power IP stack
– IPv6 Ready
• Nano Stack (Sensinode)
– Nano Stack, Nano Router, Nano Service
– Nano Sensor
• Jennic 6LoWPAN (Jennic)
– JN5139 Wireless Microcontroller
– Jenie API, SNAP, JenNet

59
SIPIA Net
Wireless Sensor Network for
Agronomical Research
SIPIA Net
Propietary STACK (gridTiCS)
SIPIA6 Net
6loWPAN STACK

60
Referencias
• N. Kushalnagar, G. Montenegro, C. Schumacher “IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs):Overview, Assumptions, Problem Statement,
and Goals”, RFC 4919, August 2007, IETF
• G. Montenegro,N. Kushalnagar,J. Hui, D. Culler “Transmission of IPv6 Packets over
IEEE 802.15.4 Networks”, RFC 4944, September 2007, IETF
• Shelby & Bormann, “The Wireless Embedded Internet” ISBN: 978-0-470-
74799-5, (c) 2009 John Wiley & Sons Ltd. Book's slides available here
David E. Culler & Jonathan Hui ”6LoWPAN Tutorial: IP on IEEE 802.15.4 Low-Power
Wireless Networks”, Arch Rock Corporation
• “Compression Format for IPv6 Datagrams in 6LoWPAN Networks”
draft-ietf-6lowpan-hc-13. RFC 6282.
• “Neighbor Discovery Optimization for Low-power and Lossy Networks”
draft-ietf-6lowpan-nd-15
• “Design and Application Spaces for 6LoWPANs”, draft-ietf-6lowpan-usecases-09.
• IPV4 Address Report http://www.potaroo.net/tools/ipv4/index.html
•

61
¿PREGUNTAS?
Ing. Ana Diedrichs
UTN - Mendoza - Argentina
ana.diedrichs@gridtics.frm.utn.edu.ar

Power Consumption
• Radio power consumption critical
to consider
• Power output level
– Limited savings effect
– Optimal power difficult
– Must be considered globally
• Transition times
– Each transition costs
– Power equal to RX mode
– Should be accounted for
Output
Power (mW)
Power
Used (mW)
0.003 15.30
0.032 17.82
0.100 20.16
0.200 22.50
0.316 25.02
0.501 27.36
0.794 29.70
1.000 31.32

Power Consumption
A simple approximation for power consumption:
= Time that takes to go from sleep state to awake state
= Transmitter setup time, i.e. time it takes for the transmitter to be ready
= Time in the Tx state
= Receiver setup time, i.e. time it takes for the receiver to be ready
= Time in the Rx state
= Time in the idle state
= Time in the sleep state
= Average number of times per frame that the transmitter is used
= Average number of times per frame that the receiver is used
= Duration of the time frame
= Power used in the Tx state
= Power used in the Rx state
= Power used in the idle state
= Power used in the sleep state
= Average power used by the transceiver
ﾠ
Pavg =
1
TF
PRxTwk - up + PRx ( NTxTTx - up + NRxTRx - up ) + PTxTTx + PRxTRx + PidleTidle + PsleepTsleep{ }
ﾠ
Twk - up
ﾠ
TTx - up
ﾠ
TTx
ﾠ
TRx - up
ﾠ
TRx
ﾠ
Tidle
ﾠ
Tsleep
ﾠ
NTx
ﾠ
NRx
ﾠ
TF
ﾠ
PTx
ﾠ
PRx
ﾠ
Pidle
ﾠ
Psleep
ﾠ
Pavg

Contiki uIPv6
• Popular embedded OS for small microcontrollers
– MSP430, AVR, PIC, 8051 etc.
• http://www.sics.se/contiki
• Standard C-based
• Portable applications
• Lightweight protothreads
• uIPv6 Stack
– Full IPv6 support
– RFC4944 + 6lowpan-hc
– UDP, TCP, ICMPv6
• Great for research

What is Contiki?
• Contiki is an open-source operating system/protocol stack for
embedded systems
• Highly portable and reasonably compact
• Protocol stack configuration customizable
• Originally created by Adam Dunkels, developer of the uIP
stack
• http://www.sics.se/contiki

Contiki processes
• Contiki core is event-driven
– Interrupts and HW drivers generate events
– Events are dispatched to event handlers by the Contiki core
– Event handlers must return control to core as soon as possible
– Co-operative multitasking
• Basic processes are implemented using protothreads
– Easier to create sequential operations
– An abstraction to avoid complex state-machine programming
• In more complex applications, the amount of states may be huge

Contiki execution models
• Contiki offers multiple execution models
• Protothreads: thread-like event handlers
– Allow thread-like structures without the requirement of additional
stacks
– Limits process structure: no switch/case structures allowed
– May not use local variables
• Multi-threading model available
– For more powerful systems
– Allows structured application design

Contiki processes: An example
/* Declare the process */
PROCESS(hello_world_process, “Hello world”);
/* Make the process start when the module is loaded */
AUTOSTART_PROCESSES(&hello_world_process);
/* Define the process code */
PROCESS_THREAD(hello_world_process, ev, data) {
PROCESS_BEGIN(); /* Must always come first */
printf(“Hello, world!n”); /* Initialization code goes here */
while(1) { /* Loop for ever */
PROCESS_WAIT_EVENT(); /* Wait for something to happen */
}
PROCESS_END(); /* Must always come last */
}

Contiki processes: Notes
• A process may not use switch-case constructs
– A limitation of the protothread model
– Complex state structures and switches should be subroutines
• A process may not declare local variables
– Variables will lose their values at any event waiting call
– All variables required by the main process must be static
• Effects on application design
– The main process thread should only contain sequences between event
waits
– All operations should be done in subroutines

Contiki events
• process_post(&process, eventno, evdata);
– Process will be invoked later
• process_post_synch(&process, evno, evdata);
– Process will be invoked now
– Must not be called from an interrupt (device driver)
• process_poll(&process);
– Sends a PROCESS_EVENT_POLL event to the process
– Can be called from an interrupt
• Using events
PROCESS_THREAD(rf_test_process, ev, data) {
while(1) {
PROCESS_WAIT_EVENT();
if (ev == EVENT_PRINT) printf(“%s”, data);
}
}

Contiki timers
• Contiki has two main timer types; etimer and rtimer
• Etimer: generates timed events
Declarations:
static struct etimer et;
In main process:
while(1) {
etimer_set(&et, CLOCK_SECOND);
PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et));
etimer_reset(&et);
}
• Rtimer: uses callback function
– Callback executed after specified time
rtimer_set(&rt, time, 0 , &callback_function, void *argument);

Contiki Protocol Stacks
• Contiki has 2 different protocol stacks: uIP and Rime
• uIP provides a full TCP/IP stack
– For interfaces that allow protocol overhead
– Ethernet devices
– Serial line IP
– Includes IPv4 and IPv6/6LoWPAN support
• Rime provides compressed header support
– Application may use MAC layer only
• Protocol stacks may be interconnected
– uIP data can be transmitted over Rime and vice versa

The Rime protocol stack
• Separate modules for protocol parsing and state machines
– Rime contains the protocol operation modules
– Chameleon contains protocol parsing modules
• Rime startup: an example
– Configure Rime to use sicslowmac over cc2430 rf
– Startup is done in platform main function:
platform/sensinode/contiki-sensinode-main.c
rime_init(sicslowmac_init(&cc2430_rf_driver));
set_rime_addr(); //this function reads MAC from flash and places
//it to Rime address

Rime: Receiving
• Setting up Rime receiving: broadcast
– Set up a callback function
Declarations:
static struct broadcast_conn bc;
static const struct broadcast_callbacks broadcast_callbacks =
{recv_bc};
The callback definition:
static void
recv_bc(struct broadcast_conn *c, rimeaddr_t *from);
In main process:
broadcast_open(&bc, 128, &broadcast_callbacks);
• Unicast receive in a similar manner

Rime: Sending
• Sending broadcast data using Rime
Declarations:
static struct broadcast_conn bc;
In main process:
packetbuf_copyfrom("Hello everyone", 14);
broadcast_send(&bc);
• Sending unicast data using Rime
Declarations:
static struct unicast_conn uc;
In your function:
rimeaddr_t *addr;
addr.u8[0] = first_address_byte;
addr.u8[1] = second_address_byte;
packetbuf_copyfrom("Hello you", 9);
unicast_send(&uc, &addr);

Creating Contiki Ports
• First step: see if your cpu already has code
– If yes, configure your platform to use it
– If not, see other cpu directories for implementation models
• Second step: see if your hardware is close to other platforms
– If yes, copy code from example platform and modify
– If not, see other platforms for minimal model
• Create a test application
– Start with LEDs in platform/myplatform/contiki-myplatform-main.c
– Use for loops to make sure that your compiler works
– Continue by adding printf's to see if your UART works
• First real application
– Create an etimer for your test process: flash LEDs, print info
– Try different timeouts to see if your clocks are correct
• Add more drivers and try them out

Router Integration
• Edge Routers interconnect the
IPv6 world and 6LoWPAN
• An ER needs to implement:
– 6LoWPAN interface(s)
– 6LoWPAN adaptation
– Simple 6LoWPAN-ND
– A full IPv6 protocol stack
• Other typical features include:
– IPv4 support and tunneling
– Application proxy techniques
– Extended LoWPAN support
– A firewall
– Management

81
Types of Mobility
• Mobility involves two processes
– Roaming - moving from one network to another
– Handover - changing point of attachment (and data flows)
• Mobility can be categorized as
– Micro-mobility - within a network domain
– Macro-mobility - between network domains (IP address change)
• Consider also Node vs. Network mobility
• What causes mobility?
– Physical movement
– Radio channel
– Network performance
– Sleep schedules
– Node failure

84
Dealing with Mobility
• Micro-mobility
– Do nothing (restart)
– Link-layer techniques (e.g. GPRS, WiFi)
– 6LoWPAN-ND extended LoWPANs
– Routing also plays a role
• Macro-mobility
– Do nothing (restart)
– Application layer (SIP, UUID, DNS)
– Mobile IPv6 [RFC3775]
– Proxy Home Agent
• Network mobility
– Do nothing (restart all nodes)
– NEMO [RFC3963]

86
IPv4 – IPv6 Transition
• Redes separadas
• Protocolos no compatibles entre si .Disruptivo
– Working group at the IETF
• Transition Mechanisms [RFC 4213]
• Dual Stack
• Tunnel
– Manual
– Automatic
– 6to4
– Tunnel Broker
• Traslation
– Application Layer Gateway
– NAT64/DNS64

88
Internet Architecture
Image source: (Wikipeida) GFDL

CASE 2013 - 6lowpan

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to CASE 2013 - 6lowpan

Similar to CASE 2013 - 6lowpan (20)

Recently uploaded

Recently uploaded (10)

CASE 2013 - 6lowpan