Performance und Metriken von Embedded-IP-Mesh-Netzwerken

Zig Millionen Geräte sind an IEEE-802.15.4-Funknetze angeschlossen, und mit dem Internet der Dinge werden es noch deutlich mehr. Diese „Wireless Personal Area Networks“ arbeiten mit niedrigen Datenraten und verwenden eine Vielzahl von Protokollen, die von proprietären Punkt-zu-Punkt- bis hin zu Zigbee- und nun IP-basierten Mesh-Netzwerk-Stacks reichen, zum Beispiel das neue Thread-Protokoll. In diesem komplexen Umfeld ist es für Entwickler eine besondere Herausforderung, Übertragungen ohne Störung und mit hoher Effizienz sicherzustellen.

Wer neue vernetzte Geräte für das Internet der Dinge (IoT) entwirft, muss neben den Gerätefunktionen auch die Mesh-Netzwerke en Detail verstehen. Für die Geräte wichtig sind die Nachrichtenlatenz, der Stromverbrauch und die erwartete Batterielebensdauer. Das Netzwerkverhalten umfasst die durchgehende Nachrichtenlatenz, den Datendurchsatz und wie groß ein Netzwerk skaliert werden kann, ohne die Geräteleistung zu beeinträchtigen. Die Interaktion von Software und Hardware unterscheidet sich zwischen den einzelnen Implementierungen und kann kritische Parameter wie die Batterielebensdauer beeinflussen. Ein Verständnis über dieses grundlegende Verhalten und die Designwahl ist daher entscheidend. IoT-Entwickler sollten das Geräteverhalten, kritische Parameter und auch das Netzwerkverhalten und dessen Leistungsfähigkeit testen.

Geräteverhalten

Es gibt zwei grundlegende Gerätearten in Embedded-Mesh-Netzwerken auf Basis von IEEE 802.15.4. Erstens Router, die typischerweise direkt am Stromnetz hängen. Deren Empfänger ist stets aktiviert, um Nachrichten für andere Geräte weiterzuleiten. Die zweite Kategorie sind Endgeräte, die sich meist aus einer Batterie speisen. Sie befinden sich normalerweise im Ruhezustand und werden aktiviert, um eine Nachricht zu senden oder das Netzwerk auf eingehende Nachrichten zu überprüfen. Von der Leistungsfähigkeit der Router hängt ab, wie sich das Netzwerk verhält. Für Entwickler batteriebetriebener Geräte steht eher der Energieverbrauch im Fokus.

Bild 1: Typischer Wach-Schlaf-Zyklus eines Endgeräts in IEEE-802.15.4-Mesh-Netzen.Silicon Labs

IEEE 802.15.4 bietet einen Mechanismus, der das Verhalten schlafender Endgeräte definiert. Erstens, eine Datenabfrage seitens des Endgeräts, um festzustellen, ob das übergeordnete Gerät Daten vorliegen hat. Diese Abfrage ist eine der häufigsten Aktionen eines schlafenden Endgeräts, wenn es das Netzwerk überprüft. Die zweite 802.15.4-Nachricht ist ein normales Datenpaket, bei dem sich die Einrichtung aktiviert, Daten sendet und wieder in den Schlafzustand zurückkehrt. Bild 1 zeigt den Wach-Schlaf-Zyklus eines Geräts.

Energiebedarf

Die Leistungsaufnahme eines batteriebetriebenen und drahtlos vernetzten Geräts wird beeinflusst durch:

• Aktiv- und Ruheströme (abhängig vom Hardwaredesign und verwendeten ICs).
• Zeit zur Aktivierung des Geräts und der Funkverbindung (implementierungsspezifisch).
• Zeitdauer der Funkübertragung (Paketgröße).
• Wartedauer bis zur Bestätigung (definiert in der Spezifikation).
• Eigentliche Schlaf- und Aufweckdauer (implementierungsspezifisch).

