6LoWPAN-Open-Source-Projekt
emb::6 spricht Bluetooth Low Energy
Fortsetzung des Artikels von Teil 1
IPv6-Kommunikation über BLE
Sowohl IPv6 als auch 6LoWPAN bieten beide sehr nützliche Funktionen und Mechanismen, von denen einige bei der Verwendung von BLE als Grundlage für die Kommunikation wiederverwendet werden können. Einige benötigen aber spezielle Anpassungen. So erlaubt 6LoWPAN beispielsweise durch eine Header Compression die Verringerung der durch das IPv6-Protokoll hervorgerufenen Verwaltungsdaten (Overhead), die auch bei der Kommunikation von IPv6 über BLE verwendet wird. Dabei werden die Protokoll-Verwaltungsdaten der gekapselten Schichten reduziert, um den Nutzdatenanteil der ohnehin schon kleinen Pakete so groß wie möglich zu halten.
Darüber hinaus kommen verschiedene Funktionen, wie z.B. die Stateless Address Auto Configuration zum Einsatz, durch welche die IPv6-Adressen der Geräte automatisch konfiguriert werden können. Dies ist in mehrerlei Hinsicht sinnvoll. Nicht nur, dass diese Geräte in sehr großer Anzahl eingesetzt werden können; sie sind – wie viele typische IoT-Geräte – auch meist weder mit einem Display noch mit Eingabemöglichkeiten zur Konfiguration ausgestattet oder werden z.B. an schwer zugänglichen Orten verbaut und eingesetzt.
6LoWPAN und BLE unterscheiden sich in der sogenannten Maximum Transmission Unit (MTU) wesentlich. Diese definiert die Anzahl an Bytes, die maximal mit einem Paket übertragen werden können. Hier können über die BLE-Sicherungsschicht nur bis zu 23 Byte Nutzdaten verschickt werden. Dies ist, auch im Vergleich zu der ohnehin schon geringeren Nutzdatenmenge des IEEE-802.15.4-Standards von maximal 102 Byte pro Paket, sehr wenig. Da IPv6 jedoch eine minimale MTU von 1280 Bytes voraussetzt, müssen beide Techniken sogenannte Fragmentierungsmechanismen einsetzten. Diese teilen große Pakete beim Senden in mehrere kleine Pakete auf, die dann auf der Empfängerseite wieder nahtlos zusammengesetzt werden. Dadurch wird für die höheren Schichten eine größere virtuelle MTU erreicht. Wird diese Fragmentierung von 6LoWPAN selbst durchgeführt, so verfügt BLE im L2PCAP bereits nativ über eine solche Funktion.
Zusatzfunktionen
Wie bereits erwähnt, verfügt IPv6 über eine Reihe von hilfreichen Zusatzfunktionen. Zu den wichtigsten gehören hierbei wohl die Stateless Address Auto Configuration (SLAAC) und das Neighbor Discovery Protocol (NDP). Letzteres hilft dabei, benachbarte Knoten zu ermitteln und schnell zu erkennen, ob ein Knoten noch erreichbar ist. Zum einen spezifiziert das Protokoll, wie Knoten – die keine Router sind – einen benachbarten Router lokalisieren können. Zum anderen erlaubt das Protokoll, die sogenannten IPv6-Adress-Präfixe zu entdecken, mit denen z.B. unterschieden werden kann, ob ein Ziel direkt oder nur über einen Router erreichbar ist.
Ein Knoten ist auch in der Lage, Parameter der Verbindung, wie z.B. die MTU, oder Parameter des Internet-Protokolls, wie z.B. Hop-Grenzwert, zu erlernen. Das NDP verläuft prinzipiell über das bekannte Internet Control Message Protocol (ICMP). Hierfür wurden speziell fünf neue Pakettypen definiert, bestehend aus Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement und Redirect Message.
Tutorial zu emb::6 auf dem 15. Wireless Congress 2018 | |
|---|---|
 | |
