NB-IoT: kuidas see töötab? Osa 3: SCEF – operaatori teenustele pääsemise ühtne keskus

Artiklis «NB-IoT: kuidas see töötab? Osa 2», räägime NB-IoT võrgu pakett-omaarkitektuurist ja mainime uut SCEF sõlme. Selgitame kolmandas osas, mis see on ja miks seda on vaja?

M2M-teenuse loomisel seisavad rakenduste arendajad silmitsi järgmiste küsimustega:

• kuidas seadmeid tuvastada;
• millist autentimise ja tõendamise algoritmi kasutada;
• millist transportprotokolli seadmete vaheliseks suhtlemiseks valida;
• kuidas andmeid seadmetesse usaldusväärselt edastada;
• kuidas korraldada ja kehtestada andmevahetuse reegleid;
• kuidas jälgida ja reaalajas teavet nende seisundi kohta saada;
• kuidas andmeid samaaegselt edastada rühmale seadmetest;
• kuidas andmeid samaaegselt edastada ühest seadmest mitmele kliendile;
• kuidas saada ühtne ligipääs operaatori täiendavatele teenustele seadme haldamiseks.

Nende probleemide lahendamiseks tuleb luua patenteeritud tehniliselt „raskete” lahenduste, mis suurendab tööjõu nõudlikkust ja teenuste turule toomise aega. Just siin tulebki appi uus SCEF sõlm.

3GPP definitsiooni kohaselt on SCEF (service capability exposure function) täiesti uus komponent 3GPP arhitektuuris, mille funktsiooniks on teenuste ja võimaluste turvaline eksponeerimine, mida pakuvad 3GPP võrgu liidesed API kaudu.

Lihtsustatult öeldes on SCEF vahendaja võrgu ja rakenduste serveri (application server — AS) vahel, pakkudes ühte ligipääsu operaatori teenustele, et hallata oma M2M seadet NB-IoT võrgus intuitiivse ja standardiseeritud API-liidese abil.

SCEF peidab operaatori võrgu keerukuse, võimaldades rakenduste arendajatel end distantsi võtta keerulistest ja spetsiifilistest seadmete suhtlemismehhanismidest.

Muutes võrgu protokolle arendajatele tuttavaks API-liideseks, muudab SCEF uute teenuste loomise lihtsamaks ja vähendab turule suunamise aega. Samuti sisaldab uus sõlm mobiilseadmete identifitseerimise ja autentimise funktsioone, andes reeglid andmevahetuse jaoks seadme ja AS vahel, vabastades rakenduste arendajad nende funktsioonide rakendamisest oma poolel, andes vastutuse nende funktsioonide täitmise eest operaatori kanda.

SCEF ühendab kõik vajalikud liidesed, mis on vajalikud rakendusserverite autentimiseks ja autoriseerimiseks, UE liikuvuse säilitamiseks, andmete edastamiseks ja seadmete aktiveerimiseks, samuti juurdepääsuks lisateenustele ja operaatori võrgu võimalustele.

AS-i suunas on ainult üks liides T8, API-liides (HTTP/JSON), mis on standardiseeritud 3GPP poolt. Kõik liidesed, välja arvatud T8, töötavad DIAMETER-protokolli põhjal (joonis 1).

T6a on liides SCEF-i ja MME vahel. Seda kasutatakse liikuvuse/seansi haldamise protseduuride, non-IP andmete edastamise, jälgimise sündmuste varustamise ning nende aruannete saamiseks.

S6t on liides SCEF-i ja HSS vahel. See on vajalik abonendi autentimiseks, rakendusserverite autoriseerimiseks, external ID ja IMSI/MSISDN sidumise saamiseks, samuti jälgimise sündmuste varustamiseks ja nende aruannete saamiseks.

