6LoWPAN
6LoWPAN ist ein Akronym für „IPv6 over Low power Wireless Personal Area Network“ (engl.: IPv6 für WPAN mit niedrigem Energieverbrauch).[1] 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[2][3]. 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.[4]
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.[4]
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).[5] Nach jetzigem Stand sind Messungen mit Genauigkeiten im Zentimeter- bis Millimeterbereich möglich.[6]
Diese Entwicklung wird sehr wahrscheinlich auch die zukünftigen Routing-Protokolle beeinflussen.
Ein Chip mit dieser Funktion ist zum Beispiel der AT86RF233[7] von Atmel, die Forschung auf diesem Gebiet wird aber von allen Herstellern vorangetrieben.[6]
Implementierungen
Im Bereich Open-Source:
- 6LoWPAN-Implementierung in Linux[8]
- 6LoWPAN-Implementierung in Contiki[9]
- BLIP: 6LoWPAN-Implementierung in TinyOS[10]
- 6LoWPAN-Implementierung in RIOT[11]
Als proprietäre Implementierungen:
- NanoStack und NanoRouter von Sensinode[12]
Siehe auch
- RPL – Routingprotokoll, das für 6LoWPAN konzipiert wurde.
Weblinks
- IPv6 over Low power WPAN (6lowpan) (Memento vom 1. Juni 2009 im Internet Archive)
- 6lowpan.tzi.org
Einzelnachweise
- In 6LoWPAN: The Wireless Embedded Internet (Wiley, 2009), Shelby and Bormann redefine the 6LoWPAN acronym as „IPv6 over lowpower wireless area networks,“ arguing that „Personal“ is no longer relevant to the technology.
- Ludovici, A.; Calveras, A.; Casademont, J. Forwarding Techniques for IP Fragmented Packets in a Real 6LoWPAN Network. Sensors 2011, 11, 992-1008. http://www.mdpi.com/1424-8220/11/1/992
- Andreas Weigel, Martin Ringwelski, Volker Turau and Andreas Timm-Giel. Route-Over Forwarding Techniques in a 6LoWPAN. In Proceedings of the 5th International Conference on Mobile Networks and Management (MONAMI'13), September 2013. Cork, Irland. http://link.springer.com/chapter/10.1007%2F978-3-319-04277-0_10
- Route-over vs mesh-under routing in 6LoWPAN
- – RF ranging for location awareness
- Distanzmessung über RF
- AT86RF233
- 6lowpan – Linux-Kernel
- Contiki-OS
- http://www.ece.iisc.ernet.in/6panview/wp-content/uploads/2010/11/website_techdocs/blip_implementation.pdf@1@2Vorlage:Toter+Link/www.ece.iisc.ernet.in (Seite+nicht+mehr+abrufbar,+Suche+in+Webarchiven)+ (Link nicht abrufbar)
- RIOT-OS
- Sensinode’s 6LoWPAN-Implementierungen (Memento vom 13. August 2014 im Internet Archive)