В статията «», обсъждайки архитектурата на пакетното ядро на мрежата NB-IoT, споменахме за появата на новия възел SCEF. Обясняваме в третата част какво е това и защо е необходимо?
При създаването на M2M-сервис разработчиците на приложения се сблъскват със следните въпроси:
- как да идентифицират устройствата;
- кой алгоритъм за проверка и удостоверяване на автентичност да използват;
- кой транспортен протокол да изберат за взаимодействие с устройствата;
- как да гарантират доставката на данни до устройствата;
- как да организират и установят правила за обмен на данни с тях;
- как да контролират и в реално време да получават информация за тяхното състояние;
- как едновременно да доставят данни до група от собствените си устройства;
- как едновременно да изпратят данни от едно устройство до няколко клиента;
- как да получат унифициран достъп до допълнителни услуги на оператора за управление на своето устройство.
За решаването на тези въпроси се налага създаването на собствени технически „тежки“ решения, което води до увеличаване на трудоемкостта и времето до пускане на пазара на услугите. Тук на помощ идва новият възел SCEF.
Според определението на 3GPP, SCEF (функция за експониране на услуги) — това е напълно нов компонент от архитектурата на 3GPP, чиято функция е безопасното експониране на услуги и възможности, предоставяни от мрежовите интерфейси на 3GPP чрез API.
Просто казано, SCEF е посредник между мрежата и сървъра на приложения (application server — AS), единен достъп до услугите на оператора за управление на своето M2M устройство в мрежата NB-IoT чрез интуитивен стандартизиран API интерфейс.
SCEF скрива сложността на мрежата на оператора, позволявайки на разработчиците на приложения да се абстрахират от сложните, специфични механизми за взаимодействие с устройствата.
Чрез преобразуването на мрежовите протоколи в познат за разработчиците API-интерфейс, SCEF улеснява създаването на нови услуги и намалява времето за пускане на пазара. Новият възел също така включва функции за идентификация/автентикация на мобилни устройства, определяне на правила за обмен на данни между устройството и AS, освободждавайки разработчиците от необходимостта да реализират тези функции на своя страна и прехвърляйки ги на оператора.
SCEF обединява интерфейсите, необходими за автентикация и авторизация на сървъри на приложения, поддържане на мобилността на UE, предаване на данни и тригериране на устройства, достъп до допълнителни услуги и възможности на мрежата на оператора.
Към AS отива един-единствен интерфейс T8, API-интерфейс (HTTP/JSON), стандартизиран от 3GPP. Всички интерфейси, с изключение на T8, работят на базата на протокола DIAMETER (фиг. 1).
T6a – интерфейс между SCEF и MME. Използва се за процедури за управление на мобилността/сесии, предаване на non-IP данни, провизиране на събития за мониторинг и получаване на отчети за тях.
S6t – интерфейс между SCEF и HSS. Необходим е за автентикацията на абоната, авторизацията на сървъри на приложения, получаване на връзка между external ID и 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) към external ID;
- предаване на non-IP трафик (Non-IP Data Delivery, NIDD);
- групови операции, с използване на external group ID;
- подкрепа на режима на предаване на данни с потвърждение;
- буферизация на MO (Mobile Originated) и MT (Mobile Terminated) данни;
- автентикация и авторизация на устройства и сървъри на приложения;
- съвместна употреба на данни от един UE от множество AS;
- поддръжка на специални функции за мониторинг на състоянието на UE (MONTE – Monitoring Events);
- тригериране на устройства;
- осигуряване на роуминг на non-IP данни.
Основният принцип на взаимодействие между AS и SCEF е основан на схемата на т.н. абонаменти. При необходимост от достъп до определена услуга SCEF за конкретен UE, приложният сървър трябва да създаде абонамент, като изпрати команда до конкретния API на исканата услуга и получи уникален идентификатор в отговор. След което всички последващи действия и комуникации с UE в рамките на тази услуга ще се извършват с използване на този идентификатор.
Външен идентификатор: универсален идентификатор на устройството
Едно от най-значимите изменения в схемата на взаимодействие между AS и устройствата при работа с SCEF е появата на универсален идентификатор. Сега вместо телефонен номер (MSISDN) или IP адрес, както беше в класическите мрежи 2G/3G/LTE, идентификаторът на устройството за приложния сървър става «външен идентификатор». Той е определен от стандарта в познатия за разработчиците формат «@».
Разработчиците вече не трябва да реализират алгоритми за аутентикация на устройства, мрежата поема тази функция изцяло. Външният идентификатор е свързан с IMSI, и разработчикът може да бъде сигурен, че когато се обръща към конкретен външен идентификатор, той взаимодействува с конкретна SIM карта. При използване на SIM чип, става наистина уникална ситуация, когато външният идентификатор еднозначно идентифицира конкретно устройство!
Освен това, към един IMSI могат да бъдат свързани няколко външни идентификатора — получава се още по-интересна ситуация, когато външният идентификатор еднозначно идентифицира конкретно приложение, отговарящо за определена услуга на конкретно устройство.
Също така се появява групов идентификатор — външен групов ID, който включва набор от отделни външни идентификатори. Сега с едно запитване към SCEF AS може да инициира групови операции — изпращане на данни или команди за управление на множество устройства, обединени в една логическа група.
Поради факта, че за разработчиците AS преходът към новия идентификатор на устройството не може да бъде моментален, SCEF остави възможност за комуникация между AS и UE чрез стандартния номер – MSISDN.
Предаване на non-IP трафик (Non-IP Data Delivery, NIDD)
В NB-IoT, в контекста на оптимизацията на механизмите за предаване на малки обеми данни, се добавя нов тип PDN — non-IP, в допълнение към вече съществуващите, като IPv4, IPv6 и IPv4v6. В този случай устройството (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. Използване на heartbeat. След като веднъж е установена връзката, устройството трябва да обменя пакети с AS на всеки няколко минути, за да не се затвори транслацията на NAT. Но тук не може да стане дума за енергоефективност.
2. Всеки път при необходимост да се провери наличието на пакети за устройството на AS — да се изпраща съобщение в uplink.
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, може да се продават данни от тях на много услуги едновременно.
Механизъм за гарантирано доставяне на съобщения
Reliable Data Service — механизъм за гарантирано доставяне на MO и MT съобщения без използване на специализирани алгоритми на протоколно ниво, такива като например handshake в TCP. Работи чрез включване на специален флаг в служебната част на съобщението при обмена между UE и SCEF. Активирането или неактивирането на този механизъм при предаване на трафика се решава от AS.
Ако механизмът е активиран, UE при необходимост от гарантирано доставяне на MO трафик включва специален флаг в служебната част на пакета. При получаване на такъв пакет, SCEF отговаря на UE с потвърждение. Ако UE не получи пакет с потвърждение, пакетът в посока SCEF ще бъде пренасочен повторно. Същото се случва и за MT трафика.
Мониторинг на устройства (monitoring events- MONTE)
Както беше споменато по-рано, функционалността на SCEF, освен всичко друго, включва функции за контрол на състоянието на UE, т.н. мониторинг на устройства. И ако новите идентификатори и механизми за предаване на данни са оптимизации (макар и много сериозни) на вече съществуващи процедури, MONTE е съвсем нова функционалност, недостъпна в мрежи 2G/3G/LTE. MONTE позволява на AS да следи такива параметри на устройството, като статус на връзката, наличност за комуникация, местоположение, роуминг статус и т.н. По-подробно за всеки от тях ще разкажем по-късно.
При необходимост да се активира някакво събитие за мониторинг за устройство или група устройства, AS подписва за съответния сервис, изпращайки на SCEF команда от съответния API MONTE, в която се включват такива параметри, като external Id или external group ID, идентификатор на AS, тип мониторинг, брой репорти, които AS иска да получи. Ако AS е упълномощен да извърши заявката, SCEF, в зависимост от типа, провижинира събитието на HSS или MME (фиг. 4). При настъпване на събитието, MME или HSS генерират репорт в посока SCEF, който го изпраща на AS.
Провижинингът на всички събития, с изключение на 'Number of UEs present in a geographic area', се извършва чрез HSS. Две събития 'Change of IMSI-IMEI Association' и 'Roaming Status' се следят директно на HSS, останалите HSS провижинира на MME.
Събитията могат да бъдат както еднократни, така и периодични и зависят от техния тип.
Изпращането на отчет за събитие (репортиране) се извършва от възел, следящ събитие, директно на SCEF (фиг. 5).
Важно: събитията за мониторинг могат да се прилагат както за non-IP устройства, свързани през SCEF, така и за IP устройства, предаващи данни по класическия начин през MME-SGW-PGW.
Нека разгледаме по-подробно всяко от събитията за мониторинг:
Загуба на свързаност — информира AS, че UE вече не е на разположение нито за data-трафик, нито за сигнален обмен. Събитието настъпва, когато на MME изтече ‘mobile reachability timer’ за UE. В заявката за този тип мониторинг AS може да посочи собствено значение за ‘Maximum Detection Time’ — ако в рамките на това време UE не прояви активност, AS ще бъде информиран, че UE не е достъпна, с посочване на причината. Събитието също настъпва, ако UE е било принудително изтрито от мрежата по някаква причина.
* За да знае мрежата, че устройството все още е на разположение, то периодично инициира процедура за актуализация — Tracking Area Update (TAU). Честотата на тази процедура се задава от мрежата с таймер T3412 или (T3412_extended в случай на PSM), чиято стойност се предава на устройството по време на процедура Attach или при следваща TAU. Mobile reachability timer обикновено е няколко минути по-дълъг от T3412. Ако UE не направи TAU преди изтичането на 'Mobile reachability timer', мрежата счита, че тя не е достъпна.
Достъпност на UE – Показва, когато UE става на разположение за DL трафик или SMS. Това се случва, когато UE стане достъпна за пейджинг (за UE в режим eDRX) или когато UE премине в режим ECM-CONNECTED (за UE в режим PSM или eDRX), т.е. прави TAU или изпраща uplink пакет.
Докладване на местоположение – Този вид мониторингови събития позволява на AS да поиска данни за местоположението на UE. Може да бъде поискано или текущото местоположение (Current Location), или последното известно (Last Known Location, определяно по cell ID, от който устройството е направило TAU или е предавало трафик за последен път), което е актуално за устройства, намиращи се в режими за пестене на енергия PSM или eDRX. За 'Current Location' AS може да поиска повторни репорти, при което MME ще информира AS всеки път, когато устройството смени местоположението си.
Смяна на асоциацията IMSI-IMEI – При активиране на това събитие SCEF започва да следи промените в комплекта IMSI (идентификатор на SIM карта) и IMEI (идентификатор на устройството). При настъпването на събитието — уведомява AS. Може да се използва за автоматично преназначаване на външен ID към устройството по време на планирани дейности за замяна или да служи като идентификатор за кражба на устройството.
Състояние на роуминг – този вид мониторинг се използва от AS, за да определи дали UE е в домашната мрежа или в мрежата на роумингов партньор. Опционално може да бъде предаден PLMN (Public Land Mobile Network) на оператора, в който устройството е регистрирано.
Неуспешна комуникация — Този тип мониторинг уведомява AS за проблеми в комуникацията с устройството, основавайки се на причините за прекъсването на връзката (release cause code), получени от мрежата за радиодостъп (протокол S1-AP). Това събитие може да помогне да се определи причината за сбоя в комуникацията — поради проблеми в мрежата, например, при претоварване на eNodeb (Radio resources not available) или поради неизправност на самото устройство (Radio Connection With UE Lost).
Наличност след DDN Сбой – това събитие уведомява AS, че устройството е станало достъпно след сбой в комуникацията. Може да се използва, когато е необходимо да се предадат данни на устройството, но предишната опит е била неуспешна, тъй като UE не е реагирала на уведомлението от мрежата (пейджинг) и данните не са били доставени. Ако този тип мониторинг е поискан за UE, след като устройството инициира входяща комуникация, извърши TAU или изпрати данни в uplink, AS ще бъде информиран, че устройството е станало достъпно. Тъй като процедурата DDN (downlink data notification) работи между MME и S/P-GW, този вид мониторинг е достъпен само за IP устройства.
Състояние на свързаност с PDN – уведомява AS при промяна в статуса на устройството (PDN connectivity status) — свързване (активация на PDN) или изключване (премахване на PDN). Това може да бъде използвано от AS за иницииране на комуникация с UE или обратно, за да се разбере, че комуникацията вече е невъзможна. Този тип мониторинг е наличен за IP и non-IP устройства.
Брой на наличните UE в географска зона – този тип мониторинг се използва от AS, за да определи количеството UE в определена географска зона.
Тригериране на устройства (Device triggering)
В 2G/3G мрежи процедурата за регистрация в мрежата беше двустепенна: първо устройството се регистрираше в SGSN (процедура attach), след това, при необходимост, активираше PDP контекст – свързване с пакетния шлюз (GGSN). В 3G мрежи тези две процедури протичаха последователно, т.е. устройството не чакаше момента, в който трябва да предаде данни, а активираше PDP веднага след приключване на процедурата attach. В LTE тези две процедури бяха обединени в една, тоест при attach устройството веднага искаше активиране на PDN свързването (аналог PDP в 2G/3G) през eNodeB към MME-SGW-PGW.
В NB-IoT е определен такъв начин на свързване, като “attach without PDN”, т.е. UE прави attach, без да установява PDN-свързване. В този случай то не е налично за предаване на трафик и може само да получава или изпраща SMS. За да предаде на такова устройство команда за активиране на PDN и свързване с AS, е разработена функция “Device triggering”.
При получаване на команда за свързване на такова UE от AS, SCEF чрез SMS-центъра инициира изпращането на управляваща SMS на устройството. При получаване на SMS устройството активира PDN и се свързва с AS за получаване на последващи инструкции или предаване на данни.
Възможни са случаи, когато на SCEF изтече абонамента за устройството. Да, абонаментът има свой срок на годност, определен от оператора или уговорен с AS. След неговото изтичане на MME ще бъде деактивиран PDN и устройството ще стане недостъпно за AS. В този случай ще помогне и функцията “Device triggering”. При получаване на нови данни от AS, SCEF ще установи статуса на свързването на устройството и ще достави данните по SMS-канала.
Заключение
Функцията на SCEF, разбира се, не се ограничава до описаните по-горе услуги и постоянно еволюира и разширява. В момента вече са стандартизирани повече от десет услуги за SCEF. В момента разгледахме само основните и търсени функции от страна на разработчиците, за другите ще говорим в бъдещи статии.
Сразу възниква въпросът, как да получите тестов достъп до този „чудо“-възел за предварително тестване и отстраняване на възможни проблеми? Всичко е много просто. Всеки разработчик може да изпрати запитване на iot.info@mts.ru, в което е достатъчно да посочи целта на свързването, описание на възможния случай и контактна информация за връзка.
До нови срещи!
Автори:
- старши експерт в отдела за конвергентни решения и мултимедийни услуги Сергей Новиков ,
- експерт в отдела за конвергентни решения и мултимедийни услуги Алексей Лапшин
Източник: habr.com
