6LoWPAN

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von 6lowpan)
Zur Navigation springen Zur Suche springen

6LoWPAN ist ein Akronym für „IPv6 over Low power Wireless Personal Area Network“ (englisch für: „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[2] festgehalten. Einige Probleme des 6LoWPAN sind im RFC 4919[3] 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[4] eine neue Methode eingeführt (IPHC) und die alte soll nicht mehr verwendet werden.

6LoWPAN-Adaption-Layer

[Bearbeiten | Quelltext bearbeiten]
6LoWPAN-Stack im OSI-Modell

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

[Bearbeiten | Quelltext bearbeiten]

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

[Bearbeiten | Quelltext bearbeiten]

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.[5][6] Da sich in dem ersten Fragment bereits der IP-Header befindet, sind damit bereits alle Informationen vorhanden, um eine Routingentscheidung zu treffen.

Mesh mit Internetanbindung (6LoWPAN-Gateway)

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.[7]

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

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[8]) verwendet.

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

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

Weiterentwicklungen Hardware

[Bearbeiten | Quelltext bearbeiten]

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).[9] Nach jetzigem Stand sind Messungen mit Genauigkeiten im Zentimeter- bis Millimeterbereich möglich.[10]

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

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

Implementierungen

[Bearbeiten | Quelltext bearbeiten]

Im Bereich Open-Source:

Als proprietäre Implementierungen:

  • NanoStack und NanoRouter von Sensinode[17]

Realisierte Beispielanwendungen:

  • Self-Powered MEMS-Based Wireless Sensor Node: MEMS-basierter energieautonomer kabelloser Sensorknoten[18]
  • MEMS-based piezoelectric energy harvesting modules for distributed automotive tire sensors[19]
  • Wireless-based energy autonomous tire pressure monitoring system[20]
  • RPL – Routingprotokoll, das für 6LoWPAN konzipiert wurde.

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. Wiley: 6LoWPAN: The Wireless Embedded Internet. eetimes.com, 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.
  2. RFC 4944 – Transmission of IPv6 Packets over IEEE 802.15.4 Networks. September 2007 (englisch).
  3. RFC 4919 – IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals. August 2007 (englisch).
  4. RFC 6282 – Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks. September 2011 (englisch).
  5. A. Ludovici, A. Calveras, J. Casademont: Forwarding Techniques for IP Fragmented Packets in a Real 6LoWPAN Network. In: Sensors, 2011, 11, S. 992–1008. mdpi.com
  6. Andreas Weigel, Martin Ringwelski, Volker Turau, 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. link.springer.com
  7. a b Route-over vs mesh-under routing in 6LoWPAN. dl.acm.org
  8. RFC 3561 – Ad hoc On-Demand Distance Vector (AODV) Routing. Juli 2003 (englisch).
  9. eecs.berkeley.edu (PDF; 4,0 MB) – RF ranging for location awareness
  10. a b rfranging.com (Memento vom 22. Mai 2014 im Internet Archive; PDF) Distanzmessung über RF
  11. atmel.com AT86RF233
  12. 6lowpan – Linux-Kernel
  13. 6lowpan options (for ipv6). In: Contiki-NG Documentation. Abgerufen am 17. Oktober 2023 (englisch).
  14. BLIP Tutorial. In: TinyOS Documentation Wiki. Stanford University, 24. Oktober 2011, abgerufen am 17. Oktober 2023 (englisch).
  15. RIOT-OS
  16. IEEE 802.15.4. In: Zephyr Project Documentation. Zephyr Project, a Linux Foundation Project, 22. August 2024, abgerufen am 22. August 2024 (englisch).
  17. Sensinode’s 6LoWPAN-Implementierungen (Memento vom 13. August 2014 im Internet Archive)
  18. T. Zimmermann, A. Frey, M. Schreiter, J. Seidel, I. Kühne: 5.1.4 MEMS-basierter energieautonomer kabelloser Sensorknoten. In: Tagungsband. AMA Service GmbH, Von-Münchhausen-Str. 49, 31515 Wunstorf, Germany, Nürnberg 2012, S. 522–530, doi:10.5162/sensoren2012/5.1.4.
  19. Thomas Zimmermann, Alexander Frey, Matthias Schreiter, Julian Seidel, Ingo Kuehne: MEMS-based piezoelectric energy harvesting modules for distributed automotive tire sensors. In: International Multi-Conference on Systems, Signals & Devices. März 2012, S. 1–4, doi:10.1109/SSD.2012.6198097.
  20. J. Warmuth, T. Zimmermann, M. Schreiter, A. Frey, I. Kuehne: C3.2 – Wireless-Based Energy Autonomous Tire Pressure Monitoring System. In: Proceedings Sensor 2013. AMA Service GmbH, Von-Münchhausen-Str. 49, 31515 Wunstorf, Germany, Nürnberg 2013, S. 384–388, doi:10.5162/sensor2013/C3.2.