Tool für die Analyse von IEEE-802.15.4-DrahtlosNetzen

In drahtlosen Sensornetzwerken großen Maßstabs ist Monitoring eine wesentliche Aufgabe, um das Netzwerkverhalten verfolgen und seine Leistungsfähigkeit in realen Anwendungen messen zu können. Im Gegensatz zu bestehenden, entweder teuren oder nicht ausreichend leistungsfähigen Ansätzen eignet sich die hier vorgestellte kostenfreie Lösung für das Monitoring selbst großer ZigBee-Sensornetzwerke mit vielen Knoten.

Aufgrund ihrer wesentlichen Rolle in »Cyber Physical Systems« oder auch dem »Internet of Things« nimmt die Bedeutung von »Low Power Wireless Personal Area Networks« (LoWPANs) gemäß dem IEEE-Standard 802.15.4 deutlich zu. Ihre Merkmale wie infrastrukturlose Konnektivität, niedrige Kosten und niedrige Datenrate eröffnen LoWPANs eine breite Anwendungspalette und machen sie zu einer wesentlichen Komponente des »Ubiquitous Computing«-Paradigmas. Um sicherzustellen, dass die LoWPANs auf dem geforderten Leistungsniveau arbeiten, und den Endanwendern quantitativ zu zeigen, dass ihre Anforderungen erfüllt werden, ist es wichtig, Netzwerk- und Systemadministratoren mit Werkzeugen für das Monitoring und die Protokollanalyse auszustatten.

Netzwerkmonitoring ist tatsächlich der Schlüssel dazu,

• Leistungsanalysen durchzuführen, 
• das Netzwerkverhalten zu verfolgen, 
• Netzwerkprogrammierer beim Code-Debugging zu unterstützen und 
• Netzwerkmanagement-Operationen auszuführen. 

Gewiss existieren Lösungen für das LoWPAN-Monitoring, aber diese weisen verschiedene Einschränkungen auf wie ihre hohen Kosten, die Notwendigkeit zusätzlicher spezieller Hardware oder ihre proprietäre Natur, sodass sie sich nicht flexibel an andere Protokollstacks anpassen lassen.

LoWPANs sind meist aus Knoten aufgebaut, die dem Standard IEEE 802.15.4-2003 entsprechen. Während dieser Standard die Bitübertragungsschicht und den MAC-Layer sowie darunterliegende Dienste für LoWPANs spezifiziert, werden höhere Layer wie die Vermittlungs- und die Anwendungsschicht von anderen Standards wie ZigBee oder 6LoWPAN definiert.

Trotz der Tatsache, dass ZigBee und 6LoWPAN/RPL heute wohl die wichtigsten Technologien für drahtlose Sensornetze sind, ist das Angebot für das Monitoring und Debugging dieser Netzwerke sehr schmal. Es existieren einige kommerzielle Produkte für das LoWPAN-Monitoring, doch dabei handelt es sich meist um Paket-Sniffer, die spezielle Hardware erfordern und ziemlich teuer sind. Den Autoren ist keine kostenlos verfügbare, spezielle Lösung für das Netzwerkmonitoring und -debugging bekannt, welche die IEEE-802.15.4-Protokollfamilie voll unterstützt.

Als eine solche Lösung stellen die Autoren hier das »Z-Monitor«-Tool [2] vor. Bei dessen Entwicklung war die Motivation des Teams, eine kostenlose Anwendung für das Monitoring und die Steuerung eines LoWPAN mit den folgenden Zielen bereitzustellen:

• ein modulares und erweiterbares LoWPAN-Protokollanalysetool, das sich kostenfrei und ohne jede spezielle Sniffer-Hardware nutzen lässt, 
• Unterstützung der Dekodierung von ZigBee- und 6LoWPAN-Protokollpaketen, 
• statistische Werkzeuge für die Netzwerk-Trafficanalyse, um die Evaluierung der Netzwerkperformance zu ermöglichen, 
• ein anwenderfreundliches GUI, das nicht nur dem Endanwender die Paketinformation zeigt, sondern sich auch für die einfache Steuerung des Netzwerks und die Überwachung seines Verhaltens eignet, 
• in der neuen Version: die Möglichkeit mehrere verteilte Sniffing-Punkte für das Monitoring eines großen Netzwerks zu nutzen, 
• auf mehreren Betriebssystemen (Windows und Linux) lauffähig.

