imported>SchlurcherBot: Bot: http → https

2025-10-08T20:12:01Z

Bot: http → https

Neue Seite

'''6LoWPAN''' ist ein [[Akronym]] für „[[IPv6]] over Low power [[Wireless Personal Area Network]]“ ({{enS}} für: „IPv6 für WPAN mit niedrigem Energieverbrauch“).<ref>Wiley: [http://www.eetimes.com/design/embedded-internet-design/4216240/6LoWPAN--The-wireless-embedded-Internet---Part-1--Why-6LoWPAN-?pageNumber=0 ''6LoWPAN: The Wireless Embedded Internet''.] eetimes.com, 2009 {{" |Sprache=en |Text=Shelby and Bormann redefine the 6LoWPAN acronym as ‘IPv6 over lowpower wireless area networks’, arguing that ‘Personal’ is no longer relevant to the technology.}}</ref> 6LoWPAN ist ein Kommunikationsprotokoll zur Funkdatenübertragung und eine Arbeitsgruppe der [[Internet Engineering Task Force|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|IEEE-802.15.4]]-basierende Netzwerke zu übermitteln. Das [[Internet Protocol|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 <nowiki>RFC 4944</nowiki><ref>{{RFC-Internet |RFC=4944 |Titel=Transmission of IPv6 Packets over IEEE 802.15.4 Networks |Datum=2007-09}}</ref> festgehalten. Einige Probleme des 6LoWPAN sind im <nowiki>RFC 4919</nowiki><ref>{{RFC-Internet |RFC=4919 |Titel=IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals |Datum=2007-08}}</ref> aufgeführt. Da die Header-Komprimierung aus dem ursprünglichen Entwurf (HC1) nur in wenigen Fällen zu guten Ergebnissen führt, wurde in <nowiki>RFC 6282</nowiki><ref>{{RFC-Internet |RFC=6282 |Titel=Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks |Datum=2011-09}}</ref> eine neue Methode eingeführt (IPHC) und die alte soll nicht mehr verwendet werden.

== 6LoWPAN-Adaption-Layer ==
[[Datei:6LoWPAN stack.jpeg|mini|hochkant=1.5|6LoWPAN-Stack im [[OSI-Modell]]]]
Die Hauptkomponente des 6LoWPAN-Protokolls ist der ''6LoWPAN-Adaption-Layer'', der auf der [[OSI-Modell#Schicht 3 – Vermittlungsschicht (Network Layer)|Vermittlungsebene]] des [[OSI-Modell]]s arbeitet und Aufgaben wie ''[[Datenkompression|Header-Komprimierung]]'', ''[[IP-Fragmentierung|Paket-Fragmentierung und -defragmentierung]]'', sowie ''[[Routing]]'' in [[Vermaschtes Netz|Mesh]]-Netzwerken übernimmt.

=== Header-Komprimierung ===
Von den 127 Byte der [[Maximum Transmission Unit]] (MTU) werden 25 für den [[Media Access Control|MAC]]-Layer verwendet. Durch einen optionalen weiteren Layer, der für [[Advanced Encryption Standard|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 [[User Datagram Protocol|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 [[Maximum Transmission Unit|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.<ref>A. Ludovici, A. Calveras, J. Casademont: ''Forwarding Techniques for IP Fragmented Packets in a Real 6LoWPAN Network''. In: ''Sensors'', 2011, 11, S. 992–1008. [http://www.mdpi.com/1424-8220/11/1/992 mdpi.com]</ref><ref>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. [https://link.springer.com/chapter/10.1007%2F978-3-319-04277-0_10 link.springer.com]</ref> Da sich in dem ersten Fragment bereits der IP-Header befindet, sind damit bereits alle Informationen vorhanden, um eine Routingentscheidung zu treffen.

=== Routing ===
[[Datei:Freifunk mesh cloud.png|mini|hochkant=1.5|[[Vermaschtes Netz|Mesh]] mit Internetanbindung (6LoWPAN-[[Gateway (Informatik)|Gateway)]] ]]
Bei Routing in dynamischen [[Vermaschtes Netz|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 [[Routing Information Protocol|RIP]], [[Open Shortest Path First|OSPF]], [[Interior Gateway Routing Protocol|IGRP]] oder [[Enhanced Interior Gateway Routing Protocol|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.<ref name="romu">[http://dl.acm.org/citation.cfm?id=1582643 Route-over vs mesh-under routing in 6LoWPAN.] dl.acm.org</ref>

Einer der verbreitetsten [[Algorithmus|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 [[Media Access Control|MAC-Adresse]] der einzelnen Knoten. Für die Identifizierung der Knoten beim Routing werden Informationen (MAC-Adresse) aus der [[OSI-Modell#Schicht 2 – Sicherungsschicht (Data Link Layer)|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 [[Ad-hoc On-demand Distance Vector|AODV]]-Protokolls (<nowiki>RFC 3561</nowiki><ref>{{RFC-Internet |RFC=3561 |Titel=Ad hoc On-Demand Distance Vector (AODV) Routing |Datum=2003-07}}</ref>) verwendet.

Weitere 6LoWPAN-spezifische Mesh-Routing-Protokolle sind ''DYMO'' (Dynamisches [[Ad-hoc-Netz|MANET]] On Demand) und ''HiLow'' (hierarchisches Routingprotokoll für 6LoWPAN).

==== IP-Routing ====
Ein Routing auf IP-Basis ([[OSI-Modell#Schicht 3 – Vermittlungsschicht (Network Layer)|Network Layer]]) wird ''route-over (IP)'' genannt. [[Routing Protocol for Low power and Lossy Networks|RPL]] ist ein 6LoWPAN-spezifisches ''Route-over''-Protokoll.<ref name="romu" />

==== 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 [[Laufzeit (Elektrotechnik)|Signallaufzeit]] (''RF ranging'').<ref>[http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-69.pdf eecs.berkeley.edu] (PDF; 4,0 MB) – RF ranging for location awareness</ref> Nach jetzigem Stand sind Messungen mit Genauigkeiten im Zentimeter- bis Millimeterbereich möglich.<ref name="rf">{{Webarchiv |url=http://www.rfranging.com/wp-content/uploads/2013/06/RFRB0413-Datasheet-v130620.pdf |text=rfranging.com |format=PDF |wayback=20140522162835 |archiv-bot=}} Distanzmessung über RF</ref>

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

Ein Chip mit dieser Funktion ist zum Beispiel der AT86RF233<ref>[http://www.atmel.com/devices/AT86RF233.aspx atmel.com] AT86RF233</ref> von Atmel, die Forschung auf diesem Gebiet wird aber von allen Herstellern vorangetrieben.<ref name="rf" />

== Implementierungen ==
Im Bereich Open-Source:

* 6LoWPAN-Implementierung in [[Linux]]<ref>[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/6lowpan 6lowpan] – Linux-Kernel</ref>
* 6LoWPAN-Implementierung in [[Contiki]]<ref>{{Internetquelle |url=https://docs.contiki-ng.org/en/master/_api/group__uipoptsics.html |titel=6lowpan options (for ipv6) |werk=Contiki-NG Documentation|abruf=2023-10-17 |sprache=en}}</ref>
* BLIP: 6LoWPAN-Implementierung in [[TinyOS]]<ref>{{Internetquelle |url=http://tinyos.stanford.edu/tinyos-wiki/index.php/BLIP_Tutorial |titel=BLIP Tutorial |werk=TinyOS Documentation Wiki |hrsg=Stanford University |datum=2011-10-24 |abruf=2023-10-17 |sprache=en}} </ref>
* 6LoWPAN-Implementierung in [[RIOT (Betriebssystem)|RIOT]]<ref>[http://www.riot-os.org/#features RIOT-OS]</ref>
* 6LoWPAN (Thread, native IEEE 802.15.4) im [[Zephyr (Betriebssystem)| Zephyr RTOS]]<ref>{{Internetquelle |url=https://docs.zephyrproject.org/latest/connectivity/networking/api/ieee802154.html |titel=IEEE 802.15.4 |werk=Zephyr Project Documentation |hrsg=Zephyr Project, a Linux Foundation Project |datum=2024-08-22 |abruf=2024-08-22 |sprache=en}}</ref>

Als [[Proprietäre Software|proprietäre Implementierungen]]:

* NanoStack und NanoRouter von Sensinode<ref>{{Webarchiv |url=http://www.sensinode.com/EN/products.html |text=Sensinode’s 6LoWPAN-Implementierungen |wayback=20140813113534}}</ref>
Realisierte Beispielanwendungen:
* Self-Powered MEMS-Based Wireless Sensor Node: MEMS-basierter energieautonomer kabelloser Sensorknoten<ref>{{Literatur |Autor=T. Zimmermann, A. Frey, M. Schreiter, J. Seidel, I. Kühne |Titel=5.1.4 MEMS-basierter energieautonomer kabelloser Sensorknoten |Sammelwerk=Tagungsband |Verlag=AMA Service GmbH, Von-Münchhausen-Str. 49, 31515 Wunstorf, Germany |Ort=Nürnberg |Datum=2012 |Seiten=522–530 |DOI=10.5162/sensoren2012/5.1.4}}</ref>
* MEMS-based piezoelectric energy harvesting modules for distributed automotive tire sensors<ref>{{Literatur |Autor=Thomas Zimmermann, Alexander Frey, Matthias Schreiter, Julian Seidel, Ingo Kuehne |Titel=MEMS-based piezoelectric energy harvesting modules for distributed automotive tire sensors |Sammelwerk=International Multi-Conference on Systems, Signals & Devices |Datum=2012-03 |Seiten=1–4 |DOI=10.1109/SSD.2012.6198097}}</ref>
* Wireless-based energy autonomous tire pressure monitoring system<ref>{{Literatur |Autor=J. Warmuth, T. Zimmermann, M. Schreiter, A. Frey, I. Kuehne |Titel=C3.2 – Wireless-Based Energy Autonomous Tire Pressure Monitoring System |Sammelwerk=Proceedings Sensor 2013 |Verlag=AMA Service GmbH, Von-Münchhausen-Str. 49, 31515 Wunstorf, Germany |Ort=Nürnberg |Datum=2013 |Seiten=384–388 |DOI=10.5162/sensor2013/C3.2}}</ref>

== Siehe auch ==
* [[Routing Protocol for Low power and Lossy Networks|RPL]] – Routingprotokoll, das für 6LoWPAN konzipiert wurde.

== Weblinks ==
* {{Webarchiv |url=http://www.ietf.org:80/html.charters/6lowpan-charter.html |text=IPv6 over Low power WPAN (6lowpan) |wayback=20090601205048}} [[Internet Engineering Task Force|IETF]]
* [http://6lowpan.tzi.org/ 6lowpan.tzi.org]

== Einzelnachweise ==
<references />

{{SORTIERUNG:#:6LoWPAN}}
[[Kategorie:Kommunikationsprotokoll (Funktechnik)]]
[[Kategorie:Internet Protocol]]

6LoWPAN - Versionsgeschichte

imported>SchlurcherBot: Bot: http → https