NB-IoT: cum funcționează? Partea 3: SCEF – fereastra unică pentru accesarea serviciilor operatorului

În articolul „NB-IoT: Cum funcționează? Partea 2”, discutând despre arhitectura nucleului de pachet al rețelei NB-IoT, am menționat apariția unui nou nod SCEF. Explicăm în a treia parte ce este acesta și de ce este necesar.

În crearea unui serviciu M2M, dezvoltatorii de aplicații se confruntă cu următoarele întrebări:

• cum să identifice dispozitivele;
• ce algoritm să folosească pentru verificarea și confirmarea autenticității;
• ce protocol de transport să aleagă pentru interacțiunea cu dispozitivele;
• cum să garanteze livrarea datelor către dispozitive;
• cum să organizeze și să stabilească reguli pentru schimbul de date cu acestea;
• cum să controleze și să obțină informații în timp real despre starea acestora;
• cum să livreze simultan date unei grupări de dispozitive proprii;
• cum să trimită simultan date de la un dispozitiv la mai mulți clienți;
• cum să obțină un acces unificat la serviciile suplimentare ale operatorului pentru gestionarea dispozitivului propriu.

Pentru a le soluționa, este necesar să se creeze soluții tehnice proprietare „grele”, ceea ce duce la creșterea efortului și a timpului de realizare a serviciilor. Aici intervine noul nod SCEF.

Conform definiției 3GPP, SCEF (funcția de expunere a capacității serviciului) este un component complet nou al arhitecturii 3GPP, al cărui scop este expunerea în siguranță a serviciilor și capabilităților oferite de interfețele de rețea 3GPP prin intermediul API-ului.

În termeni simpli, SCEF este un intermediar între rețea și serverul de aplicații (application server – AS), o fereastră unică de acces la serviciile operatorului pentru gestionarea dispozitivului M2M în rețeaua NB-IoT printr-un API standardizat intuitiv.

SCEF ascunde complexitatea rețelei operatorului, permițând dezvoltatorilor de aplicații să se abstreacă de mecanismele complicate și specifice de interacțiune cu dispozitivele.

Prin transformarea protocoalelor de rețea într-un API accesibil dezvoltatorilor de aplicații, SCEF facilitează crearea de noi servicii și reduce timpul de lansare pe piață. De asemenea, noul nod include funcții de identificare/autentificare a dispozitivelor mobile și de stabilire a regulilor de schimb de date între dispozitiv și AS, scutind dezvoltatorii de implementarea acestor funcții de partea lor, transferând această responsabilitate operatorului.

SCEF aglomerează interfețele necesare pentru autentificarea și autorizarea serverelor de aplicații, menținerea mobilității UE, transferul de date și declanșarea dispozitivelor, precum și accesul la servicii și funcționalități suplimentare ale rețelei operatorului.

Către AS există o singură interfață T8, interfață API (HTTP/JSON) standardizată de 3GPP. Toate interfețele, cu excepția T8, funcționează pe baza protocoalelor DIAMETER (fig. 1).

T6a – interfața între SCEF și MME. Este utilizată pentru procedurile de gestionare a mobilității/sesiunii, transferul de date non-IP, provizionarea evenimentelor de monitorizare și obținerea raporturilor pentru acestea.

S6t – interfața între SCEF și HSS. Necesită autentificarea abonatului, autorizarea serverelor de aplicații, obținerea asocierii ID extern și IMSI/MSISDN, provizionarea evenimentelor de monitorizare și obținerea raporturilor pentru acestea.

S6m/T4 – interfețele de la SCEF la HSS și SMS-C (în 3GPP este definit un nod MTC-IWF, care este utilizat pentru declanșarea dispozitivelor și transferul de SMS în rețelele NB-IoT. Cu toate acestea, în toate implementările, funcționalitatea acestui nod este integrată în SCEF, astfel încât pentru simplificarea schemei, nu-l vom considera separat). Sunt utilizate pentru obținerea informațiilor de rutare pentru trimiterea SMS-urilor și interacțiunea cu centrul SMS.

T8 – interfața API de interacțiune a SCEF cu serverele de aplicații. Prin această interfață sunt transmise atât comenzi de control, cât și trafic.

*de fapt, există mai multe interfețe, acestea fiind enumerate doar pe cele mai fundamentale. Lista completă este prezentată în 3GPP 23.682 (4.3.2 Lista Punctelor de Referință).

Mai jos sunt prezentate funcțiile și serviciile cheie ale SCEF:

• legarea identității SIM (IMSI) la ID extern;
• transferul de trafic non-IP (Non-IP Data Delivery, NIDD);
• operațiuni de grup, utilizând ID-ul grupului extern;
• suport pentru modul de transfer de date cu confirmare;
• bufferizarea datelor MO (Mobile Originated) și MT (Mobile Terminated);
• autentificarea și autorizarea dispozitivelor și serverelor de aplicații;
• utilizarea simultană a datelor unui UE de către mai multe AS;
• suport pentru funcții speciale de monitorizare a stării UE (MONTE – Evenimente de Monitorizare);
• triggering-ul dispozitivelor;
• asigurarea roaming-ului datelor non-IP.

Principiul fundamental de interacțiune între AS și SCEF se bazează pe schema așa-numitelor abonamente. Atunci când este necesară accesarea unui anumit serviciu SCEF pentru un UE specific, serverul aplicației trebuie să creeze un abonament prin trimiterea unei comenzi către API-ul specific al serviciului solicitat și, ca răspuns, să obțină un identificator unic. După aceasta, toate acțiunile și comunicațiile ulterioare cu UE în cadrul acestui serviciu vor avea loc folosind acest identificator.

ID extern: identificatorul universal al dispozitivului

Una dintre cele mai importante schimbări în schema de interacțiune AS cu dispozitivele atunci când se lucrează prin SCEF este apariția identificatorului universal. Acum, în loc de numărul de telefon (MSISDN) sau adresa IP, așa cum era în rețelele clasice 2G/3G/LTE, identificatorul dispozitivului pentru serverul aplicației devine „ID extern”. Acesta este definit de standard într-un format familiar pentru dezvoltatorii de aplicații „@”.

Dezvoltatorii nu mai trebuie să implementeze algoritmi de autentificare a dispozitivelor, rețeaua își asumă complet această funcție. ID-ul extern se leagă de IMSI, iar dezvoltatorul poate fi sigur că, adresându-se unui anumit ID extern, interacționează cu un anumit card SIM. Când se folosește un cip SIM, se creează o situație cu adevărat unică, când ID-ul extern identifică fără echivoc un anumit dispozitiv!

Mai mult, la un IMSI pot fi legate mai multe ID-uri externe — rezultând o situație și mai interesantă, când ID-ul extern identifică fără echivoc o anumită aplicație responsabilă pentru un serviciu specific pe un anumit dispozitiv.

De asemenea, apare un identificator de grup — ID extern de grup, care include un set de ID-uri externe separate. 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.

Din cauza faptului că pentru dezvoltatori trecerea la un nou identificator de dispozitiv nu poate fi instantanee, SCEF a lăsat posibilitatea comunicării AS cu UE prin numărul standard – MSISDN.

Livrarea de date non-IP (Non-IP Data Delivery, NIDD)

În NB-IoT, în cadrul optimizării mecanismelor de transmitere a unor volume mici de date, pe lângă tipurile de PDN deja existente, cum ar fi IPv4, IPv6 și IPv4v6, a apărut un nou tip - non-IP. În acest caz, dispozitivului (UE) nu i se alocă o adresă IP, iar datele sunt transmise fără utilizarea protocolului IP. Traficul pentru astfel de conexiuni poate fi rutat în două moduri: clasic - MME -> SGW -> PGW și mai departe printr-un tunel PtP către AS (fig. 2) sau folosind SCEF (fig. 3).

Metoda clasică nu aduce avantaje semnificative față de traficul IP, cu excepția reducerii dimensiunii pachetelor transmise datorită absenței antetelor IP. Folosirea SCEF deschide însă o serie de noi oportunități și simplifică semnificativ procedurile de interacțiune cu dispozitivele.

În transmisia de date 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 trebuie să cunoască adresa sa IP. Aici apare problema: deoarece dispozitivul, la înregistrare, primește de obicei o adresă IP „gri”, cu serverul de aplicații, care se află în internet, comunică printr-un nod NAT, unde se face traducerea adresei gri în alb. Legătura dintre adresele gri și alb se menține un timp limitat, în funcție de setările NAT. În medie, pentru TCP sau UDP — nu mai mult de cinci minute. Astfel, dacă în decurs de 5 minute nu a avut loc nicio schimbare de date cu acest dispozitiv, legătura se va desface, iar dispozitivul va înceta să fie accesibil prin acea adresă albă cu care a fost inițiată sesiunea cu AS. Există câteva soluții:

1. Utilizarea heartbeat-ului. Odată stabilită conexiunea, dispozitivul trebuie să schimbe pachete cu AS la fiecare câteva minute, astfel încât traducerea NAT să nu se închidă. Dar aici nu poate fi vorba despre vreo eficiență energetică.

2. De fiecare dată când este necesar, pentru a verifica disponibilitatea pachetelor pentru dispozitiv pe AS — trimiteți un mesaj în uplink.

3. Crearea unui APN privat (VRF), unde serverul de aplicații și dispozitivele vor fi în aceeași subrețea și alocarea de adrese IP statice dispozitivelor. Acest lucru va funcționa, dar este aproape imposibil de realizat când este vorba despre un parc de mii sau zeci de mii de dispozitive.

4. În cele din urmă, cea mai potrivită opțiune: utilizarea IPv6, deoarece nu este necesar NAT, deoarece adresele IPv6 sunt accesibile direct din internet. Cu toate acestea, chiar și în acest caz, atunci când dispozitivul este regimistrat, acesta va primi o nouă adresă IPv6 și nu va mai fi accesibil prin adresa anterioară.

Prin urmare, este necesar să se trimită un pachet de inițializare cu identificatorul dispozitivului către server, pentru a comunica noua adresă IP a dispozitivului. Apoi, așteptați un pachet de confirmare de la AS, ceea ce influențează, de asemenea, eficiența energetică.

Aceste metode funcționează bine pentru dispozitive 2G/3G/LTE, unde nu există cerințe stricte privind autonomia dispozitivului și, prin urmare, nu există restricții în ceea ce privește timpul de activitate și traficul. Pentru NB-IoT, aceste metode nu sunt adecvate din cauza consumului lor mare de energie.

SCEF rezolvă această problemă: deoarece singurul identificator al dispozitivului pentru AS este ID-ul extern, AS trebuie doar să trimită un pachet de date la SCEF pentru ID-ul extern specific, iar SCEF se va ocupa de restul. În cazul în care dispozitivul se află în modul de economisire a energiei PSM sau eDRX, datele vor fi bufferizate ș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 comenzile de control.

În orice moment, AS poate retrage mesajul bufferizat către UE sau să-l înlocuiască cu unul nou.

Mecanismul de bufferizare poate fi aplicat și în cazul transmiterii datelor MO de la UE către AS. Dacă SCEF nu a reușit să livreze datele către AS imediat, de exemplu, dacă se desfășoară lucrări de întreținere pe serverele AS, aceste pachete vor fi bufferizate și garantat livrate de îndată ce AS devine disponibil.

După cum s-a menționat anterior, accesul la un anumit serviciu și UE pentru AS (iar NIDD este un serviciu) este reglementat de reguli și politici pe partea SCEF, ceea ce permite realizarea unei oportunități unice de utilizare simultană a datelor unui singur UE de către mai multe AS. Adică, dacă mai multe AS s-au abonat la un UE, atunci, după primirea datelor de la UE, SCEF le va distribui tuturor AS-urilor abonate. Acest lucru este foarte potrivit pentru cazuri în care creatorul unui parc de dispozitive specializate împărtășește datele între mai mulți clienți. De exemplu, creând o rețea de stații meteorologice care funcționează pe NB-IoT, datele de la acestea pot fi vândute mai multor servicii simultan.

Mecanismul livrării garantate a mesajelor

Serviciul de date fiabile — mecanismul livrării garantate a mesajelor MO și MT fără utilizarea algoritmilor specializați la nivel de protocol, cum ar fi handshake-ul în TCP. Funcționează prin activarea unei flori speciale în partea de control a mesajului în timpul schimbului între UE și SCEF. Activarea sau dezactivarea acestui mecanism în timpul transferului de trafic este decizia AS.

Dacă mecanismul este activat, UE, în cazul livrării garantate a traficului MO, include o floare specială în partea de control a pachetului. La primirea unui astfel de pachet, SCEF răspunde UE cu o confirmare. Dacă UE nu a primit pachetul cu confirmarea, pachetul către SCEF va fi retransmis. Același lucru se întâmplă și pentru traficul MT.

Monitorizarea dispozitivelor (event monitoring - MONTE)

După cum s-a menționat anterior, funcționalitatea SCEF, pe lângă altele, include funcții de control al stării UE, numite monitorizarea dispozitivelor. Și dacă noile identificatori și mecanismele de transfer de date sunt optimizări (deși foarte semnificative) ale procedurilor existente, MONTE este o funcționalitate complet nouă, inaccesibilă în rețelele 2G/3G/LTE. MONTE permite AS-ului să monitorizeze parametrii dispozitivului, cum ar fi statutul conexiunii, disponibilitatea pentru comunicație, locația, statutul de roaming etc. Vom detalia fiecare aspect puțin mai târziu.

