Në artikullin "", duke folur për arkitekturën e kernelit të paketave të rrjetit NB-IoT, përmendëm shfaqjen e një nën-nyjeje të re SCEF. Shpjegojmë në pjesën e tretë se çfarë është kjo dhe për çfarë i nevojitet?

Kur krijojnë një shërbim M2M, zhvilluesit e aplikacioneve përballen me pyetje të mëposhtme:
- Si të identifikoni pajisjet;
- Cilin algoritëm të verifikimit dhe konfirmimit të autenticitetit të përdorni;
- Cilin protokoll transporti të zgjidhni për të komunikuar me pajisjet;
- Si të sigurohet dorëzimi i të dhënave në pajisje;
- Si të organizoni dhe të vendosni rregullat për shkëmbimin e të dhënave me to;
- Si të kontrolloni dhe të merrni informacion në kohë reale për gjendjen e tyre;
- Si të dërgoni të dhëna në mënyrë të njëkohshme në një grup pajisjesh;
- Si të dërgoni të dhëna nga një pajisje në disa klientë njëkohësisht;
- Si të merrni qasje të unifikuar në shërbimet shtesë të operatorit për menaxhimin e pajisjes suaj.
Për të zgjidhur këto probleme, shpesh krijohen zgjidhje teknike «të rënda» proprietare, gjë që çon në rritjen e kostove të punës dhe kohës së tregut për shërbimet. Këtu vjen në ndihmë nën-nyja e re SCEF.
Sipas përkufizimit 3GPP, SCEF (funksioni i ekspozimit të kapaciteteve të shërbimit) është një komponent i ri i arkitekturës 3GPP, i cili ka funksionin e ekspozimit në mënyrë të sigurt të shërbimeve dhe mundësive të ofruara nga ndërfaqet rrjetore 3GPP nëpërmjet API.
Me fjalë të thjeshta, SCEF është një ndërmjetës midis rrjetit dhe serverit të aplikacioneve (application server – AS), një dritare e vetme për qasje në shërbimet e operatorit për menaxhimin e pajisjes suaj M2M në rrjetin NB-IoT nëpërmjet një ndërfaqe API hynëse dhe të standardizuar.
SCEF fsheh kompliksitetin e rrjetit të operatorit, duke u lejuar zhvilluesve të aplikacioneve të abstrohen nga mekanizmat kompleksë dhe specifikë të ndërveprimit me pajisjet.
Duke transformimit të protokolleve të rrjetit në një ndërfaqe API që është e njohur për zhvilluesit e aplikacioneve, SCEF lehtëson krijimin e shërbimeve të reja dhe zvogëlon kohën e tregut. Gjithashtu, nyja e re përfshin funksione për identifikimin/authentikimin e pajisjeve mobile, përcaktimin e rregullave për shkëmbimin e të dhënave midis pajisjes dhe AS, duke hequr nevojën që zhvilluesit e aplikacioneve të implementojnë këto funksione në anën e tyre, duke i kaluar këto funksione në krahët e operatorit.
SCEF lidh ndërfaqet e nevojshme për autentifikimin dhe autorizimin e serverëve të aplikacioneve, mbështetje për lëvizshmërinë UE, shkëmbimin e të dhënave dhe aktivizimin e pajisjeve, qasjen në shërbime dhe mundësi të tjera të rrjetit të operatorit.
Në drejtim të AS shkon një ndërfaqe e vetme T8, ndërfaqe API (HTTP/JSON), e standardizuar nga 3GPP. Të gjitha ndërfaqet, përveç T8, punojnë mbi bazën e protokollit DIAMETER (fig. 1).

