Desk Sharing & IoT - wie LoRaWAN seine Stärken ausspielt

Da wir in nächster Zeit in ein neues Gebäude umziehen werden, ist dieses Thema auch bei uns hochaktuell. Eine Verbindung mit IoT Technologien liegt da auf der Hand. Fachliche Grundlage bildet das Desk Sharing Konzept: Einzelne Mitarbeiter bekommen keinen festen Platz zugewiesen, sondern suchen sich zu Beginn eines Arbeitstages einen freien Büroplatz. 

Ohne technische Unterstützung müssten Mitarbeiter jeden Morgen mehrere Stockwerke auf freie Plätze überprüfen. Gleiches gilt für die Suche von Kollegen – oder man kontaktiert dies über Messenger oder direkt per Telefon. Und das Management hat keine Möglichkeiten herauszufinden, wie es um die genaue Auslastung der Arbeitsplätze steht. Behauptungen über fehlende Plätze können dann nicht überprüft werden, genauso wird die Anmietung von zu viel Bürofläche ebenfalls unentdeckt bleiben. 

Mittels eines platzspezifischen Check-In und -Out Systems und mehreren verteilten Anwendungen wollen wir diese Fragen angehen. Beim Check-In soll sich der Mitarbeiter vor der Arbeitsplatzbelegung mit seinem Mitarbeiterausweis bei einem am Platz platziertem Device anmelden. Das Device registriert daraufhin die Benutzerinteraktion und sendet die ID des Ausweises an das Backend. Die Daten können nun aufbereitet werden – dafür haben wir drei verschiedene Services implementiert: 

• Entrance-Dashboard
  Zeigt im Eingangsbereich, in welchem Stockwerk wie viele Plätze verfügbar sind. 
• Buddyfinder
  Ermöglicht, dass sich Kollegen untereinander finden können. 
• Analysis
  Auswertungstool für das Management, um die Platzauslastung festzustellen. 

LPWANs

Einer der wichtigsten Fragen ist nun: wie kann ich die erfassten Daten ressourcenoptimal in mein Backend senden. D.h. mit wenig Energie und ohne eine große Infrastruktur aufbauen zu müssen. Kurz: welchen Funkstandard verwende ich und welche Hardware benötige ich dafür? 

Aufgrund des hohen Energieverbrauchs eignen sich Technologien wie WLAN nur bedingt oder nicht. Mit den LPWANs (Low Power WAN) existieren jedoch eine Hand voll Standards, welche genau hier ihre Stärken ausspielen. Denn LPWANs zeichnen sich dafür aus, dass sie wenig Energie verbrauchen, eine hohe Reichweite besitzen und wenig Kosten zu verursachen. Der einzige Wermutstropfen ist, dass sie keine besonders große Übertragungsrate bieten – in unserem Anwendungsfall spielt dies aber keine Rolle. 

Die drei wichtigsten Vertreter der LPWANs sind NB-IoT, SigFox und LoRaWAN. Jeder bringt unterschiedliche Vor- und Nachteile mit sich. 

NB-IoT

NarrowBand IoT ist ein auf LTE aufbauender Standard. Zu seinen Vorteilen zählt der gute Quality of Service (QoS), die geringe Latenz und die vergleichsweise hohe Datenrate. Dafür wird jedoch eine (E)Sim und ein Mobilfunkanbieter zwingend benötigt.  

SIGFOX

Bei Sigfox handelt es sich um ein proprietäres Protokoll, welches die ISM Frequenzbänder nutzt. Der Energieverbrauch ist geringer als bei NB-IoT und die Funkmodule sind billiger. Genau wie NB-IoT ist ein Sigfox Netzwerk nicht ohne externen Betreiber nutzbar (in Deutschland ist das nur Sigfox Germany). Auch ist die Übertragungsrate nicht so hoch wie bei NB-IoT und LoRaWAN. Roaming bekommt man out-of–the-box. 

LoRaWAN 

Vergleichbar mit Sigfox nutzt LoRaWAN die ISM Bänder, proprietär ist aber nur das Modulations-Protokoll. Der größte Vorteil gegenüber anderen Technologien ist jedoch die Möglichkeit, sich sein eigenes Netzwerk aufzubauen. Eine Abhängigkeit zu einem Drittunternehmen entsteht also nicht, Betriebskosten entstehen nur intern. 

Wir haben uns – der geneigte Leser ahnt es – für LoRaWAN entschieden. Die Gründe hierfür sind: 

• Unabhängigkeit von Betreibern 
• Reifegrad der Umsetzung und Dokumentation und Schnittstellen 

Device 

Nun benötigen wir ein Microcontrollerboard für das Prototyping, welches möglichst schon ein LoRaWAN-Modem integriert hat und Anschlussmöglichkeiten für weitere Peripherie besitzt. 