S6m/T4 – SCEF-i ja HSS-i ning SMS-C vahelised liideseid (3GPP-s on määratud MTC-IWF, mida kasutatakse seadmete aktiveerimiseks ja SMS-ide edastamiseks NB-IoT võrkudes. Siiski on selle sõlme funktsionaalsus kõigis teostustes integreeritud SCEF-i, seega lihtsustades skeemi, ei käsitleme seda eraldi). Kasutatakse SMS-i saatmise ja SMS-keskusega suhtlemise marsruudi teabe saamiseks.

T8 – SCEF-i API-liides rakendusserveritega suhtlemiseks. Selle liidese kaudu edastatakse nii juhtimisnõuded kui ka liiklus.

*tegelikult on liideseid rohkem, siin on loetletud vaid põhilised. Täielik nimekiri on toodud 3GPP 23.682 (4.3.2 Viidete nimekiri).

Allpool on toodud SCEF-i peamised funktsioonid ja teenused:

• SIM-kaardi identifikaatori (IMSI) sidumine external ID-ga;
• non-IP andmete edastamine (Non-IP Data Delivery, NIDD);
• grupitegevused, kasutades external group ID-d;
• andmete edastamise toetamist kinnitustega;
• MO (Mobile Originated) ja MT (Mobile Terminated) andmete puhversüsteem;
• seadmete ja rakendusserverite autentimine ja autoriseerimine;
• ühe UE andmete samal ajal kasutamine mitme AS-i poolt;
• UE (MONTE – Monitoring Events) olekonsulteerimise erifunktsioonide tugi;
• seadmete käivitamine;
• non-IP andmete rändlust tagamine.

AS ja SCEF vahelise koostöö peamine põhimõte põhineb nn tellimuste skeemil. Kui SCEF vajab juurdepääsu mõnele teenusele teatud UE jaoks, peab rakendusserver looma tellimuse, saates käsu konkreetsele API-le nõutud teenuse jaoks ja saadud vastuse tulemusena saama ainulaadse identifikaatori. Pärast seda toimuvad kõik edasised toimingud ja suhtlemine UE-ga selle teenuse raames selle identifikaatori abil.

Väline ID: seadme universaalne identifikaator

Üks olulisemaid muudatusi AS-i ja seadmete vahelises koostöös SCEF-i kaudu on universaalse identifikaatori ilmumine. Nüüd ei kasutata enam seadme identifikaatorina telefoninumbrit (MSISDN) või IP-aadressi, nagu see oli klassikalises 2G/3G/LTE võrgus, vaid seadme identifikaatoriks rakendusserveri jaoks saab "välise ID". See on määratletud standardses, arendajatele tuttavas vormingus "@".

Arendajatel ei ole enam vaja rakendada seadmete autentimise algoritme, kogu funktsioon on täielikult võrgu enda kanda. External ID sidub IMSI-ga, ja arendaja võib olla kindel, et konkreetse external ID-ga suheldes suhtleb ta konkreetse SIM-kaardiga. SIM-kiipi kasutades tekib täielikult ainulaadne olukord, kus external ID tuvastab üheselt konkreetse seadme!

Veelgi enam, ühele IMSI-le võib siduda mitu external ID-d — nii tekib veelgi huvitavam olukord, kus external ID tuvastab üheselt konkreetse rakenduse, mis vastutab konkreetse teenuse eest antud seadmes.

Samuti tekib grupi identifikaator — external group ID, mis sisaldab endas tervikut eraldi external ID-dest. Nüüd saab ühe päringuga SCEF AS-i algatada grupitegevusi — andmete saatmist või juhtimisalgatusi paljudele seadmetele, mis on koondatud ühte loogilisse gruppi.

Kuna arendajatel AS-ile ei saa uus seadme identifikaator olla kohene, on SCEF jäänud võimaluseks AS-i ja UE suhtlemiseks standardse numbri – MSISDN – kaudu.

Non-IP andmete edastamine (Non-IP Data Delivery, NIDD)

