NB-IoT: како функционира? Дел 3: SCEF – единствен прозорец за пристап до услугите на операторот

Во написот „NB-IoT: како функционира? Дел 2“, зборувајќи за архитектурата на јадрото на пакетите на мрежата NB-IoT, споменавме појава на нов SCEF јазол. Во третиот дел објаснуваме што е тоа и зошто е потребно?

Кога креирате услуга M2M, развивачите на апликации се соочуваат со следниве прашања:

• како да се идентификуваат уредите;
• кој алгоритам за верификација и автентикација да се користи;
• кој транспортен протокол да се избере за интеракција со уреди;
• како сигурно да се доставуваат податоци до уредите;
• како да се организираат и воспостават правила за размена на податоци со нив;
• како да се следи и да се добијат информации за нивната состојба на интернет;
• како истовремено да доставувате податоци до група ваши уреди;
• како истовремено да испраќате податоци од еден уред на неколку клиенти;
• како да добиете унифициран пристап до дополнителни услуги на операторот за управување со вашиот уред.

За да се решат, неопходно е да се создадат сопственички технички „тешки“ решенија, што доведува до зголемени трошоци за работна сила и услуги од време до пазарот. Ова е местото каде што новиот SCEF јазол доаѓа на помош.

Како што е дефинирано од 3GPP, SCEF (функција за изложување на можности за услуги) е сосема нова компонента на архитектурата 3GPP чија функција е безбедно да ги изложува услугите и можностите што ги обезбедуваат 3GPP мрежните интерфејси преку API.

Со едноставни зборови, SCEF е посредник помеѓу мрежата и апликативниот сервер (AS), единствен прозорец за пристап до услугите на операторот за управување со вашиот M2M уред во мрежата NB-IoT преку интуитивен, стандардизиран API интерфејс.

SCEF ја крие сложеноста на мрежата на операторот, дозволувајќи им на развивачите на апликации да ги апстрактираат сложените механизми специфични за уредот за интеракција со уредите.

Со трансформирање на мрежните протоколи во познато API за развивачите на апликации, SCEF API го олеснува создавањето на нови услуги и го намалува времето до пазар. Новиот јазол вклучува и функции за идентификација/автентикација на мобилни уреди, дефинирање на правилата за размена на податоци помеѓу уредот и АС, отстранување на потребата од развивачите на апликации да ги имплементираат овие функции на своја страна, префрлајќи ги овие функции на рамениците на операторот.

SCEF ги покрива интерфејсите неопходни за автентикација и овластување на апликативните сервери, одржување на мобилноста на UE, пренос на податоци и активирање на уредот, пристап до дополнителни услуги и можности за мрежни оператори.

Кон AS постои единствен интерфејс T8, API (HTTP/JSON) стандардизиран со 3GPP. Сите интерфејси, со исклучок на T8, работат врз основа на протоколот DIAMETER (сл. 1).

T6a – интерфејс помеѓу SCEF и MME. Се користи за процедури за управување со мобилност/сесии, пренос на податоци што не се IP, обезбедување на настани за следење и примање извештаи за нив.

S6t – интерфејс помеѓу SCEF и HSS. Потребно е за автентикација на претплатници, овластување на апликативни сервери, добивање комбинација на надворешен ID и IMSI/MSISDN, обезбедување на настани за следење и примање извештаи за нив.

S6m/T4 – интерфејси од SCEF до HSS и SMS-C (3GPP го дефинира MTC-IWF јазолот, кој се користи за активирање на уредот и пренос на SMS во NB-IoT мрежите. Меѓутоа, во сите имплементации функционалноста на овој јазол е интегрирана во SCEF, па за поедноставување на колото, нема да го разгледуваме одделно). Се користи за добивање информации за рутирање за испраќање СМС и интеракција со СМС центарот.

T8 – API интерфејс за SCEF интеракција со апликациски сервери. И контролните команди и сообраќајот се пренесуваат преку овој интерфејс.

*во реалноста има повеќе интерфејси тука се наведени само најосновните. Комплетна листа е дадена во 3GPP 23.682 (4.3.2 Листа на референтни точки).

Подолу се клучните функции и услуги на SCEF:

• поврзување на идентификаторот на SIM картичката (IMSI) со надворешен ID;
• пренос на сообраќај кој не е IP (Испорака на податоци без IP, NIDD);
• групни операции со користење на надворешен ID на групата;
• поддршка за режим на пренос на податоци со потврда;
• баферирање на податоци од MO (Mobile Originated) и MT (Mobile Terminated);
• автентикација и авторизација на уреди и сервери за апликации;
• истовремена употреба на податоци од еден UE од неколку AS;
• поддршка за специјални функции за следење на статусот на UE (MONTE – Monitoring Events);
• активирање на уредот;
• обезбедување роаминг на податоци без IP.

