Interaktion mit NIDD über SCEF mit dem Dienstprogramm Postman. Eine kurze Tour durch SCEF und seine Funktionen

In diesem Artikel erhalten diejenigen, die gerade mit der Entwicklung beginnen oder bereits die NB-IoT-Technologie anwenden, eine Vorstellung davon, wie sie remote mit dem NB-IoT-Gerät interagieren können.

Bild

Kurze Review


NB-IoT ist 2G auf den Fersen und hat sich als energieeffizienter Standard für die Mobilfunkkommunikation etabliert, der in absehbarer Zukunft 2G aus dem Weg räumen kann, was seine Position gestärkt hat. Der Grund dafür ist die Fähigkeit, das Problem des Energieverbrauchs eines der am meisten verbrauchenden Teile des Geräts - des Funksenders - flexibel anzugehen. Wenn Sie nicht auf Details eingehen, haben wir zusammen mit NB-IoT die Möglichkeit, die Betriebsmodi des Geräts flexibel zu konfigurieren, indem Sie den Kommunikationsplan des Geräts und die Interaktion des Geräts mit Servern im Internet festlegen.

Parallel dazu steigt die Anzahl der gleichzeitig mit einer Zelle verbundenen Teilnehmergeräte sowie die Kosten des Mobilfunkbetreibers für die Aufrechterhaltung der Funktionsfähigkeit dieser Kommunikation selbst erheblich an.

Es wird davon ausgegangen, dass der Leser ein ungefähres Verständnis der NB-IoT-Technologie hat und nur minimale Interaktionserfahrungen vorliegen.
Der Artikel wird regelmäßig aktualisiert und aktualisiert.


Schwierigkeiten innerhalb des NB-IoT-Netzwerks


Zusammen mit der Fähigkeit zur Steuerung des Funksenders und der hohen Energieeffizienz ist das Problem des Sendens von Daten in Richtung vom Server zum Modul (Gerät) aufgetreten. Der Grund dafür ist, dass es möglich ist, Hunderttausende von Geräten mit weißen IP-Adressen zu versorgen. Dies ist jedoch mit einem hohen Overhead verbunden und verringert die allgemeine Zuverlässigkeit des Netzwerks aufgrund seiner Komplexität. Das Modul empfängt die Adresse für das NAT des Bedieners und es ist für den Bediener aufgrund der großen Anzahl von Geräten schwierig, sie "out" zu übersetzen. Beispiel: 100.000 Geräte haben die gleiche Anzahl von IP-Adressen und im Rahmen von IPv4 scheint dies einfach nicht möglich zu sein. Der Übergang zu IPv6 kann dieses Problem lösen, Sie müssen jedoch immer noch für die „weiße“ Adresse des Geräts im Netzwerk bezahlen, was sich erheblich auf die Tasche der Unternehmenskunden auswirkt.

Das heißt, im allgemeinen Fall stellt sich heraus, dass das Gerät nur im Einwegmodus arbeiten kann, indem Daten an den Server übertragen werden, ohne dass Daten vom Server empfangen werden können, da der Server praktisch nicht weiß, wann das Gerät zum ersten Mal Kontakt aufnimmt. Oder verwenden Sie durchschnittlich nicht mehr als fünf Minuten, nachdem die Verbindung zwischen dem Gerät und dem Server zum Übertragen von Daten vom Server zum Gerät hergestellt wurde.

NIDD (Non-IP Data Delivery) - warum wird dies benötigt?


Bei der Arbeit mit dem NB-IoT-Netzwerk ist es sehr schwierig, sich an ein Gerät zur Übertragung eines Befehls oder bestimmter Daten zu wenden. Um dieses Problem zu lösen, wurde ein Mechanismus zur Optimierung der Übertragung kleiner Datenmengen, Non-IP Data Delivery (NIDD), erfunden. Der Mechanismus reduziert die Gesamtgröße der übertragenen Nachricht durch Reduzieren der Header. Dies wirkt sich wiederum positiv auf die Eigenschaften des Geräts aus: Es reduziert den Stromverbrauch und erhöht die Autonomie (Batterielebensdauer). Infolgedessen führt die Ablehnung der IP-Unterstützung zu billigeren Geräten, einer kürzeren Entwicklungszeit, einer höheren Wettbewerbsfähigkeit auf dem Markt für IoT-Geräte usw.