NB-IoT-s, andmete edastamise mehhanismide optimeerimise raames, lisaks juba olemasolevatele PDN-i liikidele, nagu IPv4, IPv6 ja IPv4v6, on tekkinud veel üks liik — non-IP. Sellisel juhul ei omista seadele (UE) IP-aadressi ja andmed edastatakse ilma IP-protokolli kasutamiseta. Selliste ühenduste liiklus võib suunata kahte moodi: klassikaliselt — MME -> SGW -> PGW ja edasi PtP tunnelis AS-i (vt joonis 2) või kasutades SCEF-i (vt joonis 3).

Klassikaline meetod ei paku IP-liikluse ees olulisi eeliseid, välja arvatud edastatavate pakettide suuruse vähenemine IP-peade puudumise tõttu. SCEF-i kasutamine aga avab uue hulga võimalusi ja lihtsustab seadmete suhtluse protseduure.

Andmete edastamisel SCEF-i kaudu ilmneb kaks väga olulist eelist klassikalise IP-liikluse ees:

MT liikluse kohaletoimetamine seadmele välise ID kaudu

Klassikalisele IP-seadmest sõnumi saatmiseks peab AS teadma selle IP-aadressi. Siin tekib probleem: kuna seade saab registreerimisel tavaliselt "hall" IP-aadressi, suhtleb see rakenduste serveriga, mis asub internetis, NAT-sõlme kaudu, kus halli aadressi muudetakse valgeks. Halli ja valge IP-aadressi seos kestab piiratud aja, sõltuvalt NAT-i seadistustest. Keskmiselt TCP või UDP jaoks - mitte rohkem kui viis minutit. See tähendab, et kui viie minuti jooksul ei toimu seadmest andmevahetust, laguneb seos ja seade lakkab olemast kättesaadav selle valge aadressi kaudu, millega sessioon AS-iga algatati. On mitmeid lahendusi:

1. Kullaneda heartbeat. Ühenduse loomise korral peab seade saatma AS-ile pakette iga paari minuti tagant, et vältida NAT-i muunduste sulgemist. Kuid siin ei saa juttu olla mingist energiatõhususest.

2. Iga kord, kui on vaja seadmest pakettide olemasolu kontrollida AS-is - saata uplinkis sõnum.

3. Luua privaatne APN (VRF), kus rakenduste server ja seadmed asuvad samas alamvõrgus ning määrata seadmetele staatilised IP-aadressid. See toimib, kuid see on peaaegu teostamatu, kui tegu on tuhandete, kümnete tuhandete seadmetega.

4. Lõpuks, kõige sobivam variant: kasutada IPv6, kuna NAT-i pole vajalik, sest IPv6 aadresse saab otse internetist. Siiski, isegi sel juhul, kui seade registreeritakse uuesti, saab see uue IPv6 aadressi ja ei pruugi enam olla kergesti ligipääsetav varasema aadressi kaudu.

Seega on vajalik saata serverile mingit tüüpi algatuspakk, mis sisaldab seadme identifikaatorit, et edastada uue seadme IP-aadress. Seejärel tuleb oodata kinnituspakkumist AS-ilt, mis mõjutab samuti energiatarbimist.

Need meetodid toimivad hästi 2G/3G/LTE seadmete puhul, kus seadmele ei esita ranged nõuded autonoomi jaoks ning seega puuduvad piirangud eetrisoleku aja ja andmeside osas. NB-IoT puhul ei sobi need meetodid nende suure energiatarbimise tõttu.

SCEF lahendab selle probleemi: kuna seadme ainus identifikaator AS-i jaoks on external ID, piisab AS-ile andmepaketi saatmisest SCEF-ile konkreetse external ID jaoks, kõik muu hoolitseb SCEF. Kui seade on energiasäästu režiimis PSM või eDRX, andmed vahetatakse puhvrisse ja tarnitakse, kui seade on saadaval. Kui seade on aga liikluseks saadaval, tarnitakse andmed koheselt. See kehtib ka halduskomandode kohta.

Iga hetk AS võib tagasi kutsuda puhverdatud sõnumi UE suunal või asendada selle uuega.

