Für und wider Standardprotokolle bei Sensorknoten-Netzen

Sparsam funken

29. Januar 2015, 10:24 Uhr | Von Christian Mauderer

Fortsetzung des Artikels von Teil 1

Nachteile bei der Verwendung von Standardprotokollen

Das Hauptproblem bei Standard-Protokollen ist meist, dass durch die universelle Auslegung zusätzliche Steuerinformationen nötig sind. Viele dieser Informationen können entfallen, wenn die Lösung speziell für eine Anwendung optimiert wird. Der Unterschied lässt sich an einem Beispiel verdeutlichen: Ein einfacher Messwert (z.B. ein Außentemperaturwert) soll von einem Sensor zu einer Basis übertragen werden. Da das eine typische Hausautomatisierungsaufgabe ist, könnte hier durchaus das für die Automatisierung ausgelegte ZigBee zum Einsatz kommen.

Bei ZigBee muss vor der Datenkommunikation zunächst ein Kanal gewählt werden. Dies passiert je nach Modus durch aktives Versenden von Paketen oder durch Hören, auf welchem Kanal kommuniziert wird. Ebenfalls je nach Modus gibt es eine ständig hörende Gegenstelle oder die Gegenstelle sendet in einem festgelegten Abstand Beacons und legt mit diesen Beacons den zeitlichen Rahmen für das Senden fest. Für diesen Verbindungsaufbau muss also aus Sensorknotensicht schon einmal für jeden Kanal eine gewisse Zeitspanne mit Senden oder Empfangen verbracht werden. Da der Verbindungsaufbau jedoch nur einmalig nach dem Einschalten passiert, ist das noch nicht der schwierigste Punkt.

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Deutlich kritischer ist die Paketgröße der späteren Datenpakete. Ein Paket besteht bei ZigBee aus mindestens folgenden Daten (Bild 2):

2 Byte Frame-Steuerung
2 Byte Zieladresse
2 Byte Quelladresse
1 Byte Radius (vergleichbar mit einer Time to Live bei Ethernet)
1 Byte Sequenznummer

Zusätzlich kommen dazu eventuell noch einmal zwei 8 Byte umfassende MAC-Adressen. Diese werden verwendet, solange dem Knoten vom Koordinator noch keine kürzere 16 bit lange „Short Address“ zugewiesen wurde. Ein Paket ist also zu Beginn mindestens 24 Byte groß. Nach erfolgreicher Zuteilung einer 16-bit-Adresse verringert sich die Mindestgröße auf 8 Byte für den Paket-Header. Hinzu kommen noch die Daten, die bei einem Temperatursensor nur wenige Bytes betragen (ein bis zwei – je nach Auflösung).

Dem gegenüber steht bei einer anwendungsspezifischen Lösung für diesen Fall ein relativ einfacher Paketaufbau. Wenn eine ständig aktive Gegenstelle vorhanden ist (z.B. die Steuerzentrale der Hausautomatisierung), würde es ausreichen, wenn der Temperatursensor eine bei der Installation einmal eingestellte Kennung von ein bis zwei Byte (je nach Größe der Anlage) vorneweg sendet und dann seine Daten anhängt. Eventuell macht noch ein Paketzähler Sinn, um verlorengegangene Pakete zu erkennen. Damit reichen hier zwei bis drei Byte für den Header.

Eine Übertragungssicherheit kann sowohl bei ZigBee als auch bei der anwendungsspezifischen Lösung durch mehrmaliges Senden oder durch eine Empfangsbestätigung erreicht werden. Allerdings sollte bei dieser stets bedacht werden, dass der Fehlerfall ein erneutes Senden und damit einen deutlich erhöhten Energieaufwand bedeutet. Vergleicht man nun die Größen der Pakete bei ZigBee und der anwendungsspezifischen Lösung, so sieht man, dass leicht ein Faktor zwei bis drei in der Paketgröße und infolgedessen auch im Stromverbrauch vorhanden ist. Zusätzlich kommt noch der Aufwand des Verbindungsaufbaus hinzu, der bei ZigBee nötig ist, da ZigBee auf einen dynamischen Aufbau eines Netzes ausgelegt ist. Bei der festen Installation kann hingegen von Anfang an von einer gleichbleibenden Struktur ausgegangen werden. Der Verbindungsaufbau und die Verbindungshaltung können damit deutlich einfacher sein oder komplett entfallen.