In die artikel “"Ons het gepraat oor die argitektuur van die pakketkern van die NB-IoT-netwerk, en ons het die voorkoms van 'n nuwe SCEF-nodus genoem. Ons verduidelik in die derde deel wat dit is en hoekom dit nodig is?
Wanneer 'n M2M-diens geskep word, staan toepassingontwikkelaars voor die volgende vrae:
- hoe om toestelle te identifiseer;
- watter verifikasie- en verifikasiealgoritme om te gebruik;
- watter vervoerprotokol om te kies vir interaksie met toestelle;
- hoe om data betroubaar aan toestelle te lewer;
- hoe om reëls vir die uitruil van data met hulle te organiseer en daar te stel;
- hoe om aanlyn inligting oor hul toestand te monitor en te bekom;
- hoe om data gelyktydig aan 'n groep van jou toestelle te lewer;
- hoe om data gelyktydig vanaf een toestel na verskeie kliënte te stuur;
- hoe om verenigde toegang tot bykomende operateurdienste te kry om jou toestel te bestuur.
Om dit op te los, is dit nodig om eie tegnies "swaar" oplossings te skep, wat lei tot verhoogde arbeidskoste en tyd-tot-mark dienste. Dit is waar die nuwe SCEF-nodus tot die redding kom.
Soos gedefinieer deur 3GPP, is SCEF (diensvermoë-blootstellingsfunksie) 'n heeltemal nuwe komponent van die 3GPP-argitektuur wie se funksie is om die dienste en vermoëns wat deur 3GPP-netwerkkoppelvlakke verskaf word, veilig bloot te stel deur API's.
In eenvoudige woorde, SCEF is 'n tussenganger tussen die netwerk en die toepassingsbediener (AS), 'n enkele venster van toegang tot operateurdienste vir die bestuur van jou M2M-toestel in die NB-IoT-netwerk deur 'n intuïtiewe, gestandaardiseerde API-koppelvlak.
SCEF verberg die kompleksiteit van 'n operateur se netwerk, wat toepassingsontwikkelaars in staat stel om komplekse, toestelspesifieke meganismes vir interaksie met toestelle weg te abstraheer.
Deur netwerkprotokolle in 'n bekende API vir toepassingsontwikkelaars te omskep, vergemaklik die SCEF API die skepping van nuwe dienste en verminder die tyd-tot-mark. Die nuwe nodus bevat ook funksies vir die identifisering/verifikasie van mobiele toestelle, die definisie van die reëls vir data-uitruiling tussen die toestel en AS, die verwydering van die behoefte vir toepassingsontwikkelaars om hierdie funksies aan hul kant te implementeer, en verskuif hierdie funksies na die skouers van die operateur.
SCEF dek die koppelvlakke wat nodig is vir verifikasie en magtiging van toepassingsbedieners, handhawing van UE-mobiliteit, data-oordrag en toestelsnellering, toegang tot bykomende dienste en operateurnetwerkvermoëns.
Na die AS is daar 'n enkele T8-koppelvlak, 'n API (HTTP/JSON) gestandaardiseer deur 3GPP. Alle koppelvlakke, met die uitsondering van T8, werk gebaseer op die DIAMETER-protokol (Fig. 1).
T6a – koppelvlak tussen SCEF en MME. Word gebruik vir mobiliteits-/sessiebestuurprosedures, oordrag van nie-IP-data, voorsiening van moniteringsgebeure en die ontvangs van verslae daaroor.
S6t – koppelvlak tussen SCEF en HSS. Vereis vir intekenaar-verifikasie, magtiging van toepassingbedieners, verkryging van 'n kombinasie van eksterne ID en IMSI/MSISDN, voorsiening van moniteringsgebeurtenisse en die ontvangs van verslae daaroor.
S6m/T4 – koppelvlakke van SCEF na HSS en SMS-C (3GPP definieer die MTC-IWF nodus, wat gebruik word vir toestelsnellering en SMS transmissie in NB-IoT netwerke. In alle implementerings is die funksionaliteit van hierdie nodus egter geïntegreer in SCEF, dus vir die vereenvoudiging van die stroombaan, sal ons dit nie afsonderlik oorweeg nie). Word gebruik om roete-inligting te verkry vir die stuur van SMS en interaksie met die SMS-sentrum.
T8 – API-koppelvlak vir SCEF-interaksie met toepassingsbedieners. Beide beheeropdragte en verkeer word deur hierdie koppelvlak oorgedra.
* in werklikheid is daar meer koppelvlakke; slegs die mees basiese word hier gelys. 'n Volledige lys word gegee in 3GPP 23.682 (4.3.2 Lys van verwysingspunte).
Hieronder is die sleutelfunksies en dienste van SCEF:
- koppel die SIM-kaart identifiseerder (IMSI) aan eksterne ID;
- oordrag van nie-IP-verkeer (Non-IP Data Delivery, NIDD);
- groep bedrywighede met behulp van eksterne groep ID;
- ondersteuning vir data-oordragmodus met bevestiging;
- buffering van MO (Mobile Originated) en MT (Mobile Terminated) data;
- stawing en magtiging van toestelle en toepassingsbedieners;
- gelyktydige gebruik van data van een UE deur verskeie AS'e;
- ondersteuning vir spesiale UE status monitering funksies (MONTE – Monitering Gebeurtenisse);
- toestelsnellering;
- verskaffing van nie-IP-dataswerwing.
Die basiese beginsel van interaksie tussen AS en SCEF is gebaseer op die sogenaamde skema. intekeninge. As dit nodig is om toegang tot enige SCEF-diens vir 'n spesifieke UE te verkry, moet die toepassingbediener 'n intekening skep deur 'n opdrag na die spesifieke API van die versoekte diens te stuur en 'n unieke identifiseerder in reaksie te ontvang. Waarna alle verdere aksies en kommunikasie met die UE binne die raamwerk van hierdie diens sal plaasvind met behulp van hierdie identifiseerder.
Eksterne ID: Universele toestelidentifiseerder
Een van die belangrikste veranderinge in die interaksieskema tussen AS en toestelle wanneer daar deur SCEF gewerk word, is die verskyning van 'n universele identifiseerder. Nou, in plaas van 'n telefoonnommer (MSISDN) of IP-adres, soos die geval was in die klassieke 2G/3G/LTE-netwerk, word die toestelidentifiseerder vir die toepassingbediener "eksterne ID". Dit word gedefinieer deur die standaard in 'n formaat wat bekend is vir toepassingsontwikkelaars " @ "
Ontwikkelaars hoef nie meer toestelverifikasiealgoritmes te implementeer nie; die netwerk neem hierdie funksie heeltemal oor. Eksterne ID is gekoppel aan IMSI, en die ontwikkelaar kan seker wees dat wanneer toegang tot 'n spesifieke eksterne ID verkry word, dit met 'n spesifieke SIM-kaart in wisselwerking tree. Wanneer jy 'n SIM-skyfie gebruik, kry jy 'n heeltemal unieke situasie wanneer die eksterne ID 'n spesifieke toestel uniek identifiseer!
Boonop kan verskeie eksterne ID's aan een IMSI gekoppel word - 'n selfs meer interessante situasie ontstaan wanneer die eksterne ID 'n spesifieke toepassing wat verantwoordelik is vir 'n spesifieke diens op 'n spesifieke toestel, uniek identifiseer.
'n Groepidentifiseerder verskyn ook - eksterne groep-ID, wat 'n stel individuele eksterne ID's insluit. Nou, met een versoek aan SCEF, kan AS groepbedrywighede inisieer - die stuur van data of beheeropdragte na verskeie toestelle wat in 'n enkele logiese groep verenig is.
As gevolg van die feit dat vir AS-ontwikkelaars die oorgang na 'n nuwe toestelidentifiseerder nie oombliklik kan wees nie, het SCEF die moontlikheid van AS-kommunikasie met die UE gelaat deur 'n standaardnommer - MSISDN.
Oordrag van nie-IP-verkeer (Nie-IP-datalewering, NIDD)
In NB-IoT, as deel van die optimalisering van meganismes vir die oordrag van klein hoeveelhede data, bykomend tot die reeds bestaande PDN-tipes, soos IPv4, IPv6 en IPv4v6, het 'n ander tipe verskyn - nie-IP. In hierdie geval word die toestel (UE) nie 'n IP-adres toegeken nie en data word versend sonder om die IP-protokol te gebruik. Verkeer vir sulke verbindings kan op twee maniere gelei word: klassiek - MME -> SGW -> PGW en dan deur die PtP-tonnel na AS (Fig. 2) of deur gebruik te maak van SCEF (Fig. 3).
Die klassieke metode bied geen spesiale voordele bo IP-verkeer nie, behalwe vir die vermindering van die grootte van gestuurde pakkies as gevolg van die afwesigheid van IP-opskrifte. Die gebruik van SCEF maak 'n aantal nuwe moontlikhede oop en vereenvoudig die prosedures vir interaksie met toestelle aansienlik.
Wanneer data via SCEF oorgedra word, verskyn twee baie belangrike voordele bo klassieke IP-verkeer:
Lewering van MT-verkeer na die toestel via eksterne ID
Om 'n boodskap na 'n klassieke IP-toestel te stuur, moet die AS sy IP-adres ken. Hier ontstaan 'n probleem: aangesien die toestel gewoonlik 'n "grys" IP-adres by registrasie ontvang, kommunikeer dit met die toepassingsbediener, wat op die internet geleë is, deur 'n NAT-nodus, waar die grys adres in wit vertaal word. Die kombinasie van grys en wit IP-adresse duur vir 'n beperkte tyd, afhangende van die NAT-instellings. Gemiddeld vir TCP of UDP - nie meer as vyf minute nie. Dit wil sê, as daar geen data-uitruiling met hierdie toestel binne 5 minute is nie, sal die verbinding disintegreer en die toestel sal nie meer toeganklik wees by die wit adres waarmee die sessie met AS begin is nie. Daar is verskeie oplossings:
1. Gebruik hartklop. Sodra 'n verbinding tot stand gebring is, moet die toestel elke paar minute pakkies met die AS uitruil, om sodoende te verhoed dat NAT-vertalings sluit. Maar van enige energiedoeltreffendheid kan hier nie sprake wees nie.
2. Kontroleer elke keer, indien nodig, die beskikbaarheid van pakkette vir die toestel op die AS - stuur 'n boodskap na die opskakel.
3. Skep 'n private APN (VRF), waar die toepassingsbediener en toestelle op dieselfde subnet sal wees, en ken statiese IP-adresse aan die toestelle toe. Dit sal werk, maar dit is amper onmoontlik as ons praat van 'n vloot van duisende, tienduisende toestelle.
4. Ten slotte, die mees geskikte opsie: gebruik IPv6, dit vereis nie NAT nie, aangesien IPv6-adresse direk vanaf die internet toeganklik is. Selfs in hierdie geval, wanneer die toestel herregistreer word, sal dit egter 'n nuwe IPv6-adres ontvang en sal dit nie meer toeganklik wees met die vorige een nie.
Gevolglik is dit nodig om een of ander inisialiseringspakkie met 'n toestelidentifiseerder na die bediener te stuur om die nuwe IP-adres van die toestel te rapporteer. Wag dan vir 'n bevestigingspakkie van AS, wat ook energiedoeltreffendheid beïnvloed.
Hierdie metodes werk goed vir 2G/3G/LTE-toestelle, waar die toestel nie streng vereistes vir outonomie het nie en gevolglik geen beperkings op lugtyd en verkeer is nie. Hierdie metodes is nie geskik vir NB-IoT nie weens hul hoë energieverbruik.
SCEF los hierdie probleem op: aangesien die enigste toestelidentifiseerder vir 'n AS 'n eksterne ID is, hoef die AS slegs 'n datapakkie na SCEF te stuur vir 'n spesifieke eksterne ID, en SCEF sorg vir die res. As die toestel in PSM- of eDRX-kragbesparingsmodus is, sal data gebuffer word en afgelewer word wanneer die toestel beskikbaar word. As die toestel vir verkeer beskikbaar is, sal die data onmiddellik afgelewer word. Dieselfde geld vir bestuurspanne.
Die AS kan te eniger tyd die gebufferde boodskap aan die UE herroep of dit met 'n nuwe een vervang.
Die buffermeganisme kan ook gebruik word wanneer MO-data van die UE na die AS oorgedra word. Indien SCEF nie in staat was om data onmiddellik aan die AS te lewer nie, byvoorbeeld as instandhoudingswerk op die AS-bedieners aan die gang is, sal hierdie pakkies gebuffer word en gewaarborg word om afgelewer te word sodra die AS beskikbaar word.
Soos hierbo genoem, word toegang tot 'n spesifieke diens en UE vir 'n AS (en NIDD is 'n diens) gereguleer deur reëls en beleide aan die SCEF-kant, wat voorsiening maak vir die unieke moontlikheid van gelyktydige gebruik van data van een UE deur verskeie AS'e. Dié. as verskeie AS op een UE ingeteken het, sal SCEF dit na ontvangs van data van die UE aan alle ingetekende AS stuur. Dit is goed geskik vir gevalle waar die skepper van 'n vloot gespesialiseerde toestelle data tussen verskeie kliënte deel. Deur byvoorbeeld 'n netwerk van weerstasies te skep wat op NB-IoT loop, kan jy data van hulle gelyktydig aan baie dienste verkoop.
Gewaarborgde boodskap aflewering meganisme
Betroubare datadiens is 'n meganisme vir gewaarborgde aflewering van MO- en MT-boodskappe sonder die gebruik van gespesialiseerde algoritmes op protokolvlak, soos byvoorbeeld handdruk in TCP. Dit werk deur 'n spesiale vlag in die diensgedeelte van die boodskap in te sluit wanneer dit tussen die UE en SCEF uitgeruil word. Die AS besluit of hierdie meganisme geaktiveer moet word wanneer verkeer oorgedra word.
As die meganisme geaktiveer is, sluit die UE 'n spesiale vlag in die oorhoofse deel van die pakkie in wanneer dit gewaarborgde aflewering van MO-verkeer vereis. By ontvangs van so 'n pakkie, reageer die SCEF aan die UE met 'n erkenning. As die UE nie die bevestigingspakkie ontvang nie, sal die pakkie na SCEF hergestuur word. Dieselfde ding gebeur vir MT-verkeer.
Toestelmonitering (monitering van gebeure - MONTE)
Soos hierbo genoem, sluit die SCEF-funksionaliteit onder andere funksies in vir die monitering van die toestand van die UE, die sg. toestelmonitering. En as nuwe identifiseerders en data-oordragmeganismes optimaliserings (hoewel baie ernstig) van bestaande prosedures is, dan is MONTE 'n heeltemal nuwe funksionaliteit wat nie in 2G/3G/LTE-netwerke beskikbaar is nie. MONTE laat AS toe om toestelparameters soos verbindingstatus, kommunikasiebeskikbaarheid, ligging, swerfstatus, ens. Ons sal 'n bietjie later oor elkeen in meer besonderhede praat.
As dit nodig is om enige moniteringsgebeurtenis vir 'n toestel of groep toestelle te aktiveer, teken die AS in op die ooreenstemmende diens deur die ooreenstemmende API MONTE-opdrag na SCEF te stuur, wat parameters insluit soos eksterne ID of eksterne groep ID, AS identifiseerder, monitering tipe, aantal verslae, wat AS wil ontvang. Indien die AS gemagtig is om die versoek uit te voer, sal SCEF, afhangend van die tipe, die geleentheid aan die HSS of MME verskaf (Fig. 4). Wanneer 'n gebeurtenis plaasvind, genereer die MME of HSS 'n verslag aan SCEF, wat dit na die AS stuur.
Voorsiening van alle gebeurtenisse, met die uitsondering van "Aantal UE's teenwoordig in 'n geografiese gebied", geskied deur HSS. Twee gebeurtenisse "Verandering van IMSI-IMEI Association" en "Roaming Status" word direk op HSS nagespoor, die res sal deur HSS op MME voorsien word.
Gebeurtenisse kan óf eenmalig óf periodiek wees, en word bepaal deur hul tipe.
Die stuur van 'n verslag oor 'n gebeurtenis (rapportering) word uitgevoer deur die nodus wat die gebeurtenis direk na SCEF volg (Fig. 5).
Belangrike punt: Moniteringsgebeure kan toegepas word op beide nie-IP-toestelle wat via SCEF gekoppel is en IP-toestelle wat data op die klassieke manier via MME-SGW-PGW oordra.
Kom ons kyk van naderby na elk van die moniteringsgebeurtenisse:
Verlies aan konneksie - lig die AS in dat die UE nie meer beskikbaar is vir óf dataverkeer óf sein nie. Die gebeurtenis vind plaas wanneer die "mobiele bereikbaarheidstydteller" vir die UE op die MME verval. In 'n versoek vir hierdie tipe monitering, kan die AS sy “Maksimum Deteksie Tyd” waarde aandui - as die UE gedurende hierdie tyd geen aktiwiteit toon nie, sal die AS ingelig word dat die UE nie beskikbaar is nie, wat die rede aandui. Die gebeurtenis vind ook plaas as die UE om enige rede met geweld deur die netwerk verwyder is.
* Om die netwerk te laat weet dat die toestel nog beskikbaar is, begin dit periodiek 'n opdateringsprosedure - Tracking Area Update (TAU). Die frekwensie van hierdie prosedure word ingestel deur die netwerk met timer T3412 of (T3412_extended in die geval van PSM), waarvan die waarde na die toestel oorgedra word tydens die Aanheg-prosedure of die volgende TAU. Mobiele bereikbaarheidstydteller is gewoonlik 'n paar minute langer as T3412. As die UE nie 'n TAU gemaak het voor die verstryking van die "Mobiele bereikbaarheid timer" nie, beskou die netwerk dit as nie meer bereikbaar nie.
UE bereikbaarheid - Dui aan wanneer die UE beskikbaar word vir DL-verkeer of SMS. Dit vind plaas wanneer die UE beskikbaar word vir blaai (vir 'n UE in eDRX-modus) of wanneer die UE in ECM-CONNECTED-modus gaan (vir 'n UE in PSM- of eDRX-modus), d.w.s. maak 'n TLU of stuur 'n opskakelpakkie.
Liggingverslaggewing – Hierdie tipe moniteringsgebeurtenisse laat die AS toe om die ligging van die UE te bevraagteken. Óf die huidige ligging (Huidige ligging) óf die laaste bekende ligging (Bepaal deur die sel-ID waaruit die toestel TAU gemaak het of die laaste keer verkeer oorgedra het) kan aangevra word, wat relevant is vir toestelle in PSM- of eDRX-kragbesparingsmodusse. Vir "Huidige ligging", kan die AS herhaalde antwoorde versoek, met die MME wat die AS inlig elke keer as die toestel se ligging verander.
Verandering van IMSI-IMEI Vereniging - Wanneer hierdie gebeurtenis geaktiveer word, begin SCEF om veranderinge in die kombinasie van IMSI (SIM-kaartidentifiseerder) en IMEI (toestelidentifiseerder) te monitor. Wanneer 'n gebeurtenis plaasvind, lig AS. Kan gebruik word om outomaties 'n eksterne ID aan 'n toestel te herbind tydens geskeduleerde vervangingswerk of dien as 'n identifiseerder vir diefstal van 'n toestel.
Swerfstatus – hierdie tipe monitering word deur AS gebruik om te bepaal of die UE in die tuisnetwerk of in die netwerk van 'n swerfvennoot is. Opsioneel kan die PLMN (Public Land Mobile Network) van die operateur waarin die toestel geregistreer is versend word.
Kommunikasie mislukking — Hierdie tipe monitering lig die AS in oor mislukkings in kommunikasie met die toestel, gebaseer op die redes vir die verbindingsverlies (vrystellingoorsaakkode) wat vanaf die radiotoegangsnetwerk (S1-AP-protokol) ontvang is. Hierdie gebeurtenis kan help om vas te stel hoekom die kommunikasie misluk het - as gevolg van probleme op die netwerk, byvoorbeeld wanneer die eNodeb oorlaai is (Radiobronne nie beskikbaar nie) of as gevolg van 'n mislukking van die toestel self (Radio Connection With UE Lost).
Beskikbaarheid na DDN-mislukking – hierdie gebeurtenis stel die AS in kennis dat die toestel beskikbaar geword het na 'n kommunikasiefout. Kan gebruik word wanneer daar 'n behoefte is om data na 'n toestel oor te dra, maar die vorige poging was nie suksesvol nie omdat die UE nie op 'n kennisgewing van die netwerk (blaai) gereageer het nie en die data nie afgelewer is nie. As hierdie tipe monitering vir die UE versoek is, sal die AS ingelig word dat die toestel beskikbaar geword het sodra die toestel 'n inkomende kommunikasie maak, 'n TLU maak of data na die opskakel stuur. Aangesien die DDN-prosedure (afskakeldatakennisgewing) tussen MME en S/P-GW werk, is hierdie tipe monitering slegs vir IP-toestelle beskikbaar.
PDN-verbindingstatus – lig AS in wanneer die toestelstatus verander (PDN-konnektiwiteitstatus) - verbinding (PDN-aktivering) of ontkoppeling (PDN-skrap). Dit kan deur die AS gebruik word om kommunikasie met die UE te inisieer, of omgekeerd, om te verstaan dat kommunikasie nie meer moontlik is nie. Hierdie tipe monitering is beskikbaar vir IP- en nie-IP-toestelle.
Aantal UE's teenwoordig in 'n geografiese gebied – Hierdie tipe monitering word deur die AS gebruik om die aantal UE's in 'n sekere geografiese area te bepaal.
Toestel aktiveer)
In 2G/3G-netwerke was die registrasieprosedure in die netwerk twee-fase: eerstens, die toestel wat by die SGSN geregistreer is (hegprosedure), dan, indien nodig, het dit die PDP-konteks geaktiveer - 'n verbinding met die pakketpoort (GGSN) om data oor te dra. In 3G-netwerke het hierdie twee prosedures opeenvolgend plaasgevind, m.a.w. die toestel het nie gewag vir die oomblik toe dit nodig was om data oor te dra nie, maar PDP geaktiveer onmiddellik nadat die aanhegprosedure voltooi is. In LTE is hierdie twee prosedures in een gekombineer, dit wil sê, wanneer dit geheg is, het die toestel onmiddellik die aktivering van die PDN-verbinding (analoog aan PDP in 2G/3G) via die eNodeB na die MME-SGW-PGW versoek.
NB-IoT definieer 'n verbindingsmetode as "heg aan sonder PDN", dit wil sê, die UE heg aan sonder om 'n PDN-verbinding te vestig. In hierdie geval is dit nie beskikbaar om verkeer te stuur nie, en kan dit slegs SMS ontvang of stuur. Om 'n opdrag na so 'n toestel te stuur om PDN te aktiveer en aan AS te koppel, is die "Device triggering"-funksie ontwikkel.
Wanneer 'n opdrag ontvang word om so 'n UE vanaf die AS te koppel, begin SCEF die stuur van 'n beheer-SMS na die toestel deur die SMS-sentrum. Wanneer 'n SMS ontvang word, aktiveer die toestel die PDN en koppel dit aan die AS om verdere instruksies te ontvang of data oor te dra.
Daar kan tye wees wanneer jou toestelintekening op SCEF verval. Ja, die intekening het sy eie leeftyd, bepaal deur die operateur of ooreengekom met AS. By verstryking sal die PDN op die MME gedeaktiveer word en die toestel sal nie vir die AS beskikbaar wees nie. In hierdie geval sal die "Device triggering"-funksie ook help. Wanneer nuwe data vanaf AS ontvang word, sal SCEF die toestelverbindingstatus uitvind en die data via SMS-kanaal aflewer.
Gevolgtrekking
Die funksionaliteit van SCEF is natuurlik nie beperk tot die dienste wat hierbo beskryf is nie en is voortdurend aan die ontwikkel en uitbrei. Tans is meer as 'n dosyn dienste reeds vir SCEF gestandaardiseer. Nou het ons net die hooffunksies aangeraak wat deur ontwikkelaars in aanvraag is; ons sal oor die res in toekomstige artikels praat.
Die vraag ontstaan onmiddellik: hoe om toetstoegang tot hierdie "wonderwerk"-nodus te kry vir voorlopige toetsing en ontfouting van moontlike gevalle? Alles is baie eenvoudig. Enige ontwikkelaar kan 'n versoek indien by [e-pos beskerm], waarin dit genoeg is om die doel van verbinding aan te dui, 'n beskrywing van 'n moontlike saak en kontakinligting vir kommunikasie.
Tot volgende keer!
Skrywers:
- senior deskundige van die departement van konvergente oplossings en multimediadienste Sergey Novikov ,
- kenner van die afdeling vir konvergente oplossings en multimediadienste Alexey Lapshin
Bron: will.com