See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/319205134

6LoWPAN – IPv6 over Low power Wireless Personal Area Network

Chapter · June 2017

CITATION READS

1 1,100

1 author:

Anatol Badach
University of Applied Sciences Fulda
247 PUBLICATIONS 115 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Voice over IP View project

Internet of Things – Technologies, Protocols and Applications View project

All content following this page was uploaded by Anatol Badach on 21 August 2017.

The user has requested enhancement of the downloaded file.

 6
► 6LoWPAN

6LoWPAN
IPv6 over Low-Power WPAN
Autor: Prof. Dr.-Ing. Unsere reale Welt wird immer enger mit dem Internet verknüpft. An
Anatol Badach dieses werden heutzutage bereits nicht nur Rechner verschiedener
Art angeschlossen, sondern zunehmend auch aus unterschiedlichen
intelligenten Geräten/Einrichtungen (z.B. Kühl-, Heizungsaggrega-
ten, Beleuchtungsanlagen usw.) bestehende drahtlose Netze. Da die
intelligenten Geräte in solchen Netzen als Smart Objects bezeichnet
werden, spricht man z.B. bei einer Vernetzung dieser Smart Objects
in einem Haus von Smart Home und bei einer Vernetzung von Smart
Objects innerhalb einer Stadt von Smart City. Da Smart Objects
zwecks ihrer Steuerung und Überwachung diverse Sensoren und
Aktoren enthalten, führt die Anbindung der intelligenten Objekte
und deren Vernetzungen an das klassische Internet zu einer besonde-
ren Erweiterung dieses Netzes. Diese Erweiterung des Internets um
Auszug aus dem Werk: vernetzte Strukturen diverser Smart Objects heißt Internet of Things
(IoT) bzw. auf Deutsch Internet der Dinge.

Die Kommunikation zwischen vernetzten Smart Objects, de facto

zwischen den in diesen Objects enthaltenen Sensoren und Aktoren,
erfolgt über drahtlose Netze, weshalb man auch von Sensor-Aktor-
Netzen (Sensor Actuator Networks) spricht. Weil Sensoren in der
Regel ihre Energie aus winzigen Batterien oder Solarzellen bezie-
hen, zeichnen sich die drahtlosen Sensor-Aktor-Netze u.a. durch
einen äußerst geringen Stromverbrauch, niedrige Bitraten und kurze
Reichweiten aus. Diese drahtlosen Netze werden häufig als sog. LR-
WPANs (Low-Rate Wireless Personal Area Networks) nach dem
Herausgeber: Dipl.-Ing.
Standard 802.15.4 des Institute of Electrical and Electronics Engi-
Heinz Schulte
neers (IEEE) installiert. In ihnen wird das Internet Protocol Version
6 (IPv6) als Kommunikationsprotokoll auf dem Network Layer
eingesetzt.

Der Standard IEEE 802.15.4 stellt spezielle Anforderungen, die in

drahtlosen Sensor-Aktor-Netzen mit sog. energiearmen Komponen-
ten eingehalten werden müssen. Insbesondere darf die maximale
Länge der in LR-WPANs übermittelten sog. MAC Data Frames mit
den in ihnen eingekapselten IPv6-Paketen nur 127 Byte betragen. Im
IPv6-Standard werden aber IPv6-Pakete bis zur Länge von 1280
WEKA-Verlag
Byte zugelassen. Aus diesem Grund müssen die IPv6-Pakete für die
ISBN 978-3-8276-9142-2

1 1
6
► 6LoWPAN

Übermittlung in energiearmen und mit Datenverlust behafteten

WPANs hinsichtlich ihrer Länge entsprechend angepasst und auch
komprimiert werden. Diese unabdingbare Adaption des Protokolls
IPv6 an die Anforderungen solcher WPANs bezeichnet man als IPv6
over Low-Power WPAN, kurz 6LoWPAN.

Die technischen Entwicklungen im Hinblick auf 6LoWPAN werden IETF-

bei der Internet Engineering Task Force (IETF) von der Working Standards
Group 6lo1 koordiniert. Die bisherigen 6LoWPAN-betreffenden
Entwicklungen wurden bereits in zahlreichen als RFCs von der
IETF veröffentlichten Internet Standards bzw. Internet Drafts doku-
mentiert; eine Auflistung dieser findet sich am Ende des Beitrags.

Dieser Beitrag erläutert zuerst die vonseiten 6LoWPAN an das IPv6 Schwerpunkte
gestellten Anforderungen. Anschließend geht er auf die Bedeutung dieses Beitrags
der Adaption von IPv6 für den Einsatz im IoT ein und präsentiert
das Verfahren zur Komprimierung sowohl des IPv6-Header als auch
des UDP-Header2. Darüber hinaus wird u.a. das Prinzip der Multi-
hop Communication in WPANs dargestellt und die Möglichkeiten
der Fragmentierung (im Folgenden engl. Fragmentation) von langen
IPv6-Paketen gezeigt.

Topologien von LR-WPANs

Die wesentlichen Konzepte von LR-WPANs wurden bereits zu
Beginn der 2000er-Jahre entwickelt. Der erste Standard IEEE
802.15.4 mit der Spezifikation von LR-WPANs wurde im Jahr 2003
veröffentlicht; daraufhin folgten erweiterte Ausgaben des Standards
in den Jahren 2006, 2011 und 2015. Für den Aufbau von LR-
WPANs werden zwei grundlegende Topologien definiert: die Stern-
topologie (Star Topology) und die Peer-to-Peer-Topologie (P2P-
Topology). Bild 008201 illustriert diese Topologien.

In der Sterntopologie können die einzelnen, als Devices bezeichne- Sterntopologie

ten Knoten, de facto Smart Objects, nur über einen WPAN-

1
IPv6 over Networks of Resource-constrained Nodes
2
UDP: User Datagram Protocol
 6
► 6LoWPAN

Koordinator (WPAN Coordinator) untereinander kommunizieren.

Die Sterntopologie eignet sich deshalb hauptsächlich für räumlich
begrenzte Anwendungen, wie z.B. Smart Homes.

Bild 008201: Grundlegende Topologien von LR-WPANs und deren

Anbindung an das Internet
PAN-ID: Personal Area Network Identifier

