NB-IoT: kuidas see töötab? 3. osa: SCEF – operaatoriteenustele juurdepääsu üks aken

Artiklis "NB-IoT: kuidas see töötab? 2. osa", rääkides NB-IoT võrgu paketttuuma arhitektuurist, mainisime uue SCEF-sõlme ilmumist. Mis see on ja milleks seda vaja on, selgitame kolmandas osas?

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

• kuidas seadmeid tuvastada;
• millist verifitseerimis- ja autentimisalgoritmi kasutada;
• millist transpordiprotokolli seadmetega suhtlemiseks valida;
• kuidas andmeid seadmetesse usaldusväärselt edastada;
• kuidas korraldada ja kehtestada reegleid nendega andmete vahetamiseks;
• kuidas jälgida ja hankida teavet nende seisundi kohta Internetis;
• kuidas edastada andmeid üheaegselt oma seadmete rühma;
• kuidas saata andmeid üheaegselt ühest seadmest mitmele kliendile;
• kuidas saada ühtne juurdepääs täiendavatele operaatoriteenustele oma seadme haldamiseks.

Nende lahendamiseks on vaja luua patenteeritud tehniliselt “rasked” lahendused, mis toob kaasa tööjõukulude ja teenuste turuletuleku aja suurenemise. Siin tuleb appi uus SCEF-i sõlm.

3GPP definitsiooni kohaselt on SCEF (service Capability Exposition Function) 3GPP arhitektuuri täiesti uus komponent, mille ülesanne on turvaliselt avalikustada 3GPP võrguliideste pakutavad teenused ja võimalused API-de kaudu.

Lihtsamalt öeldes on SCEF vahendaja võrgu ja rakendusserveri (AS) vahel, üks aken juurdepääsuks operaatoriteenustele, et hallata teie M2M-seadet NB-IoT võrgus läbi intuitiivse standardiseeritud API liidese.

SCEF varjab operaatori võrgu keerukust, võimaldades rakenduste arendajatel seadmetega suhtlemiseks keerukatest seadmespetsiifilistest mehhanismidest välja võtta.

Muutes võrguprotokollid rakenduste arendajatele tuttavaks API-ks, hõlbustab SCEF-i API uute teenuste loomist ja vähendab turuletuleku aega. Uus sõlm sisaldab ka mobiilsete seadmete tuvastamise/autentimise funktsioone, seadme ja AS-i vahelise andmevahetuse reeglite määratlemist, eemaldab vajaduse rakenduste arendajatel neid funktsioone enda poolel juurutada, nihutab need funktsioonid operaatori õlule.

SCEF hõlmab liideseid, mis on vajalikud rakendusserverite autentimiseks ja autoriseerimiseks, UE mobiilsuse säilitamiseks, andmeedastuseks ja seadmete käivitamiseks, juurdepääsuks lisateenustele ja operaatori võrgu võimalustele.

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

T6a – liides SCEF-i ja MME vahel. Kasutatakse mobiilsuse/seansi haldamise protseduuride jaoks, mitte-IP-andmete edastamiseks, seiresündmuste varustamiseks ja nende kohta aruannete vastuvõtmiseks.

S6t – liides SCEF-i ja HSS-i vahel. Vajalik abonendi autentimiseks, rakendusserverite autoriseerimiseks, välise ID ja IMSI/MSISDN-i kombinatsiooni hankimiseks, jälgimissündmuste varustamiseks ja nende kohta aruannete vastuvõtmiseks.

S6m/T4 – liidesed SCEF-ist HSS-ile ja SMS-C-le (3GPP defineerib MTC-IWF sõlme, mida kasutatakse seadmete käivitamiseks ja SMS-ide edastamiseks NB-IoT võrkudes. Samas on kõigis rakendustes selle sõlme funktsionaalsus integreeritud SCEF, nii et vooluringi lihtsustamiseks me seda eraldi ei käsitle). Kasutatakse marsruutimisteabe hankimiseks SMS-ide saatmiseks ja SMS-keskusega suhtlemiseks.