Der Arduino MKR WAN 1300 ist ein Board, welches diese Anforderungen erfüllt. Wie bei Arduinos üblich, gibt es auch für diese Board einige Libraries, mit welchen die NFC-Chips und das LoRaWAN-Modem leicht angesprochen werden können. Außerdem kann dieses Board komfortabel über die Arduino IDE programmiert werden. 

Um NFC-/RFID-Tags auszulesen, setzen wir ein PN532 Board ein, welches sich über SPI mit dem Arduino verbindet. Für die Anzeige der Statusinformation setzen wird ein über SPI verbundenes E-Paper-Display ein – der Vorteil ist ein sehr geringer Energieverbrauch. 

Unser Prototype, ganz links im Bilder der NFC-Reader zur Erkennung des Mitarbeiterausweises, unten mittig ein Arduino MKR 1300-Board – das Brain -, darüber ein E-Paper-Display, welcher den aktuellen Status anzeigt, ganz oben die LoRaWAN-Antenne und zu letzt ganz rechts der Akkupack.

Sobald der Arduino startet, wird folgender Code ausgeführt, um sich mit dem Netzwerk zu verbinden:  

Die Join-Prozedur läuft über OTAA (Over-the–Air Activation) ab, hierbei werden die EUI und der AppKey benötigt. Während der Entwicklung können diese Parameter fest als Konstante eingespeichert sein. 

Nachdem der Arduino verbunden ist und die restliche Peripherie initialisiert hat, versucht er die eindeutige UID eines Tags über den NFC-Reader auszulesen. Wenn der Reader vor dem Timeout einen Tag lesen kann, toggelt der Arduino den aktuellen Workspacestatus, zeigt diesen auf dem Display an und sendet eine Nachricht über LoRaWAN an das Backend. 

Mit LoRaWAN vom Device ins Backend

Wie erwähnt, wollen wir über LoRaWAN Daten zwischen Device und Backend austauschen. Um diesen Vorgang und eventuelle Implikationen besser zu verstehen, haben wir uns LoRaWAN im Detail angeschaut. 

LoRaWAN lässt sich in zwei Schichten einteilen: in die proprietäre Modulationsschicht LoRa und in die, durch die LoRa Alliance öffentlich standardisierte, MAC-Schicht. Die LoRa-Schicht entspricht im OSI-Model (in etwa) der Bitübertragungsschicht und ist für die physikalische Umsetzung der Kommunikation zuständig. Die Media-Access-Contoll-Schicht (MAC-Schicht) hat folgende Aufgaben: Addressierung der Teilnehmer, Aktivierung der Geräte über OTAA, Verschlüsselung und die Sicherstellung der Integrität der (Nutz-)Daten. 

Modulation 

LoRa nutzt zur Funkübertragung die Regionalen SRD/ISM Bänder. In der EU liegen diese bei 433Mhz und 868Mhz (in der USA bei 915Mhz). Diese Bänder darf jeder frei benutzen, jedoch i.d.R. mit der Einschränkung in max. 1% der Zeit zu senden (die meisten LoRaWAN-Netzwerke schränken dies aber noch stärker ein). Somit gilt neben der Reichweite, dem geringen Energieverbrauch und einem hohen Quality–of–Service eine geringe Sendezeit als eine Einschränkung (bzw. Anforderung an Endgeräte) von LoRa. Alle Anforderungen gleichzeitig zu erfüllen ist mit den vorhandenen Stellschrauben für den jeweiligen Anwendungsfall möglich: 

• Viele kleine Nachrichten pro Zeiteinheit bedeutet weniger Sendezeit pro Nachricht, also auch weniger Inhalt pro Nachricht. 
• Bandbreiten 125kHz – 250kHz – 500kHz: Je höher die Frequenz, desto mehr Inhalt kann pro Zeiteinheit übertragen werden – jedoch mit geringerer Reichweite. 
• Anpassung des Spreadingfactors erlaubt höhere QoS jedoch verbunden mit längerer Sendezeit. 
• Höhere Sendeleistung bedeutet höhere Reichweite und QoS, jedoch mit höherem Energieverbrauch. 

Jede Anpassung der Stellschrauben muss intensiv getestet werden, da die physikalischen Eigenschaften des Netzwerks verändert werden – was unter Umständen dazu führt, dass die Übertragung der Information nicht mehr gesichert funktioniert. 

Sicherheitsmodel 