P2P-Toplogie Eine P2P-Toplogie als WPAN repräsentiert eine Gruppe von Knoten
mit einem WPAN-Koordinator, in der die einzelnen Devices als
mobile Knoten aber auch untereinander paarweise kommunizieren
können. Dazu muss jeder Knoten aber in Funkreichweite des Koor-
dinators liegen. Folglich ist die P2P-Toplogie ebenfalls nur für
räumlich begrenzte Netzwerke geeignet. Diese können als sog. Ad-
hoc-Netzwerke sogar spontan eingerichtet werden.

Cluster Tree WPAN Um mit WPANs eine größere Reichweite (z.B. innerhalb einer
Stadt) einrichten zu können, müssen, wie Bild 008201 zeigt, mehre-
re WPANs mit P2P-Topologie so „kaskadiert“ werden, dass eine
quasi baumförmige Vernetzungsstruktur von WPANs entsteht, die
als Cluster Tree WPAN (CT WPAN) bezeichnet wird. In diesem
Zusammenhang spricht man auch von einer Mesh-WPAN-Topologie
bzw. von einem Mesh WPAN. In einem WPAN mit einer Mesh-
Topologie kann die Kommunikation zwischen zwei nicht direkt
erreichbaren Knoten (Devices) über andere Devices verlaufen, die
als Zwischenknoten (Transit Devices) fungieren. Diese Form der

3 3
6
► 6LoWPAN

Kommunikationsabwicklung in WPANs nennt man Multi-hop

Communication (Bild 008215). Um sie technisch zu realisieren, wird
bei 6LoWPAN mit dem Mesh Header ein spezieller Header einge-
führt, auf den im Weiteren eingegangen wird.

Die Multi-hop Communication in einem Mesh WPAN entlang einer Multi-hop

Route verläuft in der Regel über mehrere WPANs. Zu ihrer Kenn- im Mesh WPAN
zeichnung werden ihnen entsprechende Identifikatoren (PAN-IDs)
zugewiesen. Diese PAN-IDs (Bild 008201) ermöglichen es unter
anderem, über mehrere WPANs verlaufenden Routen zu ermitteln
und zu beschreiben.

Hierfür ist ein entsprechend befähigtes Routingprotokoll nötig. Zum Routingprotokoll

Einsatz kommt das für Low-Power and Lossy Networks (LLN) – RPL
also Netze mit relativ hohen Datenverlusten und -fehlerraten – im
RFC 6550 spezifizierte IPv6 Routing Protocol for Low-Power and
Lossy Networks (RPL), vgl. Bild 008202.

Wie das obige Bild zum Ausdruck bringt, ist in jeder WPAN-
WPAN-
Topologie für die Koordination des Zugriffs von Devices (Knoten)
Koordinator
auf den gemeinsamen Funkkanal ein spezieller Netzknoten als
WPAN-Koordinator zuständig.

Man unterscheidet dabei zwischen zwei Arten von Devices: Devices

 FFD – Full Function Device
Diese fungieren als Knoten in einem WPAN und können Daten-
pakete empfangen, senden und an jeden anderen Knoten im glei-
chen WPAN weiterleiten. Dadurch können sie als WPAN-
Koordinatoren, Sensoren/Aktoren, Router und Gateways einge-
setzt werden. Aufgrund ihrer Funktionalität müssen sie immer
aktiv sein, können also nicht in den sog. Schlafmodus wechseln,
um den Stromverbrauch zu reduzieren, und benötigen aus die-
sem Grund meist eine ständige Stromversorgung.
 RFD – Reduced Function Device
Diese dienen als einfache Sensoren und Aktoren, welche ledig-
lich Datenpakete empfangen und senden können. Ein RFD kann
mit einem FFD kommunizieren. In einer Sterntopologie ist dies
nicht direkt und nur über einen WPAN-Koordinator möglich, in
der P2P-Topologie dagegen direkt mit einem als Parent bezeich-
neten Knoten. Aufgrund der „beschränkten“ Funktionalität kön-
nen RFDs ihre zum Betrieb benötigte Energie sogar aus winzi-
 6
► 6LoWPAN

gen Batterien bzw. Solarzellen beziehen. Einige RFDs können

auch in den Schlafmodus versetzt werden; man spricht in diesem
Zusammenhang von schlafenden Knoten. Diese Schlafphasen
werden unterbrochen (Wecken) durch das regelmäßige Versen-
den von Beacon Frames durch die WPAN-Koordinatoren.

Protokollstruktur von IoT-Devices

Bild 008202 zeigt die typische Protokollstruktur von IoT-Devices
(kurz Devices) in LR-WPANs. Wie hier ersichtlich ist, spezifiziert
der Standard IEEE 802.15.4 für LR-WPANs lediglich die untersten
zwei Layers in dieser Protokollarchitektur, d.h. den Physical Layer
(PHY) und den MAC-Layer.

Bild 008202: Typische Protokollstruktur von IoT-Devices in LR-

WPANs
c/ncUDP: compressed/not compressed User Datagram Protocol
CoAP: Constrained Application Protocol
ICMP: Internet Control Message Protocol
TCP: Transmission Control Protocol

Physical Layer In einem LR-WPAN wird von allen Devices (Knoten) ein gemein-
samer Funkkanal (Common Wireless Channel) auf dem Physical
Layer genutzt. Die kollisions- und störungsfreie Nutzung dieses
Kanals verlangt die Anwendung eines geordneten Zugriffsverfahrens
(Access Method), an das sich alle Devices halten. Hierzu wurden
zwei Verfahren auf der Grundlage des bekannten CSMA/CA (Car-
rier Sense Multiple Access/(with) Collision Avoidance) spezifiziert:
 Slotted CSMA/CA in LR-WPANs mit Sterntopologie und

5 5
6
► 6LoWPAN

 Unslotted CSMA/CA in LR-WPANs mit P2P-Topologie.

Bei Slotted CSMA/CA realisiert man das Beacon-Konzept, bei
Unslotted CSMA/CA hingegen nicht. Deshalb bezeichnet man LR-
WPANs mit Slotted CSMA/CA als Beacon-enabled PANs und LR-
WPANs mit Unslotted CSMA/CA dementsprechend als Non-
Beacon-enabled PANs.

Auf dem MAC-Layer, auch als Link Layer (LL) bezeichnet, spezifi- MAC-Layer
ziert der Standard MAC Frames, die der Übermittlung komprimier-
ter IPv6-Pakete dienen. Auf den Aufbau dieser Frames wird im
Weiteren detaillierter eingegangen (Bild 008206).

Der Network Layer in der Protokollstruktur von Devices wird von Network Layer
6LoWPAN erbracht und kann als IPv6 Adaptation Layer angesehen (6LoWPAN)
werden. Mit 6LoWPAN wird der Header des Protokolls IPv6 kom-
primiert und an die Besonderheiten von LR-WPANs angepasst. Wie
im Weiteren gezeigt (Bilder 008204 und 008205), hat der IPv6
Adaptation Layer, also 6LoWPAN, eine dynamische und hierar-
chisch organisierte Struktur. Diese kann auf mehrere Sublayer, wie
z.B. Multi-hop Communication, Fragmentation, IPv6-Header Com-
pression, von denen einige optional sind, aufgeteilt werden.

Auf dem Transport Layer (TL) im IoT kommt als Transportprotokoll Transport
hauptsächlich das verbindungslos arbeitende User Datagram Proto- Layer
col (UDP) zum Einsatz, wobei auch dessen Header komprimiert
werden kann. Folglich unterscheidet man zwischen
 compressed UDP (cUDP) und
 non-compressed UDP (ncUDP).
6LoWPAN ermöglicht außerdem den Einsatz des verbindungsorien-
tiert arbeitenden Transportprotokolls Transmission Control Protocol
(TCP) und des Internet Control Message Protocol (ICMP). Auf dem
Transport Layer spielt ICMP eine besonders wichtige Rolle. Mit
seiner Hilfe können andere Protokolle zwecks Management und
Routing im IoT, als eine Art ICMP-Variante, „generiert“ werden.
Ein Beispiel dafür ist das bereits oben erwähnte Routingprotokoll
(RPL).

Auf den Transport Layer folgt im IoT der Application Support Application Support
Layer mit den Application Support Protocols, wie z.B. dem im Layer
 6
► 6LoWPAN

RFC 7252 spezifizierten Constrained Application Protocol (CoAP).

Beim CoAP handelt es sich um ein speziell für die Datenübermitt-

lung im Device Management des IoT entwickeltes, HTTP-ähnliches
Supportprotokoll. Als CoAP-Payload werden die Daten für das
Device Management sowohl im klassischen binären Format als auch
in einem neuen als Concise Binary Object Representation (CBOR)3
bezeichneten Format transportiert.

Application Layer Auf dem sechsten und letzten Layer der Protokollstruktur von IoT-
Devices in LR-WPAN bzw. 6LoWPAN, dem Application Layer
(AL), ist das Device Management für die verschiedenen Anwendun-
gen des IoT positioniert. Zu den typischen Anwendungsszenarien
des IoT zählen Machine-to-Machine (M2M) in der Produktion,
Smart City, Smart Environment, Smart Home, Smart Metering,
Smart Parking und Telemedizin (E-Health) – um nur einige zu nen-
nen.

Adressierung in Rechnern mit IPv6

Zum besseren Verständnis der Protokollarchitektur von Devices in
IoT („IoT Hosts“) wird zunächst kurz die in Bild 008203 gezeigte
Protokollarchitektur von Rechnern mit IPv6 im Internet erläutert.
Der Fokus liegt hierbei auf der Interpretation von MAC- und IP-
Adressen.

IPv6-Adresse Im Internet werden IP-Pakete zwischen weltweit eindeutigen IP-

Adressen von Rechnern übermittelt. Jeder Rechner am Internet
enthält hierfür einige Komponenten, u.a. eine Netzwerkadapterkarte
(NIC) und eine IP-Instanz, mit denen er die IP-Pakete generieren,
senden, empfangen und interpretieren kann. Der IP-Adresse eines
Rechners mit dem Protokoll IPv6, d.h. der IPv6-Adresse, kann ein
Speicherplatz an der Grenze zwischen dem Network Layer, der als
IPv6-Layer angesehen werden kann, und dem Transport Layer, der
de facto als Kommunikationspuffer dient, zugeordnet werden. Über
diesen Puffer können die Instanzen verschiedener Transportproto-
kolle logisch mit der IPv6-Instanz verbunden werden. Daher kann

3
CBOR wurde in RFC 7049 spezifiziert und basiert weitgehend auf dem
erfolgreichen Datenmodell JSON (JavaScript Object Notation).

7 7
6
► 6LoWPAN

eine IPv6-Adresse als „virtuelle Steckdose“ mit mehreren Pins ober-

halb der IPv6-Instanz dargestellt und als eine Art IPv6-Socket ange-
sehen werden.4

Bild 008203: Adressierungsschema in Rechnern mit IPv6 im Inter-

net
IP-H: IP-Header
NIC: Network Interface Card/Controller
TP: Transport Protocol
TP-H: Transport Protocol Header

Ein Pin in dieser Steckdose, also im IPv6-Socket, die anschaulich

eine IPv6-Adresse darstellt, symbolisiert die Angabe Next Header im
IPv6-Header, genauer gesagt die Nummer des Protokolls aus dem
Transport Layer. Über einen IPv6-Socket, als „virtuelle, mehrere
Pins enthaltende Steckdose“ im Rechner, können dann die Instanzen
verschiedener Transportprotokolle aus dem Transport Layer an die
IPv6-Instanz logisch angebunden werden.

Ein kommunikationsfähiger Rechner besitzt eine Netzwerkadapter- Netzwerka-

karte (Network Interface Card, NIC), über die er an das Netzwerk dapterkarte

4
Mit der Angabe IPv6 und MAC im „IPv6 Socket“ bzw. „MAC Socket“ soll
darauf hingewiesen werden, dass es sich um eine spezielle Art von Sockets
(als „Steckdosen“) auf dem IPv6 Layer bzw. auf dem MAC Layer handelt
und dass diese speziellen Socket-Arten von dem allgemeinen Begriff „So-
cket“ als Paar (IP Address, Port) zu unterscheiden sind.
 6
► 6LoWPAN

angeschlossen ist, und eine physikalische Adresse, die den physika-

lischen Anschlusspunkt des Rechners am Netzwerk angibt. So ent-
hält z.B. ein Rechner am LAN eine LAN-Adapterkarte, welche eine
MAC-Adresse besitzt. Mittels der MAC-Adresse wird der Rechner
im Netzwerk innerhalb eines IP-Subnetzes eindeutig identifiziert.

