NB-IoT: kuidas see töötab? Osa 3: SCEF – operaatori teenustele juurdepääsu üksikaken

Artiklis «NB-IoT: kuidas see töötab? Osa 2» käsitletakse NB-IoT paketi tuuma arhitektuuri, kus mainime uue SCEF sõlme tulekut. Selgitame kolmandas osas, mis see ikkagi on ja miks seda on vaja?

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

• kuidas tuvastada seadmed;
• millist autentimise ja kinnitamise algoritmi kasutada;
• millise transportprotokolli valida seadmetega suhtlemiseks;
• kuidas andmeid seadmetesse usaldusväärselt edastada;
• kuidas korraldada ja kehtestada andmevahetuse reeglid;
• kuidas reaalajas jälgida nende seisundit;
• kuidas andmeid üheaegselt edastada oma seadmete gruppidele;
• kuidas üheaegselt edastada andmeid ühest seadmest mitmele kliendile;
• kuidas saada ühtne juurdepääs operaatori lisateenustele oma seadme haldamiseks.

Nende lahendamiseks on vajalik luua patenteeritud tehniliselt ‘raskemaid’ lahendusi, mis toob kaasa suurenenud töökoormuse ja teenuste turuletoomise aja. Siinkohal tulebki appi uus SCEF sõlm.

3GPP määratlemise kohaselt on SCEF (teenuse suutlikkuse eksponeerimise funktsioon) täiesti uus komponent 3GPP arhitektuuris, mille funktsiooniks on turvaliselt eksponeerida teenuseid ja võimalusi, mida pakuvad 3GPP võrgu liidesed API kaudu.

Lihtsustatult öeldes on SCEF vahend võrgus ja rakenduste serveri (rakenduste server - AS) vahel, mille kaudu pääseb juurdepääsu operaatori teenustele oma M2M-seadmest NB-IoT võrgus läbi intuitiivselt mõistetava standardiseeritud API liidese.

SCEF peidab operaatori võrgu keerukuse, võimaldades rakenduste arendajatel abstraktiseerida keerulised, spetsiifilised seadmeid puudutavad suhtlemismehhanismid.

Muutes võrgu protokollid arendajatele tuttavaks API liideseks, lihtsustab SCEF uute teenuste loomist ja lühendab turuletoomise aega. Samuti sisaldab uus sõlm mobiilseadmete autentimise tuvastamise ning andmevahetuse reeglite määramise funktsioone, vabastades rakenduste arendajad nende rakendamiseks oma poolel, usaldades need funktsioonid operaatori kanda.

SCEF ühendab kõik vajalikud liidesed rakenduste serverite autentimiseks ja autoriseerimiseks, UE mobiilsuse säilitamiseks, andmete edastamiseks ja seadmete aktiveerimiseks, samuti juurdepääsuks operaatori lisateenustele ja võrguvõimekustele.

AS-i suunas on üksainus liides T8, API-liides (HTTP/JSON), mille on standardiseerinud 3GPP. Kõik liidesed, välja arvatud T8, töötavad DIAMETER protokolli alusel (vt joonis 1).

T6a – liides SCEF-i ja MME vahel. Kasutatakse mobiilsuse/sessioonihalduse, non-IP andmete edastamise, jälgimissündmuste provotseerimise ja nende raportite saamise protseduuride jaoks.

S6t – liides SCEF-i ja HSS vahel. Vajalik määratud abonendi autentimiseks, rakenduste serverite autoriseerimiseks, external ID ja IMSI/MSISDN sidumise saamiseks, jälgimissündmuste provotseerimiseks ja nende raportite saamiseks.

S6m/T4 – liidesed SCEF-ist HSS-ile ja SMS-C-le (3GPP määratleb MTC-IWF sõlme, mida kasutatakse seadmete aktiveerimiseks ja SMS-ide edastamiseks NB-IoT võrkudes. Kuid kõigis rakendustes on selle sõlme funktsionaalsus integreeritud SCEF-i, seega lihtsustamise huvides ei käsitle me seda eraldi). Kasutatakse SMS-i saatmiseks vajaliku marsruutimise info saamiseks ja SMS-keskusega suhtlemiseks.

T8 – API-liides SCEF-i suhtlemiseks rakenduste serveritega. Selle liidese kaudu edastatakse nii juhtimis käsud kui ka andmevoog.

*Tegelikult on liideseid rohkem, siin on loetletud ainult kõige olulisemad. Täielik loetelu on esitatud 3GPP 23.682 (4.3.2 Viidatud punktide loetelu).

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);
• grupi operatsioonid, kasutades external group ID-d;
• ande edastamise tagasisidega režiimi tugi;
• MO (Mobile Originated) ja MT (Mobile Terminated) andmete vahemällu salvestamine;
• seadmete ja rakenduste serverite autentimine ja autoriseerimine;
• ühe UE andmete samaaegne kasutamine mitme AS-i poolt;
• eriliste UE oleku jälgimise funktsioonide tugi (MONTE – Monitoring Events);
• seadmete aktiveerimine;
• non-IP andmete rändeteenuste tagamine.

AS ja SCEF vahelise koostöö põhivorm põhineb nn tellimuste skeemil. Kui SCEF vajab juurdepääsu mingile teenusele teatud UE jaoks, peab rakenduste server looma tellimuse, saates käsu konkreetsele API-le nõutud teenusest ja saades vastuseks unikaalse identifikaatori. Edasi toimuvad kõik tegevused ja suhtlus UE-ga antud teenuse raames selle identifikaatori kasutamise kaudu.

External ID: seadme universaalne identifikaator

Üks peamisi muudatusi AS-i ja seadmete koostöö skeemis SCEF-i kaudu on universaalse identifikaatori ilmumine. Nüüd, erinevalt telefoninumbritest (MSISDN) või IP-aadressidest, nagu see oli traditsioonilises 2G/3G/LTE võrgus, on seadme identifikaator rakenduste serveri jaoks "external ID". See on määratletud standardis arendajatele tuttavas formaadis "@".

Arendajatel ei ole enam vaja rakendada seadme autentimise algoritme, kuna kogu funktsiooni võtab enda kanda võrk. External ID seondub IMSI-ga, mistõttu arendaja võib olla kindel, et pöördudes konkreetse external ID poole, suhtleb ta konkreetse SIM-kaardiga. SIM-kiibi kasutamisel tekib täiesti ainulaadne olukord, kus external ID tuvastab ühemõtteliselt konkreetse seadme!

Lisaks saab ühele IMSI-le siduda mitmeid external ID-sid — see loob veelgi huvitavama olukorra, kui external ID tuvastab ühemõtteliselt konkreetse rakenduse, mis on seotud teatud teenusega antud seadmel.

Samuti ilmub rühma identifikaator — external group ID, mis sisaldab rikka individuaalseid external ID-sid. Nüüd saab ühe päringuga SCEF-ile AS algatada grupitegevusi — andmete või juhtimisnõuete saatmine paljudele seadmetele, mis on ühendatud ühte loogilisse gruppi.

Kuna AS-i arendajate jaoks ei saa üleminek uuele seadme identifikaatorile olla kohene, on SCEF ikka veel võimaldanud AS-i suhtlemist UE-ga standardse numbri – MSISDN – kaudu.

Non-IP andmeedastus (Non-IP Data Delivery, NIDD)

NB-IoT-s, väikeste andmehulkade edastamise mehhanismide optimeerimise käigus, on olemasolevate PDN-tüüpidest, nagu IPv4, IPv6 ja IPv4v6, lisandunud veel üks tüüp - non-IP. Sellisel juhul ei omistata seadmele (UE) IP-aadressi ning andmed edastatakse ilma IP-protokolli kasutamata. Selliste ühenduste liiklust saab suunata kahel viisil: klassikaline - MME -> SGW -> PGW ja edasi PtP tunneliga AS-i (vt joonis 2) või kasutades SCEF-i (vt joonis 3).

