Im Artikel "„Als wir über die Architektur des Paketkerns des NB-IoT-Netzwerks sprachen, erwähnten wir das Erscheinen eines neuen SCEF-Knotens. Wir erklären im dritten Teil, was es ist und warum es benötigt wird.
Bei der Erstellung eines M2M-Dienstes stehen Anwendungsentwickler vor folgenden Fragen:
- wie man Geräte identifiziert;
- welcher Verifizierungs- und Authentifizierungsalgorithmus verwendet werden soll;
- welches Transportprotokoll für die Interaktion mit Geräten gewählt werden soll;
- wie man Daten zuverlässig an Geräte übermittelt;
- wie man den Datenaustausch mit ihnen organisiert und Regeln festlegt;
- wie man seinen Zustand online überwacht und Informationen darüber erhält;
- wie Sie gleichzeitig Daten an eine Gruppe Ihrer Geräte liefern;
- wie man gleichzeitig Daten von einem Gerät an mehrere Clients sendet;
- So erhalten Sie einheitlichen Zugriff auf zusätzliche Betreiberdienste zur Verwaltung Ihres Geräts.
Um sie zu lösen, ist es notwendig, proprietäre, technisch „schwere“ Lösungen zu entwickeln, was zu höheren Arbeitskosten und einer schnelleren Markteinführung von Dienstleistungen führt. Hier kommt der neue SCEF-Knoten zur Rettung.
Im Sinne von 3GPP ist SCEF (Service Capability Exposure Function) eine völlig neue Komponente der 3GPP-Architektur, deren Funktion darin besteht, die von 3GPP-Netzwerkschnittstellen bereitgestellten Dienste und Funktionen über APIs sicher offenzulegen.
In einfachen Worten ist SCEF ein Vermittler zwischen dem Netzwerk und dem Anwendungsserver (AS), ein einziges Fenster für den Zugriff auf Betreiberdienste zur Verwaltung Ihres M2M-Geräts im NB-IoT-Netzwerk über eine intuitive, standardisierte API-Schnittstelle.
SCEF verbirgt die Komplexität des Netzwerks eines Betreibers und ermöglicht es Anwendungsentwicklern, komplexe, gerätespezifische Mechanismen für die Interaktion mit Geräten zu abstrahieren.
Durch die Umwandlung von Netzwerkprotokollen in eine vertraute API für Anwendungsentwickler erleichtert die SCEF-API die Erstellung neuer Dienste und verkürzt die Markteinführungszeit. Der neue Knoten umfasst auch Funktionen zur Identifizierung/Authentifizierung mobiler Geräte und zur Definition der Regeln für den Datenaustausch zwischen Gerät und AS, sodass Anwendungsentwickler diese Funktionen nicht mehr auf ihrer Seite implementieren müssen und diese Funktionen auf die Schultern des Betreibers verlagert werden.
SCEF deckt die Schnittstellen ab, die für die Authentifizierung und Autorisierung von Anwendungsservern, die Aufrechterhaltung der UE-Mobilität, die Datenübertragung und Gerätetriggerung, den Zugriff auf zusätzliche Dienste und die Netzwerkfunktionen des Betreibers erforderlich sind.
Zum AS gibt es eine einzige T8-Schnittstelle, eine durch 3GPP standardisierte API (HTTP/JSON). Alle Schnittstellen, mit Ausnahme von T8, arbeiten auf Basis des DIAMETER-Protokolls (Abb. 1).
T6a – Schnittstelle zwischen SCEF und MME. Wird für Mobilitäts-/Sitzungsverwaltungsverfahren, die Übertragung von Nicht-IP-Daten, die Bereitstellung von Überwachungsereignissen und den Empfang von Berichten darüber verwendet.
S6t – Schnittstelle zwischen SCEF und HSS. Erforderlich für die Abonnentenauthentifizierung, die Autorisierung von Anwendungsservern, den Erhalt einer Kombination aus externer ID und IMSI/MSISDN, die Bereitstellung von Überwachungsereignissen und den Empfang von Berichten darüber.
S6m/T4 – Schnittstellen von SCEF zu HSS und SMS-C (3GPP definiert den MTC-IWF-Knoten, der zur Geräteauslösung und SMS-Übertragung in NB-IoT-Netzwerken verwendet wird. Allerdings ist in allen Implementierungen die Funktionalität dieses Knotens integriert SCEF, daher werden wir es zur Vereinfachung der Schaltung nicht separat betrachten. Wird verwendet, um Routing-Informationen zum Senden von SMS und zur Interaktion mit dem SMS-Center zu erhalten.
T8 – API-Schnittstelle für die SCEF-Interaktion mit Anwendungsservern. Über diese Schnittstelle werden sowohl Steuerbefehle als auch Verkehr übertragen.
*In Wirklichkeit gibt es mehr Schnittstellen; hier werden nur die grundlegendsten aufgeführt. Eine vollständige Liste ist in 3GPP 23.682 (4.3.2 List of Reference Points) enthalten.
Nachfolgend sind die wichtigsten Funktionen und Dienste von SCEF aufgeführt:
- Verknüpfung der SIM-Karten-ID (IMSI) mit der externen ID;
- Übertragung von Nicht-IP-Verkehr (Non-IP Data Delivery, NIDD);
- Gruppenoperationen mit externer Gruppen-ID;
- Unterstützung des Datenübertragungsmodus 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 von einem UE durch mehrere ASes;
- Unterstützung spezieller UE-Statusüberwachungsfunktionen (MONTE – Monitoring Events);
- Geräteauslösung;
- Bereitstellung von Nicht-IP-Datenroaming.
Das Grundprinzip der Interaktion zwischen AS und SCEF basiert auf dem sogenannten Schema. Abonnements. Wenn für ein bestimmtes UE Zugriff auf einen SCEF-Dienst erforderlich ist, muss der Anwendungsserver ein Abonnement erstellen, indem er einen Befehl an die spezifische API des angeforderten Dienstes sendet und als Antwort eine eindeutige Kennung erhält. Anschließend erfolgen alle weiteren Aktionen und Kommunikationen mit dem UE im Rahmen dieses Dienstes über diese Kennung.
Externe ID: Universelle Gerätekennung
Eine der wichtigsten Änderungen im Interaktionsschema zwischen AS und Geräten bei der Arbeit mit SCEF ist das Erscheinen einer universellen Kennung. Statt einer Telefonnummer (MSISDN) oder IP-Adresse, wie es im klassischen 2G/3G/LTE-Netzwerk der Fall war, wird nun die Gerätekennung für den Anwendungsserver zur „externen ID“. Es wird vom Standard in einem Format definiert, das Anwendungsentwicklern vertraut ist. @ "
Entwickler müssen keine Geräteauthentifizierungsalgorithmen mehr implementieren; das Netzwerk übernimmt diese Funktion vollständig. Die externe ID ist an IMSI gebunden, und der Entwickler kann sicher sein, dass beim Zugriff auf eine bestimmte externe ID diese mit einer bestimmten SIM-Karte interagiert. Bei der Verwendung eines SIM-Chips entsteht eine völlig einzigartige Situation, wenn die externe ID ein bestimmtes Gerät eindeutig identifiziert!
Darüber hinaus können mehrere externe IDs mit einer IMSI verknüpft werden – eine noch interessantere Situation ergibt sich, wenn die externe ID eine bestimmte Anwendung, die für einen bestimmten Dienst auf einem bestimmten Gerät verantwortlich ist, eindeutig identifiziert.
Außerdem wird eine Gruppenkennung angezeigt – die externe Gruppen-ID, die eine Reihe einzelner externer IDs enthält. Jetzt kann AS mit einer einzigen Anfrage an SCEF Gruppenoperationen initiieren – das Senden von Daten oder Steuerbefehlen an mehrere Geräte, die in einer einzigen logischen Gruppe vereint sind.
Da für AS-Entwickler der Übergang zu einer neuen Gerätekennung nicht sofort erfolgen kann, hat SCEF die Möglichkeit der AS-Kommunikation mit dem UE über eine Standardnummer – MSISDN – gelassen.
Übertragung von Nicht-IP-Verkehr (Non-IP Data Delivery, NIDD)
Im NB-IoT ist im Rahmen der Optimierung von Mechanismen zur Übertragung kleiner Datenmengen zusätzlich zu den bereits vorhandenen PDN-Typen wie IPv4, IPv6 und IPv4v6 ein weiterer Typ aufgetaucht – Nicht-IP. In diesem Fall wird dem Gerät (UE) keine IP-Adresse zugewiesen und die Daten werden ohne Verwendung des IP-Protokolls übertragen. Der Datenverkehr für solche Verbindungen kann auf zwei Arten weitergeleitet werden: klassisch – MME -> SGW -> PGW und dann durch den PtP-Tunnel zu AS (Abb. 2) oder über SCEF (Abb. 3).
Das klassische Verfahren bietet gegenüber dem IP-Verkehr keine besonderen Vorteile, außer dass es aufgrund des Fehlens von IP-Headern die Größe der übertragenen Pakete reduziert. Der Einsatz von SCEF eröffnet eine Reihe neuer Möglichkeiten und vereinfacht die Abläufe bei der Interaktion mit Geräten deutlich.
Bei der Datenübertragung per SCEF ergeben sich zwei ganz wesentliche Vorteile gegenüber dem klassischen IP-Verkehr:
Zustellung des MT-Verkehrs an das Gerät über externe ID
Um eine Nachricht an ein klassisches IP-Gerät zu senden, muss das AS dessen IP-Adresse kennen. Hier entsteht ein Problem: Da das Gerät bei der Registrierung in der Regel eine „graue“ IP-Adresse erhält, kommuniziert es mit dem Anwendungsserver, der sich im Internet befindet, über einen NAT-Knoten, bei dem die graue Adresse in weiß übersetzt wird. Die Kombination aus grauen und weißen IP-Adressen ist abhängig von den NAT-Einstellungen nur für eine begrenzte Zeit gültig. Im Durchschnitt für TCP oder UDP nicht mehr als fünf Minuten. Das heißt, wenn innerhalb von 5 Minuten kein Datenaustausch mit diesem Gerät stattfindet, bricht die Verbindung ab und das Gerät ist nicht mehr unter der weißen Adresse erreichbar, mit der die Sitzung mit AS initiiert wurde. Es gibt mehrere Lösungen:
1. Verwenden Sie Heartbeat. Sobald eine Verbindung hergestellt wurde, muss das Gerät alle paar Minuten Pakete mit dem AS austauschen und so verhindern, dass NAT-Übersetzungen geschlossen werden. Von Energieeffizienz kann hier aber keine Rede sein.
2. Überprüfen Sie bei Bedarf jedes Mal die Verfügbarkeit von Paketen für das Gerät auf dem AS – senden Sie eine Nachricht an den Uplink.
3. Erstellen Sie einen privaten APN (VRF), bei dem sich der Anwendungsserver und die Geräte im selben Subnetz befinden, und weisen Sie den Geräten statische IP-Adressen zu. Es wird funktionieren, aber es ist fast unmöglich, wenn wir über eine Flotte von Tausenden, Zehntausenden von Geräten sprechen.
4. Schließlich die am besten geeignete Option: IPv6 verwenden; NAT ist nicht erforderlich, da IPv6-Adressen direkt aus dem Internet zugänglich sind. Allerdings erhält das Gerät auch in diesem Fall bei einer erneuten Registrierung eine neue IPv6-Adresse und ist nicht mehr über die bisherige erreichbar.
Dementsprechend ist es notwendig, ein Initialisierungspaket mit einer Gerätekennung an den Server zu senden, um die neue IP-Adresse des Geräts zu melden. Warten Sie dann auf ein Bestätigungspaket von AS, was sich auch auf die Energieeffizienz auswirkt.
Diese Methoden funktionieren gut für 2G/3G/LTE-Geräte, bei denen das Gerät keine strengen Anforderungen an die Autonomie stellt und es daher keine Einschränkungen hinsichtlich Sendezeit und Datenverkehr gibt. Diese Methoden sind aufgrund ihres hohen Energieverbrauchs nicht für NB-IoT geeignet.
SCEF löst dieses Problem: Da die einzige Gerätekennung für einen AS eine externe ID ist, muss der AS nur für eine bestimmte externe ID ein Datenpaket an SCEF senden, und SCEF kümmert sich um den Rest. Falls sich das Gerät im PSM- oder eDRX-Energiesparmodus befindet, werden die Daten gepuffert und übermittelt, sobald das Gerät verfügbar ist. Wenn das Gerät für den Datenverkehr verfügbar ist, werden die Daten sofort übermittelt. Dasselbe gilt auch für Managementteams.
Der AS kann jederzeit die zwischengespeicherte Nachricht an das UE zurückrufen oder durch eine neue ersetzen.
Der Puffermechanismus kann auch bei der Übertragung von MO-Daten vom UE zum AS verwendet werden. Wenn SCEF nicht in der Lage war, Daten sofort an den AS zu liefern, beispielsweise wenn Wartungsarbeiten an den AS-Servern laufen, werden diese Pakete zwischengespeichert und garantiert zugestellt, sobald der AS verfügbar ist.
Wie oben erwähnt, wird der Zugriff auf einen bestimmten Dienst und ein UE für einen AS (und NIDD ist ein Dienst) durch Regeln und Richtlinien auf der SCEF-Seite geregelt, was die einzigartige Möglichkeit der gleichzeitigen Nutzung von Daten von einem UE durch mehrere AS ermöglicht. Diese. Wenn mehrere AS ein UE abonniert haben, sendet SCEF nach dem Empfang von Daten vom UE diese an alle abonnierten AS. Dies eignet sich gut für Fälle, in denen der Ersteller einer Flotte spezialisierter Geräte Daten zwischen mehreren Clients teilt. Wenn Sie beispielsweise ein Netzwerk von Wetterstationen aufbauen, die auf NB-IoT laufen, können Sie die Daten dieser Stationen gleichzeitig an viele Dienste verkaufen.
Garantierter Nachrichtenübermittlungsmechanismus
Reliable Data Service ist ein Mechanismus zur garantierten Zustellung von MO- und MT-Nachrichten ohne den Einsatz spezieller Algorithmen auf Protokollebene, wie beispielsweise Handshake in TCP. Dies funktioniert durch die Einfügung eines speziellen Flags in den Serviceteil der Nachricht, wenn sie zwischen dem UE und SCEF ausgetauscht wird. Ob dieser Mechanismus bei der Übertragung von Datenverkehr aktiviert wird oder nicht, wird vom AS entschieden.
Wenn der Mechanismus aktiviert ist, fügt das UE ein spezielles Flag in den Overhead-Teil des Pakets ein, wenn eine garantierte Zustellung von MO-Verkehr erforderlich ist. Beim Empfang eines solchen Pakets antwortet der SCEF dem UE mit einer Bestätigung. Wenn das UE das Bestätigungspaket nicht empfängt, wird das Paket erneut an SCEF gesendet. Das Gleiche gilt für den MT-Verkehr.
Geräteüberwachung (Überwachung von Ereignissen – MONTE)
Wie oben erwähnt, umfasst die SCEF-Funktionalität unter anderem Funktionen zur Überwachung des Zustands des UE, die sogenannten. Geräteüberwachung. Und wenn neue Identifikatoren und Datenübertragungsmechanismen (wenn auch sehr gravierende) Optimierungen bestehender Verfahren sind, dann handelt es sich bei MONTE um eine völlig neue Funktionalität, die in 2G/3G/LTE-Netzen nicht verfügbar ist. Mit MONTE kann AS Geräteparameter wie Verbindungsstatus, Kommunikationsverfügbarkeit, Standort, Roaming-Status usw. überwachen. Wir werden etwas später ausführlicher auf die einzelnen Elemente eingehen.
Wenn es erforderlich ist, ein Überwachungsereignis für ein Gerät oder eine Gerätegruppe zu aktivieren, abonniert der AS den entsprechenden Dienst, indem er den entsprechenden API-MONTE-Befehl an SCEF sendet, der Parameter wie externe ID oder externe Gruppen-ID, AS-Kennung und Überwachung enthält Typ, Anzahl der Berichte, die AS empfangen möchte. Wenn der AS berechtigt ist, die Anfrage auszuführen, stellt SCEF das Ereignis je nach Typ dem HSS oder MME zur Verfügung (Abb. 4). Wenn ein Ereignis auftritt, generiert MME oder HSS einen Bericht an SCEF, der ihn an den AS sendet.
Die Bereitstellung aller Ereignisse mit Ausnahme von „Anzahl der in einem geografischen Gebiet vorhandenen UEs“ erfolgt über HSS. Zwei Ereignisse „Änderung der IMSI-IMEI-Zuordnung“ und „Roaming-Status“ werden direkt auf HSS verfolgt, der Rest wird von HSS auf MME bereitgestellt.
Ereignisse können entweder einmalig oder periodisch sein und werden durch ihren Typ bestimmt.
Das Senden eines Berichts über ein Ereignis (Reporting) erfolgt durch den Knoten, der das Ereignis direkt an SCEF verfolgt (Abb. 5).
Wichtiger Punkt: Überwachungsereignisse können sowohl auf über SCEF angeschlossene Nicht-IP-Geräte als auch auf IP-Geräte angewendet werden, die Daten klassisch über MME-SGW-PGW übertragen.
Schauen wir uns die einzelnen Überwachungsereignisse genauer an:
Verlust der Konnektivität – informiert den AS darüber, dass das UE weder für den Datenverkehr noch für die Signalisierung mehr verfügbar ist. Das Ereignis tritt auf, wenn der „Mobile-Reachability-Timer“ für das UE auf der MME abläuft. In einer Anfrage für diese Art der Überwachung kann der AS seinen Wert „Maximale Erkennungszeit“ angeben. Wenn das UE während dieser Zeit keine Aktivität zeigt, wird der AS unter Angabe des Grundes darüber informiert, dass das UE nicht verfügbar ist. Das Ereignis tritt auch auf, wenn das UE aus irgendeinem Grund gewaltsam vom Netzwerk entfernt wurde.
* Um dem Netzwerk mitzuteilen, dass das Gerät noch verfügbar ist, wird regelmäßig ein Update-Vorgang eingeleitet – Tracking Area Update (TAU). Die Häufigkeit dieses Vorgangs wird vom Netzwerk mithilfe des Timers T3412 bzw. (T3412_extended im Fall von PSM) eingestellt, dessen Wert während des Attach-Vorgangs oder des nächsten TAU an das Gerät übertragen wird. Der Timer für die mobile Erreichbarkeit ist normalerweise mehrere Minuten länger als bei T3412. Wenn das UE vor Ablauf des „Mobile Reachability Timer“ keine TAU durchgeführt hat, geht das Netzwerk davon aus, dass es nicht mehr erreichbar ist.
UE-Erreichbarkeit – Zeigt an, wann das UE für DL-Verkehr oder SMS verfügbar wird. Dies geschieht, wenn das UE für Paging verfügbar wird (für ein UE im eDRX-Modus) oder wenn das UE in den ECM-CONNECTED-Modus wechselt (für ein UE im PSM- oder eDRX-Modus), d. h. erstellt eine TAU oder sendet ein Uplink-Paket.
Standortberichte – Diese Art von Überwachungsereignissen ermöglicht es dem AS, den Standort des UE abzufragen. Es kann entweder der aktuelle Standort (Current Location) oder der letzte bekannte Standort (Last Known Location, bestimmt durch die Zellen-ID, von der aus das Gerät zuletzt TAU durchgeführt oder Datenverkehr übertragen hat) abgefragt werden, was für Geräte im PSM- oder eDRX-Stromsparmodus relevant ist Modi. Für „Aktueller Standort“ kann der AS wiederholte Antworten anfordern, wobei die MME den AS jedes Mal informiert, wenn sich der Standort des Geräts ändert.
Änderung der IMSI-IMEI-Vereinigung – Wenn dieses Ereignis aktiviert wird, beginnt SCEF mit der Überwachung von Änderungen in der Kombination aus IMSI (SIM-Karten-ID) und IMEI (Geräte-ID). Wenn ein Ereignis eintritt, informiert AS. Kann verwendet werden, um bei geplanten Austauscharbeiten automatisch eine externe ID erneut mit einem Gerät zu verknüpfen oder als Identifikator für den Diebstahl eines Geräts zu dienen.
Roaming-Status – Diese Art der Überwachung wird von AS verwendet, um festzustellen, ob sich das UE im Heimnetzwerk oder im Netzwerk eines Roaming-Partners befindet. Optional kann das PLMN (Public Land Mobile Network) des Betreibers übermittelt werden, bei dem das Gerät registriert ist.
Kommunikationsfehler — Diese Art der Überwachung informiert den AS über Fehler in der Kommunikation mit dem Gerät, basierend auf den Gründen für den Verbindungsverlust (Freigabeursachencode), die vom Funkzugangsnetzwerk (S1-AP-Protokoll) empfangen werden. Dieses Ereignis kann dabei helfen, festzustellen, warum die Kommunikation fehlgeschlagen ist – aufgrund von Problemen im Netzwerk, z. B. wenn der eNodeb überlastet ist (Funkressourcen nicht verfügbar) oder aufgrund eines Fehlers des Geräts selbst (Funkverbindung mit verlorener UE).
Verfügbarkeit nach DDN-Ausfall – Dieses Ereignis informiert das AS darüber, dass das Gerät nach einem Kommunikationsausfall wieder verfügbar ist. Kann verwendet werden, wenn Daten an ein Gerät übertragen werden müssen, der vorherige Versuch jedoch nicht erfolgreich war, weil das UE nicht auf eine Benachrichtigung vom Netzwerk (Paging) reagiert hat und die Daten nicht übermittelt wurden. Wenn diese Art der Überwachung für das UE angefordert wurde, wird der AS darüber informiert, dass das Gerät verfügbar ist, sobald das Gerät eine eingehende Kommunikation durchführt, eine TAU durchführt oder Daten an den Uplink sendet. Da zwischen MME und S/P-GW das DDN-Verfahren (Downlink Data Notification) funktioniert, ist diese Art der Überwachung nur für IP-Geräte verfügbar.
PDN-Konnektivitätsstatus – informiert AS, wenn sich der Gerätestatus ändert (PDN-Konnektivitätsstatus) – Verbindung (PDN-Aktivierung) oder Trennung (PDN-Löschung). Dies kann vom AS genutzt werden, um die Kommunikation mit dem UE zu initiieren, oder umgekehrt, um zu erkennen, dass die Kommunikation nicht mehr möglich ist. Diese Art der Überwachung ist für IP- und Nicht-IP-Geräte verfügbar.
Anzahl der in einem geografischen Gebiet vorhandenen UEs – Diese Art der Überwachung wird vom AS verwendet, um die Anzahl der UEs in einem bestimmten geografischen Gebiet zu ermitteln.
Geräteauslösung)
In 2G/3G-Netzen war das Registrierungsverfahren im Netzwerk zweistufig: Zuerst registrierte sich das Gerät beim SGSN (Anhängeverfahren), dann aktivierte es bei Bedarf den PDP-Kontext – eine Verbindung mit dem Paket-Gateway (GGSN). Daten zu übertragen. In 3G-Netzen erfolgten diese beiden Vorgänge nacheinander, d. h. Das Gerät wartete nicht auf den Moment, in dem es Daten übertragen musste, sondern aktivierte PDP sofort nach Abschluss des Verbindungsvorgangs. Bei LTE wurden diese beiden Verfahren zu einem zusammengefasst, d. h. beim Anschließen forderte das Gerät sofort die Aktivierung der PDN-Verbindung (analog zu PDP in 2G/3G) über den eNodeB zum MME-SGW-PGW an.
NB-IoT definiert eine Verbindungsmethode als „Anhängen ohne PDN“, d. h. das UE stellt eine Verbindung her, ohne eine PDN-Verbindung herzustellen. In diesem Fall ist die Übertragung des Datenverkehrs nicht möglich, sondern nur der Empfang oder Versand von SMS. Um einen Befehl an ein solches Gerät zu senden, um PDN zu aktivieren und sich mit AS zu verbinden, wurde die Funktionalität „Geräteauslösung“ entwickelt.
Beim Empfang eines Befehls zum Verbinden eines solchen UE vom AS initiiert SCEF das Senden einer Kontroll-SMS an das Gerät über das SMS-Center. Beim Empfang einer SMS aktiviert das Gerät das PDN und verbindet sich mit dem AS, um weitere Anweisungen zu empfangen oder Daten zu übertragen.
Es kann vorkommen, dass Ihr Geräteabonnement am SCEF abläuft. Ja, das Abonnement hat eine eigene Laufzeit, die vom Betreiber festgelegt oder mit AS vereinbart wird. Nach Ablauf wird das PDN auf der MME deaktiviert und das Gerät ist für den AS nicht mehr verfügbar. In diesem Fall hilft auch die Funktionalität „Geräteauslösung“. Beim Empfang neuer Daten von AS ermittelt SCEF den Verbindungsstatus des Geräts und übermittelt die Daten per SMS-Kanal.
Abschluss
Die Funktionalität von SCEF beschränkt sich natürlich nicht auf die oben beschriebenen Dienste und wird ständig weiterentwickelt und erweitert. Derzeit sind bereits mehr als ein Dutzend Dienste für SCEF standardisiert. Jetzt haben wir nur die Hauptfunktionen angesprochen, die von Entwicklern nachgefragt werden; über den Rest werden wir in zukünftigen Artikeln sprechen.
Es stellt sich sofort die Frage: Wie erhält man Testzugriff auf diesen „Wunder“-Knoten, um mögliche Fälle vorab zu testen und zu debuggen? Alles ist sehr einfach. Jeder Entwickler kann eine Anfrage an senden [E-Mail geschützt] , in dem es ausreicht, den Zweck der Verbindung, eine Beschreibung eines möglichen Falles und Kontaktinformationen für die Kommunikation anzugeben.
Bis wir uns wieder treffen!
Autoren:
- leitender Experte der Abteilung für konvergente Lösungen und Multimediadienste Sergey Novikov ,
- Experte der Abteilung für konvergente Lösungen und Multimediadienste Alexey Lapshin
Source: habr.com