6LoWPAN
# 6LoWPAN

6LoWPAN ist ein Akronym für „IPv6 over Low power Wireless Personal Area Network“ (englisch für: „IPv6 für WPAN mit niedrigem Energieverbrauch“). 6LoWPAN ist ein Kommunikationsprotokoll zur Funkdatenübertragung und eine Arbeitsgruppe der IETF, die für diesen Standard zuständig ist.

Der Standard umfasst dabei auch Header-Kompressionsverfahren, die es effizienter machen, IPv6-Pakete über IEEE-802.15.4-basierende Netzwerke zu übermitteln. Das Internet-Protokoll ist dabei Grundlage für die Netzstrukturen des Internets und für lokale Netze. 6LoWPAN verfolgt das Ziel, drahtlose PANs mit möglichst geringem Aufwand in bestehende Netze integrieren zu können.

Die Basisspezifikation des Protokolls, die von der 6LoWPAN-Arbeitsgruppe der IETF entwickelt wurde, ist im RFC 4944 festgehalten. Einige Probleme des 6LoWPAN sind im RFC 4919 aufgeführt. Da die Header-Komprimierung aus dem ursprünglichen Entwurf (HC1) nur in wenigen Fällen zu guten Ergebnissen führt, wurde in RFC 6282 eine neue Methode eingeführt (IPHC) und die alte soll nicht mehr verwendet werden.

## 6LoWPAN-Adaption-Layer

Die Hauptkomponente des 6LoWPAN-Protokolls ist der 6LoWPAN-Adaption-Layer, der auf der Vermittlungsebene des OSI-Modells arbeitet und Aufgaben wie Header-Komprimierung, Paket-Fragmentierung und -defragmentierung, sowie Routing in Mesh-Netzwerken übernimmt.

### Header-Komprimierung

Von den 127 Byte der Maximum Transmission Unit (MTU) werden 25 für den MAC-Layer verwendet. Durch einen optionalen weiteren Layer, der für AES-CCM-128 Verschlüsselung weitere 21 Byte belegt, bleiben nur 81 Byte für die darüber liegenden Layer. Der IPv6-Header benötigt 40 Byte, der UDP-Header weitere 8 Byte, wodurch für Nutzdaten nur noch 33 Byte zur Verfügung stehen. Durch die Komprimierung der IPv6- und UDP-Header von 6LoWPAN können diese beiden Header im Idealfall bis auf 7 Byte komprimiert werden.

Die Komprimierung der Adressen macht sich zu Nutze, dass sich eine Adresse in IPv6 im Idealfall aus einem 64-Bit-Präfix für das Subnetz und aus einem 64-Bit-Suffix identisch zur MAC-Adresse zusammensetzt. Wird ein Paket nur über einen Hop transportiert, sind also das Suffix der Zieladresse identisch zur Ziel-MAC-Adresse und das Suffix der Senderadresse identisch zur MAC-Adresse des Senders und können daher weggelassen werden. Werden Linklocal-Adressen verwendet, kann sogar das Präfix weggelassen werden. Weiterhin gibt es die Möglichkeit, Adressen über Kontexte zu komprimieren. Der Standard macht allerdings bisher keine Angaben, wie diese Kontexte ausgetauscht werden.

Weitere Komprimierungs-Möglichkeiten des Headers sind das Flow Label und die Traffic Class, die häufig auf 0 gelassen werden.

### Paket-Fragmentierung und -defragmentierung

IPv6 erfordert eine MTU von mindestens 1280 Bytes. IEEE 802.15.4 sieht jedoch nur eine Paketgröße von 127 Byte vor. Der 6LoWPAN-Adaption-Layer ermöglicht eine transparente Fragmentierung der IP-Pakete, so dass diesen virtuell eine größere MTU zur Verfügung steht.

Hier gibt es verschiedene Ansätze, wie mit fragmentierten Paketen beim Weiterleiten umgegangen wird. Der Standard beschreibt, dass ein Paket auf jedem Knoten wieder komplett empfangen und zusammengesetzt wird, bevor es an den nächsten Knoten weitergeleitet wird. Ein schnellerer Ansatz, der auch Speicher auf den Sensorknoten spart, ist das direkte Weiterleiten der Fragmente. Da sich in dem ersten Fragment bereits der IP-Header befindet, sind damit bereits alle Informationen vorhanden, um eine Routingentscheidung zu treffen.