Основниот принцип на интеракција помеѓу AS и SCEF се заснова на т.н. претплати. Доколку е неопходно да се добие пристап до која било услуга SCEF за одредена UE, апликацискиот сервер треба да создаде претплата со испраќање команда до одреденото API на бараната услуга и да добие единствен идентификатор како одговор. По што сите понатамошни активности и комуникации со UE во рамките на оваа услуга ќе се одвиваат со користење на овој идентификатор.

Надворешен ID: Универзален идентификатор на уред

Една од најважните промени во шемата за интеракција помеѓу AS и уредите при работа преку SCEF е појавата на универзален идентификатор. Сега, наместо телефонски број (MSISDN) или IP адреса, како што беше случајот во класичната мрежа 2G/3G/LTE, идентификаторот на уредот за серверот на апликацијата станува „надворешен ID“. Тоа е дефинирано со стандардот во формат познат на развивачите на апликации “ @ "

Програмерите повеќе не треба да имплементираат алгоритми за автентикација на уредот, мрежата целосно ја презема оваа функција. Надворешниот ID е поврзан со IMSI, а развивачот може да биде сигурен дека кога пристапува до одреден надворешен ID, тој има интеракција со одредена SIM-картичка. Кога користите SIM чип, добивате сосема уникатна ситуација кога надворешниот ID уникатно идентификува одреден уред!

Покрај тоа, неколку надворешни ИД може да се поврзат со еден IMSI - уште поинтересна ситуација се јавува кога надворешниот ID уникатно идентификува одредена апликација одговорна за одредена услуга на одреден уред.

Се појавува и идентификатор на група - надворешен идентификатор на групата, кој вклучува збир на поединечни надворешни ИД. Сега, со едно барање до SCEF, AS може да иницира групни операции - испраќање податоци или контролни команди до повеќе уреди обединети во една логичка група.

Поради фактот што за програмерите на AS преминот кон нов идентификатор на уред не може да биде моментален, SCEF остави можност за AS комуникација со UE преку стандарден број - MSISDN.

Пренос на сообраќај кој не е IP (Испорака на податоци без IP, NIDD)

Во NB-IoT, како дел од оптимизацијата на механизмите за пренос на мали количини на податоци, покрај веќе постоечките PDN типови, како што се IPv4, IPv6 и IPv4v6, се појави уште еден тип - не-IP. Во овој случај, на уредот (UE) не му е доделена IP адреса и податоците се пренесуваат без користење на IP протоколот. Сообраќајот за такви врски може да се насочува на два начина: класичен - MME -> SGW -> PGW и потоа преку PtP тунелот до AS (сл. 2) или со користење на SCEF (сл. 3).

Класичниот метод не нуди никакви посебни предности во однос на IP сообраќајот, освен намалување на големината на пренесените пакети поради отсуството на IP заглавија. Употребата на SCEF отвора голем број нови можности и значително ги поедноставува процедурите за интеракција со уредите.

При пренос на податоци преку SCEF, се појавуваат две многу важни предности во однос на класичниот IP сообраќај:


Испорака на MT сообраќај до уредот преку надворешен ID

За да испрати порака до класичен 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 треба само да испрати пакет податоци до SCEF за одреден надворешен ID, а SCEF се грижи за останатото. Во случај уредот да е во режим за заштеда на енергија PSM или eDRX, податоците ќе бидат зачувани и испорачани кога уредот ќе стане достапен. Ако уредот е достапен за сообраќај, податоците ќе бидат доставени веднаш. Истото важи и за менаџерските тимови.

Во секое време, AS може да се потсети на буферираната порака до UE или да ја замени со нова.

Механизмот за тампонирање може да се користи и при пренос на MO податоци од UE до AS. Ако SCEF не можеше веднаш да достави податоци до AS, на пример, ако работите за одржување се во тек на серверите на AS, овие пакети ќе бидат во бафер и ќе се гарантира дека ќе бидат испорачани веднаш штом AS стане достапен.

Како што е наведено погоре, пристапот до одредена услуга и UE за AS (и NIDD е услуга) е регулиран со правила и политики на страната SCEF, што овозможува единствена можност за истовремена употреба на податоци од еден UE од страна на неколку AS. Оние. ако неколку AS се претплатени на еден UE, тогаш по добивањето податоци од UE, SCEF ќе ги испрати до сите претплатени AS. Ова е добро прилагодено за случаи кога создавачот на флота од специјализирани уреди споделува податоци помеѓу неколку клиенти. На пример, со создавање мрежа на метеоролошки станици што работат на NB-IoT, можете да продавате податоци од нив на многу услуги истовремено.

Загарантиран механизам за испорака на пораки

Сигурна услуга за податоци е механизам за гарантирана испорака на MO и MT пораки без употреба на специјализирани алгоритми на ниво на протокол, како што е, на пример, ракување во TCP. Работи со вклучување на специјално знаменце во сервисниот дел од пораката кога се разменува помеѓу UE и SCEF. Дали да се активира овој механизам при пренос на сообраќај одлучува АС.

Ако механизмот е активиран, UE вклучува специјално знаменце во надземниот дел од пакетот кога бара гарантирана испорака на сообраќајот на MO. По приемот на таков пакет, SCEF одговара на UE со потврда. Ако UE не го прими пакетот за потврда, пакетот кон SCEF ќе биде повторно испратен. Истото се случува и за сообраќајот на МТ.

Следење на уредот (следење на настани - MONTE)

Како што споменавме погоре, функционалноста SCEF, меѓу другото, вклучува функции за следење на состојбата на UE, т.н. следење на уредот. И ако новите идентификатори и механизмите за пренос на податоци се оптимизација (иако многу сериозни) на постоечките процедури, тогаш MONTE е сосема нова функционалност која не е достапна во мрежите 2G/3G/LTE. MONTE овозможува AS да ги следи параметрите на уредот како што се статусот на конекцијата, достапноста на комуникацијата, локацијата, статусот на роаминг итн. Ќе разговараме за секој подетално малку подоцна.

Доколку е неопходно да се активира кој било настан за следење за уред или група уреди, AS се претплати на соодветната услуга со испраќање на соодветната команда API MONTE до SCEF, која вклучува параметри како што се надворешен ID или надворешен ID на групата, AS идентификатор, мониторинг тип, број на извештаи кои АС сака да ги прима. Ако AS е овластен да го изврши барањето, SCEF, во зависност од видот, ќе го обезбеди настанот до HSS или MME (сл. 4). Кога ќе се случи настан, MME или HSS генерира извештај до SCEF, кој го испраќа до AS.

Обезбедувањето на сите настани, со исклучок на „Број на UE присутни во географска област“, ​​се случува преку HSS. Два настани „Промена на асоцијацијата IMSI-IMEI“ и „Статус на роаминг“ се следат директно на HSS, а останатите ќе бидат обезбедени од HSS на MME.
Настаните можат да бидат еднократни или периодични и се одредуваат според нивниот тип.

Испраќањето извештај за настан (известување) го врши јазолот што го следи настанот директно до SCEF (сл. 5).

Важна точка: Настаните за следење може да се применат и на уредите што не се IP поврзани преку SCEF и на IP уредите кои пренесуваат податоци на класичен начин преку MME-SGW-PGW.

Ајде внимателно да го разгледаме секој од настаните за следење:

Губење на поврзување — го информира AS дека UE повеќе не е достапен ниту за сообраќај на податоци ниту за сигнализација. Настанот се случува кога „тајмерот за достапност на мобилниот“ за UE истекува на MME. Во барањето за овој тип на мониторинг, AS може да ја означи својата вредност „Максимално време за откривање“ - ако за ова време UE не покаже никаква активност, AS ќе биде информиран дека UE е недостапен, наведувајќи ја причината. Настанот, исто така, се случува ако UE беше насилно отстранет од мрежата поради која било причина.

* За да ја извести мрежата дека уредот е сè уште достапен, таа периодично започнува процедура за ажурирање - Ажурирање област за следење (TAU). Фреквенцијата на оваа постапка ја поставува мрежата користејќи тајмер T3412 или (T3412_extended во случај на PSM), чија вредност се пренесува на уредот за време на процедурата Прикачи или следниот TAU. Тајмерот за достапност на мобилниот телефон обично е неколку минути подолг од T3412. Ако UE не направил TAU пред истекот на „Тајмерот за достапност за мобилни телефони“, мрежата смета дека повеќе не е достапно.

UE достапност – Покажува кога UE станува достапен за DL сообраќај или SMS. Ова се случува кога UE станува достапен за страничење (за UE во режим eDRX) или кога UE влегува во режим ECM-CONNECTED (за UE во режим PSM или eDRX), т.е. прави TAU или испраќа пакет за надоврзување.

Известување за локација – Овој тип на настани за следење му овозможува на AS да ја бара локацијата на UE. Може да се побара или тековната локација (Тековна локација) или последната позната локација (одредена со ID на ќелијата од која уредот направи TAU или пренесе сообраќај последен пат), што е релевантно за уредите во режими за заштеда на енергија PSM или eDRX. За „Тековна локација“, AS може да бара повторени одговори, при што MME го известува AS секој пат кога се менува локацијата на уредот.

Промена на Здружението IMSI-IMEI – Кога овој настан е активиран, SCEF започнува да ги следи промените во комбинацијата на IMSI (идентификатор на SIM картичка) и IMEI (идентификатор на уред). Кога ќе се случи некој настан, информира АС. Може да се користи за автоматско повторно поврзување на надворешен ID на уред за време на закажаната работа за замена или да служи како идентификатор за кражба на уред.