MAC-Adresse Die MAC-Adresse kann als „virtuelle Steckdose“ mit mehreren Pins
(„MAC Socket“) oberhalb der Adapterkarte dargestellt werden. Ein
Pin in dieser Steckdose repräsentiert die im Header EtherType (ET)
angegebene Nummer des Protokolls aus dem Network Layer (IPv6-
Layer), wie z.B. 0x0800 von IPv4 oder 0x86DD von IPv6. Logisch
betrachtet können die Instanzen mehrerer Protokolle aus dem Net-
work Layer (z.B. IPv4, IPv6) über eine MAC-Adresse als „virtuelle
Steckdose“ an die Adapterkarte angebunden werden.

Adressierung in IoT-Devices mit 6LoWPAN

Ein ähnliches, aber viel komplexeres Adressierungsschema findet
man in IoT-Devices mit 6LoWPAN. Bild 008203 stellt dieses dar.
Wie bereits erwähnt wurde, besitzt 6LoWPAN als Network Layer in
IoT-Devices eine dynamische und hierarchisch organisierte, aus
mehreren Sublayers bestehende Struktur (Bild 008205). Zwecks
einer anschaulichen Erläuterung der grundlegenden Idee von
6LoWPAN zeigt Bild 008204 eine vereinfachte Form dieser Struktur
und illustriert dabei sowohl die Hierarchie von zu 6LoWPAN gehö-
renden Funktionen als auch das Prinzip der IPv6-Adaption an die
Anforderungen von LR-WPANs.

Anmerkung: Es sei angemerkt, dass Bild 008204 nur den einfachsten Fall
zeigt, nämlich den, in dem nur der IPv6-Header und der UDP-Header kom-
primiert werden und folglich die zu den Sublayers 3 a und 3b gehörenden
6LoWPAN-Funktionen unnötig sind (vgl. hierzu Bild 008211d). Die voll-
ständige Struktur des 6LoWPAN-Layer wird in Bild 008205 erläutert.

Zu Bild 008204 ist weiterhin anzumerken, dass die Reihenfolge der

hier gezeigten Subbayers 3a, 3b, 3c, 3d und 3e im 6LoWPAN-Layer
mit der Reihenfolge von diesen Sublayers entsprechenden Headers
im compressed IPv6-Packet übereinstimmt. Da das Bild nur den
geschilderten einfachsten Fall illustriert, sind die den Sublayers 3a
und 3b entsprechenden Headers im gezeigten IPv6-Paket nicht ent-
halten.

9 9
6
► 6LoWPAN

Bild 008204: Adressierungsschema in IoT-Devices mit 6LoWPAN –

Struktur des IPv6 Adaptation Layer
cIPv6: compressed IPv6
cUDP: compressed UDP
FCS: Frame Checking Sequence
FHx: Fragment Header, x = 1, x = N (N = 2, 3, ...)
FRAGx: IPv6-Packet Fragment, x = 1, x = N (N = 2, 3, ...)
HC1: IPv6-Header Compression Scheme
HC2: UDP-Header Compression Scheme
MESH: Mesh Network (Multi-hop Communication)
PHY-H: Physical Layer Header
SHR: Synchronization Header

Vergleicht man die in den Bildern 008203 und 008204 dargestellten Feststellungen
Prinzipien der Adressierung in Internet-Hosts und in IoT-Devices,
stellt man Folgendes fest:
 MAC-Adressen als MAC Sockets
MAC-Adressen kann man sowohl in Internet-Hosts als auch in
IoT-Devices als virtuelle, mehrere Pins enthaltende Steckdosen
 6
► 6LoWPAN

oberhalb des MAC-Layer darstellen. Deshalb können MAC-

Adressen quasi als MAC Sockets angesehen werden.
 Pins in MAC Sockets
Diese stellen in Internet-Hosts die Angaben im Header Ether-
Type und in IoT-Devices die Angaben im direkt dem MAC-
Header folgenden Dispatch Header dar (Bild 008210). Demzu-
folge erfüllen die Headers EtherType und Dispatch Header ver-
gleichbare Aufgaben. In beiden wird angegeben, welche Funkti-
onen auf dem Network Layer, d.h. im Internet auf dem IPv6-
Layer und im IoT auf dem 6LoWPAN-Layer, bei der „Bearbei-
tung“ jedes empfangenen IPv6-Pakets realisiert werden müssen.
Anschaulich betrachtet ermöglichen die Pins in MAC Sockets
den Anschluss von verschiedenen Instanzen aus dem Network
Layer an den MAC-Layer.
 IPv6-Adressen als IPv6 Sockets
IPv6-Adressen können sowohl in Internet-Hosts als auch in IoT-
Devices – genau wie MAC-Adressen – als virtuelle, mehrere
Pins enthaltende Steckdosen oberhalb des IPv6-Layer dargestellt
werden.
 Pins in IPv6 Sockets
Diese repräsentieren sowohl in Internet-Hosts als auch in IoT-
Devices die Angabe Next Header (NH) im IPv6-Header. Mit NH
wird angegeben, welches Protokoll aus dem Transport Layer rea-
lisiert wird. Anschaulich betrachtet ermöglichen Pins in IPv6
Sockets den Anschluss von Protokollinstanzen aus dem Trans-
port Layer an die IPv6-Instanz innerhalb des Network Layer. In
IoT Devices mit 6LoWPAN ermöglichen Pins in IPv6 Sockets
den Anschluss von Protokollinstanzen aus dem Transport Layer
an die Instanz im Sublayer 3e, d.h. an die Instanz, die dem Pro-
tokoll „compressed IPv6“ entspricht.

Next Header (NH) Hierzu sei angemerkt, dass die Angabe NH im IPv6-Header beim
Einsatz von 6LoWPAN komprimiert werden kann. Der komprimier-
te Wert NH, in Bild 008204 als compressed NH Value (cHNV)
bezeichnet, wird im Header HC1, also auf dem Sublayer HC1, mit
zwei Bit x5x6 (Bild 008212) spezifiziert. Diese haben folgende Be-
deutung:

11 11
6
► 6LoWPAN

 x5x6 = 00 besagt, dass NH nicht komprimiert und vollständig

im IPv6-Header enthalten ist. Die Werte von NH werden ge-
mäß IPv6 interpretiert.
 x5x6 = 01, 10 oder 11 bedeutet, dass NH komprimiert ist. Auf
dem Transport Layer wird verwendet: UDP oder cUDP (com-
pressed UDP, d.h. UDP mit compressed Header) bei x5x6 = 01,
TCP bei x5x6 = 10 oder ICMP bei x5x6 = 11.
Es sei angemerkt, dass UDP zum Transportieren von CoAP- UDP und ICMP
Nachrichten verwendet wird, während einige Nachrichten des ICMP
dazu herangezogen werden können, das Routingprotokoll RPL zu
realisieren. Das RPL stellt folglich eine Art ICMP-Variante dar.

6LoWPAN als IPv6 Adaptation Layer

Nachdem im letzten Bild zwecks einer kurzen und anschaulichen
Erläuterung des Adressierungsschemas in IoT-Devices nur die all-
gemeine Struktur des 6LoWPAN-Layer vereinfacht dargestellt wur-
de, illustriert Bild 008205 nunmehr dessen vollständige Struktur in
Form eines aus den Sublayers 3a, 3b, 3c, 3d und 3e bestehenden Mo-
dells. Eine Besonderheit des hier gezeigten Modells besteht darin,
dass es sich auf zwei Kommunikationsarten bezieht:
 One-hop Communication
 Multi-hop Communication
Bevor auf die Unterschiede zwischen diesen Arten der Kommunika- Mesh Header
tion im Folgenden differenzierter eingegangen wird (Bild 008215),
sei hier nochmals angemerkt, dass der bereits bekannte Mesh Header
(MH) bei der Multi-hop Communication verwendet wird, um kom-
primierten IPv6-Paketen, also de facto IPv6-Paketen ohne IPv6-
Adressen, IPv6-Adressen vom Quell- und Ziel-Device voranstellen
zu können.

Unter One-hop Communication versteht man die Kommunikation One-hop

zwischen zwei direkt erreichbaren Devices innerhalb eines WPAN, Communica-
d.h. eine WPAN-interne Kommunikation. Dies würde im Internet tion
der Kommunikation innerhalb eines IP-Subnetzes entsprechen. Bei
dieser Kommunikationsart können die beiden kommunizierenden
Devices im IoT nur mittels ihrer MAC-Adressen eindeutig Identifi-
ziert werden. Darüber hinaus können aus ihren MAC-Adressen die
IPv6-Adressen von kommunizierenden – zum gleichen WPAN
 6
► 6LoWPAN

gehörenden – Devices abgeleitet werden (Bild 008208). Aus diesem

Grund ist bei der One-hop Communication die Übermittlung des
Mesh Header mit IPv6-Adressen unnötig und demzufolge ist der
Sublayer 3a (Multi-hop Communication/Forwarding) mit dem Mesh
Header in der Struktur vom 6LoWPAN-Layer für One-hop Commu-
nication nicht enthalten.

Bild 008205: Struktur von 6LoWPAN als IPv6 Adaptation Layer in

IoT- Devices mit IEEE 802.15.4 Interfaces
Multi-hop Communi- Die Kommunikation zwischen Devices, die zu verschiedenen
cation WPLANs gehören, muss oft über mehrere Transit Devices verlaufen
– also quasi in mehreren Hops (Sprüngen). Folglich spricht man von
Multi-hop Communication. Diese Art der Kommunikation würde im
Internet der Kommunikation zwischen Hosts an verschiedenen IP-
Subnetzen entsprechen. Bei der Multi-hop Communication können
die beiden kommunizierenden Devices im IoT – aufgrund der zwei-
stufigen Adressierung (Bild 008207) – nur durch ihre IPv6-Adressen

13 13
6
► 6LoWPAN

eindeutig identifiziert werden. Deshalb ist hier eine Übermittlung

des Mesh Header mit den erforderlichen IPv6-Adressen notwendig.
Demzufolge ist der Sublayer 3a mit dem Mesh Header in der Struk-
tur vom 6LoWPAN-Layer für Multi-hop Communication enthalten.

Es kommt vor, dass im Internet ein langes IPv6-Paket in mehrere Packet Frag-
kleinere IPv6-Pakete aufgeteilt werden muss. Man bezeichnet diesen mentation
Vorgang als Fragmentation (IPv6 Packet Fragmentation). Diese ist
bei langen IPv6-Paketen auch im IoT nötig. Um diese bei
6LoWPAN zu ermöglichen, wurde der Sublayer 3b (Fragmentation)
vorgesehen; im Weiteren wird darauf noch detaillierter eingegangen.

Zu den Sublayern 3a und 3b, also Multi-hop Forwarding und Frag- Hierarchie der
mentation, sei angemerkt, dass diese beiden Sublayer eine zweistufi- Sublayers
ge Hierarchie besitzen, denn sowohl im Sublayer 3a nach dem Mesh
Header als auch im Sublayer 3b nach den Fragment Headers (FH1
und FHN) kommt jeweils ein Dispatcher Header (DH), und zwar der
gleiche DH wie auf dem Sublayer 2b. Dies wurde in Bild 008205
durch die Bezeichnungen 3a,1 (Mesh Header), 3a,2 (DH) und 3b,1
(FH1/FHN) sowie 3b,2 (DH) entsprechend zum Ausdruck gebracht.

Frames in IEEE 802.15.5 Low Rate WPANs

Wie bereits erwähnt und in Bild 008202 dargestellt wurde, spezifi-
ziert lEEE 802.15.4 in der Protokollarchitektur von IoT-Devices
lediglich die untersten zwei Layers, d.h. Physical Layer (PHY) und
MAC-Layer. Bild 008206 zeigt den Aufbau der auf ihnen eingesetz-
ten Frames und beschreibt ihre zugehörigen Header.

Aus demselben Bild lässt sich entnehmen, dass die maximale Länge Maximale
der PHY-Payload, d.h. die maximale Länge von MAC Data Frames Paketlänge
mit den in ihnen eingekapselten IPv6-Paketen als deren Nutzlast
(MAC-Payload), auf 127 Byte begrenzt ist. Daraus resultiert, dass
die Länge der IPv6-Pakete als MAC-Payload im „günstigsten“ Fall,
also wenn weder ein sog. Information Element (IE) noch ein Auxili-
ary Security Header (ASH) für Security Support enthalten ist, maxi-
mal 102 Byte betragen darf. Von diesen bräuchte man allein für den
unkomprimierten IPv6-Header 40 Byte und für den unkomprimier-
ten UDP-Header 8 Byte. Für den Transport von Daten in IPv6-
Paketen als UDP-Payload verblieben somit nur 102 minus (40+8) =
 6