Um das Mitlauschen oder Verändern der gesendeten Daten zu verhindern, wird die Payload verschlüsselt und mit einem Message Integrity Code (MIC) versehen. Dafür existieren zwei 128 Bit lange Schlüssel – zum einen der Network-Session-Key (NwsSKey), der dem Device und dem Netzwerk bekannt ist und für die MIC/Integritätschecks verwendet wird (der verwendete Algorithmus ist AES-CMAC). Der zweite Schlüssel ist der Application-Session-Key (AppSKey) – dieser ist dem Device und der Anwendung (Handler) bekannt und wird für die Verschlüsselung der Payload verwendet (der verwendete Algorithus ist AES-128). 

Aktivierung 

Bei LoRaWAN gibt es zwei Möglichkeiten, wie Devices in das Netzwerk eintreten: 

1. ABP (Activation-by-Personalization)
   Hierbei werden die DevAddr, der NwsSKey und AppSKey, fest nach der Herstellung ins das Device programmiert. 
2. OTAA (Over-the-Air-Activation)
   Anstatt beide Schlüssel und die DevAddr von Beginn an im Speicher zu halten, werden beim Start des Gerätes zwei neue Schlüssel mit dem Netzwerk ausgehandelt. Als Grundlage dient die AppEUI und der AppKey – dieser darf sogar bei mehreren Devices derselbe sein. 

Netzwerk – TheThingsNetwork

Genauso wie bei Mobilfunk gibt es auch bei LoRaWAN Netzwerke, welche Basisstationen (bei LoRaWAN Gateways) betreiben um die vom Device gefunkten Daten einzusammeln und an die jeweilige Anwendung weiterzureichen. Auch wenn es relativ einfach ist, mittels frei verfügbarer Technik sich sein eigenes Netzwerk aufzubauen, haben wir uns dafür entschieden, TheThingsNetwork(TTN) zu nutzen. TheThingsNetwork ist das größte offene LoRaWAN Netzwerk weltweit, jeder kann kostenfrei seine eigenen Devices und Anwendungen verbinden. Jedoch verfolgt TTN einen communitybasierten Ansatz und betreibt selbst keine eigenen Gateways: diese müssen von den einzelnen Teilnehmer selbst aufgestellt werden. Das zuvor genannte Argument der Unabhängigkeit sehen wir weiterhin gegeben, da wir nur den kostenfreien Teil von TTN nutzen. 

Gateway 

Gateways sind die Relays, welche über LoRaWAN gesendete Paket dem Netzwerk über TCP/IP weitergeben – und vice–versa. Ein Gateway ist somit zwingend für die Übertragung (ins Internet) erforderlich. Trotzdem ist es aber nicht immer notwendig sein eigenes Gateway aufzustellen, denn gerade in Großstädten können die Gateways von anderen TTN Mitgliedern mitgenutzt werden. Die Abdeckung kann bei ttnmapper überprüft werden. Da an unserem Standort in Echterdingen (Stuttgart Flughafen) keine ausreichende Abdeckung vorhanden war, haben wir uns kurzerhand dafür entschieden, ein eigenes Gateway aufzustellen. Zum Einsatz kam The Thing Indoor Gateway. Es handelt es sich hierbei um ein preiswertes Einsteiger–Gateway. Alternativ bieten Hersteller wie Cisco, Kerilink und co. Geräte an, welche auch im Außenbereich angebracht werden können und qualitativ hochwertiger sind. Natürlich besteht auch die Möglichkeit, sich sein Gateway mittels Raspberry Pi und einem concentrator board selbst zubauen. 

Routing und Verarbeitung im TTN

Stark vereinfacht beschrieben sendet das Gateway ein Paket an einen Router. Der Router leitet das Paket basierend auf der im Paket enthaltenen DevAddr an den passenden Broker weiter. Dieser wiederum erkennt gleiche Nachrichten, falls diese von mehreren Gateways empfangen und weitergeleitet worden waren. Außerdem überprüft der Broker im Zusammenspiel mit dem Networkserver den MIC, welcher Aufschluss über die genaue DevEUI und AppEUI gibt und die Integrität der Nachricht sicherstellt. Mittels der AppEUI (Adresse der Applikation) kann der Broker nun die Nachricht dem Handler übergeben. Der Handler entschlüsselt die Nachricht, bereitet die Payload auf und leitet diese letztlich an das Backend der Applikation weiter. Dies kann über einen HTTP-Hook als auch per MQTT passieren. Es können sowohl die öffentlichen Handler, als auch eigene private Handler genutzt werden. Private lokal deployte Handler bieten End-to-End Verschlüsselung (die Entschlüsselung findet erst auf eigenem Terrain statt). 

Der komplette TTN “Stack” steht als auf GitHub offen zur Verfügung, mit diesem lässt sich auch Problemlos ein eigenes LoRaWAN-Netzwerk aufsetzen. 

