В статията „“, говорейки за архитектурата на пакетното ядро на мрежата NB-IoT, споменахме появата на нов SCEF възел. В третата част обясняваме какво представлява и защо е необходимо?
Когато създават M2M услуга, разработчиците на приложения са изправени пред следните въпроси:
- как да идентифицираме устройствата;
- какъв алгоритъм за проверка и удостоверяване да използвате;
- кой транспортен протокол да изберете за взаимодействие с устройства;
- как надеждно да доставяме данни до устройствата;
- как да организират и установят правила за обмен на данни с тях;
- как да наблюдават и получават информация за състоянието си онлайн;
- как едновременно да доставяте данни до група от вашите устройства;
- как едновременно да изпращате данни от едно устройство към няколко клиента;
- как да получите унифициран достъп до допълнителни операторски услуги за управление на вашето устройство.
За решаването им е необходимо да се създадат патентовани технически „тежки” решения, което води до увеличаване на разходите за труд и услуги във времето до пускане на пазара. Това е мястото, където новият възел SCEF идва на помощ.
Както е дефинирано от 3GPP, SCEF (функция за експониране на възможности за услуги) е напълно нов компонент на архитектурата на 3GPP, чиято функция е да излага сигурно услугите и възможностите, предоставени от мрежовите интерфейси на 3GPP чрез API.
С прости думи, SCEF е посредник между мрежата и сървъра на приложения (AS), един прозорец за достъп до услугите на оператора за управление на вашето M2M устройство в мрежата NB-IoT чрез интуитивен, стандартизиран API интерфейс.
SCEF скрива сложността на мрежата на оператора, позволявайки на разработчиците на приложения да абстрахират сложни, специфични за устройството механизми за взаимодействие с устройства.
Чрез трансформиране на мрежовите протоколи в познат API за разработчиците на приложения, SCEF API улеснява създаването на нови услуги и намалява времето за пускане на пазара. Новият възел също така включва функции за идентифициране/удостоверяване на мобилни устройства, определяне на правилата за обмен на данни между устройството и AS, премахване на необходимостта разработчиците на приложения да изпълняват тези функции от своя страна, прехвърляйки тези функции на раменете на оператора.
SCEF обхваща интерфейсите, необходими за удостоверяване и оторизация на сървъри за приложения, поддържане на UE мобилност, трансфер на данни и задействане на устройства, достъп до допълнителни услуги и възможности на операторската мрежа.
Към AS има единичен T8 интерфейс, API (HTTP/JSON), стандартизиран от 3GPP. Всички интерфейси, с изключение на T8, работят на базата на протокола DIAMETER (фиг. 1).
T6a – интерфейс между SCEF и MME. Използва се за процедури за управление на мобилност/сесия, предаване на не-IP данни, осигуряване на събития за наблюдение и получаване на отчети за тях.
S6t – интерфейс между SCEF и HSS. Изисква се за удостоверяване на абонати, оторизация на сървъри на приложения, получаване на комбинация от външен идентификатор и IMSI/MSISDN, осигуряване на събития за наблюдение и получаване на отчети за тях.
S6m/T4 – интерфейси от SCEF към HSS и SMS-C (3GPP дефинира възела MTC-IWF, който се използва за задействане на устройство и предаване на SMS в мрежи NB-IoT. Въпреки това във всички реализации функционалността на този възел е интегрирана в SCEF, така че за опростяване на веригата няма да я разглеждаме отделно). Използва се за получаване на информация за маршрутизиране за изпращане на SMS и взаимодействие с SMS центъра.
T8 – API интерфейс за SCEF взаимодействие със сървъри на приложения. Както командите за управление, така и трафикът се предават през този интерфейс.
*в действителност има повече интерфейси; тук са изброени само най-основните. Пълният списък е даден в 3GPP 23.682 (4.3.2 Списък на референтни точки).
По-долу са основните функции и услуги на SCEF:
- свързване на идентификатора на SIM картата (IMSI) с външен идентификатор;
- предаване на не-IP трафик (Non-IP Data Delivery, NIDD);
- групови операции с използване на външен идентификатор на група;
- поддръжка на режим на предаване на данни с потвърждение;
- буфериране на MO (Mobile Originated) и MT (Mobile Terminated) данни;
- удостоверяване и авторизация на устройства и сървъри за приложения;
- едновременно използване на данни от едно UE от няколко AS;
- поддръжка на специални функции за наблюдение на състоянието на UE (MONTE – Monitoring Events);
- задействане на устройството;
- осигуряване на не-IP данни в роуминг.
Основният принцип на взаимодействие между AS и SCEF се основава на схемата на т.нар. абонаменти. Ако е необходимо да се получи достъп до която и да е SCEF услуга за конкретно UE, сървърът на приложения трябва да създаде абонамент, като изпрати команда до конкретния API на исканата услуга и получи уникален идентификатор в отговор. След което всички по-нататъшни действия и комуникации с ЕС в рамките на тази услуга ще се извършват с помощта на този идентификатор.
Външен идентификатор: Универсален идентификатор на устройство
Една от най-важните промени в схемата за взаимодействие между AS и устройства при работа чрез SCEF е появата на универсален идентификатор. Сега, вместо телефонен номер (MSISDN) или IP адрес, както беше в класическата 2G/3G/LTE мрежа, идентификаторът на устройството за сървъра на приложения става „външен идентификатор”. Дефинира се от стандарта във формат, познат на разработчиците на приложения “ @ "
Вече не е необходимо разработчиците да прилагат алгоритми за удостоверяване на устройството; мрежата напълно поема тази функция. Външният идентификатор е свързан с IMSI и разработчикът може да бъде сигурен, че при достъп до конкретен външен идентификатор той взаимодейства с конкретна SIM карта. Когато използвате SIM чип, получавате напълно уникална ситуация, когато външният ID уникално идентифицира конкретно устройство!
Освен това няколко външни идентификатора могат да бъдат свързани с един IMSI - още по-интересна ситуация възниква, когато външният идентификатор уникално идентифицира конкретно приложение, отговорно за конкретна услуга на конкретно устройство.
Появява се и групов идентификатор - външен групов идентификатор, който включва набор от индивидуални външни идентификатори. Сега, с една заявка към SCEF, AS може да инициира групови операции - изпращане на данни или контролни команди до множество устройства, обединени в една логическа група.
Поради факта, че за разработчиците на AS преходът към нов идентификатор на устройство не може да бъде мигновен, SCEF остави възможността за комуникация на AS с UE чрез стандартен номер - MSISDN.
Предаване на не-IP трафик (Non-IP Data Delivery, NIDD)
В NB-IoT, като част от оптимизирането на механизмите за предаване на малки количества данни, в допълнение към вече съществуващите типове PDN, като IPv4, IPv6 и IPv4v6, се появи друг тип - non-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 е външен идентификатор, AS трябва само да изпрати пакет данни до SCEF за конкретен външен идентификатор, а 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, можете да продавате данни от тях на много услуги едновременно.
Гарантиран механизъм за доставка на съобщения
Reliable Data Service е механизъм за гарантирана доставка на MO и MT съобщения без използването на специализирани алгоритми на ниво протокол, като например ръкостискане в TCP. Той работи, като включва специален флаг в обслужващата част на съобщението, когато се обменя между UE и SCEF. Дали този механизъм да се активира или не при предаване на трафик се решава от AS.
Ако механизмът е активиран, UE включва специален флаг в горната част на пакета, когато изисква гарантирана доставка на MO трафик. При получаване на такъв пакет, SCEF отговаря на UE с потвърждение. Ако UE не получи пакета за потвърждение, пакетът към SCEF ще бъде изпратен повторно. Същото се случва и с МТ трафика.
Мониторинг на устройството (мониторинг на събития - MONTE)
Както бе споменато по-горе, функционалността на SCEF освен всичко друго включва функции за наблюдение на състоянието на UE, т.нар. мониторинг на устройството. И ако новите идентификатори и механизми за трансфер на данни са оптимизации (макар и много сериозни) на съществуващите процедури, то MONTE е напълно нова функционалност, която не е налична в 2G/3G/LTE мрежите. MONTE позволява на AS да наблюдава параметри на устройството като състояние на връзката, наличност на комуникация, местоположение, състояние на роуминг и др. Ще говорим за всеки по-подробно малко по-късно.
Ако е необходимо да се активира някое събитие за наблюдение за устройство или група устройства, AS се абонира за съответната услуга, като изпраща съответната команда API MONTE към SCEF, която включва параметри като външен идентификатор или идентификатор на външна група, идентификатор на 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 е премахнато принудително от мрежата по някаква причина.
* За да уведоми мрежата, че устройството все още е достъпно, тя периодично инициира процедура за актуализиране - Tracking Area Update (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. Може да бъде поискано или текущото местоположение (Текущо местоположение), или последното известно местоположение (Определено от идентификатора на клетката, от който устройството е направило TAU или предало трафик последния път), което е от значение за устройства в режими за пестене на енергия PSM или eDRX. За „Текущо местоположение“ AS може да поиска повтарящи се отговори, като MME информира AS всеки път, когато местоположението на устройството се промени.
Промяна на асоциацията IMSI-IMEI – Когато това събитие е активирано, SCEF започва да следи промените в комбинацията от IMSI (идентификатор на SIM карта) и IMEI (идентификатор на устройство). При настъпване на събитие, информира AS. Може да се използва за автоматично свързване на външен идентификатор към устройство по време на планирана подмяна или да служи като идентификатор за кражба на устройство.
Състояние на роуминг – този тип наблюдение се използва от AS, за да се определи дали UE е в домашната мрежа или в мрежата на роуминг партньор. По желание може да се предава PLMN (Public Land Mobile Network) на оператора, в който е регистрирано устройството.
Неуспех в комуникацията — Този тип мониторинг информира AS за неуспехи в комуникацията с устройството въз основа на причините за загубата на връзка (код на причината за освобождаване), получен от мрежата за радио достъп (протокол S1-AP). Това събитие може да помогне да се определи защо комуникацията е неуспешна - поради проблеми в мрежата, например, когато eNodeb е претоварен (Радио ресурсите не са налични) или поради повреда на самото устройство (Радио връзка с изгубено UE).
Наличност след повреда на DDN – това събитие информира AS, че устройството е станало достъпно след прекъсване на комуникацията. Може да се използва, когато има нужда от прехвърляне на данни към устройство, но предишният опит не беше успешен, защото UE не отговори на известие от мрежата (пейджинг) и данните не бяха доставени. Ако този тип мониторинг е бил заявен за UE, тогава веднага щом устройството осъществи входяща комуникация, направи TAU или изпрати данни към връзката нагоре, AS ще бъде информиран, че устройството е станало достъпно. Тъй като процедурата DDN (уведомяване за данни надолу по връзката) работи между MME и S/P-GW, този тип наблюдение е достъпно само за IP устройства.
Състояние на PDN свързаност – информира AS, когато състоянието на устройството се промени (състояние на PDN връзка) - свързване (PDN активиране) или прекъсване (PDN изтриване). Това може да се използва от AS за иницииране на комуникация с UE или обратно, за да се разбере, че комуникацията вече не е възможна. Този тип мониторинг е достъпен за IP и не-IP устройства.
Брой UE, присъстващи в географска област – Този тип наблюдение се използва от AS за определяне на броя на UE в определена географска област.
Задействане на устройството)
В 2G/3G мрежите процедурата по регистрация в мрежата беше на два етапа: първо устройството се регистрира в SGSN (attach procedure), след което, ако е необходимо, активира PDP контекста - връзка с пакетния шлюз (GGSN). за предаване на данни. В 3G мрежите тези две процедури се случиха последователно, т.е. устройството не изчака момента, когато трябваше да прехвърли данни, а активира PDP веднага след приключване на процедурата за прикачване. В LTE тези две процедури бяха комбинирани в една, тоест при свързване устройството веднага поиска активиране на PDN връзката (аналогично на PDP в 2G/3G) през eNodeB към MME-SGW-PGW.
NB-IoT дефинира метод на свързване като „прикачване без PDN“, тоест UE се свързва без установяване на PDN връзка. В този случай той не е наличен за предаване на трафик и може само да получава или изпраща SMS. За да се изпрати команда до такова устройство за активиране на PDN и свързване с AS, беше разработена функционалността „Задействане на устройството“.
При получаване на команда за свързване на такова UE от AS, SCEF инициира изпращане на управляващ SMS към устройството през SMS центъра. Когато получи SMS, устройството активира PDN и се свързва с AS, за да получи допълнителни инструкции или да прехвърли данни.
Възможно е да има моменти, когато абонаментът за вашето устройство изтича на SCEF. Да, абонаментът има свой собствен живот, зададен от оператора или договорен с AS. След изтичане PDN ще бъде деактивиран на MME и устройството ще стане недостъпно за AS. В този случай функцията „Задействане на устройството“ също ще помогне. При получаване на нови данни от AS, SCEF ще разбере състоянието на връзката на устройството и ще достави данните чрез SMS канал.
Заключение
Функционалността на SCEF, разбира се, не се ограничава до гореописаните услуги и непрекъснато се развива и разширява. В момента повече от дузина услуги вече са стандартизирани за SCEF. Сега се докоснахме само до основните функции, които се търсят от разработчиците, а за останалите ще говорим в бъдещи статии.
Веднага възниква въпросът: как да получите тестов достъп до този „чудотворен“ възел за предварително тестване и отстраняване на грешки на възможни случаи? Всичко е много просто. Всеки разработчик може да изпрати заявка до [имейл защитен], в които е достатъчно да посочите целта на свързване, описание на възможен случай и контактна информация за комуникация.
Ще се видим отново!
Автори:
- старши експерт от отдела за конвергентни решения и мултимедийни услуги Сергей Новиков ,
- експерт от отдела за конвергентни решения и мултимедийни услуги Алексей Лапшин
Източник: www.habr.com