Sa artikulong "", na pinag-uusapan ang arkitektura ng packet core ng NB-IoT network, binanggit namin ang hitsura ng isang bagong SCEF node. Ipinapaliwanag namin sa ikatlong bahagi kung ano ito at bakit ito kinakailangan?
Kapag gumagawa ng serbisyo ng M2M, nahaharap ang mga developer ng application sa mga sumusunod na tanong:
- kung paano makilala ang mga aparato;
- anong algorithm sa pagpapatunay at pagpapatunay ang gagamitin;
- aling transport protocol ang pipiliin para sa pakikipag-ugnayan sa mga device;
- kung paano mapagkakatiwalaang maghatid ng data sa mga device;
- kung paano ayusin at magtatag ng mga patakaran para sa pakikipagpalitan ng data sa kanila;
- kung paano masubaybayan at makakuha ng impormasyon tungkol sa kanilang kalagayan online;
- kung paano sabay na maghatid ng data sa isang pangkat ng iyong mga device;
- kung paano sabay na magpadala ng data mula sa isang device patungo sa ilang kliyente;
- kung paano makakuha ng pinag-isang access sa mga karagdagang serbisyo ng operator para sa pamamahala ng iyong device.
Upang malutas ang mga ito, kinakailangan na lumikha ng pagmamay-ari na teknikal na "mabigat" na mga solusyon, na humahantong sa pagtaas ng mga gastos sa paggawa at mga serbisyo sa oras-sa-market. Dito nagliligtas ang bagong SCEF node.
Gaya ng tinukoy ng 3GPP, ang SCEF (service capability exposure function) ay isang ganap na bagong bahagi ng arkitektura ng 3GPP na ang tungkulin ay ligtas na ilantad ang mga serbisyo at kakayahan na ibinigay ng mga interface ng network ng 3GPP sa pamamagitan ng mga API.
Sa madaling salita, ang SCEF ay isang tagapamagitan sa pagitan ng network at ng application server (AS), isang window ng pag-access sa mga serbisyo ng operator para sa pamamahala ng iyong M2M device sa NB-IoT network sa pamamagitan ng intuitive, standardized na interface ng API.
Itinatago ng SCEF ang pagiging kumplikado ng network ng operator, na nagbibigay-daan sa mga developer ng application na i-abstract ang mga kumplikadong mekanismong partikular sa device para sa pakikipag-ugnayan sa mga device.
Sa pamamagitan ng pagbabago ng mga network protocol sa isang pamilyar na API para sa mga developer ng application, pinapadali ng SCEF API ang paglikha ng mga bagong serbisyo at binabawasan ang oras-sa-market. Kasama rin sa bagong node ang mga function para sa pagtukoy/pag-authenticate ng mga mobile device, pagtukoy sa mga panuntunan para sa pagpapalitan ng data sa pagitan ng device at AS, pag-alis ng pangangailangan para sa mga developer ng application na ipatupad ang mga function na ito sa kanilang panig, paglilipat ng mga function na ito sa mga balikat ng operator.
Sinasaklaw ng SCEF ang mga interface na kinakailangan para sa pagpapatunay at awtorisasyon ng mga server ng application, pagpapanatili ng kadaliang kumilos ng UE, paglilipat ng data at pag-trigger ng device, pag-access sa mga karagdagang serbisyo at mga kakayahan sa network ng operator.
Patungo sa AS mayroong isang T8 interface, isang API (HTTP/JSON) na na-standardize ng 3GPP. Ang lahat ng mga interface, maliban sa T8, ay gumagana batay sa DIAMETER protocol (Larawan 1).
T6a – interface sa pagitan ng SCEF at MME. Ginagamit para sa mga pamamaraan sa pamamahala ng Mobility/Session, paghahatid ng data na hindi IP, paglalaan ng mga kaganapan sa pagsubaybay at pagtanggap ng mga ulat sa mga ito.
S6t – interface sa pagitan ng SCEF at HSS. Kinakailangan para sa pagpapatunay ng subscriber, awtorisasyon ng mga server ng application, pagkuha ng kumbinasyon ng panlabas na ID at IMSI/MSISDN, pagbibigay ng mga kaganapan sa pagsubaybay at pagtanggap ng mga ulat tungkol sa mga ito.
S6m/T4 – mga interface mula sa SCEF hanggang HSS at SMS-C (tinukoy ng 3GPP ang MTC-IWF node, na ginagamit para sa pag-trigger ng device at pagpapadala ng SMS sa mga network ng NB-IoT. Gayunpaman, sa lahat ng pagpapatupad ang functionality ng node na ito ay isinama sa SCEF, kaya para sa pagpapasimple ng circuit, hindi namin ito isasaalang-alang nang hiwalay). Ginagamit upang makakuha ng impormasyon sa pagruruta para sa pagpapadala ng SMS at pakikipag-ugnayan sa SMS center.
T8 – API interface para sa pakikipag-ugnayan ng SCEF sa mga server ng application. Ang parehong mga control command at trapiko ay ipinapadala sa pamamagitan ng interface na ito.
*sa katotohanan ay mayroong higit pang mga interface; tanging ang mga pinakapangunahing interface lamang ang nakalista dito. Ang isang kumpletong listahan ay ibinibigay sa 3GPP 23.682 (4.3.2 Listahan ng mga Reference Points).
Nasa ibaba ang mga pangunahing tungkulin at serbisyo ng SCEF:
- pag-link ng SIM card identifier (IMSI) sa panlabas na ID;
- paghahatid ng trapikong hindi IP (Paghahatid ng Data na Hindi IP, NIDD);
- pagpapatakbo ng grupo gamit ang panlabas na ID ng grupo;
- suporta para sa mode ng paghahatid ng data na may kumpirmasyon;
- buffering ng MO (Mobile Originated) at MT (Mobile Terminated) data;
- pagpapatunay at awtorisasyon ng mga device at application server;
- sabay-sabay na paggamit ng data mula sa isang UE ng ilang ASes;
- suporta para sa mga espesyal na UE status monitoring function (MONTE – Monitoring Events);
- pag-trigger ng device;
- pagbibigay ng non-IP data roaming.
Ang pangunahing prinsipyo ng pakikipag-ugnayan sa pagitan ng AS at SCEF ay batay sa tinatawag na iskema. mga subscription. Kung kinakailangan upang makakuha ng access sa anumang serbisyo ng SCEF para sa isang partikular na UE, ang server ng application ay kailangang gumawa ng isang subscription sa pamamagitan ng pagpapadala ng isang command sa partikular na API ng hiniling na serbisyo at makatanggap ng isang natatanging identifier bilang tugon. Pagkatapos nito, ang lahat ng karagdagang pagkilos at pakikipag-ugnayan sa UE sa loob ng balangkas ng serbisyong ito ay magaganap gamit ang identifier na ito.
Panlabas na ID: Pangkalahatang pagkakakilanlan ng device
Ang isa sa pinakamahalagang pagbabago sa scheme ng pakikipag-ugnayan sa pagitan ng AS at mga device kapag nagtatrabaho sa pamamagitan ng SCEF ay ang hitsura ng isang unibersal na identifier. Ngayon, sa halip na isang numero ng telepono (MSISDN) o IP address, tulad ng nangyari sa classic na 2G/3G/LTE network, ang device identifier para sa application server ay nagiging “external ID”. Tinutukoy ito ng pamantayan sa format na "@" na pamilyar sa mga developer ng application.
Hindi na kailangan ng mga developer na magpatupad ng mga algorithm ng pagpapatunay ng device; ganap na inaako ng network ang function na ito. Nakatali ang External ID sa IMSI, at matitiyak ng developer na kapag nag-a-access ng partikular na external ID, nakikipag-ugnayan ito sa isang partikular na SIM card. Kapag gumagamit ng SIM chip, nakakakuha ka ng ganap na kakaibang sitwasyon kapag ang panlabas na ID ay natatanging kinikilala ang isang partikular na device!
Bukod dito, maraming mga panlabas na ID ang maaaring maiugnay sa isang IMSI - ang isang mas kawili-wiling sitwasyon ay lumitaw kapag ang panlabas na ID ay natatanging kinikilala ang isang partikular na application na responsable para sa isang partikular na serbisyo sa isang partikular na device.
May lalabas ding group identifier - external group ID, na kinabibilangan ng set ng mga indibidwal na external ID. Ngayon, sa isang kahilingan sa SCEF, maaaring simulan ng AS ang mga pagpapatakbo ng grupo - pagpapadala ng data o control command sa maraming device na pinagsama sa isang lohikal na grupo.
Dahil sa katotohanan na para sa mga developer ng AS ang paglipat sa isang bagong identifier ng device ay hindi maaaring maging madalian, iniwan ng SCEF ang posibilidad ng AS na komunikasyon sa UE sa pamamagitan ng isang karaniwang numero - MSISDN.
Paghahatid ng hindi IP na trapiko (Non-IP Data Delivery, NIDD)
Sa NB-IoT, bilang bahagi ng pag-optimize ng mga mekanismo para sa pagpapadala ng maliit na halaga ng data, bilang karagdagan sa mga umiiral nang uri ng PDN, tulad ng IPv4, IPv6 at IPv4v6, lumitaw ang isa pang uri - hindi IP. Sa kasong ito, ang device (UE) ay hindi nakatalaga ng isang IP address at ang data ay ipinapadala nang hindi gumagamit ng IP protocol. Ang trapiko para sa mga naturang koneksyon ay maaaring iruta sa dalawang paraan: classic - MME -> SGW -> PGW at pagkatapos ay sa pamamagitan ng PtP tunnel patungo sa AS (Fig. 2) o gamit ang SCEF (Fig. 3).
Ang klasikong pamamaraan ay hindi nag-aalok ng anumang mga espesyal na pakinabang sa trapiko ng IP, maliban sa pagbawas ng laki ng mga ipinadalang packet dahil sa kawalan ng mga header ng IP. Ang paggamit ng SCEF ay nagbubukas ng ilang bagong posibilidad at makabuluhang pinapasimple ang mga pamamaraan para sa pakikipag-ugnayan sa mga device.
Kapag nagpapadala ng data sa pamamagitan ng SCEF, lumalabas ang dalawang napakahalagang bentahe sa klasikong trapiko ng IP:
Paghahatid ng MT traffic sa device sa pamamagitan ng external ID
Upang magpadala ng mensahe sa isang klasikong IP device, dapat malaman ng AS ang IP address nito. Dito lumitaw ang isang problema: dahil ang aparato ay karaniwang tumatanggap ng isang "grey" na IP address sa pagpaparehistro, nakikipag-ugnayan ito sa server ng application, na matatagpuan sa Internet, sa pamamagitan ng isang NAT node, kung saan ang kulay abong address ay isinalin sa puti. Ang kumbinasyon ng kulay abo at puting mga IP address ay tumatagal ng limitadong panahon, depende sa mga setting ng NAT. Sa karaniwan, para sa TCP o UDP - hindi hihigit sa limang minuto. Ibig sabihin, kung walang palitan ng data sa device na ito sa loob ng 5 minuto, magwawakas ang koneksyon at hindi na maa-access ang device sa puting address kung saan sinimulan ang session sa AS. Mayroong ilang mga solusyon:
1. Gumamit ng tibok ng puso. Kapag naitatag na ang isang koneksyon, ang aparato ay dapat makipagpalitan ng mga packet sa AS bawat ilang minuto, sa gayon ay mapipigilan ang pagsara ng mga pagsasalin ng NAT. Ngunit hindi maaaring pag-usapan ang anumang kahusayan sa enerhiya dito.
2. Sa bawat oras, kung kinakailangan, suriin ang pagkakaroon ng mga pakete para sa device sa AS - magpadala ng mensahe sa uplink.
3. Gumawa ng pribadong APN (VRF), kung saan ang server ng application at mga device ay nasa parehong subnet, at magtalaga ng mga static na IP address sa mga device. Gagana ito, ngunit halos imposible kapag pinag-uusapan natin ang tungkol sa isang fleet ng libu-libo, sampu-sampung libong mga aparato.
4. Panghuli, ang pinaka-angkop na opsyon: gumamit ng IPv6, hindi ito nangangailangan ng NAT, dahil ang mga IPv6 address ay direktang naa-access mula sa Internet. Gayunpaman, kahit na sa kasong ito, kapag muling nairehistro ang device, makakatanggap ito ng bagong IPv6 address at hindi na maa-access gamit ang nauna.
Alinsunod dito, kinakailangang magpadala ng ilang initialization packet na may device identifier sa server upang maiulat ang bagong IP address ng device. Pagkatapos ay maghintay para sa isang pakete ng kumpirmasyon mula sa AS, na nakakaapekto rin sa kahusayan ng enerhiya.
Ang mga pamamaraang ito ay gumagana nang maayos para sa mga 2G/3G/LTE na device, kung saan ang device ay walang mahigpit na kinakailangan para sa awtonomiya at, bilang resulta, walang mga paghihigpit sa airtime at trapiko. Ang mga pamamaraang ito ay hindi angkop para sa NB-IoT dahil sa kanilang mataas na pagkonsumo ng enerhiya.
Niresolba ng SCEF ang problemang ito: dahil ang tanging identifier ng device para sa isang AS ay isang panlabas na ID, kailangan lang ng AS na magpadala ng data packet sa SCEF para sa isang partikular na panlabas na ID, at ang SCEF ang bahala sa iba. Kung sakaling ang device ay nasa PSM o eDRX power saving mode, ang data ay mabu-buffer at maihahatid kapag ang device ay naging available. Kung available ang device para sa trapiko, ihahatid kaagad ang data. Ang parehong ay totoo para sa mga pangkat ng pamamahala.
Sa anumang oras, maaaring ma-recall ng AS ang naka-buffer na mensahe sa UE o palitan ito ng bago.
Ang mekanismo ng buffering ay maaari ding gamitin kapag nagpapadala ng MO data mula sa UE patungo sa AS. Kung hindi agad nakapaghatid ang SCEF ng data sa AS, halimbawa kung nagpapatuloy ang maintenance work sa mga server ng AS, ang mga packet na ito ay mabu-buffer at magagarantiyang maihahatid sa sandaling maging available ang AS.
Gaya ng nabanggit sa itaas, ang pag-access sa isang partikular na serbisyo at UE para sa isang AS (at ang NIDD ay isang serbisyo) ay kinokontrol ng mga patakaran at patakaran sa panig ng SCEF, na nagbibigay-daan para sa natatanging posibilidad ng sabay-sabay na paggamit ng data mula sa isang UE ng ilang AS. Yung. kung maraming AS ang nag-subscribe sa isang UE, pagkatapos matanggap ang data mula sa UE, ipapadala ito ng SCEF sa lahat ng naka-subscribe na AS. Ito ay angkop na angkop para sa mga kaso kung saan ang lumikha ng isang fleet ng mga dalubhasang device ay nagbabahagi ng data sa pagitan ng ilang mga kliyente. Halimbawa, sa pamamagitan ng paglikha ng isang network ng mga istasyon ng panahon na tumatakbo sa NB-IoT, maaari kang magbenta ng data mula sa kanila sa maraming serbisyo nang sabay-sabay.
Garantiyang mekanismo ng paghahatid ng mensahe
Ang Maaasahang Serbisyo ng Data ay isang mekanismo para sa garantisadong paghahatid ng mga mensahe ng MO at MT nang hindi gumagamit ng mga espesyal na algorithm sa antas ng protocol, tulad ng, halimbawa, pakikipagkamay sa TCP. Gumagana ito sa pamamagitan ng pagsasama ng isang espesyal na bandila sa bahagi ng serbisyo ng mensahe kapag ipinagpalit sa pagitan ng UE at SCEF. Ang AS ay magpapasya kung isaaktibo o hindi ang mekanismong ito kapag nagpapadala ng trapiko.
Kung ang mekanismo ay isinaaktibo, ang UE ay nagsasama ng isang espesyal na bandila sa itaas na bahagi ng packet kapag nangangailangan ito ng garantisadong paghahatid ng MO na trapiko. Sa pagtanggap ng naturang packet, ang SCEF ay tumugon sa UE na may isang pagkilala. Kung hindi natanggap ng UE ang acknowledgement packet, ang packet patungo sa SCEF ay muling ipapadala. Ang parehong bagay ay nangyayari para sa MT traffic.
Pagsubaybay sa device (mga kaganapan sa pagsubaybay - MONTE)
Tulad ng nabanggit sa itaas, ang SCEF functionality, bukod sa iba pang mga bagay, ay kinabibilangan ng mga function para sa pagsubaybay sa estado ng UE, ang tinatawag na. pagmamanman ng device. At kung ang mga bagong identifier at mekanismo ng paglilipat ng data ay mga pag-optimize (bagaman napakaseryoso) ng mga kasalukuyang pamamaraan, ang MONTE ay isang ganap na bagong functionality na hindi available sa 2G/3G/LTE network. Binibigyang-daan ng MONTE ang AS na subaybayan ang mga parameter ng device gaya ng status ng koneksyon, availability ng komunikasyon, lokasyon, status ng roaming, atbp. Pag-uusapan natin ang bawat isa nang mas detalyado sa ibang pagkakataon.
Kung kinakailangang i-activate ang anumang kaganapan sa pagsubaybay para sa isang device o pangkat ng mga device, nagsu-subscribe ang AS sa kaukulang serbisyo sa pamamagitan ng pagpapadala ng kaukulang API MONTE command sa SCEF, na kinabibilangan ng mga parameter gaya ng external Id o external group ID, AS identifier, monitoring uri, bilang ng mga ulat, na gustong matanggap ng AS. Kung pinahintulutan ang AS na isagawa ang kahilingan, ibibigay ng SCEF, depende sa uri, ang kaganapan sa HSS o MME (Fig. 4). Kapag naganap ang isang kaganapan, ang MME o HSS ay bumubuo ng isang ulat sa SCEF, na nagpapadala nito sa AS.
Ang pagbibigay ng lahat ng mga kaganapan, maliban sa "Bilang ng mga UE na naroroon sa isang heyograpikong lugar", ay nangyayari sa pamamagitan ng HSS. Dalawang kaganapan na "Pagbabago ng IMSI-IMEI Association" at "Roaming Status" ay direktang sinusubaybayan sa HSS, ang iba ay ibibigay ng HSS sa MME.
Ang mga kaganapan ay maaaring minsanan o pana-panahon, at natutukoy ayon sa kanilang uri.
Ang pagpapadala ng ulat tungkol sa isang kaganapan (pag-uulat) ay isinasagawa ng node na direktang sumusubaybay sa kaganapan sa SCEF (Larawan 5).
Mahalagang punto: Maaaring ilapat ang mga kaganapan sa pagsubaybay sa parehong mga non-IP device na konektado sa pamamagitan ng SCEF at mga IP device na nagpapadala ng data sa klasikong paraan sa pamamagitan ng MME-SGW-PGW.
Tingnan natin ang bawat isa sa mga kaganapan sa pagsubaybay:
Pagkawala ng koneksyon — nagpapaalam sa AS na ang UE ay hindi na magagamit para sa alinman sa trapiko ng data o pagsenyas. Nagaganap ang kaganapan kapag ang "mobile reachability timer" para sa UE ay nag-expire sa MME. Sa isang kahilingan para sa ganitong uri ng pagsubaybay, maaaring ipahiwatig ng AS ang halaga nito na "Maximum Detection Time" - kung sa panahong ito ang UE ay hindi nagpapakita ng anumang aktibidad, ipapaalam sa AS na ang UE ay hindi available, na nagsasaad ng dahilan. Nagaganap din ang kaganapan kung ang UE ay sapilitang inalis ng network sa anumang dahilan.
* Para ipaalam sa network na available pa rin ang device, pana-panahon itong nagpapasimula ng pamamaraan sa pag-update - Tracking Area Update (TAU). Ang dalas ng pamamaraang ito ay itinakda ng network gamit ang timer T3412 o (T3412_extended sa kaso ng PSM), ang halaga nito ay ipinadala sa device sa panahon ng Attach procedure o sa susunod na TAU. Ang mobile reachability timer ay karaniwang mas mahaba ng ilang minuto kaysa sa T3412. Kung ang UE ay hindi nakagawa ng TAU bago ang pag-expire ng "Mobile reachability timer", itinuturing ng network na hindi na ito maaabot.
UE reachability – Isinasaad kung kailan magiging available ang UE para sa DL traffic o SMS. Ito ay nangyayari kapag ang UE ay naging available para sa paging (para sa isang UE sa eDRX mode) o kapag ang UE ay pumasok sa ECM-CONNECTED mode (para sa isang UE sa PSM o eDRX mode), i.e. gumagawa ng TAU o nagpapadala ng uplink packet.
Pag-uulat ng lokasyon – Ang ganitong uri ng mga kaganapan sa pagsubaybay ay nagpapahintulot sa AS na i-query ang lokasyon ng UE. Maaaring hilingin ang kasalukuyang lokasyon (Kasalukuyang Lokasyon) o ang huling alam na lokasyon (Tinukoy ng cell ID kung saan ginawa ang TAU o ipinadalang trapiko sa huling pagkakataon), na may kaugnayan para sa mga device sa PSM o eDRX na power saving mode. Para sa "Kasalukuyang Lokasyon", ang AS ay maaaring humiling ng mga paulit-ulit na tugon, kasama ang MME na nagpapaalam sa AS sa tuwing nagbabago ang lokasyon ng device.
Pagbabago ng IMSI-IMEI Association – Kapag na-activate ang kaganapang ito, magsisimulang subaybayan ng SCEF ang mga pagbabago sa kumbinasyon ng IMSI (SIM card identifier) at IMEI (device identifier). Kapag naganap ang isang kaganapan, ipaalam sa AS. Maaaring gamitin upang awtomatikong i-rebind ang isang external na ID sa isang device sa panahon ng nakaiskedyul na pagpapalit ng trabaho o magsilbi bilang isang identifier para sa pagnanakaw ng isang device.
Katayuan ng Roaming – ang ganitong uri ng pagsubaybay ay ginagamit ng AS upang matukoy kung ang UE ay nasa home network o nasa network ng isang roaming partner. Opsyonal, ang PLMN (Public Land Mobile Network) ng operator kung saan nakarehistro ang device ay maaaring ipadala.
Kapalpakan sa komunikasyon — Ang ganitong uri ng pagsubaybay ay nagpapaalam sa AS tungkol sa mga pagkabigo sa komunikasyon sa device, batay sa mga dahilan ng pagkawala ng koneksyon (release cause code) na natanggap mula sa radio access network (S1-AP protocol). Makakatulong ang kaganapang ito na matukoy kung bakit nabigo ang komunikasyon - dahil sa mga problema sa network, halimbawa, kapag na-overload ang eNodeb (Hindi available ang mga mapagkukunan ng radyo) o dahil sa pagkabigo ng device mismo (Radio Connection With UE Lost).
Availability pagkatapos ng DDN Failure – ang kaganapang ito ay nagpapaalam sa AS na ang aparato ay naging available pagkatapos ng pagkabigo sa komunikasyon. Maaaring gamitin kapag may pangangailangang maglipat ng data sa isang device, ngunit hindi nagtagumpay ang nakaraang pagtatangka dahil hindi tumugon ang UE sa isang abiso mula sa network (paging) at hindi naihatid ang data. Kung ang ganitong uri ng pagsubaybay ay hiniling para sa UE, pagkatapos ay sa sandaling gumawa ang device ng papasok na komunikasyon, gumawa ng TAU o magpadala ng data sa uplink, ipapaalam sa AS na available na ang device. Dahil gumagana ang pamamaraan ng DDN (downlink data notification) sa pagitan ng MME at S/P-GW, available lang ang ganitong uri ng pagsubaybay para sa mga IP device.
Katayuan ng Pagkakakonekta ng PDN – nagpapaalam sa AS kapag nagbago ang status ng device (PDN connectivity status) - connection (PDN activation) o disconnection (PDN deletion). Ito ay maaaring gamitin ng AS upang simulan ang komunikasyon sa UE, o kabaliktaran, upang maunawaan na ang komunikasyon ay hindi na posible. Ang ganitong uri ng pagsubaybay ay available para sa mga IP at non-IP na device.
Bilang ng mga UE na naroroon sa isang heyograpikong lugar – Ang ganitong uri ng pagsubaybay ay ginagamit ng AS upang matukoy ang bilang ng mga UE sa isang partikular na heograpikal na lugar.
Pagti-trigger ng device)
Sa mga network ng 2G/3G, ang pamamaraan ng pagpaparehistro sa network ay dalawang yugto: una, ang aparato na nakarehistro sa SGSN (maglakip ng pamamaraan), pagkatapos, kung kinakailangan, isinaaktibo nito ang konteksto ng PDP - isang koneksyon sa packet gateway (GGSN) upang magpadala ng data. Sa mga 3G network, ang dalawang pamamaraang ito ay naganap nang sunud-sunod, i.e. hindi hinintay ng device ang sandali kung kailan kailangan nitong maglipat ng data, ngunit na-activate kaagad ang PDP pagkatapos makumpleto ang attach procedure. Sa LTE, ang dalawang pamamaraang ito ay pinagsama sa isa, iyon ay, kapag nag-attach, agad na hiniling ng device ang pag-activate ng koneksyon ng PDN (katulad ng PDP sa 2G/3G) sa pamamagitan ng eNodeB sa MME-SGW-PGW.
Tinutukoy ng NB-IoT ang isang paraan ng koneksyon bilang "mag-attach nang walang PDN", iyon ay, ang UE ay nakakabit nang hindi nagtatatag ng koneksyon sa PDN. Sa kasong ito, hindi ito magagamit upang magpadala ng trapiko, at maaari lamang tumanggap o magpadala ng SMS. Upang magpadala ng command sa naturang device para i-activate ang PDN at kumonekta sa AS, binuo ang functionality na "Device triggering."
Kapag tumatanggap ng command na ikonekta ang naturang UE mula sa AS, sinisimulan ng SCEF ang pagpapadala ng control SMS sa device sa pamamagitan ng SMS center. Kapag tumatanggap ng SMS, ina-activate ng device ang PDN at kumokonekta sa AS para makatanggap ng karagdagang mga tagubilin o maglipat ng data.
Maaaring may mga pagkakataong mag-e-expire ang iyong subscription sa device sa SCEF. Oo, ang subscription ay may sariling buhay, itinakda ng operator o sumang-ayon sa AS. Sa pag-expire, ide-deactivate ang PDN sa MME at magiging hindi available ang device sa AS. Sa kasong ito, makakatulong din ang functionality na "Pag-trigger ng device". Kapag tumatanggap ng bagong data mula sa AS, malalaman ng SCEF ang status ng koneksyon ng device at maghahatid ng data sa pamamagitan ng SMS channel.
Konklusyon
Ang functionality ng SCEF, siyempre, ay hindi limitado sa mga serbisyong inilarawan sa itaas at patuloy na umuunlad at lumalawak. Sa kasalukuyan, mahigit isang dosenang serbisyo ang na-standardize na para sa SCEF. Ngayon ay hinawakan lamang namin ang mga pangunahing pag-andar na hinihiling mula sa mga developer; pag-uusapan natin ang natitira sa mga artikulo sa hinaharap.
Ang tanong ay agad na lumitaw: kung paano makakuha ng pagsubok na access sa "himala" na node para sa paunang pagsubok at pag-debug ng mga posibleng kaso? Napakasimple ng lahat. Ang sinumang developer ay maaaring magsumite ng kahilingan sa [protektado ng email], kung saan ito ay sapat na upang ipahiwatig ang layunin ng koneksyon, isang paglalarawan ng isang posibleng kaso at impormasyon ng contact para sa komunikasyon.
Nakikita mo ulit!
Mga May-akda:
- senior expert ng departamento ng convergent solutions at multimedia services Sergey Novikov ,
- eksperto ng convergent solutions at multimedia services department Alexey Lapshin
Pinagmulan: www.habr.com