Klassikaline meetod ei paku IP-liikluse ees erilisi eeliseid, välja arvatud pakettide suuruse vähendamine IP-pealkirjade puudumise tõttu. SCEF-i kasutamine avab aga terve rea uusi võimalusi ja lihtsustab seadmete koostalitluse protseduure.

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

• MT-liikluse edastamine seadmele välise ID kaudu

Klassikalise IP-seadmest sõnumi edastamiseks peab AS teadma selle IP-aadressi. Siin tekib probleem: kuna seade registreerimise ajal saab tavaliselt „hall“ IP-aadress, suhtleb ta internetis asuva rakenduste serveriga NAT-sõlme kaudu, kus halli aadressi muudetakse valgeks. Halli ja valge IP-aadressi paar püsib piiratud aja, sõltuvalt NAT-i seadistustest. Keskmiselt TCP või UDP puhul - mitte rohkem kui viis minutit. See tähendab, et kui viie minuti jooksul ei ole seadmega andmevahetust, laguneb seos ja seade ei ole enam selle valge aadressi kaudu, millega AS-iga sessioon algatati, kättesaadav. On mitu lahendust:

1. Kasutada heartbeat'i. Ühe korra ühenduse seadmisel peab seade vahetama AS-iga pakette iga paari minuti järel, hoides sellega NAT-i translatsiooni avatud. Kuid siin ei saa rääkida mingisugusest energiatõhususest.

2. Iga kord, kui on vaja, kontrollida seadme pakette AS-is - saata sõnum uplinki.

3. Luua privaatne APN (VRF), kus rakenduste server ja seadmed asuvad samas alamvõrgus, ning määrata seadmetele staatilised IP-aadressid. See töötab, kuid seda on peaaegu võimatu teostada, kui tegemist on tuhandete, isegi kümnete tuhandete seadmetega.

4. Lõpuks sobivaim variant: kasutada IPv6, kuna selle jaoks ei ole vajalik NAT, kuna IPv6 aadressid on otse internetist saadaval. Kuid isegi sel juhul, kui seade registreeritakse uuesti, saab see uue IPv6 aadressi ja ei ole enam kätte saadav varasema aadressi järgi.

Seetõttu tuleb saata serverile algatuspakett koos seadme identifikaatoriga, et teatada seadme uue IP-aadressi kohta. Seejärel tuleb oodata kinnitavat paketti AS-ilt, mis mõjutab samuti energiaefektiivsust.

Need meetodid töötavad hästi 2G/3G/LTE seadmete puhul, kus seadmele ei esitata rangeid autonoomsuse nõudeid ning seetõttu ei ole ka reaalajas ja liikluse osas piiranguid. NB-IoT jaoks ei sobi need meetodid nende suure energiatarbimise tõttu.

SCEF lahendab selle probleemi: kuna seadme ainus identifikaator AS-i jaoks on väline ID, piisab AS-ilt andmepaketi saatmisest SCEF-ile konkreetse välishääle jaoks, kõik muu korraldab SCEF. Kui seade on energiasäästurežiimis PSM või eDRX, siis andmed vahemälustatakse ja edastatakse, kui seade on kätte saadav. Kui seade on liikluseks saadaval, edastatakse andmed viivitamatult. See kehtib ka juhtimiskäskude puhul.

Igal ajal võib AS tagasi kutsuda vahemälus hoidmise sõnumi UE suunas või asendada selle uuega.

Vahemälumehhanismi saab rakendada ka MO-andmete edastamisel UE-lt AS-i. Kui SCEF ei suutnud andmeid kohe AS-ile edastada, näiteks kui AS serverites toimub hooldustööd, siis need paketid vahemälustatakse ja tagatakse, et need edastatakse, kui AS on saadaval.

