NB-IoT: Wie funktioniert es? Teil 3: SCEF – ein einheitliches Zugangsfester zu den Diensten des Betreibers

Im Artikel „NB-IoT: Wie funktioniert das? Teil 2“, sprechen wir über die Architektur des Paketkernels des NB-IoT-Netzes und erwähnen das Auftreten eines neuen Knotens, SCEF. In Teil drei erklären wir, was das ist und warum es notwendig ist.

Bei der Erstellung eines M2M-Dienstes stehen Anwendungsentwickler vor folgenden Fragen:

• Wie identifiziert man Geräte;
• Welchen Algorithmus zur Überprüfung und Bestätigung der Authentizität verwendet man;
• Welches Transportprotokoll sollte für die Interaktion mit den Geräten gewählt werden;
• Wie kann man sicherstellen, dass Daten an die Geräte geliefert werden;
• Wie organisiert man den Austausch von Daten mit ihnen und stellt Regeln auf;
• Wie kann man in Echtzeit Informationen über ihren Zustand erhalten und überwachen;
• Wie kann man Daten gleichzeitig an eine Gruppe seiner Geräte liefern;
• Wie kann man Daten von einem Gerät an mehrere Clients gleichzeitig senden;
• Wie erhält man einen einheitlichen Zugang zu zusätzlichen Betreiberdiensten zur Verwaltung seines Geräts.

Um diese Fragen zu lösen, sind oft proprietäre, technisch „schwere“ Lösungen erforderlich, was zu einem Anstieg des Arbeitsaufwands und der Time-to-Market für die Dienste führt. Hier kommt der neue Knoten SCEF zur Hilfe.

Laut 3GPP-Definition ist SCEF (Service Capability Exposure Function) eine völlig neue Komponente der 3GPP-Architektur mit der Funktion, Dienste und Möglichkeiten, die von den 3GPP-Netzschnittstellen über APIs bereitgestellt werden, sicher zu exponieren.

Einfach ausgedrückt ist SCEF ein Vermittler zwischen dem Netzwerk und dem Anwendungsserver (Application Server - AS), ein einheitliches Zugangstor zu den Diensten des Betreibers zur Verwaltung seines M2M-Geräts im NB-IoT-Netz über eine intuitiv verständliche standardisierte API-Schnittstelle.

SCEF verbirgt die Komplexität des Betreiber-Netzwerks und ermöglicht es Anwendungsentwicklern, sich von den schwierigen, spezifischen Mechanismen der Interaktion mit den Geräten abzukoppeln.

Durch die Umwandlung von Netzwerkprotokollen in die für Entwickler von Anwendungen vertraute API-Schnittstelle erleichtert SCEF die Erstellung neuer Dienste und verkürzt die Time-to-Market. Der neue Knoten umfasst auch Funktionen zur Identifizierung/Authentifizierung mobiler Geräte sowie zur Festlegung von Regeln für den Datenaustausch zwischen dem Gerät und dem AS, wodurch die Entwickler von Anwendungen entlastet werden und diese Funktionen nicht selbst implementieren müssen, sondern die Aufgaben auf den Betreiber übertragen werden.

SCEF bündelt die Interfaces, die für die Authentifizierung und Autorisierung von Anwendungsservern, die Mobilität von UE, die Datenübertragung und die Triggerung von Geräten, den Zugriff auf zusätzliche Dienste und die Möglichkeiten des Betreiber-Netzes erforderlich sind.

In Richtung AS gibt es nur ein einziges Interface T8, ein API-Interface (HTTP/JSON), das von 3GPP standardisiert wurde. Alle Interfaces, mit Ausnahme von T8, basieren auf dem DIAMETER-Protokoll (siehe Abbildung 1).

T6a – Interface zwischen SCEF und MME. Wird für Verfahren zur Mobilität/Sitzungsmanagement, zur Übertragung von non-IP-Daten, zur Provisionierung von Überwachungsereignissen und zum Erhalt von Berichten darüber verwendet.

S6t – Interface zwischen SCEF und HSS. Notwendig für die Authentifizierung von Abonnenten, die Autorisierung von Anwendungsservern, den Erhalt der Verknüpfung von external ID und IMSI/MSISDN, die Provisionierung von Überwachungsereignissen und den Erhalt von Berichten darüber.

