NB-IoT: Wie funktioniert es? Teil 3: SCEF – das einheitliche Zugangstor zu den Diensten des Anbieters

Im Artikel „NB-IoT: Wie funktioniert es? Teil 2“ haben wir über die Architektur des Paketkernnetzes NB-IoT gesprochen und einen neuen Knoten, SCEF, erwähnt. In diesem dritten Teil erklären wir, was das ist und wozu es dient.

Bei der Erstellung eines M2M-Services stoßen Anwendungsentwickler auf folgende Fragen:

• Wie identifiziere ich Geräte?
• Welchen Algorithmus zur Überprüfung und Bestätigung der Authentizität sollte ich verwenden?
• Welches Transportprotokoll wähle ich für die Interaktion mit den Geräten?
• Wie gewährleiste ich die zuverlässige Datenübertragung an die Geräte?
• Wie organisiere und lege ich Regeln für den Datenaustausch mit ihnen fest?
• Wie überwache ich den Status der Geräte und erhalte Informationen in Echtzeit?
• Wie sende ich gleichzeitig Daten an eine Gruppe von Geräten?
• Wie sende ich gleichzeitig Daten von einem Gerät an mehrere Kunden?
• Wie erhalte ich einen einheitlichen Zugang zu zusätzlichen Servicediensten des Anbieters zur Verwaltung meines Geräts?

Um diese Herausforderungen zu bewältigen, müssen proprietäre, technisch „schwere“ Lösungen entwickelt werden, was zu erhöhtem Arbeitsaufwand und längeren Time-to-Market-Zeiten für die Dienstleistungen führt. Genau hier kommt der neue Knoten SCEF ins Spiel.

Nach der Definition der 3GPP ist SCEF (Service Capability Exposure Function) ein völlig neues Element der 3GPP-Architektur, dessen Funktion es ist, Dienstleistungen und Möglichkeiten, die durch 3GPP-Netzwerkschnittstellen bereitgestellt werden, sicher über APIs zu exponieren.

In einfachen Worten ist SCEF ein Vermittler zwischen dem Netzwerk und dem Anwendungserver (Application Server – AS), ein einheitliches Zugangstor zu den Diensten des Betreibers zur Verwaltung seines M2M-Geräts im NB-IoT-Netz über eine intuitive, standardisierte API-Schnittstelle.

SCEF verbirgt die Komplexität des Betreiber-Netzwerks und ermöglicht es Anwendungsentwicklern, sich von den komplexen, spezifischen Interaktionsmechanismen mit den Geräten zu distanzieren.

Durch die Umwandlung von Netzwerkprotokollen in eine für Anwendungsentwickler vertraute API-Schnittstelle erleichtert SCEF die Entwicklung neuer Dienste und verkürzt die Markteinführungszeit. Zudem umfasst der neue Knoten Funktionen zur Identifizierung/Authentifizierung mobiler Geräte und zur Festlegung von Datenübertragungsregeln zwischen dem Gerät und dem AS, wodurch Anwendungsentwickler von der Notwendigkeit befreit werden, diese Funktionen selbst zu implementieren, und somit die Verantwortung auf den Betreiber übertragen wird.

SCEF integriert die Schnittstellen, die für die Authentifizierung und Autorisierung von Anwendungsservern, die Aufrechterhaltung der Mobilität der UE, die Datenübertragung und das Triggern von Geräten, sowie den Zugang zu zusätzlichen Diensten und Möglichkeiten des Betreiber-Netzes erforderlich sind.

In Richtung AS gibt es eine einzige Schnittstelle T8, eine API-Schnittstelle (HTTP/JSON), die von 3GPP standardisiert wurde. Alle Schnittstellen, mit Ausnahme von T8, arbeiten auf Basis des DIAMETER-Protokolls (siehe Abbildung 1).