T6a – është ndërfaqe midis SCEF dhe MME. Përdoret për procedurat e menaxhimit të Lëvizshmërisë/Sesionit, për shkëmbimin e të dhënave non-IP, për provizionimin e ngjarjeve të monitorimit dhe marrjen e raporteve për to.
S6t – ndërfaqe midis SCEF dhe HSS. Nevojitet për autentifikimin e abonentit, autorizimin e serverëve të aplikacioneve, marrjen e lidhjes external ID dhe IMSI/MSISDN, provizionimin e ngjarjeve të monitorimit dhe marrjen e raporteve për to.
S6m/T4 – ndërfaqet nga SCEF deri te HSS dhe SMS-C (në 3GPP është e përcaktuar nyja MTC-IWF, e cila përdoret për aktivizimin e pajisjeve dhe për dërgimin e SMS-ve në rrjetet NB-IoT. Megjithatë, në të gjitha realizimet, funksionaliteti i kësaj nyje është integruar në SCEF, kështu që për thjeshtimin e skemës nuk do ta shqyrtojmë atë veçmas). Përdoren për marrjen e informacionit të rrugës për dërgimin e SMS-ve dhe për të bashkëpunuar me qendrën SMS.
T8 – ndërfaqe API për ndërveprimin e SCEF me serverët e aplikacioneve. Përmes kësaj ndërfaqe dërgohen si komandat menaxhuese ashtu edhe trafiku.
*në të vërtetë ka shumë më tepër ndërfaqe, këtu janë përmendur vetëm ato më të rëndësishmet. Lista e plotë është dhënë në 3GPP 23.682 (4.3.2 Lista e Pikave të Referencës).
Më poshtë janë funksionet dhe shërbimet kryesore të SCEF:
- lidha e identifikuesit të kartës SIM (IMSI) me external ID;
- shkëmbimi i trafikut non-IP (Non-IP Data Delivery, NIDD);
- operacione grupore, duke përdorur external group ID;
- mbështetje për modin e dërgimit të të dhënave me konfirmim;
- buforizimi i të dhënave MO (Mobile Originated) dhe MT (Mobile Terminated);
- autentifikimi dhe autorizimi i pajisjeve dhe serverëve të aplikacioneve;
- përdorimi i të dhënave të një UE nga disa AS njëkohësisht;
- mbështetje për funksione të veçanta të kontrollit të gjendjes së UE (MONTE – Monitoring Events);
- ngacmimi i pajisjeve;
- sigurimi i roaming-ut të të dhënave non-IP.
Principi kryesor i bashkëpunimit midis AS dhe SCEF është ndërtuar mbi sistemin e ashtuquajtur të abonimeve. Kur nevojitet akses në ndonjë shërbim nga SCEF për një UE të caktuar, serveri i aplikacioneve kërkon të krijojë një abonim, duke dërguar një komandë në API-në e shërbimit të kërkuar dhe duke marrë në përgjigje një identifikues unik. Pas kësaj, të gjitha veprimet dhe komunikimet e mëtejshme me UE brenda këtij shërbimi do të realizohen duke përdorur këtë identifikues.
ID e Jashtme: identifikuesi universial i pajisjes
Një nga ndryshimet më të rëndësishme në sistemin e bashkëpunimit midis AS dhe pajisjeve gjatë punës përmes SCEF është shfaqja e identifikuesit universial. Tani, në vend të numrit të telefonit (MSISDN) ose adresës IP, siç ndodhte në rrjetin tradicional 2G/3G/LTE, identifikuesi i pajisjes për serverin e aplikacioneve bëhet "ID e jashtme". Ai përcaktohet nga standardi në formatin e njohur për zhvilluesit e aplikacioneve "@".
Zhvilluesit nuk kanë më nevojë të realizojnë algoritme autentikimi për pajisjet, rrjeti plotësisht merr përsipër këtë funksion. ID e jashtme lidhët me IMSI-në, dhe zhvilluesi mund të jetë i sigurt se duke iu referuar një ID të jashtme të caktuar, ai komunikon me një kartelë specifike. Kur përdoret çipa i sim, fitohet një situatë krejt unikale, kur ID e jashtme identifikon në mënyrë unike një pajisje specifike!
Më shumë se kaq, një IMSI mund të lidhë disa ID të jashtme — duke krijuar një situatë edhe më interesante, ku ID e jashtme identifikon në mënyrë unike një aplikacion të caktuar, përgjegjës për një shërbim të caktuar në një pajisje të veçantë.
Gjithashtu shfaqet një identifikues grupor — ID e grupit të jashtëm, i cili përfshin një grup të veçantë ID të jashtme. Tani, me një kërkesë në SCEF, AS mund të inicirojë operacione grupore — dërgimin e të dhënave ose komandave të menaxhimit për shumë pajisje, të bashkuara në një grup logjik të vetëm.
Për shkak se për zhvilluesit AS kalimi në identifikuesin e ri të pajisjes nuk mund të jetë momental, SCEF ka lënë mundësinë e komunikimit të AS me UE përmes numrit standard – MSISDN.
Transporti i të dhënave non-IP (Non-IP Data Delivery, NIDD)
Në NB-IoT, në kuadër të optimizimit të mekanizmave për transferimin e volumesh të vogla të të dhënave, përveç llojeve të tanishme të PDN, si IPv4, IPv6 dhe IPv4v6, është ndarë një lloj tjetër — non-IP. Në këtë rast, pajisjes (UE) nuk i jepet një adresë IP, dhe të dhënat transmetohen pa përdorimin e protokollit IP. Trafiku për këto lidhje mund të rrugëtizohet në dy mënyra: në mënyrën klasike — MME -> SGW -> PGW dhe më pas nëpërmjet tunelit PtP deri në AS (fig. 2) ose duke përdorur SCEF (fig. 3).