Der Entwickler kann dabei nur wenige Faktoren beeinflussen, zum Beispiel die Zeiten für die Schlaf- und Weckzyklen, was dann sich die Batterielebensdauer des Geräts auswirkt. Die Hardware- und Software-Interaktionen, die die Effizienz dieses Schlaf- und Wachzyklus bestimmen, sind entscheidend für die Gesamtlebensdauer der Batterie.

Reale Messung

Die Autoren haben zwei Wach- und Schlaf-Operationen mit dem Wireless-SoC EM35x von Silicon Labs untersucht. Dabei nutzten sie den neuesten Embedded-Mesh-IP-Stack für das Thread-Protokoll. Wenn das Gerät Daten abfragt, aber keine Daten vorliegen, dann dauert das Aufwecken zwischen 4,16 und 6,34 ms. Die Datenpakete sind hierbei nur 18 Byte groß und verwenden keine Sicherheitsfunktionen. Wenn das Gerät hingegen 50 Byte sendet, liegen die Aufwachzeiten zwischen 8,65 und 10,4 ms. Die Pakete sind hier 97 Byte groß und per MAC gesichert.

Bild 2: Je länger der Wachzyklus dauert und je öfter das Gerät Daten abfragt, desto kürzer wird die Batterielebensdauer.Silicon Labs

Der Unterschied zwischen der minimalen und maximalen Zeit begründet sich durch Abweichungen beim Clear-Channel-Assessment. Zu beachten ist, dass sichere Verarbeitung beim gesendeten Paket vorhanden ist, aber nicht bei der Datenabfrage. Der tatsächliche Stromverbrauch während dieser Vorgänge hängt von der Funkleistung, der verwendeten MCU und deren Stromprofilen ab (Aktiv- und Ruhezustand).

Wachzyklus und Ruhestrom

Die Messung der Leistungsfähigkeit bedeutet wenig, solange ein Entwickler die Daten nicht in Zusammenhang mit dem Kontext des Systems bringt. Um die Batterielebensdauer abzuschätzen, muss er auf die Interaktion von Hard- und Software achten. Von der Software hängt maßgeblich ab, wie lange die Wach- und Ruhezeiten dauern. Ein häufiger Fehler ist, die Aktiv- und Ruheströme zwischen zwei Geräten oder Einrichtungen zu vergleichen, ohne den Einfluss der Software-Interaktion mit der Hardware zu berücksichtigen.

Bild 3: Auch mit steigendem Ruhestrom sinkt die Batterielebensdauer.Silicon Labs

Die Bilder 2 und 3 zeigen den Einfluss auf die Batterielebensdauer in Jahren, wenn sich der Wachzyklus oder der Ruhestrom verdoppeln, wobei alle anderen Bedingungen konstant bleiben. Die Aufweck- und Abfragezeit hat erheblichen Einfluss auf die Batterielebensdauer, wenn das Gerät in regelmäßigen Intervallen (zum Beispiel alle 10 s) nach Daten sucht. Der Ruhestrom heutiger MCUs hat verglichen dazu viel weniger Einfluss auf die Batterielebensdauer. Daher ist der Wachzyklus entscheidend für die Vorhersage der Batterielebensdauer.

Netzwerkverhalten

Wie hoch der Datendurchsatz und die Latenz von Nachrichten sind, hängt vom Netzwerkverhalten ab. Beides lässt sich über eine Serie von Übertragungen messen, wobei ein Gerät bei jeder Übertragung sicherstellt, dass das Datenpaket nur einen Pfad durch das Netzwerk nutzt. Der Sender übermittelt die Pakete an die entsprechenden Router im Netzwerk. Anschließend antwortet der Empfänger mit einer Bestätigung. Bild 4 zeigt einen typischen Testaufbau. Diese Hin- und Her-Übertragung spiegelt das Gerät-zu-Gerät-Verhalten im Netzwerk wider. Zu beachten ist, dass die Netzwerkperformance eines Geräts bei der Kommunikation mit einem Smartphone oder einem Cloud-Dienst dabei nicht gemessen wird.