SCEF (Service Capability Exposure Function) - ein Geschenk für Benutzer


SCEF ist ein funktionales Netzwerkelement, das erstmals angezeigt wurde, und 3GPP Release 13, das auf der Seite des Mobilfunkbetreibers bereitgestellt wird und einen sicheren Kommunikationskanal zwischen dem SCS / AS (Service Capability Server / Anwendungsserver) und dem NB-IoT-Gerät bereitstellt. SCEF bietet einen Kommunikationskanal für die Kommunikation mit dem Gerät über NIDD und bietet über eine einzige Anwendungsprogrammierschnittstelle (aus der API T8-Beschreibung) Zugriff auf zusätzliche Netzwerkfunktionen / -dienste des NB-IoT-Netzwerks. In 3GPP Release 13 wurde nur der SCEF-Mechanismus für die Schnittstelle mit zellularen Netzwerkschnittstellen standardisiert. Dadurch wird die Netzwerklast optimiert, die Interaktion mit dem Gerät vereinfacht und der Algorithmus des Geräts selbst vereinfacht.SCEF erfüllt auch hohe Anforderungen an die Sicherheit der Datenübertragung und die Erfüllung der Anforderungen, um eine erfolgreiche Datenübertragung in beide Richtungen zu bestätigen.


Mit SCEF können Sie komplexe Interaktionssysteme mit dem NB-IoT-Gerät abstrahieren, auch wenn sich dieses im eDRX- oder PSM-Modus befindet und nicht für die Datenübertragung in Richtung des Server-> Geräts verfügbar ist. Wenn das Gerät eine Registrierung erhalten und mit dem Netzwerk des Netzbetreibers über den Kommunikationsplan „vereinbart“ hat, können Sie über eine einfache Schnittstelle Daten auf das Gerät übertragen und Daten von diesem empfangen, das „Abonnement“ Ihres Geräts und des AS für bestimmte Ereignisse verwalten, eindeutige Ereignisse festlegen und selbst binden Universelle ID-Namen und mehr. All dies über dieselbe Schnittstelle - T8 API.

Es ist wichtig zu beachten, dass ein Server (AS) nicht einer, sondern mehrere sein kann und Sie die Verteilung von Informationen zwischen Servern für bestimmte Ereignisse oder Gerätegruppen flexibel konfigurieren können.

Wie es funktioniert


Die beliebteste Lösung zum Organisieren des Zugriffs eines Geräts auf ein Mobilfunknetz ist die Verwendung eines Mobilfunkmoduls, zum Beispiel:


Bei der Registrierung in einem Mobilfunknetz überträgt ein solches Modul einige Informationen an den Betreiber, einschließlich der IMSI einer Teilnehmer-SIM-Karte, die der Betreiber dem Teilnehmerkonto oder dem Teilnehmer selbst zuordnen kann, wenn er Zugriff auf das persönliche Konto des Betreibers hat. Hinter dem SCEF-Bildschirm verbirgt sich das Wissen über die nächste Kommunikationssitzung mit dem Gerät. Die Registrierung eines Nicht-IP-Geräts im Netz des Betreibers ist nur möglich, wenn mindestens ein Abonnement von SCS / AS für dieses Gerät besteht. Kein Abonnement - niemand kommuniziert mit diesem Gerät über NIDD und das Gerät wird nicht im Netzwerk registriert. Somit kann SCEF, das über die nächste Kommunikationssitzung Bescheid weiß, Daten gemäß den angegebenen Übermittlungsparametern und der Lebensdauer der übertragenen Nachricht vom / zum Gerät übertragen, ohne dass eine zusätzliche Überwachung des Status der Datenübertragung und der Übermittlungssteuerung organisiert werden muss.

Leichtigkeit


Das Einkapseln von Datenbyteeinheiten vom Gerät in das TCP-Protokoll und das Übertragen auf den Server ist im Hinblick auf Hunderttausende von Teilnehmergeräten in der Flotte des Unternehmens teuer. Mit SCEF können Sie die IP-Adresse des Geräts verlassen und nur Nicht-IP-Daten ohne IP-Header über den Signalkanal übertragen. Dies trägt zu einer erheblichen Reduzierung der Kosten für das übertragene Byte bei und bietet zusätzliche Vorteile bei der Verwendung des Dienstes. Darüber hinaus nimmt SCEF keine Änderungen an den übertragenen Daten sowohl zum Gerät als auch von diesem vor. Die Nutzdaten werden transparent übertragen. Mit NIDD ist es daher möglich, nicht nur unstrukturierte Daten zu übertragen, sondern auch Daten, die in einem verständlichen standardisierten Format wie JSON „verpackt“ sind, um die Datenverarbeitung auf der AS-Seite zu vereinfachen.

