NB-IoT: ал кантип иштейт? 3-бөлүк: SCEF – оператор кызматтарына кирүүнүн бирдиктүү терезеси

Макалада “NB-IoT: ал кантип иштейт? 2 бөлүк", NB-IoT тармагынын пакеттик өзөгүнүн архитектурасы жөнүндө айтып жатып, биз жаңы SCEF түйүнүнүн пайда болушун айттык. Үчүнчү бөлүктө бул эмне экенин жана эмне үчүн керек экенин түшүндүрөбүз?

M2M кызматын түзүп жатканда, тиркемени иштеп чыгуучулар төмөнкү суроолорго туш болушат:

• түзмөктөрдү кантип аныктоо керек;
• кандай текшерүү жана аутентификация алгоритмин колдонуу керек;
• түзмөктөр менен иштешүү үчүн кайсы транспорттук протоколду тандоо керек;
• түзмөктөргө маалыматтарды кантип ишенимдүү жеткирүү керек;
• алар менен маалымат алмашуу эрежелерин кантип уюштуруу жана белгилөө;
• кантип мониторинг жүргүзүү жана алардын абалы жөнүндө маалыматты онлайн алуу;
• кантип бир эле учурда сиздин түзмөктөр тобуна маалыматтарды жеткирүү;
• бир түзмөктөн бир нече кардарларга маалыматтарды кантип жөнөтүү керек;
• аппаратыңызды башкаруу үчүн кошумча оператор кызматтарына бирдиктүү мүмкүнчүлүк алуу үчүн.

Аларды чечүү үчүн, эмгек чыгымдарынын жана рынокко чейин кызмат көрсөтүүлөрдүн көбөйүшүнө алып келген менчик техникалык "оор" чечимдерди түзүү зарыл. Бул жерде жаңы SCEF түйүнү жардамга келет.

3GPP аныктагандай, SCEF (кызмат мүмкүнчүлүктөрүн ачуу функциясы) 3GPP архитектурасынын таптакыр жаңы компоненти болуп саналат, анын милдети API аркылуу 3GPP тармак интерфейстери тарабынан берилген кызматтарды жана мүмкүнчүлүктөрдү коопсуз ачып берүү.

Жөнөкөй сөз менен айтканда, SCEF тармак менен тиркеме серверинин (AS) ортосундагы ортомчу, интуитивдик, стандартташтырылган API интерфейси аркылуу NB-IoT тармагындагы M2M түзмөгүңүздү башкаруу үчүн оператор кызматтарына кирүүнүн бирдиктүү терезеси.

SCEF оператордун тармагынын татаалдыгын жашырып, тиркемени иштеп чыгуучуларга түзмөктөр менен иштешүүнүн татаал, түзмөккө тиешелүү механизмдерин абстракциялоого мүмкүндүк берет.

Тармак протоколдорун тиркемелерди иштеп чыгуучулар үчүн тааныш APIге айландыруу менен, SCEF API жаңы кызматтарды түзүүгө көмөктөшөт жана рынокко чыгуу убактысын кыскартат. Жаңы түйүн ошондой эле мобилдик түзүлүштөрдү идентификациялоо/аутентификациялоо, түзүлүш менен АС ортосунда маалымат алмашуу эрежелерин аныктоо, тиркемени иштеп чыгуучуларды бул функцияларды өз тарабында ишке ашыруу зарылдыгынан бошотуу, бул функцияларды оператордун мойнуна которуу функцияларын камтыйт.

SCEF тиркемелердин серверлерин аутентификациялоо жана авторизациялоо, UE мобилдүүлүгүн колдоо, маалыматтарды берүү жана түзмөктү ишке киргизүү, кошумча кызматтарга жетүү жана оператор тармагынын мүмкүнчүлүктөрү үчүн зарыл болгон интерфейстерди камтыйт.

AS үчүн бирдиктүү T8 интерфейси, 3GPP тарабынан стандартташтырылган API (HTTP/JSON) бар. T8ден башка бардык интерфейстер DIAMETER протоколунун негизинде иштейт (1-сүрөт).