► 6LoWPAN

52 Byte. Demzufolge ist die Komprimierung von Overhead in IPv6-

Paketen, also des IPv6- und des UDP-Header, absolut unabdingbar.

Bild 008206: Aufbau von MAC Data Frames in LR-WPANs nach

IEEE 802.15.4 (Standard 2015)
FCS: Frame Checking Sequence
MAC: Media Access Control
PAN-ID: Personal Area Network Identifier
Rsvd: Reserved

15 15
6
► 6LoWPAN

Die Sensoren und Aktoren als Devices im IoT werden zweistufig Adressierung
adressiert (Bild 008207). Das heißt, es wird zuerst mittels der PAN- der Devices
ID angegeben, in welchem WPAN sich das betreffende Device
befindet, und dann mithilfe der Adresse im WPAN angegeben, um
welches Device es sich im betreffenden WPAN handelt. Daraus geht
hervor, dass ein WPAN im IoT im Hinblick auf die Adressierung
weitgehend mit einem IP-Subnetz im klassischen Internet vergleich-
bar ist. Diesem Vergleich nach entspricht eine Subnetz-ID einer
PAN-ID und eine Host-ID in einem IP-Subnetz einer Device-
Adresse in einem WPAN.

Zu Bild 008206 sei angemerkt, dass die beiden Adressangaben, d.h. Komprimie-
PAN-ID und Address im WPAN, sowohl von der Quelle (Source) rung des IPv6-
als auch vom Ziel (Destination) im MAC-Header eingetragen wer- Header
den. Dies und der Umstand, dass ein WPAN im IoT einem IP-
Subnetz im klassischen Internet entspricht, führen dazu, dass im IoT
die Adressen auf dem IP-Layer aus den Adressen auf dem MAC-
Layer abgeleitet werden können (Bild 008208). Diese Besonderheit
der Adressierung im IoT verursacht eine Redundanz im IPv6-
Header. Infolgedessen können die Adressangaben im IPv6-Header
als irrelevante Informationen angesehen werden. Das ist der Grund,
warum diese Angaben ohne Verluste aus dem IPv6-Header entfernt
werden können, was zur Komprimierung des IPv6-Header führt.
Dies geht auch aus dem in Bild 008207 gezeigten Aufbau von
MAC-Adressen und in WPANs verwendeten IPv6-Adressen hervor.

Adressierung in LR-WPANs
Wie gesagt wird die Lokation von Devices in LR-WPANs nach
IEEE 802.15.4 sowohl auf dem MAC-Layer mit MAC-Adressen als
auch auf dem Network Layer mit IPv6-Adressen angegeben.

Es sei hervorgehoben, dass beide Adressarten den Interfaces von EUI-64 ID

Devices in WPANs zugewiesen werden. Wie aus Bild 008207 er-
sichtlich, wird eine klassische 48 Bit lange MAC-Adresse zuerst
durch das Einbetten der 16 Bit langen Folge 0xFEFE zu einer IEEE-
EUI-64-Adresse, d.h. zu einer vom IEEE standardisierten 64 Bit
langen MAC-Adresse, erweitert. Die EUI-64-Adresse wird auch
EUI-64 ID genannt.
 6
► 6LoWPAN

Bild 008207: Aufbau von MAC- und IPv6-Adressen in LR-WPANs

nach IEEE 802.15.4
EUI-64: 64-Bit Extended Unique Identifier
ID: Identifier
NIC: Network Interface Control

Eine EUI-64-Adresse stellt eine Adresse auf dem MAC-Layer dar

und wird auch als Interface ID für die IPv6-Adresse auf dem Net-
work Layer angenommen. Als Network Prefix in der IPv6-Adresse
wird die PAN-ID angenommen, also eine Adressangabe aus dem
MAC-Header. Eine solche Nutzung von Adressangaben aus dem
MAC-Layer auf dem Network Layer hat zur Folge, dass die Adres-
sangaben im IPv6-Header aus dem MAC-Header abgeleitet werden
können. Sie sind faktisch redundant – also irrelevant. Bild 008208
illustriert dies.
Anmerkung: In LR-WPANs nach IEEE 802.15.4 kann auch eine kurze 16
Bit lange Form von MAC-Adressen eingesetzt werden.

Redundanz von IPv6- und UDP-Header

Das Hauptproblem beim Einsatz von IPv6 im IoT besteht darin, dass
die IPv6-Pakete im „günstigsten“ Fall in LR-WPANs maximal 102
Bit lang sein dürfen.

Redundante Angaben Aus diesem Grund muss der Overhead in IPv6-Paketen komprimiert
werden. Da das UDP als Transportprotokoll im IoT dient, besteht
die wichtigste Aufgabe der Adaption des IPv6 zu dessen Einsatz in
LR-WPANs in der Komprimierung sowohl des IPv6-Header als
auch des UDP-Header. Bild 008208 stellt dar, wie die einzelnen
Angaben in den IPv6- und UDP-Headers bei ihrer Komprimierung

17 17
6
► 6LoWPAN

„behandelt“ werden können, um die Länge der IPv6-Pakete mög-

lichst weitgehend zu reduzieren.

Bild 008208: Möglichkeiten der Komprimierung von IPv6- und

UDP-Headers. Welche Bedeutung haben dabei die einzelnen Anga-
ben in IPv6- und UDP-Headers?
FC: Frame Control
FCS: Frame Checking Sequence
ID: Identification
IID: Interface Identification
Net Pref: Network Prefix
S/D Port: Source/Destination (UDP) Port
S/DN: Source/Destination Network

Die einzelnen Angaben im IPv6-Header können bei dessen Kom- IPv6-Header

primierung wie folgt betrachtet werden:
 V – Version
Diese Angabe, d.h. V = 6, ist immer gleich (konstant). Sie ist im
IoT bedeutungslos und auf ihre Übermittlung kann verzichtet
werden.
 6
► 6LoWPAN

 TC – Traffic Class, FC – Flow Label, PL – Payload Length und

NH – Next Header
Auch diese Angaben sind konstant. Auf ihre Übermittlung kann
ebenso verzichtet werden.
 HL – Hop Limit
Diese Angabe ist variabel und kann somit nicht komprimiert
werden.
 IPv6-Adressen