T8 – API liides SCEF-i interaktsiooniks rakendusserveritega. Selle liidese kaudu edastatakse nii juhtkäsud kui ka liiklus.

*tegelikkuses on liideseid rohkem, siin on loetletud vaid kõige elementaarsemad. Täielik nimekiri on esitatud dokumendis 3GPP 23.682 (4.3.2 Võrdluspunktide loend).

Allpool on toodud SCEF-i põhifunktsioonid ja teenused:

• SIM-kaardi identifikaatori (IMSI) sidumine välise ID-ga;
• mitte-IP-liikluse edastamine (Non-IP Data Delivery, NIDD);
• rühmatoimingud välise grupi ID-ga;
• andmeedastusrežiimi tugi koos kinnitusega;
• MO (Mobile Originated) ja MT (Mobile Terminated) andmete puhverdamine;
• seadmete ja rakendusserverite autentimine ja autoriseerimine;
• ühe kasutajaseadme andmete samaaegne kasutamine mitme AS-i poolt;
• UE oleku jälgimise erifunktsioonide tugi (MONTE – Monitoring Events);
• seadme käivitamine;
• mitte-IP andmerändluse pakkumine.

AS-i ja SCEF-i interaktsiooni aluspõhimõte põhineb nn skeemil. tellimused. Kui konkreetse kasutajaseadme jaoks on vaja juurdepääsu mis tahes SCEF-teenusele, peab rakendusserver looma tellimuse, saates käsu soovitud teenuse konkreetsele API-le ja saama vastuseks kordumatu identifikaatori. Pärast seda toimuvad selle teenuse raames kõik edasised toimingud ja suhtlus kasutajaseadmega seda identifikaatorit kasutades.

Väline ID: universaalne seadme identifikaator

Üks olulisemaid muudatusi AS-i ja seadmete interaktsiooniskeemis SCEF-i kaudu töötamisel on universaalse identifikaatori ilmumine. Nüüd saab telefoninumbri (MSISDN) või IP-aadressi asemel, nagu see oli klassikalises 2G/3G/LTE võrgus, rakendusserveri seadme identifikaatoriks "väline ID". See on standardiga määratletud vormingus, mis on rakenduste arendajatele tuttav " @ "

Arendajad ei pea enam seadmete autentimisalgoritme rakendama, võrk võtab selle funktsiooni täielikult üle. Väline ID on seotud IMSI-ga ja arendaja võib olla kindel, et konkreetsele välisele ID-le ligi pääsedes suhtleb see konkreetse SIM-kaardiga. SIM-kiipi kasutades tekib täiesti unikaalne olukord, kui väline ID tuvastab üheselt konkreetse seadme!

Veelgi enam, ühe IMSI-ga saab siduda mitu välist ID-d – veelgi huvitavam olukord tekib siis, kui väline ID tuvastab unikaalselt konkreetse rakenduse, mis vastutab konkreetse teenuse eest konkreetses seadmes.

Ilmub ka rühma identifikaator - väline grupi ID, mis sisaldab individuaalsete väliste ID-de komplekti. Nüüd saab AS ühe päringuga SCEF-ile algatada rühmatoiminguid – saata andmeid või juhtkäske mitmele seadmele, mis on ühendatud ühte loogilisse rühma.

Kuna AS-i arendajate jaoks ei saa üleminek uuele seadme identifikaatorile olla hetkeline, jättis SCEF võimaluse AS-iga UE-ga suhelda standardnumbri - MSISDN-i kaudu.

Mitte-IP-liikluse edastamine (Non-IP Data Delivery, NIDD)

NB-IoT-s on väikeste andmemahtude edastamise mehhanismide optimeerimise osana lisaks juba olemasolevatele PDN-tüüpidele, nagu IPv4, IPv6 ja IPv4v6, ilmunud veel üks tüüp - mitte-IP. Sellisel juhul ei määrata seadmele (UE) IP-aadressi ja andmed edastatakse ilma IP-protokolli kasutamata. Selliste ühenduste liiklust saab suunata kahel viisil: klassikaline - MME -> SGW -> PGW ja seejärel läbi PtP tunneli AS-i (joonis 2) või kasutades SCEF-i (joonis 3).

