В статията «», говорим за архитектурата на пакетното ядро на мрежата 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. Необходим е за удостоверяване на абоната, авторизация на приложение сървъри, получаване на връзката между външен 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) към външен ID;
- предаване на non-IP трафик (Non-IP Data Delivery, NIDD);
- групови операции с използване на външен групов ID;
- поддръжка на режим на предаване на данни с потвърждение;
- буфериране на MO (Mobile Originated) и MT (Mobile Terminated) данни;
- удостоверяване и авторизация на устройства и приложение сървъри;
- едновременно използване на данни от един UE от няколко AS;
- поддръжка на специални функции за контрол на състоянието на UE (MONTE – Monitoring Events);
- задействане на устройства;
- осигуряване на роуминг на non-IP данни.
Основният принцип на взаимодействието между AS и SCEF е основан на т.н. схеми на абонаментите. Когато е необходимо получаването на достъп до определена услуга от SCEF за конкретен UE, сървърът на приложенията трябва да създаде абонамент, изпращайки команда на конкретното API на исканата услуга и в отговор получава уникален идентификатор. След това всички по-нататъшни действия и комуникации с UE в рамките на тази услуга ще се извършват с използване на този идентификатор.
External ID: универсален идентификатор на устройството
Едно от най-важните изменения в схемата на взаимодействие между AS и устройствата при работа чрез SCEF е появата на универсалния идентификатор. Сега, вместо телефонния номер (MSISDN) или IP адреса, както беше в класическите мрежи 2G/3G/LTE, идентификаторът на устройството за сървъра на приложенията става „external ID“. Той е определен от стандарта в познатия на разработчиците формат „@“.
Разработчиците вече нямат нужда да реализират алгоритми за удостоверяване на устройствата, мрежата напълно поема тази функция. External ID е свързан с IMSI, и разработчикът може да бъде сигурен, че като се обърне към конкретен external ID, той взаимодейства с конкретна SIM карта. При използване на SIM чип се получава изключителна ситуация, когато external ID недвусмислено идентифицира конкретно устройство!
Освен това, към един IMSI могат да се свържат няколко external ID — получава се още по-интересна ситуация, при която external ID недвусмислено идентифицира конкретно приложение, отговарящо за определена услуга на конкретно устройство.
Също така се появява групов идентификатор — external group ID, който включва набор от отделни external ID. Сега с една заявка към SCEF AS може да инициира групови операции — изпращане на данни или команди за управление на множество устройства, обединени в една логическа група.
Поради причини, че за разработчиците AS преходът към новия идентификатор на устройството не може да бъде моментален, SCEF остави възможността за комуникация на AS с UE чрез стандартния номер – MSISDN.
Предаване на non-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 трафика до устройства по external 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 в geографска зона – този тип мониторинг се използва от AS, за да определи броя на UE в определена географска зона.
Тригериране на устройства (Device triggering)
В 2G/3G мрежи процедура за регистрация в мрежата беше двустепенна: първо устройството се регистрираше в SGSN (процедура attach), след това, при необходимост да предадe данни, активираше PDP контекст – връзка с пакетния шлюз (GGSN). В 3G мрежите тези две процедури протичаха последователно, т.е. устройството не чакаше момента, когато трябва да предаде данни, а активираше PDP веднага след приключването на процедурата attach. В LTE тези две процедури бяха обединени в една, т.е. при attach устройството веднага поиска активиране на PDN връзката (аналог на PDP в 2G/3G) чрез eNodeB към MME-SGW-PGW.
В NB-IoT е определен такъв начин на свързване, като “attach без 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