Das Institut für verlässliche Embedded Systems und Kommunikationselektronik (ivESK) der Hochschule Offenburg wird auf dem 15. Wireless Congress Systems & Applications den Einsatz von emb:.6 in der Praxis demonstrieren. Der 15. Wireless Congress wird wieder parallel zur Electronica im ICM – Internationales Congress Center München stattfinden. Weitere Informationen zum emb::6-Tutorial und zum Kongressprogramm finden Sie auf der Internetseite des Wireless Congress. | |
Darüber hinaus führt das Protokoll die bereits erwähnte Stateless Address Auto Configuration ein, mit der die Knoten dazu in der Lage sind, an sich selbst IPv6 Adressen zu vergeben. Der IPv6-Standard legt fest, wie ein Gerät seine IPv6-Schnittstellen konfigurieren muss. Dieser Prozess umfasst das Erzeugen einer Link-Local-Adresse, die Erzeugung von globalen Adressen über die sogenannte SLACC und die Erkennung doppelter Adressen, die Duplicate Address Detection. Die SLAAC hat hier einen besonderen Stellenwert, da sie es einem Gerät ermöglicht, seine eigenen Adressen zu erzeugen, indem es eine Kombination von lokal verfügbaren Informationen – eine 64 bit breite sogenannte Interface Identifier (IID) – und von Routern verteilten Informationen verwendet; die bereits erwähnten IPv6-Adress-Präfixe.
Zusammen mit der IID kann sich ein Gerät auf diese Weise eine eigene globale Adresse erzeugen. Auch ohne Präfix ist ein Gerät in der Lage, sich eine sogenannte Link-Local-Adresse zu generieren, die dann aber nur lokal für das Netzwerk und für die Kommunikation mit den benachbarten Knoten verwendet werden kann.
Für die Generierung der Adressen wird in BLE – sowohl bei 6LN als auch bei 6LBR – als lokale Information die 48 bit lange Bluetooth-Geräteadresse verwendet. Im Gegensatz zum IEEE-802.15.4-Standard, bei dem eine 64 bit lange Adresse existiert, bietet BLE die Möglichkeit, verschiedene Arten von Sicherungsschicht-Adressen zu verwenden.
Zugunsten der Sicherheit und der Privatsphäre wird allerdings empfohlen, private Bluetooth-Geräteadressen zu verwenden. So sollte ein 6LN eine andere Bluetooth-Geräteadresse für jede BLE-Verbindung mit einem 6LBR auswählen und ein 6LBR sollte regelmäßig seine zufällige Bluetooth-Geräteadresse ändern.
Um die IPv6-Adresse zu generieren, wird eine 64-bit-Adresse benötigt, welche bei BLE aus der 48-bit-Bluetooth-Geräteadresse gebildet wird, indem in deren Mitte zwei Bytes mit hexadezimalen Werten von 0xFF und 0xFE eingefügt werden.
Die IPv6-Link-Local-Adresse wird gebildet, indem der IID des Geräts der spezielle Präfix FE80::/64 vorangestellt wird (Bild 4). Diese Link-Local-Adresse muss für die gesamte Lebensdauer eines BLE-L2CAP-Kanals verwendet werden. Nachdem eine logische Verknüpfung aufgebaut wurde, wird dieser Kanal intern über ein sogenanntes Handle referenziert. So beeinflussen eventuell wechselnde Geräteadressen keine Datenströme innerhalb bestehender L2CAP-Kanäle. Daher besteht keine Notwendigkeit, IPv6-Link-Local-Adressen zu ändern, auch wenn Geräte ihre zufälligen Geräteadressen während der L2CAP-Kanallebensdauer ändern.
Nachdem die Link-Local-Adresse generiert wurde, folgt die Erstellung der globalen Adresse. Der 6LN sendet eine Router-Solicitation-Nachricht an den 6LBR und verarbeitet die Antwort – ein Router Advertisement – entsprechend. Diese enthält Informationen über den IPv6-Präfix, mit dem dann zusammen mit der IID die globale Adresse gebildet werden kann. Letztendlich kann dann die Adresse mittels des NDP auf Eindeutigkeit überprüft werden.
BLE-Adressen auf IPv6
Die BLE-Sicherungsschicht unterstützt kein Multicast wodurch eine direkte Kommunikation immer zwischen genau zwei BLE-Geräten stattfindet. Dies gilt ebenso für den Fall, bei dem ein Router (6LBR) mit mehreren Knoten (6LN) verbunden ist. Will ein 6LBR ein Multicast-Paket an alle 6LNs senden, muss er das Paket replizieren und über jede Verbindung separat senden. Dies ist nicht energieeffizient, weshalb besonders bei batteriebetriebenen Geräten Vorsicht geboten ist. In umgekehrter Richtung muss auch ein 6LN bei einem Multicast für jeden Knoten einzelne Datenpakete an oder über einen 6LBR senden.
BLE-Adaption in emb::6
Um IPv6 über BLE zu unterstützen, wurden in emb::6 nicht nur einige Änderungen in der Kern-6LoWPAN-Konfiguration angewendet, sondern auch ein Adaptionstreiber für niedrige Schichten des BLE-Stapels eingeführt. Bild 5 zeigt die Struktur des emb::6-Stapels mit Unterstützung für IEEE 802.15.4 und BLE als untere Kommunikationsschichten.
Ein essenzieller Punkt ist hierbei die Behandlung der Pakete. So muss die 6LoWPAN-Paketfragmentierung deaktiviert werden, da eine ähnliche Funktion bereits von der L2CAP-Schicht im BLE-Stapel bereitgestellt wird. Zudem ist es erforderlich, das emb::6-Puffermanagement entsprechend zu erweitern, um die von BLE geforderte maximale Paketgröße von 1280 Bytes in der Bitübertragungsschicht unterstützen zu können – IEEE 802.15.4 erlaubt maximal 127 Bytes.
Eine weitere Anpassung ergibt sich beim Umgang mit Adressen. Der Standard IEEE-802.15.4 definiert 64-bit-Adressen, wogegen BLE nur eine 48-bit-Adresse verwendet. Dies beeinflusst die Generierung des IPv6-
Interface-Identifiers und musste bei der Umsetzung in den emb::6-Stapel berücksichtigt werden.
Um nun letztendlich über BLE kommunizieren zu können wurde innerhalb der emb::6-Struktur ein neuer Treiber namens dllc_ble_drv eingeführt (Bild 5). Dieser fungiert im Wesentlichen als Adapter von und zum BLE-L2PCAP und kümmert sich um den Austausch der IPv6-Paketströme. Die Schnittstelle wurde hierbei zugunsten einer guten Erweiterbarkeit so gewählt, dass prinzipiell auch andere Basisprotokolle in Form solcher Treiber eingebaut werden können, die dann je nach Protokoll eine entsprechende Adaption auf die unteren Schichten bereitstellen.
- emb::6 spricht Bluetooth Low Energy
- IPv6-Kommunikation über BLE
- Test auf einem BLE-Entwicklungskit
- Übersicht: Elektronik-Projekt emb::6
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Wireless Congress 2018
Als Frühbucher bis zu 320 Euro sparen
Trends 2018: Kommunikation
LPWA-Netzwerke – Lückenfüller, Enabler, Konkurrenz
Ganzheitliche Testumgebung
IoT-Funknetze simulieren, virtualisieren, emulieren und testen
Open-Source-Tools für Sensornetzwerke
Code-Automatik für Datenschnittstellen