Sie ändern sich nicht und können aus MAC-Adressen abgeleitet
werden. Ihre Angabe im IPv6-Header ist nicht immer nötig.
UDP-Header Bei der Komprimierung des UDP-Header können die einzelnen
Angaben wie folgt betrachtet werden:
 UDP-Ports
Diese Angaben sind variabel, können aber teilweise komprimiert
werden.
 Length
Diese Angabe ist naturgemäß variabel, kann aber, so wie in Bild
008208 gezeigt, aus der Angabe Length im PHY-Header und der
Angabe der Länge des IPv6-Pakets, d.h. Packet Length, im IPv6-
Header abgeleitet werden. Demzufolge kann auf die Angabe
Length im UDP-Header verzichtet werden.
 Checksum
Die Prüfsumme hängt natürlich von den aktuell zu übermitteln-
den Daten ab, ist somit variabel und frei von Redundanz. Folg-
lich steht sie für eine Komprimierung nicht zur Verfügung.

Grenzen der Komprimierung

Nachdem in Bild 008208 dargestellt wurde, wie die einzelnen Anga-
ben im IPv6-Header bezüglich ihrer Komprimierung zu bewerten
sind, zeigt Bild 008209 den Fall, in dem der 40 Byte lange IPv6-
Header maximal komprimiert, d.h. auf 8 Byte reduziert, wurde. Das
Beispiel betont nochmals die Bedeutung der IPv6-Header-
Komprimierung.

Stateless Compression Bild 008209 vermittelt zudem das grundlegende Konzept der zu-
standslosen Komprimierung (stateless Compression) des IPv6-
Header. Das heißt, einer von der aktuellen „Situation“ der Daten-
übermittlung unabhängigen Komprimierung. Sie beruht darauf, dass

19 19
6
► 6LoWPAN

dem nach der IPv6-Header-Komprimierung verbleibenden Rest, d.h.

dem IPv6-Header Field Hop Limit, zwei zusätzliche spezielle Hea-
ders vorangestellt werden:
 DH – Dispatch Header
Der DH gibt an, wie der IPv6-Header komprimiert wird – ge-
nauer gesagt, welches IPv6-Header Compression Schema ange-
wandt wird. Aus Bild 008209 ergibt sich, dass ihm der Header
HC1 folgt.
 HC1 – IPv6-Header Compression Scheme
Der HC1 beschreibt das Schema der Komprimierung des IPv6-
Header. Im HC1 wird darüber informiert, welche Angaben der
IPv6-Header beinhaltet und wie diese Angaben komprimiert
werden (vgl. hierzu Bild 008212).

Bild 008209: Maximale Komprimierung des IPv6-Header (Beispiel)

Dispatch Header
Der Dispatch Header (DH) stellt ein maximal 8 Bit langes Bitmuster
dar und hat bei 6LoWPAN eine zentrale Bedeutung. Er dient quasi
als Bindeglied zwischen dem MAC-Header und dem folgenden
Header, der dem 6LoWPAN-Sublayer zuzuordnen ist. Wie bereits in
den Bildern 008204 und 008205 verdeutlicht wurde, wird im Dis-
patch Header – mit Dispatch Type – auf die Bedeutung des darauf-
folgenden Header und indirekt auch auf Besonderheiten des IPv6-
Pakets (komprimiert, fragmentiert, ...) hingewiesen (vgl. auch Bilder
008211 und 008214). Zu diesem Zweck wurden verschiedene Dis-
patch Header Types im RFC 4944 definiert, von denen Bild 008210
eine Auswahl präsentiert.
 6
► 6LoWPAN

Bild 008210: Dispatch Headers nach RFC 4944

BC: Broadcasting
HC: Header Compression
NALP: Not a LoWPAN

Eine vollständige Auflistung aller registrierten Dispatch Headers

findet sich unter:
http://www.iana.org/assignments/_6lowpan-parameters

Dispatch Type Wie in Bild 008210 zu erkennen ist, gibt Dispatch Type an, welche
Bedeutung der ihm folgende Header hat – beispielsweise:
 IPv6 Dispatch gibt an, dass ein nicht komprimiertes IPv6-Paket
folgt.
 LOWPAN_HC1 Dispatch (kurz HC1 Dispatch) gibt an, dass ein
HC1-Header folgt, der das Schema der Komprimierung des
IPv6-Header beschreibt (Bilder 008211a und 008212).

21 21
6
► 6LoWPAN

 Mesh Dispatch gibt an, dass ein Mesh Header folgt (Bilder
008211d und 008216).
Der Bedeutung nach ist der direkt nach dem MAC-Header platzierte
Dispatch Header in MAC-Frames von WPANs im IoT mit dem
EtherType-Header in Ethernet Frames im Internet vergleichbar.

Komprimierung des IPv6-Overhead

Nachdem das allgemeine Konzept der Komprimierung des IPv6-
Header und die Funktion des Dispatch Header erläutert wurden, soll
nun in Bild 008211 auf die mit dem Header HC1 verbundenen As-
pekte der Komprimierung eingegangen werden.

Bild 008211: Bedeutung des Header HC1 und mögliche Varianten

der Komprimierung von Overhead in IPv6-Paketen (a bis d)
HC1: IPv6-Header Compression Scheme
HC2: UDP-Header Compression Scheme
HL: Hop Limit
UDP-H: UDP-Header
 6
► 6LoWPAN

Bild 008211 zeigt die folgenden Varianten Varianten

der Komprimierung:
a) No Compression
Mit Pv6 Dispatch wird angezeigt, dass ein nicht kompri-
mierter, d.h. in der ursprünglichen Form vorliegender
IPv6-Header folgt.
b) Only IPv6-Header Compression
Mit HC1 Dispatch wird angezeigt, dass ein HC1-Header
folgt, in dem das Schema der Komprimierung des IPv6-
Header angegeben wird. Im HC1-Header wird darauf hin-
gewiesen, dass kein HC2-Header mit der Angabe des
Komprimierungsschemas des UDP-Header kommt. Das
bedeutet, dass der UDP-Header in dieser Variante nicht
komprimiert wird.
c) IPv6-Header and UDP-Header Compression
Mit HC1 Dispatch wird, ebenso wie in Variante b) darüber
„informiert“, dass ihm ein HC1-Header folgt. Hierbei han-
delt es sich um den HC2-Header mit der Angabe des
Komprimierungsschemas für den UDP-Header. Das heißt,
sowohl IPv6-Header als auch UDP-Header werden kom-
primiert.
d) Multi-hop Communication and Compression
Um Multi-hop Communication auf dem Link Layer, d.h.
eine über mehrere Transit Devices verlaufende Kommuni-
kation zwischen zwei End Devices, zu ermöglichen, wurde
der Mesh Header eingeführt. Wie Bild 008211d vermittelt,
wird mit Mesh Dispatch zu Beginn darauf verwiesen, dass
ein Mesh Header kommt. Daraufhin folgen die beiden
Headers HC1 und HC2 mit derselben Bedeutung wie in
Variante c).