T6a ist die Schnittstelle zwischen SCEF und MME. Sie wird für die Verfahren zur Mobilitäts-/Sitzungsverwaltung, zur Übertragung von Non-IP-Daten, zur Provisionierung von Monitoring-Ereignissen und zur Erfassung von entsprechenden Berichten verwendet.

S6t – die Schnittstelle zwischen SCEF und HSS. Sie ist notwendig für die Authentifizierung des Teilnehmers, die Autorisierung von Anwendungsservern, den Erhalt der Kombination aus external ID und IMSI/MSISDN, die Provisionierung von Überwachungsereignissen und den Erhalt von Berichten dazu.

S6m/T4 – Schnittstellen von SCEF zu HSS und SMS-C (in 3GPP wird der Knoten MTC-IWF definiert, der zum Triggern von Geräten und zum Versand von SMS in NB-IoT-Netzen verwendet wird. In allen Implementierungen ist die Funktionalität dieses Knotens jedoch in SCEF integriert, sodass wir ihn zur Vereinfachung des Schemas nicht separat betrachten werden). Sie werden verwendet, um Routinginformationen für den Versand von SMS zu erhalten und um mit dem SMS-Zentrum zu interagieren.

T8 – API-Schnittstelle für die Interaktion von SCEF mit Anwendungsservern. Über diese Schnittstelle werden sowohl Steuerbefehle als auch Datenverkehr übertragen.

*Tatsächlich gibt es mehr Schnittstellen, hier sind nur die grundlegendsten aufgeführt. Eine vollständige Liste ist in 3GPP 23.682 (4.3.2 Liste der Bezugspunkte) zu finden.

Im Folgenden sind die wichtigsten Funktionen und Dienste von SCEF aufgeführt:

• Bindung der SIM-Karten-ID (IMSI) an die external ID;
• Übertragung von Non-IP-Datenverkehr (Non-IP Data Delivery, NIDD);
• Gruppenoperationen unter Verwendung der external group ID;
• Unterstützung des Bestätigungsmodus für die Datenübertragung;
• Mobile Originated (MO) und Mobile Terminated (MT) Datenpufferung;
• Authentifizierung und Autorisierung von Geräten und Anwendungsservern;
• Gleichzeitige Nutzung der Daten eines UE durch mehrere AS;
• Unterstützung spezieller Funktionen zur Überwachung des UE-Zustands (MONTE – Monitoring Events);
• Triggering von Geräten;
• Gewährleistung des Roamings von non-IP-Daten.

Das grundlegende Prinzip der Interaktion zwischen AS und SCEF basiert auf dem Schema sogenannter Abonnements. Bei Bedarf an Zugriff auf einen bestimmten Dienst muss der Anwendungsserver ein Abonnement erstellen, indem er einen Befehl an die spezifische API des angeforderten Dienstes sendet und als Antwort eine eindeutige Identifikation erhält. Alle weiteren Aktionen und Kommunikationen mit dem UE im Rahmen dieses Dienstes erfolgen dann unter Verwendung dieser Identifikation.

External ID: universelle Geräteidentifikation

Eine der bedeutendsten Änderungen im Interaktionsschema zwischen dem AS und den Geräten bei der Nutzung über SCEF ist die Einführung eines universellen Identifizierers. Anstelle der Telefonnummer (MSISDN) oder IP-Adresse, wie es im klassischen 2G/3G/LTE-Netz war, wird der Gerätetyp für den Anwendungsserver nun durch die "external ID" definiert. Diese wird standardmäßig im für Entwickler gewohnten Format "@" angegeben.

Entwickler sind nicht mehr gezwungen, Authentifizierungsalgorithmen für Geräte umzusetzen, da das Netzwerk diese Funktion vollständig übernimmt. Die external ID ist mit der IMSI verknüpft, wodurch die Entwickler sicher sein können, dass sie beim Zugriff auf eine spezifische external ID mit einer bestimmten SIM-Karte interagieren. Bei Verwendung des SIM-Moduls ergibt sich eine einzigartige Situation, in der die external ID eindeutig ein bestimmtes Gerät identifiziert!

