Sensornetze: Die Sprache für das "Internet der Dinge"

Funkvernetzung im Nahbereich genannt Short-Range Wireless Network ist auf dem Vormarsch
Funkvernetzung im Nahbereich mit Short-Range Wireless Networks ist auf dem Vormarsch

Die Funk-Vernetzung im Internet der Dinge ist weiter auf dem Vormarsch. Allerdings gibt es weiterhin eine Unmenge von Protokollen – vor allem für den Nahbereichsfunk, die so genannten Short-Range Wireless Networks. Seit Jahren ist auch IPv6 über IEEE 802.15.4 am Start, bekannt als 6LoWPAN. Hier Details dazu.

Nachdem die ersten Jahre im Umfeld des Wireless-Standards IEEE 802.15.4 eher holprig verliefen, hat sich nun Stabilität eingestellt. Auf dieser Grundlage sind bereits zahlreiche quelloffene und kommerzielle Lösungen verfügbar. Reicht dies aus, um wirklich zur umfassenden Sprache der lokalen Sensor-Aktor-Netze zu werden?

IPv6 für die Netzwerkschicht

Grundidee von „IPv6 over Low-Power Wireless Personal Area Networks“ (6LoWPAN) ist, das IPv6-Protokoll auch für lokale Funknetze zu nutzen, um homogene Ende-zu-Ende-adressierte Netzwerke zu realisieren. So kann das Internet der Dinge eine Verschaltung mehrerer IP-basierter Netze unter Nutzung individueller IPv6-Adressen werden, so dass zur Kopplung nur Layer-3-Router und keine Kopplungselemente höherer Schichten, insbesondere keine Gateways, nötig sind. Auch kommt die Standardisierung in den öffentlicheren Raum der Internet Engineering Task Force (IETF). Als Funk soll vor allem der IEEE802.15.4-Standard genutzt werden.

Allerdings müssen einige Adaptionen vorgenommen werden, um die Anforderungen von IPv6 auf der einen Seite und des IEEE-802.15.4-Standards auf der anderen Seite anzupassen. IPv6 erfordert eine max. Rahmengröße (Maximum Transmission Unit, MTU) von 1280  Bytes, während IEEE 802.15.4 maximal nur 127 Bytes erlaubt.

Die geringere Rahmengröße des IEEE-802.15.4-Standards erfordert auch eine effiziente Einbettung, weil der fixe Teil des Standard-IPv6-Headers schon 40 Byte hat. Würden diese in jedem Rahmen mit den bis zu 25 Bytes MAC-Overhead des IEEE-802.15.4-Standards übertragen, wäre mit bis zu 65 Bytes schon mehr als die Hälfte des Rahmens mit Steuerinformationen gefüllt. Entsprechend erscheint sowohl eine Kompression des Headers als auch eine Fragmentierung notwendig. Diese Anpassungen stehen zusammen mit einigen anderen Funktionen als 6LoWPAN in den RFCs 4944, 6282 und 6775.

Positiv ist, dass diese Vorgaben seit nunmehr zwei Jahren stabil und auch die Grundlage für zahlreiche quelloffene und kommerzielle Implementierungen sind, deren Interoperabilität im letzten Jahr in einem ersten Plug-Test verifiziert wurde.

Weiter positiv ist, dass mit dieser auf Modularität basierenden Kopplung zwischen den beiden Trendsettern IPv6 und IEEE 802.15.4 auch die verschiedensten Optimierungen möglich sind. So kann z.B. die 802.15.4-Schicht auch durch Wake-On-Radio-(WOR)-Elemente erweitert werden, die nach oben transparent sein können.

Allerdings wird deutlich, wie mit der Definition der Netzwerkschicht die derzeit eindeutige Standardisierung endet – drahtlose Sensor-Aktor-Netze in der Praxis jedoch über zahlreiche weitere Standards verfügen müssen, vor allem auf den höheren Schichten.

Routing

Das Routing auf Netzwerkebene ist eine wesentliche Voraussetzung, um zum einen die Reichweiten-Problematik durch eine gefilterte und gerichtete Weiterleitung von Paketen zu überwinden und zum anderen, um einen zuverlässigen Betrieb durch die Nutzung redundanter Verbindungen und die selbstständige und dynamische Auswahl der jeweils besten Route zu bieten. Dabei ist mit der Auswahl des Netzwerkprotokolls aber noch keine Auswahl eines Routingprotokolls gegeben. Allerdings lässt sich auch hier feststellen, dass sich mit dem ebenfalls in 2012 spezifizierten „Routing Protocol for Low power and Lossy Networks“ (RPL, sprich: rippl) ein weiterer stabiler Kandidat gefunden hat, der von praktisch allen wichtigen Marktteilnehmern anerkannt und verwendet wird. Das Routingprotokoll selbst ist im RFC 6550 beschrieben. Weitere wichtige Bestandteile sind der Trickle Algorithmus (RFC 6206) für das Timing der Informationspakete, die Definition der Routingmetriken in RFC 6551 sowie die Objective Function Zero (RFC 6552), die für die Wahl des bevorzugten Elternknotens benötigt wird.

Parameter1.) Ketten-
Topologie
 („chain“)
2. Baum-
Topologie
("tree")
3.) Maschen-
Topologie
("mesh")
 DODAG (*) Aufbau-Zeit  5 s 7 s 7 s
gesendete Datenpakete122689722118118
verlorene Datenpakete4736
Paket-Verlustrate0,04 %0,04 %0,03 %
DODAG „global repair time“34 s48 s34 s
DODAG „local repair time“-53 s90 s
gesendete u. empfangene Pakete188030182480192981
Control-Pakete248627042838
Control-Übertragungs-Overhead  1,32 % 1,48 % 

1,47 %

 

1,47 %

Ergebnisse von Messungen für drei repräsentative Topologien, die eine sehr gute Zuverlässigkeit und annehmbare Rekonfigurationszeiten zeigen. (*) Destination Oriented Directed Acyclic Graph

Tests mit einer eigenen Implementierung von sechs LoWPAN und RPL (Routing Protocol for Low power and Lossy Networks) zeigen auf einem Emulator, dass eine sehr gute Zuverlässigkeit und ein für viele „langsame“ Anwendungen völlig ausreichendes Zeitverhalten erreicht werden kann. Dieses kann durch Adaption von Parametern auf Kosten zusätzlichen Managementverkehrs deutlich verkürzt werden. Siehe in diesem Zusammenhang auch die Tabelle.

Die häufiger geäußerte Kritik, dass die Implementierung zu aufwendig sei, kann nicht ganz nachvollzogen werden. Die hauseigene – nicht auf Codegröße optimierte – RPL-Implementierung benötigt 11 kB Programmspeicher auf einem Atmel ATmega, was als durchaus akzeptabel angesehen werden kann.