In dem Artikel " NB-IoT: Wie funktioniert es?" Teil 2 “, in dem es um die Architektur des Paketkerns des NB-IoT-Netzwerks ging, erwähnten wir das Auftreten eines neuen SCEF-Knotens. Wir erklären im dritten Teil, was es ist und warum es benötigt wird.
Beim Erstellen eines M2M-Dienstes stehen Anwendungsentwickler vor folgenden Fragen:
- So identifizieren Sie Geräte
- Welcher Authentifizierungs- und Authentifizierungsalgorithmus verwendet werden soll;
- welches Transportprotokoll für die Interaktion mit Geräten verwendet werden soll;
- So liefern Sie garantiert Daten an Geräte
- wie man Regeln für den Datenaustausch mit ihnen organisiert und festlegt;
- wie man Informationen über ihren Status online überwacht und empfängt;
- wie man gleichzeitig Daten an eine Gruppe ihrer Geräte liefert;
- So senden Sie gleichzeitig Daten von einem Gerät an mehrere Clients.
- So erhalten Sie einen einheitlichen Zugriff auf zusätzliche Betreiberdienste für die Verwaltung Ihres Geräts.
Um sie zu lösen, müssen proprietäre, technisch „schwere“ Lösungen erstellt werden, was zu einer Erhöhung der Arbeitskosten und der Markteinführungszeit führt. Hier kommt der neue SCEF-Knoten zur Rettung.
Gemäß der Definition von 3GPP ist SCEF (Service Capability Exposure Function) eine völlig neue Komponente der 3GPP-Architektur, deren Funktion darin besteht, die von 3GPP-Netzwerkschnittstellen über die API bereitgestellten Dienste und Funktionen sicher verfügbar zu machen.
Mit einfachen Worten, SCEF ist ein Vermittler zwischen dem Netzwerk und dem Anwendungsserver (AS), einem einzigen Zugriffsfenster auf Betreiberdienste zur Verwaltung seines M2M-Geräts im NB-IoT-Netzwerk über eine intuitive standardisierte API.
SCEF verbirgt die Komplexität des Netzes des Betreibers und ermöglicht es Anwendungsentwicklern, von komplexen, spezifischen Mechanismen für die Interaktion mit Geräten zu abstrahieren.
Durch die Umwandlung von Netzwerkprotokollen in vertraute Anwendungsentwickler erleichtert die SCEF-API die Erstellung neuer Dienste und verkürzt die Markteinführungszeit. Außerdem umfasst der neue Knoten die Funktionen zur Identifizierung / Authentifizierung mobiler Geräte, zur Festlegung der Regeln für den Datenaustausch zwischen dem Gerät und AS, um die Implementierung dieser Funktionen von Anwendungsentwicklern auf ihrer Seite zu vermeiden und diese Funktionen auf die Schultern des Bedieners zu übertragen.
SCEF schließt die für die Authentifizierung und Autorisierung von Anwendungsservern erforderlichen Schnittstellen, um die UE-Mobilität, die Datenübertragung und das Auslösen von Geräten, den Zugriff auf zusätzliche Dienste und die Funktionen des Betreibernetzwerks aufrechtzuerhalten.
In Richtung AS gibt es eine einzige T8-Schnittstelle, eine API (HTTP / JSON), ein standardisiertes 3GPP. Alle Schnittstellen mit Ausnahme von T8 arbeiten auf Basis des DIAMETER-Protokolls (Abb. 1).
T6a ist die Schnittstelle zwischen SCEF und MME. Wird für Mobilitäts- / Sitzungsverwaltungsverfahren, Nicht-IP-Datenübertragung, Bereitstellung von Überwachungsereignissen und Empfang von Berichten darüber verwendet.
S6t ist die Schnittstelle zwischen SCEF und HSS. Es ist erforderlich, um den Abonnenten zu authentifizieren, Anwendungsserver zu autorisieren, eine Reihe externer IDs und IMSI / MSISDN zu erhalten, Überwachungsereignisse bereitzustellen und Berichte darüber zu erhalten.
S6m / T4 - Schnittstellen von SCEF zu HSS und SMS-C (der MTC-IWF-Knoten ist in 3GPP definiert, das zum Auslösen von Geräten und zum Senden von SMS in NB-IoT-Netzwerken verwendet wird. In allen Implementierungen ist jedoch die Funktionalität dieses Knotens in SCEF integriert, z Vereinfachung des Schemas werden wir nicht gesondert betrachten). Wird verwendet, um Routing-Informationen zum Senden von SMS und zur Interaktion mit dem SMS-Center abzurufen.
T8 - SCEF-API für die Interaktion mit Anwendungsservern. Über diese Schnittstelle werden sowohl Steuerbefehle als auch Verkehr übertragen.
* In Wirklichkeit gibt es mehr Schnittstellen, nur die grundlegendsten sind hier aufgelistet. Eine vollständige Liste finden Sie in 3GPP 23.682 (4.3.2 Liste der Referenzpunkte).
Nachfolgend sind die wichtigsten Funktionen und Dienste von SCEF aufgeführt:
- Binden einer SIM-Karten-ID (IMSI) an eine externe ID;
- Nicht-IP-Verkehrszustellung (Non-IP Data Delivery, NIDD);
- Gruppenoperationen unter Verwendung einer externen Gruppen-ID;
- Unterstützung des Datenübertragungsmodus mit Bestätigung;
- Puffern von MO- (Mobile Originated) und MT- (Mobile Terminated) Daten;
- Authentifizierung und Autorisierung von Geräten und Anwendungsservern;
- gleichzeitige Verwendung der Daten eines UE durch mehrere AS;
- Unterstützung spezieller Funktionen zur Überwachung des Status von UE (MONTE - Monitoring Events);
- Geräteauslösung;
- Bereitstellung von Roaming-Nicht-IP-Daten.
Das Grundprinzip der Interaktion zwischen AS und SCEF basiert auf dem sogenannten Abonnements. Wenn Sie auf einen SCEF-Dienst für ein bestimmtes UE zugreifen müssen, 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. Danach finden alle weiteren Aktionen und Kommunikationen mit dem UE im Rahmen dieses Dienstes unter Verwendung dieser Kennung statt.
Externe ID: universelle GerätekennungEine der wichtigsten Änderungen im Interaktionsschema zwischen AS und Geräten bei der Arbeit mit SCEF ist die Entstehung einer universellen Kennung. Anstelle einer Telefonnummer (MSISDN) oder IP-Adresse wie im klassischen 2G / 3G / LTE-Netzwerk wird die Gerätekennung für den Anwendungsserver nun zu „externer ID“. Es wird durch den Standard in dem Format definiert, das Anwendungsentwicklern "<Local Identifier> @ <Domain Identifier>" bekannt ist.
Entwickler müssen keine Geräteauthentifizierungsalgorithmen mehr implementieren, das Netzwerk übernimmt diese Funktion vollständig. Die externe ID ist an IMSI angehängt, und der Entwickler kann sicher sein, dass er unter Bezugnahme auf eine bestimmte externe ID mit einer bestimmten SIM-Karte interagiert. Bei Verwendung eines SIM-Chips ergibt sich eine allgemein eindeutige Situation, wenn die externe ID ein bestimmtes Gerät eindeutig identifiziert!
Darüber hinaus können mehrere externe IDs an eine IMSI angehängt werden. Eine noch interessantere Situation ergibt sich, wenn die externe ID eine bestimmte Anwendung eindeutig identifiziert, die für einen bestimmten Dienst auf einem bestimmten Gerät verantwortlich ist.
Eine Gruppenkennung wird ebenfalls angezeigt - eine externe Gruppen-ID, die eine Reihe separater externer IDs enthält. Mit einer einzigen Anforderung an SCEF kann AS jetzt Gruppenoperationen initiieren - Daten oder Steuerbefehle an mehrere Geräte senden, die zu einer einzigen logischen Gruppe zusammengefasst sind.
Aufgrund der Tatsache, dass für AS-Entwickler der Übergang zu einer neuen Gerätekennung nicht sofort erfolgen kann, hat SCEF die Möglichkeit einer AS-Kommunikation mit dem UE über die Standardnummer - MSISDN - verlassen.
Non-IP Data Delivery (NIDD)In NB-IoT wurde im Rahmen der Optimierung der Mechanismen für die Übertragung kleiner Datenmengen zusätzlich zu den vorhandenen PDN-Typen wie IPv4, IPv6 und IPv4v6 ein anderer Typ angezeigt - Nicht-IP. In diesem Fall wird dem Gerät (UE) keine IP-Adresse zugewiesen, und Daten werden ohne Verwendung des IP-Protokolls übertragen. Der Verkehr für solche Verbindungen kann auf zwei Arten geleitet werden: klassisch - MME -> SGW -> PGW und dann durch den PtP-Tunnel zu AS (Abb. 2) oder mithilfe von SCEF (Abb. 3).
Die klassische Methode bietet keine besonderen Vorteile gegenüber dem IP-Verkehr, außer dass die Größe der übertragenen Pakete aufgrund des Fehlens von IP-Headern verringert wird. Die Verwendung von SCEF eröffnet eine Reihe neuer Möglichkeiten und vereinfacht die Verfahren zur Interaktion mit Geräten erheblich.
Bei der Datenübertragung über SCEF gibt es zwei sehr wichtige Vorteile gegenüber dem klassischen IP-Verkehr:
Übermittlung des MT-Verkehrs an das Gerät per externer IDUm eine Nachricht an ein klassisches IP-Gerät zu senden, muss der AS seine IP-Adresse kennen. Hier tritt ein Problem auf: Da sich das Gerät normalerweise mit einer „grauen“ IP-Adresse registriert, kommuniziert es über den NAT-Knoten mit dem Anwendungsserver, der sich im Internet befindet, wo die graue Adresse in Weiß übersetzt wird. Eine Reihe von grauen und weißen IP-Adressen ist abhängig von den NAT-Einstellungen zeitlich begrenzt. 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 stattgefunden hat, wird das Bundle aufgelöst und das Gerät ist unter der weißen Adresse, mit der die Sitzung mit AS initiiert wurde, nicht mehr zugänglich. Es gibt verschiedene Lösungen:
1. Verwenden Sie einen Herzschlag. Sobald eine Verbindung hergestellt ist, muss das Gerät alle paar Minuten mit AS-Paketen austauschen, um zu verhindern, dass NAT-Übersetzungen geschlossen werden. Von Energieeffizienz kann jedoch keine Rede sein.
2. Suchen Sie bei Bedarf jedes Mal auf dem AS nach Paketen für das Gerät - senden Sie eine Nachricht an den Uplink.
3. Erstellen Sie einen privaten APN (VRF), in 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 dies ist fast unmöglich, wenn es um eine Flotte von Tausenden, Zehntausenden von Geräten geht.
4. Schließlich die am besten geeignete Option: Verwenden Sie IPv6, es wird kein NAT benötigt, da auf IPv6-Adressen direkt über das Internet zugegriffen werden kann. Selbst in diesem Fall erhält das Gerät bei einer erneuten Registrierung eine neue IPv6-Adresse und ist bei der vorherigen nicht mehr verfügbar.
Dementsprechend ist es notwendig, ein bestimmtes Initialisierungspaket mit der Gerätekennung an den Server zu senden, um die neue IP-Adresse des Geräts zu melden. Warten Sie dann auf das Bestätigungspaket von AS, das sich auch auf die Energieeffizienz auswirkt.
Diese Methoden eignen sich gut für 2G / 3G / LTE-Geräte, bei denen für das Gerät keine strengen Anforderungen an die Autonomie gelten und daher keine zeitlichen Beschränkungen für Luft und Verkehr 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 eine externe ID ist, reicht es für AS aus, ein Datenpaket für eine bestimmte externe ID an SCEF zu senden. SCEF kümmert sich um den Rest. Befindet sich das Gerät im Energiesparmodus PSM oder eDRX, 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 geliefert. Gleiches gilt für Managementteams.
Der AS kann die gepufferte Nachricht jederzeit an das UE zurückziehen oder durch eine neue ersetzen.
Der Puffermechanismus kann auch verwendet werden, wenn MO-Daten vom UE zur AS-Seite übertragen werden. Wenn SCEF nicht in der Lage war, Daten sofort an AS zu übermitteln, z. B. wenn Servicearbeiten auf AS-Servern ausgeführt werden, werden diese Pakete gepuffert und garantiert zugestellt, sobald der AS verfügbar ist.
Wie oben erwähnt, wird der Zugriff auf einen bestimmten Dienst und ein bestimmtes UE für AS (und NIDD ist ein Dienst) durch Regeln und Richtlinien auf der SCEF-Seite geregelt, wodurch die einzigartige Fähigkeit realisiert werden kann, die Daten eines UE von mehreren AS gleichzeitig zu verwenden. Das heißt Wenn mehrere AS ein UE abonniert haben, sendet SCEF sie nach dem Empfang von Daten vom UE an alle signierten AS. Dies ist gut geeignet für Fälle, in denen der Ersteller einer Flotte spezialisierter Geräte Daten zwischen mehreren Clients fummelt. Wenn Sie beispielsweise ein Netzwerk von Wetterstationen erstellen, die mit NB-IoT betrieben werden, können Sie Daten von diesen gleichzeitig an viele Dienste verkaufen.
Garantierter Mechanismus zur NachrichtenübermittlungZuverlässiger Datendienst - ein Mechanismus für die garantierte Zustellung von MO- und MT-Nachrichten ohne Verwendung spezieller Algorithmen auf Protokollebene, wie z. B. Handshake in TCP. Es funktioniert, indem während des Austauschs zwischen dem UE und dem SCEF ein spezielles Flag in den Dienstteil der Nachricht aufgenommen wird. Ob dieser Mechanismus bei der Übertragung von Datenverkehr aktiviert werden soll oder nicht, entscheidet der AS.
Wenn der Mechanismus aktiviert ist, enthält das UE, falls erforderlich, die garantierte Zustellung von MO-Verkehr ein spezielles Flag im Serviceteil des Pakets. Nach Erhalt eines solchen Pakets antwortet der SCEF dem UE mit einer Bestätigung. Wenn das UE kein Bestätigungspaket empfangen hat, wird das Paket an SCEF weitergeleitet. Das gleiche passiert für den MT-Verkehr.
Geräteüberwachung (Überwachungsereignisse - MONTE)Wie oben erwähnt, umfasst die SCEF-Funktion unter anderem Funktionen zum Überwachen des Zustands des UE, die sogenannten Geräteüberwachung. Und wenn neue Kennungen und Datenübertragungsmechanismen Optimierungen (wenn auch sehr schwerwiegend) bestehender Verfahren sind, ist MONTE 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 Ihnen später mehr darüber erzählen.
Wenn ein Überwachungsereignis für ein Gerät oder eine Gruppe von Geräten aktiviert werden muss, abonniert AS den entsprechenden Dienst, indem der entsprechende MONTE-API-Befehl an SCEF gesendet wird, der Parameter wie externe ID oder externe Gruppen-ID, AS-ID, Überwachungstyp, Anzahl der Berichte usw. enthält. welche AS erhalten möchte. Wenn der AS berechtigt ist, die Anforderung auszuführen, löst SCEF je nach Typ das Ereignis auf dem HSS oder der MME aus (Abb. 4). Wenn ein Ereignis eintritt, generiert die MME oder HSS einen Bericht an die SCEF-Seite, der ihn an den AS sendet.
Alle Ereignisse mit Ausnahme von "Anzahl der in einem geografischen Gebiet vorhandenen UEs" werden über HSS bereitgestellt. Die beiden Ereignisse "Änderung der IMSI-IMEI-Zuordnung" und "Roaming-Status" werden direkt auf dem HSS verfolgt, der Rest des HSS wird auf dem MME bereitgestellt.
Ereignisse können entweder einmalig oder periodisch sein und werden durch ihren Typ bestimmt.
Die Ereignisberichterstattung (Berichterstellung) wird vom Ereignisverfolgungsknoten direkt an SCEF gesendet (Abb. 5).
Ein wichtiger Punkt: Überwachungsereignisse können sowohl auf Nicht-IP-Geräte angewendet werden, die über SCEF verbunden sind, als auch auf IP-Geräte, die Daten auf klassische Weise über MME-SGW-PGW übertragen.
Schauen wir uns jedes Überwachungsereignis genauer an:
Verbindungsverlust - Informiert AS, dass das UE weder für Datenverkehr noch für Signalisierung mehr verfügbar ist. Das Ereignis tritt auf, wenn der "mobile Erreichbarkeitszeitgeber" für das UE auf der MME abläuft. In der Anforderung für diese Art der Überwachung kann der AS seinen Wert "Maximale Erkennungszeit" angeben. Wenn das UE während dieser Zeit keine Aktivität anzeigt, wird der AS darüber informiert, dass das UE nicht verfügbar ist, und den Grund angeben. Das Ereignis tritt auch auf, wenn das UE aus irgendeinem Grund vom Netzwerk zwangsweise entfernt wurde.
* Damit das Netzwerk weiß, dass das Gerät noch verfügbar ist, wird regelmäßig der Aktualisierungsvorgang - Tracking Area Update (TAU) - eingeleitet. Die Frequenz dieser Prozedur wird vom Netzwerk unter Verwendung des Zeitgebers T3412 oder (T3412_extended im Fall von PSM) eingestellt, dessen Wert während der Attach-Prozedur oder der nächsten TAU an das Gerät übertragen wird. Der Timer für die mobile Erreichbarkeit ist normalerweise einige Minuten länger als der T3412. Wenn das UE vor Ablauf des Zeitgebers für die mobile Erreichbarkeit keine TAU erstellt, betrachtet das Netzwerk diese als nicht mehr verfügbar.
Erreichbarkeit des UE - Zeigt an, wann das UE für DL-Verkehr oder SMS verfügbar wird. Dies geschieht, wenn das UE für das Paging verfügbar wird (für das UE im eDRX-Modus) oder wenn das UE in den ECM-CONNECTED-Modus wechselt (für das UE im PSM- oder eDRX-Modus), d. H. macht eine TAU oder sendet ein Uplink-Paket.
Standortberichterstattung - Mit dieser Art von Überwachungsereignis kann der AS UE-Standortdaten anfordern. Es kann entweder der aktuelle Standort (aktueller Standort) oder der letzte bekannte Standort (letzter bekannter Standort, bestimmt durch die Zellen-ID, von der das Gerät die TAU erstellt oder den Datenverkehr zum letzten Mal übertragen hat) angefordert werden, was für Geräte im PSM- oder eDRX-Energiesparmodus wichtig ist. Für "Aktueller Standort" kann der AS wiederholte Wiederholungen anfordern, wobei die MME den AS jedes Mal informiert, wenn der Gerätestandort geändert wird.
Änderung der IMSI-IMEI-Zuordnung - Wenn dieses Ereignis aktiviert ist, beginnt SCEF, die Änderungen in der Verbindung zwischen IMSI (SIM-Karten-ID) und IMEI (Geräte-ID) zu verfolgen. Wenn ein Ereignis eintritt - informiert AS. Es kann verwendet werden, um die externe ID dem Gerät während geplanter Austauscharbeiten automatisch neu zuzuweisen oder als Kennung für den Diebstahl des Geräts zu dienen.
Roaming-Status - Diese Art der Überwachung wird vom AS verwendet, um zu bestimmen, ob sich das UE im Heimnetzwerk oder im Netzwerk des Roaming-Partners befindet. Optional kann das PLMN (Public Land Mobile Network) des Betreibers übertragen werden, in dem das Gerät registriert ist.
Kommunikationsfehler - Diese Art der Überwachung informiert den AS über Kommunikationsfehler mit dem Gerät, basierend auf den Gründen für die Verbindung (Freigabekurscode), die vom Funkzugangsnetz (S1-AP-Protokoll) empfangen wurde. Dieses Ereignis kann dabei helfen, den Grund für den Kommunikationsfehler zu ermitteln - beispielsweise aufgrund von Netzwerkproblemen, wenn eNodeb (Funkressourcen nicht verfügbar) überlastet ist oder weil das Gerät selbst (Funkverbindung mit verlorenem UE) ausgefallen ist.
Verfügbarkeit nach DDN-Fehler - Dieses Ereignis informiert den AS darüber, dass das Gerät nach einem Kommunikationsfehler verfügbar wurde. Es kann verwendet werden, wenn Daten auf das Gerät übertragen werden müssen, der vorherige Versuch jedoch nicht erfolgreich war, da das UE nicht auf die Benachrichtigung vom Netzwerk reagiert hat (Paging) und die Daten nicht übermittelt wurden. Wenn diese Art der Überwachung für das UE angefordert wurde, wird AS informiert, sobald das Gerät eingehende Kommunikation herstellt, eine TAU erstellt oder Daten an die Aufwärtsverbindung sendet, dass das Gerät verfügbar geworden ist. Da das DDN-Verfahren (Downlink Data Notification) zwischen der MME und S / P-GW funktioniert, ist diese Art der Überwachung nur für IP-Geräte verfügbar.
PDN-Konnektivitätsstatus - Informiert den AS beim Ändern des Gerätestatus (PDN-Konnektivitätsstatus) - Verbinden (Aktivieren des PDN) oder Trennen (Löschen des PDN). Dies kann vom AS verwendet werden, um die Kommunikation mit dem UE zu initiieren oder umgekehrt, um zu verstehen, dass keine Kommunikation 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 von der AS verwendet, um die Anzahl der UEs in einem bestimmten geografischen Gebiet zu bestimmen.
GeräteauslösungIn 2G / 3G-Netzwerken war die Registrierungsprozedur im Netzwerk zweistufig: Zuerst wurde das Gerät in SGSN registriert (Anhängeprozedur), dann wurden die Daten bei Bedarf durch den PDP-Kontext aktiviert - Verbindung zum Paket-Gateway (GGSN). In 3G-Netzen gingen diese beiden Verfahren nacheinander vor, d.h. Das Gerät wartete nicht auf den Moment, in dem Daten übertragen werden mussten, sondern aktivierte PDP sofort nach Abschluss des Verbindungsvorgangs. In LTE wurden diese beiden Verfahren zu einem zusammengefasst, dh beim Anschließen forderte das Gerät sofort die Aktivierung der PDN-Verbindung (analog zu PDP in 2G / 3G) über eNodeB zu MME-SGW-PGW an.
NB-IoT definiert eine Verbindungsmethode wie "Anhängen ohne PDN", dh das UE stellt eine Verbindung her, ohne eine PDN-Verbindung herzustellen. In diesem Fall ist es nicht für die Verkehrsübertragung verfügbar und kann nur SMS empfangen oder senden. Um einen Befehl zum Aktivieren eines PDN und zum Herstellen einer Verbindung mit AS zu einem solchen Gerät zu senden, wurde die Funktion "Geräteauslösung" entwickelt.
Nach Erhalt eines Befehls zum Verbinden eines solchen UE von AS initiiert SCEF über das SMS-Zentrum das Senden einer Steuer-SMS an das Gerät. Beim Empfang einer SMS aktiviert das Gerät den PDN und stellt eine Verbindung zum AS her, um nachfolgende Anweisungen zu empfangen oder Daten zu übertragen.
Es kann vorkommen, dass ein Abonnement für ein Gerät in SCEF abläuft. Ja, das Abonnement hat eine eigene Lebensdauer, die vom Betreiber festgelegt oder mit AS vereinbart wurde. MME PDN, AS. “Device triggering”. AS SCEF SMS-.
FazitSCEF, , . SCEF . , .
, «»- ? . nidd_scef@mts.ru, , .
Bis bald
: