TOP
SSV Software Systems Register  Register
Log in to check your private messages  Log in to check your private messages
Startseite FAQ Search Mitglieder Profile  Log in 
SSV Support-Forum
NB-IoT …

 
Post new topic   Reply to topic    SSV-Forum Forum Index >>> RMG/941
<<< Previous topic - Next topic >>>  
Display posts from previous:   
Author Message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 04.03.2020, 18:20    Post subject: NB-IoT … Reply with quote

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
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 18.03.2020, 18:52    Post subject: NB-IoT-Netzverfügbarkeit … Reply with quote

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
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 19.03.2020, 07:22    Post subject: GPRS Fallback ... Reply with quote

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
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 24.03.2020, 15:26    Post subject: NB-IoT Latency ... Reply with quote

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
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 25.03.2020, 07:17    Post subject: MQTT per NB-IoT ... Reply with quote

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
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 26.03.2020, 07:32    Post subject: Ungünstiger Standort … Reply with quote

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
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 29.03.2020, 18:40    Post subject: MQTT Byte Count … Reply with quote

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
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 08.04.2020, 13:26    Post subject: MQTT Keep Alive … Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    SSV-Forum Forum Index >>> RMG/941 All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

SSV Software Systems GmbH

Dünenweg 5
30419 Hannover

Fon: +49(0)511  ·  40 000-0
Fax: +49(0)511  ·  40 000-40

sales@ssv-embedded.de


Impressum    ·    Datenschutz    ·    AGB

© 2023 SSV SOFTWARE SYSTEMS GmbH. Alle Rechte vorbehalten.

ISO 9001:2015