In unserem konkreten Fall haben wir auf dem (öffentlichen) Handler folgenden Code installiert, um den Payload zu decodieren: 

Auswertung in der Cloud

Unsere verteilte Microservicearchitektur besteht aus drei Auswertungsservices und dem Devicemanagement bzw. der Deviceregistry. Das Devicemanagement ist bei uns eine in node.js und express entwickelte Anwendung.

Sie ist nötig, um neue Devices und Stockwerke (Erinnerung – Desk Sharing!) anzulegen und an einer Stelle diese Daten zu halten. Bei der Registrierung wird: 

• Das Schlüsselmaterial generiert
• Bei TTN das Device angelegt 
• Die Zugangsparameter in das Device geschrieben, wir hab dafür WebUSB ausprobiert es sind jedoch auch andere Verfahren denkbar
• der Name, das Stockwerk, die Position auf dem Grundriss und der Raum des Devices in der Service–eigenen MongoDB abgelegt 

Ablauf Deviceregistrierung

Um nicht selbst auf die Rest-API von TTN zugreifen zu müssen, bietet TTN für u.a. node und Java ein SDK an: 

Wenn ein Microservice den Name und den Standort eines Devices erfragen will, kann dieser die REST-Api des Devicemanagments aufrufen 

und bekommt darauf folgenden Response zurückgeliefert: 

Im letzten Schritt können wir in unseren Microservices die Daten verwerten. Exemplarisch dafür soll der Analysis-Service dienen. 

Datenfluss im Analysis-Service

Eingangs registriert dieser sich über das TTN-SDK am MQTT-Server des Handlers und lauscht fort an auf neue Nachrichten, nämlich Statusänderungen der Arbeitsplätze: 

Beim Eintreffen von Änderungen werden diese in die lokale MongoDB gespeichert. Sollte dies die erste Nachricht eines Devices sein, frägt der Service beim Devicemanagement dessen Standort ab und legt initial das Device in seiner lokaler DB an: 

Auf der anderen Seite des Service steht eine über das Kotlin Microframework ktor zur Verfügung gestellte REST-API für das Angular-Frontend. In diesem Teil werden bei Aufruf des jeweiligen Endpoints die Daten aus der Datenbank geholt und dementsprechend aufbereitet. 

Die Auswertung der Daten folgt in diesem Fall direkt in der MongoDB mittels einer Aggregation-Query oder aber über die eingebaute Map–Reduce-Funktionalität. Diese Aggregation kumuliert die totale Zeit der Auslastung jedes Arbeitsplatzes im gegebenen Stockwerk. 

Das Frontend kann diesen Endpoint nun dafür nutzen um dem Anwender auf dem jeweiligem Flurplan die Auslastung der Arbeitsplätze anzuzeigen. Den Flurplan kann das Frontend wiederum beim Devicemanagment abrufen.

Fazit 

• Es ist ein Ausbau seitens Mobilfunkanbietern in Gange, welche eine großflächige Abdeckung (mit LoraWAN) anstreben.
• Der TTN Stack bekommt ein Major Update auf Version 3, welcher auch Roaming/Peering zwischen mehreren Verschiedenen Netzen unterstützt.
• LoRaWAN ist extrem energieeffizient, der NFC benötigt das meiste Powerbudget.
• Die Installation eines eigenen Gateways für das öffentliche Netz ist einfach. 
• Sehr gute Dokumentation für TTN und Arduino verfügbar. 
• Dadurch, dass nur sehr kleine Datenmengen übertragen werden können, sollte ein Binärformat verwendet (oder entwickelt) werden.  

Gesamtarchitektur

Bürofläche ist nicht billig und Mitarbeiter, die nicht optimal verteilt sind, können weniger effizient kommunizieren: Es gibt viele Gründe, die eine Nutzungsoptimierung von Bürofläche nahelegen. Eine Verbindung mit IoT Technologien liegt auf der Hand. 

Im Kontext einer Desk-Sharing Anwendung konnten wir verschiedene Perspektiven einnehmen, um Verbindungstechnologien zu beleuchten – insbesondere LoRaWAN hat es uns da angetan. Einer effizienten Nutzung steht schon heute nichts mehr im Wege – es schadet aber nichts, wenn man die technischen Details kennt. Vollständig wegabstrahiert ist die technische Umsetzung an dieser Stelle noch nicht. 

NB-IoT und Sigfox sind Alternativen, die betrachtet werden müssen – und die unter anderen Umständen schnell zum Sieger gekürt werden würden. 

Wir freuen uns auf Feedback – Kommentare – Diskussionen. Mehr Informationen über IoT & Industrie 4.0 ist unter https://www.novatec-gmbh.de/beratung/iot/ zu finden.