Mënyra klasike nuk ofron ndonjë përparësi të veçantë përballë trafikut IP, përveç reduktimit të madhësisë së paketeve të transmetuara për shkak të mungesës së titujve IP. Përdorimi i SCEF hap një sërë mundësish të reja dhe e thjeshton ndjeshëm procedurën e ndërveprimit me pajisjet.
Kur trasferohen të dhëna përmes SCEF, dalin dy avantazhe shumë të rëndësishme para trafikut klasik IP:
Dërgimi i trafik MT deri te pajisja përmes ID-së ekstern.
Për të dërguar një mesazh në një pajisje klasike IP — AS duhet të njohë adresën e saj IP. Këtu shfaqet problemi: pasi pajisja gjatë regjistrimit zakonisht merr një adresë IP "të shkretë", ajo komunikon me serverin e aplikacioneve të vendosur në internet përmes një nodi NAT, ku ndodhet translacioni nga adresa e shkretë në të bardhë. Lidhja e adresave IP të shkretë dhe të bardhë mbahet për një kohë të kufizuar, në varësi të konfigurimeve të NAT. Në mesatarisht për TCP ose UDP — jo më shumë se pesë minuta. Kështu, nëse brenda 5 minutave nuk ka pasur shkëmbim të të dhënave me këtë pajisje, lidhja do të shpërbëhet, dhe pajisja do të ndalojë së qeni e aksesueshme për atë adresë të bardhë, me të cilin është iniciuar seanca me AS. Ka disa zgjidhje:
1. Përdorimi i heartbeat. Njëherë që është krijuar lidhja, pajisja duhet të shkëmbejë me AS paketa çdo disa minuta, duke mos lejuar që kështu të mbyllen translacionet në NAT. Por këtu nuk mund të flitet për ndonjë efikasitet energetik.
2. Çdo herë kur është e nevojshme, kontrollohet nëse ka paketa për pajisjen në AS — dërgohet një mesazh në uplink.
3. Të krijohet një APN privat (VRF), ku serveri i aplikacioneve dhe pajisjet do të jenë në të njëjtin nënshtet, dhe t'u caktohen pajisjeve adresat IP statike. Do të funksionojë, por kjo është pothuajse e pamundur kur flitet për një park prej mijëra, dhjetëra mijëra pajisjesh.
4. Së fundi, zgjidhja më e përshtatshme: përdorimi i IPv6, sepse nuk kërkon NAT, pasi adresat IPv6 janë të disponueshëm drejtpërdrejt nga interneti. Megjithatë, edhe në këtë rast, në momentin e ri-regjistrimit të pajisjes, ajo do të marrë një adresë të re IPv6 dhe nuk do të jetë më e qasshme me adresën e mëparshme.
Për rrjedhojë, është e nevojshme të dërgohet një paketë fillestare me identifikuesin e pajisjes në server, për të njoftuar adresën e re IP të pajisjes. Më pas, duhet të pritet paketa konfirmuese nga AS, e cila gjithashtu ndikon në efikasitetin energjetik.
Këto metoda funksionojnë mirë për pajisjet 2G/3G/LTE, ku nuk ka kërkesa të rrepta për autonomi dhe, si pasojë, nuk ka kufizime në kohëzgjatjen në eter dhe trafik. Për NB-IoT, këto metoda nuk janë të përshtatshme për shkak të konsumit të lartë të energjisë.
SCEF zgjidh këtë problem: pasi identifikuesi i vetëm i pajisjes për AS është identifikuesi i jashtëm, AS mjafton të dërgojë një paketë të dhënash në SCEF për identifikuesin e jashtëm të caktuar, ndërsa SCEF do të kujdeset për të gjitha gjërat e tjera. Nëse pajisja është në modalitetin e kursimit të energjisë PSM ose eDRX, të dhënat do të ruhen në kujtesë dhe do të dërgohen kur pajisja bëhet e disponueshme. Nëse pajisja është e qasshme për trafik, të dhënat do të dërgohen menjëherë. Kjo vlen edhe për komandat e menaxhimit.
Në çdo moment, AS mund të tërheqë mesazhin e ruajtur në drejtim të UE ose ta zëvendësojë me një të re.
Mekanizmi i ruajtjes gjithashtu mund të aplikohet edhe për transmetimin e të dhënave MO nga UE në AS. Nëse SCEF nuk arrin të dërgojë të dhënat në AS menjëherë, për shembull, nëse janë duke u kryer punime shërbimi në serverët e AS, këto paketa do të ruhen në kujtesë dhe do të dërgohen me siguri sapo AS të bëhet e disponueshme.
Siç u përmend më sipër, qasja në një shërbim të caktuar dhe UE për AS (dhe NIDD – është një shërbim), rregullohet nga rregullat dhe politikat nga ana e SCEF, që lejon realizimin e mundësisë unike të përdorimit të dhënave të një UE nga disa AS njëkohësisht. Kështu, nëse disa AS janë abonuar në një UE, pasi të marrin të dhënat nga UE, SCEF do t'i shpërndajë ato në të gjitha AS që janë abonuar. Kjo është e përshtatshme për raste kur krijuesi i një shtesi tëspecializuar pajisjesh ndan të dhënat midis disa klientëve. Për shembull, duke krijuar një rrjet stacionesh meteorologjike që funksionojnë me NB-IoT, është e mundur të shiten të dhënat nga ato për shumë shërbime njëkohësisht.
Mekanizmi i dorëzimit të garantuar të mesazheve
Shërbimi i Dhënave të Besueshme — mekanizmi i dorëzimit të garantuar të mesazheve MO dhe MT pa përdorimin e algoritmeve të specializuara në nivelin e protokollit, si për shembull handshake në TCP. Funksionon duke përfshirë një flamur të veçantë në pjesën shërbyese të mesazhit gjatë shkëmbimit midis UE dhe SCEF. Aktivizimi ose jo i këtij mekanizmi gjatë transferimit të trafikut vendoset nga AS.
Nëse mekanizmi është aktivizuar, UE kur është e nevojshme për dorëzimin e garantuar të trafikut MO përfshin një flamur të veçantë në pjesën shërbyese të paketës. Kur merr një paketë të tillë, SCEF i përgjigjet UE me një konfirmim. Nëse UE nuk ka marrë paketën me konfirmimin, paketa në drejtim të SCEF do të përsëritet. E njëjta gjë ndodh edhe për trafikun MT.
Monitorimi i pajisjeve (monitoring events- MONTE)
Siç u tha më lart, funksionaliteti i SCEF, përveç të tjerave, përfshin funksionet e kontrollit të gjendjes së UE, të ashtuquajturin monitorim të pajisjeve. Dhe nëse identifikuesit dhe mekanizmat e rinj të transferimit të të dhënave janë optimizime (edhe pse shumë të rëndësishme) të procedurave ekzistuese, MONTE është një funksionalitet krejtësisht i ri, që nuk është i disponueshëm në rrjetet 2G/3G/LTE. MONTE lejon AS të ndjekë parameteret e tilla të pajisjes si statusi i lidhjes, disponueshmëria për komunikim, vendndodhja, statusi i roamingut etj. Do të flasim më në detaje për secilën pak më vonë.
Nëse është e nevojshme të aktivizoni ndonjë ngjarje monitorimi për një pajisje ose grup pajisjesh, AS bëhet anëtar i shërbimit përkatës duke dërguar në SCEF një komandë përkatëse API MONTE, e cila përfshin parametra të tillë si external Id ose external group ID, identifikuesin AS, tipin e monitorimit, numrin e raporteve që AS dëshiron të marrë. Nëse AS është e autorizuar për të kryer kërkesën, SCEF, në varësi të tipit, provizionon ngjarjen në HSS ose MME (shih. 4). Kur ndodh ngjarja, MME ose HSS gjenerojnë një raport në drejtim të SCEF, i cili e dërgon atë te AS.
Provizionimi i të gjitha ngjarjeve, përveç "Numri i UE-ve të pranishëm në një zonë gjeografike", ndodh përmes HSS. Dy ngjarjet "Ndryshimi i IMSI-IMEI Asociacionit" dhe "Statusi i Roamingut" përcaktohen drejtpërdrejt në HSS, ndërsa të tjera HSS i provizionon në MME.
Ngjarjet mund të jenë si një herë, ashtu edhe periodike, dhe janë të kushtëzuara nga tipi i tyre.