Puhverdamismehhanismi saab kasutada ka MO-andmete edastamiseks UE-st AS-i suunal. Kui SCEF ei suutnud andmeid AS-ile kohe edastada, näiteks kui AS-i serverites on hooldustööd, siis need paketid vahetatakse puhvrisse ja tarnitakse kindlasti, kui AS on taas saadaval.

Nagu eelnevalt mainitud, on juurdepääs teatud teenusele ja UE-le AS-le (kus NIDD on teenus) reguleeritud SCEF-i poolelt kehtivate reeglite ja poliitikatega, mis võimaldab unikaalset võimalust kasutada sama UE andmeid mitmete AS-ide poolt samaaegselt. See tähendab, et kui mitu AS-i on sama UE-le tellitud, siis pärast andmete saamist UE-lt edastab SCEF need kõikidele tellitud AS-idele. See sobib hästi juhtumite jaoks, kus spetsialiseeritud seadmete pargi looja jagab andmeid mitme kliendi vahel. Näiteks, luues NB-IoT-l töötavate ilmapostide võrgu, on võimalik müüa nende andmeid mitmele teenusele samaaegselt.

Sõnumite garanteeritud kohaletoimetamise mehhanism

Reliable Data Service — sõnumite MO ja MT kohaletoimetamise mehhanism ilma spetsialiseeritud algoritmide kasutamiseta protokollitasandil, nagu näiteks TCP-s oleva handshake'i puhul. Töötab, lisades spetsiaalse lipu sõnumi teenusosasse UE ja SCEF vahelises vahetuses. Kas aktiveerida või mitte aktiveerida see mehhanism andmevoo edastamisel, otsustab AS.

Kui mehhanism on aktiveeritud, lisab UE vajadusel MO liikluse garanteeritud edastamise tagamiseks paketi juhtosa erilise lipu. Kui SCEF saab sellise paketi, vastab see UE-le kinnitusega. Kui UE ei saa kinnituse paketiga, saadetakse pakett SCEF-ile uuesti. Sama toimub ka MT liikluse puhul.

Seadmete jälgimine (monitoring events - MONTE)

Nagu eespool mainitud, sisaldab SCEF funktsionaalsus, peale teiste, ka UE oleku jälgimise funktsioone, nn seadmete jälgimist. Ja kui uued identifikaatorid ja andmete edastamise mehhanismid on olemasolevate protseduuride optimeerimised (kuigi väga olulised), siis MONTE on täiesti uus funktsionaalsus, mida 2G/3G/LTE võrkudes ei ole. MONTE võimaldab AS-l jälgida seadme parameetreid, nagu ühenduse seisund, kommunikatsioonivõime, asukoht, rändestatus jne. Räägime igast neist lähemalt veidi hiljem.

Kui on vajalik aktiveerida mõni seadme või seadmete rühma jälgimissündmus, siis AS tellib vastava teenuse, saates SCEF-ile MONTE API vastava käsu, kusse kuuluvad sellised parameetrid nagu external Id või external group ID, AS identifikaator, jälgimise tüüp, raportite hulk, mida AS soovib saada. Kui AS on volitatud päringut täitma, siis SCEF provitsioneerib sõltuvalt tüübist sündmuse HSS-is või MME-s (vt joonis 4). Sündmuse toimumisel genereerivad MME või HSS raporti SCEF-i suunas, mis saadetakse AS-ile.

Kõigi sündmuste provitsioneerimine, välja arvatud „Number of UEs present in a geographic area”, toimub HSS-i kaudu. Kaks sündmust „Change of IMSI-IMEI Association” ja „Roaming Status” jälgitakse otse HSS-is, ülejäänud provitsioneerib HSS MME-le.
Sündmused võivad olla nii ühekordsed kui ka perioodilised ning sõltuvad nende tüübist.

Sündmuse raporti saatmine (raporteerimine) toimub sündmust jälgiva sõlme poolt otse SCEF-ile (vt joonis 5).

Oluline punkt: Jälgimisüritusi saab kasutada nii non-IP seadmete jaoks, mis on ühendatud SCEF-i kaudu, kui ka IP-seadmete jaoks, mis edastavad andmeid klassikalise MME-SGW-PGW kaudu.