Tabelle 1 fasst die Features einiger der wichtigsten bisher verfügbaren Tools zusammen und vergleicht sie mit dem hier vorgestellten Z-Monitor. Wie zu sehen ist, hat Z-Monitor einige Vorteile – so ist die neueste Version das einzige Tool, das mehrfache Sniffing-Punkte unterstützt.

Tabelle 1: Vergleich der Hauptleistungsmerkmale verfügbarer Sniffing-Tools

Beim Entwurf der Z-Monitor-Software war eine modulare und anwenderfreundliche Open-Source-Lösung für das LoWPAN-Monitoring das Ziel. Das Tool ermöglicht das Monitoring von Netzwerken auf 802.15.4-Basis und die Untersuchung des Netzwerkverhaltens durch statistische Datenanalyse.

Z-Monitor beruht auf einem speziellen Sensorknoten, der als passiver Sniffer agiert, den Netzwerkverkehr erfasst und ihn über eine anwenderfreundliche Benutzerschnittstelle (GUI) ausgibt. Der Hauptvorteil des Tools im Vergleich mit den oben erwähnten kommerziell verfügbaren Produkten ist seine Unabhängigkeit von jeglicher spezieller Hardware.

Um die angeführten Vorgaben zu erfüllen, wurde Z-Monitor mit einem Ansatz auf Komponentenbasis entwickelt (Blockdiagramm in Bild 1). Hardwareseitig besteht der Sniffer einfach aus einem IEEE-802.15.4-kompatiblen Sensorknoten, der den Netzwerkverkehr passiv erfasst. Jedes empfangene Datenpaket wird auf der seriellen Schnittstelle ausgegeben, über die der Sniffer das Paket an die Sniffing-Softwarethreads weiterleitet. Als Sniffer-Hardware kam ein »TelosB«-Knoten von Memsic (TPR2420 [3]) zum Einsatz, der die unter TinyOS [4] verfügbare Paket-Sniffer-Anwendung implementiert. Diese Anwendung schaltet den USB-Port in den »Promiscous«-Modus und erfasst anschließend alle vorbeikommenden Pakete.

Z-Monitor sammelt die vom USB-Port ankommenden Pakete, speichert sie in einem Puffer, führt das Parsing und die Paketdekodierung aus und zeigt schließlich die Frames und Netzwerkstatistiken an.

Auf der Softwareseite sind fünf Haupt-Softwarekomponenten definiert, die durch verschiedene Java-Klassen implementiert sind. Die einzelnen Komponenten sind:

• Sniffer-Komponente – liest die Daten von der im Konfigurationspanel spezifizierten Quelle, dem Sensorknoten, und verarbeitet sie in einem logischen Format für die Interpretation. Die Java-Klasse Zsniffer empfängt die Pakete vom Paket-Sniffer und schickt diese an die Pufferkomponente
• Pufferkomponente – speichert den eingehenden Daten-Bitstrom im flüchtigen Speicher, um Paketverlust zu vermeiden. Die Java-Klasse Zbuffer führt diese Operation aus. Um der Unabhängigkeit von den Netzwerkprotokollen willen speichert Zsniffer an dieser Stelle einfach den rohen Bitstrom.
• Speicherkomponente – erlaubt die permanente Speicherung der eingehenden Pakete für eine spätere Off-Line-Analyse. Die Java-Klasse Zstorage ist in den beiden unterschiedlichen Modulen ZfileStorage und ZdatabaseStorage instanziiert, die sowohl Optionen für die Dateispeicherung als auch die Datenbankspeicherung implementieren.
• Parser-Komponente – sie ist das Herzstück des Tools. Die Java-Klasse Zparser implementiert die Parsing-Funktionen des Bitstroms, also die Erkennung der Bedeutung jedes Felds eines Datenpakets. Hierfür nutzt die Klasse mehrere verschiedene Module, eines für jedes unterstützte Protokoll.