Arbeitsbeginn


Die Struktur des URI (Uniform Resource Identifier) ​​am Beispiel von Postman


Zunächst müssen Sie vom Betreiber (M2M-Manager-Service) Zugriff auf Ihr persönliches Konto erhalten. Für die kommerzielle Implementierung von MTS wird eine einzige Schnittstelle für persönliche Konten bereitgestellt, über die Sie unabhängig voneinander einen APN erstellen, einen Anmelde- / Kennwortzugriff auf die API erstellen und die Namen ScsAsID, extID für Ihre Geräte zuweisen können.

Jene. wir werden zumindest brauchen:
  • ScsAsID - Ihre AS ID
  • APN - derjenige, der normalerweise für die Interaktion mit dem Netzwerk verwendet wird, funktioniert nicht
  • Login / Passwort - Daten für den Zugriff auf Ihr persönliches Konto und die Interaktion mit SCEF
  • URI - HTTP-Adresse und Port im Netzwerk, die Ihnen von SCEF zur Verfügung gestellt werden
  • externalID - ID unseres Geräts


Lass uns weiter üben


Die Theorie ist vorbei. Kommen wir zum interessantesten Teil - der Praxis des Produktionsmoduls SIMCom Wireless Solutions - SIM7020E .

Zuerst müssen Sie das Modul selbst für die Arbeit mit NIDD konfigurieren. Versetzen Sie dazu das Modul zunächst in den CFUN = 0-Modus und konfigurieren Sie es:

AT+CFUN=0
+CPIN: NOT READY

OK
AT+ENVDM=1,tel_conn_mgr,default_pdn_flag,1,30
OK
AT*MCGDEFCONT="Non-IP","<APN>"
OK
AT+CFUN=1
OK

+CPIN: READY
AT+EGACT=1,4,"<APN>"
+EGACT:1

OK

+EGACT:1,1,1,4

Überprüfen der Registrierung des Moduls im Paketdatennetz

AT+CGREG?
+CGREG: 0,1

OK

Und beenden Sie die Einrichtung von NIDD

AT+NIDD=0,"<APN>","<login>","<pass>"
+NIDD=0,0

OK

Die Antwort des Moduls enthält hier account_id: + NIDD = 0, <account_id> - Dies ist nützlich, wenn Sie NIDD auf dem Modul aktivieren.

AT+NIDD=1,0
+NIDD=1,0

OK

In diesem Fall ist account_id 0.

Fertig. In dieser Phase ist die Arbeit mit dem Modul abgeschlossen. Fahren wir mit der Einrichtung von SCEF fort.

Ein wichtiger Punkt: Ohne ein registriertes Abonnement in SCEF erhält das Modul keine Registrierung im Netzwerk!

SCEF


API T8


Es gibt ein spezielles Dokument, das die Interaktion mit SCEF detailliert beschreibt. Diese API definiert eine Reihe von Datenmodellen, Ressourcen und zugehörigen Verfahren zum Übertragen von Nicht-IP-Daten.



Arbeiten mit SCEF- und Dienstabonnements - JSON (JavaScript Object Notation)


Daten, die die SCEF-Konfiguration enthalten und über HTTP / 1.1 an SCEF übertragen werden, müssen im JSON-Format codiert sein, und der Hauptteil der HTTP-Anforderung selbst im Feld Inhaltstyp muss den Header "application / json" enthalten. Wenn die Nachricht an den Empfänger gesendet und die Zustellbestätigung empfangen wurde, muss SCEF gleichzeitig die entsprechende Konfiguration löschen, die Nachricht über HTTP POST für AS mit dem Statuscode „200 OK“ senden und den Ereignisbericht aktivieren.

Briefträger


