A l’article “", parlant de l'arquitectura del nucli de paquets de la xarxa NB-IoT, vam esmentar l'aparició d'un nou node SCEF. Expliquem a la tercera part què és i per què cal?
Quan creen un servei M2M, els desenvolupadors d'aplicacions s'enfronten a les preguntes següents:
- com identificar els dispositius;
- quin algorisme de verificació i autenticació utilitzar;
- quin protocol de transport triar per interactuar amb dispositius;
- com lliurar dades de manera fiable als dispositius;
- com organitzar i establir regles per intercanviar dades amb ells;
- com controlar i obtenir informació sobre el seu estat en línia;
- com lliurar dades simultàniament a un grup dels vostres dispositius;
- com enviar dades simultàniament des d'un dispositiu a diversos clients;
- com obtenir accés unificat a serveis addicionals de l'operador per gestionar el vostre dispositiu.
Per resoldre'ls, és necessari crear solucions patentades tècnicament "pesades", la qual cosa comporta un augment dels costos laborals i dels serveis de temps de llançament al mercat. Aquí és on el nou node SCEF ve al rescat.
Tal com es defineix per 3GPP, SCEF (funció d'exposició de capacitat de servei) és un component completament nou de l'arquitectura 3GPP la funció de la qual és exposar de manera segura els serveis i les capacitats que ofereixen les interfícies de xarxa 3GPP mitjançant API.
En paraules senzilles, SCEF és un intermediari entre la xarxa i el servidor d'aplicacions (AS), una finestra única d'accés als serveis de l'operador per gestionar el vostre dispositiu M2M a la xarxa NB-IoT mitjançant una interfície API intuïtiva i estandarditzada.
SCEF amaga la complexitat de la xarxa d'un operador, permetent als desenvolupadors d'aplicacions abstraure mecanismes complexos i específics del dispositiu per interactuar amb els dispositius.
En transformar els protocols de xarxa en una API familiar per als desenvolupadors d'aplicacions, l'API SCEF facilita la creació de nous serveis i redueix el temps de comercialització. El nou node també inclou funcions d'identificació/autenticació de dispositius mòbils, definint les regles d'intercanvi de dades entre el dispositiu i AS, eliminant la necessitat que els desenvolupadors d'aplicacions implementin aquestes funcions al seu costat, traslladant aquestes funcions a les espatlles de l'operador.
SCEF cobreix les interfícies necessàries per a l'autenticació i l'autorització dels servidors d'aplicacions, el manteniment de la mobilitat de la UE, la transferència de dades i l'activació del dispositiu, l'accés a serveis addicionals i les capacitats de xarxa de l'operador.
Cap a l'AS hi ha una única interfície T8, una API (HTTP/JSON) estandarditzada per 3GPP. Totes les interfícies, a excepció de la T8, funcionen segons el protocol DIAMETER (Fig. 1).
T6a: interfície entre SCEF i MME. S'utilitza per a procediments de gestió de Mobilitat/Sessió, transmissió de dades no IP, subministrament d'esdeveniments de seguiment i recepció d'informes sobre ells.
S6t: interfície entre SCEF i HSS. Necessari per a l'autenticació de subscriptors, l'autorització dels servidors d'aplicacions, l'obtenció d'una combinació d'ID extern i IMSI/MSISDN, el subministrament d'esdeveniments de monitorització i la recepció d'informes sobre ells.
S6m/T4: interfícies de SCEF a HSS i SMS-C (3GPP defineix el node MTC-IWF, que s'utilitza per a l'activació de dispositius i la transmissió d'SMS en xarxes NB-IoT. No obstant això, en totes les implementacions la funcionalitat d'aquest node està integrada en SCEF, així que per simplificar el circuit, no el considerarem per separat). S'utilitza per obtenir informació d'encaminament per enviar SMS i interactuar amb el centre d'SMS.
T8: interfície API per a la interacció SCEF amb servidors d'aplicacions. Tant les ordres de control com el trànsit es transmeten mitjançant aquesta interfície.
*en realitat hi ha més interfícies; aquí només s'enumeren les més bàsiques. Es proporciona una llista completa a 3GPP 23.682 (4.3.2 Llista de punts de referència).
A continuació es mostren les funcions i serveis clau de SCEF:
- enllaçar l'identificador de la targeta SIM (IMSI) amb l'identificador extern;
- transmissió de trànsit no IP (Non-IP Data Delivery, NIDD);
- operacions de grup utilitzant ID de grup extern;
- suport per al mode de transmissió de dades amb confirmació;
- emmagatzematge en memòria intermèdia de dades MO (Mobile Originated) i MT (Mobile Terminated);
- autenticació i autorització de dispositius i servidors d'aplicacions;
- ús simultani de dades d'una UE per part de diversos AS;
- suport per a funcions especials de control de l'estat de la UE (MONTE – Monitoring Events);
- activació del dispositiu;
- proporcionant itinerància de dades no IP.
El principi bàsic d'interacció entre AS i SCEF es basa en l'anomenat esquema. subscripcions. Si és necessari accedir a qualsevol servei SCEF per a un UE específic, el servidor d'aplicacions ha de crear una subscripció enviant una ordre a l'API específica del servei sol·licitat i rebre un identificador únic com a resposta. Després d'això, totes les accions i comunicacions posteriors amb la UE en el marc d'aquest servei tindran lloc mitjançant aquest identificador.
Identificador extern: identificador universal del dispositiu
Un dels canvis més importants en l'esquema d'interacció entre AS i dispositius quan es treballa mitjançant SCEF és l'aparició d'un identificador universal. Ara, en lloc d'un número de telèfon (MSISDN) o una adreça IP, com era el cas de la xarxa clàssica 2G/3G/LTE, l'identificador del dispositiu per al servidor d'aplicacions es converteix en "ID extern". Està definit per l'estàndard en un format familiar per als desenvolupadors d'aplicacions " @ "
Els desenvolupadors ja no necessiten implementar algorismes d'autenticació de dispositius; la xarxa assumeix completament aquesta funció. L'identificador extern està lligat a IMSI i el desenvolupador pot estar segur que quan accedeix a un identificador extern específic, interactua amb una targeta SIM específica. Quan utilitzeu un xip SIM, obteniu una situació completament única quan l'identificador extern identifica de manera única un dispositiu específic.
A més, es poden enllaçar diversos identificadors externs a un IMSI; una situació encara més interessant sorgeix quan l'identificador extern identifica de manera única una aplicació específica responsable d'un servei específic en un dispositiu específic.
També apareix un identificador de grup: identificador de grup extern, que inclou un conjunt d'identificadors externs individuals. Ara, amb una sol·licitud a SCEF, AS pot iniciar operacions de grup: enviant dades o ordres de control a diversos dispositius units en un sol grup lògic.
A causa del fet que per als desenvolupadors d'AS la transició a un nou identificador de dispositiu no pot ser instantània, SCEF va deixar la possibilitat de comunicació AS amb la UE mitjançant un número estàndard: MSISDN.
Transmissió de trànsit no IP (Enviament de dades no IP, NIDD)
A NB-IoT, com a part de l'optimització dels mecanismes de transmissió de petites quantitats de dades, a més dels tipus PDN ja existents, com IPv4, IPv6 i IPv4v6, ha aparegut un altre tipus: no IP. En aquest cas, al dispositiu (UE) no se li assigna una adreça IP i les dades es transmeten sense utilitzar el protocol IP. El trànsit d'aquestes connexions es pot encaminar de dues maneres: clàssic - MME -> SGW -> PGW i després a través del túnel PtP fins a AS (Fig. 2) o mitjançant SCEF (Fig. 3).
El mètode clàssic no ofereix cap avantatge especial respecte al trànsit IP, excepte la reducció de la mida dels paquets transmesos a causa de l'absència de capçaleres IP. L'ús de SCEF obre una sèrie de noves possibilitats i simplifica significativament els procediments d'interacció amb els dispositius.
Quan es transmeten dades mitjançant SCEF, apareixen dos avantatges molt importants respecte al trànsit IP clàssic:
Lliurament de trànsit MT al dispositiu mitjançant identificador extern
Per enviar un missatge a un dispositiu IP clàssic, l'AS ha de conèixer la seva adreça IP. Aquí sorgeix un problema: com que el dispositiu sol rebre una adreça IP "grisa" en registrar-se, es comunica amb el servidor d'aplicacions, que es troba a Internet, a través d'un node NAT, on l'adreça grisa es tradueix en blanc. La combinació d'adreces IP grises i blanques dura un temps limitat, depenent de la configuració del NAT. De mitjana, per a TCP o UDP, no més de cinc minuts. És a dir, si no hi ha intercanvi de dades amb aquest dispositiu en 5 minuts, la connexió es desintegrarà i ja no es podrà accedir al dispositiu a l'adreça blanca amb la qual es va iniciar la sessió amb AS. Hi ha diverses solucions:
1. Utilitza el batec del cor. Un cop establerta la connexió, el dispositiu ha d'intercanviar paquets amb l'AS cada pocs minuts, evitant així que es tanquin les traduccions NAT. Però aquí no es pot parlar d'eficiència energètica.
2. Cada vegada, si cal, comproveu la disponibilitat dels paquets per al dispositiu a l'AS: envieu un missatge a l'enllaç ascendent.
3. Creeu un APN privat (VRF), on el servidor d'aplicacions i els dispositius estaran a la mateixa subxarxa, i assigneu adreces IP estàtiques als dispositius. Funcionarà, però és gairebé impossible quan parlem d'una flota de milers, desenes de milers de dispositius.
4. Finalment, l'opció més adequada: utilitzar IPv6, no requereix NAT, ja que les adreces IPv6 són directament accessibles des d'Internet. Tanmateix, fins i tot en aquest cas, quan el dispositiu es torni a registrar, rebrà una nova adreça IPv6 i ja no serà accessible mitjançant l'anterior.
En conseqüència, cal enviar algun paquet d'inicialització amb un identificador de dispositiu al servidor per informar de la nova adreça IP del dispositiu. A continuació, espereu un paquet de confirmació d'AS, que també afecta l'eficiència energètica.
Aquests mètodes funcionen bé per a dispositius 2G/3G/LTE, on el dispositiu no té requisits estrictes d'autonomia i, per tant, no hi ha restriccions de temps d'aire i trànsit. Aquests mètodes no són adequats per a NB-IoT a causa del seu alt consum d'energia.
SCEF resol aquest problema: com que l'únic identificador de dispositiu per a un AS és un ID extern, l'AS només necessita enviar un paquet de dades a SCEF per a un ID extern específic i SCEF s'encarrega de la resta. En cas que el dispositiu estigui en mode d'estalvi d'energia PSM o eDRX, les dades s'emmagatzemaran i es lliuraran quan el dispositiu estigui disponible. Si el dispositiu està disponible per al trànsit, les dades es lliuraran immediatament. El mateix passa amb els equips directius.
En qualsevol moment, l'AS pot recuperar el missatge en memòria intermèdia a l'UE o substituir-lo per un de nou.
El mecanisme de memòria intermèdia també es pot utilitzar quan es transmeten dades MO des de l'UE a l'AS. Si SCEF no ha pogut lliurar dades a l'AS immediatament, per exemple, si s'està treballant de manteniment als servidors de l'AS, aquests paquets es guardaran a la memòria intermèdia i es garanteix que es lliuraran tan aviat com l'AS estigui disponible.
Com s'ha indicat anteriorment, l'accés a un servei i UE específics per a un AS (i NIDD és un servei) està regulat per regles i polítiques del costat SCEF, que permet la possibilitat única d'utilitzar dades simultàniament d'un UE per diversos AS. Aquells. si diversos AS s'han subscrit a un UE, després de rebre dades de l'UE, SCEF les enviarà a tots els AS subscrits. Això és molt adequat per als casos en què el creador d'una flota de dispositius especialitzats comparteix dades entre diversos clients. Per exemple, en crear una xarxa d'estacions meteorològiques que funcionen amb NB-IoT, podeu vendre dades d'elles a molts serveis simultàniament.
Mecanisme de lliurament de missatges garantit
El servei de dades fiables és un mecanisme per garantir el lliurament de missatges MO i MT sense l'ús d'algoritmes especialitzats a nivell de protocol, com, per exemple, l'encaix de mans en TCP. Funciona incloent una bandera especial a la part de servei del missatge quan s'intercanvia entre la UE i SCEF. L'AS decideix si s'activa o no aquest mecanisme quan es transmet el trànsit.
Si el mecanisme està activat, la UE inclou una bandera especial a la part superior del paquet quan requereix un lliurament garantit del trànsit MO. En rebre aquest paquet, l'SCEF respon a la UE amb un reconeixement. Si la UE no rep el paquet de reconeixement, el paquet cap a SCEF es tornarà a enviar. El mateix passa amb el trànsit MT.
Supervisió de dispositius (vigilància d'esdeveniments - MONTE)
Com s'ha esmentat anteriorment, la funcionalitat SCEF, entre altres coses, inclou funcions de seguiment de l'estat de la UE, l'anomenada. monitorització del dispositiu. I si els nous identificadors i mecanismes de transferència de dades són optimitzacions (encara que molt greus) dels procediments existents, aleshores MONTE és una funcionalitat completament nova que no està disponible a les xarxes 2G/3G/LTE. MONTE permet a AS controlar paràmetres del dispositiu com ara l'estat de la connexió, la disponibilitat de la comunicació, la ubicació, l'estat d'itinerància, etc. En parlarem de cadascun amb més detall una mica més endavant.
Si és necessari activar qualsevol esdeveniment de monitorització per a un dispositiu o grup de dispositius, l'AS es subscriu al servei corresponent enviant l'ordre API MONTE corresponent a SCEF, que inclou paràmetres com l'identificador extern o l'identificador de grup extern, l'identificador d'AS, la supervisió. tipus, nombre d'informes, que vol rebre AS. Si l'AS està autoritzat per executar la sol·licitud, SCEF, segons el tipus, subministrarà l'esdeveniment a l'HSS o al MME (Fig. 4). Quan es produeix un esdeveniment, el MME o HSS genera un informe a SCEF, que l'envia a l'AS.
El subministrament de tots els esdeveniments, a excepció del "Nombre d'UEs presents en una àrea geogràfica", es fa mitjançant HSS. Dos esdeveniments "Canvi de l'associació IMSI-IMEI" i "Estat d'itinerància" es fan un seguiment directament a HSS, la resta serà subministrat per HSS a MME.
Els esdeveniments poden ser puntuals o periòdics i es determinen pel seu tipus.
L'enviament d'un informe sobre un esdeveniment (informe) el realitza el node que fa un seguiment de l'esdeveniment directament a SCEF (Fig. 5).
Punt important: Els esdeveniments de monitorització es poden aplicar tant a dispositius no IP connectats mitjançant SCEF com a dispositius IP que transmeten dades de la manera clàssica mitjançant MME-SGW-PGW.
Fem una ullada més de prop a cadascun dels esdeveniments de seguiment:
Pèrdua de connectivitat — informa l'AS que l'UE ja no està disponible ni per al trànsit de dades ni per a la senyalització. L'esdeveniment es produeix quan el "temporitzador d'accessibilitat mòbil" per a la UE caduca a l'MME. En una sol·licitud d'aquest tipus de monitorització, l'AS pot indicar el seu valor de "Temps màxim de detecció": si durant aquest temps l'UE no mostra cap activitat, s'informarà a l'AS que l'UE no està disponible, indicant-ne el motiu. L'esdeveniment també es produeix si la xarxa va eliminar per la força la UE per qualsevol motiu.
* Per fer saber a la xarxa que el dispositiu encara està disponible, inicia periòdicament un procediment d'actualització: Actualització de l'àrea de seguiment (TAU). La freqüència d'aquest procediment l'estableix la xarxa mitjançant el temporitzador T3412 o (T3412_extended en el cas de PSM), el valor del qual es transmet al dispositiu durant el procediment Attach o la següent TAU. El temporitzador d'accessibilitat mòbil sol ser uns minuts més llarg que el T3412. Si la UE no ha fet una TAU abans de l'expiració del "Temporitzador d'accessibilitat mòbil", la xarxa considera que ja no és accessible.
Accessibilitat de la UE – Indica quan la UE està disponible per al trànsit DL o SMS. Això passa quan l'UE està disponible per a la paginació (per a un UE en mode eDRX) o quan l'UE entra en mode ECM-CONNECTED (per a un UE en mode PSM o eDRX), és a dir. fa un TAU o envia un paquet d'enllaç ascendent.
Informe d'ubicació – Aquest tipus d'esdeveniments de supervisió permet que l'AS consulti la ubicació de l'UE. Es pot sol·licitar la ubicació actual (Ubicació actual) o l'última ubicació coneguda (determinada per l'identificador de cel·la des de la qual el dispositiu va fer TAU o va transmetre trànsit l'última vegada), cosa que és rellevant per als dispositius en modes d'estalvi d'energia PSM o eDRX. Per a la "Ubicació actual", l'AS pot sol·licitar respostes repetides, amb l'MME informant l'AS cada vegada que canvia la ubicació del dispositiu.
Canvi d'Associació IMSI-IMEI – Quan aquest esdeveniment està activat, SCEF comença a controlar els canvis en la combinació d'IMSI (identificador de targeta SIM) i IMEI (identificador de dispositiu). Quan es produeix un esdeveniment, informa AS. Es pot utilitzar per tornar a vincular automàticament una identificació externa a un dispositiu durant el treball de substitució programat o servir com a identificador per al robatori d'un dispositiu.
Estat d'itinerància – aquest tipus de monitorització l'utilitza AS per determinar si l'UE es troba a la xarxa domèstica o a la xarxa d'un soci en itinerància. Opcionalment es pot transmetre la PLMN (Public Land Mobile Network) de l'operador en què està registrat el dispositiu.
Fracàs de comunicació — Aquest tipus de monitorització informa a l'AS sobre fallades en la comunicació amb el dispositiu, en funció dels motius de la pèrdua de connexió (codi de causa d'alliberament) rebuda de la xarxa d'accés de ràdio (protocol S1-AP). Aquest esdeveniment pot ajudar a determinar per què ha fallat la comunicació, a causa de problemes a la xarxa, per exemple, quan l'eNodeb està sobrecarregat (recursos de ràdio no disponibles) o a causa d'una fallada del propi dispositiu (connexió de ràdio amb UE perdut).
Disponibilitat després d'un error DDN – aquest esdeveniment informa l'AS que el dispositiu està disponible després d'un error de comunicació. Es pot utilitzar quan cal transferir dades a un dispositiu, però l'intent anterior no va tenir èxit perquè l'UE no va respondre a una notificació de la xarxa (paging) i les dades no es van lliurar. Si s'ha sol·licitat aquest tipus de monitorització per a la UE, tan aviat com el dispositiu faci una comunicació entrant, faci una TAU o enviï dades a l'enllaç ascendent, l'AS serà informat que el dispositiu està disponible. Com que el procediment DDN (notificació de dades d'enllaç descendent) funciona entre MME i S/P-GW, aquest tipus de monitorització només està disponible per a dispositius IP.
Estat de connectivitat PDN – informa AS quan l'estat del dispositiu canvia (estat de connectivitat PDN) - connexió (activació PDN) o desconnexió (supressió PDN). Això pot ser utilitzat per l'AS per iniciar la comunicació amb l'UE, o viceversa, per entendre que la comunicació ja no és possible. Aquest tipus de monitorització està disponible per a dispositius IP i no IP.
Nombre d'UE presents en una àrea geogràfica – Aquest tipus de seguiment és utilitzat per l'AS per determinar el nombre d'UEs en una àrea geogràfica determinada.
Dispositiu d'activació)
A les xarxes 2G/3G, el procediment de registre a la xarxa era de dues etapes: primer, el dispositiu es va registrar amb el SGSN (procediment d'adjuntar), després, si calia, va activar el context PDP: una connexió amb la passarel·la de paquets (GGSN) per transmetre dades. A les xarxes 3G, aquests dos procediments es van produir de manera seqüencial, és a dir. el dispositiu no va esperar el moment en què necessitava transferir dades, sinó que va activar PDP immediatament després de completar el procediment d'adjuntar. A LTE, aquests dos procediments es van combinar en un, és a dir, en connectar-se, el dispositiu va sol·licitar immediatament l'activació de la connexió PDN (anàloga a PDP en 2G/3G) a través de l'eNodeB al MME-SGW-PGW.
NB-IoT defineix un mètode de connexió com "adjuntar sense PDN", és a dir, l'UE s'enllaça sense establir una connexió PDN. En aquest cas, no està disponible per transmetre trànsit i només pot rebre o enviar SMS. Per enviar una ordre a aquest dispositiu per activar PDN i connectar-se a AS, es va desenvolupar la funcionalitat "Dispositiu d'activació".
Quan rep una ordre per connectar aquest UE des de l'AS, SCEF inicia l'enviament d'un SMS de control al dispositiu a través del centre d'SMS. Quan rep un SMS, el dispositiu activa el PDN i es connecta a l'AS per rebre instruccions addicionals o transferir dades.
Hi pot haver moments en què la vostra subscripció al dispositiu caduqui a SCEF. Sí, la subscripció té la seva pròpia vida útil, establerta per l'operador o acordada amb AS. Un cop expirat, el PDN es desactivarà a l'MME i el dispositiu no estarà disponible per a l'AS. En aquest cas, la funcionalitat "Activació del dispositiu" també ajudarà. Quan rebi dades noves d'AS, SCEF esbrinarà l'estat de connexió del dispositiu i lliurarà les dades mitjançant el canal SMS.
Conclusió
La funcionalitat de SCEF, per descomptat, no es limita als serveis descrits anteriorment i està en constant evolució i expansió. Actualment, ja s'han normalitzat més d'una dotzena de serveis per a SCEF. Ara només hem tocat les funcions principals que demanen els desenvolupadors; de la resta en parlarem en propers articles.
De seguida sorgeix la pregunta: com aconseguir l'accés de prova a aquest node "miracle" per a proves preliminars i depuració de possibles casos? Tot és molt senzill. Qualsevol desenvolupador pot enviar una sol·licitud a [protegit per correu electrònic], en què n'hi ha prou amb indicar la finalitat de la connexió, una descripció d'un possible cas i informació de contacte per a la comunicació.
Us tornem a veure
Autors:
- expert sènior del departament de solucions convergents i serveis multimèdia Sergey Novikov ,
- expert del departament de solucions convergents i serveis multimèdia Alexey Lapshin
Font: www.habr.com