• Datenmanipulations-Komponente – die Rolle dieser letzten Komponente ist es, die Paketfelder anzuzeigen und nützliche Statistiken zu berechnen. Mehrere Anzeigeoptionen sind verfügbar, beispielsweise eine Gesamtansicht, in der die Felder jedes Pakets in einer Zeile dargestellt werden (Bild 2), zusammen mit einer Zeitleiste, welche die Abfolge der Pakete zeigt. Oder eine Schichtdarstellung (ähnlich der WireShark-Oberfläche), in der ein Paket Schicht für Schicht dargestellt wird (also Bitübertragungsschicht, dann MAC-Layer, Vermittlungsschicht usw.). Die Statistiken, die Z-Monitor bietet, umfassen die gesamte und durchschnittliche Paketanzahl und die durchschnittliche Paketgröße. 

Verteilte Schnüffler

In der neuesten Version verfügt Z-Monitor über eine Mehrfach-Sniffing-Funktion für das Monitoring größerer Netzwerke, in denen ein einzelner Sniffer nicht den gesamten Verkehr aufzeichnen kann.

Im Prinzip wird die Fähigkeit der Stand-alone-Version, auf eine abgesetzte Datenbank zuzugreifen, zusammen mit zwei Extra-IDs als Schlüssel für die Datenbank (eine ID für das Netzwerk und eine für den Anwender) für den Aufbau einer Client/Server-Architektur gemäß Bild 3 genutzt. Im Detail sammeln mehrfache Stand-alone-Versionen des Tools (in diesem Fall als Provider bezeichnet) lokale Abbilder des Netzwerks und senden die Daten über drahtgebundene oder drahtlose Verbindungen (z.B. WLAN) an einen globalen Z-Server, der die Datenbank enthält. Somit kann ein Anwender per Fernzugriff über einen Z-Monitor-Client das gesamte Netzwerk in Echtzeit verfolgen, indem er auf den Z-Server zugreift und die Daten kontinuierlich aus der Datenbank aktualisiert. Mit anderen Worten: Der Anwender hat mit einer einzigen Z-Monitor-Station den Eindruck, einen einzihen Sniffer für das Monitoring des gesamten Netzwerks zu haben, ungeachtet dessen geografischer Ausdehnung.

Da sich mehrfache Sniffing-Punkte oft über gemeinsame Bereiche des Netzwerks verteilen, könnten sie allerdings die gleichen Anteile des Netzwerkverkehrs erfassen und so dieselben Pakete mehrfach an den Z-Server melden. Um dieses Phänomen zu vermeiden, ist daher eine genaue Synchronisierung zwischen den Sniffern erforderlich. Dafür werden die Pakete im Z-Server über die bereits erwähnten Netzwerk- und Anwender-IDs hinaus mit einem Zeitstempel abgelegt. Für den verteilten Sniffing-Modus wurden über den Stand-alone-Modus hinaus einige neue Elemente implementiert: 

• Der Z-Server – eine lokale oder abgesetzte Server-Maschine, welche die Datenbank für die Paketspeicherung hostet und für die Z-Monitor-Provider über einen drahtgebundenen oder drahtlosen Kommunikationskanal (z.B. WLAN) erreichbar ist. 
• Der Z-Monitor-Client – eine lokale oder abgesetzte Client-Maschine, die dem Endanwender über Z-Server-Zugriffe den vollen Netzwerkstatus und die Statistiken zeigt. 
• Synchronisierung zwischen den Z-Monitor-Providern – versieht die Pakete mithilfe des »Network Time Protocol« (NTP [5]) mit einem genauen Zeitstempel, um Duplikate zu vermeiden und die korrekte Reihenfolge der Pakete von verschiedenen Sniffern zu erhalten. 
• Eine verteilte Funktion zur Vermeidung von Paketduplikaten – jeder Z-Monitor prüft in der Datenbank, ob das ankommende Paket bereits vorhanden ist. Falls nicht, legt er es dort ab, ansonsten löscht er es einfach. 

