LPWAN
Das Sigfox-Funkprotokoll
Fortsetzung des Artikels von Teil 1
Uplink Protocol Stack: Wie Sigfox-Nachrichten verpackt werden
Wer ein Embedded-Sigfox-Endgerät mit bereits vorhandenem Funk-Transceiver einsetzt, kann sich direkt den Abschnitten 3 und 4 der Sigfox-Spezifikation zuwenden. In Sektion 3 geht es um alle Aspekte des Uplink-Protokoll-Stacks von Sigfox. Ähnlich zum Aufbau des OSI-Modells lässt sich die Kommunikation auch hier am besten in einem von oben nach unten laufenden Schichtmodell darstellen. Ausgehend von der Anwendungsebene (oben) mit dem Inhalt der zu übertragenden Daten, wie zum Beispiel gemessenen GPS-Koordinaten oder Temperaturwerte, durchläuft die Kommunikation alle sieben Schichten bis ganz unten zur physikalischen Übertragungsschicht, in der die Daten auf die Trägerfrequenz moduliert werden.
In der Protokollschicht »Header Insertion« erhält die zu übertragende Nachricht (UL Message Content oder UL-Payload) einen Kopf (Header) mit Längenangabe (Length Indicator – LI), zwei Flags (Bidirectional Flag – BF, Repeated Flag – RF), Nachrichtenzähler (Message Counter – MC) und einer Kennung (Identifier – ID). Unter »Authentication« wird das Datenframe mit dem UL-Auth-Parameter (Uplink Authentication) versehen, so dass der Empfänger im Sigfox-Server die Integrität und Authentizität des übertragenen Datenframes prüfen kann.
In Kürze wird Sigfox auch die Protokoll-Spezifikation zur 128-bit-AES-Verschlüsselung des Nachrichteninhalts zum Schutz sensibler Daten veröffentlichen. Ist die Verschlüsselung der Nutzdaten (Payload Encryption) aktiviert, erweitert das Endgerät das Datenframe um ein zusätzliches »RoC«-Feld (Rollover Counter).
In den Bereichen »CRC« und »Convolution« der Spezifikation geht es um die Erkennung von Übertragungsfehlern mittels Prüfsummen und um das korrekte Zusammenfügen von Nachrichten, die sich aus mehreren Datenframes zusammensetzen (Multiple-Frame-Übertragungen). Hierbei spielen die Header (Preamble) und der Typ des Datenframes (Frame Type) eine wichtige Rolle, denn sie helfen dem Empfänger in der Sigfox-Basisstation, die empfangenen UL-Datenframes korrekt zuzuordnen sowie zwischen einer Steuerungsnachricht (Control Message) mit einer Länge von einem Datenframe (Single Frame) und einer Applikationsnachricht (Application Message) mit mehreren Datenframes (Multiple Frame) zu unterscheiden.
Die letzte Protokollschicht »Modulation«, in der die Nachricht dann über Funk gesendet wird, entspricht dem zuvor besprochenen Abschnitt 2 »Radio Hardware Engineering« der Spezifikation.
Downlink-Stack: Wie ein Endgerät Nachrichten empfängt
Sektion 4 der Spezifikation beschreibt den Aufbau des Downlink Protocol Stack, wenn eine Nachricht von der Basisstation aus dem Sigfox-Netzwerk an ein Endgerät gesendet wird. Alle Downlink-Nachrichten werden vom Endgerät initiiert, weshalb der Aufbau des Downlink-Stacks etwas schlanker ist. Hier fällt beispielsweise die Protokollschicht »Header Insertion« (siehe Bild 3) im MAC/LINK-Bereich weg. Neben einer Fehlererkennung (Error Detection – DL-CRC) implementiert der Downlink-Stack zusätzlich eine Fehlerkorrekturfunktion (Error Correction), die mit zyklischen fehlerkorrigierenden BCH-Codes (Bose-Chaudhuri-Hocquenghem Code) arbeitet. Mit dieser Vorwärtsfehlerkorrektur lässt sich das erneute Versenden einer Downlink-Nachricht wirkungsvoll vermeiden.
Eine weitere Besonderheit der Downlink-Übertragung stellt die »Bidirectional Procedure« dar, auf die Punkt 4.9 des Spezifikationsdokuments näher eingeht. Diese B-Procedure beschreibt, wie eine Downlink-Übertragung von einem Sigfox-Endgerät angestoßen wird.
Die verschiedenen Übertragungsszenarien in verschiedenen Regionen bei der jeweils vorgeschriebenen Frequenznutzung (DC, FH, LBT, – siehe Bild 2) lassen sich in zwölf verschiedenen Zeitintervallkonfigurationen darstellen, die alle im Anhand A (Sektion 6) des Spezifikationsdokuments abgebildet sind.
Aufbau der gesendeten Nachrichten
In Abschnitt 5 »Applicative/Control Level« der Sigfox-Spezifikation geht es um den Aufbau von Endgeräte-Nachrichten, die an das Sigfox-Netzwerk gesendet werden. »Keep-Alive Control Messages« enthalten Informationen über den Zustand eines Sigfox-Endgerätes, wie zum Beispiel Batteriespannung oder Temperatur. Die »Confirmation Control Message« wird vom Endgerät nach einer Bidirectional Procedure an das Sigfox-Netzwerk gesendet, wenn die Downlink-Datenübertragung aus dem Sigfox-Netzwerk funktioniert hat.
Eine komplette Übersicht über den möglichen Aufbau von Application-Nachrichten, deren Nutzlast von leer bis zu 12 Byte reichen kann, zeigt Anhang B (Sektion 7) der Sigfox-Spezifikation. Im letzten Abschnitt (Sektion 8) der Sigfox-Spezifikation sind schließlich noch eine Reihe von Definitionen und Abkürzungen (Acronyms) aufgeführt.
Welche Auswirkungen verspricht sich Sigfox von der Offenlegung?
Mit der Sigfox-Spezifikation als Grundlage kann nun jeder Entwickler sein eigenes Sigfox-Endgerät erstellen. Sigfox erhofft sich dadurch eine Vielzahl neuer Anwendungen und zwar nicht nur für die bereits erfolgreich adressierten B2B-Märkte, sondern auch für lokal begrenzte oder stärker auf den Verbraucher ausgerichtete Applikationen. Ein Beispiel hierfür wurde auf der Veranstaltung Sigfox Connect 2018 in Berlin demonstriert, bei der Lebensmittelverpackungen, wie Wasserflaschen oder Süßigkeitentüten, ausgerüstst mit einem Sigfox-Transceiver erfasst und Lebensmittelkäufe so automatisch abgerechnet werden können.
Interessant wird nun zu sehen sein, welche neuen Produkte zukünftig insbesondere auf Basis von ASICs und Zustandsautomaten entwickelt werden. Denn genau solche Embedded-Logik braucht es für Endgeräte, die als Konsumprodukt in extrem großen Stückzahlen produziert werden.
Als offener Standard kann die Sigfox-Funktechnik jetzt zudem demokratisiert werden, da sie nicht mehr auf bestimmte Geräte- und Halbleiterhersteller begrenzt sein wird.
Der Autor
Aurelius Wosylus
leitet seit März 2016 die deutsche Niederlassung des französischen IoT-Netzwerkbetreibers Sigfox. Zuvor war er als Direktor bei Gemalto für die Geschäftsentwicklung der Embedded-Märkte sowie im IoT-Bereich zuständig.
In seiner 18-jährigen Erfahrung im Embedded-/IoT-Markt arbeitete er für mehrere multinationale Unternehmen, wie AMD, Lattice Semiconductor und STMicroelectronics. Zudem war er Eigentümer und Geschäftsführer von Mycon Technologies.
aurelius.wosylus@sigfox.com
- Das Sigfox-Funkprotokoll
- Uplink Protocol Stack: Wie Sigfox-Nachrichten verpackt werden
