Startseite > Kommunikation > Wireless > Zigbee, Thread und Bluetooth Mesh im Vergleich

Funktechniken für Netzwerke

Zigbee, Thread und Bluetooth Mesh im Vergleich

10. September 2018, 11:28 Uhr | Von Tom Pannell

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Welches Protokoll ist das Beste?

Auf diese Frage gibt es keine einfache Antwort. Zwischen Zigbee, Thread und Bluetooth Mesh bestehen grundsätzliche Unterschiede.

Zigbee und Thread können bei Bedarf das Prinzip der Nachrichtenflut (Flooding) einsetzen, aber im Allgemeinen wird ein definiertes Routing genutzt, um den Verwaltungsdatenaufwand für das Netzwerk zu minimieren, der die Nachrichtenübertragung beeinträchtigen kann.

Bluetooth Mesh verwendet einen Flutalgorithmus, erlaubt aber die Konfiguration der Geräte als Router, um die Auswirkungen der Überflutung zu reduzieren. Die Bluetooth Special Interest Group (SIG) nennt das »kontrollierte Nachrichtenflut« (managed flooding).

Zigbee- und Thread-Netzwerke enthalten Vermittlungsknoten und Endknoten. Die Vermittlungsknoten sind in der Regel netzgespeist und dienen als Gerüst für das Netzwerk. Dagegen sind die Endknoten normalerweise batteriebetrieben; sie arbeiten an der Peripherie des Netzwerkes und verwenden Router, um Nachrichten für sie weiterzuleiten.

Die Routing-Tabelle wird beim Aufbau des Netzwerkes erstellt. Dabei handelt es sich um ein Verzeichnis, das jedem Gerät sagt, wie es mit anderen Geräten im Netz kommunizieren soll. Auf diese Weise kann ein Knoten effizient mit einem anderen Knoten kommunizieren, indem er Nachrichten auf einem genau vorgegebenen Weg durch das Netzwerk sendet. Dies wirkt sich positiv auf den Durchsatz des Netzwerks aus und kann die Latenzzeit reduzieren, wenn das vermaschte Netzwerk weiter wächst.

In der Vergangenheit wurde ein Netzwerk mit definiertem Routing einem Netzwerk, das mit Nachrichtenflut arbeitet, vorgezogen, da es eine effizientere Kommunikation sowie eine vorhersehbare Leistung bietet. Andererseits ist das Routing für die Entwickler des Stacks schwieriger zu implementieren.

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Paketstruktur bei Zigbee und Thread

Sowohl Zigbee als auch Thread verwenden IEEE 802.15.4 mit 127-Byte-Paketen und einer Datenrate von 250 kbit/s. Die Header der Bitübertragungsschicht sind zwar gleich, doch die Paketstruktur unterscheidet sich, was zu geringfügig unterschiedlichen Nutzlastgrößen führt. Das Zigbee-Paketformat (Bild 2) ergibt eine Nutzlast von 68 Byte.

Das Thread-Paketformat (Bild 3) ergibt eine Nutzlast von 63 Byte. Nutzlasten über 63 Bytes werden vom Thread-Stack mithilfe von 6LoWPAN aufgeteilt.

Die von Silicon Labs ermittelten Leistungsdaten basieren auf der Größe der Nutzlast. Sie ist bei einer Anwendungsentwicklung der entscheidende Parameter.

Jedes dieser Netzwerke teilt größere Nachrichten in kleinere auf. Bei Zigbee erfolgt die Fragmentierung auf der Anwendungsschicht und wird Ende-zu-Ende von der Quelle bis zum Ziel durchgeführt. Bei Thread erfolgt die Fragmentierung sowohl auf der 6LoWPAN-Ebene als auch von der Quelle bis zum Ziel.

Bei der Weiterleitung von Unicast-Nachrichten innerhalb dieser Netzwerke wird die Nachricht durchgeleitet, sobald das Gerät sendebereit ist. Bei Multicast bestehen Anforderungen des Netzwerks bezüglich der Nachrichtenübermittlung:

Bei Zigbee-Geräten wird eine Multicast-Nachricht erst nach einem Jitter von bis zu 64 ms weitergeleitet. Allerdings ist im Sender der Nachricht eine Zeitspanne von 500 ms vorgesehen, ehe er die Nachricht erneut sendet.
Bei Thread-Geräten erfolgt die Weiterleitung einer Multicast-Nachricht nach dem Protokoll RFC 7731 [1]. Der Timer ist auf 64 ms eingestellt und die Geräte ziehen von diesem Zeitwert einen Zufallswert ab, bevor sie eine Nachricht erneut senden.

Paketstruktur Zigbee und Thread, Bilder 2-4

Alle Bilder anzeigen (3)

Bluetooth-LE-Paketstruktur

Bluetooth Low Energy hat die in Bild 4 dargestellte Paketstruktur, um die Sendezeit und die Energieaufnahme zu minimieren. Bluetooth Mesh hat diese Paketstruktur um die Funktionen zur Nachrichtenvermittlung und um Sicherheitsfunktionen ergänzt.