Klassikaline meetod ei paku IP-liikluse ees erilisi eeliseid, välja arvatud edastatavate pakettide suuruse vähendamine IP-päiste puudumise tõttu. SCEF-i kasutamine avab mitmeid uusi võimalusi ja lihtsustab oluliselt seadmetega suhtlemise protseduure.

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


MT liikluse edastamine seadmesse välise ID kaudu

Klassikalisele IP-seadmele sõnumi saatmiseks peab AS teadma oma IP-aadressi. Siin tekib probleem: kuna seade saab registreerimisel tavaliselt “halli” IP-aadressi, suhtleb ta Internetis asuva rakendusserveriga NAT-sõlme kaudu, kus hall aadress tõlgitakse valgeks. Halli ja valge IP-aadressi kombinatsioon kestab sõltuvalt NAT-i sätetest piiratud aja. Keskmiselt TCP või UDP puhul - mitte rohkem kui viis minutit. See tähendab, et kui selle seadmega 5 minuti jooksul andmevahetust ei toimu, katkeb ühendus ja seade ei ole enam juurdepääsetav sellel valgel aadressil, millega seanss AS-iga algatati. Lahendusi on mitu:

1. Kasutage südamelööke. Kui ühendus on loodud, peab seade vahetama pakette AS-iga iga paari minuti järel, vältides sellega NAT-i tõlgete sulgemist. Aga mingist energiatõhususest ei saa siin juttugi olla.

2. Iga kord, kui vaja, kontrolli seadme pakettide saadavust AS-is – saada teade üleslingile.

3. Looge privaatne APN (VRF), kus rakendusserver ja seadmed asuvad samas alamvõrgus, ning määrake seadmetele staatilised IP-aadressid. See toimib, kuid see on peaaegu võimatu, kui räägime tuhandetest, kümnetest tuhandetest seadmetest koosnevast laevastikust.

4. Lõpuks kõige sobivam variant: kasuta IPv6, see ei nõua NAT-i, kuna IPv6 aadressid on Internetist otse ligipääsetavad. Kuid ka sel juhul saab seade uuesti registreerides uue IPv6-aadressi ja eelmist kasutades enam ligi ei pääse.

Sellest lähtuvalt on seadme uue IP-aadressi edastamiseks vaja saata serverisse mõni lähtestamispakett koos seadme identifikaatoriga. Seejärel oota ASilt kinnituspaketti, mis mõjutab ka energiatõhusust.

Need meetodid töötavad hästi 2G/3G/LTE seadmete puhul, kus seadmel ei ole rangeid autonoomianõudeid ning sellest tulenevalt puuduvad piirangud eetriajale ja liiklusele. Need meetodid ei sobi NB-IoT jaoks oma suure energiatarbimise tõttu.

SCEF lahendab selle probleemi: kuna AS-i ainus seadme identifikaator on väline ID, peab AS saatma SCEF-ile ainult konkreetse välise ID jaoks andmepaketi ja SCEF hoolitseb ülejäänu eest. Kui seade on PSM- või eDRX-i energiasäästurežiimis, siis andmed puhverdatakse ja edastatakse, kui seade on saadaval. Kui seade on liikluseks saadaval, toimetatakse andmed kohe kohale. Sama kehtib ka juhtimismeeskondade kohta.

AS võib igal ajal puhverdatud sõnumi kasutajaseadmesse tagasi kutsuda või selle uuega asendada.

Puhverdusmehhanismi saab kasutada ka MO andmete edastamisel UE-st AS-i. Kui SCEF-il ei õnnestunud andmeid kohe AS-ile edastada, näiteks kui AS-i serverites on käimas hooldustööd, puhverdatakse need paketid ja tagatakse, et need edastatakse niipea, kui AS on saadaval.