Când este necesar să activeze un eveniment de monitorizare pentru un dispozitiv sau un grup de dispozitive, AS se abonează la serviciul corespunzător prin trimiterea unei comenzi API MONTE către SCEF, care include parametrii, cum ar fi external Id sau external group ID, identificatorul AS, tipul de monitorizare, numărul de rapoarte pe care AS dorește să le primească. Dacă AS este autorizat să efectueze cererea, SCEF, în funcție de tip, provizionază evenimentul pe HSS sau MME (fig. 4). La apariția evenimentului, MME sau HSS generează un raport pentru SCEF, care îl trimite către AS.

Provizionarea tuturor evenimentelor, cu excepția „Număr de UEs prezent în o zonă geografică”, se face prin HSS. Două evenimente, „Schimbarea asocierii IMSI-IMEI” și „Statutul de roaming” — sunt monitorizate direct pe HSS, celelalte fiind provizionate de HSS pe MME.
Evenimentele pot fi atât unice, cât și periodice, și sunt conditionate de tipul lor.

Trimiterea raportului de eveniment (reporting) se realizează de către nodul care monitorizează evenimentul, direct pe SCEF (fig. 5).

Un aspect important: evenimentele de monitorizare pot fi aplicabile atât dispozitivelor non-IP conectate prin intermediul SCEF, cât și dispozitivelor IP care transmit date prin metode clasice prin MME-SGW-PGW.

Să analizăm mai în detaliu fiecare dintre evenimentele de monitorizare:

Pierderea conectivității — informează AS că UE nu mai este disponibilă atât pentru traficul de date cât și pentru schimburile de semnale. Evenimentul are loc atunci când timerul de accesibilitate mobilă pentru UE expire la MME. În cererea pentru acest tip de monitorizare, AS poate specifica valoarea sa pentru „Timpul Maxim de Detectare” — dacă, în această perioadă, UE nu manifestă nicio activitate, AS va fi informat că UE nu este disponibilă, cu indicarea motivului. De asemenea, evenimentul are loc dacă UE a fost eliminată din rețea forțat dintr-un anumit motiv.

* Pentru ca rețeaua să știe că dispozitivul este în continuare disponibil, acesta inițiază periodic procedura de actualizare — Tracking Area Update (TAU). Frecvența acestei proceduri este determinată de rețea prin timerul T3412 sau (T3412_extended în cazul PSM), valoarea căruia este transmisă dispozitivului în timpul procedurii Attach sau a TAU-ului următor. Timerul de accesibilitate mobilă este de obicei cu câteva minute mai lung decât T3412. Dacă UE nu efectuează TAU până la expirarea „Timer-ului de Accesibilitate Mobilă”, rețeaua o consideră ca fiind mai puțin disponibilă.

Accesibilitatea UE – Arată când UE devine disponibilă pentru traficul DL sau SMS. Acest lucru se întâmplă când UE devine disponibilă pentru paging (pentru UE în modul eDRX) sau când UE trece în modul ECM-CONNECTED (pentru UE în modul PSM sau eDRX), adică efectuează TAU sau trimite un pachet de uplink.

Raportarea locației – Acest tip de eveniment de monitorizare permite AS să solicite date despre locația UE. Poate fi solicitată fie locația curentă (Current Location), fie ultima locație cunoscută (Last Known Location, definită pe baza ID-ului celulei din care dispozitivul a făcut TAU sau a transmis trafic ultima dată), ceea ce este relevant pentru dispozitivele aflate în moduri de economisire a energiei PSM sau eDRX. Pentru „Current Location”, AS poate solicita rapoarte repetate, iar MME va informa AS de fiecare dată când se schimbă locația dispozitivului.

Schimbarea asocierii IMSI-IMEI – Activarea acestui eveniment determină ca SCEF să înceapă să monitorizeze modificarea legăturii IMSI (identificatorul cartelei SIM) și IMEI (identificatorul dispozitivului). La apariția evenimentului, informează AS. Poate fi utilizat pentru reasocierea automată a ID-ului extern la dispozitiv în timpul lucrărilor de întreținere sau poate servi drept identificator pentru furtul dispozitivului.

Starea Roaming – acest tip de monitorizare este utilizat de AS pentru a determina dacă UE se află în rețeaua sa de origine sau în rețeaua unui partener de roaming. Opțional, poate fi transmis PLMN (Public Land Mobile Network) al operatorului în care dispozitivul este înregistrat.