Nagu eespool mainitud, reguleerivad juurdepääsu konkreetsele teenusele ja UE-le AS-i jaoks (ja NIDD on teenus) reeglid ja poliitikad SCEF-i poolel, võimaldades erakordset võimalust, et sama UE andmeid kasutavad korraga mitu AS-i. St kui mitu AS-i registreerub ühe UE jaoks, siis pärast andmete saamist UE-lt edastab SCEF need kõikidele registreeritud AS-idele. See sobib hästi juhtumiteks, kus spetsialiseeritud seadmete loojad jagavad andmeid mitme kliendiga. Näiteks, luues murejaamade võrgu, mis töötab NB-IoT, saab andmeid müüa paljudele teenustele korraga.

Sõnumite garanteeritud kohaletoimetamise mehhanism

Reliable Data Service — sõnumite MO ja MT garanteeritud kohaletoimetamise mehhanism ilma spetsialiseeritud algoritmide, nagu TCP handshake, kasutamiseta. See töötab, lisades sõnumi teenusosa erimärgi vahetamisel UE ja SCEF vahel. AS otsustab, kas aktiveerida või mitte aktiveerida see mehhanism andmevoogude edastamisel.

Kui mehhanism on aktiveeritud, lisab UE, kui on vajalik MO andmevoogude garanteeritud kohaletoimetamine, paketi teenusossa erimärgi. Kui SCEF saab sellise paketi, vastab see UE-le kinnitusega. Kui UE ei saa kinnituse paketiga, saadetakse pakett SCEF poole tagasi. Sama kehtib ka MT andmevoogude puhul.

Seadmete jälgimine (monitoring events- MONTE)

Nagu eelnevalt mainitud, sisaldab SCEF funktsionaalsus, peale selle, ka UE oleku jälgimise funktsioone, nn seadmete jälgimist. Ja kui uued identifikaatorid ja andmeedastusmehhanismid on optimeeringud (kuigi väga tõsised) juba olemasolevatele protseduuridele, siis MONTE on täiesti uus funktsionaalsus, mis ei ole saadaval 2G/3G/LTE võrkudes. MONTE võimaldab AS-l jälgida seadme selliseid parameetreid nagu ühenduse olek, kommunikatsioonivõimekuse kättesaadavus, asukoht, roaming'i olek jne. Räägime igaühe kohta hiljem üksikasjalikumalt.

Kui on vajalik aktiveerida mõni jälgimise üritus seadme või seadmete grupi jaoks, allkirjastab AS vastava teenuse, saates SCEF-ile vastava MONTE API käsu, mis sisaldab selliseid parameetreid nagu external Id või external group ID, AS identifikaator, jälgimise tüüp, aruannete arv, mida AS soovib saada. Kui AS on volitatud taotluse täitmiseks, proviisionib SCEF ürituse HSS või MME poolt sõltuvalt tüübist (vt joonis 4). Ürituse tekkimisel genereerib MME või HSS aruande SCEF poole, mis saadab selle AS-ile.

Kõigi ürituste proviisionimine, välja arvatud "Number of UEs present in a geographic area", toimub HSS kaudu. Kaks üritust "Change of IMSI-IMEI Association" ja "Roaming Status" jälgitakse otse HSS-is, teised proviisionib HSS MME-le.
Üritused võivad olla nii ühekordsed kui ka perioodilised ning sõltuvad nende tüübist.

Sündmuste aruande edastamine (raporteerimine) toimub sõlme kaudu, mis jälgib sündmust, otse SCEF-ile (kujund 5).

Oluline punkt: jälgimise sündmused võivad kehtida nii non-IP seadmetele, mis on ühendatud SCEF-i kaudu, kui ka IP-seadmetele, mis edastavad andmeid klassikalisel viisil läbi MME-SGW-PGW.