### Routing

Bei Routing in dynamischen Vermaschten Netzen (Meshs) mit beweglichen Netzwerkknoten tauchen spezielle Probleme auf:

* Beweglichkeit der Knoten
* Erreichbarkeit der einzelnen Knoten über IPv6 oder IPv4
* potentiell große Anzahl von Knoten
* Knotenfluktuation (neu integrierte Knoten, Verlust von Knoten, verwaiste Knoten)

Traditionelle Routing-Protokolle wie RIP, OSPF, IGRP oder EIGRP sind deshalb für dynamische Vermaschte Netze nur eingeschränkt geeignet.

Für dynamische Meshs werden spezielle Routing-Protokolle entwickelt, die auf zwei grundsätzlichen Ansätzen basieren:

Mesh-Routing (mesh-under) und IP-Routing (route-over)

Welches Routing eingesetzt wird (mesh-under oder route-over) hängt unter anderem von den Anforderungen für die das Mesh konzipiert ist ab, beide Varianten haben Vor- und Nachteile.

Einer der verbreitetsten Algorithmen für Routing in Vermaschten Netzen ist der Distanzvektoralgorithmus.

**Mesh-Routing**

In 6LoWPAN wird bei Mesh-Routing vor die Fragmentierungs- und Komprimierungs-Header ein Mesh-Header gesetzt, der die Start- und Ziel-ID der Knoten sowie die Anzahl der übrigen Sprünge enthält. Diese Form des Routings wird mesh-under genannt.

Die Start- und Ziel-ID der Knoten ist bei mesh-under keine IP-Adresse, sondern beispielsweise die MAC-Adresse der einzelnen Knoten. Für die Identifizierung der Knoten beim Routing werden Informationen (MAC-Adresse) aus der Data Link Layer und damit dem Bereich der Netzwerktechnologie (IEEE 802.15.4) verwendet.

Viele der mesh-under-Protokolle in IEEE 802.15.4 verwenden Varianten des Distanzvektoralgorithmus. In 6LoWPAN wird im 6LoWPAN Ad hoc Routing Protocol (LOAD) eine vereinfachte Form des AODV-Protokolls (RFC 3561) verwendet.

Weitere 6LoWPAN-spezifische Mesh-Routing-Protokolle sind DYMO (Dynamisches MANET On Demand) und HiLow (hierarchisches Routingprotokoll für 6LoWPAN).

**IP-Routing**

Ein Routing auf IP-Basis (Network Layer) wird route-over (IP) genannt. RPL ist ein 6LoWPAN-spezifisches Route-over-Protokoll.

**Weiterentwicklungen Hardware**

Ein Fokus der Entwicklung von Transceiver-Chips für IEEE 802.15.4 ist zurzeit (05/2014) die Distanzermittlung zwischen zwei Transceiver-Einheiten über die Messung der Signallaufzeit (RF ranging). Nach jetzigem Stand sind Messungen mit Genauigkeiten im Zentimeter- bis Millimeterbereich möglich.

Diese Entwicklung wird sehr wahrscheinlich auch die zukünftigen Routing-Protokolle beeinflussen.

Ein Chip mit dieser Funktion ist zum Beispiel der AT86RF233 von Atmel, die Forschung auf diesem Gebiet wird aber von allen Herstellern vorangetrieben.

## Implementierungen

Im Bereich Open-Source:

* 6LoWPAN-Implementierung in Linux
* 6LoWPAN-Implementierung in Contiki
* BLIP: 6LoWPAN-Implementierung in TinyOS
* 6LoWPAN-Implementierung in RIOT

Als proprietäre Implementierungen:

* NanoStack und NanoRouter von Sensinode

Realisierte Beispielanwendungen:

* Self-Powered MEMS-Based Wireless Sensor Node: MEMS-basierter energieautonomer kabelloser Sensorknoten
* MEMS-based piezoelectric energy harvesting modules for distributed automotive tire sensors
* Wireless-based energy autonomous tire pressure monitoring system