Darüber hinaus können mehrere external IDs einer einzigen IMSI zugeordnet werden – dies schafft eine noch interessantere Situation, in der die external ID eindeutig eine spezifische Anwendung identifiziert, die für einen bestimmten Dienst auf einem bestimmten Gerät verantwortlich ist.

Es wird auch eine Gruppen-ID – die externe Gruppen-ID – eingeführt, die aus einer Reihe einzelner externer IDs besteht. Mit einem einzigen Anfrage an das SCEF AS können jetzt Gruppenoperationen initiiert werden: die Übertragung von Daten oder Steuerbefehlen an eine Vielzahl von Geräten, die zu einer logischen Gruppe zusammengefasst sind.

Da der Übergang zu einer neuen Geräte-ID für Entwickler des AS nicht sofort erfolgen kann, hat das SCEF die Möglichkeit zur Kommunikation zwischen AS und UE über die Standardnummer – MSISDN – beibehalten.

Übertragung nicht-IP-Verkehrs (Non-IP Data Delivery, NIDD)

Im NB-IoT wurde im Rahmen der Optimierung der Mechanismen zur Übertragung kleiner Datenmengen neben den bereits bestehenden PDN-Typen wie IPv4, IPv6 und IPv4v6 ein weiterer Typ – Non-IP – eingeführt. In diesem Fall erhält das Gerät (UE) keine IP-Adresse, und die Daten werden ohne Verwendung des IP-Protokolls übertragen. Der Verkehr für solche Verbindungen kann auf zwei Arten geroutet werden: klassisch – MME -> SGW -> PGW und dann über einen PtP-Tunnel bis zum AS (Abb. 2) oder unter Verwendung des SCEF (Abb. 3).

Die klassische Methode bietet im Vergleich zu IP-Traffic keine wesentlichen Vorteile, abgesehen von der Reduzierung der übertragenen Paketgrößen aufgrund des Fehlens von IP-Headern. Die Nutzung von SCEF hingegen eröffnet eine Vielzahl neuer Möglichkeiten und vereinfacht die Interaktion mit Geräten erheblich.

Bei der Datenübertragung über SCEF ergeben sich zwei sehr wichtige Vorteile gegenüber klassischem IP-Traffic:

Die Zustellung von MT-Traffic an das Gerät über externe IDs.

Um eine Nachricht an ein klassisches IP-Gerät zu senden, muss das AS die IP-Adresse des Geräts kennen. Hier tritt ein Problem auf: Da das Gerät bei der Registrierung normalerweise eine „graue“ IP-Adresse erhält, kommuniziert es mit dem Anwendungsserver, der im Internet liegt, über einen NAT-Knoten, wo die graue Adresse in eine öffentliche Adresse übersetzt wird. Die Zuordnung von grauer zu öffentlicher IP-Adresse besteht nur für einen begrenzten Zeitraum, abhängig von den NAT-Einstellungen. Im Durchschnitt sind dies für TCP oder UDP nicht mehr als fünf Minuten. Das bedeutet, wenn innerhalb von fünf Minuten kein Datenaustausch mit diesem Gerät stattfindet, fällt die Zuordnung auseinander, und das Gerät ist nicht mehr unter der öffentlichen Adresse erreichbar, mit der die Sitzung mit dem AS initiiert wurde. Es gibt mehrere Lösungen:

1. Verwenden Sie Heartbeat. Nachdem eine Verbindung einmal hergestellt wurde, sollte das Gerät alle paar Minuten Pakete mit dem AS austauschen, um zu verhindern, dass die Übertragung am NAT geschlossen wird. Eine energieeffiziente Lösung ist hierbei jedoch nicht möglich.

2. Jedes Mal, wenn es nötig ist, das Vorhandensein von Paketen für das Gerät beim AS zu überprüfen – eine Nachricht an das Uplink senden.

