Rakstā “", runājot par NB-IoT tīkla pakešu kodola arhitektūru, mēs pieminējām jauna SCEF mezgla parādīšanos. Trešajā daļā paskaidrojam, kas tas ir un kāpēc tas ir vajadzīgs?
Veidojot M2M pakalpojumu, lietojumprogrammu izstrādātāji saskaras ar šādiem jautājumiem:
- kā atpazīt ierīces;
- kādu verifikācijas un autentifikācijas algoritmu izmantot;
- kādu transporta protokolu izvēlēties mijiedarbībai ar ierīcēm;
- kā droši piegādāt datus ierīcēm;
- kā organizēt un izveidot noteikumus datu apmaiņai ar viņiem;
- kā uzraudzīt un iegūt informāciju par viņu stāvokli tiešsaistē;
- kā vienlaicīgi piegādāt datus jūsu ierīču grupai;
- kā vienlaicīgi nosūtīt datus no vienas ierīces vairākiem klientiem;
- kā iegūt vienotu piekļuvi papildu operatora pakalpojumiem ierīces pārvaldīšanai.
Lai tos atrisinātu, ir jārada patentēti tehniski “smagie” risinājumi, kas palielina darbaspēka izmaksas un pakalpojumu nonākšanas tirgū laiku. Šeit palīgā nāk jaunais SCEF mezgls.
Kā definējis 3GPP, SCEF (pakalpojuma iespēju ekspozīcijas funkcija) ir pilnīgi jauns 3GPP arhitektūras komponents, kura funkcija ir droši atklāt pakalpojumus un iespējas, ko nodrošina 3GPP tīkla saskarnes, izmantojot API.
Vienkāršiem vārdiem sakot, SCEF ir starpnieks starp tīklu un lietojumprogrammu serveri (AS), kas ir viens piekļuves logs operatora pakalpojumiem, lai pārvaldītu jūsu M2M ierīci NB-IoT tīklā, izmantojot intuitīvu, standartizētu API saskarni.
SCEF slēpj operatora tīkla sarežģītību, ļaujot lietojumprogrammu izstrādātājiem abstrahēt sarežģītus, ierīcei raksturīgus mehānismus mijiedarbībai ar ierīcēm.
Pārveidojot tīkla protokolus par lietojumprogrammu izstrādātājiem pazīstamu API, SCEF API atvieglo jaunu pakalpojumu izveidi un samazina laiku, kas nepieciešams, lai tie nonāktu tirgū. Jaunajā mezglā ir iekļautas arī mobilo ierīču identifikācijas/autentifikācijas funkcijas, datu apmaiņas noteikumu definēšana starp ierīci un AS, novēršot nepieciešamību lietojumprogrammu izstrādātājiem šīs funkcijas ieviest savā pusē, pārceļot šīs funkcijas uz operatora pleciem.
SCEF aptver saskarnes, kas nepieciešamas lietojumprogrammu serveru autentifikācijai un autorizācijai, UE mobilitātes uzturēšanai, datu pārsūtīšanai un ierīču iedarbināšanai, piekļuvei papildu pakalpojumiem un operatora tīkla iespējām.
Uz AS ir viens T8 interfeiss — API (HTTP/JSON), ko standartizē 3GPP. Visas saskarnes, izņemot T8, darbojas, pamatojoties uz DIAMETER protokolu (1. att.).
T6a – saskarne starp SCEF un MME. Izmanto mobilitātes/sesijas pārvaldības procedūrām, ne-IP datu pārraidei, monitoringa notikumu nodrošināšanai un atskaišu saņemšanai par tiem.
S6t – saskarne starp SCEF un HSS. Nepieciešams abonentu autentifikācijai, lietojumprogrammu serveru autorizācijai, ārējā ID un IMSI/MSISDN kombinācijas iegūšanai, uzraudzības notikumu nodrošināšanai un atskaišu saņemšanai par tiem.
S6m/T4 – saskarnes no SCEF uz HSS un SMS-C (3GPP definē MTC-IWF mezglu, kas tiek izmantots ierīču iedarbināšanai un SMS pārraidei NB-IoT tīklos. Taču visās implementācijās šī mezgla funkcionalitāte ir integrēta SCEF, tāpēc ķēdes vienkāršošanai mēs to neapskatīsim atsevišķi). Izmanto, lai iegūtu maršrutēšanas informāciju SMS sūtīšanai un mijiedarbībai ar SMS centru.
T8 – API saskarne SCEF mijiedarbībai ar lietojumprogrammu serveriem. Caur šo saskarni tiek pārraidītas gan vadības komandas, gan satiksme.
*Patiesībā ir vairāk saskarņu; šeit ir uzskaitītas tikai visvienkāršākās. Pilns saraksts ir sniegts 3GPP 23.682 (4.3.2. Atsauces punktu saraksts).
Tālāk ir norādītas SCEF galvenās funkcijas un pakalpojumi:
- SIM kartes identifikatora (IMSI) saistīšana ar ārējo ID;
- ne-IP trafika pārraide (Non-IP Data Delivery, NIDD);
- grupas operācijas, izmantojot ārējo grupas ID;
- atbalsts datu pārraides režīmam ar apstiprinājumu;
- MO (Mobile Originated) un MT (Mobile Terminated) datu buferizācija;
- ierīču un lietojumprogrammu serveru autentifikācija un autorizācija;
- vienas UE datu vienlaicīga izmantošana vairākās AS;
- atbalsts īpašām UE statusa uzraudzības funkcijām (MONTE – Monitoring Events);
- ierīces iedarbināšana;
- ne-IP datu viesabonēšanas nodrošināšana.
AS un SCEF mijiedarbības pamatprincips balstās uz tā saukto shēmu. abonementi. Ja ir nepieciešams piekļūt jebkuram SCEF pakalpojumam konkrētai UE, lietojumprogrammu serverim ir jāizveido abonements, nosūtot komandu uz konkrētu pieprasītā pakalpojuma API, un atbildē jāsaņem unikāls identifikators. Pēc tam visas turpmākās darbības un saziņa ar UE šī pakalpojuma ietvaros notiks, izmantojot šo identifikatoru.
Ārējais ID: universāls ierīces identifikators
Viena no svarīgākajām izmaiņām AS un ierīču mijiedarbības shēmā, strādājot ar SCEF, ir universāla identifikatora parādīšanās. Tagad tālruņa numura (MSISDN) vai IP adreses vietā, kā tas bija klasiskajā 2G/3G/LTE tīklā, lietojumprogrammu servera ierīces identifikators kļūst par “ārējo ID”. Tas ir definēts ar standartu formātā, kas pazīstams lietojumprogrammu izstrādātājiem. @ "
Izstrādātājiem vairs nav jāievieš ierīces autentifikācijas algoritmi; tīkls pilnībā pārņem šo funkciju. Ārējais ID ir saistīts ar IMSI, un izstrādātājs var būt pārliecināts, ka, piekļūstot konkrētam ārējam ID, tas mijiedarbojas ar konkrētu SIM karti. Izmantojot SIM mikroshēmu, jūs iegūstat pilnīgi unikālu situāciju, kad ārējais ID unikāli identificē konkrētu ierīci!
Turklāt vienam IMSI var piesaistīt vairākus ārējos ID – vēl interesantāka situācija rodas, ja ārējais ID unikāli identificē konkrētu aplikāciju, kas ir atbildīga par konkrētu pakalpojumu konkrētā ierīcē.
Parādās arī grupas identifikators - ārējās grupas ID, kas ietver atsevišķu ārējo ID kopu. Tagad ar vienu pieprasījumu SCEF AS var uzsākt grupas darbības - datu vai vadības komandu nosūtīšanu uz vairākām ierīcēm, kas apvienotas vienā loģiskā grupā.
Sakarā ar to, ka AS izstrādātājiem pāreja uz jaunu ierīces identifikatoru nevar notikt acumirklī, SCEF atstāja iespēju AS sazināties ar UE, izmantojot standarta numuru - MSISDN.
Datplūsmas, kas nav IP datplūsma, pārraide (Datu piegāde bez IP — NIDD)
NB-IoT ietvaros, optimizējot neliela apjoma datu pārsūtīšanas mehānismus, papildus jau esošajiem PDN veidiem, piemēram, IPv4, IPv6 un IPv4v6, ir parādījies vēl viens veids - ne-IP. Šajā gadījumā ierīcei (UE) netiek piešķirta IP adrese un dati tiek pārsūtīti, neizmantojot IP protokolu. Satiksmi šādiem savienojumiem var novirzīt divos veidos: klasiskais - MME -> SGW -> PGW un tad caur PtP tuneli uz AS (2. att.) vai izmantojot SCEF (3. att.).
Klasiskā metode nepiedāvā nekādas īpašas priekšrocības salīdzinājumā ar IP trafiku, izņemot pārsūtīto pakešu lieluma samazināšanu IP galvenes trūkuma dēļ. SCEF izmantošana paver vairākas jaunas iespējas un ievērojami vienkāršo procedūras mijiedarbībai ar ierīcēm.
Pārsūtot datus, izmantojot SCEF, parādās divas ļoti svarīgas priekšrocības salīdzinājumā ar klasisko IP trafiku:
MT trafika piegāde uz ierīci, izmantojot ārējo ID
Lai nosūtītu ziņojumu uz klasisko IP ierīci, AS ir jāzina tās IP adrese. Šeit rodas problēma: tā kā ierīce reģistrējoties parasti saņem “pelēko” IP adresi, tā sazinās ar lietojumprogrammu serveri, kas atrodas internetā, izmantojot NAT mezglu, kur pelēkā adrese tiek pārtulkota baltā krāsā. Pelēko un balto IP adrešu kombinācija darbojas ierobežotu laiku atkarībā no NAT iestatījumiem. Vidēji TCP vai UDP - ne vairāk kā piecas minūtes. Tas ir, ja 5 minūšu laikā nenotiks datu apmaiņa ar šo ierīci, savienojums pārtrūks un ierīce vairs nebūs pieejama baltajā adresē, ar kuru tika uzsākta sesija ar AS. Ir vairāki risinājumi:
1. Izmantojiet sirdsdarbību. Kad savienojums ir izveidots, ierīcei ik pēc dažām minūtēm ir jāapmainās ar paketēm ar AS, tādējādi novēršot NAT tulkojumu slēgšanu. Bet par energoefektivitāti te nevar būt ne runas.
2. Katru reizi, ja nepieciešams, pārbaudiet pakotņu pieejamību ierīcei AS - nosūtiet ziņojumu uz augšupsaiti.
3. Izveidojiet privātu APN (VRF), kur lietojumprogrammu serveris un ierīces atradīsies vienā apakštīklā, un piešķiriet ierīcēm statiskas IP adreses. Tas darbosies, bet tas ir gandrīz neiespējami, ja mēs runājam par tūkstošiem, desmitiem tūkstošu ierīču parku.
4. Visbeidzot, vispiemērotākais variants: izmantojiet IPv6, tam nav nepieciešams NAT, jo IPv6 adreses ir tieši pieejamas no interneta. Taču arī šajā gadījumā, pārreģistrējot ierīci, tā saņems jaunu IPv6 adresi un vairs nebūs pieejama, izmantojot iepriekšējo.
Attiecīgi serverim ir jānosūta kāda inicializācijas pakete ar ierīces identifikatoru, lai ziņotu par ierīces jauno IP adresi. Pēc tam gaidiet apstiprinājuma paketi no AS, kas arī ietekmē energoefektivitāti.
Šīs metodes labi darbojas 2G/3G/LTE ierīcēm, kur ierīcei nav stingras prasības autonomijai un līdz ar to nav ētera laika un satiksmes ierobežojumu. Šīs metodes nav piemērotas NB-IoT to lielā enerģijas patēriņa dēļ.
SCEF atrisina šo problēmu: tā kā AS vienīgais ierīces identifikators ir ārējais ID, AS ir jānosūta tikai datu pakete SCEF noteiktam ārējam ID, un SCEF rūpējas par pārējo. Ja ierīce ir PSM vai eDRX enerģijas taupīšanas režīmā, dati tiks buferizēti un piegādāti, kad ierīce būs pieejama. Ja ierīce ir pieejama satiksmei, dati tiks piegādāti nekavējoties. Tas pats attiecas uz vadības komandām.
AS var jebkurā laikā atsaukt buferizēto ziņojumu UE vai aizstāt to ar jaunu.
Buferizācijas mehānismu var izmantot arī, pārsūtot MO datus no UE uz AS. Ja SCEF nevarēja nekavējoties piegādāt datus AS, piemēram, ja AS serveros notiek apkopes darbi, šīs paketes tiks saglabātas buferšķīdumā un tiek garantētas, ka tās tiks piegādātas, tiklīdz AS būs pieejama.
Kā minēts iepriekš, piekļuvi noteiktam pakalpojumam un UE AS (un NIDD ir pakalpojums) regulē noteikumi un politikas SCEF pusē, kas nodrošina unikālu iespēju vairākām AS vienlaicīgi izmantot datus no vienas UE. Tie. ja vienu UE ir abonējušas vairākas AS, tad pēc datu saņemšanas no UE SCEF tos nosūtīs visām abonētajām AS. Tas ir labi piemērots gadījumiem, kad specializēto ierīču parka veidotājs koplieto datus starp vairākiem klientiem. Piemēram, izveidojot laikapstākļu staciju tīklu, kas darbojas, izmantojot NB-IoT, varat vienlaikus pārdot datus no tiem daudziem pakalpojumiem.
Garantēts ziņojumu piegādes mehānisms
Reliable Data Service ir mehānisms garantētai MO un MT ziņojumu piegādei, neizmantojot specializētus algoritmus protokola līmenī, piemēram, rokasspiedienu TCP. Tas darbojas, ziņojuma pakalpojuma daļā iekļaujot īpašu karogu, kad notiek apmaiņa starp UE un SCEF. To, vai aktivizēt šo mehānismu, pārraidot trafiku, izlemj AS.
Ja mehānisms ir aktivizēts, UE iekļauj īpašu karogu paketes augšējā daļā, kad tas prasa garantētu MO trafika piegādi. Saņemot šādu paketi, SCEF atbild UE ar apstiprinājumu. Ja UE nesaņem apstiprinājuma paketi, pakete uz SCEF tiks nosūtīta atkārtoti. Tas pats notiek ar MT satiksmi.
Ierīces uzraudzība (notikumu pārraudzība — MONTE)
Kā minēts iepriekš, SCEF funkcionalitāte, cita starpā, ietver funkcijas UE stāvokļa uzraudzībai, ts. ierīces uzraudzība. Un, ja jauni identifikatori un datu pārsūtīšanas mehānismi ir esošo procedūru optimizācija (kaut arī ļoti nopietna), tad MONTE ir pilnīgi jauna funkcionalitāte, kas nav pieejama 2G/3G/LTE tīklos. MONTE ļauj AS pārraudzīt tādus ierīces parametrus kā savienojuma statuss, sakaru pieejamība, atrašanās vieta, viesabonēšanas statuss utt. Par katru sīkāk runāsim nedaudz vēlāk.
Ja ir nepieciešams aktivizēt kādu ierīces vai ierīču grupas uzraudzības notikumu, AS abonē atbilstošo pakalpojumu, nosūtot SCEF atbilstošo API MONTE komandu, kas ietver tādus parametrus kā ārējais ID vai ārējās grupas ID, AS identifikators, monitorings. veids, atskaišu skaits, ko AS vēlas saņemt. Ja AS ir pilnvarota izpildīt pieprasījumu, SCEF atkarībā no veida nodrošinās notikumu HSS vai MME (4. attēls). Kad notiek notikums, MME vai HSS ģenerē ziņojumu SCEF, kas to nosūta AS.
Visu notikumu nodrošināšana, izņemot “Ģeogrāfiskā apgabalā esošo UE skaitu”, tiek nodrošināta, izmantojot HSS. Divi notikumi “IMSI-IMEI asociācijas maiņa” un “Viesabonēšanas statuss” tiek izsekoti tieši HSS, pārējos HSS nodrošinās MME.
Notikumi var būt vienreizēji vai periodiski, un tos nosaka to veids.
Ziņojuma nosūtīšanu par notikumu (ziņošanu) veic mezgls, kas izseko notikumu tieši uz SCEF (5. att.).
Svarīgs punkts: Monitoringa notikumus var piemērot gan ierīcēm, kas nav IP savienotas, izmantojot SCEF, gan IP ierīcēm, kas pārsūta datus klasiskā veidā, izmantojot MME-SGW-PGW.
Apskatīsim sīkāk katru no uzraudzības pasākumiem:
Savienojuma zudums — informē AS, ka UE vairs nav pieejama ne datu plūsmai, ne signalizācijai. Notikums notiek, kad UE “mobilās sasniedzamības taimeris” beidzas MME. Pieprasījumā šāda veida uzraudzībai AS var norādīt savu “Maksimālā noteikšanas laika” vērtību – ja šajā laikā UE neuzrāda nekādu darbību, AS tiks informēta, ka UE nav pieejama, norādot iemeslu. Notikums notiek arī tad, ja tīkls kāda iemesla dēļ ir piespiedu kārtā noņēmis UE.
* Lai tīkls zinātu, ka ierīce joprojām ir pieejama, tā periodiski uzsāk atjaunināšanas procedūru - Tracking Area Update (TAU). Šīs procedūras biežumu tīkls nosaka, izmantojot taimeri T3412 vai (PSM gadījumā T3412_extended), kura vērtība tiek pārsūtīta uz ierīci Attach procedūras vai nākamās TAU laikā. Mobilā sasniedzamības taimeris parasti ir vairākas minūtes garāks nekā T3412. Ja UE nav veikusi TAU pirms “Mobilās sasniedzamības taimera” termiņa beigām, tīkls uzskata, ka tas vairs nav sasniedzams.
UE sasniedzamība – Norāda, kad UE kļūst pieejama DL trafikai vai SMS. Tas notiek, kad UE kļūst pieejama peidžeru veikšanai (UE eDRX režīmā) vai kad UE pāriet ECM-CONNECTED režīmā (UE PSM vai eDRX režīmā), t.i. izveido TAU vai nosūta augšupsaites paketi.
Ziņošana par atrašanās vietu – Šāda veida uzraudzības notikumi ļauj AS vaicāt UE atrašanās vietu. Var pieprasīt vai nu pašreizējo atrašanās vietu (pašreizējā atrašanās vieta), vai pēdējo zināmo atrašanās vietu (nosaka pēc šūnas ID, no kuras ierīce pēdējo reizi veica TAU vai pārsūtīja trafiku), kas attiecas uz ierīcēm PSM vai eDRX enerģijas taupīšanas režīmā. Attiecībā uz “Pašreizējā atrašanās vieta” AS var pieprasīt atkārtotas atbildes, MME informējot AS katru reizi, kad mainās ierīces atrašanās vieta.
IMSI-IMEI asociācijas maiņa – Kad šis notikums ir aktivizēts, SCEF sāk pārraudzīt izmaiņas IMSI (SIM kartes identifikators) un IMEI (ierīces identifikators) kombinācijā. Kad notiek notikums, informē AS. Var izmantot, lai automātiski pārsaistītu ārējo ID ierīcei plānoto nomaiņas darbu laikā vai kalpotu kā ierīces zādzības identifikators.
Viesabonēšanas statuss – AS izmanto šāda veida uzraudzību, lai noteiktu, vai UE atrodas mājas tīklā vai viesabonēšanas partnera tīklā. Pēc izvēles var pārsūtīt tā operatora PLMN (publisko zemes mobilo tīklu), kurā ierīce ir reģistrēta.
Sakaru kļūme — Šāda veida uzraudzība informē AS par sakaru traucējumiem ar ierīci, pamatojoties uz savienojuma zuduma iemesliem (atlaišanas iemesla kods), kas saņemts no radiopiekļuves tīkla (S1-AP protokols). Šis notikums var palīdzēt noteikt, kāpēc saziņa neizdevās — tīkla problēmu dēļ, piemēram, ja eNodeb ir pārslogots (radio resursi nav pieejami) vai pašas ierīces kļūmes dēļ (radio Connection With UE Lost).
Pieejamība pēc DDN kļūmes – šis notikums informē AS, ka ierīce ir kļuvusi pieejama pēc sakaru kļūmes. Var izmantot, ja ir nepieciešams pārsūtīt datus uz ierīci, bet iepriekšējais mēģinājums nebija veiksmīgs, jo UE neatbildēja uz paziņojumu no tīkla (peidžeru) un dati netika piegādāti. Ja šāda veida uzraudzība ir pieprasīta UE, tad, tiklīdz ierīce izveido ienākošo komunikāciju, veic TAU vai nosūta datus uz augšupsaiti, AS tiks informēta, ka ierīce ir kļuvusi pieejama. Tā kā DDN (lejupsaites datu paziņošanas) procedūra darbojas starp MME un S/P-GW, šāda veida uzraudzība ir pieejama tikai IP ierīcēm.
PDN savienojuma statuss – informē AS, kad mainās ierīces statuss (PDN savienojuma statuss) – savienojums (PDN aktivizēšana) vai atvienošana (PDN dzēšana). To AS var izmantot, lai uzsāktu saziņu ar UE vai otrādi, lai saprastu, ka saziņa vairs nav iespējama. Šis uzraudzības veids ir pieejams IP un ne-IP ierīcēm.
UE skaits, kas atrodas ģeogrāfiskajā apgabalā – Šo uzraudzības veidu AS izmanto, lai noteiktu UE skaitu noteiktā ģeogrāfiskā apgabalā.
Ierīces aktivizēšana)
2G/3G tīklos reģistrācijas procedūra tīklā bija divpakāpju: vispirms ierīce tika reģistrēta SGSN (pievienošanas procedūra), pēc tam, ja nepieciešams, tika aktivizēts PDP konteksts - savienojums ar pakešu vārteju (GGSN) lai pārsūtītu datus. 3G tīklos šīs divas procedūras notika secīgi, t.i. ierīce negaidīja brīdi, kad vajadzēja pārsūtīt datus, bet aktivizēja PDP uzreiz pēc pievienošanas procedūras pabeigšanas. LTE gadījumā šīs divas procedūras tika apvienotas vienā, tas ir, pievienojot, ierīce nekavējoties pieprasīja PDN savienojuma aktivizēšanu (analoģiski PDP 2G/3G), izmantojot eNodeB uz MME-SGW-PGW.
NB-IoT savienojuma metodi definē kā “pievienot bez PDN”, tas ir, UE pievieno, neizveidojot PDN savienojumu. Šajā gadījumā tas nav pieejams trafika pārsūtīšanai un var tikai saņemt vai nosūtīt SMS. Lai šādai ierīcei nosūtītu komandu aktivizēt PDN un izveidot savienojumu ar AS, tika izstrādāta funkcionalitāte “Ierīces iedarbināšana”.
Saņemot komandu pieslēgt šādu UE no AS, SCEF uzsāk vadības SMS nosūtīšanu uz ierīci, izmantojot SMS centru. Saņemot SMS, ierīce aktivizē PDN un izveido savienojumu ar AS, lai saņemtu turpmākus norādījumus vai pārsūtītu datus.
Dažkārt var beigties jūsu ierīces abonementa derīguma termiņš SCEF. Jā, abonementam ir savs darbības laiks, ko nosaka operators vai tas ir saskaņots ar AS. Pēc derīguma termiņa beigām PDN tiks deaktivizēts MME un ierīce kļūs nepieejama AS. Šajā gadījumā palīdzēs arī funkcionalitāte “Ierīces aktivizēšana”. Saņemot jaunus datus no AS, SCEF noskaidros ierīces savienojuma statusu un piegādās datus pa SMS kanālu.
Secinājums
SCEF funkcionalitāte, protams, neaprobežojas tikai ar iepriekš aprakstītajiem pakalpojumiem un pastāvīgi attīstās un paplašinās. Pašlaik SCEF jau ir standartizēti vairāk nekā ducis pakalpojumu. Tagad mēs esam pieskārušies tikai galvenajām funkcijām, kuras ir pieprasītas no izstrādātājiem, par pārējo mēs runāsim nākamajos rakstos.
Uzreiz rodas jautājums: kā iegūt testa piekļuvi šim "brīnummezglam" iespējamo gadījumu sākotnējai testēšanai un atkļūdošanai? Viss ir ļoti vienkārši. Jebkurš izstrādātājs var nosūtīt pieprasījumu uz iot.info@mts.ru, kurā pietiek norādīt savienojuma mērķi, iespējamā gadījuma aprakstu un kontaktinformāciju saziņai.
Līdz nākamajai reizei!
Autori:
- Konverģento risinājumu un multimediju pakalpojumu nodaļas vecākais eksperts Sergejs Novikovs ,
- konverģento risinājumu un multimediju pakalpojumu nodaļas eksperts Aleksejs Lapšins
Avots: www.habr.com