Bild 4: Mit diesem Testaufbau lässt sich das Verhalten eines Mesh-Netzwerks untersuchen.Silicon Labs

Die Netzwerklatenz wird mit verschiedenen Datenpaketgrößen gemessen. Jeder Protokollstack weist einen Satz an Headern auf, die als Overhead im Paket vorhanden, aber für die verschiedenen MAC- (Media Access Control), Netzwerk- und Sicherheitsdienste erforderlich sind. Die Header verbrauchen den Overhead im Paket – und der Entwickler muss die Nutzlast abschätzen, die bereitgestellt werden kann. Der gemessene Thread-Embedded-Mesh-IP-Stack weist die folgenden Header auf:

• PHY- und MAC-Header: 9 Byte plus 2 Byte FCS (Frame Check Sequence)
• MAC-Sicherheitsheader: 6 Byte plus ein 4 Byte MIC (Message Integrity Code)
• 6LoWPAN-Header: 8 Byte
• UDP-Header: 6 Byte (User Datagram Protocol)

Dieser Satz an Headern führt zu 35 Byte Overhead im 127 Byte umfassenden 802.15.4-Paket.

Bild 5: Gemessene Latenzzeiten bei der Hin- und Rückübertragung (Roundtrip) im Thread-Netzwerk.Silicon Labs

Latenz

Um die Netzwerklatenz zu messen, sind verschiedene Pakete nötig, um den Einfluss steigender Nutzlasten zu verdeutlichen. Bild 5 zeigt die Latenz von 10 bis 250 Byte Nutzlast und von einer bis sieben Übertragungen über das Netzwerk. Die Roundtrip-Latenz für eine Übertragung liegt bei maximal 82 ms für 250 Byte Nutzlast. Bei sieben Übertragungen ergeben sich für die gleiche Last 244 ms. Zu beachten ist, dass diese Roundtrip-Latenzen die MAC-Sicherheitsverarbeitung und die Bestätigung des empfangenden Geräts mit enthalten.

Die Latenz-Grafik (Bild 5) beschreibt auch den Einfluss der Fragmentierung über den Paketen: Für 70 Byte genügt ein Paket, bei 80 Byte Nutzlast muss der Sender schon zwei Pakete abschicken. Der Übergang von zwei auf drei Pakete zeigt sich zwischen 140 auf 150 Byte Nutzlast. Die steilere Kurve an diesen Übergangspunkten resultiert aus dem Verarbeitungsaufwand für das zusätzliche Paket.

Bild 6: Der Netzwerk-Durchsatz sinkt mit steigender Anzahl an Übertragungsstellen (Hops).Silicon Labs

Durchsatz

Die Messung des Netzwerkdurchsatzes basiert auf dem gleichen Testaufbau wie die Latenz. Dieser Durchsatz bemisst sich in Paketen pro Sekunde über das Netzwerk. Bild 6 beschreibt die Ergebnisse dieses Tests für eine 10- und eine 70-Byte-Nutzlast und von einer bis sieben Teilübertragungen (Router, Hops). Diese Ergebnisse zeigen die hohe Leistungsfähigkeit von 54 Paketen pro Sekunde für eine 10-Byte-Nutzlast bei einem Hop, die bei einer Nutzlast von 70 Byte auf 34 Pakete pro Sekunde abnimmt. Bei sieben Übertragungen im Netzwerk konvergieren beide zu 10 Paketen pro Sekunde.