Ich werde mich nicht mit der Arbeit mit diesem Dienstprogramm befassen. Im Internet finden Sie viele Bewertungen. Ich kann nur sagen, dass die kostenlose Version einige Einschränkungen aufweist, aber wir brauchen nicht viel. Die kostenlose Funktionalität ist mehr als ausreichend für unsere Aufgaben.

Nachdem wir es heruntergeladen und geöffnet haben, wird uns der erste Tab begrüßen - Launchpad, wo uns angeboten wird, unsere erste Anfrage zu erstellen, werden wir nicht ablehnen.


Fahren Sie sofort mit der Konfiguration unseres neuen Geräts fort.

Zunächst haben wir die GET-Methode konfiguriert und auf POST umgestellt (wenig später wird klar, warum dies erforderlich ist). Geben Sie auf der Registerkarte "Autorisierung" die verfügbaren "Anmeldeinformationen" ein:


Erstellen Sie jetzt unsere erste Anfrage:


Im Anfragetext geben wir Folgendes an:

{
    "externalId": "<ID >",
    "reliableDataService": false,
    "pdnEstablishmentOption": "WAIT_FOR_UE",
    "duration":"2020-12-31T23:59:59Z",
    "notificationDestination": "http://<IP >:<port>"
}

Wichtig!
:
  • “duration” – duration SLA SCEF (SCSAS/ID) , SCEF ,
  • “maximumPacketSize” – /

Beachten wir sofort, dass in „pdnEstablishmentOption“ folgende Optionen möglich sind:
  • WAIT_FOR_UE - Puffer, wenn das Gerät nicht verfügbar ist (nicht im Netzwerk, im PSM oder in einem anderen Status registriert)
  • INDICATE_ERROR - Antworten Sie sofort mit einem Fehler, wenn das Gerät nicht verfügbar ist
  • SEND_TRIGGER - Device Triggering Service verwenden (alternativer Übermittlungskanal per SMS). Dieser Artikel wird nicht berücksichtigt.

Wir verwenden denselben Parameter, um Daten an das Gerät zu senden. Beim Erstellen eines Abonnements können wir sofort Daten an das Gerät senden, wodurch die Anzahl der API-Anforderungen verringert wird.
Alle! Sie können auf die Schaltfläche Senden klicken und sorgfältig prüfen, was wir als Antwort von SCEF erhalten:

{
    "externalId": "<ID >",
    "duration": "2020-12-31T23:59:59Z",
    "notificationDestination": "http://<IP >:<port>",
    “reliableDataService": false,
    "maximumPacketSize": 500,
    "self": "/3gpp-nidd/v1/<ScsAsID>/configurations/<ID >",
    "status": "ACTIVE"
}

In der Selbstzeile sind wir hauptsächlich an der ID der von uns erstellten Konfiguration interessiert. Es ist äußerst unerwünscht, diese zu verlieren, da die Operatoren höchstwahrscheinlich die Anforderungsfunktion aller erstellten Konfigurationen nicht unterstützen. Wenn im Rahmen einer ScsAsID mehrere tausend Geräte erstellt werden, wird auf den SCEF-Servern zu viel Last erstellt, um alle Gerätekonfigurationen zu übertragen. Wir nehmen es in der Regel: ein Gerät = ein Abonnement als Teil des ScsAsID-Dienstes.

Somit können wir bereits Daten vom Modul auf dem Server empfangen, dessen IP-Adresse und Port wir oben angegeben haben.

Datenübertragung vom Modul zum AS


Versuchen wir, Daten vom Gerät an AS zu übertragen, kehren wir zum SIM7020E-Modul zurück. Wenn wir es im vorherigen Kapitel nicht berührt und nicht ausgeschaltet haben, senden wir den Befehl an das Gerät:

AT+NIDD=3,<account_id>,"6162636465"
OK

Bitte beachten Sie, dass unsere Nachricht in HEX codiert ist und eine einfache Sequenz enthält: "abcde".
Fast sofort auf dem Server (AS), der der Host ist, werden wir sehen:

POST / HTTP/1.1
OCSGHTTPProcessor: 147ff7c6-a43d-4fc9-b303-0ca50f497747
X-callback-t8-type: 3
X-callback-url: http://<IP >:<port>
X-api-network-service-node: 0
Content-Type: application/json
Content-Length: 214
Host: <IP >:<port>
Connection: Keep-Alive
User-Agent: Apache-HttpAsyncClient/4.1.3 (Java/1.8.0_181)

