In articol "„, vorbind despre arhitectura nucleului de pachete al rețelei NB-IoT, am menționat apariția unui nou nod SCEF. Vă explicăm în partea a treia ce este și de ce este necesar?
Când creează un serviciu M2M, dezvoltatorii de aplicații se confruntă cu următoarele întrebări:
- modul de identificare a dispozitivelor;
- ce algoritm de verificare și autentificare să folosească;
- ce protocol de transport să alegeți pentru interacțiunea cu dispozitivele;
- cum să livrezi în mod fiabil date către dispozitive;
- modul de organizare și stabilire a regulilor de schimb de date cu aceștia;
- cum să monitorizezi și să obții online informații despre starea lor;
- cum să livrați simultan date către un grup de dispozitive;
- cum să trimiteți simultan date de pe un dispozitiv către mai mulți clienți;
- cum să obțineți acces unificat la servicii suplimentare ale operatorului pentru gestionarea dispozitivului dvs.
Pentru a le rezolva, este necesar să se creeze soluții proprietare „grele” din punct de vedere tehnic, ceea ce duce la creșterea costurilor cu forța de muncă și a serviciilor de livrare pe piață. Aici vine în ajutor noul nod SCEF.
După cum este definit de 3GPP, SCEF (funcția de expunere a capacității de serviciu) este o componentă complet nouă a arhitecturii 3GPP a cărei funcție este de a expune în siguranță serviciile și capabilitățile furnizate de interfețele de rețea 3GPP prin intermediul API-urilor.
Cu cuvinte simple, SCEF este un intermediar între rețea și serverul de aplicații (AS), o fereastră unică de acces la serviciile operatorului pentru gestionarea dispozitivului dvs. M2M în rețeaua NB-IoT printr-o interfață API intuitivă, standardizată.
SCEF ascunde complexitatea rețelei unui operator, permițând dezvoltatorilor de aplicații să abstragă mecanisme complexe, specifice dispozitivului, pentru a interacționa cu dispozitivele.
Prin transformarea protocoalelor de rețea într-un API familiar pentru dezvoltatorii de aplicații, API-ul SCEF facilitează crearea de noi servicii și reduce timpul de lansare pe piață. Noul nod include și funcții de identificare/autentificare a dispozitivelor mobile, definirea regulilor de schimb de date între dispozitiv și AS, eliminând necesitatea ca dezvoltatorii de aplicații să implementeze aceste funcții pe partea lor, deplasând aceste funcții pe umerii operatorului.
SCEF acoperă interfețele necesare pentru autentificarea și autorizarea serverelor de aplicații, menținerea mobilității UE, transferul de date și declanșarea dispozitivului, accesul la servicii suplimentare și capabilitățile rețelei operatorului.
Spre AS există o singură interfață T8, un API (HTTP/JSON) standardizat de 3GPP. Toate interfețele, cu excepția lui T8, funcționează pe baza protocolului DIAMETER (Fig. 1).
T6a – interfață între SCEF și MME. Folosit pentru procedurile de gestionare a mobilității/sesiunii, transmiterea de date non-IP, furnizarea de evenimente de monitorizare și primirea de rapoarte despre acestea.
S6t – interfață între SCEF și HSS. Necesar pentru autentificarea abonaților, autorizarea serverelor de aplicații, obținerea unei combinații de ID extern și IMSI/MSISDN, asigurarea monitorizării evenimentelor și primirea de rapoarte despre acestea.
S6m/T4 – interfețe de la SCEF la HSS și SMS-C (3GPP definește nodul MTC-IWF, care este utilizat pentru declanșarea dispozitivului și transmiterea SMS-urilor în rețelele NB-IoT. Cu toate acestea, în toate implementările funcționalitatea acestui nod este integrată în SCEF, deci pentru simplificarea circuitului, nu îl vom lua în considerare separat). Folosit pentru a obține informații de rutare pentru trimiterea de SMS-uri și interacțiunea cu centrul SMS.
T8 – Interfață API pentru interacțiunea SCEF cu serverele de aplicații. Atât comenzile de control, cât și traficul sunt transmise prin această interfață.
*în realitate există mai multe interfețe; doar cele mai elementare sunt enumerate aici. O listă completă este dată în 3GPP 23.682 (4.3.2 Lista punctelor de referință).
Mai jos sunt principalele funcții și servicii ale SCEF:
- conectarea identificatorului cartelei SIM (IMSI) la ID-ul extern;
- transmiterea traficului non-IP (Non-IP Data Delivery, NIDD);
- operațiuni de grup folosind ID-ul de grup extern;
- suport pentru modul de transmitere a datelor cu confirmare;
- tamponarea datelor MO (Mobile Originated) și MT (Mobile Terminated);
- autentificarea si autorizarea dispozitivelor si serverelor de aplicatii;
- utilizarea simultană a datelor de la un UE de către mai multe AS-uri;
- suport pentru funcții speciale de monitorizare a stării UE (MONTE – Monitoring Events);
- declanșarea dispozitivului;
- furnizarea de date în roaming non-IP.
Principiul de bază al interacțiunii dintre AS și SCEF se bazează pe așa-numita schemă. abonamente. Dacă este necesar să obțineți acces la orice serviciu SCEF pentru un anumit UE, serverul de aplicații trebuie să creeze un abonament trimițând o comandă către API-ul specific al serviciului solicitat și să primească un identificator unic ca răspuns. După care toate acțiunile și comunicările ulterioare cu UE în cadrul acestui serviciu vor avea loc folosind acest identificator.
ID extern: identificator universal de dispozitiv
Una dintre cele mai importante schimbări în schema de interacțiune între AS și dispozitive atunci când se lucrează prin SCEF este apariția unui identificator universal. Acum, în locul unui număr de telefon (MSISDN) sau a unei adrese IP, așa cum era cazul în rețeaua clasică 2G/3G/LTE, identificatorul dispozitivului pentru serverul de aplicații devine „ID extern”. Este definit de standard într-un format familiar dezvoltatorilor de aplicații „ @ "
Dezvoltatorii nu mai trebuie să implementeze algoritmi de autentificare a dispozitivului; rețeaua preia complet această funcție. ID-ul extern este legat de IMSI, iar dezvoltatorul poate fi sigur că atunci când accesează un anumit ID extern, acesta interacționează cu o anumită cartelă SIM. Când utilizați un cip SIM, obțineți o situație complet unică când ID-ul extern identifică în mod unic un anumit dispozitiv!
Mai mult, mai multe ID-uri externe pot fi legate la un IMSI - o situație și mai interesantă apare atunci când ID-ul extern identifică în mod unic o aplicație specifică responsabilă pentru un anumit serviciu pe un anumit dispozitiv.
Apare și un identificator de grup - ID de grup extern, care include un set de ID-uri externe individuale. Acum, cu o singură solicitare către SCEF, AS poate iniția operațiuni de grup - trimiterea de date sau comenzi de control către mai multe dispozitive unite într-un singur grup logic.
Datorită faptului că pentru dezvoltatorii AS trecerea la un nou identificator de dispozitiv nu poate fi instantanee, SCEF a lăsat posibilitatea comunicării AS cu UE printr-un număr standard - MSISDN.
Transmiterea traficului non-IP (Non-IP Data Delivery, NIDD)
În NB-IoT, ca parte a optimizării mecanismelor de transmitere a unor cantități mici de date, pe lângă tipurile PDN deja existente, precum IPv4, IPv6 și IPv4v6, a apărut un alt tip - non-IP. În acest caz, dispozitivului (UE) nu i se atribuie o adresă IP și datele sunt transmise fără utilizarea protocolului IP. Traficul pentru astfel de conexiuni poate fi direcționat în două moduri: clasic - MME -> SGW -> PGW și apoi prin tunelul PtP către AS (Fig. 2) sau folosind SCEF (Fig. 3).
Metoda clasică nu oferă avantaje deosebite față de traficul IP, cu excepția reducerii dimensiunii pachetelor transmise din cauza absenței antetelor IP. Utilizarea SCEF deschide o serie de noi posibilități și simplifică semnificativ procedurile de interacțiune cu dispozitivele.
La transmiterea datelor prin SCEF apar două avantaje foarte importante față de traficul IP clasic:
Livrarea traficului MT către dispozitiv prin ID extern
Pentru a trimite un mesaj către un dispozitiv IP clasic, AS-ul trebuie să-și cunoască adresa IP. Aici apare o problemă: deoarece dispozitivul primește de obicei o adresă IP „gri” la înregistrare, acesta comunică cu serverul de aplicații, care se află pe Internet, printr-un nod NAT, unde adresa gri este tradusă în alb. Combinația de adrese IP gri și alb durează un timp limitat, în funcție de setările NAT. În medie, pentru TCP sau UDP - nu mai mult de cinci minute. Adică dacă nu există schimb de date cu acest dispozitiv în decurs de 5 minute, conexiunea se va dezintegra și dispozitivul nu va mai fi accesibil la adresa albă cu care a fost inițiată sesiunea cu AS. Există mai multe soluții:
1. Folosiți bătăile inimii. Odată ce o conexiune a fost stabilită, dispozitivul trebuie să facă schimb de pachete cu AS la fiecare câteva minute, împiedicând astfel închiderea traducerilor NAT. Dar aici nu se poate vorbi de eficiență energetică.
2. De fiecare dată, dacă este necesar, verificați disponibilitatea pachetelor pentru dispozitiv pe AS - trimiteți un mesaj către uplink.
3. Creați un APN privat (VRF), unde serverul de aplicații și dispozitivele vor fi pe aceeași subrețea și atribuiți adrese IP statice dispozitivelor. Va funcționa, dar este aproape imposibil când vorbim de o flotă de mii, zeci de mii de dispozitive.
4. În sfârșit, cea mai potrivită opțiune: folosiți IPv6, nu necesită NAT, deoarece adresele IPv6 sunt direct accesibile de pe Internet. Totuși, chiar și în acest caz, atunci când dispozitivul este reînregistrat, acesta va primi o nouă adresă IPv6 și nu va mai fi accesibil folosind cea anterioară.
În consecință, este necesar să trimiteți un pachet de inițializare cu un identificator de dispozitiv către server pentru a raporta noua adresă IP a dispozitivului. Apoi așteptați un pachet de confirmare de la AS, care afectează și eficiența energetică.
Aceste metode funcționează bine pentru dispozitivele 2G/3G/LTE, unde dispozitivul nu are cerințe stricte de autonomie și, ca urmare, nu există restricții privind timpul de difuzare și trafic. Aceste metode nu sunt potrivite pentru NB-IoT din cauza consumului lor ridicat de energie.
SCEF rezolvă această problemă: deoarece singurul identificator de dispozitiv pentru un AS este un ID extern, AS-ul trebuie să trimită doar un pachet de date către SCEF pentru un anumit ID extern, iar SCEF se ocupă de restul. În cazul în care dispozitivul este în modul de economisire a energiei PSM sau eDRX, datele vor fi stocate și livrate atunci când dispozitivul devine disponibil. Dacă dispozitivul este disponibil pentru trafic, datele vor fi livrate imediat. Același lucru este valabil și pentru echipele de conducere.
În orice moment, AS poate reapela mesajul tamponat către UE sau îl poate înlocui cu unul nou.
Mecanismul de tamponare poate fi utilizat și la transmiterea datelor MO de la UE către AS. Dacă SCEF nu a reușit să livreze date către AS imediat, de exemplu dacă lucrările de întreținere sunt în desfășurare pe serverele AS, aceste pachete vor fi stocate în tampon și se vor garanta că vor fi livrate de îndată ce AS-ul devine disponibil.
După cum sa menționat mai sus, accesul la un anumit serviciu și UE pentru un AS (și NIDD este un serviciu) este reglementat de reguli și politici din partea SCEF, ceea ce permite posibilitatea unică de utilizare simultană a datelor dintr-un UE de către mai multe AS-uri. Acestea. dacă mai multe AS s-au abonat la un UE, atunci după primirea datelor de la UE, SCEF le va trimite către toate AS abonate. Acest lucru este potrivit pentru cazurile în care creatorul unei flote de dispozitive specializate partajează date între mai mulți clienți. De exemplu, prin crearea unei rețele de stații meteo care rulează pe NB-IoT, puteți vinde date de la acestea către mai multe servicii simultan.
Mecanism de livrare a mesajelor garantat
Reliable Data Service este un mecanism pentru livrarea garantată a mesajelor MO și MT fără utilizarea de algoritmi specializați la nivel de protocol, cum ar fi, de exemplu, handshake în TCP. Funcționează prin includerea unui steag special în partea de serviciu a mesajului atunci când este schimbat între UE și SCEF. Dacă se activează sau nu acest mecanism la transmiterea traficului este decis de AS.
Dacă mecanismul este activat, UE include un flag special în partea superioară a pachetului atunci când necesită livrarea garantată a traficului MO. La primirea unui astfel de pachet, SCEF răspunde UE cu o confirmare. Dacă UE nu primește pachetul de confirmare, pachetul către SCEF va fi retrimis. Același lucru se întâmplă și cu traficul MT.
Monitorizarea dispozitivului (monitorizarea evenimentelor - MONTE)
După cum sa menționat mai sus, funcționalitatea SCEF, printre altele, include funcții de monitorizare a stării UE, așa-numitele. monitorizarea dispozitivului. Și dacă noi identificatori și mecanisme de transfer de date sunt optimizări (deși foarte serioase) ale procedurilor existente, atunci MONTE este o funcționalitate complet nouă care nu este disponibilă în rețelele 2G/3G/LTE. MONTE permite AS să monitorizeze parametrii dispozitivului, cum ar fi starea conexiunii, disponibilitatea comunicațiilor, locația, starea roamingului etc. Vom vorbi despre fiecare în detaliu puțin mai târziu.
Dacă este necesară activarea oricărui eveniment de monitorizare pentru un dispozitiv sau un grup de dispozitive, AS se abonează la serviciul corespunzător trimițând comanda API MONTE corespunzătoare către SCEF, care include parametri precum ID extern sau ID de grup extern, identificator AS, monitorizare. tipul, numărul de rapoarte pe care AS dorește să le primească. Dacă AS este autorizat să execute cererea, SCEF, în funcție de tip, va furniza evenimentul către HSS sau MME (Fig. 4). Când are loc un eveniment, MME sau HSS generează un raport către SCEF, care îl trimite AS.
Furnizarea tuturor evenimentelor, cu excepția „Număr de UE-uri prezente într-o zonă geografică”, are loc prin HSS. Două evenimente „Schimbarea Asociației IMSI-IMEI” și „Starea Roaming” sunt urmărite direct pe HSS, restul vor fi furnizate de HSS pe MME.
Evenimentele pot fi fie o singură dată, fie periodice și sunt determinate de tipul lor.
Trimiterea unui raport despre un eveniment (raportare) este efectuată de nodul care urmărește evenimentul direct către SCEF (Fig. 5).
Punct important: Evenimentele de monitorizare pot fi aplicate atât dispozitivelor non-IP conectate prin SCEF, cât și dispozitivelor IP care transmit date în mod clasic prin MME-SGW-PGW.
Să aruncăm o privire mai atentă la fiecare dintre evenimentele de monitorizare:
Pierderea conectivității — informează AS că UE nu mai este disponibil nici pentru trafic de date, nici pentru semnalizare. Evenimentul are loc când „temporizatorul de accesibilitate mobil” pentru UE expiră pe MME. Într-o solicitare pentru acest tip de monitorizare, AS-ul poate indica valoarea „Maximum Detection Time” - dacă în acest timp UE-ul nu prezintă nicio activitate, AS va fi informat că UE-ul este indisponibil, indicând motivul. Evenimentul are loc și dacă UE a fost îndepărtat forțat de rețea din orice motiv.
* Pentru a anunța rețeaua că dispozitivul este încă disponibil, aceasta inițiază periodic o procedură de actualizare - Actualizarea zonei de urmărire (TAU). Frecvența acestei proceduri este setată de rețea folosind temporizatorul T3412 sau (T3412_extended în cazul PSM), a cărui valoare este transmisă dispozitivului în timpul procedurii Attach sau al următoarei TAU. Temporizatorul de accesibilitate mobil este de obicei cu câteva minute mai lung decât T3412. În cazul în care UE nu a făcut un TAU înainte de expirarea „Cronometrului de accesibilitate mobil”, rețeaua consideră că acesta nu mai este accesibil.
Accesibilitate UE – Indică când UE devine disponibilă pentru trafic DL sau SMS. Acest lucru are loc atunci când UE devine disponibil pentru paginare (pentru un UE în modul eDRX) sau când UE intră în modul ECM-CONNECTED (pentru un UE în modul PSM sau eDRX), adică face un TAU sau trimite un pachet uplink.
Raportarea locației – Acest tip de evenimente de monitorizare permite AS să interogheze locația UE. Pot fi solicitate fie locația curentă (Locația curentă), fie ultima locație cunoscută (determinată de ID-ul celulei de la care dispozitivul a făcut TAU sau a transmis trafic ultima dată), ceea ce este relevant pentru dispozitivele în modurile de economisire a energiei PSM sau eDRX. Pentru „Locația curentă”, AS poate solicita răspunsuri repetate, MME informând AS de fiecare dată când locația dispozitivului se schimbă.
Schimbarea Asociației IMSI-IMEI – Când acest eveniment este activat, SCEF începe să monitorizeze modificările în combinația dintre IMSI (identificatorul cartelei SIM) și IMEI (identificatorul dispozitivului). Când are loc un eveniment, informează AS. Poate fi folosit pentru a relega automat un ID extern la un dispozitiv în timpul lucrărilor de înlocuire programată sau pentru a servi drept identificator pentru furtul unui dispozitiv.
Stare de roaming – acest tip de monitorizare este utilizat de AS pentru a determina dacă UE se află în rețeaua de domiciliu sau în rețeaua unui partener de roaming. Opțional, se poate transmite PLMN (Public Land Mobile Network) al operatorului în care este înregistrat dispozitivul.
Eroare de comunicare — Acest tip de monitorizare informează AS cu privire la defecțiunile în comunicarea cu dispozitivul, pe baza motivelor pierderii conexiunii (release cause code) primite de la rețeaua de acces radio (protocol S1-AP). Acest eveniment poate ajuta la determinarea motivului pentru care comunicarea a eșuat - din cauza problemelor din rețea, de exemplu, când eNodeb-ul este supraîncărcat (resurse radio nu sunt disponibile) sau din cauza unei defecțiuni a dispozitivului în sine (Conexiune radio cu UE pierdută).
Disponibilitate după eșecul DDN – acest eveniment informează AS că dispozitivul a devenit disponibil după o eroare de comunicare. Poate fi folosit atunci când este nevoie de transfer de date pe un dispozitiv, dar încercarea anterioară nu a reușit deoarece UE nu a răspuns la o notificare din rețea (paging) și datele nu au fost livrate. Dacă acest tip de monitorizare a fost solicitat pentru UE, atunci de îndată ce dispozitivul face o comunicare de intrare, face un TAU sau trimite date către uplink, AS va fi informat că dispozitivul a devenit disponibil. Deoarece procedura DDN (downlink data notification) funcționează între MME și S/P-GW, acest tip de monitorizare este disponibil numai pentru dispozitivele IP.
Stare conectivitate PDN – informează AS când se schimbă starea dispozitivului (starea conectivitate PDN) - conectare (activare PDN) sau deconectare (ștergere PDN). Acesta poate fi folosit de AS pentru a iniția comunicarea cu UE, sau invers, pentru a înțelege că comunicarea nu mai este posibilă. Acest tip de monitorizare este disponibil pentru dispozitive IP și non-IP.
Numărul de UE-uri prezente într-o zonă geografică – Acest tip de monitorizare este utilizat de AS pentru a determina numărul de UE într-o anumită zonă geografică.
Declanșarea dispozitivului)
În rețelele 2G/3G, procedura de înregistrare în rețea a fost în două etape: mai întâi, dispozitivul s-a înregistrat cu SGSN (procedura de atașare), apoi, dacă este necesar, a activat contextul PDP - o conexiune cu gateway-ul de pachete (GGSN) pentru a transmite date. În rețelele 3G, aceste două proceduri au avut loc secvenţial, adică. dispozitivul nu a așteptat momentul în care trebuia să transfere date, ci a activat PDP imediat după finalizarea procedurii de atașare. În LTE, aceste două proceduri au fost combinate într-una singură, adică la atașare, dispozitivul a solicitat imediat activarea conexiunii PDN (analog cu PDP în 2G/3G) prin intermediul eNodeB la MME-SGW-PGW.
NB-IoT definește o metodă de conectare ca „atașare fără PDN”, adică UE se atașează fără a stabili o conexiune PDN. În acest caz, nu este disponibil pentru a transmite trafic și poate doar primi sau trimite SMS-uri. Pentru a trimite o comandă unui astfel de dispozitiv pentru a activa PDN și a se conecta la AS, a fost dezvoltată funcționalitatea „Declanșare dispozitiv”.
Când primește o comandă de conectare a unui astfel de UE de la AS, SCEF inițiază trimiterea unui SMS de control către dispozitiv prin centrul SMS. La primirea unui SMS, dispozitivul activează PDN-ul și se conectează la AS pentru a primi instrucțiuni suplimentare sau a transfera date.
Pot exista momente când abonamentul dvs. pentru dispozitiv expiră pe SCEF. Da, abonamentul are o durată de viață proprie, stabilită de operator sau convenită cu AS. La expirare, PDN-ul va fi dezactivat pe MME și dispozitivul va deveni indisponibil pentru AS. În acest caz, funcționalitatea „Declanșarea dispozitivului” va ajuta, de asemenea. Când primește date noi de la AS, SCEF va afla starea conexiunii dispozitivului și va livra datele prin canalul SMS.
Concluzie
Funcționalitatea SCEF, desigur, nu se limitează la serviciile descrise mai sus și evoluează și se extinde constant. În prezent, mai mult de o duzină de servicii au fost deja standardizate pentru SCEF. Acum am atins doar principalele funcții care sunt solicitate de la dezvoltatori; despre restul vom vorbi în articolele viitoare.
Apare imediat întrebarea: cum să obțineți accesul de testare la acest nod „miracol” pentru testarea preliminară și depanarea posibilelor cazuri? Totul este foarte simplu. Orice dezvoltator poate trimite o solicitare către [e-mail protejat], în care este suficient să se indice scopul conexiunii, o descriere a unui posibil caz și informații de contact pentru comunicare.
Până data viitoare!
Autori:
- expert senior al departamentului de soluții convergente și servicii multimedia Serghei Novikov ,
- expert al departamentului de soluții convergente și servicii multimedia Alexey Lapshin
Sursa: www.habr.com