T6a – SCEF жана MME ортосундагы интерфейс. Мобилдүүлүк/сессияны башкаруу процедуралары, IP эмес маалыматтарды берүү, мониторинг окуяларын камсыздоо жана алар боюнча отчетторду алуу үчүн колдонулат.

S6t – SCEF жана HSS ортосундагы интерфейс. Абоненттин аутентификациясы, тиркеме серверлерин авторизациялоо, тышкы ID жана IMSI/MSISDN комбинациясын алуу, мониторинг окуяларын камсыздоо жана алар боюнча отчетторду алуу үчүн талап кылынат.

S6m/T4 – SCEFтен HSS жана SMS-Cге чейинки интерфейстер (3GPP MTC-IWF түйүнүн аныктайт, ал NB-IoT тармактарында түзмөктү триггерлөө жана SMS жөнөтүү үчүн колдонулат. Бирок, бардык ишке ашырууларда бул түйүндүн функционалы интеграцияланган. SCEF, ошондуктан схеманы жөнөкөйлөтүү үчүн, биз аны өзүнчө карап көрбөйбүз). SMS жөнөтүү жана SMS борбору менен иштешүү үчүн маршруттук маалымат алуу үчүн колдонулат.

T8 – SCEF колдонмо серверлери менен өз ара аракеттенүү үчүн API интерфейси. Башкаруу буйруктары да, трафик да ушул интерфейс аркылуу берилет.

*чындыгында бул жерде эң негизгилери гана келтирилген; Толук тизме 3GPP 23.682 (4.3.2 Маалымдама пункттарынын тизмеси) берилген.

Төмөндө SCEFтин негизги функциялары жана кызматтары келтирилген:

• SIM карта идентификаторун (IMSI) тышкы ID менен байланыштыруу;
• IP эмес трафикти берүү (Non-IP Data Delivery, NIDD);
• тышкы топтун идентификаторун колдонуу менен топтук операциялар;
• тастыктоо менен маалыматтарды берүү режимин колдоо;
• MO (Mobile Originated) жана MT (Mobile Terminated) маалыматтарын буферлөө;
• түзмөктөрдүн жана колдонмо серверлеринин аутентификациясы жана авторизациясы;
• бир UEден алынган маалыматтарды бир нече АС тарабынан бир убакта колдонуу;
• UE абалына мониторинг жүргүзүү үчүн атайын функцияларды колдоо (MONTE – Мониторинг окуялары);
• аппаратты ишке киргизүү;
• IP эмес маалыматтар роумингди камсыз кылуу.

AS жана SCEF ортосундагы өз ара аракеттенүүнүн негизги принциби схема деп аталган нерсеге негизделген. жазылуулар. Эгерде конкреттүү UE үчүн кандайдыр бир SCEF кызматына жетүү керек болсо, тиркеме сервери суралган кызматтын конкреттүү API'сине буйрук жөнөтүү аркылуу жазылууну түзүшү жана жооп катары уникалдуу идентификаторду алышы керек. Андан кийин, бул кызматтын алкагында UE менен кийинки бардык аракеттер жана байланыштар ушул идентификатордун жардамы менен ишке ашат.

Тышкы ID: Универсалдуу түзмөк идентификатору

SCEF аркылуу иштөөдө АС менен түзүлүштөрдүн өз ара аракеттенүү схемасындагы эң маанилүү өзгөрүүлөрдүн бири универсалдуу идентификатордун пайда болушу болуп саналат. Эми классикалык 2G/3G/LTE тармагындагыдай телефон номеринин (MSISDN) же IP даректин ордуна, тиркеме сервери үчүн түзмөк идентификатору "тышкы ID" болуп калат. Бул тиркемени иштеп чыгуучуларга тааныш форматта стандарт менен аныкталат " @ "

Иштеп чыгуучуларга түзмөктүн аутентификациясынын алгоритмдерин ишке ашыруунун кереги жок; тармак бул функцияны толугу менен өзүнө алат. Тышкы ID IMSI менен байланышкан жана иштеп чыгуучу белгилүү бир тышкы идентификаторго киргенде, ал белгилүү бир SIM карта менен иштешет деп ишене алат. SIM чипти колдонууда, тышкы ID белгилүү бир түзүлүштү уникалдуу түрдө аныктаганда, сиз толугу менен уникалдуу кырдаалга ээ болосуз!