Eșec de comunicație – Acest tip de monitorizare informează AS despre eșecurile în comunicarea cu dispozitivul, pe baza motivelor întreruperii conexiunii (release cause code) primite de la rețeaua de acces radio (protocolul S1-AP). Acest eveniment poate ajuta la determinarea motivului eșecului comunicației — fie din cauza problemelor de rețea, de exemplu, în caz de supraîncărcare a eNodeb (Resurse radio indisponibile) sau din cauza unei defectări a dispozitivului (Conexiune radio pierdută cu UE).

Disponibilitate după eșec DDN – acest eveniment informează AS că dispozitivul a devenit disponibil după un eșec de comunicație. Poate fi folosit atunci când este necesar să se transmită date către dispozitiv, dar încercarea anterioară a fost nereușită deoarece UE nu a răspuns la notificarea din rețea (paging), iar datele nu au fost livrate. Dacă acest tip de monitorizare a fost solicitat pentru UE, de îndată ce dispozitivul va iniția o comunicație în intrare, va efectua un TAU sau va trimite date în 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 dispozitive IP.

Starea conectivității PDN – informează AS cu privire la schimbarea stării dispozitivului (starea conectivității PDN) — conectare (activare PDN) sau deconectare (eliminare PDN). Acesta poate fi utilizat de AS pentru a iniția comunicația cu UE sau, dimpotrivă, pentru a înțelege că comunicația nu mai este posibilă. Acest tip de monitorizare este disponibil pentru dispozitive IP și non-IP.

Numărul de UE prezente într-o zonă geografică – acest tip de monitorizare este utilizat de AS pentru a determina numărul de UE într-o zonă geografică specifică.

Declanșarea dispozitivelor (Device triggering)

În rețelele 2G/3G, procedura de înregistrare în rețea era bipartită: mai întâi, dispozitivul se înregistra în SGSN (procedura attach), apoi, dacă era necesar să transmită date, activa contextul PDP – conexiunea cu gateway-ul de pachete (GGSN). În rețelele 3G, aceste două proceduri se desfășurau în ordine consecutivă, adică dispozitivul nu aștepta momentul în care să transmită date, ci activa PDP imediat după finalizarea procedurii attach. În LTE, aceste două proceduri au fost combinate într-una, adică, la attach, dispozitivul solicita imediat activarea conexiunii PDN (analog PDP în 2G/3G) prin eNodeB către MME-SGW-PGW.

În NB-IoT, a fost definit un mod de conectare numit „attach without PDN”, adică UE face attach fără să stabilească o conexiune PDN. În acest caz, nu este disponibil pentru transmiterea de trafic și poate doar să primească sau să trimită SMS-uri. Pentru a transmite unui astfel de dispozitiv un comandă pentru activarea PDN și conectare la AS, a fost dezvoltată funcționalitatea „Device triggering”.

La primirea comenzii de conectare a unui astfel de UE de la AS, SCEF, prin centrul SMS, inițiază trimiterea unui SMS de control către dispozitiv. La primirea SMS-ului, dispozitivul activează PDN și se conectează la AS pentru a primi instrucțiuni ulterioare sau pentru a transmite date.

Există cazuri în care abonamentul SCEF pentru dispozitiv expira. Da, fiecare abonament are o durată de viață stabilită de operator sau convenită cu AS. La expirarea acestuia, PDN va fi dezactivat pe MME, iar dispozitivul va deveni inaccesibil pentru AS. În acest caz, funcționalitatea „Device triggering” va ajuta de asemenea. La primirea de noi date de la AS, SCEF va verifica starea de conectare a 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, pentru SCEF sunt deja standardizate mai mult de zece servicii. Acum am acoperit doar funcțiile de bază și cele solicitate de dezvoltatori; despre celelalte vom discuta în articolele viitoare.

Se pune imediat întrebarea, cum se poate obține accesul de test la acest „minune”-nod pentru testarea preliminară și debugging-ul posibilelor cazuri? Totul este foarte simplu. Orice dezvoltator poate trimite o solicitare la iot.info@mts.ru, în care este suficient să menționeze scopul conectării, o descriere a cazului posibil și informațiile de contact pentru a fi contactat.

Ne vedem data viitoare!

Autori:

• expert senior al soluțiilor convergente și serviciilor multimedia Serghei Novikov sanov,
• expert al soluțiilor convergente și serviciilor multimedia Alexei Lapșin aslapsh

Sursa: habr.com