<<< Previous topic - Next topic >>> |
|
Author |
Message |
kdw
Joined: 05 May 2006 Posts: 1460
|
Posted: 04.03.2020, 18:20 Post subject: NB-IoT … |
|
|
Hallo Forum.
Das RMG/941 wird in der Variante „RMG/941N“ mit einem internen NB-IoT-Modem ausgeliefert. Auch eine 1NCE-SIM-Karte ist vorinstalliert, so dass der Anwender ohne weitere Kosten die nächsten 10 Jahre insgesamt 500 MByte Daten übertragen kann, ohne dass irgendwelche Mobilfunkkosten entstehen.
NB-IoT ist keine rein deutsche Angelegenheit, sondern ein offizieller Standard, der weltweit gültig ist. Insofern ist ein RMG/941N auch in vielen anderen Ländern nutzbar. Auf der Website der GSMA findet man einen Überblick zum weltweiten Ausbau der NB-IoT-Netze:
Quelle: https://www.gsma.com/iot/deployment-map/#deployments
VG KDW |
|
Back to top |
|
|
kdw
Joined: 05 May 2006 Posts: 1460
|
Posted: 18.03.2020, 18:52 Post subject: NB-IoT-Netzverfügbarkeit … |
|
|
Hallo Forum.
Bzgl. des T-Mobil-Netzes kann man über eine interaktive Karte im Internet für einen beliebigen Standort in Deutschland die NB-IoT-Verfügbarkeit prüfen:
Siehe https://t-map.telekom.de/TMAP4/jsp/nbiot.jsp
Durch die vorinstallierte 1NCE-SIM-Karte bucht sich ein RMG/941N innerhalb Deutschlands in das T-Mobil-Netz ein.
VG KDW |
|
Back to top |
|
|
kdw
Joined: 05 May 2006 Posts: 1460
|
Posted: 19.03.2020, 07:22 Post subject: GPRS Fallback ... |
|
|
Hallo Forum.
Sollte an einem bestimmten Standort kein NB-IoT-Netz verfügbar sein, bucht sich ein RMG/941 mit 1NCE-SIM-Karte automatisch in das T-Mobil-GPRS-Net ein.
Das jeweils benutze Netz ist in der Web-basierten Benutzerschnittstelle (SSV/WebUI) unter dem Menüpunkt Network => Mobil sichtbar - siehe erste Abbildung.
Die hier folgende Abbildung zeigt die typische GPRS Latency eines RMG/941N für einen einfachen ping im T-Mobile-Netz mit 1NCE-SIM-Karte.
VG KDW |
|
Back to top |
|
|
kdw
Joined: 05 May 2006 Posts: 1460
|
Posted: 24.03.2020, 15:26 Post subject: NB-IoT Latency ... |
|
|
Hallo Forum.
Sehr viel ungünstiger sieht es mit der NB-IoT Latency aus (siehe die Zeiten für den ping in der hier folgenden Abbildung).
VG KDW |
|
Back to top |
|
|
kdw
Joined: 05 May 2006 Posts: 1460
|
Posted: 25.03.2020, 07:17 Post subject: MQTT per NB-IoT ... |
|
|
Hallo Forum.
Auch MQTT-Verbindungen sind mit einem RMG/941N möglich. Zum Ausprobieren reicht der einfache Node-RED-Flow aus der folgenden Abbildung und die Verbindung zu einem frei zugänglichen Test-Broker im Internet:
Code: | MQTT-Konfiguration für den my_test Node:
Broker: mqtt.eclipse.org
Port..: 1883
Topic.: my_test |
Durch die relativ geringe NB-IoT Latency ist die Publish-Subscribe-Verzögerung der MQTT-Nachricht deutlich wahrnehmbar. Nach dem Publish-Trigger durch das Betätigen der Schaltfläche des Inject Node dauert es schon etwas, bevor die Nachricht im Node-RED-Debug-Fenster angezeigt wird.
VG KDW |
|
Back to top |
|
|
kdw
Joined: 05 May 2006 Posts: 1460
|
Posted: 26.03.2020, 07:32 Post subject: Ungünstiger Standort … |
|
|
Hallo Forum.
Meine NB-IoT-Tests mit einem RMG/941N und der 1NCE-SIM-Karte laufen besser, als ich erwartet hatte. Ich habe inzwischen einen ersten Verbindungstest an einem relativ ungünstigen Standort durchgeführt (kleines Dorf am Stadtrand von Hannover, Kellerraum eines 1-Familienhaus mit solidem Mauerwerk, kleine Magnetfußantenne einfach auf den Fußboden gestellt).
Die Verbindungsqualität ist von der Tageszeit abhängig. Morgens zwischen 07:00 und 08:00 Uhr hatte ich 2 ASU, -109 dBm (6%). Ein Ping-Test liefert 11% Paketverlust. Der MQTT-Test funktioniert aber problemlos. Abends zwischen 22:00 und 23:00 Uhr waren es nur noch 1 ASU, -111 dBm (3%), siehe folgende Abbildung.
Der Ping-Test mit dieser suboptimalen Verbindung ergab 46% Paketverlust (siehe folgende Abbildung). Aber der MQTT-Test funktioniert immer noch. Man kann also nach wie vor kleine Datenmengen an einen Server im Internet senden.
Bei 46% Paketverlust und dem Einsatz von TCP (MQTT nutzt TCP) muss man allerdings die Auswirkungen auf den Verbrauch des NB-IoT-Datenvolumens der 1NCE-SM-Karte bedenken. Würde man NB-IoT in einem Batterie-betriebenen Sensor nutzen, hätte der ungünstige Paketverlust-Prozentsatz auch noch erhebliche Auswirkungen auf die Batterielebensdauer.
VG KDW |
|
Back to top |
|
|
kdw
Joined: 05 May 2006 Posts: 1460
|
Posted: 29.03.2020, 18:40 Post subject: MQTT Byte Count … |
|
|
Hallo Forum.
Für die Nutzung einer NB-IoT-Verbindung mit geringer Bandbreite und begrenztem Datenvolumen ist es schon recht hilfreich, wenn man ein möglichst präzises Fingerspitzengefühl dafür entwickelt, mit welchem Datenvolumen in Abhängigkeit von Transport- und Applikationsprotokoll sowie Byte-Anzahl der Nutzdaten (Payload) man es genau zu tun hat. Deshalb hier ein Beispiel für einen MQTT-Publish.
MQTT benutzt bekanntlich TCP als Transportprotokoll. Der Protokoll-Overhead von TCP ist schon recht hoch, aber dafür liefert das Protokoll eine Zustellgarantie für den Payload.
Das folgende Szenario zeigt die Details für einen MQTT-Publish der Nutzdaten „1585481311411“ (ASCII-String mit 13 Bytes). Als Ausgangssituation sind für die „ppp0“-Schnittstelle eines RMG/941N folgende Werte vorgegeben (ppp0 ist die NB-IoT-Schnittstelle eines RMG/941N innerhalb des Linux-Betriebssystems): RX = 1.883 Bytes / TX = 10.332 Bytes vor der MQTT-Datenübertragung (aktive Verbindung zum MQTT-Broker war vorhanden).
Es werden insgesamt 13 Bytes Nutzdaten übertragen. Ein Node-RED-Timestamp als Zeichenfolge, zum Beispiel „1585481311411“.
Durch den MQTT-Publish wird ein Paket (siehe TX packets) mit 76 Bytes gesendet und ein Paket (siehe RX packets) mit insgesamt 40 Bytes empfangen. Die 76 + 40 = 116 Bytes zeigen, dass wir es mit einem Protokoll-Overhead von insgesamt 103 Bytes zu tun haben, um 13 Bytes Nutzdaten „1585481311411“ zu übertragen.
VG KDW |
|
Back to top |
|
|
kdw
Joined: 05 May 2006 Posts: 1460
|
Posted: 08.04.2020, 13:26 Post subject: MQTT Keep Alive … |
|
|
Hallo Forum.
Zwischen einem MQTT-Broker als Server und einem MQTT-Client wird eine TCP-Verbindung benutzt. TCP-Verbindungen müssen zunächst vom Client ausgehend aufgebaut werden, bevor eine Datenübertragung vom Client zum Server oder in umgekehrter Richtung möglich ist. Eine aktive TCP- und somit auch eine MQTT-Verbindung kann jederzeit sowohl vom Client als auch vom Server wieder beendet werden.
Soll zum Beispiel ein RMG/941N per MQTT-Publish jederzeit eine Nachricht empfangen können, muss das betreffende System eine dauerhaft aktive MQTT- bzw. TCP-Verbindung zum jeweiligen Broker aufrechthalten. Zur Steuerung des Zeitverhaltens ist das MQTT Keep Alive Timeout vorgesehen. Gemäß MQTT-Protokoll kann der Client nach Ablauf des Timeouts einen Ping-Request (PINGREQ Message) an den Broker senden, den dieser mit einer Ping-Response (PINGRESP Message) beantwortet und damit angezeigt bekommt, dass die Verbindung weiterhin bestehen soll. Auf diese Art und Weise lässt sich eine MQTT-Verbindung praktisch dauerhaft aufrechterhalten. Die folgende Abbildung zeigt die MQTT-Keep-Alive-Timeout-Einstellung unter Node-RED für ein RMG/941N (Broker: mqtt.eclipse.org):
Bei dem Eclipse.org-Broker lässt sich mit dieser Einstellung (210 Sekunden) eine dauerhafte Verbindung erzeugen. Auch kleinere Werte sind selbstverständlich möglich. Man muss allerdings berücksichtigen, dass durch die jeweilige Keep-Alive-Timeout-Einstellung auch mehr Daten für den Austausch der PINGREQ- und PINGRESP-Message je Verbindungsstunde verursacht werden. Die folgende Übersicht zeigt einige Beispiele zur Keep-Alive-Timeout-Einstellung und die dazu passenden Messwerte bzgl. der Datenübertragung zum Aufrechthalten der dauerhaften Verbindung:
Code: | MQTT Keep Alive Timeout = 120 Sekunden: ca. 8.325 Bytes je Stunde
MQTT Keep Alive Timeout = 180 Sekunden: ca. 4.318 Bytes je Stunde
MQTT Keep Alive Timeout = 210 Sekunden: ca. 4.594 Bytes je Stunde |
Welche Einstellung mit welchem Broker jeweils am besten funktioniert, muss für jedes Projekt sorgfältig ermittelt werden. Ohne eine optimierte Keep-Alive-Timeout-Einstellung wird die Verbindung immer wieder beendet und dann von Client sofort neu aufgebaut, um die Empfangsbereitschaft für den MQTT-Publish zu gewährleisten. Durch den Verbindungsabbau und Wiederaufbau fallen ebenfalls unnötige Datenmengen an. Diese können die durch den Keep Alive verursachte Datenmenge überschreiten.
VG KDW |
|
Back to top |
|
|
|