3. Erstellen Sie ein privates APN (VRF), in dem der Anwendungsserver und die Geräte im selben Subnetz sind, und weisen Sie den Geräten statische IP-Adressen zu. Es wird funktionieren, aber es ist fast unmöglich, wenn es sich um einen Pool von Tausenden oder Zehntausenden von Geräten handelt.

4. Schließlich die beste Option: Verwenden Sie IPv6, da dafür kein NAT benötigt wird, da IPv6-Adressen direkt aus dem Internet erreichbar sind. Allerdings erhält das Gerät bei einer erneuten Registrierung eine neue IPv6-Adresse und ist nicht mehr über die vorherige verfügbar.

Daher ist es notwendig, ein Initialisierungspaket mit der Gerätekennung an den Server zu senden, um die neue IP-Adresse des Geräts zu kommunizieren. Danach muss auf das Bestätigungspaket vom AS gewartet werden, was ebenfalls die Energieeffizienz beeinträchtigt.

Diese Methoden sind gut geeignet für 2G/3G/LTE-Geräte, bei denen keine strengen Anforderungen an die Akkulaufzeit bestehen und somit keine Einschränkungen hinsichtlich der Online-Zeit und des Traffics bestehen. Für NB-IoT sind diese Methoden aufgrund ihres hohen Energieverbrauchs nicht geeignet.

SCEF löst dieses Problem: Da die einzige Gerätekennung für AS die externe ID ist, genügt es, dass AS ein Datenpaket an SCEF für die spezifische externe ID sendet, während sich SCEF um den Rest kümmert. Wenn das Gerät im Energiesparmodus PSM oder eDRX ist, werden die Daten zwischengespeichert und geliefert, sobald das Gerät verfügbar ist. Ist das Gerät jedoch für den Verkehr verfügbar, werden die Daten sofort zugestellt. Dies gilt auch für Steuerbefehle.

Jederzeit kann AS die zwischengespeicherte Nachricht an das UE zurückziehen oder durch eine neue ersetzen.

Der Mechanismus zur Pufferung kann auch bei der Übertragung von MO-Daten vom UE zu AS angewendet werden. Wenn SCEF die Daten nicht sofort an AS zustellen kann, etwa aufgrund von Wartungsarbeiten an den AS-Servern, werden diese Pakete zwischengespeichert und garantiert ausgeliefert, sobald AS verfügbar ist.

Wie bereits erwähnt, wird der Zugang zu einem bestimmten Dienst und UE für AS (wobei NIDD ein Dienst ist) durch die Regeln und Richtlinien auf Seiten des SCEF geregelt. Dies ermöglicht eine einzigartige Möglichkeit der gleichzeitigen Nutzung von Daten eines einzelnen UE durch mehrere AS. Das bedeutet, dass wenn mehrere AS sich für ein einzelnes UE angemeldet haben, SCEF nach dem Empfang der Daten von UE diese an alle angemeldeten AS weiterleitet. Dies eignet sich gut für Szenarien, in denen der Ersteller eines Parks spezialisierter Geräte Daten zwischen mehreren Kunden teilt. Zum Beispiel kann man durch die Erstellung eines Netzwerks von Wetterstationen, die auf NB-IoT basieren, die Daten gleichzeitig an viele Dienste verkaufen.

Mechanismus für garantierte Nachrichtenlieferung

Reliable Data Service — ein Mechanismus zur garantierten Lieferung von MO- und MT-Nachrichten ohne den Einsatz spezialisierter Algorithmen auf Protokollebene, wie beispielsweise Handshakes in TCP. Er funktioniert durch die Aktivierung eines speziellen Flags in der Steuerungskomponente der Nachricht während des Austauschs zwischen UE und SCEF. Ob dieser Mechanismus bei der Übertragung von Daten aktiviert werden soll oder nicht, entscheidet das AS.

Wenn der Mechanismus aktiviert ist, setzt das UE bei Bedarf für die garantierte Lieferung von MO-Traffic ein spezielles Flag in den Header des Pakets. Wenn das SCEF ein solches Paket erhält, antwortet es dem UE mit einer Bestätigung. Falls das UE kein Bestätigungspaket erhält, wird das Paket in Richtung SCEF erneut gesendet. Dasselbe gilt auch für MT-Traffic.

Gerätemonitoring (Monitoring-Events - MONTE)

Wie bereits erwähnt, umfasst die Funktionalität des SCEF unter anderem die Überwachung des Zustands der UE, das sogenannte Gerätemonitoring. Während neue Identifikatoren und Datenübertragungsmechanismen Optimierungen (auch wenn sie sehr bedeutend sind) bereits bestehender Verfahren darstellen, bietet MONTE eine völlig neue Funktionalität, die in 2G/3G/LTE-Netzen nicht verfügbar ist. MONTE ermöglicht es der AS, Parameter wie den Verbindungsstatus, die Kommunikationsverfügbarkeit, den Standort, den Roaming-Status usw. zu verfolgen. Im Folgenden werden wir jedes dieser Aspekte näher erläutern.

Um ein Monitoring-Ereignis für ein Gerät oder eine Gruppe von Geräten zu aktivieren, abonniert das AS den entsprechenden Service, indem es einen Befehl über die passende API MONTE an das SCEF sendet. Dabei werden Parameter wie die externe ID oder die externe Gruppen-ID, die AS-ID, der Monitoring-Typ und die Anzahl der Berichte, die das AS empfangen möchte, einbezogen. Sofern das AS für die Anfrage autorisiert ist, provisioniert das SCEF je nach Typ das Ereignis auf dem HSS oder MME (siehe Abb. 4). Bei Eintritt eines Ereignisses generieren MME oder HSS einen Bericht für das SCEF, welches diesen an das AS sendet.

Die Provisionierung aller Ereignisse, mit Ausnahme von "Anzahl der in einem geografischen Gebiet vorhandenen UEs", erfolgt über den HSS. Die beiden Ereignisse "Änderung der IMSI-IMEI-Zuordnung" und "Roaming-Status" werden direkt auf dem HSS verfolgt, während die anderen vom HSS auf dem MME provisioniert werden.
Ereignisse können einmalig oder periodisch sein und hängen von ihrem Typ ab.

Der Versand des Ereignisberichts (Reporting) erfolgt durch den Knoten, der das Ereignis überwacht, direkt an das SCEF (siehe Abb. 5).

Wichtiger Punkt: Überwachungsereignisse können sowohl auf non-IP-Geräte, die über SCEF verbunden sind, als auch auf IP-Geräte angewendet werden, die Daten auf herkömmliche Weise über MME-SGW-PGW übertragen.

Werfen wir einen genaueren Blick auf jedes der Überwachungsereignisse:

Verlust der Konnektivität — informiert AS, dass das UE weder für Datenverkehr noch für Signalaustausch verfügbar ist. Dieses Ereignis tritt ein, wenn der "Mobile Reachability Timer" für das UE im MME abläuft. In einer Anfrage für diesen Typ der Überwachung kann AS seinen Wert für die "Maximale Erkennungszeit" angeben – wenn während dieser Zeit keine Aktivität des UE festgestellt wird, wird AS darüber informiert, dass das UE nicht verfügbar ist, einschließlich des Grundes. Das Ereignis tritt ebenfalls ein, wenn das UE aus irgendeinem Grund gezwungen aus dem Netzwerk entfernt wurde.

* Damit das Netzwerk weiß, dass das Gerät weiterhin verfügbar ist, initiiert es regelmäßig den Aktualisierungsprozess — Tracking Area Update (TAU). Die Häufigkeit dieses Verfahrens wird vom Netzwerk über den Timer T3412 (oder T3412_extended im Fall von PSM) festgelegt, dessen Wert dem Gerät während des Attach- oder eines zeitlichen TAU-Verfahrens übermittelt wird. Der Mobile Reachability Timer ist normalerweise einige Minuten länger als T3412. Wenn die UE bis zum Ablauf des „Mobile Reachability Timer“ kein TAU durchgeführt hat, wird sie von dem Netzwerk als weniger verfügbar angesehen.