S6m/T4 – Interfaces von SCEF zu HSS und SMS-C (im 3GPP ist der Knoten MTC-IWF definiert, der für die Triggerung von Geräten und die Übertragung von SMS in NB-IoT-Netzen verwendet wird. In allen Implementierungen ist die Funktionalität dieses Knotens in SCEF integriert, sodass wir ihn zur Vereinfachung der Darstellung nicht separat betrachten). Wird verwendet, um Routinginformationen für das Senden von SMS und die Interaktion mit dem SMS-Zentrum zu erhalten.

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

*In Wirklichkeit gibt es mehr Interfaces; hier sind nur die grundlegendsten aufgelistet. Eine vollständige Liste ist in 3GPP 23.682 (4.3.2 Liste der Referenzpunkte) enthalten.

Nachfolgend sind die Schlüssel-/Funktionsdienste 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 mit Verwendung von external group ID;
• Unterstützung des Modus zur Datenübertragung mit Bestätigung;
• Pufferung von MO (Mobile Originated) und MT (Mobile Terminated) Daten;
• Authentifizierung und Autorisierung von Geräten und Anwendungsservern;
• Gleichzeitige Nutzung von Daten eines UE durch mehrere AS;
• Unterstützung spezieller Funktionen zur Überwachung des UE-Zustands (MONTE – Monitoring Events);
• Triggerung von Geräten;
• Bereitstellung von Roaming für non-IP-Daten.

Das grundlegende Prinzip der Interaktion zwischen AS und SCEF basiert auf dem sogenannten Abonnement-Modell. Wenn ein bestimmter UE Zugang zu einem Service von SCEF benötigt, muss der Anwendungsserver ein Abonnement erstellen, indem er einen Befehl an die spezifische API des angeforderten Service sendet und als Antwort eine eindeutige Identifikationsnummer erhält. Alle weiteren Aktionen und Kommunikationen mit dem UE im Rahmen dieses Services erfolgen dann unter Verwendung dieser Identifikationsnummer.

Externe ID: universelle Geräteidentifikationsnummer

Eine der wichtigsten Änderungen im Interaktionsschema zwischen AS und Geräten bei der Arbeit über SCEF ist das Auftreten einer universellen Identifikationsnummer. Anstatt wie in klassischen 2G-/3G-/LTE-Netzen eine Telefonnummer (MSISDN) oder IP-Adresse zu verwenden, wird die Identifikation des Geräts für den Anwendungsserver zur ‚external ID‘. Diese ist im Format ‚@‘ definiert, das für Entwickler vertraut ist.

Entwickler müssen keine Geräteauthentifizierungsalgorithmen mehr implementieren; das Netzwerk übernimmt diese Funktion vollständig. Die externe ID wird an die IMSI gebunden, und der Entwickler kann sicher sein, dass er mit einer bestimmten SIM-Karte interagiert, wenn er auf eine spezifische externe ID zugreift. Bei der Verwendung eines SIM-Chips entsteht eine ganz besondere Situation, da die externe ID das spezifische Gerät eindeutig identifiziert!

Darüber hinaus können mehreren externen IDs einer IMSI zugeordnet werden – es entsteht eine noch interessantere Situation, in der die externe ID eindeutig eine bestimmte Anwendung identifiziert, die für einen bestimmten Service auf einem bestimmten Gerät verantwortlich ist.

Es wird auch eine Gruppenidentifikation eingeführt – die externe Gruppen-ID, die eine Sammlung einzelner externer IDs umfasst. Jetzt kann ein SCEF AS mit einer einzigen Anfrage gruppenweise Operationen initiieren – den Versand von Daten oder Steuerbefehlen an mehrere Geräte, die in einer einzigen logischen Gruppe zusammengefasst sind.

Da der Übergang für Entwickler AS zu einer neuen Geräteidentifikation nicht sofort erfolgen kann, hat SCEF die Möglichkeit belassen, AS über die Standardnummer – MSISDN – mit UE zu kommunizieren.

Übertragung von Non-IP-Datenverkehr (Non-IP Data Delivery, NIDD)