Мындан тышкары, бир нече тышкы идентификаторлорду бир IMSI менен байланыштырса болот - андан да кызыктуу жагдай тышкы ID белгилүү бир түзмөктөгү белгилүү бир кызмат үчүн жооптуу конкреттүү тиркемени уникалдуу түрдө аныктаганда пайда болот.

Топтун идентификатору да пайда болот - тышкы топтун идентификатору, ал жеке тышкы идентификаторлордун топтомун камтыйт. Эми, SCEFке бир суроо менен, AS топтук операцияларды башташы мүмкүн - маалыматтарды же башкаруу буйруктарын бир логикалык топко бириктирилген бир нече түзмөктөргө жөнөтүү.

AS иштеп чыгуучулары үчүн жаңы түзмөк идентификаторуна өтүү заматта болушу мүмкүн эместигине байланыштуу, SCEF AS стандарттык номери - MSISDN аркылуу UE менен байланышуу мүмкүнчүлүгүн калтырды.

IP эмес трафикти берүү (Non-IP Data Delivery, NIDD)

NB-IoTде аз көлөмдөгү маалыматтарды берүү механизмдерин оптималдаштыруунун алкагында IPv4, IPv6 жана IPv4v6 сыяктуу PDN түрлөрүнөн тышкары дагы бир түрү пайда болду - IP эмес. Бул учурда түзмөккө (UE) IP дареги ыйгарылбайт жана маалыматтар IP протоколун колдонбостон өткөрүлүп берилет. Мындай байланыштар үчүн трафик эки жол менен багытталышы мүмкүн: классикалык - MME -> SGW -> PGW жана андан кийин PtP туннели аркылуу AS (2-сүрөт) же SCEF (3-сүрөт) аркылуу.

Классикалык ыкма IP-трафиктен эч кандай өзгөчө артыкчылыктарды бербейт, IP аталыштарынын жоктугуна байланыштуу берилүүчү пакеттердин өлчөмүн азайтуу. SCEFти колдонуу бир катар жаңы мүмкүнчүлүктөрдү ачат жана түзүлүштөр менен өз ара аракеттенүү процедураларын кыйла жөнөкөйлөтөт.

SCEF аркылуу маалыматтарды өткөрүп жатканда классикалык IP трафикке караганда эки маанилүү артыкчылык пайда болот:


Тышкы ID аркылуу аппаратка MT трафикти жеткирүү

Классикалык IP түзмөккө билдирүү жөнөтүү үчүн, AS анын IP дарегин билиши керек. Бул жерде көйгөй келип чыгат: каттоодон өткөндө түзмөк адатта "боз" IP дарегин алгандыктан, ал NAT түйүнү аркылуу Интернетте жайгашкан тиркеме сервери менен байланышат, анда боз дарек ак түскө которулат. Боз жана ак IP даректеринин айкалышы NAT жөндөөлөрүнө жараша чектелген убакытка созулат. Орточо алганда, TCP же UDP үчүн - беш мүнөттөн ашык эмес. Башкача айтканда, 5 мүнөттүн ичинде бул түзмөк менен маалымат алмашуу болбосо, туташуу бузулат жана аппарат AS менен сеанс башталган ак даректе жеткиликтүү болбой калат. бир нече чечимдер бар:

1. Жүрөктүн согушун колдонуңуз. Туташуу орнотулгандан кийин, аппарат AS менен пакеттерди бир нече мүнөт сайын алмаштырып турууга тийиш, ошону менен NAT котормолорун жабууга жол бербейт. Бирок бул жерде эч кандай энергетикалык натыйжалуулук жөнүндө сөз болушу мүмкүн эмес.

2. Ар бир жолу, эгерде зарыл болсо, AS боюнча түзүлүш үчүн пакеттердин бар-жоктугун текшериңиз - линияга билдирүү жөнөтүңүз.

3. Жеке APN (VRF) түзүңүз, анда тиркеме сервери жана түзмөктөр бир эле ички тармакта болот жана түзмөктөргө статикалык IP даректерди дайындаңыз. Бул иштей берет, бирок биз миңдеген, он миңдеген аппараттар паркы жөнүндө сөз кылып жатканда, бул дээрлик мүмкүн эмес.

4. Акырында, эң ылайыктуу вариант: IPv6 колдонуу, ал NAT талап кылбайт, анткени IPv6 даректери Интернеттен түз жеткиликтүү. Бирок, бул учурда да, аппарат кайра каттоодон өткөндө, ал жаңы IPv6 дарегин алат жана мурунку дарегин колдонууга мүмкүн болбой калат.

Демек, аппараттын жаңы IP дареги жөнүндө кабарлоо үчүн серверге түзмөктүн идентификатору менен инициализациялоо пакетин жөнөтүү керек. Андан кийин AS тастыктоочу пакетти күтүңүз, бул да энергиянын натыйжалуулугуна таасирин тийгизет.

Бул ыкмалар 2G/3G/LTE түзмөктөрүндө жакшы иштейт, мында аппараттын автономияга катуу талаптары жок жана натыйжада эфир убактысына жана трафикке эч кандай чектөөлөр жок. Бул ыкмалар NB-IoT үчүн ылайыктуу эмес, анткени алардын энергия керектөөлөрү жогору.

SCEF бул көйгөйдү чечет: AS үчүн жалгыз түзмөк идентификатору тышкы ID болгондуктан, AS белгилүү бир тышкы ID үчүн SCEFге маалымат пакетин жөнөтүшү керек, ал эми калганын SCEF чечет. Түзмөк PSM же eDRX энергияны үнөмдөө режиминде болсо, маалымат буферге салынып, аппарат жеткиликтүү болгондо жеткирилет. Эгер аппарат трафик үчүн жеткиликтүү болсо, маалыматтар дароо жеткирилет. Башкаруучу коллективдерге да ушун-дай.

Каалаган убакта AS буфердик билдирүүнү UEге чакырып алат же аны жаңысына алмаштыра алат.

Буферлөө механизми МО маалыматтарын UEден АСга өткөрүп жатканда да колдонулушу мүмкүн. Эгерде SCEF АСга маалыматтарды дароо жеткире албаса, мисалы, AS серверлеринде техникалык тейлөө иштери жүрүп жатса, бул пакеттер буферделет жана AS жеткиликтүү болгондон кийин жеткирилет.

Жогоруда белгиленгендей, АС үчүн белгилүү бир кызматка жана UEге жетүү (жана NIDD бул кызмат) SCEF тарабындагы эрежелер жана саясаттар менен жөнгө салынат, бул бир UEден бир нече АС тарабынан бир эле учурда маалыматтарды колдонуунун уникалдуу мүмкүнчүлүгүн берет. Ошол. эгерде бир нече АС бир ББга жазылган болсо, анда ББден маалыматтарды алгандан кийин, SCEF аны бардык жазылган АСга жөнөтөт. Бул адистештирилген түзмөктөрдүн паркын түзүүчү бир нече кардарлардын ортосунда маалыматтарды бөлүштүргөн учурларда абдан ылайыктуу. Мисалы, NB-IoTде иштеген метеостанциялардын тармагын түзүү менен, сиз алардан маалыматтарды бир эле учурда көптөгөн кызматтарга сата аласыз.

Кепилденген кабар жеткирүү механизми

Reliable Data Service – бул, мисалы, TCPде кол алышуу сыяктуу, протокол деңгээлинде адистештирилген алгоритмдерди колдонбостон, MO жана MT билдирүүлөрүн кепилденген жеткирүү механизми. Ал UE жана SCEF ортосунда алмашуу учурунда билдирүүнүн тейлөө бөлүгүнө атайын желекти кошуу менен иштейт. Трафикти өткөрүүдө бул механизмди иштетүү керекпи же жокпу, аны АС чечет.

Эгерде механизм иштетилсе, UE MO трафигинин кепилденген жеткирүүсүн талап кылган учурда пакеттин үстүнкү бөлүгүндө атайын желекти камтыйт. Мындай пакетти алгандан кийин, SCEF UEге тастыктоо менен жооп берет. Эгерде UE тастыктоо пакетин албаса, SCEFке пакет кайра жөнөтүлөт. Ушундай эле нерсе MT трафик үчүн да болот.