Reportimi i ngjarjes (reportimi) kryhet nga nodi që ndjek ngjarjen drejtpërdrejt në SCEF (shih. 5).

Një pikë e rëndësishme: ngjarjet e monitorimit mund të përdoren si për pajisjet non-IP të lidhura përmes SCEF, ashtu edhe për pajisjet IP që dërgojnë të dhëna në mënyrën tradicionale përmes MME-SGW-PGW.
Le të shqyrtojmë më në detaje secilën nga ngjarjet e monitorimit:
Humbja e lidhjes – njofton AS-në se UE nuk është më e доступshme për as data trafikun as për shkëmbimin e sinjaleve. Ngjarja ndodh kur ora "mobile reachability timer" për UE përfundon në MME. Në kërkesën për këtë lloj monitorimi, AS mund të specifikojë vlerën e tij "Koha Maksimale e Zbulimit" - nëse gjatë kësaj kohe UE nuk tregon asnjë aktivitet, AS do të njoftohet se UE nuk është e доступshme, me shpjegimin e arsyes. Ngjarja gjithashtu ndodh nëse UE është hequr me forcë nga rrjeti për ndonjë arsye.
* Që rrjeti të dijë se pajisja është ende e доступshme, ajo niset periodikisht procedurën e përditësimit - Tracking Area Update (TAU). Frekuenca e kësaj procedure përcaktohet nga rrjeti përmes timer-it T3412 ose (T3412_extended në rastin e PSM), vlera e të cilit i dërgohet pajisjes gjatë procedurës Attach ose TAU të radhës. Ora e arritjes së telefonit zakonisht është disa minuta më e madhe se T3412. Nëse UE nuk bën TAU përpara skadimit të "Mobile reachability timer", rrjeti e konsideron atë si më të недоступshme.
Arsimi i aksesit të UE – Tregon kur UE bëhet e доступshme për DL trafik ose SMS. Kjo ndodh kur UE bëhet e доступshme për pagimin (për UE në modin e eDRX) ose kur UE kalon në modin ECM-CONNECTED (për UE në modin PSM ose eDRX), dmth. bën TAU ose dërgon një paketë uplink.
Raportimi i vendndodhjes – Ky lloj ngjarjeje monitorimi lejon AS që të kërkojë të dhëna mbi vendndodhjen e UE. Mund të kërkohet ose vendndodhja aktuale (Current Location), ose vendndodhja e fundit e njohur (Last Known Location, e përcaktuar nga ID e celularit nga i cili pajisja bëri TAU ose dërgoi trafik për herë të fundit), e cila është e rëndësishme për pajisjet në mënyrat e kursimit të energjisë PSM ose eDRX. Për "Current Location" AS mund të kërkojë raporte të përsëritura, ndërsa MME do të informojë AS çdo herë që ndryshon vendndodhja e pajisjes.
Ndryshimi i Asociacionit IMSI-IMEI – Kur aktivizimi i këtij eventi, SCEF fillon të ndjekë ndryshimin e lidhjes IMSI (identifikuesi i kartës SIM) dhe IMEI (identifikuesi i pajisjes). Në rastin e këtij eventi — informon AS. Mund të përdoret për ribindjen automatike të ID-së ekstern te pajisja gjatë punimeve planifikuara për zëvendësim ose si identifikues i vjedhjes së pajisjes.
Statusi i Roaming – ky tip monitorimi përdoret nga AS për të përcaktuar nëse UE ndodhet në rrjetin e saj të shtëpisë apo në rrjetin e partnerit të roaming. Opcionalisht, mund të dërgohet PLMN (Rrjeti Publik i Mobilit) të operatorit, në të cilin pajisja është regjistruar.
Dështimi i komunikimit — Ky tip monitorimi informon AS për dështimet në komunikim me pajisjen, duke u bazuar në arsyet e ndërprerjes së lidhjes (release cause code) të marra nga rrjeti i aksesit radio (protokolli S1-AP). Ky eveniment mund të ndihmojë në përcaktimin e arsyes së dështimit të komunikimit — për shkak të problemeve në rrjet, për shembull, në rast të ngarkesës së eNodeb (Burimet radio janë të paavailable) ose për shkak të dështimit të vetë pajisjes (Lidhja radio me UE e humbur).
Disponueshmëria pas dështimit DDN – ky eveniment informon AS se pajisja është bërë e disponueshme pas një dështimi të komunikimit. Mund të përdoret kur është e nevojshme të dërgohen të dhëna në pajisje, por tentativa e mëparshme nuk kishte qenë e suksesshme, pasi UE nuk iu përgjigj njoftimit nga rrjeti (paging), dhe të dhënat nuk u dorëzuan. Nëse ky tip monitorimi u kërkua për UE, atëherë sapo pajisja të realizojë një komunikim hyrës, të bëjë TAU, ose të dërgojë të dhëna në uplink, AS do të informohet se pajisja është bërë e disponueshme. Që procedura DDN (njoftimi i të dhënave downstream) funksionon midis MME dhe S/P-GW, ky lloj monitorimi është i disponueshëm vetëm për pajisjet IP.
Statusi i lidhjes PDN – informon AS për ndryshimin e statusit të pajisjes (statusi i lidhjes PDN) — lidhjes (aktivizimit të PDN) ose çtensionimit (heqjes së PDN). Kjo mund të përdoret nga AS për të iniciuar komunikimin me UE, ose anasjelltas, për të kuptuar se komunikimi nuk është më i mundur. Ky tip monitorimi është i disponueshëm për pajisjet IP dhe non-IP.
Numri i UEs të pranishëm në një zonë gjeografike – ky tip monitorimi përdoret nga AS për të përcaktuar numrin e UE në një zonë të caktuar gjeografike.
Aktivizimi i pajisjeve)
Në rrjetet 2G/3G, procedura e regjistrimit në rrjet ishte dyfishore: së pari, pajisja regjistrohej në SGSN (procedura attach), pastaj, kur ishte e nevojshme për të transmetuar të dhëna, aktivizonte PDP context – lidhjen me portën e paketave (GGSN). Në rrjetet 3G, këto dy procedura zhvilloheshin njëra pas tjetrës, pra pajisja nuk priste momentin që të transmetonte të dhëna, por aktivizonte PDP menjëherë pas përfundimit të procedurës attach. Në LTE, këto dy procedura ishin kombinuar në një, dmth gjatë attach, pajisja menjëherë kërkonte aktivizimin e lidhjes PDN (analog PDP në 2G/3G) përmes eNodeB në MME-SGW-PGW.
Në NB-IoT është përcaktuar një mënyrë bashkimi, siç është “attach without PDN”, dmth UE bën attach pa vendosur një lidhje PDN. Në këtë rast, ajo nuk është e disponueshme për transmetimin e trafikut dhe mund vetëm të pranojë ose dërgojë SMS. Për të transmetuar një komandë në një pajisje të tillë për aktivizimin e PDN dhe lidhjes në AS — është zhvilluar funksionaliteti “Device triggering”.
Kur merr komandën për lidhjen e këtij UE nga AS, SCEF përmes qendrës SMS inicon dërgimin e një SMS menaxhuese në pajisje. Kur pajisja merr SMS-në, ajo aktivizon PDN dhe lidhet me AS për të marrë udhëzime të mëtejshme ose për të transmetuar të dhëna.
Mund të ndodhin raste kur në SCEF skadon abonimi për pajisjen. Po, abonimi ka një kohëzgjatje të caktuar, e cila është vendosur nga operatori ose u miratua me AS. Pasi të skadojë, PDN në MME do të deaktivizohet dhe pajisja do të bëhet e paaksesueshme për AS. Në këtë rast, gjithashtu ndihmon funksionaliteti “Device triggering”. Kur merr të dhëna të reja nga AS, SCEF do të zbulojë statusin e lidhjes së pajisjes dhe do t'i dërgojë të dhënat përmes kanaleve SMS.
Përfundim
Funksionaliteti SCEF, sigurisht që nuk është i kufizuar vetëm në shërbimet e përmendura më sipër dhe vazhdon të evoluoni dhe të zgjerohet. Aktualisht, për SCEF janë standardizuar më shumë se një dhjetë shërbime. Tani ne preku vetëm funksionet kryesore dhe të kërkuara nga zhvilluesit, për të tjerat do të flasim në artikujt e ardhshëm.
Menjëherë lind pyetja, si të merrni akses testues në këtë ‘mrekulli’ të nodit për testimin paraprak dhe debugging të mundshëm të rasteve? E gjithë kjo është shumë e thjeshtë. Çdo zhvillues mund të dërgojë një kërkesë në iot.info@mts.ru, në të cilën mjafton të tregoni qëllimin e lidhjes, përshkrimin e mundshëm të rastit dhe informacionin e kontaktit për lidhje.
Në takim të ardhshëm!
Autorët:
- ekspert i lartë i zgjidhjeve konvergjente dhe shërbimeve multimedia, Sergey Novikov ,
- ekspert i zgjidhjeve konvergjente dhe shërbimeve multimedia, Aleksey Lapshin
Burimi: habr.com