Vaadakem lähemalt igat jälgimise sündmust:

Ühenduse kadumine — teavitab AS-i, et UE ei ole enam kättesaadav ei andmeside jaoks ega signaalivahetuseks. Sündmus toimub, kui MME-l aegub "mobile reachability timer" UE jaoks. Selle jälgimise tüübi päringus võib AS määrata oma "Maximum Detection Time" väärtuse — kui selle aja jooksul UE ei näita mingit aktiivsust, teavitab AS, et UE ei ole kättesaadav, näidates põhjust. Samuti toimub sündmus, kui UE on mingil põhjusel võrgu poolt sunnitud eemaldatud.

* Et võrk teaks, et seade on endiselt kättesaadav, algatab see perioodiliselt värskendamisprotseduuri — Jälgimissektori Uuendus (TAU). Selle protseduuri sageduse määrab võrk T3412 taimeri abil või (T3412_extended juhul kui PSM), mille väärtus edastatakse seadmele seose käivitamise või järgmise TAU protseduuri ajal. Mobile reachability timer on tavaliselt paar minutit pikem kui T3412. Kui UE ei tee TAU-d "Mobile reachability timer" kehtivuse ajal, peab võrk seda kättesaamatuks.

UE kättesaadavus – Näitab, millal UE muutub kättesaadavaks DL andmeside või SMS-i jaoks. See juhtub, kui UE muutub kättesaadavaks pagingu jaoks (UE eDRX režiimis) või kui UE läheb ECM-CONNECTED režiimi (UE PSM või eDRX režiimis), st teeb TAU või saadab ülespoole suunatud paketti.

Asukoha aruandlus – See monitorimise sündmuste liik võimaldab AS-l küsida UE asukohaandmeid. Võib küsida kas praegust asukohta (Current Location) või viimati teadaolevat (Last Known Location, määratakse cell ID järgi, millest seade tegi TAU või edastas andmeid viimati), mis on asjakohane energiasäästurežiimides olevate seadmete jaoks PSM või eDRX. "Current Location" korral võib AS küsida korduvaid aruandeid, samal ajal teavitab MME AS-i iga kord, kui seadme asukoht muutub.

IMSI-IMEI assotsiatsiooni muutus – Kui see sündmus aktiveeritakse, hakkab SCEF jälgima IMSI (SIM-kaardi identifikaator) ja IMEI (seadmestiku identifikaator) sideme muutmist. Kui sündmus toimub, teavitab see AS-i. Saame kasutada automaatseks välise ID sidumiseks seadmega plaaniliste asendustööde ajal või see võib toimida seadme varguse identifikaatorina.

Roamingu olek – seda tüüpi seiret kasutab AS, et määrata, kas UE on koduvõrgus või rändamise partneri võrgus. Valikuliselt võib edastada PLMN (avalik maapealne mobiilivõrk) operaatorilt, kus seade on registreeritud.

Side ebaõnnestumine — See seiresüsteem teavitab AS-i seadmega suhtlemise tõrgetest, tuginedes ühenduse katkestamise põhjustele (vabastamise põhjuse kood), mis saadi raadioside võrgust (S1-AP protokoll). See sündmus aitab kindlaks teha, miks side ebaõnnestus — kas võrgu probleemide tõttu, näiteks eNodeb ülekoormuse korral (raadiosüsteemi ressursid pole saadaval) või seadme enda tõrke tõttu (raadioside kaotamine UE-ga).

Saadavus pärast DDN ebaõnnestumist – see sündmus teavitab AS-i, et seade on pärast sidekatkestust kättesaadavaks muutunud. Seda võib kasutada, kui andmete edastamine seadmesse on vajalik, kuid eelmine katse jäi tulemusteta, kuna UE ei vastanud võrgu teavitusele (paging), ja andmeid ei saadud. Kui see seiretaotlus oli antud UE-le, siis kui seade algatab sissetuleva side, teeb TAU või saadab andmeid ülekande suunas, teavitab AS, et seade on kättesaadav. Kuna DDN (ülesande andmete teavitamine) protseduur töötab MME ja S/P-GW vahel, on see seiretüüp saadaval ainult IP-seadmetele.