Über eine ebenfalls neu implementierte Funktion kann der Anwender beim Boot-up wählen, in welchem Modus der Z-Monitor laufen soll: 

• Stand-alone-Version – der Normalmodus, in dem ein Knoten als Sniffer agiert und die lokal erfassten und analysierten Pakete zeigt, 
• Provider-Version – wie der Normalmodus, aber mit Abspeichern der Pakete in einem lokalen oder abgesetzten Z-Server, 
• Client-Version – ohne jede spezielle Hardware am Z-Monitor verbindet sich der Anwender mit dem Z-Server und analysiert den Netzwerkverkehr in Echtzeit oder indem er die in der Datenbank abgelegte Historie betrachtet. 

Versuche und Resultate

Eine experimentelle Studie zeigte, wie sich das Tool beim Monitoring und der Leistungsevaluierung eines ZigBee-Netzwerks schlägt. Für den Stand-alone-Modus bauten die Forscher ein drahtloses Sensornetzwerk (WSN) aus insgesamt zwölf TelosB-Knoten auf (ein Snifferknoten, auf dem die TinyOS-Paketsniffer-Anwendung läuft, sowie elf Netzwerkknoten in einer Cluster-Baum-Topologie aus einem ZigBee-Koordinator, drei ZigBee-Routern und sieben Endgeräten). Die TelosB-Knoten wurden in einer einzelnen Broadcast-Domäne aufgestellt, daher beziehen sich die Ergebnisse auf ein Einzelsprung-Netzwerk. Die Übertragungsleistung der Knoten war auf den minimal möglichen Wert von -25 dB eingestellt, und der Frequenzkanal war auf 26 gesetzt. Die Beacon-Order war auf BO = 8 gesetzt, was zu einem Beacon-Intervall von BI = 3,97 s führte, und die Superframe-Order war auf SO = 4 eingestellt. Die restlichen Netzwerkparameter sind: 

• maximale Tiefe Lm = 3 Sprünge, 
• maximale Anzahl Children-Router pro Parent Rm = 4 und 
• maximale Anzahl Children-Knoten pro Parent Cm = 6. 

In dieser Studie maßen die Forscher die »Network Convergence Time« jedes Knotens, also die Zeit, die jeder Knoten für die Verbindung mit dem LoWPAN-Netzwerk braucht. Hierfür wird angenommen, dass alle Knoten (Router und Endgeräte) zur selben Zeit aufwachen. Sobald sich ein Knoten mit einem Parent-Knoten verbindet, sendet er ein spezifisches Datenpaket. Mit Z-Monitor wird die Zeit aufgezeichnet, zu der solche Datenpakete geschickt werden. Diese Zeiten werden als die Verbindungszeiten der jeweiligen Knoten gewertet.

Bild 4 zeigt einen Z-Monitor-Screenshot, während ein solches Netzwerk läuft. Aus dem Screenshot ist klar ersichtlich, dass das Parsing der ZigBee-Pakete korrekt abläuft und alle Pakettypen (Beacon, Acknowledgement, Datenframes) unterstützt werden. Z-Monitor erfasst die Verbindungszeit jedes Knotens. Wie zu erwarten, verbindet sich der erste ZigBee-Router nach drei Beacons (12 s). Zudem wächst die Verbindungszeit linear mit der Größe des ZigBee-Netzwerks, da sich die ZigBee-Endgeräte nicht vor ihren Parents (den Routern) mit dem Netzwerk verbinden können.

Für den Test der Synchronität im verteilten Sniffing-Modus bauten die Forscher ein deutlich größeres Netzwerk mit zunächst drei geografisch verteilten Sniffing-Punkten im selben WSN auf, von denen jeder mit einem anderen PC verbunden ist. Diese PCs agieren als Z-Monitor-Provider und sind so konfiguriert, dass sie einen NTP-Server als Zeitreferenz verwenden. Zunächst war der NTP-Server im selben LAN angebunden (Bild 5 a). Der Test lief etwa 30 Minuten lang, dabei wurden 1500 Beacons aufgezeichnet und der Offset jedes Beacons in jedem der drei Sniffer analysiert.