Nagu eespool märgitud, reguleerivad AS-i (ja NIDD on teenus) juurdepääsu konkreetsele teenusele ja kasutajakeskkonnale SCEF-i poolel kehtivad reeglid ja poliitikad, mis võimaldab ainulaadse võimaluse ühe kasutajaseadme andmete samaaegseks kasutamiseks mitmel AS-il. Need. kui mitu AS-i on tellinud ühe UE, siis pärast UE-lt andmete saamist saadab SCEF need kõigile tellitud AS-idele. See sobib hästi juhtudel, kui spetsialiseeritud seadmete pargi looja jagab andmeid mitme kliendi vahel. Näiteks luues NB-IoT-l töötavate ilmajaamade võrgu, saate müüa nende andmeid korraga paljudele teenustele.

Garanteeritud sõnumi edastamise mehhanism

Usaldusväärne andmeteenus on mehhanism MO- ja MT-sõnumite garanteeritud kohaletoimetamiseks ilma protokollitasemel spetsiaalseid algoritme kasutamata, näiteks TCP-s käepigistust. See toimib, lisades sõnumi teenindusosasse spetsiaalse lipu, kui seda vahetatakse UE ja SCEF-i vahel. Kas seda mehhanismi liikluse edastamisel aktiveerida või mitte, otsustab AS.

Kui mehhanism on aktiveeritud, lisab UE paketi üldosas spetsiaalse lipu, kui see nõuab MO-liikluse garanteeritud edastamist. Sellise paketi vastuvõtmisel vastab SCEF kasutajaseadmele UE kinnitusega. Kui kasutajaseade ei saa kinnituspaketti, saadetakse pakett SCEF-i poole uuesti. Sama juhtub MT liiklusega.

Seadme jälgimine (sündmuste jälgimine – MONTE)

Nagu eelpool mainitud, sisaldab SCEF-i funktsionaalsus muuhulgas ka UE oleku jälgimise funktsioone, nn. seadme jälgimine. Ja kui uued identifikaatorid ja andmeedastusmehhanismid on olemasolevate protseduuride optimeerimised (ehkki väga tõsised), siis MONTE on täiesti uus funktsionaalsus, mida 2G/3G/LTE võrkudes pole. MONTE võimaldab AS-il jälgida seadme parameetreid, nagu ühenduse olek, side kättesaadavus, asukoht, rändluse olek jne. Räägime igaühest üksikasjalikumalt veidi hiljem.

Kui seadme või seadmete rühma jaoks on vaja aktiveerida mõni jälgimissündmus, tellib AS vastava teenuse, saates SCEF-ile vastava API MONTE käsu, mis sisaldab parameetreid nagu väline ID või väline grupi ID, AS-i identifikaator, monitooring. tüüp, aruannete arv, mida AS saada soovib. Kui AS on volitatud päringut täitma, varustab SCEF olenevalt tüübist sündmuse HSS-ile või MME-le (joonis 4). Sündmuse korral genereerib MME või HSS aruande SCEF-ile, mis saadab selle AS-ile.

Kõik sündmused, välja arvatud „geograafilises piirkonnas olevate kasutajaseadmete arv”, toimub HSS-i kaudu. Kahte sündmust „IMSI-IMEI ühenduse muutmine” ja „Rändluse olek” jälgitakse otse HSS-is, ülejäänud varustab HSS MME-s.
Sündmused võivad olla kas ühekordsed või perioodilised ning need määratakse nende tüübi järgi.

Sündmuse kohta aruande (aruandluse) saatmise teostab sõlm, mis jälgib sündmust otse SCEF-ile (joonis 5).

Oluline punkt: Seiresündmusi saab rakendada nii mitte-IP-seadmetele, mis on ühendatud SCEF-i kaudu, kui ka IP-seadmetele, mis edastavad andmeid klassikalisel viisil MME-SGW-PGW kaudu.

Vaatame lähemalt kõiki seiresündmusi:

