En la artikolo "", parolante pri la arkitekturo de la paka kerno de la reto NB-IoT, ni menciis la aperon de nova SCEF-nodo. Ni klarigas en la tria parto kio ĝi estas kaj kial ĝi estas bezonata?
Kreante M2M-servon, programistoj de aplikaĵoj alfrontas la jenajn demandojn:
- kiel identigi aparatojn;
- kian konfirmon kaj aŭtentikig-algoritmon uzi;
- kiun transportprotokolo elekti por interagi kun aparatoj;
- kiel fidinde liveri datumojn al aparatoj;
- kiel organizi kaj establi regulojn por interŝanĝi datumojn kun ili;
- kiel kontroli kaj akiri informojn pri ilia kondiĉo interrete;
- kiel liveri datumojn samtempe al grupo de viaj aparatoj;
- kiel samtempe sendi datumojn de unu aparato al pluraj klientoj;
- kiel akiri unuecan aliron al pliaj operaciistservoj por administri vian aparaton.
Por solvi ilin, necesas krei proprietajn teknike "pezajn" solvojn, kio kondukas al pliigitaj laborkostoj kaj al merkataj servoj. Jen kie la nova SCEF-nodo venas al la savo.
Kiel difinite fare de 3GPP, SCEF (servokapabla eksponiĝofunkcio) estas tute nova komponento de la 3GPP-arkitekturo kies funkcio estas sekure elmontri la servojn kaj kapablojn disponigitajn per 3GPP-retaj interfacoj tra APIoj.
En simplaj vortoj, SCEF estas peranto inter la reto kaj la aplika servilo (AS), ununura fenestro de aliro al operaciistservoj por administri vian M2M-aparaton en la reto NB-IoT per intuicia, normigita API-interfaco.
SCEF kaŝas la kompleksecon de la reto de funkciigisto, permesante al aplikaĵprogramistoj abstrakti kompleksajn, aparat-specifajn mekanismojn por interagado kun aparatoj.
Transformante retajn protokolojn en konatan API por programistoj de aplikaĵoj, la SCEF-API faciligas la kreadon de novaj servoj kaj reduktas la tempo-merkatiĝon. La nova nodo ankaŭ inkluzivas funkciojn por identigi/aŭtentikigi porteblajn aparatojn, difinante la regulojn por interŝanĝo de datumoj inter la aparato kaj AS, forigante la bezonon, ke aplikaĵprogramistoj efektivigu ĉi tiujn funkciojn sur sia flanko, ŝanĝante ĉi tiujn funkciojn al la ŝultroj de la funkciigisto.
SCEF kovras la interfacojn necesajn por aŭtentikigo kaj rajtigo de aplikaĵserviloj, konservado de UE-movebleco, datumtransigo kaj aparato-eksigado, aliro al kromaj servoj kaj funkciigistaj retkapabloj.
Al la AS ekzistas ununura T8-interfaco, API (HTTP/JSON) normigita de 3GPP. Ĉiuj interfacoj, escepte de T8, funkcias surbaze de la DIAMETRO-protokolo (Fig. 1).
T6a - interfaco inter SCEF kaj MME. Uzita por Moveblecaj/Sesiaj administradproceduroj, transdono de ne-IP-datumoj, provizo de monitorado de eventoj kaj ricevado de raportoj pri ili.
S6t - interfaco inter SCEF kaj HSS. Bezonata por abonantaŭtentigo, rajtigo de aplikaĵserviloj, akiro de kombinaĵo de ekstera identigilo kaj IMSI/MSISDN, provizado de monitorado de eventoj kaj ricevado de raportoj pri ili.
S6m/T4 - interfacoj de SCEF ĝis HSS kaj SMS-C (3GPP difinas la MTC-IWF-nodon, kiu estas uzata por aparato ekigado kaj SMS-transsendo en NB-IoT-retoj. Tamen, en ĉiuj efektivigoj la funkcieco de ĉi tiu nodo estas integrita en SCEF, do por simpligo de la cirkvito, ni ne konsideros ĝin aparte). Uzita por akiri vojinformojn por sendi SMS kaj interagi kun la SMS-centro.
T8 - API-interfaco por SCEF-interagado kun aplikiĝserviloj. Kaj kontrolkomandoj kaj trafiko estas transdonitaj per ĉi tiu interfaco.
*en realeco ekzistas pli da interfacoj; nur la plej bazaj estas listigitaj ĉi tie. Kompleta listo estas donita en 3GPP 23.682 (4.3.2 Listo de Referencaj Punktoj).
Malsupre estas la ĉefaj funkcioj kaj servoj de SCEF:
- ligi la SIM-kartan identigilon (IMSI) al ekstera ID;
- transdono de ne-IP-trafiko (Non-IP Data Delivery, NIDD);
- grupoperacioj uzante eksteran grupan ID;
- subteno por transdono de datumoj reĝimo kun konfirmo;
- bufrado de MO (Mobile Originated) kaj MT (Mobile Terminated) datumoj;
- aŭtentikigo kaj rajtigo de aparatoj kaj aplikaĵserviloj;
- samtempa uzo de datumoj de unu UE fare de pluraj AS-oj;
- subteno por specialaj funkcioj de monitorado de la statuso de UE (MONTE - Monitorado de Eventoj);
- aparato ekigado;
- disponigante ne-IP-datuman vagadon.
La baza principo de interago inter AS kaj SCEF baziĝas sur la tielnomita skemo. abonoj. Se necesas akiri aliron al iu SCEF-servo por specifa UE, la aplikaĵservilo devas krei abonon sendante komandon al la specifa API de la petita servo kaj ricevi unikan identigilon kiel respondo. Post tio ĉiuj pluaj agoj kaj komunikadoj kun la UE kadre de ĉi tiu servo okazos per ĉi tiu identigilo.
Ekstera ID: Universala aparato-identigilo
Unu el la plej gravaj ŝanĝoj en la interaga skemo inter AS kaj aparatoj kiam vi laboras per SCEF estas la aspekto de universala identigilo. Nun, anstataŭ telefonnumero (MSISDN) aŭ IP-adreso, kiel estis la kazo en la klasika reto 2G/3G/LTE, la aparato-identigilo por la aplika servilo fariĝas "ekstera ID". Ĝi estas difinita de la normo en formato konata al aplikaĵprogramistoj " @ "
Programistoj ne plu bezonas efektivigi aparatajn aŭtentigajn algoritmojn; la reto tute transprenas ĉi tiun funkcion. Ekstera ID estas ligita al IMSI, kaj la programisto povas esti certa, ke alirante specifan eksteran ID, ĝi interagas kun specifa SIM-karto. Kiam vi uzas SIM-peton, vi ricevas tute unikan situacion kiam la ekstera identigilo unike identigas specifan aparaton!
Krome, pluraj eksteraj identigiloj povas esti ligitaj al unu IMSI - eĉ pli interesa situacio aperas kiam la ekstera identigilo unike identigas specifan aplikaĵon respondecan pri specifa servo sur specifa aparato.
Ankaŭ aperas grupidentigilo - ekstera grupidentigilo, kiu inkluzivas aron de individuaj eksteraj identigiloj. Nun, kun unu peto al SCEF, AS povas iniciati grupoperaciojn - sendante datumojn aŭ kontroli komandojn al pluraj aparatoj kunigitaj en ununura logika grupo.
Pro la fakto, ke por AS-programistoj la transiro al nova aparato-identigilo ne povas esti tuja, SCEF lasis la eblecon de AS-komunikado kun la UE per norma nombro - MSISDN.
Transdono de ne-IP-trafiko (Ne-IP-Datumo-Liveraĵo, NIDD)
En NB-IoT, kadre de la optimumigo de mekanismoj por transdoni malgrandajn kvantojn da datumoj, krom la jam ekzistantaj PDN-tipoj, kiel IPv4, IPv6 kaj IPv4v6, aperis alia tipo - ne-IP. En ĉi tiu kazo, la aparato (UE) ne ricevas IP-adreson kaj datumoj estas transdonitaj sen uzi la IP-protokolon. Trafiko por tiaj konektoj povas esti direktita en du manieroj: klasika - MME -> SGW -> PGW kaj poste tra la PtP-tunelo al AS (Fig. 2) aŭ uzante SCEF (Fig. 3).
La klasika metodo ne ofertas specialajn avantaĝojn super IP-trafiko, krom reduktado de la grandeco de elsenditaj pakaĵetoj pro la foresto de IP-kapoj. La uzo de SCEF malfermas kelkajn novajn eblecojn kaj signife simpligas la procedurojn por interagado kun aparatoj.
Dum elsendado de datumoj per SCEF, du tre gravaj avantaĝoj aperas super klasika IP-trafiko:
Livero de MT-trafiko al la aparato per ekstera identigilo
Por sendi mesaĝon al klasika IP-aparato, la AS devas scii sian IP-adreson. Ĉi tie aperas problemo: ĉar la aparato kutime ricevas "grizan" IP-adreson post registriĝo, ĝi komunikas kun la aplikaĵoservilo, kiu troviĝas en la Interreto, per NAT-nodo, kie la griza adreso estas tradukita al blanka. La kombinaĵo de grizaj kaj blankaj IP-adresoj daŭras limigitan tempon, depende de la NAT-agordoj. Averaĝe, por TCP aŭ UDP - ne pli ol kvin minutoj. Tio estas, se ne estas interŝanĝo de datumoj kun ĉi tiu aparato ene de 5 minutoj, la konekto disfalos kaj la aparato ne plu estos alirebla ĉe la blanka adreso kun kiu la kunsido kun AS estis komencita. Estas pluraj solvoj:
1. Uzu korbaton. Post kiam konekto estas establita, la aparato devas interŝanĝi pakaĵetojn kun la AS ĉiujn kelkajn minutojn, tiel malhelpante NAT-tradukojn fermiĝi. Sed ĉi tie oni ne povas paroli pri iu ajn energia efikeco.
2. Ĉiufoje, se necese, kontrolu la haveblecon de pakaĵoj por la aparato sur la AS - sendu mesaĝon al la suprenligo.
3. Kreu privatan APN (VRF), kie la aplikaĵservilo kaj aparatoj estos sur la sama subreto, kaj asignu senmovajn IP-adresojn al la aparatoj. Ĝi funkcios, sed estas preskaŭ neeble, kiam ni parolas pri aro de miloj, dekoj da miloj da aparatoj.
4. Fine, la plej taŭga opcio: uzi IPv6, ĝi ne postulas NAT, ĉar IPv6-adresoj estas rekte alireblaj de Interreto. Tamen, eĉ en ĉi tiu kazo, kiam la aparato estas reregistrita, ĝi ricevos novan IPv6-adreson kaj ne plu estos alirebla uzante la antaŭan.
Sekve, necesas sendi iun inicialigpakaĵon kun aparato-identigilo al la servilo por raporti la novan IP-adreson de la aparato. Tiam atendu konfirman paketon de AS, kiu ankaŭ influas energian efikecon.
Ĉi tiuj metodoj funkcias bone por 2G/3G/LTE-aparatoj, kie la aparato ne havas striktajn postulojn por aŭtonomio kaj, kiel rezulto, ne estas limigoj pri aertempo kaj trafiko. Ĉi tiuj metodoj ne taŭgas por NB-IoT pro sia alta energikonsumo.
SCEF solvas ĉi tiun problemon: ĉar la nura aparatidentigilo por AS estas ekstera ID, la AS nur bezonas sendi datumpakaĵon al SCEF por specifa ekstera ID, kaj SCEF prizorgas la reston. Se la aparato estas en PSM aŭ eDRX-ŝpara reĝimo, datumoj estos bufrigitaj kaj liveritaj kiam la aparato disponeblas. Se la aparato disponeblas por trafiko, la datumoj estos liveritaj tuj. La sama validas por administraj teamoj.
En ajna momento, la AS povas revoki la bufran mesaĝon al la UE aŭ anstataŭigi ĝin per nova.
La bufra mekanismo ankaŭ povas esti uzita dum elsendado de MO-datenoj de la UE ĝis la AS. Se SCEF ne povis liveri datumojn al la AS tuj, ekzemple se daŭra laboro sur la AS-serviloj, tiuj pakaĵetoj estos bufrigitaj kaj garantiitaj por esti liveritaj tuj kiam la AS iĝas havebla.
Kiel notite supre, aliro al specifa servo kaj UE por AS (kaj NIDD estas servo) estas reguligita per reguloj kaj politikoj sur la SCEF-flanko, kio enkalkulas la unikan eblecon de samtempa uzo de datenoj de unu UE de pluraj ASoj. Tiuj. se pluraj AS abonis unu UE, tiam post ricevo de datumoj de la UE, SCEF sendos ĝin al ĉiuj abonintaj AS. Ĉi tio taŭgas por kazoj, kie la kreinto de aro de specialigitaj aparatoj dividas datumojn inter pluraj klientoj. Ekzemple, kreante reton de veterstacioj funkcianta per NB-IoT, vi povas vendi datumojn de ili al multaj servoj samtempe.
Garantiita mesaĝa livero-mekanismo
Reliable Data Service estas mekanismo por garantiita livero de MO kaj MT-mesaĝoj sen la uzo de specialigitaj algoritmoj ĉe la protokolnivelo, kiel ekzemple manpremo en TCP. Ĝi funkcias inkludante specialan flagon en la servoparto de la mesaĝo kiam interŝanĝite inter la UE kaj SCEF. Ĉu aŭ ne aktivigi ĉi tiun mekanismon dum elsendado de trafiko estas decidita de la AS.
Se la mekanismo estas aktivigita, la UE inkluzivas specialan flagon en la supra parto de la pakaĵeto kiam ĝi postulas garantiitan liveron de MO-trafiko. Post ricevo de tia pako, la SCEF respondas al la UE per agnosko. Se la UE ne ricevas la agnoskan paketon, la pako al SCEF estos resendita. La sama afero okazas por MT-trafiko.
Monitorado de aparatoj (monitorado de eventoj - MONTE)
Kiel menciite supre, la SCEF-funkcio, interalie, inkluzivas funkciojn por kontroli la staton de la UE, la t.n. aparato monitorado. Kaj se novaj identigiloj kaj datumtransigo mekanismoj estas optimumigo (kvankam tre seriozaj) de ekzistantaj proceduroj, tiam MONTE estas tute nova funkcieco kiu ne estas disponebla en 2G/3G/LTE retoj. MONTE permesas al AS monitori aparatojn parametrojn kiel konektostatuso, komunika havebleco, loko, vaganta statuso, ktp. Pri ĉiu ni parolos pli detale iom poste.
Se necesas aktivigi ajnan monitoran eventon por aparato aŭ grupo de aparatoj, la AS abonas la respondan servon sendante la respondan komandon API MONTE al SCEF, kiu inkluzivas parametrojn kiel ekstera Id aŭ ekstera grupa ID, AS-identigilo, monitorado. tipo, nombro da raportoj, kiujn AS volas ricevi. Se la AS estas rajtigita por efektivigi la peton, SCEF, depende de la tipo, disponigos la eventon al la HSS aŭ MME (Fig. 4). Kiam okazaĵo okazas, la MME aŭ HSS generas raporton al SCEF, kiu sendas ĝin al la AS.
Provizo de ĉiuj okazaĵoj, kun la escepto de "Nombro de UEoj ĉeestantaj en geografia areo", okazas tra HSS. Du eventoj "Ŝanĝo de IMSI-IMEI-Asocio" kaj "Roaming Status" estas spuritaj rekte sur HSS, la resto estos provizita de HSS sur MME.
Okazaĵoj povas esti aŭ unufojaj aŭ periodaj, kaj estas determinitaj per sia tipo.
Sendi raporton pri evento (raportado) estas farita de la nodo, kiu spuras la eventon rekte al SCEF (Fig. 5).
Grava punkto: Monitoraj eventoj povas esti aplikataj al ambaŭ ne-IP-aparatoj konektitaj per SCEF kaj IP-aparatoj transdonantaj datumojn laŭ la klasika maniero per MME-SGW-PGW.
Ni rigardu pli detale ĉiun el la monitoraj eventoj:
Perdo de konektebleco — informas la AS, ke la UE ne plu disponeblas nek por datumtrafiko nek por signalado. La okazaĵo okazas kiam la "poŝtelefona atingebla tempigilo" por la UE eksvalidiĝas sur la MME. En peto por ĉi tiu speco de monitorado, la AS povas indiki sian "Maksimuman Detektan Tempon" valoron - se dum ĉi tiu tempo la UE ne montras ajnan agadon, la AS estos informita ke la UE estas nedisponebla, indikante la kialon. La okazaĵo ankaŭ okazas se la UE estis perforte forigita de la reto ial ajn.
* Por sciigi al la reto, ke la aparato ankoraŭ disponeblas, ĝi periode iniciatas ĝisdatigproceduron - Spuranta Area Ĝisdatigo (TAU). La ofteco de ĉi tiu proceduro estas agordita de la reto uzante tempigilon T3412 aŭ (T3412_extended en la kazo de PSM), kies valoro estas transdonita al la aparato dum la Attach-proceduro aŭ la sekva TAU. Poŝtelefona atingebla tempigilo estas kutime plurajn minutojn pli longa ol T3412. Se la UE ne faris TAU antaŭ la eksvalidiĝo de la "Mobile atingebla tempigilo", la reto konsideras ĝin ne plu atingebla.
UE-atingebleco - Indikas kiam la UE iĝas disponebla por DL trafiko aŭ SMS. Tio okazas kiam la UE iĝas disponebla por paĝigo (por UE en eDRX-reĝimo) aŭ kiam la UE eniras ECM-CONNECTED-reĝimon (por UE en PSM aŭ eDRX-reĝimo), t.e. faras TAU aŭ sendas suprenligan paketon.
Loka raportado – Ĉi tiu tipo de monitoraj eventoj permesas al la AS pridemandi la lokon de la UE. Ĉu la nuna loko (Nuna Loko) aŭ la lasta konata loko (Determinita de la ĉela ID de kiu la aparato faris TAU aŭ transdonis trafikon lastan fojon) povas esti petita, kio estas grava por aparatoj en PSM aŭ eDRX-ŝparad-energioj. Por "Nuna Loko", la AS povas peti ripetajn respondojn, kie la MME informas la AS ĉiun fojon kiam la loko de la aparato ŝanĝiĝas.
Ŝanĝo de IMSI-IMEI-Asocio - Kiam ĉi tiu evento estas aktivigita, SCEF komencas monitori ŝanĝojn en la kombinaĵo de IMSI (identigilo de SIM-karto) kaj IMEI (identigilo de aparato). Kiam okazas evento, informas AS. Povas esti uzata por aŭtomate religi eksteran identigilon al aparato dum planita anstataŭiga laboro aŭ servi kiel identigilo por ŝtelo de aparato.
Roaming Statuso – ĉi tiu tipo de monitorado estas uzata de AS por determini ĉu la UE estas en la hejma reto aŭ en la reto de vaganta partnero. Laŭvole, la PLMN (Public Land Mobile Network) de la funkciigisto en kiu la aparato estas registrita povas esti transdonita.
Komunika malsukceso — Ĉi tiu speco de monitorado informas la AS pri malsukcesoj en komunikado kun la aparato, surbaze de la kialoj de la konektoperdo (liberiga kaŭzokodo) ricevita de la radio-alira reto (protokolo S1-AP). Ĉi tiu evento povas helpi determini kial la komunikado malsukcesis - pro problemoj en la reto, ekzemple, kiam la eNodeb estas troŝarĝita (Radioresursoj ne haveblaj) aŭ pro misfunkciado de la aparato mem (Radio-Konekto Kun UE Perdita).
Havebleco post DDN-Malsukceso – ĉi tiu evento informas la AS, ke la aparato fariĝis disponebla post misfunkciado de komunikado. Uzeblas kiam necesas transdoni datumojn al aparato, sed la antaŭa provo ne sukcesis ĉar la UE ne respondis al sciigo de la reto (paĝigo) kaj la datumoj ne estis liveritaj. Se ĉi tiu tipo de monitorado estis petita por la UE, tiam tuj kiam la aparato faras envenantan komunikadon, faras TAU aŭ sendas datumojn al la suprenligo, la AS estos informita ke la aparato fariĝis havebla. Ĉar la proceduro DDN (malsuprenliga datuma sciigo) funkcias inter MME kaj S/P-GW, ĉi tiu speco de monitorado estas disponebla nur por IP-aparatoj.
PDN-Konekteca Statuso – informas AS kiam la stato de la aparato ŝanĝiĝas (PDN-konekteca stato) - konekto (PDN-aktivigo) aŭ malkonekto (PDN-forigo). Tio povas esti uzata de la AS por iniciati komunikadon kun la UE, aŭ inverse, por kompreni ke komunikado ne plu eblas. Ĉi tiu tipo de monitorado disponeblas por IP kaj ne-IP-aparatoj.
Nombro de UE-oj ĉeestantaj en geografia areo – Ĉi tiu speco de monitorado estas uzata de la AS por determini la nombron da UEoj en certa geografia areo.
Aparato ekfunkciigo)
En 2G/3G retoj, la registra proceduro en la reto estis duetapa: unue, la aparato registrita kun la SGSN (aleksa proceduro), poste, se necese, ĝi aktivigis la PDP-kuntekston - konekton kun la paka pordego (GGSN) por transdoni datumojn. En 3G-retoj, ĉi tiuj du proceduroj okazis sinsekve, t.e. la aparato ne atendis la momenton, kiam ĝi bezonis transdoni datumojn, sed aktivigis PDP tuj post kiam la kunliga proceduro estis kompletigita. En LTE, ĉi tiuj du proceduroj estis kombinitaj en unu, tio estas, kiam alkroĉite, la aparato tuj petis aktivigon de la PDN-konekto (analoga al PDP en 2G/3G) per la eNodeB al la MME-SGW-PGW.
NB-IoT difinas konektan metodon kiel "alkroĉi sen PDN", tio estas, la UE-ataŝeoj sen establi PDN-konekton. En ĉi tiu kazo, ĝi ne disponeblas por transdoni trafikon, kaj nur povas ricevi aŭ sendi SMS. Por sendi komandon al tia aparato por aktivigi PDN kaj konekti al AS, la funkcio "Aparato ekigado" estis evoluigita.
Ricevinte komandon por konekti tian UE de la AS, SCEF komencas sendi kontrolan SMS al la aparato tra la SMS-centro. Ricevinte SMS, la aparato aktivigas la PDN kaj konektas al la AS por ricevi pliajn instrukciojn aŭ transdoni datumojn.
Povas esti tempoj kiam via aparato-abono eksvalidiĝas ĉe SCEF. Jes, la abono havas sian propran vivdaŭron, fiksitan de la funkciigisto aŭ interkonsentita kun AS. Post eksvalidiĝo, la PDN estos malaktivigita sur la MME kaj la aparato fariĝos neatingebla por la AS. En ĉi tiu kazo, la funkcio "Aparato ekfunkciigo" ankaŭ helpos. Ricevinte novajn datumojn de AS, SCEF ekscios la staton de la konekto de la aparato kaj liveros la datumojn per SMS-kanalo.
konkludo
La funkcieco de SCEF, kompreneble, ne estas limigita al la servoj priskribitaj supre kaj konstante evoluas kaj vastiĝas. Nuntempe, pli ol deko da servoj jam estis normigitaj por SCEF. Nun ni tuŝis nur la ĉefajn funkciojn, kiujn oni postulas de programistoj; pri la resto ni parolos en estontaj artikoloj.
La demando tuj ekestas: kiel akiri provan aliron al ĉi tiu "mirakla" nodo por prepara testado kaj sencimigado de eblaj kazoj? Ĉio estas tre simpla. Ajna programisto povas sendi peton al [retpoŝte protektita], en kiu sufiĉas indiki la celon de konekto, priskribo de ebla kazo kaj kontaktinformoj por komunikado.
Ĝis revido!
Aŭtoroj:
- altranga fakulo de la fako pri konverĝaj solvoj kaj plurmediaj servoj Sergey Novikov ,
- sperta de la fako de konverĝaj solvoj kaj plurmediaj servoj Alexey Lapshin
fonto: www.habr.com