In het artikel "", hebben we het in verband met de architectuur van de pakketkernel van het NB-IoT-netwerk over de introductie van een nieuwe knooppunt SCEF. In het derde deel leggen we uit wat dit is en waarom het nodig is.
Bij het ontwikkelen van een M2M-service staan app-ontwikkelaars voor de volgende vragen:
- hoe apparaten te identificeren;
- welk algoritme te gebruiken voor verificatie en authenticatie;
- welke transportprotocol te kiezen voor interactie met apparaten;
- hoe gegevens gegarandeerd naar apparaten te verzenden;
- hoe de regels voor gegevensuitwisseling met hen te organiseren en vast te stellen;
- hoe online informatie over hun status te controleren en te verkrijgen;
- hoe tegelijkertijd gegevens naar een groep van hun apparaten te verzenden;
- hoe tegelijkertijd gegevens van één apparaat naar meerdere klanten te verzenden;
- hoe een uniforme toegang te krijgen tot aanvullende diensten van de operator voor het beheer van hun apparaat.
Om deze uitdagingen aan te pakken, moeten er vaak propriëtaire technisch 'zware' oplossingen worden ontwikkeld, wat leidt tot een toename van de inspanning en de tijd tot marktintroductie van de diensten. Hier komt het nieuwe knooppunt SCEF in beeld.
Volgens de definitie van 3GPP is SCEF (service capability exposure function) een compleet nieuwe component in de 3GPP-architectuur, waarvan de functie het veilig exposeren van diensten en mogelijkheden is die door de 3GPP-netwerkinterfaces worden aangeboden via API.
In eenvoudige bewoordingen is SCEF een tussenpersoon tussen het netwerk en de applicatieserver (application server - AS), een enkel toegangspunt voor operatordiensten voor het beheer van hun M2M-apparaat in het NB-IoT-netwerk via een intuïtieve gestandaardiseerde API-interface.
SCEF verbergt de complexiteit van het operatornetwerk, waardoor app-ontwikkelaars zich kunnen abstraheren van de complexe, specifieke mechanismen voor interactie met apparaten.
Door het omzetten van netwerkprotocollen naar een voor applicatieontwikkelaars vertrouwde API-interface, vergemakkelijkt SCEF de creatie van nieuwe diensten en verkort het de time-to-market. Ook omvat de nieuwe knooppunt functies voor identificatie/authenticatie van mobiele apparaten en het bepalen van de gegevensuitwisselingsregels tussen het apparaat en AS, waarbij de verantwoordelijkheid voor deze functies van de ontwikkelaars van applicaties naar de operator wordt verlegd.
SCEF sluit de interfaces die nodig zijn voor de authenticatie en autorisatie van applicatieservers, het handhaven van de mobiliteit van UE, gegevensoverdracht en het triggeren van apparaten, alsook toegang tot aanvullende diensten en mogelijkheden van het netwerk van de operator.
In de richting van AS is er één enkele interface T8, een API-interface (HTTP/JSON), gestandaardiseerd door 3GPP. Alle interfaces, met uitzondering van T8, werken op basis van het DIAMETER-protocol (zie fig. 1).
T6a is de interface tussen SCEF en MME. Het wordt gebruikt voor procedures voor mobiliteit/session beheer, overdracht van non-IP gegevens, provisioning van monitoring evenementen en het ontvangen van rapporten hierover.
S6t is de interface tussen SCEF en HSS. Dit is noodzakelijk voor de authenticatie van de deelnemer, autorisatie van applicatieservers, en het verkrijgen van de koppeling tussen external ID en IMSI/MSISDN, provisioning van monitoring evenementen en het ontvangen van rapporten hierover.
S6m/T4 zijn interfaces van SCEF naar HSS en SMS-C (in 3GPP is de MTC-IWF knooppunt gedefinieerd, dat gebruikt wordt voor het triggeren van apparaten en het verzenden van SMS in NB-IoT-netwerken. Echter, in alle implementaties is de functionaliteit van dit knooppunt geïntegreerd in SCEF, dus om de diagram te vereenvoudigen, zullen we het niet apart beschouwen). Ze worden gebruikt voor het verkrijgen van routeringsinformatie voor het verzenden van SMS en interactie met het SMS-centrum.
T8 is de API-interface voor de interactie van SCEF met applicatieservers. Via deze interface worden zowel beheerscommando's als verkeer overgedragen.
*In feite zijn er meer interfaces, hier zijn alleen de belangrijkste opgesomd. Een volledige lijst is te vinden in 3GPP 23.682 (4.3.2 Lijst met referentiepunten).
Hieronder volgen de belangrijkste functies en services van SCEF:
- koppeling van het simkaartidentificatienummer (IMSI) aan external ID;
- overdracht van non-IP verkeer (Non-IP Data Delivery, NIDD);
- groepsoperaties, met gebruik van external group ID;
- ondersteuning van gegevensoverdracht in bevestigingsmodus;
- buffering van MO (Mobile Originated) en MT (Mobile Terminated) gegevens;
- authenticatie en autorisatie van apparaten en applicatieservers;
- gelijktijdig gebruik van gegevens van één UE door meerdere AS;
- ondersteuning voor speciale functies voor het bewaken van de status van UE (MONTE – Monitoring Events);
- apparaattriggering;
- garantie van non-IP gegevensroaming.
Het belangrijkste principe van de interactie tussen AS en SCEF is gebaseerd op het zogenaamde abonnementschema. Wanneer toegang tot een bepaalde service via SCEF voor een specifieke UE nodig is, moet de applicatieserver een abonnement aanmaken door een opdracht naar specifieke API van de gevraagde service te sturen en als antwoord een unieke identificatie te ontvangen. Vervolgens zullen alle verdere acties en communicatie met de UE binnen het kader van deze service verlopen met behulp van deze identificatie.
Externe ID: universele apparaatidentificatie
Een van de belangrijkste wijzigingen in het communicatie schema tussen AS en apparaten bij het werken via SCEF is de introductie van een universele identificatie. Nu wordt in plaats van een telefoonnummer (MSISDN) of IP-adres, zoals dat het geval was in het klassieke 2G/3G/LTE-netwerk, de ‘external ID’ de identificatie van het apparaat voor de applicatieserver. Deze is gedefinieerd volgens de standaard in het voor ontwikkelaars bekende formaat '<Local Identifier>@<Domain Identifier>'.
Ontwikkelaars hoeven geen authenticatie-algoritmes voor apparaten meer te implementeren; het netwerk neemt deze functie volledig over. De external ID is gekoppeld aan de IMSI, en de ontwikkelaar kan er zeker van zijn dat hij contact heeft met een specifieke simkaart wanneer hij een bepaalde external ID aanroept. Bij gebruik van een sim-chip ontstaat een unieke situatie waarin de external ID specifiek een bepaald apparaat identificeert!
Bovendien kunnen meerdere external ID's aan één IMSI worden gekoppeld - dit creëert een nog interessantere situatie waarin de external ID een bepaalde applicatie identificeert die verantwoordelijk is voor een specifieke service op een bepaald apparaat.
Er verschijnt ook een groepsidentificatie - external group ID, die een set van aparte external ID's omvat. Nu kan AS met één verzoek naar SCEF groepsoperaties initiëren - het verzenden van gegevens of beheercommando's naar meerdere apparaten die in een enkele logische groep zijn samengevoegd.
Omdat de overgang naar de nieuwe apparaatidentificatie voor ontwikkelaars niet onmiddellijk kan zijn, heeft SCEF de mogelijkheid van communicatie tussen AS en UE via het standaardnummer - MSISDN behouden.
Overdracht van non-IP verkeer (Non-IP Data Delivery, NIDD)
In NB-IoT, ter optimalisatie van de mechanismen voor de overdracht van kleine hoeveelheden data, is er naast de reeds bestaande type PDN's, zoals IPv4, IPv6 en IPv4v6, een nieuw type toegevoegd — non-IP. In dit geval krijgt het apparaat (UE) geen IP-adres toegewezen en worden de gegevens zonder gebruik van het IP-protocol verzonden. Verkeer voor dergelijke verbindingen kan op twee manieren worden gerouteerd: klassiek — MME -> SGW -> PGW en verder via een PtP-tunnel naar AS (zie fig. 2) of met behulp van SCEF (zie fig. 3).
De klassieke methode biedt geen bijzondere voordelen ten opzichte van IP-verkeer, behalve het verkleinen van de verzonden pakketten door het ontbreken van IP-headers. Het gebruik van SCEF opent echter een hele reeks nieuwe mogelijkheden en vereenvoudigt de interactieprocedures met apparaten aanzienlijk.
Bij de overdracht van gegevens via SCEF ontstaan er twee zeer belangrijke voordelen ten opzichte van klassiek IP-verkeer:
Levering van MT-verkeer naar het apparaat op basis van external ID
Om een bericht naar een klassiek IP-apparaat te sturen, moet AS het IP-adres ervan weten. Hier ontstaat een probleem: aangezien het apparaat bij registratie meestal een 'grijs' IP-adres krijgt, communiceert het met de applicatieserver, die zich op internet bevindt, via een NAT-knooppunt, waar het grijze adres wordt vertaald naar een wit adres. De koppeling tussen grijze en witte IP-adressen blijft een beperkte tijd bestaan, afhankelijk van de NAT-instellingen. Gemiddeld voor TCP of UDP is dit niet meer dan vijf minuten. Dat wil zeggen dat als er binnen 5 minuten geen gegevenswisseling met dit apparaat heeft plaatsgevonden, de koppeling zal uiteenvallen, en het apparaat niet meer toegankelijk zal zijn via dat witte adres waarmee de sessie met AS werd geïnitieerd. Er zijn verschillende oplossingen:
1. Gebruik heartbeat. Nadat de verbinding eenmaal is gelegd, moet het apparaat elke paar minuten pakketten uitwisselen met AS, zodat de NAT-vertalingen niet gesloten worden. Maar hier kan geen sprake zijn van enige energie-efficiëntie.
2. Elke keer bij behoefte controleren of er pakketten voor het apparaat op AS zijn — een bericht in uplink verzenden.
3. Een privaat APN (VRF) opzetten, waar de applicatieserver en apparaten zich in hetzelfde subnet bevinden, en statische IP-adressen aan de apparaten toewijzen. Dit zal werken, maar het is bijna onuitvoerbaar wanneer het gaat om een park van duizenden, tienduizenden apparaten.
4. Ten slotte, de meest geschikte optie: gebruik IPv6, waarvoor geen NAT nodig is, omdat IPv6-adressen rechtstreeks vanuit het internet toegankelijk zijn. Zelfs in dat geval krijgt het apparaat bij herregistratie echter een nieuw IPv6-adres en is het niet meer toegankelijk via het vorige adres.
Daarom is het noodzakelijk om een initiële gegevenspakket met de apparaatidentificatie naar de server te sturen om het nieuwe IP-adres van het apparaat te melden. Vervolgens moet men wachten op een bevestigingspakket van AS, wat ook invloed heeft op de energie-efficiëntie.
Deze methoden werken goed voor 2G/3G/LTE-apparaten, waar geen strenge eisen aan de autonomie van het apparaat worden gesteld, en waar dus geen tijd- en dataverbruikbeperkingen zijn. Voor NB-IoT zijn deze methoden niet geschikt vanwege hun hoge energieverbruik.
SCEF lost dit probleem op: aangezien de enige identifier voor het apparaat voor AS de externe ID is, hoeft AS alleen maar een gegevenspakket naar SCEF te sturen voor de specifieke externe ID, terwijl SCEF voor de rest zorgt. Als het apparaat zich in de energiebesparende modus PSM of eDRX bevindt, worden de gegevens gebufferd en geleverd wanneer het apparaat weer beschikbaar wordt. Als het apparaat echter beschikbaar is voor verkeer, worden de gegevens onmiddellijk geleverd. Dit geldt ook voor besturingscommando's.
Op elk moment kan AS het gebufferde bericht terugroepen naar UE of vervangen door een nieuwe.
Het bufferingsmechanisme kan ook worden toegepast bij de overdracht van MO-gegevens van UE naar AS. Als SCEF de gegevens niet onmiddellijk aan AS kan leveren, bijvoorbeeld als er onderhoud aan de AS-servers plaatsvindt, worden deze pakketten gebufferd en gegarandeerd geleverd zodra AS weer beschikbaar is.
Zoals eerder opgemerkt, wordt de toegang tot een specifieke dienst en UE voor AS (en NIDD is een dienst) vastgesteld door de regels en beleidsmaatregelen aan de zijde van SCEF, wat een unieke mogelijkheid biedt voor het gelijktijdig gebruik van gegevens van één UE door meerdere AS. Dit betekent dat als meerdere AS zich hebben aangemeld op één UE, SCEF de ontvangen gegevens van UE naar alle aangemelde AS zal verzenden. Dit is goed toepasbaar voor scenario's waarbij de maker van een park gespecialiseerde apparaten gegevens deelt tussen meerdere klanten. Bijvoorbeeld, door een netwerk van weerstations te creëren die op NB-IoT werken, kunnen de gegevens van hen tegelijkertijd aan veel diensten worden verkocht.
Mechanisme voor gegarandeerde aflevering van berichten
Reliable Data Service — mechanisme voor gegarandeerde aflevering van MO- en MT-berichten zonder gebruik te maken van gespecialiseerde algoritmen op protocolniveau, zoals bijvoorbeeld handshake in TCP. Het werkt door het inschakelen van een speciale vlag in het controlgedeelte van het bericht tijdens de uitwisseling tussen UE en SCEF. Het activeren of niet activeren van dit mechanisme bij het verzenden van verkeer wordt beslist door de AS.
Als het mechanisme is geactiveerd, voegt UE bij gegarandeerde aflevering van MO-verkeer een speciale vlag toe aan het controlgedeelte van het pakket. Bij ontvangst van zo'n pakket bevestigt SCEF de ontvangst naar UE. Als UE het pakket met de bevestiging niet heeft ontvangen, wordt het pakket opnieuw verzonden naar SCEF. Dit gebeurt ook voor MT-verkeer.
Apparaatmonitoring (monitoring events - MONTE)
Zoals hierboven vermeld, omvat de functionaliteit van SCEF, naast andere functies, de controle van de status van de UE, de zogenaamde apparaatmonitoring. En terwijl nieuwe identificatoren en gegevensoverdrachtsmechanismen optimalisaties zijn (ook al zijn ze zeer ingrijpend) van bestaande procedures, is MONTE een volledig nieuwe functionaliteit die niet beschikbaar is in 2G/3G/LTE-netwerken. MONTE stelt AS in staat om parameters van het apparaat te volgen zoals verbindingsstatus, beschikbaarheid voor communicatie, locatie, roamingstatus, enz. Meer hierover volgt later.
Indien nodig om een monitoringsevent voor een apparaat of een groep apparaten te activeren, abonneert AS zich op de bijbehorende service door een opdracht naar SCEF te sturen via de relevante MONTE API, waarin parameters zoals external Id of external group ID, identificatie AS, type monitoring, aantal rapporten dat AS wil ontvangen, zijn opgenomen. Als AS is geautoriseerd om het verzoek uit te voeren, provisioneert SCEF het event afhankelijk van het type op HSS of MME (zie Fig. 4). Bij het optreden van het event genereert MME of HSS een rapport in de richting van SCEF, dat het naar AS stuurt.
Provisioning van alle events, met uitzondering van 'Number of UEs present in a geographic area', gebeurt via HSS. De twee events 'Change of IMSI-IMEI Association' en 'Roaming Status' worden rechtstreeks op HSS gevolgd; de overige worden door HSS op MME provisioned.
Events kunnen eenmalig of periodiek zijn en zijn afhankelijk van hun type.
Het verzenden van een gebeurtenisrapport (reporting) gebeurt door de node die de gebeurtenis volgt, rechtstreeks naar SCEF (zie fig. 5).
Belangrijk punt: monitoring gebeurtenissen kunnen zowel voor non-IP apparaten die via SCEF zijn aangesloten als voor IP-apparaten die gegevens op de traditionele manier via MME-SGW-PGW verzenden, worden toegepast.
Laten we elk van de monitoring gebeurtenissen in meer detail bekijken:
Verlies van connectiviteit — informeert AS dat UE niet langer beschikbaar is voor dataverkeer of signaaluitwisseling. Deze gebeurtenis vindt plaats wanneer de "mobile reachability timer" voor UE op de MME is verstreken. In het verzoek voor dit type monitoring kan AS zijn waarde voor "Maximum Detection Time" opgeven — als UE in deze tijd geen enkele activiteit vertoont, wordt AS geïnformeerd dat UE niet beschikbaar is, met vermelding van de reden. Deze gebeurtenis vindt ook plaats als UE om welke reden dan ook gedwongen uit het netwerk is verwijderd.
* Om het netwerk te laten weten dat het apparaat nog steeds beschikbaar is, initieert het periodiek de actualisatieprocedure — Tracking Area Update (TAU). De frequentie van deze procedure wordt door het netwerk ingesteld met behulp van de timer T3412 of (T3412_extended in het geval van PSM), waarvan de waarde aan het apparaat wordt doorgegeven tijdens de Attach-procedure of de volgende TAU. De mobile reachability timer is doorgaans enkele minuten langer dan T3412. Als UE niet voor het verstrijken van de "Mobile reachability timer" een TAU heeft uitgevoerd, beschouwt het netwerk deze als niet langer beschikbaar.
UE beschikbaarheid – Toont wanneer UE beschikbaar wordt voor DL verkeer of SMS. Dit gebeurt wanneer UE beschikbaar wordt voor paging (voor UE in de eDRX-modus) of wanneer UE overgaat in de ECM-CONNECTED-modus (voor UE in de PSM of eDRX-modus), d.w.z. een TAU uitvoert of een uplink-pakket verzendt.
Locatierapportage – Dit type monitoringgebeurtenis stelt AS in staat om gegevens over de locatie van UE op te vragen. Er kan ofwel de huidige locatie (Current Location) of het laatst bekende (Last Known Location, vastgesteld op basis van de cell ID waaruit het apparaat voor het laatst TAU heeft uitgevoerd of gegevens heeft verzonden) worden opgevraagd, wat relevant is voor apparaten die zich in de energiebesparende modi PSM of eDRX bevinden. Voor "Current Location" kan AS verzoeken om herhaalde rapporten, waarbij MME AS elke keer informeert bij het veranderen van de locatie van het apparaat.
Verandering van IMSI-IMEI associatie Bij de activatie van deze gebeurtenis begint SCEF de wijziging van de IMSI (identificator van de simkaart) en IMEI (identificator van het apparaat) te volgen. Wanneer de gebeurtenis zich voordoet, informeert het AS. Dit kan worden gebruikt voor automatische hervermelding van de externe ID aan het apparaat tijdens geplande werkzaamheden of om te dienen als identificator bij diefstal van het apparaat.
Roamingstatus Dit type monitoring wordt door AS gebruikt om te bepalen of de UE zich in het thuisnetwerk of in het netwerk van een roamingpartner bevindt. Optioneel kan de PLMN (Public Land Mobile Network) van de operator worden doorgegeven waarin het apparaat is geregistreerd.
Communicatiefout Dit type monitoring informeert AS over storingen in de communicatie met het apparaat, gebaseerd op de oorzaken van de verbindingsonderbreking (release cause code) die van het radiotoegang netwerk (S1-AP-protocol) zijn ontvangen. Dit evenement kan helpen te bepalen waarom de communicatie is mislukt - doordat er problemen in het netwerk waren, bijvoorbeeld tijdens overbelasting van eNodeb (Radio resources not available), of vanwege een storing in het apparaat zelf (Radio Connection With UE Lost).
Beschikbaarheid na DDN-fout Dit evenement informeert AS dat het apparaat weer beschikbaar is na een communicatiestoring. Het kan worden gebruikt wanneer gegevens naar het apparaat moeten worden verzonden, maar de vorige poging niet succesvol was omdat de UE niet op de melding van het netwerk (paging) heeft gereageerd, en de gegevens niet zijn afgeleverd. Als dit type monitoring voor de UE is aangevraagd, zal AS geïnformeerd worden zodra het apparaat inkomende communicatie tot stand brengt, een TAU uitvoert of gegevens in de uplink verzendt, dat het apparaat weer beschikbaar is. Aangezien de DDN-procedure (downlink data notification) tussen MME en S/P-GW werkt, is dit type monitoring alleen beschikbaar voor IP-apparaten.
PDN-connectiviteitsstatus Dit informeert AS bij een wijziging van de status van het apparaat (PDN-connectiviteitsstatus) - verbinding (activatie PDN) of ontkoppeling (verwijdering PDN). Dit kan door AS worden gebruikt om communicatie met de UE te initiëren, of omgekeerd, om te begrijpen dat communicatie niet meer mogelijk is. Dit type monitoring is beschikbaar voor zowel IP- als non-IP-apparaten.
Aantal UE's aanwezig in een geografisch gebied Dit type monitoring wordt door AS gebruikt om het aantal UE's in een bepaald geografisch gebied te bepalen.
Apparaattriggering (Device triggering)
In 2G/3G networks, the registration process was two-step: first, the device registered with the SGSN (attach procedure), and then, if data needed to be transmitted, it activated the PDP context – a connection to the packet gateway (GGSN). In 3G networks, these two procedures occurred sequentially, meaning the device did not wait until data needed to be transmitted but activated the PDP immediately after completing the attach procedure. In LTE, these two procedures were combined into one, so that during attach the device immediately requested the activation of the PDN connection (analogous to PDP in 2G/3G) through eNodeB to MME-SGW-PGW.
In NB-IoT, a connection method called 'attach without PDN' is defined, meaning that the UE attaches without establishing a PDN connection. In this case, it is not available for traffic transmission and can only receive or send SMS. To send a command to activate the PDN and connect to AS to such a device, a feature called 'Device triggering' was developed.
Upon receiving a connection command for such a UE from AS, SCEF initiates the sending of a control SMS to the device through the SMS center. Upon receiving the SMS, the device activates the PDN and connects to AS for further instructions or data transmission.
There may be cases when the subscription for the device expires on SCEF. Yes, subscriptions have their own lifespan, established by the operator or agreed upon with AS. Upon expiration, the PDN will be deactivated on the MME, and the device will become unavailable to AS. In this case, the 'Device triggering' feature will also come in handy. Upon receiving new data from AS, SCEF will determine the connection status of the device and deliver the data via the SMS channel.
Conclusie
The SCEF functionality, of course, is not limited to the aforementioned services and is constantly evolving and expanding. Currently, over a dozen services have already been standardized for SCEF. We have only touched on the main and sought-after functions from developers; we will discuss others in future articles.
The question immediately arises: how can one gain test access to this 'miracle' node for preliminary testing and debugging of possible cases? It’s very simple. Any developer can send a request to iot.info@mts.ru stating the purpose of the connection, describing a possible case, and providing contact information for further communication.
Until we meet again!
Authors:
- senior expert op het gebied van convergente oplossingen en multimedia-services Sergey Novikov ,
- expert op het gebied van convergente oplossingen en multimedia-services Alexey Lapshin
Bron: habr.com