UE-Erreichbarkeit – Zeigt an, wann die UE für DL-Traffic oder SMS erreichbar wird. Dies geschieht, wenn die UE für Paging verfügbar wird (für UE im eDRX-Modus) oder wenn die UE in den ECM-CONNECTED Modus wechselt (für UE im PSM oder eDRX-Modus), d.h. TAU durchführt oder ein Uplink-Paket sendet.

Standortberichterstattung – Dieser Monitoring-Typ ermöglicht es dem AS, Daten über den Standort des UE abzurufen. Es kann entweder der aktuelle Standort (Current Location) oder der zuletzt bekannte Standort (Last Known Location, bestimmt durch die Cell ID, von der das Gerät zuletzt TAU durchgeführt oder Daten übertragen hat) angefordert werden, was für Geräte im Energiesparmodus PSM oder eDRX relevant ist. Für "Current Location" kann das AS wiederkehrende Berichte anfordern, wobei das MME AS jedes Mal informiert, wenn sich der Standort des Geräts ändert.

Änderung der IMSI-IMEI-Zuordnung – Sobald dieses Ereignis aktiviert ist, beginnt das SCEF, die Änderung der Zuordnung von IMSI (Identifikator der SIM-Karte) und IMEI (Identifikator des Geräts) zu überwachen. Bei Eintreten des Ereignisses wird das AS informiert. Dies kann zur automatischen Neuzuweisung der externen ID an das Gerät während geplanter Wartungsarbeiten verwendet werden oder als Identifikator für einen Diebstahl des Geräts dienen.

Roaming-Status – Diese Art der Überwachung wird vom AS verwendet, um festzustellen, ob sich das UE im Heimnetz oder im Netz eines Partner-Roaming-Anbieters befindet. Optional kann der PLMN (Public Land Mobile Network) des Betreibers übertragen werden, bei dem das Gerät registriert ist.

Kommunikationsfehler Dieser Typ der Überwachung informiert das AS über Kommunikationsausfälle mit dem Gerät, basierend auf den Ursachen des Verbindungsabbruchs (Release Cause Code), die vom Funkzugangsnetz (S1-AP-Protokoll) erhalten werden. Dieses Ereignis kann helfen festzustellen, warum die Kommunikation abgebrochen wurde — aufgrund von Netzwerkproblemen, zum Beispiel bei einer Überlastung des eNodeb (Radioressourcen nicht verfügbar) oder aufgrund eines Fehlers im Gerät selbst (Radio Connection With UE Lost).

Verfügbarkeit nach DDN-Ausfall Dieses Ereignis informiert das AS darüber, dass das Gerät nach einem Kommunikationsausfall wieder verfügbar ist. Es kann verwendet werden, wenn Daten an das Gerät übertragen werden müssen, die vorherige Versuch jedoch nicht erfolgreich war, da das UE nicht auf die Benachrichtigung des Netzwerks (Paging) reagiert hat und die Daten nicht zugestellt wurden. Wenn dieser Typ der Überwachung für das UE angefordert wurde, wird das AS informiert, sobald das Gerät eine eingehende Kommunikation herstellt, eine TAU durchführt oder Daten im Uplink sendet. Da das DDN (Downlink Data Notification)-Verfahren zwischen MME und S/P-GW arbeitet, ist diese Art der Überwachung nur für IP-Geräte verfügbar.