Komprimierung des IPv6-Header

Wie bereits bekannt beschreibt der HC1-Header das Schema der
Komprimierung des IPv6-Header mit allen dazu nötigen Angaben.
Bild 008212 zeigt, um welche Angaben es sich handelt und wie
diese zum „Abbau“ der Redundanz des IPv6-Header dienen können.

23 23
6
► 6LoWPAN

Es sei hervorgehoben, dass die bereits in Bild 008208 aufgezeigten

Möglichkeiten der Komprimierung des IPv6-Header im Aufbau des
HC1-Header entsprechend berücksichtigt sind. Hierbei werden
insbesondere zwei Angaben im IPv6-Header bis auf 0 Bit kompri-
miert. Der Grund: Die Angabe Version ist im IoT bedeutungslos und
die Angabe Packet Length im IPv6-Paket ist aus den Angaben
Length of the PSDU im PHY-Header und Length im UDP-Header
ableitbar (derivable).

Bild 008212: Schema der Komprimierung des IPv6-Header – mögli-

che Optionen und ihre Codierung im HC1-Header
ICMP: Internet Control Message Protocol
TCP: Transmission Control Protocol
UDP: User Datagram Protocol

Zu den einzelnen Bits im HC1-Header ist Folgendes zu sagen: HC1-Header-

Bits
 x0x1: Diese Bits beschreiben die Komprimierung der Quell-
IPv6-Adresse (Source IPv6 Address): Ist x0 = 0, wird Source
Network Prefix (SNP) nicht komprimiert; ist x0 = 1, wird SNP
auf 0 Bit komprimiert und wenn nötig von Source Network ID
im MAC-Header abgeleitet (Bild 008208).
 x2x3: Diese Bits beschreiben die Komprimierung der Ziel-IPv6-
Adresse (Destination IPv6 Address): Ist x2 = 0, wird Destination
 6
► 6LoWPAN

Network Prefix (DNP) nicht komprimiert; ist x3 = 1, wird DNP

auf 0 Bit komprimiert und wenn nötig von Destination Network
ID im MAC-Header abgeleitet (Bild 008208).
 x4: Dieses Bit beschreibt die Komprimierung der Angaben Traf-
fic Class und Flow Label: Ist x4 = 1, werden diese beiden Anga-
ben auf 0 Bit komprimiert und somit als irrelevant angesehen; ist
x4 = 0, werden sie nicht komprimiert.
 x5x6: Diese Bits beschreiben die Komprimierung der 8 Bit lan-
gen Angabe Next Header (NH): Ist x5x6 = 00, wird NH nicht
komprimiert; ansonsten wird er auf die zwei Bits x5x6 reduziert.
Diese zwei Bits reichen aus, um darauf zu verweisen, welches
Protokoll auf dem Transport Layer – UDP, TCP oder ICMP –
verwendet wird (Bild 008212).
 x7: Dieses Bit verweist darauf, ob direkt nach dem HC1-Header
noch der HC2-Header kommt: Ist x7 = 0, folgt der HC2-Header
nicht; ist x7 = 1, folgt der HC2-Header.

Für die vollständige Darstellung siehe: Dreibändiges Loseblatt-

werk (Print und CD-Version) mit Update-Dienst:
"Protokolle und Dienste der Informationstechnologie"
Aktualisierungszyklus: 2 Monate
WEKA Media, Kissing
ISBN-13: 978-3827691422, Bestell-Nr. OL9142J
http://shop.weka.de/protokolle-und-dienste-der-
informationstechnologie-online

Literatur
[1] Badach, Anatol; Hoffmann, Erwin: Technik der IP-Netze. Verlag
Hanser, 2015, DOI: 10.13140/RG.2.1.4449.8404
[2] Devasena, C. Lakshmi: IPv6 Low Power Wireless Personal Area
Network (6LoWPAN) for Networking Internet of Things (IoT) –
Analyzing its Suitability for IoT; Indian Journal of Science and
Technology, 2016, DOI: 10.17485/ijst/2016/v9i30/98730

25 25
6
► 6LoWPAN

[3] Ishaq, Isam; et al.: IETF Standardization in the Field of the In-
ternet of Things (IoT): A Survey; J. Sens. Actuator Netw. 2013, 2,
235-287; DOI:10.3390/jsan2020235
[4] Raza, Sharid; Duquennoy, Siemon; Höglund, Joel; Voigt,
Thiemo: Secure Communication for the Internet of Things – A
Comparison of the Link-Layer Security and IPsec for 6LoWPAN;
Security Comm. Networks 2011; DOI 10.1002/sec
[5] Raza, Sharid; Trabalza, Daniele; Voigt, Thiemo: 6LoWPAN
Compressed DTLS for CoAP; 8th IEEE Conference on Distributed
Computing in Sensor System, 2012, DOI 10.1109/DCOSS.2012.55
[6] Schulte, Heinz (Hrsg.): Protokolle und Dienste der Informations-
technologie. WEKA Verlag, ISBN-13: 978-3824540662 – siehe
CoAP, IoT
Badach, Anatol; Internet of Things – IoT;
DOI: 10.13140/RG.2.1.5157.5527
Badach, Anatol; CoAP – Constrained Application Protocol
https://www.researchgate.net/publication/312174308_CoAP_-
_Constrained_Application_Protocol

Badach, Anatol; CoAP – Constrained Application Protocol

https://www.researchgate.net/publication/312174308_CoAP_-
_Constrained_Application_Protocol

Badach, Anatol; IoT: CoAP Messages - Structure and Types

https://www.researchgate.net/publication/313926805_IoT_CoAP_Mes
sages_-_Structure_and_Type

View publication stats