{"externalId":"<ID >","niddConfiguration":"/3gpp-nidd/v1/<ScsAsID>/configurations/<ID >","data":"YWJjZGU=","reliableDataService":false}

Die Nachricht selbst ist in Base64- Codierung angekommen und sieht folgendermaßen aus:
YWJjZGU=

Wenn wir aus der Base64-Codierung übersetzen, erhalten wir unsere ursprüngliche Nachricht:
abcde

Die Base64-Codierung wird verwendet, da bei Verwendung der ASCII-Codierung manchmal einige Daten verloren gehen und die Verwendung der Base64 die Übertragung zuverlässiger macht.

Es ist auch zu beachten, dass in diesem Fall die vom Modul übertragenen Informationen nicht in SCEF gespeichert werden und sofort über HTTP an unseren Server übertragen werden.

Datenübertragung vom AS zum Modul


Um Daten in Richtung von unserem AS an das Modul zu senden, kehren wir zu Postman zurück und erstellen eine neue Anforderung mit der POST-Methode und der Base64-Codierung. Wir senden 1234567890 (in Base64: MTIzNDU2Nzg5MA ==) an unser Modul:



Bitte beachten Sie, dass im Feld "Adresse" ein Nachtrag erschienen ist, in dem wir angegeben haben, für welche Konfiguration wir die Nachricht senden möchten. Wenn in unserer Konfiguration mehrere Geräte enthalten sind, können Sie die Kennung "externalGroupID" verwenden, und dann erhalten alle diese Daten. Ein weiterer wichtiger Punkt ist die Lebensdauer der gesendeten Nachricht, die in Sekunden angegeben wird und eine ziemlich große Reichweite hat.

Übrigens, wenn das Gerät zu diesem Zeitpunkt nicht online ist, wird unsere Nachricht an SCEF gepuffert, und die Zeile „MaximumLatency“ gibt an, wie viele Sekunden bis zur Zerstörung der Nachricht verbleiben, wenn das Gerät vor dem von uns eingestellten Timer nicht Kontakt aufnimmt . Nachfolgend sehen Sie, wie die angeforderte aktuelle SCEF-Konfiguration aussehen wird (unter Verwendung des GET-Mechanismus, mehr dazu weiter unten):