Ühenduse kaotus — teavitab AS-i, et kasutajaseade ei ole enam andmeliikluse ega signaalimise jaoks saadaval. Sündmus leiab aset siis, kui MME-s MME-s aegub UE „mobiilse ligipääsetavuse taimer”. Seda tüüpi seire päringus saab AS näidata oma "Maksimaalse tuvastamisaja" väärtust – kui selle aja jooksul kasutajaseade ei näita mingit tegevust, teavitatakse AS-i, et kasutajaseade ei ole saadaval, näidates ära põhjuse. Sündmus leiab aset ka siis, kui UE eemaldas võrk mingil põhjusel sunniviisiliselt.

* Andmaks võrgule teada, et seade on endiselt saadaval, käivitab see perioodiliselt värskendusprotseduuri – Tracking Area Update (TAU). Selle protseduuri sageduse määrab võrk taimeri T3412 või (PSM puhul T3412_extended) abil, mille väärtus edastatakse seadmele Attach protseduuri või järgmise TAU ajal. Mobiiliga saadavuse taimer on tavaliselt mitu minutit pikem kui T3412. Kui kasutajaseade ei ole teinud TAU-d enne „Mobiilse kättesaadavuse taimeri” aegumist, loeb võrk seda enam kättesaamatuks.

UE juurdepääsetavus – Näitab, millal UE muutub DL-liikluse või SMS-ide jaoks kättesaadavaks. See ilmneb siis, kui kasutajaseade muutub otsinguks kättesaadavaks (eDRX-režiimis UE puhul) või kui UE siseneb režiimi ECM-CONNECTED (PSM- või eDRX-režiimis UE puhul), st. teeb TAU või saadab üleslingi paketi.

Asukohateavitus – Seda tüüpi seiresündmused võimaldavad AS-il küsida kasutajaseadme asukohta. Taotleda saab kas praegust asukohta (praegune asukoht) või viimast teadaolevat asukohta (viimane teadaolev asukoht, mille määrab kärje ID, kust seade viimati TAU-d tegi või liiklust edastas), mis on asjakohane PSM-i või eDRX-i energiasäästu seadmete puhul. režiimid. Praeguse asukoha puhul saab AS taotleda korduvaid vastuseid, kusjuures MME teavitab AS-i iga kord, kui seadme asukoht muutub.

IMSI-IMEI ühenduse muutus – Kui see sündmus on aktiveeritud, hakkab SCEF jälgima muutusi IMSI (SIM-kaardi identifikaator) ja IMEI (seadme identifikaator) kombinatsioonis. Sündmuse toimumisest teavitab AS-i. Saab kasutada välise ID automaatseks uuesti sidumiseks seadmega planeeritud asendustööde ajal või kasutada seadme varguse identifikaatorina.

Rändluse olek – AS kasutab seda tüüpi jälgimist, et teha kindlaks, kas kasutajaseade on koduvõrgus või rändluspartneri võrgus. Soovi korral saab edastada selle operaatori PLMN-i (Public Land Mobile Network), kus seade on registreeritud.

Suhtlemisviga — Seda tüüpi seire teavitab AS-i sideühenduse tõrgetest seadmega, tuginedes raadiopöördusvõrgust (S1-AP protokoll) saadud ühenduse katkemise põhjustele (vabastuse põhjuse kood). See sündmus võib aidata kindlaks teha, miks side ebaõnnestus – võrguprobleemide tõttu, näiteks kui eNodeb on ülekoormatud (raadioressursid pole saadaval) või seadme enda tõrke tõttu (raadioühendus seadmega UE Lost).

Kättesaadavus pärast DDN-i tõrget – see sündmus teavitab AS-i, et seade on muutunud kättesaadavaks pärast sidetõrget. Saab kasutada, kui on vaja andmeid seadmesse üle kanda, kuid eelmine katse ei õnnestunud, kuna UE ei vastanud võrgu teatele (otsimine) ja andmeid ei edastatud. Kui kasutajaseadme jaoks on seda tüüpi jälgimist taotletud, siis niipea, kui seade loob sissetuleva side, teeb TAU või saadab andmeid üleslingile, teavitatakse AS-i, et seade on muutunud kättesaadavaks. Kuna DDN (allalingi andmeteatise) protseduur töötab MME ja S/P-GW vahel, on seda tüüpi jälgimine saadaval ainult IP-seadmete jaoks.