In diesem Setup lagen die Offsets in einem Bereich zwischen etwa 0,2 ms und 5,2 ms (Bild 6 a). Bei einem zweiten Test kam nicht mehr der lokale, sondern ein im Internet frei verfügbarer NTP-Server zum Einsatz (Bild 5 b).

Jetzt lagen die gemessenen Offsets zwischen 0,6 ms und 17 ms (Bild 6 b. Da ein Offset unter 20 ms oft akzeptiert wird und eine Erkennung doppelter Pakete in einem WSN mit niedriger Datenrate erlaubt, belegen diese Ergebnisse, dass die Lösung funktioniert.

Nun wurde das Netzwerk auf sechs Sniffer, einen Koordinator, sechs Router und sechs Endgeräte in Cluster-Baum-Topologie (Bild 7) mit Lm = 3 Sprünge, Rm = 4, Cm = 9, BO = 10 und SO = 5 erweitert.

Die Testergebnisse bestätigten, dass dieses System mit verteilten Sniffing-Punkten Systementwicklern und Netzwerk-Administratoren ein globales Bild des Netzwerkverhaltens liefern, obwohl ein einzelner Sniffer nicht alle Pakete erfassen kann. Alle Pakete werden korrekt (also in der richtigen Reihenfolge und ohne Doppler) in der Datenbank abgelegt und stehen für die Analyse und weitere statistische Untersuchungen bereit.

Auch in einem noch deutlich größeren Testnetzwerk im Rahmen des Artemis-Projekts »EMMON« [7] stellte das Tool seine Funktionsfähigkeit unter Beweis. In einem Bürogebäude im SANJOTEC Business and Technology Park [9] im portugiesischen Sao Joao da Madeira wurden 400 TelosB-Knoten über drei Stockwerke verteilt installiert. Mithilfe von Z-Monitor sammelten die Forscher statistische Daten und untersuchten die Leistungsfähigkeit eines solch großen und sehr dichten Systems auf Basis eines drahtlosen Sensornetzwerks. So liefen sechs Sniffer auf jedem Stockwerk einige Tage lang, um die Aktivitäten der in vier Feldern zu je 100 installierten Knoten zu überwachen.

Momentan laufen Arbeiten an noch ausgefeilteren Features für Z-Monitor wie die Erweiterung der Parsing-Komponente für die Unterstützung neuer COTS-Protokollimplementierungen wie »TinyRPL«, die Integration moderner Funktionen für die Filterung und die statistische Analyse oder die Verbesserung der Schnittstelle zur Topologiedarstellung. Die Forscher sind überzeugt, dass das Tool eine komfortable Lösung für die Entwicklung, das Debugging und die Installation drahtloser Sensornetzwerke auf Basis von LoWPANs darstellt. Beleg dafür sind eine Vielzahl von Universitäten und Forschungseinrichtungen weltweit, die das Tool einsetzen, sowie mehr als 500 Downloads seit dem Release.

Über die Autoren:

Stefano Tennina, Fernando Royo, Anis Koubâa und Mario Alves forschen an der CISTER/INESCX-TEC Resarch Unit, ISEP/IPP in Portugal und Olfa Gaddour ist am CES Laboratory der National School of Engineers in Sfax, Tunesien, tätig. 

Lesen Sie mehr zum Thema

Weitere Artikel zu Metering

Neues Sub-Metering-Gateway

Zuverlässiges Auslesen auch ohne Stromanschluss

STMicroelectronics/Vodafone

Zertifizierung für ortsbasierte Cellular-IoT-Module

Energiekrise & Smart Meter

Haushalte wollen besseren Überblick über eigenen Verbrauch

Erste Finanzierungsrunde

Zählerfreunde senken die Stromrechnung

»1:network«

Kosten des Smart-Meter-Rollouts sinken