{
    "externalId": "<ID >",
    "duration": "2020-12-31T23:59:59Z",
    "notificationDestination": "http://<IP >:<port>",
    "reliableDataService": false,
    "status": "ACTIVE",
    "niddDownlinkDataTransfers": [
    {
        "externalId": "<ID >",
        "reliableDataService": false,
        "data": "MDEyMzQ1Njc4OTA=",
        "maximumLatency": 96,
        "priority": 1,
        "self": "/3gpp-nidd/v1/<ScsAsID>/configurations/<ID >/downlink-data-deliveries/1"
    }
}

Wenn das Gerät nach Ablauf des Timers immer noch nicht kontaktiert wurde, benachrichtigt SCEF Ihren Server (AS), dass die Nachricht aufgrund des Ablaufs des Timers nicht zugestellt wurde, und die Nachricht wird gelöscht:

POST / HTTP/1.1
OCSGHTTPProcessor: 14c8cab8-ecce-4868-a59e-1f784224518b
X-callback-t8-type: 4
X-callback-url: http://<IP >:<port>
X-api-network-service-node: 0
Content-Type: application/json
Content-Length: 139
Host: <IP >:<port>
Connection: Keep-Alive
User-Agent: Apache-HttpAsyncClient/4.1.3 (Java/1.8.0_181)

{"niddDownlinkDataTransfer":"/3gpp-nidd/v1/<ScsAsID>/configurations/<ID >/downlink-data-deliveries/1","status":"FAILURE"}

Bei Erfolg antwortet SCEF sofort:

{
    "externalId": "<ID >",
    "reliableDataService": false,
    "status": "SUCCESS"
}

Sie können die Möglichkeit hinzufügen, Nachrichten zu priorisieren, falls sie gepuffert sind. Sie wird durch den Parameter „Priorität“ geregelt. Wenn eine neue Nachricht an das Gerät gesendet wird und der Zustellungspuffer von SCEF überschritten wird, wird die Nachricht durch eine Nachricht mit niedrigerer Priorität ersetzt, andernfalls wird die Nachricht nicht zur Zustellung angenommen. Es ist auch möglich, eine Nachricht aus dem Puffer zu löschen.

Wenn die Nachricht nicht zugestellt werden kann und gepuffert ist, erhalten Sie Folgendes:

{
    "externalId": "<ID >",
    "reliableDataService": false,
    "self": "/3gpp-nidd/v1/<ScsAsID>/configurations/<ID >/downlink-data-deliveries/2",
   "status": "BUFFERING"
}

Wichtig!
:
/<ID >/downlink-data-deliveries/1
– SCEF. , . .

Nach Erhalt der Nachricht meldet das Modul den folgenden URC:

+NIDD=4,0,11,0,"3031323334353637383930"

Was in der Übersetzung von HEX nach ASCII unsere Botschaft sein wird:

1234567890

Lass es einfach hier. Benachrichtigung über die Zustellung einer "gepufferten" Nachricht:

{
"niddDownlinkDataTransfer":"3gpp-nidd/v1/<ScsAsID>/configurations/<ID >/downlink-data-deliveries/1",
"status":"SUCCESS"
}

Die Überwachung des Status des Gerätestatus ist über einen anderen SCEF-Dienst namens „Monitoring Event (MONTE)“ möglich. Innerhalb von MONTE ist es möglich, Benachrichtigungen über Ereignisse und Zeiten (z. B. wenn das Gerät verfügbar wird) über ein ähnliches Abonnementsystem zu erhalten. Aber lassen Sie uns ein anderes Mal darüber sprechen.

Konfiguration von SCEF abrufen


Sie haben wahrscheinlich bemerkt, dass Sie die aktuelle Konfiguration von SCEF erhalten können. Lass uns das tun. Wir nehmen den Postboten, den wir bereits geliebt haben, und erstellen die folgende Anfrage mit der GET-Methode:


Jene. Wir lassen den Nachrichtentext selbst leer und müssen in der Adressleiste nur die ID der für uns erstellten Konfiguration angeben, um den aktuellen Status als Antwort zu erhalten:

{
    "externalId": "<ID >",
    "duration": "2020-12-31T23:59:59Z",
    "notificationDestination": " http://<IP >:<port>",
    "reliableDataService": false,
    "status": "ACTIVE",
    "niddDownlinkDataTransfers": []
}

Löschen einer Konfiguration in SCEF


Nun und das letzte - wir werden die von uns erstellte Konfiguration löschen. Verwenden Sie dazu dieselbe Adressleiste wie in der aktuellen Konfiguration, ändern Sie sie jedoch in LÖSCHEN:


Als Antwort erhalten wir:

{
    "externalId": " <ID >",
    "duration": "2020-12-31T23:59:59Z",
    " notificationDestination": " http://<IP >:<port>",
    "reliableDataService": false,
    "status": "TERMINATED"
}

Wo in der Zeile "Status" sehen wir, dass die von uns erstellte Konfiguration gelöscht wird.

Fazit


Es kann mehr als eine Dissertation zum Thema SCEF geschrieben werden. Das Thema ist umfangreich und wird bald für viele M2M-Geräte in allen Bereichen und insbesondere für das Internet der Dinge äußerst relevant. Die Hauptsache, die ich Ihnen vermitteln wollte, war, wie Sie sofort mit NIDD und SCEF arbeiten können, damit Sie es selbst herausfinden können. Aber auch gerne helfe ich Ihnen weiter: support@simcom.com (markiert für RUS Team), in dem Brief müssen Sie Ihre Kontaktdaten und ein paar Worte zu Ihrem Projekt angeben.

In den folgenden Artikeln werden wir andere Aspekte der Arbeit mit Mobilfunkmodulen sorgfältig analysieren und Sie schreiben in die Kommentare, welches Thema für Sie von Interesse sein wird.

Mein besonderer Dank gilt Sergey Novikov, dem leitenden Experten für konvergierte Lösungen und Multimediadienste.Sanov) von MTS für unschätzbare Unterstützung bei der Vorbereitung des Artikels.

Verwendete Quellen


NB-IoT: Wie funktioniert es? Teil 3: SCEF - ein einziges Fenster für den Zugang zu den Diensten des Betreibers
ETSI TS 129 122

All Articles