Das bedeutet, dass Bluetooth Mesh nur 12 oder 16 Byte für Nutzdaten zur Verfügung hat. Außerdem werden die Nutzdatenpakete in einzelne Pakete segmentiert und am Ziel wieder zusammengesetzt.

Ein solches Segment-Paket enthält einen Header, der das Segment und 12 Bytes Anwendungs-Nutzdaten identifiziert, mit Ausnahme des letzten Segment-Pakets, das kürzer sein kann. Allerdings werden diese Segment-Pakete durch zusätzliche Abschalt-Anforderungen in der Bluetooth-Mesh-Spezifikation ausgeblendet, was die Latenzzeit erhöht und den Durchsatz verringert.

Alle im Test durchgeführten Durchsatz- und Latenzanalysen basieren auf den Nutzdaten für die Anwendung. Bluetooth Mesh wird aufgrund der geringeren Anzahl von Nutzdaten pro Paket folglich mehr Pakete als Zigbee oder Thread benötigen, um das im Test verwendete Referenz-Datenpaket zu übertragen.

Routing versus Flooding

Zigbee, Thread und Bluetooth Mesh wurden für die Heim- und Gebäudeautomatisierung entwickelt. Zigbee unterstützt mehrere Routing-Techniken, darunter das Fluten (Flooding) des Netzes für die Routenermittlung oder Gruppennachrichten, das Weiterleiten zum nächsten Vermittlungsknoten (Next-Hop-Routing) für den gesteuerten Nachrichtentransport im Netz und die Konzentration des Nachrichtentransports vieler Knoten auf ein Gateway, das dann den Weg zu den einzelnen Knoten kennt und sie per Source Routing erreicht. Es ist normal, dass ein Zigbee-Netzwerk alle diese Methoden gleichzeitig einsetzt.

Thread unterstützt sowohl Next-Hop-Routing als auch Flooding. Thread-Netzwerke behalten jedoch die Weginformationen zu allen Routern als Teil der normalen Netzwerkwartung bei, anstatt dass ein Gerät die Routenermittlung durchführt. Zudem minimiert Thread die Anzahl der aktiven Router, um die Skalierbarkeit auf große Netzwerke zu gewährleisten.

Bisher wurde dies als Einschränkung für eingebettete IEEE-802.15.4-Netzwerke angesehen, weil die Netzwerkflutung dann, wenn eine große Anzahl von Routern vorhanden war, die Häufigkeit und Zuverlässigkeit des Multicast-Verkehrs einschränkte. Allerdings verwaltet ein Thread-Netzwerk die Anzahl und den Abstand der aktiven Router und erfordert deshalb keinen Eingriff oder keine Verwaltung durch den Anwender.

Bluetooth Mesh unterstützt die kontrollierte Nachrichtenflut (Managed Flooding). Darunter versteht man eine geringfügige Abweichung gegenüber dem normalen Fluten, da der Anwender bestimmen kann, welche eingeschalteten Geräte am Fluten teilnehmen.

Dies reduziert die Auswirkungen von Überflutung, jedoch muss der Anwender die geeignete Dichte und Topologie für Router in seinem Netzwerk festlegen, was schwierig sein kann. Da sich das Netzwerk im Laufe der Zeit ändert, können sich auch die Geräte ändern, die am Fluten teilnehmen, was ein Ein¬greifen des Anwenders erforderlich machen würde.

Auch Bluetooth kennt Endgeräte, die als »Freund« bezeichnet werden – ähnlich wie Zigbee oder Thread. Ein solches Freundschaftsgerät ist mit einem benachbarten per Netzteil mit Strom versorgten Knoten gekoppelt, und Pakete für diesen Freund werden von dem netzgespeisten Knoten gespeichert. Der Freund wacht regelmäßig auf und befragt seinen Nachbarn, ob irgendwelche Pakete vorliegen. Der permanent aktive Knoten speichert das Paket für einen definierten Zeitraum, sodass sich der »Freund« bei seinem gepaarten Relaisknoten melden muss.

Im Test wurden sowohl kleine als auch große Netzwerke analysiert. Funknetzwerke können sich sehr unterschiedlich verhalten, und die Routing- und Managementtechniken müssen oft geändert werden, je nachdem, ob ein Netzwerk mit zehn Knoten oder 200 Knoten in Erwägung gezogen wird.

Typischerweise sind die Knoten in einem kleinen Netzwerk direkt oder über einen Relais-Knoten erreichbar – ein oder zwei Hops – und dafür kann sich ein sehr einfaches Routing oder das Fluten eignen. Je größer das Netzwerk wird, desto komplexer wird es: beispielsweise mehr Hops zwischen den Kommunikationspartnern; die Dichte der Knoten, die sich beim Senden von Nachrichten gegenseitig stören können sowie die Latenz und Zuverlässigkeit beeinträchtigen.

Wenn eine Nachricht per Fluten gesendet wird, um 100 Leuchten einzuschalten, ist es normalerweise nicht akzeptabel, dass 98 oder 99 der 100 Leuchten ein- oder ausgeschaltet werden. Dieses Problem ist in einem kleinen Netzwerk mit zehn Knoten selten, es kann aber in einem großen Netzwerk mit 100 Knoten häufig auftreten.