Түзмөккө мониторинг (окуяларды көзөмөлдөө - MONTE)

Жогоруда айтылгандай, SCEF функционалдуулугу башка нерселер менен катар UE абалына мониторинг жүргүзүү функцияларын камтыйт, деп аталган. түзмөк мониторинги. Ал эми жаңы идентификаторлор жана маалыматтарды берүү механизмдери учурдагы процедуралардын оптималдаштыруусу (өтө олуттуу болсо да) болсо, анда MONTE 2G/3G/LTE тармактарында жок таптакыр жаңы функция. MONTE ASга туташуу статусу, байланыштын жеткиликтүүлүгү, жайгашкан жери, роуминг статусу ж.б. сыяктуу түзмөктүн параметрлерин көзөмөлдөөгө мүмкүндүк берет. Ар бири жөнүндө бир аздан кийин кененирээк сүйлөшөбүз.

Түзмөк же түзмөктөр тобу үчүн ар кандай мониторинг окуясын активдештирүү зарыл болсо, AS тышкы Id же тышкы топ ID, AS идентификатору, мониторинг сыяктуу параметрлерди камтыган SCEFге тиешелүү API MONTE буйругун жөнөтүү аркылуу тиешелүү кызматка жазылат. AS алууну каалаган отчеттордун түрү, саны. Эгерде АС суроо-талапты аткарууга ыйгарым укуктуу болсо, SCEF түрүнө жараша окуяны HSS же MMEге берет (4-сүрөт). Окуя болгондо, MME же HSS SCEFке отчет түзөт, ал аны ASке жөнөтөт.

"Географиялык аймактагы UE санынан" башка бардык окуяларды камсыздоо HSS аркылуу ишке ашат. Эки окуя "IMSI-IMEI ассоциациясынын өзгөрүшү" жана "Роуминг статусу" түздөн-түз HSSде көзөмөлдөнөт, калгандары MMEде HSS тарабынан камсыз кылынат.
Окуялар бир жолку же мезгилдүү болушу мүмкүн жана алардын түрү боюнча аныкталат.

Окуя жөнүндө отчетту жөнөтүү (отчет берүү) окуяны түздөн-түз SCEFге байкоочу түйүн тарабынан ишке ашырылат (5-сүрөт).

Бир маанилүү жагдай бар: Мониторинг окуялары SCEF аркылуу туташтырылган IP эмес түзмөктөргө да, MME-SGW-PGW аркылуу классикалык жол менен маалыматтарды өткөрүүчү IP түзмөктөргө да колдонулушу мүмкүн.

Келгиле, мониторинг окуяларынын ар бирин кененирээк карап чыгалы:

байланышты жоготуу — АСга маалымат трафиги же сигнализация үчүн UE мындан ары жеткиликтүү эместигин билдирет. Окуя MMEде UE үчүн "мобилдик жеткиликтүүлүк таймеринин" мөөнөтү аяктаганда пайда болот. Мониторингдин бул түрүнө суроо-талапта АС өзүнүн “Максималдуу аныктоо убактысы” маанисин көрсөтө алат - эгерде бул убакыттын ичинде UE эч кандай активдүүлүк көрсөтпөсө, АС себебин көрсөтүү менен UE жеткиликтүү эместиги жөнүндө кабарланат. Окуя ошондой эле UE кандайдыр бир себептерден улам тармак тарабынан күч менен алынып салынган болсо пайда болот.

* Түзмөк дагы эле жеткиликтүү экенин тармакка билдирүү үчүн, ал мезгил-мезгили менен жаңыртуу процедурасын баштайт - Tracking Area Update (TAU). Бул процедуранын жыштыгы тармак тарабынан T3412 же (PSM учурда T3412_extended) таймеринин жардамы менен белгиленет, анын мааниси Тиркеме процедурасы же кийинки TAU учурунда аппаратка берилет. Мобилдик жеткиликтүүлүк таймери адатта T3412ге караганда бир нече мүнөткө узунураак. Эгерде UE "Мобилдик жеткиликтүүлүк таймеринин" мөөнөтү аяктаганга чейин TAU жасабаса, тармак аны мындан ары жеткиликсиз деп эсептейт.

