In het artikel ""Pratend over de architectuur van de pakketkern van het NB-IoT-netwerk noemden we de verschijning van een nieuw SCEF-knooppunt. In het derde deel leggen we uit wat het is en waarom het nodig is?
Bij het creëren van een M2M-dienst worden applicatieontwikkelaars geconfronteerd met de volgende vragen:
- hoe apparaten te identificeren;
- welk verificatie- en authenticatie-algoritme moet worden gebruikt;
- welk transportprotocol je moet kiezen voor interactie met apparaten;
- hoe u op betrouwbare wijze gegevens aan apparaten kunt leveren;
- hoe u regels kunt organiseren en vaststellen voor de uitwisseling van gegevens met hen;
- hoe u hun toestand online kunt volgen en verkrijgen;
- hoe u tegelijkertijd gegevens kunt leveren aan een groep van uw apparaten;
- hoe u tegelijkertijd gegevens van één apparaat naar meerdere clients kunt verzenden;
- hoe u uniforme toegang krijgt tot aanvullende operatorservices voor het beheren van uw apparaat.
Om deze op te lossen is het noodzakelijk om bedrijfseigen technisch “zware” oplossingen te creëren, wat leidt tot hogere arbeidskosten en time-to-market-diensten. Dit is waar het nieuwe SCEF-knooppunt te hulp komt.
Zoals gedefinieerd door 3GPP, is SCEF (Service Capability Exposure Function) een volledig nieuw onderdeel van de 3GPP-architectuur, waarvan de functie is om de diensten en mogelijkheden die door 3GPP-netwerkinterfaces worden geleverd veilig bloot te leggen via API's.
In eenvoudige bewoordingen is SCEF een intermediair tussen het netwerk en de applicatieserver (AS), een enkel toegangsvenster tot operatordiensten voor het beheren van uw M2M-apparaat in het NB-IoT-netwerk via een intuïtieve, gestandaardiseerde API-interface.
SCEF verbergt de complexiteit van het netwerk van een operator, waardoor applicatieontwikkelaars complexe, apparaatspecifieke mechanismen voor interactie met apparaten kunnen wegabstracten.
Door netwerkprotocollen te transformeren in een vertrouwde API voor applicatieontwikkelaars, vergemakkelijkt de SCEF API de creatie van nieuwe diensten en verkort de time-to-market. Het nieuwe knooppunt bevat ook functies voor het identificeren/authenticeren van mobiele apparaten, het definiëren van de regels voor gegevensuitwisseling tussen het apparaat en AS, waardoor de noodzaak voor applicatieontwikkelaars om deze functies aan hun kant te implementeren, wordt weggenomen en deze functies naar de schouders van de operator worden verschoven.
SCEF omvat de interfaces die nodig zijn voor authenticatie en autorisatie van applicatieservers, het onderhouden van UE-mobiliteit, gegevensoverdracht en apparaattriggering, toegang tot aanvullende diensten en netwerkmogelijkheden van operators.
Richting de AS is er één enkele T8-interface, een API (HTTP/JSON) gestandaardiseerd door 3GPP. Alle interfaces, met uitzondering van T8, werken op basis van het DIAMETER-protocol (Fig. 1).
T6a – interface tussen SCEF en MME. Gebruikt voor mobiliteits-/sessiebeheerprocedures, verzending van niet-IP-gegevens, levering van monitoringgebeurtenissen en het ontvangen van rapporten daarover.
S6t – interface tussen SCEF en HSS. Vereist voor abonneeauthenticatie, autorisatie van applicatieservers, verkrijgen van een combinatie van externe ID en IMSI/MSISDN, het inrichten van monitoringgebeurtenissen en het ontvangen van rapporten hierover.
S6m/T4 – interfaces van SCEF naar HSS en SMS-C (3GPP definieert het MTC-IWF-knooppunt, dat wordt gebruikt voor het activeren van apparaten en SMS-transmissie in NB-IoT-netwerken. In alle implementaties is de functionaliteit van dit knooppunt echter geïntegreerd in SCEF, dus ter vereenvoudiging van het circuit zullen we het niet afzonderlijk beschouwen). Wordt gebruikt om routeringsinformatie te verkrijgen voor het verzenden van sms-berichten en interactie met het sms-centrum.
T8 – API-interface voor SCEF-interactie met applicatieservers. Zowel besturingsopdrachten als verkeer worden via deze interface verzonden.
*in werkelijkheid zijn er meer interfaces; alleen de meest elementaire worden hier vermeld. Een volledige lijst wordt gegeven in 3GPP 23.682 (4.3.2 Lijst met referentiepunten).
Hieronder vindt u de belangrijkste functies en diensten van SCEF:
- het koppelen van de SIM-kaartidentificatie (IMSI) aan een externe ID;
- verzending van niet-IP-verkeer (Non-IP Data Delivery, NIDD);
- groepsbewerkingen met behulp van een externe groeps-ID;
- ondersteuning voor datatransmissiemodus met bevestiging;
- bufferen van MO (Mobile Originated) en MT (Mobile Terminate) data;
- authenticatie en autorisatie van apparaten en applicatieservers;
- gelijktijdig gebruik van gegevens uit één UE door meerdere AS's;
- ondersteuning voor speciale UE-statusbewakingsfuncties (MONTE – Monitoring Events);
- apparaattriggering;
- het aanbieden van niet-IP-dataroaming.
Het basisprincipe van de interactie tussen AS en SCEF is gebaseerd op het zogenaamde schema. abonnementen. Als het nodig is om toegang te krijgen tot een SCEF-service voor een specifieke UE, moet de applicatieserver een abonnement aanmaken door een opdracht naar de specifieke API van de aangevraagde service te sturen en als antwoord een unieke identificatiecode ontvangen. Daarna zullen alle verdere acties en communicatie met de UE in het kader van deze dienst plaatsvinden met behulp van deze identificatie.
Externe ID: Universele apparaat-ID
Een van de belangrijkste veranderingen in het interactieschema tussen AS en apparaten bij het werken via SCEF is het verschijnen van een universele identificatie. In plaats van een telefoonnummer (MSISDN) of IP-adres, zoals het geval was in het klassieke 2G/3G/LTE-netwerk, wordt de apparaat-ID voor de applicatieserver nu een “externe ID”. Het wordt door de standaard gedefinieerd in een formaat dat bekend is bij applicatieontwikkelaars “ @ "
Ontwikkelaars hoeven niet langer algoritmen voor apparaatauthenticatie te implementeren; het netwerk neemt deze functie volledig over. Externe ID is gekoppeld aan IMSI en de ontwikkelaar kan er zeker van zijn dat wanneer hij toegang krijgt tot een specifieke externe ID, deze samenwerkt met een specifieke simkaart. Wanneer u een SIM-chip gebruikt, krijgt u een volledig unieke situatie wanneer de externe ID een specifiek apparaat op unieke wijze identificeert!
Bovendien kunnen meerdere externe ID's aan één IMSI worden gekoppeld - een nog interessantere situatie doet zich voor wanneer de externe ID op unieke wijze een specifieke applicatie identificeert die verantwoordelijk is voor een specifieke dienst op een specifiek apparaat.
Er verschijnt ook een groeps-ID: externe groeps-ID, die een reeks individuele externe ID's bevat. Met één verzoek aan SCEF kan AS nu groepsbewerkingen initiëren, waarbij gegevens of besturingsopdrachten worden verzonden naar meerdere apparaten die in één logische groep zijn verenigd.
Vanwege het feit dat voor AS-ontwikkelaars de overgang naar een nieuwe apparaat-ID niet onmiddellijk kan plaatsvinden, liet SCEF de mogelijkheid open van AS-communicatie met de UE via een standaardnummer: MSISDN.
Verzending van niet-IP-verkeer (Non-IP Data Delivery, NIDD)
In NB-IoT is, als onderdeel van de optimalisatie van mechanismen voor het verzenden van kleine hoeveelheden gegevens, naast de reeds bestaande PDN-typen, zoals IPv4, IPv6 en IPv4v6, een ander type verschenen: niet-IP. In dit geval krijgt het apparaat (UE) geen IP-adres toegewezen en worden de gegevens verzonden zonder gebruik te maken van het IP-protocol. Verkeer voor dergelijke verbindingen kan op twee manieren worden gerouteerd: klassiek - MME -> SGW -> PGW en vervolgens via de PtP-tunnel naar AS (Fig. 2) of met behulp van SCEF (Fig. 3).
De klassieke methode biedt geen speciale voordelen ten opzichte van IP-verkeer, behalve het verkleinen van de omvang van de verzonden pakketten vanwege de afwezigheid van IP-headers. Het gebruik van SCEF opent een aantal nieuwe mogelijkheden en vereenvoudigt de procedures voor interactie met apparaten aanzienlijk.
Bij het verzenden van gegevens via SCEF zijn er twee zeer belangrijke voordelen ten opzichte van klassiek IP-verkeer:
Levering van MT-verkeer naar het apparaat via externe ID
Om een bericht naar een klassiek IP-apparaat te sturen, moet de AS het IP-adres ervan kennen. Hier doet zich een probleem voor: aangezien het apparaat bij registratie meestal een "grijs" IP-adres ontvangt, communiceert het met de applicatieserver, die zich op internet bevindt, via een NAT-knooppunt, waar het grijze adres wordt vertaald in wit. De combinatie van grijze en witte IP-adressen duurt een beperkte tijd, afhankelijk van de NAT-instellingen. Gemiddeld voor TCP of UDP - niet meer dan vijf minuten. Dat wil zeggen: als er binnen 5 minuten geen gegevensuitwisseling plaatsvindt met dit apparaat, valt de verbinding weg en is het apparaat niet meer bereikbaar op het witte adres waarmee de sessie met AS is gestart. Er zijn verschillende oplossingen:
1. Gebruik hartslag. Zodra er een verbinding tot stand is gebracht, moet het apparaat elke paar minuten pakketten uitwisselen met de AS, waardoor wordt voorkomen dat NAT-vertalingen worden afgesloten. Maar van enige energie-efficiëntie kan hier geen sprake zijn.
2. Controleer elke keer, indien nodig, de beschikbaarheid van pakketten voor het apparaat op de AS - stuur een bericht naar de uplink.
3. Maak een privé-APN (VRF), waarbij de applicatieserver en apparaten zich op hetzelfde subnet bevinden, en wijs statische IP-adressen toe aan de apparaten. Het zal werken, maar het is bijna onmogelijk als we het hebben over een vloot van duizenden, tienduizenden apparaten.
4. Tenslotte de meest geschikte optie: gebruik IPv6, hiervoor is geen NAT nodig, aangezien IPv6-adressen rechtstreeks toegankelijk zijn vanaf internet. Maar zelfs in dit geval zal het apparaat, wanneer het opnieuw wordt geregistreerd, een nieuw IPv6-adres ontvangen en zal het niet langer toegankelijk zijn via het vorige.
Dienovereenkomstig is het noodzakelijk om een initialisatiepakket met een apparaatidentificatie naar de server te sturen om het nieuwe IP-adres van het apparaat te rapporteren. Wacht vervolgens op een bevestigingspakket van AS, wat ook gevolgen heeft voor de energie-efficiëntie.
Deze methoden werken goed voor 2G/3G/LTE-apparaten, waarbij het apparaat geen strikte eisen stelt aan de autonomie en er dus geen beperkingen zijn op zendtijd en verkeer. Deze methoden zijn vanwege hun hoge energieverbruik niet geschikt voor NB-IoT.
SCEF lost dit probleem op: aangezien de enige apparaatidentificatie voor een AS een externe ID is, hoeft de AS alleen een datapakket naar SCEF te sturen voor een specifieke externe ID, en SCEF zorgt voor de rest. Als het apparaat zich in de PSM- of eDRX-energiebesparende modus bevindt, worden de gegevens gebufferd en geleverd zodra het apparaat beschikbaar komt. Als het apparaat beschikbaar is voor verkeer, worden de gegevens onmiddellijk geleverd. Hetzelfde geldt voor managementteams.
De AS kan het gebufferde bericht op elk moment terughalen naar de UE of vervangen door een nieuw bericht.
Het buffermechanisme kan ook worden gebruikt bij het verzenden van MO-gegevens van de UE naar de AS. Als SCEF niet onmiddellijk gegevens aan de AS kon leveren, bijvoorbeeld als er onderhoudswerkzaamheden aan de AS-servers gaande zijn, worden deze pakketten gebufferd en gegarandeerd geleverd zodra de AS beschikbaar komt.
Zoals hierboven opgemerkt, wordt de toegang tot een specifieke dienst en UE voor een AS (en NIDD is een dienst) gereguleerd door regels en beleid aan de kant van de SCEF, wat de unieke mogelijkheid mogelijk maakt van gelijktijdig gebruik van gegevens uit één UE door meerdere AS's. Die. als meerdere AS's zich op één UE hebben geabonneerd, zal SCEF, na ontvangst van gegevens van de UE, deze naar alle geabonneerde AS's sturen. Dit is zeer geschikt voor gevallen waarin de maker van een reeks gespecialiseerde apparaten gegevens deelt tussen verschillende klanten. Door bijvoorbeeld een netwerk van weerstations te creëren die op NB-IoT draaien, kunt u de gegevens van deze weerstations tegelijkertijd aan veel diensten verkopen.
Gegarandeerd berichtbezorgingsmechanisme
Reliable Data Service is een mechanisme voor gegarandeerde bezorging van MO- en MT-berichten zonder gebruik van gespecialiseerde algoritmen op protocolniveau, zoals bijvoorbeeld handshake in TCP. Het werkt door een speciale vlag op te nemen in het servicegedeelte van het bericht wanneer het wordt uitgewisseld tussen de UE en SCEF. Of dit mechanisme al dan niet wordt geactiveerd bij het verzenden van verkeer, wordt beslist door de AS.
Als het mechanisme wordt geactiveerd, neemt de UE een speciale vlag op in het overheadgedeelte van het pakket wanneer gegarandeerde levering van MO-verkeer vereist is. Bij ontvangst van een dergelijk pakket antwoordt de SCEF op de UE met een bevestiging. Als de UE het bevestigingspakket niet ontvangt, zal het pakket naar SCEF opnieuw worden verzonden. Hetzelfde gebeurt voor MT-verkeer.
Apparaatbewaking (bewakingsgebeurtenissen - MONTE)
Zoals hierboven vermeld omvat de SCEF-functionaliteit onder andere functies voor het bewaken van de status van de UE, de zogenaamde. apparaatbewaking. En als nieuwe identificatoren en mechanismen voor gegevensoverdracht optimalisaties zijn (zij het zeer serieuze) van bestaande procedures, dan is MONTE een volledig nieuwe functionaliteit die niet beschikbaar is in 2G/3G/LTE-netwerken. Met MONTE kan AS apparaatparameters bewaken, zoals verbindingsstatus, communicatiebeschikbaarheid, locatie, roamingstatus, enz. We zullen later meer in detail over elk ervan praten.
Als het nodig is om een monitoringgebeurtenis voor een apparaat of een groep apparaten te activeren, abonneert de AS zich op de bijbehorende service door het bijbehorende API MONTE-commando naar SCEF te sturen, dat parameters bevat zoals externe ID of externe groeps-ID, AS-identificatie, monitoring type, aantal meldingen, dat AS wil ontvangen. Als de AS geautoriseerd is om het verzoek uit te voeren, zal SCEF, afhankelijk van het type, de gebeurtenis aan de HSS of MME leveren (Fig. 4). Wanneer er een gebeurtenis plaatsvindt, genereert de MME of HSS een rapport naar SCEF, die dit naar de AS verzendt.
De levering van alle evenementen, met uitzondering van "Aantal UE's aanwezig in een geografisch gebied", vindt plaats via HSS. Twee gebeurtenissen “Verandering van IMSI-IMEI-associatie” en “Roamingstatus” worden rechtstreeks op HSS gevolgd, de rest wordt door HSS op MME geleverd.
Gebeurtenissen kunnen eenmalig of periodiek zijn en worden bepaald door hun type.
Het verzenden van een rapport over een gebeurtenis (rapportage) wordt uitgevoerd door het knooppunt dat de gebeurtenis rechtstreeks naar SCEF volgt (Fig. 5).
Belangrijk punt: Monitoringgebeurtenissen kunnen worden toegepast op zowel niet-IP-apparaten die zijn aangesloten via SCEF als op IP-apparaten die gegevens op de klassieke manier verzenden via MME-SGW-PGW.
Laten we elk van de monitoringgebeurtenissen eens nader bekijken:
Verlies van connectiviteit — informeert de AS dat de UE niet langer beschikbaar is voor dataverkeer of signalering. De gebeurtenis vindt plaats wanneer de “timer voor mobiele bereikbaarheid” voor de UE afloopt op de MME. Bij een verzoek om dit type monitoring kan de AS de waarde voor “Maximale detectietijd” aangeven. Als de UE gedurende deze tijd geen enkele activiteit vertoont, wordt de AS geïnformeerd dat de UE niet beschikbaar is, met vermelding van de reden. De gebeurtenis treedt ook op als de UE om welke reden dan ook met geweld door het netwerk is verwijderd.
* Om het netwerk te laten weten dat het apparaat nog steeds beschikbaar is, start het periodiek een updateprocedure: Tracking Area Update (TAU). De frequentie van deze procedure wordt door het netwerk ingesteld met behulp van timer T3412 of (T3412_extended in het geval van PSM), waarvan de waarde naar het apparaat wordt verzonden tijdens de Attach-procedure of de volgende TAU. De timer voor mobiele bereikbaarheid is doorgaans enkele minuten langer dan die van T3412. Als de UE geen TAU heeft gemaakt vóór het verstrijken van de “Mobiele bereikbaarheidstimer”, beschouwt het netwerk deze als niet langer bereikbaar.
UE-bereikbaarheid – Geeft aan wanneer de UE beschikbaar komt voor DL-verkeer of SMS. Dit gebeurt wanneer de UE beschikbaar komt voor paging (voor een UE in eDRX-modus) of wanneer de UE naar de ECM-CONNECTED-modus gaat (voor een UE in PSM- of eDRX-modus), d.w.z. maakt een TAU of verzendt een uplinkpakket.
Locatierapportage – Met dit type monitoringgebeurtenissen kan de AS de locatie van de UE opvragen. De huidige locatie (huidige locatie) of de laatst bekende locatie (bepaald door de cel-ID van waaruit het apparaat de laatste keer TAU heeft gemaakt of verkeer heeft verzonden) kan worden opgevraagd, wat relevant is voor apparaten in de energiebesparende PSM- of eDRX-modus. Voor ‘Huidige locatie’ kan de AS herhaalde antwoorden vragen, waarbij de MME de AS op de hoogte stelt telkens wanneer de locatie van het apparaat verandert.
Verandering van IMSI-IMEI-associatie – Wanneer deze gebeurtenis wordt geactiveerd, begint SCEF veranderingen in de combinatie van IMSI (SIM-kaart-ID) en IMEI (apparaat-ID) te monitoren. Wanneer er zich een gebeurtenis voordoet, informeert AS. Kan worden gebruikt om automatisch een externe ID aan een apparaat te koppelen tijdens geplande vervangingswerkzaamheden of kan dienen als identificatie voor diefstal van een 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 het PLMN (Public Land Mobile Network) van de operator waarbij het apparaat is geregistreerd worden verzonden.
Communicatiefout — Dit type monitoring informeert de AS over fouten in de communicatie met het apparaat, op basis van de redenen voor het verbindingsverlies (vrijgaveoorzaakcode) ontvangen van het radiotoegangsnetwerk (S1-AP-protocol). Deze gebeurtenis kan helpen bepalen waarom de communicatie is mislukt - vanwege problemen op het netwerk, bijvoorbeeld wanneer de eNodeb overbelast is (radiobronnen niet beschikbaar) of vanwege een storing van het apparaat zelf (radioverbinding met UE verloren).
Beschikbaarheid na DDN-fout – deze gebeurtenis informeert de AS dat het apparaat beschikbaar is gekomen na een communicatiefout. Kan worden gebruikt wanneer er behoefte is om gegevens over te dragen naar een apparaat, maar de vorige poging niet is gelukt omdat de UE niet heeft gereageerd op een melding van het netwerk (paging) en de gegevens niet zijn afgeleverd. Als dit type monitoring is aangevraagd voor de UE, wordt de AS zodra het apparaat een inkomende communicatie maakt, een TAU maakt of gegevens naar de uplink verzendt, geïnformeerd dat het apparaat beschikbaar is gekomen. Omdat de DDN-procedure (downlink data notificatie) tussen MME en S/P-GW werkt, is dit type monitoring alleen beschikbaar voor IP-apparaten.
PDN-connectiviteitsstatus – informeert AS wanneer de apparaatstatus verandert (PDN-connectiviteitsstatus) - verbinding (PDN-activering) of verbroken verbinding (PDN-verwijdering). Dit kan door de AS worden gebruikt om de communicatie met de UE te initiëren, of omgekeerd, om te begrijpen dat communicatie niet langer mogelijk is. Dit type monitoring is beschikbaar voor IP- en niet-IP-apparaten.
Aantal UE's aanwezig in een geografisch gebied – Dit type monitoring wordt door de AS gebruikt om het aantal EU's in een bepaald geografisch gebied te bepalen.
Apparaattriggering)
In 2G/3G-netwerken bestond de registratieprocedure in het netwerk uit twee fasen: eerst registreerde het apparaat zich bij de SGSN (verbindingsprocedure) en activeerde vervolgens, indien nodig, de PDP-context - een verbinding met de pakketgateway (GGSN) om gegevens te verzenden. In 3G-netwerken vonden deze twee procedures opeenvolgend plaats, d.w.z. het apparaat wachtte niet op het moment waarop het gegevens moest overbrengen, maar activeerde PDP onmiddellijk nadat de koppelprocedure was voltooid. In LTE werden deze twee procedures gecombineerd tot één, dat wil zeggen dat het apparaat bij het aansluiten onmiddellijk om activering van de PDN-verbinding vroeg (analoog aan PDP in 2G/3G) via de eNodeB naar de MME-SGW-PGW.
NB-IoT definieert een verbindingsmethode als “koppelen zonder PDN”, dat wil zeggen dat de UE verbinding maakt zonder een PDN-verbinding tot stand te brengen. In dit geval is het niet beschikbaar om verkeer te verzenden en kan het alleen sms-berichten ontvangen of verzenden. Om een commando naar zo’n apparaat te sturen om PDN te activeren en verbinding te maken met AS, is de functionaliteit ‘Device triggering’ ontwikkeld.
Wanneer SCEF een opdracht ontvangt om een dergelijke UE te verbinden van de AS, initieert SCEF het verzenden van een controle-SMS naar het apparaat via het SMS-centrum. Bij ontvangst van een sms activeert het apparaat de PDN en maakt verbinding met de AS om verdere instructies te ontvangen of gegevens over te dragen.
Het kan voorkomen dat uw apparaatabonnement op SCEF afloopt. Ja, het abonnement heeft een eigen looptijd, bepaald door de operator of overeengekomen met AS. Na het verstrijken wordt de PDN gedeactiveerd op de MME en is het apparaat niet meer beschikbaar voor de AS. In dit geval zal de functionaliteit “Apparaattriggering” ook helpen. Wanneer SCEF nieuwe gegevens van AS ontvangt, achterhaalt het de verbindingsstatus van het apparaat en levert het de gegevens via een SMS-kanaal.
Conclusie
De functionaliteit van SCEF is uiteraard niet beperkt tot de hierboven beschreven diensten en evolueert en breidt zich voortdurend uit. Momenteel zijn er al meer dan een dozijn diensten gestandaardiseerd voor SCEF. Nu hebben we alleen de belangrijkste functies besproken waar ontwikkelaars veel vraag naar hebben, over de rest zullen we in toekomstige artikelen praten.
De vraag rijst meteen: hoe kun je testtoegang krijgen tot dit “wonder”-knooppunt voor voorlopige tests en het debuggen van mogelijke gevallen? Alles is heel eenvoudig. Elke ontwikkelaar kan een verzoek indienen bij [e-mail beveiligd], waarin het voldoende is om het doel van de verbinding aan te geven, een beschrijving van een mogelijk geval en contactgegevens voor communicatie.
Tot ziens!
Auteurs:
- senior expert van de afdeling convergente oplossingen en multimediadiensten Sergey Novikov ,
- expert van de afdeling convergente oplossingen en multimediadiensten Alexey Lapshin
Bron: www.habr.com