Im NB-IoT, im Rahmen der Optimierung der Mechanismen zur Übertragung kleiner Datenmengen, ist neben den bereits bestehenden PDN-Typen wie IPv4, IPv6 und IPv4v6 ein weiterer Typ — non-IP — hinzugekommen. In diesem Fall wird dem Gerät (UE) keine IP-Adresse zugewiesen, und Daten werden ohne Verwendung des IP-Protokolls übertragen. Der Datenverkehr für solche Verbindungen kann auf zwei Arten geroutet werden: klassisch — MME -> SGW -> PGW und weiter über einen PtP-Tunnel zu AS (siehe Abb. 2) oder unter Verwendung von SCEF (siehe Abb. 3).

Der klassische Weg bietet im Vergleich zum IP-Verkehr keine besonderen Vorteile, außer der Verringerung der Größe der übertragenen Pakete durch den Verzicht auf IP-Header. Die Nutzung von SCEF hingegen eröffnet eine ganze Reihe neuer Möglichkeiten und vereinfacht die Interaktionsprozesse mit Geräten erheblich.

Bei der Datenübertragung über SCEF ergeben sich zwei sehr wichtige Vorteile gegenüber dem klassischen IP-Verkehr:

• Die Zustellung von MT-Verkehr an das Gerät über die externe ID

Um eine Nachricht an ein klassisches IP-Gerät zu senden, muss AS dessen IP-Adresse kennen. Hierbei 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 übersetzt wird. Das Binding von grauer und öffentlicher IP-Adresse hält sich nur für eine begrenzte Zeit, abhängig von den NAT-Einstellungen. Im Durchschnitt für TCP oder UDP beträgt dies nicht mehr als fünf Minuten. Das heißt, wenn innerhalb von 5 Minuten kein Datenaustausch mit diesem Gerät stattgefunden hat, löst sich das Binding auf und das Gerät ist über die öffentliche Adresse, mit der die Sitzung mit AS initiiert wurde, nicht mehr erreichbar. Es gibt mehrere Lösungen:

1. Verwendung eines Heartbeats. Nachdem die Verbindung einmal hergestellt wurde, muss das Gerät alle paar Minuten Pakete mit AS austauschen, um zu verhindern, dass die Übersetzung auf NAT geschlossen wird. Dabei kann jedoch nicht von einer Energieeffizienz die Rede sein.

2. Jedes Mal, wenn es notwendig ist, die Verfügbarkeit von Paketen für das Gerät bei AS zu überprüfen, eine Nachricht im Uplink senden.

3. Erstellen eines privaten APN (VRF), bei dem sich der Anwendungsserver und die Geräte im selben Subnetz befinden, und den Geräten statische IP-Adressen zuweisen. Das wird funktionieren, ist jedoch fast nicht umsetzbar, wenn es sich um einen Pool von Tausenden, Zehntausenden von Geräten handelt.

4. Schließlich die passendste Option: IPv6 verwenden, da es kein NAT benötigt, da IPv6-Adressen direkt aus dem Internet verfügbar sind. Selbst in diesem Fall erhält das Gerät jedoch bei einer erneuten Registrierung eine neue IPv6-Adresse und ist nicht mehr über die vorherige erreichbar.

Daher muss ein gewisses Initialisierungspaket mit der Geräte-ID an den Server gesendet werden, um die neue IP-Adresse des Geräts zu melden. Danach muss auf das Bestätigungspaket von AS gewartet werden, was auch die Energieeffizienz beeinflusst.

Diese Methoden funktionieren gut für 2G/3G/LTE-Geräte, bei denen keine strengen Anforderungen an die Autonomie des Geräts gestellt werden und daher keine Einschränkungen bezüglich der Sendezeit und des Datenverkehrs bestehen. Für NB-IoT sind diese Methoden aufgrund ihres hohen Energieverbrauchs nicht geeignet.