Uurime iga jälgimisüritust lähemalt:

Ühenduse katkemine — teavitab AS-i, et UE ei ole enam kergesti kättesaadav ei andmevahetuseks ega signaalivahetuseks. Üritus toimub, kui MME-l aegub "mobile reachability timer" UE jaoks. Jälgimisürituse taotluses võib AS märkida oma "Maximum Detection Time" väärtuse — kui selles ajavahemikus UE ei näita mingit aktiivsust, teavitab AS-i, et UE ei ole kättesaadav, märkides põhjuse. Üritus toimub ka juhul, kui UE on mingil põhjusel sunniviisiliselt eemaldatud võrgust.

* Ettevõtte teadlikkuse säilitamiseks peab seade perioodiliselt käivitama värskendamise protseduuri — Tracking Area Update (TAU). Selle protseduuri sageduse määrab võrk, kasutades T3412 või (T3412_extended PSM-i korral) ajastit, mille väärtus edastatakse seadmele ühendamise või järgmise TAU protseduuri ajal. Mobile reachability timer on tavaliselt mitu minutit pikem kui T3412. Kui UE ei tee TAU-d „Mobile reachability timeri” lõpuks, peab võrk seda vähem kergesti kätte saadavaks.

UE kättesaadavus – Näitab, millal UE on saadaval DL liiklusele või SMS-idele. See juhtub, kui UE muutub kergesti kätte saadavaks lehekatte jaoks (UE eDRX-režiimis) või kui UE liigub ECM-CONNECTED režiimi (UE PSM-i või eDRX-i režiimis), st teeb TAU-d või saadab ülesvoolu paketti.

Asukoha raporteerimine – See sündmuste jälgimise tüüp võimaldab AS-l küsida UE asukohaandmeid. Võib küsida kas praegust asukohta (Current Location) või viimase teadaolevat asukohta (Last Known Location, määratakse cell ID põhjal, millest seade tegi TAU või edastas viimati liiklust), mis on asjakohane energiasäästurežiimis PSM või eDRX olevatele seadmetele. "Current Location" puhul võib AS küsida korduvaid aruandeid, samal ajal kui MME teavitab AS-i igal korral, kui seadme asukoht muutub.

IMSI-IMEI assotsatsiooni muutmine – Selle sündmuse aktiveerimisel hakkab SCEF jälgima IMSI (SIM-kaardi identifikaatori) ja IMEI (seadmestiku identifikaatori) sideme muutust. Sündmuse toimumisel teavitab AS. Seda saab kasutada välise ID automaatseks seondamiseks seadmega plaaniliste asendustööde käigus või selleks, et olla seadmestiku varguse identifikaator.

Rändlusteenuse staatus – See monitorimisülesanne kasutatakse AS-i poolt, et määrata, kas UE on koduvõrgus või rändlusteenuse partneri võrgus. Valikuliselt võib edastada PLMN (avalik maapealne mobiilivõrk) operaatori, milles seade on registreeritud.

Sidekatkestus — See tüü jälgimine teavitab AS-i seadmega suhtlemise katkemisest, tuginedes ühenduse katkestamise põhjustele (release cause code), mis saadud raadiot pääsuvõrgu (S1-AP protokoll) kaudu. See sündmus võib aidata välja selgitada, mis põhjustas suhtlemise katkemise — kas võrgu probleemide tõttu, näiteks eNodeb koormuse tõttu (Radio resources not available), või seadme rikke tõttu (Radio Connection With UE Lost).

Saadavus pärast DDN tõrget – see sündmus teavitab AS-i, et seade on pärast suhtlemise katkemist taas saadaval. Seda saab kasutada juhul, kui on vajalik andmete edastamine seadmele, kuid varasem katse ei õnnestunud, kuna UE ei vastanud võrgu teatele (paging) ja andmeid ei toimetatud. Kui seda tüüpi jälgimist on küsitud UE jaoks, siis kohe, kui seade teeb sisenemise suhtluse, TAU või saadab andmeid uplinkis, teavitatakse AS-i, et seade on taas saadaval. Kuna DDN (downlink data notification) protseduur töötab MME ja S/P-GW vahel, on see jälgimisseade saadaval ainult IP-seadmete jaoks.