PDN-ühenduvuse olek – teavitab AS-i, kui seadme olek muutub (PDN-ühenduvuse olek) – ühendamine (PDN-i aktiveerimine) või ühenduse katkemine (PDN-i kustutamine). Seda saab AS kasutada kasutajaseadmega side algatamiseks või vastupidi, et mõista, et side pole enam võimalik. Seda tüüpi seire on saadaval IP- ja mitte-IP-seadmete jaoks.

Geograafilises piirkonnas olevate kasutajaseadmete arv – AS kasutab seda tüüpi jälgimist kasutajaseadmete arvu määramiseks teatud geograafilises piirkonnas.

Seadme käivitamine)

2G/3G võrkudes oli võrgus registreerimisprotseduur kaheetapiline: esiteks registreeriti seade SGSN-iga (attach procedura), seejärel aktiveeris vajadusel PDP konteksti – ühenduse pakettlüüsiga (GGSN) andmete edastamiseks. 3G võrkudes toimusid need kaks protseduuri järjest, s.t. seade ei oodanud hetke, mil tal oli vaja andmeid edastada, vaid aktiveeris PDP kohe pärast manustamisprotseduuri lõpetamist. LTE-s ühendati need kaks protseduuri üheks, st ühendamisel taotles seade kohe PDN-ühenduse aktiveerimist (analoogselt PDP-ga 2G/3G-s) eNodeB kaudu MME-SGW-PGW-le.

NB-IoT defineerib ühendusmeetodit kui "ühendamist ilma PDN-ita", see tähendab, et kasutajaseade ühendatakse ilma PDN-ühendust loomata. Sel juhul pole see liikluse edastamiseks saadaval ja saab ainult SMS-e vastu võtta või saata. Selleks, et saata sellisele seadmele käsk PDN-i aktiveerimiseks ja AS-iga ühenduse loomiseks, töötati välja funktsioon "Seadme käivitamine".

Saades AS-ilt sellise UE ühendamise käsu, algatab SCEF SMS-i keskuse kaudu seadmele kontroll-SMS-i saatmise. SMS-i vastuvõtmisel aktiveerib seade PDN-i ja loob ühenduse AS-iga, et saada täiendavaid juhiseid või edastada andmeid.

Mõnikord võib teie seadme tellimus SCEF-is aeguda. Jah, abonemendil on oma eluiga, selle määrab operaator või on AS-iga kokku lepitud. Aegumisel PDN deaktiveeritakse MME-s ja seade muutub AS-i jaoks kättesaamatuks. Sel juhul aitab ka funktsioon "Seadme käivitamine". AS-ilt uute andmete saamisel selgitab SCEF välja seadme ühenduse oleku ja edastab andmed SMS-kanali kaudu.

Järeldus

SCEF-i funktsionaalsus ei piirdu muidugi ülalkirjeldatud teenustega ning see areneb ja laieneb pidevalt. Praegu on SCEF-i jaoks standarditud juba üle tosina teenuse. Nüüd oleme puudutanud ainult peamisi funktsioone, mida arendajad nõuavad, ülejäänutest räägime tulevastes artiklites.

Koheselt tekib küsimus: kuidas saada sellele "ime" sõlmele testjuurdepääs võimalike juhtumite eeltestimiseks ja silumiseks? See kõik on väga lihtne. Iga arendaja saab saata päringu aadressile iot.info@mts.ru, milles piisab ühenduse eesmärgi, võimaliku juhtumi kirjelduse ja suhtluskontaktide märkimisest.

Järgmise korrani!

Autorid:

• Konvergentsete lahenduste ja multimeediateenuste osakonna vanemekspert Sergei Novikov sanov,
• konvergentsete lahenduste ja multimeediateenuste osakonna ekspert Aleksei Lapšin aslapsh

Allikas: www.habr.com