SCEF löst dieses Problem: Da die einzige Geräte-ID für AS die externe ID ist, genügt es, Datenpakete an SCEF für die spezifische externe ID zu senden; SCEF kümmert sich um den Rest. Wenn sich das Gerät im Energiesparmodus (PSM) oder eDRX befindet, werden die Daten zwischengespeichert und geliefert, sobald das Gerät verfügbar ist. Wenn das Gerät jedoch für den Datenverkehr zugänglich ist, werden die Daten sofort geliefert. Das gilt auch für Steuerbefehle.

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

Der Buffering-Mechanismus kann auch bei der Übertragung von MO-Daten von UE zu AS angewendet werden. Wenn SCEF die Daten nicht sofort an AS liefern kann, beispielsweise während Wartungsarbeiten an den AS-Servern, werden diese Pakete zwischengespeichert und garantiert geliefert, 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 Regeln und Richtlinien auf der SCEF-Seite geregelt, was die einzigartige Fähigkeit zur gleichzeitigen Nutzung von Daten eines UE durch mehrere AS ermöglicht. Das heißt, wenn mehrere AS sich für ein UE angemeldet haben, wird SCEF die Daten, nachdem sie von UE empfangen wurden, an alle angemeldeten AS weiterleiten. Dies ist besonders geeignet für Fälle, in denen der Ersteller eines Netzwerks von Spezialgeräten Daten zwischen mehreren Kunden teilt. Zum Beispiel kann man, nachdem ein Netzwerk von Wetterstationen, die auf NB-IoT arbeiten, eingerichtet wurde, die Daten gleichzeitig an viele Dienste verkaufen.

Mechanismus der garantierten Nachrichtenlieferung

Reliable Data Service — Mechanismus für die garantierte Lieferung von MO- und MT-Nachrichten ohne Verwendung spezialisierter Protokollalgorithmen wie zum Beispiel Handshake in TCP. Er funktioniert durch das Setzen eines speziellen Flags im Kontrollteil der Nachricht während des Austauschs zwischen UE und SCEF. Ob dieser Mechanismus beim Traffikversand aktiviert werden soll oder nicht, entscheidet AS.

Wenn der Mechanismus aktiviert ist, setzt UE bei Bedarf für die garantierte Lieferung von MO-Traffic ein spezielles Flag im Kontrollteil des Pakets. Beim Empfang eines solchen Pakets antwortet SCEF mit einer Bestätigung an UE. Wenn UE kein Bestätigungspaket erhält, wird das Paket an SCEF erneut gesendet. Dasselbe gilt für MT-Traffic.

Geräteüberwachung (monitoring events - MONTE)

Wie bereits erwähnt, umfasst die Funktionalität von SCEF unter anderem Funktionen zur Überwachung des Zustands von UE, die sogenannte Geräteüberwachung. Neue Identifikatoren und Datenübertragungsmechanismen sind Optimierungen (auch wenn sie sehr wesentliche sind) bereits bestehender Verfahren, während MONTE eine völlig neue Funktionalität darstellt, die in 2G/3G/LTE-Netzen nicht verfügbar ist. MONTE ermöglicht es AS, Parameter des Geräts wie Verbindungsstatus, Kommunikationsverfügbarkeit, Standort, Roaming-Status usw. zu verfolgen. Wir werden später ausführlicher auf jedes dieser Themen eingehen.

Wenn es notwendig ist, ein Überwachungsereignis für ein Gerät oder eine Gruppe von Geräten zu aktivieren, kann AS sich auf den entsprechenden Dienst anmelden, indem er SCEF einen Befehl über die entsprechende API MONTE sendet, der Parameter wie external Id oder external group ID, Identifikator AS, Überwachungstyp, Anzahl der Berichte, die AS erhalten möchte, enthält. Wenn AS zur Ausführung der Anfrage autorisiert ist, provisioniert SCEF je nach Typ das Ereignis im HSS oder MME (siehe Abb. 4). Bei Eintreten des Ereignisses generieren MME oder HSS einen Bericht an SCEF, der diesen an AS sendet.

Die Provisionierung aller Ereignisse, mit Ausnahme von "Number of UEs present in a geographic area", erfolgt über HSS. Zwei Ereignisse, "Change of IMSI-IMEI Association" und "Roaming Status", werden direkt auf HSS überwacht, die übrigen werden von HSS auf MME provisioniert.
Ereignisse können einmalig oder periodisch sein und hängen von ihrem Typ ab.

Die Übermittlung des Ereignisberichts (Reporting) erfolgt durch den Knoten, der das Ereignis überwacht, direkt an SCEF (Abb. 5).

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

Betrachten wir jedes der Überwachungsereignisse genauer:

Verlust der Konnektivität — informiert AS, dass UE weder für Datenverkehr noch für Signalaustausch verfügbar ist. Das Ereignis tritt ein, wenn der "Mobile Reachability Timer" für UE bei MME abläuft. Im Antrag auf diese Art der Überwachung kann AS seinen Wert für die "Maximale Erkennungszeit" angeben – wenn UE innerhalb dieser Zeit keine Aktivität zeigt, wird AS informiert, dass UE nicht verfügbar ist, mit Angabe des Grundes. Das Ereignis tritt auch ein, wenn UE aus irgendeinem Grund gewaltsam aus dem Netzwerk entfernt wurde.

* Damit das Netzwerk weiß, dass das Gerät weiterhin verfügbar ist, initiiert es regelmäßig das Aktualisierungsverfahren – Tracking Area Update (TAU). Die Häufigkeit dieses Verfahrens wird vom Netzwerk über den Timer T3412 oder (T3412_extended im Falle von PSM) festgelegt, dessen Wert während des Attach-Verfahrens oder des nächsten TAU an das Gerät übermittelt wird. Der Mobile Reachability Timer ist normalerweise einige Minuten länger als T3412. Wenn UE vor Ablauf des "Mobile Reachability Timer" kein TAU durchgeführt hat, betrachtet das Netzwerk es als nicht mehr verfügbar.

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

Standortberichterstattung – Diese Art von Überwachungsereignissen ermöglicht es AS, Standortdaten von UE anzufordern. Es kann entweder der aktuelle Standort (Current Location) oder der zuletzt bekannte Standort (Last Known Location, bestimmt durch die Cell-ID, aus der das Gerät zuletzt TAU durchgeführt oder Verkehr übertragen hat) angefordert werden, was für Geräte relevant ist, die sich im Energiesparmodus PSM oder eDRX befinden. Für den "Current Location" kann AS wiederholte Berichte anfordern, wobei MME AS jedes Mal informiert, wenn sich der Standort des Geräts ändert.

Änderung der IMSI-IMEI-Zuordnung – Bei Aktivierung dieses Ereignisses beginnt SCEF, die Änderung der IMSI (Identifikationsnummer der SIM-Karte) und der IMEI (Geräteidentifikator) zu verfolgen. Bei Eintritt des Ereignisses informiert es AS. Es kann zur automatischen Neuzuweisung der externen ID an das Gerät während geplanter Wartungsarbeiten verwendet werden oder als Identifikator für den Diebstahl des Geräts dienen.

Roaming-Status – Diese Art der Überwachung wird von AS verwendet, um zu bestimmen, ob sich das UE im Heimnetz oder im Netzwerk eines Roaming-Partners befindet. Optional kann der PLMN (Public Land Mobile Network) des Netzbetreibers übergeben werden, in dem das Gerät registriert ist.

Kommunikationsfehler – Diese Art der Überwachung informiert AS über Störungen in der Kommunikation mit dem Gerät, basierend auf den Gründen für den Verbindungsabbruch (Release Cause Code), die vom Funkzugangsnetz (S1-AP-Protokoll) erhalten werden. Dieses Ereignis kann helfen, den Grund für den Kommunikationsfehler zu bestimmen – entweder aufgrund von Problemen im Netzwerk, beispielsweise bei Überlastung von eNodeb (Radio Resources Not Available), oder wegen eines Fehlers im Gerät selbst (Radio Connection With UE Lost).

Verfügbarkeit nach DDN-Fehler – Dieses Ereignis informiert AS, dass das Gerät nach einem Kommunikationsfehler wieder verfügbar ist. Es kann verwendet werden, wenn Daten an das Gerät gesendet werden sollen, aber der vorherige Versuch nicht erfolgreich war, da das UE nicht auf die Benachrichtigung des Netzwerks (Paging) reagiert hat und die Daten nicht zugestellt werden konnten. Wenn diese Art der Überwachung für das UE angefordert wurde, wird AS informiert, sobald das Gerät eine eingehende Kommunikation durchführt, eine TAU ausführt oder Daten im Uplink sendet. Da das DDN (Downlink Data Notification)-Verfahren zwischen MME und S/P-GW funktioniert, ist diese Art der Überwachung nur für IP-Geräte verfügbar.