PDN Ühenduvuse olek – teavitab AS-i seadme oleku muutusest (PDN ühenduvuse olek) — ühendamine (PDN aktiveerimine) või katkestamine (PDN eemaldamine). AS saab seda kasutada UE-ga suhtlemise algatamiseks või vastupidi, et mõista, et suhtlemine enam ei ole võimalik. See seiretüüp on saadaval nii IP- kui ka mitte-IP-seadmetele.

Geograafilises piirkonnas kohalolevate UE-de arv – seda tüüpi seiret kasutab AS, et määrata teatud geograafilises piirkonnas asuvate UE-de arv.

Seadmete käivitamine (Device triggering))

2G/3G võrkudes oli võrku registreerimise protseduur kahefooluline: esmalt registreeriti seade SGSN-is (attach protseduur), seejärel, kui andmete edastamine oli vajalik, aktiveeriti PDP kontekst – ühendus pakettvõrguga (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 liideti need kaks protseduuri ühte, st attachi korral küsis seade kohe PDN ühenduse (PDP analoog 2G/3G) aktiveerimist läbi eNodeB MME-SGW-PGW-le.

NB-IoT-s on määratletud ühendamise viis nimega “attach without PDN”, st UE teeb attachi, ilma et seadistaks PDN-ühendust. Sel juhul ei ole see andmete edastamiseks saadaval ja saab ainult SMS-e vastu võtta või saata. PDN-i aktiveerimise ja AS-iga ühenduse loomise käsu edastamiseks sellisele seadmele on välja töötatud funktsioon “Device triggering”.

Kui AS-ilt tuleb käsk sellise UE ühendamiseks, käivitab SCEF SMS-keskuse kaudu juhtsmise SMS-i saatmise seadmele. Kui seade saab SMS-i, aktiveerib see PDN-i ja ühendub AS-iga edasiste juhiste saamiseks või andmete edastamiseks.

Võivad tekkida olukorrad, kus SCEF-is lõpeb seadme tellimus. Jah, tellimusel on oma eluiga, mis on määratud operaatori poolt või kooskõlastatud AS-iga. Kui see aegub, deaktiveeritakse PDN MME-l ja seade muutub AS-i jaoks kättesaamatuks. Sellisel juhul aitab samuti funktsioon “Device triggering”. Kui AS-ilt saabub uus teave, tuvastab SCEF seadme ühendatusseisundi ja edastab andmed SMS-kanali kaudu.

Kokkuvõte

SCEF-i funktsioon ei piirdu kindlasti ülaltoodud teenustega ning areneb ja laieneb pidevalt. Praeguseks on SCEF-ile standardiseeritud juba rohkem kui tosin teenust. Praegu käsitlesime vaid põhifunktsioone, mis arendajate seas nõudlikud, kuid rääkime ülejäänutest tulevastes artiklites.

Küsimus tekib kohe, kuidas saada testimisõigus sellele „ime“ sõlmele eelneva testimise ja võimalike juhtumite silumise jaoks? Kõik on väga lihtne. Iga arendaja saab saata taotluse aadressile iot.info@mts.ru, kus piisab, kui märkida ühendamise eesmärk, võimaliku juhtumi kirjeldus ja kontaktandmed suhtlemiseks.

Kohtumiseni!

Autorid:

• vanem ekspert konvergentslahenduste ja multimeedia teenuste osakonnas Sergei Novikov sanov,
• ekspert konvergentslahenduste ja multimeedia teenuste osakonnas Aleksei Lapšin aslapsh

Allikas: habr.com