UE жеткиликтүүлүгү - UE DL трафик же SMS үчүн жеткиликтүү болгондо көрсөтөт. Бул UE пейджинг үчүн жеткиликтүү болгондо (eDRX режиминдеги UE үчүн) же UE ECM-CONNECTED режимине киргенде (PSM же eDRX режиминдеги UE үчүн), б.а. TAU түзөт же uplink пакетин жөнөтөт.

Жайгашкан жер жөнүндө кабарлоо – Мониторинг окуяларынын бул түрү АСга UE жайгашкан жерди суроого мүмкүндүк берет. Учурдагы жайгашкан жерди (Учурдагы жайгашкан жер) же акыркы белгилүү жайгашкан жерди (Акыркы Белгилүү Жайгашкан жер, түзмөк TAU жасаган же акыркы жолу трафик жөнөткөн уячанын идентификатору менен аныкталат) суралышы мүмкүн, бул PSM же eDRX энергияны үнөмдөөчү түзмөктөр үчүн тиешелүү. режимдери. "Учурдагы жайгашкан жер" үчүн AS кайра-кайра жоопторду сурай алат, MME аппараттын жайгашкан жери өзгөргөн сайын ASга кабарлайт.

IMSI-IMEI ассоциациясын өзгөртүү – Бул окуя иштетилгенде, SCEF IMSI (SIM карта идентификатору) жана IMEI (түзмөктүн идентификатору) айкалышындагы өзгөрүүлөргө мониторинг жүргүзө баштайт. Окуя болгондо, AS билдирет. Пландаштырылган алмаштыруу иштери учурунда тышкы идентификаторду түзмөккө автоматтык түрдө кайра байлоо үчүн же аппаратты уурдоо үчүн идентификатор катары колдонулушу мүмкүн.

Роуминг абалы – мониторингдин бул түрү AS тарабынан UE үй тармагында же роуминг өнөктөштүн тармагында экендигин аныктоо үчүн колдонулат. Каалоо боюнча, аппарат катталган оператордун PLMN (Коомдук жер мобилдик тармагы) берилиши мүмкүн.

Байланыш үзгүлтүккө учурады — Мониторингдин бул түрү радио жетүү тармагынан (S1-AP протоколу) алынган байланышты жоготуу себептеринин (чыгаруу себебинин коду) негизинде түзүлүш менен байланыштагы мүчүлүштүктөр жөнүндө АСга маалымдайт. Бул окуя байланыш эмне үчүн иштебей калганын аныктоого жардам берет - тармактагы көйгөйлөрдөн улам, мисалы, eNodeb ашыкча жүктөлгөндө (Радио ресурстары жеткиликсиз) же түзмөктүн өзүндө иштебей калгандыктан (UE жоголгон радио байланышы).

DDN катасынан кийин жеткиликтүүлүк – бул окуя байланыш үзгүлтүккө учурагандан кийин аппараттын жеткиликтүү болуп калгандыгы тууралуу AS билдирет. Түзмөккө берилиштерди өткөрүү зарылчылыгы болгондо колдонсо болот, бирок мурунку аракет ийгиликтүү болгон жок, анткени UE тармактан (пейджинг) эскертмеге жооп берген жок жана маалыматтар жеткирилбей калды. Мониторингдин бул түрү UE үчүн суралган болсо, анда аппарат кирүүчү байланышты жасап, TAU жасаса же жогорудагы линияга маалыматтарды жөнөтөөр замат, AS аппарат жеткиликтүү болуп калгандыгы жөнүндө кабарланат. DDN (downlink data notification) процедурасы MME жана S/P-GW ортосунда иштегендиктен, мониторингдин бул түрү IP түзмөктөр үчүн гана жеткиликтүү.