PDN-Konnektivitätsstatus – Informiert AS über den Statuswechsel des Geräts (PDN-Konnektivitätsstatus) – Aktivierung (Aktivierung von PDN) oder Deaktivierung (Löschung von PDN). Dies kann von AS genutzt werden, um eine Kommunikation mit dem UE zu initiieren oder umgekehrt zu verstehen, dass eine 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 – Diese Art der Überwachung wird von AS verwendet, um die Anzahl der UEs in einem bestimmten geografischen Gebiet zu bestimmen.

Gerätetriggerung (Device triggering)

In 2G/3G-Netzen war der Registrierungsprozess in das Netzwerk zweistufig: Zuerst registrierte sich das Gerät im SGSN (Attach-Verfahren), dann wurde bei Bedarf zur Übertragung von Daten der PDP-Kontext aktiviert – die Verbindung zum Paket-Gateway (GGSN). In 3G-Netzen fanden diese beiden Prozesse nacheinander statt, d.h. das Gerät wartete nicht, bis es Daten übertragen musste, sondern aktivierte den PDP sofort nach Abschluss des Attach-Verfahrens. In LTE wurden diese beiden Verfahren zu einem einzigen zusammengefasst, d.h. beim Attach forderte das Gerät sofort die Aktivierung der PDN-Verbindung (entspricht PDP in 2G/3G) über eNodeB zu MME-SGW-PGW an.

In NB-IoT wurde eine Verbindungsmethode definiert, die als "Attach ohne PDN" bezeichnet wird, d.h. der UE führt das Attach durch, ohne eine PDN-Verbindung herzustellen. In diesem Fall ist es nicht verfügbar, um Verkehr zu übertragen, und kann nur SMS empfangen oder senden. Um diesem Gerät einen Befehl zur Aktivierung der PDN und Verbindung zu AS zu senden, wurde die Funktion "Device triggering" entwickelt.

Beim Erhalt des Befehls zur Verbindung dieses UE von AS initiiert SCEF über das SMS-Zentrum den Versand einer Steuer-SMS an das Gerät. Beim Empfang der SMS aktiviert das Gerät die PDN und verbindet sich mit AS, um weitere Anweisungen zu erhalten oder Daten zu übertragen.

Es kann Fälle geben, in denen die Anmeldung beim Gerät ausläuft. Ja, jede Anmeldung hat eine bestimmte Lebensdauer, die vom Betreiber oder in Absprache mit AS festgelegt wurde. Nach Ablauf dieser Zeit wird die PDN auf dem MME deaktiviert, und das Gerät wird für AS nicht mehr verfügbar sein. In diesem Fall hilft ebenfalls die Funktion "Device triggering". Beim Empfang neuer Daten von AS wird SCEF den Verbindungsstatus des Geräts ermitteln und die Daten über den SMS-Kanal übermitteln.

Fazit

Die Funktionalität von SCEF beschränkt sich natürlich nicht auf die oben beschriebenen Dienste und entwickelt sich ständig weiter und erweitert sich. Derzeit sind für SCEF bereits mehr als ein Dutzend Dienstleistungen standardisiert. Bislang haben wir nur die wichtigsten und nachgefragtesten Funktionen von Entwicklern angesprochen, und über die anderen werden wir in zukünftigen Artikeln berichten.

Sofort stellt sich die Frage, wie man Testzugang zu diesem "Wunder"-Knoten für vorab Testen und Debuggen möglicher Fälle erhalten kann? Alles ganz einfach. Jeder Entwickler kann eine Anfrage an iot.info@mts.ru senden, in der es ausreicht, das Ziel der Verbindung, eine Beschreibung möglicher Fälle und Kontaktdaten zur Kontaktaufnahme anzugeben.

Bis zum nächsten Mal!

Autoren:

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

Quelle: habr.com