PDN ühenduvuse staatus – teavitab AS seadme staatuse muutumisest (PDN ühenduvuse staatus) – ühendamise (PDN aktiveerimine) või lahti ühendamise (PDN eemaldamine) kohta. Seda saab AS kasutada UE-ga suhtlemise algatamiseks või vastupidi, et mõista, et suhtlemine pole enam võimalik. Selline jälgimise tüüp on saadaval nii IP kui ka non-IP seadmete jaoks.

Geograafilises piirkonnas olevate UE-de arv – seda tüüpi jälgimist kasutab AS, et määrata kindlaks, kui palju UE-sid on teatud geograafilises piirkonnas.

Seadmete aktiveerimine (Device triggering)

2G/3G võrkudes oli võrgu registreerimise protseduur kaheastmeline: kõigepealt registreeriti seade SGSN-is (attach protseduur), seejärel, kui andmete edastamine oli vajalik, aktiveeriti PDP konteksts – ühendus paketigateway-ga (GGSN). 3G võrkudes toimusid need kaks protseduuri järjestikku, st seade ei oodanud hetke, mil andmeid edastada, vaid aktiveeris PDP kohe pärast attach protseduuri lõpetamist. LTE-s ühendati need kaks protseduuri üheks, seega attach’i korral küsis seade kohe PDN ühenduse aktiveerimist (sarnane PDP-le 2G/3G) läbi eNodeB MME-SGW-PGW-le.

NB-IoT-s on määratletud selline ühendusmeetod nagu "attach without PDN", mis tähendab, et UE teeb ühenduse, ilma et loodi PDN-ühendust. Sel juhul pole see andmete edastamiseks saadaval ja saab ainult SMS-e vastu võtta või saata. Selleks, et anda sellisele seadmele käsk PDN-i aktiveerimiseks ja AS-iga ühendamiseks, on loodud funktsioon "Device triggering".

Kui AS-ilt on saadud käsk sellise UE ühendamiseks, algatab SCEF SMS-keskuse kaudu seadmele juhtiva SMS-i saatmise. SMS-i saamisel aktiveerib seade PDN-i ja ühendub AS-iga, et saada edasisi juhiseid või andmeid edastada.

On võimalik, et SCEF-il on seadme tellimus aegunud. Jah, tellimusel on oma kehtivusaeg, mille määrab operaator või mille on AS-iga kokku leppinud. Selle lõppedes deaktiveeritakse MME-l PDN ja seade muutub AS-i jaoks kättesaamatuks. Sel juhul aitab samuti funktsioon "Device triggering". Uute andmete saamisel AS-ilt tuvastab SCEF seadme ühenduse staatuse ja edastab andmeid SMS-kanali kaudu.

Kokkuvõte

SCEF funktsioneerimine ei piirdu vaid ülaltoodud teenustega, vaid see areneb ja laieneb pidevalt. Praeguseks on SCEF-i jaoks standardiseeritud üle tosina teenuse. Hetkel käsitlesime vaid peamisi ja arendajate seas nõutud funktsioone, ülejäänutest räägime tulevastes artiklites.

Tõstatub koheselt küsimus, kuidas saada testjuurdepääs sellele "ime"-punktile eelteadmiste ja erinevate juhtumite testimiseks? Kõik on väga lihtne. Iga arendaja võib saata päringu aadressile iot.info@mts.ru, kus piisab, kui märkida ühenduse eesmärk, juhtumite kirjeldus ja kontaktandmed.

Kuni kohtumiseni!

Autorid:

• konvergente lahenduste ja multimeedia teenuste vanemekspert Sergei Novikov sanov,
• konvergente lahenduste ja multimeedia teenuste ekspert Aleksei Lapshin aslapsh

Allikas: habr.com