CASE 2013 - 6lowpan

6LoWPANIPv6 for Wireless Sensor Network

SASE 2013

Ing. Ana DiedrichsUTN - Mendoza - Argentina

[email protected]

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

http://creativecommons.org/licenses/by-nc-sa/3.0/

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 ExhaustionAddresses 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 generationIPv6

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

Proprietaryradio + network

20001980s 2006

Vendor lock-in

IncreasedProductivity

ZigBee

Complex middleware

6lowpanInternet

Open development and portability

Z-Wave, prop. ISM etc.

ZigBee and WHARTAny vendor

6lowpanISA100

2008 ->

Beneficios de la tecnología 6LoWPANIPv6 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

Introducción a 6LoWPAN

¿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

15

El formato de 6LoWPAN

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

17

Arquitectura

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

21

IPv4 and IPv6 Format

22

Link-LocalSite-LocalGlobal

Unicast Address Scope

Local-link : fe80::/64Local-Site : fec0::/64Global : 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

Dispatchel 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 use01 010000 LOWPAN_BC0 - broadcast [RFC4944]01 010001 to 01011111 reserved for future use01 1xxxxx LOWPAN_IPHC [RFC6282]

10 xxxxxx MESH - Mesh header [RFC4944]

11 000xxx FRAG1 -- Fragmentation Header (first) [RFC4944]11 001000 to 11011111 reserved for future use11 100xxx FRAGN -- Fragmentation Header (subseq) [RFC4944]11 101000 to 11111111 reserved for future use

(http://www.iana.org/assignments/6lowpan-parameters/)

25

IPv6/UDP HeadersCabeceras 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

routersStateless 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 LabelSAE/DAE = Source/Destination Address EncodingNH = Next HeaderS/D = Source/Destination Port Compression (61616 + 16)L= whenever the length es compressedNever 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

29

Cabeceras de 6LoWPAN

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

43

Routing

44

6LoWPAN RoutingMultihop 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 enlaceCada 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:

– ProactivoLa información de ruteo es adquirida antes de ser necesitada.

– ReactivoLa 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

56

¿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 portabilidadEjemplos:

TI CC2530, ATMEGA 128RF Jennic JN5139.

57

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 NetWireless Sensor Network for

Agronomical Research

SIPIA NetPropietary STACK (gridTiCS)

SIPIA6 Net6loWPAN 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 DiedrichsUTN - Mendoza - Argentina

[email protected]

62

SPARE SLIDES

63

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

64

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 ( N TxTTx - up + N RxTRx - up ) + PTxTTx + PRxTRx + PidleTidle + PsleepTsleep{ }

ﾠ

Twk - up

ﾠ

TTx - up

ﾠ

TTx

ﾠ

TRx - up

ﾠ

TRx

ﾠ

Tidle

ﾠ

Tsleep

ﾠ

NTx

ﾠ

NRx

ﾠ

TF

ﾠ

PTx

ﾠ

PRx

ﾠ

Pidle

ﾠ

Psleep

ﾠ

Pavg

65

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

66

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

http://6lowpan.net/wp-content/uploads/2009/12/6lowpan-book-slides-full-20091206.pdf

http://www.potaroo.net/tools/ipv4/index.html


67

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

68

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

69

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

70

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 */

}

71

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

http://www.sics.se/contiki

72

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 eventsPROCESS_THREAD(rf_test_process, ev, data) { while(1) { PROCESS_WAIT_EVENT(); if (ev == EVENT_PRINT) printf(“%s”, data); }}

http://www.sics.se/~adam/contiki




73

Contiki timers

• Contiki has two main timer types; etimer and rtimer

• Etimer: generates timed eventsDeclarations: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);

74

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

75

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

76

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 voidrecv_bc(struct broadcast_conn *c, rimeaddr_t *from);

In main process:broadcast_open(&bc, 128, &broadcast_callbacks);

• Unicast receive in a similar manner

77

Rime: Sending

• Sending broadcast data using RimeDeclarations:static struct broadcast_conn bc;In main process:packetbuf_copyfrom("Hello everyone", 14);broadcast_send(&bc);

• Sending unicast data using RimeDeclarations: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);

78

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

79

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

80

Mobility & Routing

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

82

Node Mobility

83

Network Mobility

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]

85

IPv4 Interconnectivity

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

87

IP Protocol Stack

88

Internet Architecture

Image source: (Wikipeida) GFDL

CASE 2013 - 6lowpan

Technology

Transcript of CASE 2013 - 6lowpan