PDN байланыш абалы – аспаптын статусу өзгөргөндө (PDN байланыш абалы) - туташуу (PDN активдештирүү) же ажыратылганда (PDN өчүрүү) AS кабарлайт. Муну АС UE менен байланышты баштоо үчүн колдонсо болот, же тескерисинче, байланыш мындан ары мүмкүн эмес экенин түшүнүү үчүн. Мониторингдин бул түрү IP жана IP эмес түзмөктөр үчүн жеткиликтүү.

Географиялык аймакта бар UE саны – Мониторингдин бул түрү АС тарабынан белгилүү бир географиялык аймактагы ЭКС санын аныктоо үчүн колдонулат.

Түзмөктү ишке киргизүү)

2G/3G тармактарында тармакта каттоо процедурасы эки этаптуу болгон: биринчиден, SGSN менен катталган түзүлүш (тиркеме процедурасы), андан кийин зарыл болсо, PDP контекстти - пакет шлюзи (GGSN) менен байланышты активдештирген. маалыматтарды берүү. 3G тармактарында бул эки процедура ырааттуу түрдө болгон, б.а. түзмөк маалыматтарды өткөрүп берүү керек болгон учурду күткөн жок, бирок тиркеме процедурасы аяктагандан кийин дароо PDP иштетилди. LTEде бул эки процедура бириккен, башкача айтканда, тиркөө учурунда түзмөк дароо MME-SGW-PGWге eNodeB аркылуу PDN туташуусун (2G/3Gдеги PDP аналогу) активдештирүүнү суранган.

NB-IoT туташуу ыкмасын "PDNсиз тиркөө" деп аныктайт, башкача айтканда, UE PDN байланышын түзбөстөн тиркелет. Бул учурда, ал трафикти өткөрүү үчүн жеткиликтүү эмес, жана SMS гана кабыл же жөнөтө алат. Мындай түзүлүшкө PDNди активдештирүү жана ASга туташуу буйругун жөнөтүү үчүн “Түзмөктү ишке киргизүү” функционалы иштелип чыккан.

АСдан мындай UEди туташтыруу буйругун алганда, SCEF СМС борбору аркылуу аппаратка башкаруу SMS жөнөтүүнү баштайт. SMS кабыл алууда аппарат PDNди активдештирет жана андан аркы нускамаларды алуу же маалыматтарды өткөрүү үчүн ASга туташат.

SCEFде түзмөгүңүздүн жазылуу мөөнөтү бүтүп калган учурлар болушу мүмкүн. Ооба, жазылуу оператор тарабынан белгиленген же AS менен макулдашылган өзүнүн иштөө мөөнөтү бар. Мөөнөтү аяктагандан кийин, PDN MMEде өчүрүлөт жана аппарат AS үчүн жеткиликсиз болуп калат. Бул учурда, "Түзмөктү ишке киргизүү" функциясы да жардам берет. AS жаңы маалыматтарды алууда, SCEF аппараттын байланыш абалын билип, SMS каналы аркылуу маалыматтарды жеткирет.

жыйынтыктоо

SCEFтин функционалдуулугу, албетте, жогоруда айтылган кызматтар менен эле чектелбейт жана дайыма өнүгүп, кеңейип турат. Учурда ондон ашык кызматтар SCEF үчүн стандартташтырылган. Эми биз иштеп чыгуучулар тарабынан талап кылынган негизги функцияларга гана токтолдук, калгандары жөнүндө кийинки макалаларда сүйлөшөбүз.

Дароо суроо туулат: алдын ала тестирлөө жана мүмкүн болгон учурларды оңдоо үчүн бул "керемет" түйүнгө тесттик кирүү мүмкүнчүлүгүн кантип алууга болот? Баары абдан жөнөкөй. Ар бир иштеп чыгуучу iot.info@mts.ru дарегине суроо-талап жөнөтө алат, анда туташуунун максатын, мүмкүн болгон иштин сыпаттамасын жана байланыш үчүн байланыш маалыматын көрсөтүү жетиштүү.

Көрүшкөнгө чейин!

Авторлор:

• конвергенттик чечимдер жана мультимедиялык сервистер бөлүмүнүн улук эксперти Сергей Новиков санов,
• конвергенттик чечимдер жана мультимедиялык кызматтар бөлүмүнүн эксперти Алексей Лапшин aslapsh

Source: www.habr.com