Die Ergebnisse der Netzwerktests geben einen Hinweis auf den zu erwarteten Durchsatz in IP-basierten Mesh-Netzwerken. Damit lassen sich die Skalierbarkeit des Netzwerks und die Datenmenge, die jedes Gerät senden kann, näher einschätzen: Angenommen, ein Gerät sendet 50 Byte Daten alle 10 s als Statusüberprüfung an ein zentrales Gateway. Falls sich dieses Gerät in einem Netzwerk mit bis zu drei Übertragungsschritten vom Gateway entfernt befindet, sind 18 Pakete pro Sekunde (mit 50 Byte Nutzlast) zu erwarten. Werden die Daten also alle 10 s gesendet, skaliert das Mesh-Netzwerk bis zu 180 vernetzte Geräte.

Typische Anwenderanforderungen

Mit Leistungstests für das Netzwerk und die Geräte lassen sich die Forderungen der Anwender einschätzen. Eine Benutzerinteraktion soll typischerweise binnen weniger 100 ms abgeschlossen sein. Sieht ein Nutzer nicht die erwartete Antwort, drückt er die Taste erneut. 100 ms sind als Antwort akzeptabel, darüber hinaus wird die Reaktionszeit inakzeptabel.

Die Roundtrip-Latenzzeit ist etwas irreführend, da die Benutzererfahrung beim Einschalten von Licht nur eine Einwegebenachrichtigung ist, ohne Rückantwort des Schalters. Die Daten liefern dennoch einen Anhaltspunkt, was zu erwarten ist. Bleibt Nutzlast unter 100 Byte, dann beträgt die Roundtrip-Latenz weniger als 100 ms bei vier Übertragungen. Das System würde somit die Anforderungen für Heimbeleuchtungsnetzwerke erfüllen, die nicht mehr als vier Übertragungen benötigen. Die Nachrichtennutzlast wäre nicht größer als 100 Byte.

In der Regel erwarten Anwender eine Netzwerkskalierbarkeit für bis zu 250 Geräte. Ein System, das weniger Geräte pro Gateway unterstützt wäre zu teuer, da mehr Gateways erforderlich sind, um das typische Haus/Heim abzudecken. All diese Skalierbarkeitsvoraussetzungen sind aber schwierig zu beurteilen, da jedes Gerät sein eigenes Nachrichtenmuster aufweist. Die Überlappung der Nachrichten im Netzwerk wird dabei nicht gesteuert.

Solide Schätzung

Der Netzwerkdurchsatz hilft beim Abschätzen des akzeptierbaren Nachrichtenmusters. Nimmt man 70 Byte Nutzlast und durchschnittlich drei Hops pro Übertragungen an, kann man davon ausgehen, dass das Netzwerk etwa 16 Pakete pro Sekunde aufrechterhalten kann. Wenn sich also 250 Geräte in einem Netzwerk befinden, muss jedes Gerät Nachrichten innerhalb von weniger als 15 s senden. Der Entwickler kann dann die erwarteten Geräte im Netzwerk untersuchen und auch, wie oft Nachrichten gesendet werden müssen um festzustellen, ob die Architektur akzeptabel ist. So lässt sich zum Beispiel das folgende Datenverkehrsmuster überprüfen:

• 50 Tür- und Fenstersicherheitssensoren überprüfen den Zustand alle 5 s.
• 50 Beleuchtungseinrichtungen überprüfen den Zustand jede Minute.
• 30 Lichtschalter überprüfen den Zustand alle 5 min.
• Zehn Smart-Steckdosen senden alle 2 s Informationen zum Stromverbrauch.

Das Ergebnis einer solchen Konfiguration auf der Basis von 140 vernetzten Geräten wäre 16 Pakete pro Sekunde, was bei drei Hops möglich ist. Werden mehr Geräte hinzugefügt, würde sich das Netzwerk verlangsamen.

Das Optimum

Diese Netzwerk-Testergebnisse sind entscheidend für das erfolgreiche Design und die Implementierung vernetzter Geräte in Embedded-Mesh-Netzwerken auf Basis des IP-basierten IEEE-802.15.4-Protokolls, etwa Thread.

(lei)