PDN-Konnektivitätsstatus – informiert das AS über Änderungen des Gerätestatus (PDN-Konnektivitätsstatus) – bei der Verbindung (Aktivierung des PDN) oder der Trennung (Löschung des PDN). Dies kann vom AS genutzt werden, um die Kommunikation mit dem UE zu initiieren oder umgekehrt, um zu verstehen, dass die Kommunikation nicht mehr möglich ist. Diese Art der Überwachung ist sowohl für IP- als auch für non-IP-Geräte verfügbar.

Anzahl der UEs in einem geografischen Bereich – dieser Überwachungsmodus wird vom AS verwendet, um die Anzahl der UEs in einem bestimmten geografischen Gebiet zu bestimmen.

Gerätetriggering (Device triggering)

In 2G/3G-Netzen war das Verfahren zur Netzregistrierung zweistufig: Zuerst registrierte sich das Gerät im SGSN (Attach-Verfahren) und aktivierte dann bei Bedarf den PDP-Kontext – die Verbindung zum Paketgateway (GGSN), um Daten zu übertragen. In 3G-Netzen liefen diese beiden Verfahren nacheinander ab, d.h. das Gerät wartete nicht auf den Moment, in dem Daten übertragen werden sollten, sondern aktivierte den PDP sofort nach Abschluss des Attach-Verfahrens. In LTE wurden diese beiden Verfahren zu einem kombiniert, d.h. beim Attach forderte das Gerät sofort die Aktivierung der PDN-Verbindung (entspricht dem PDP in 2G/3G) über eNodeB an MME-SGW-PGW.

Im NB-IoT gibt es die Möglichkeit der Verbindung, die als "attach without PDN" bezeichnet wird. Das bedeutet, dass das UE sich verbindet, ohne eine PDN-Verbindung herzustellen. In diesem Fall ist es nicht möglich, Daten zu übertragen; es kann lediglich SMS empfangen oder gesendet werden. Um einem solchen Gerät den Befehl zur Aktivierung der PDN und zur Verbindung mit AS zu übermitteln, wurde die Funktion "Device triggering" entwickelt.

Wenn ein Befehl zur Verbindung eines solchen UE von AS empfangen wird, initiiert SCEF über das SMS-Zentrum den Versand einer Steuer-SMS an das Gerät. Nach Erhalt der SMS aktiviert das Gerät die PDN und verbindet sich mit AS, um weitere Anweisungen zu erhalten oder Daten zu übermitteln.

Es kann vorkommen, dass das SCEF die Abonnements für das Gerät abläuft. Ja, das Abonnement hat eine Lebensdauer, die vom Betreiber oder in Übereinstimmung mit AS festgelegt wurde. Nach Ablauf wird die PDN auf dem MME deaktiviert, und das Gerät wird für AS unzugänglich. In diesem Fall kann auch die Funktion "Device triggering" helfen. Nach Erhalt neuer Daten von AS wird SCEF den Verbindungsstatus des Geräts überprüfen und die Daten über den SMS-Kanal übermitteln.

Fazit

Die Funktionen von SCEF sind natürlich nicht auf die oben beschriebenen Dienste beschränkt und entwickeln sich ständig weiter. Aktuell sind bereits über ein Dutzend Dienste für SCEF standardisiert. Hier haben wir nur die grundlegenden und gefragtesten Funktionen für Entwickler angesprochen; über die anderen werden wir in zukünftigen Artikeln sprechen.

Sofort stellt sich die Frage, wie man Testzugang zu diesem „Wunder“-Knoten für vorläufige Tests und die Fehlersuche bei möglichen Anwendungen erhalten kann. Es ist ganz einfach. Jeder Entwickler kann eine Anfrage an iot.info@mts.ru senden, in der er den Zweck der Verbindung, eine Beschreibung des möglichen Anwendungsfalls und Kontaktdaten für die Rückmeldung angibt.

Bis zum nächsten Mal!

Autoren:

• Senior Expert für konvergente Lösungen und Multimedia-Services, Sergey Novikov sanov,
• Expert für konvergente Lösungen und Multimedia-Services, Alexey Lapshin aslapsh

Quelle: habr.com