Статус на роаминг – овој тип на мониторинг го користи AS за да утврди дали UE е во домашната мрежа или во мрежата на партнер во роаминг. Изборно, може да се пренесе PLMN (Јавна копнена мобилна мрежа) на операторот во кој е регистриран уредот.

Неуспех во комуникацијата — Овој тип на мониторинг го информира AS за неуспеси во комуникацијата со уредот, врз основа на причините за губење на врската (шифра за причина за ослободување) добиени од мрежата за радио пристап (S1-AP протокол). Овој настан може да помогне да се утврди зошто комуникацијата не успеа - поради проблеми на мрежата, на пример, кога eNodeb е преоптоварен (Радио ресурсите не се достапни) или поради дефект на самиот уред (Радио поврзување со UE Lost).

Достапност по неуспехот на DDN – овој настан го информира AS дека уредот стана достапен по дефект на комуникацијата. Може да се користи кога има потреба од пренос на податоци на уред, но претходниот обид не беше успешен бидејќи UE не одговори на известување од мрежата (страница) и податоците не беа доставени. Ако овој тип на следење е побаран за UE, тогаш штом уредот направи дојдовна комуникација, направи TAU или испрати податоци до нагорната врска, AS ќе биде информиран дека уредот станал достапен. Бидејќи постапката DDN (известување за податоци за преземање) работи помеѓу MME и S/P-GW, овој тип на следење е достапен само за IP уреди.

Статус на поврзување со PDN – го информира AS кога се менува статусот на уредот (статусот на конективност PDN) - поврзување (активирање PDN) или исклучување (бришење PDN). Ова може да го искористи AS за да започне комуникација со UE, или обратно, за да разбере дека комуникацијата повеќе не е можна. Овој тип на мониторинг е достапен за IP и не-IP уреди.

Број на UE присутни во географска област – Овој тип на мониторинг го користи АС за одредување на бројот на УЕ во одредена географска област.

Активирање на уредот)

Во мрежите 2G/3G, процедурата за регистрација во мрежата беше двостепена: прво, уредот се регистрираше со SGSN (постапка за прикачување), потоа, доколку е потребно, го активираше контекстот PDP - поврзување со портата за пакети (GGSN). за пренос на податоци. Во 3G мрежите овие две постапки се случуваа последователно, т.е. уредот не го чекаше моментот кога требаше да префрли податоци, туку го активираше PDP веднаш по завршувањето на постапката за прикачување. Во LTE, овие две постапки беа комбинирани во една, односно при прикачување, уредот веднаш побара активирање на PDN конекцијата (аналогно на PDP во 2G/3G) преку eNodeB на MME-SGW-PGW.

NB-IoT го дефинира методот на поврзување како „прикачи без PDN“, односно UE се прикачува без воспоставување на PDN врска. Во овој случај, не е достапно за пренос на сообраќај, и може само да прима или испраќа СМС. Со цел да се испрати команда до таков уред за активирање на PDN и поврзување со AS, беше развиена функционалноста „Активирање на уредот“.

Кога добивате команда за поврзување на таков UE од AS, SCEF иницира испраќање на контролна SMS порака до уредот преку СМС центарот. Кога прима SMS, уредот го активира PDN и се поврзува со AS за да прима дополнителни инструкции или да пренесува податоци.

Може да има моменти кога претплатата на вашиот уред истекува на SCEF. Да, претплатата има свој животен век, поставен од операторот или договорен со AS. По истекот, PDN ќе се деактивира на MME и уредот ќе стане недостапен за AS. Во овој случај, функционалноста „Активирање на уредот“ исто така ќе помогне. Кога примате нови податоци од AS, SCEF ќе го дознае статусот на конекцијата на уредот и ќе ги достави податоците преку SMS канал.

Заклучок

Функционалноста на SCEF, се разбира, не е ограничена само на услугите опишани погоре и постојано се развива и проширува. Во моментов, повеќе од десетина услуги се веќе стандардизирани за SCEF. Сега ги допревме само главните функции што се бараат од програмерите, ќе зборуваме за останатите во следните написи.

Веднаш се поставува прашањето: како да се добие тест пристап до овој „чудотворен“ јазол за прелиминарно тестирање и дебагирање на можни случаи? Сè е многу едноставно. Секој развивач може да испрати барање до iot.info@mts.ru, во кое е доволно да се наведе целта на врската, опис на можниот случај и информации за контакт за комуникација.

До следниот пат!

Авторите:

• виш експерт на одделот за конвергентни решенија и мултимедијални услуги Сергеј Новиков санов,
• експерт на одделот за конвергентни решенија и мултимедијални услуги Алексеј Лапшин аслапш

Извор: www.habr.com