В статье «NB-IoT: как он работает? Часть 2», рассказывая про архитектуру пакетного ядра сети NB-IoT, мы упомянули про появление нового узла SCEF. Объясняем в третьей части, что же это такое и зачем это нужно?
При создании M2M-сервиса разработчики приложений сталкиваются со следующими вопросами:
Для их решения приходится создавать проприетарные технически «тяжелые» решения, что приводит к увеличению трудозатрат и времени time-to-market сервисов. Вот здесь на помощь и приходит новый узел SCEF.
Согласно определению 3GPP, SCEF (service capability exposure function) — это совершенно новый компонент архитектуры 3GPP, функцией которого является безопасное экспонирование сервисов и возможностей, предоставляемых сетевыми интерфейсами 3GPP посредством API.
Простыми словами SCEF – это посредник между сетью и сервером приложений (application server — AS), единое окно доступа к сервисам оператора по управлению своим M2M-устройством в сети NB-IoT посредством интуитивно понятного стандартизированного API-интерфейса.
SCEF скрывает сложность сети оператора, позволяя разработчикам приложений абстрагироваться от сложных, специфических механизмов взаимодействия с устройствами.
За счет преобразования сетевых протоколов в привычный для разработчиков приложений API-интерфейс SCEF облегчает создание новых услуг и уменьшает time-to-market. Также новый узел включает в себя функции идентификации/аутентификации мобильных устройств, определения правил обмена данными между устройством и AS, снимая с разработчиков приложений необходимость реализации этих функций на своей стороне, переложив данные функции на плечи оператора.
SCEF замыкает на себе интерфейсы, необходимые для аутентификации и авторизации серверов приложений, поддержания мобильности UE, передачи данных и триггеринга устройств, доступу к дополнительным сервисам и возможностям сети оператора.
В сторону AS идет один единственный интерфейс T8, API-интерфейс (HTTP/JSON), стандартизованный 3GPP. Все интерфейсы, за исключением T8, работают на базе протокола DIAMETER (рис. 1).
T6a – интерфейс между SCEF и MME. Используется для процедур Mobility/Session management, передачи 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 List of Reference Points).
Ниже приведены ключевые функции и сервисы SCEF:
Основной принцип взаимодействия AS и SCEF построен на схеме т.н. подписок. При необходимости получения доступа к какому-либо сервису SCEF для определенного UE, серверу приложений требуется создать подписку, путем отправки команды на конкретный API запрашиваемого сервиса и в ответ получить уникальный идентификатор. После чего все дальнейшие действия и коммуникации с UE в рамках данного сервиса будут проходить с использованием данного идентификатора.
External ID: универсальный идентификатор устройства
Одним из важнейших изменений в схеме взаимодействия AS с устройствами при работе через SCEF является появление универсального идентификатора. Теперь вместо телефонного номера (MSISDN) или IP адреса, как это было в классической сети 2G/3G/LTE, идентификатором устройства для сервера приложений становится «external ID». Он определен стандартом в привычном для разработчиков приложений формате «<Local Identifier>@<Domain Identifier>».
Разработчикам больше нет нужды реализовывать алгоритмы аутентификации устройств, сеть полностью берет эту функцию на себя. External ID привязывается к IMSI, и разработчик может быть уверен, что обращаясь к конкретному external ID, он взаимодействует с конкретной сим-картой. При использовании сим-чипа получается вообще уникальная ситуация, когда 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. Cделать приватный APN (VRF), где сервер приложений и устройства будут находиться в одной подсети, и назначить на устройства статические IP-адреса. Работать будет, но это почти нереализуемо, когда речь идет о парке из тысяч, десятков тысяч устройств.
4. Наконец, наиболее подходящий вариант: использовать IPv6, для него не нужен NAT, так как IPv6 адреса доступны из интернета напрямую. Однако даже в этом случае при перерегистрации устройства, оно получит новый IPv6 адрес и уже не будет доступно по предыдущему.
Соответственно необходимо отправлять некий инициализирующий пакет c идентификатором устройства на сервер, чтобы сообщить новый IP-адрес девайса. Потом дожидаться подтверждающего пакета от AS, что также влияет на энергоэффективность.
Эти способы хорошо работают для 2G/3G/LTE девайсов, где к устройству не предъявляется жестких требований в автономности и, как следствие, нет ограничений по времени в эфире и трафику. Для NB-IoT эти способы не подходят в виду их большой энергозатратности.
SCEF решает эту проблему: так как единственным идентификатором устройства для AS является external ID, AS достаточно отправить пакет данных на SCEF для конкретного external 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.
Давайте подробнее рассмотрим каждое из событий мониторинга:
Loss of connectivity — информирует 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 до истечения “Mobile reachability timer” не сделало TAU, сеть считает ее более недоступной.
UE reachability – Показывает, когда UE становится доступна для DL трафика или SMS. Это происходит, когда UE становится доступной для пейджинга (для UE в режиме eDRX) или когда UE переходит в режим ECM-CONNECTED (для UE в режиме PSM или eDRX), т.е. делает TAU или отправляет uplink-пакет.
Location reporting – Данный вид мониторинговых событий позволяет AS запросить данные о местоположении UE. Может быть запрошено либо текущее местоположение (Current Location), либо последнее известное (Last Known Location, определяется по cell ID из которого устройство делало TAU или передавало трафик в последний раз), что актуально для устройств, находящихся в режимах энергосбережения PSM или eDRX. Для “Current Location” AS может запросить повторяющиеся репотры, при этом MME будет информировать AS каждый раз при смене местоположения устройства.
Change of IMSI-IMEI Association – При активации данного события SCEF начинает отслеживать изменение связки IMSI (идентификатора сим-карты) и IMEI (идентификатора устройства). При наступлении события — информирует AS. Может применяться для автоматической перепривязки external ID к устройству в ходе плановых работ по замене или служить идентификатором кражи устройства.
Roaming Status – данный вид мониторинга используется AS, что бы определить находится UE в домашней сети или в сети роумингового партнера. Опционально может быть передан PLMN (Public Land Mobile Network) оператора, в котором устройство зарегистрировано.
Communication failure — Данный тип мониторинга информирует AS о сбоях в коммуникации с устройством, основываясь на причинах обрыва соединения (release cause code) полученных от сети радиодоступа (протокол S1-AP). Это событие может помочь определить, по какой причине произошел сбой коммуникации — из-за проблем на сети, например, при перегрузке eNodeb (Radio resources not available) или по причине сбоя самого устройства (Radio Connection With UE Lost).
Availability after DDN Failure – данное событие информирует AS, что устройство стало доступно после сбоя коммуникации. Может использоваться, когда необходимо передать данные на устройство, но предыдущая попытка была не успешна, так как UE не ответила на нотификацию от сети (пейджинг), и данные не были доставлены. Если данный тип мониторинга был запрошен для UE, то как только устройство произведет входящую коммуникацию, сделает TAU или отправит данные в uplink, AS будет проинформирован, что устройство стало доступно. Так как процедура DDN (downlink data notification) работает между MME и S/P-GW, то данный вид мониторинга доступен только для IP-девайсов.
PDN Connectivity Status – информирует AS при изменение статуса устройства (PDN connectivity status) — подключении (активации PDN) или отключении (удаление PDN). Это может быть использовано AS для инициации коммуникации с UE, или наоборот, для понимания, что коммуникация более не возможна. Данный тип мониторинга доступен для IP и для non-IP девайсов.
Number of UEs present in a geographic area – данный тип мониторинга используется AS, чтобы определить количество UE в определенной географической зоне.
Триггеринг устройств (Device triggering)
В 2G/3G сетях процедура регистрации в сети была двухступенчатая: сначала устройство регистрировалось в SGSN (процедура attach), потом при необходимости передать данные активировало PDP context – соединение с пакетным шлюзом (GGSN). В 3G сетях эти две процедуры шли последовательно, т.е. устройство не дожидалось момента, когда надо передать данные, а активировало PDP сразу по завершении процедуры attach. В LTE эти две процедуры были объединены в одну, то есть при attach устройство сразу запрашивало активацию PDN connection (аналог 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 уже стандартизированы более десятка сервисов. Сейчас мы затронули только основные и востребованные со стороны разработчиков функции, об остальных мы поговорим в будущих статьях.
Сразу же возникает вопрос, как получить тестовый доступ к этому «чудо»-узлу для предварительного тестирования и отладки возможных кейсов? Все очень просто. Любой разработчик может отправить запрос на nidd_scef@mts.ru, в котором достаточно указать цель подключения, описание возможного кейса и контактную информацию для связи.
До новых встреч!
Авторы:
При создании M2M-сервиса разработчики приложений сталкиваются со следующими вопросами:
- как идентифицировать устройства;
- какой использовать алгоритм проверки и подтверждения подлинности;
- какой выбрать транспортный протокол для взаимодействия с устройствами;
- как гарантированно доставить данные на устройства;
- как организовать и установить правила обмена данными с ними;
- как контролировать и в онлайн режиме получить информацию об их состоянии;
- как одновременно доставить данные на группу своих устройств;
- как одновременно отправить данные с одного устройства на несколько клиентов;
- как получить унифицированный доступ к дополнительным сервисам оператора по управлению своим устройством.
Для их решения приходится создавать проприетарные технически «тяжелые» решения, что приводит к увеличению трудозатрат и времени time-to-market сервисов. Вот здесь на помощь и приходит новый узел SCEF.
Согласно определению 3GPP, SCEF (service capability exposure function) — это совершенно новый компонент архитектуры 3GPP, функцией которого является безопасное экспонирование сервисов и возможностей, предоставляемых сетевыми интерфейсами 3GPP посредством API.
Простыми словами SCEF – это посредник между сетью и сервером приложений (application server — AS), единое окно доступа к сервисам оператора по управлению своим M2M-устройством в сети NB-IoT посредством интуитивно понятного стандартизированного API-интерфейса.
SCEF скрывает сложность сети оператора, позволяя разработчикам приложений абстрагироваться от сложных, специфических механизмов взаимодействия с устройствами.
За счет преобразования сетевых протоколов в привычный для разработчиков приложений API-интерфейс SCEF облегчает создание новых услуг и уменьшает time-to-market. Также новый узел включает в себя функции идентификации/аутентификации мобильных устройств, определения правил обмена данными между устройством и AS, снимая с разработчиков приложений необходимость реализации этих функций на своей стороне, переложив данные функции на плечи оператора.
SCEF замыкает на себе интерфейсы, необходимые для аутентификации и авторизации серверов приложений, поддержания мобильности UE, передачи данных и триггеринга устройств, доступу к дополнительным сервисам и возможностям сети оператора.
В сторону AS идет один единственный интерфейс T8, API-интерфейс (HTTP/JSON), стандартизованный 3GPP. Все интерфейсы, за исключением T8, работают на базе протокола DIAMETER (рис. 1).
T6a – интерфейс между SCEF и MME. Используется для процедур Mobility/Session management, передачи 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 List of Reference Points).
Ниже приведены ключевые функции и сервисы SCEF:
- привязка идентификатора сим-карты (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 в рамках данного сервиса будут проходить с использованием данного идентификатора.
External ID: универсальный идентификатор устройства
Одним из важнейших изменений в схеме взаимодействия AS с устройствами при работе через SCEF является появление универсального идентификатора. Теперь вместо телефонного номера (MSISDN) или IP адреса, как это было в классической сети 2G/3G/LTE, идентификатором устройства для сервера приложений становится «external ID». Он определен стандартом в привычном для разработчиков приложений формате «<Local Identifier>@<Domain Identifier>».
Разработчикам больше нет нужды реализовывать алгоритмы аутентификации устройств, сеть полностью берет эту функцию на себя. External ID привязывается к IMSI, и разработчик может быть уверен, что обращаясь к конкретному external ID, он взаимодействует с конкретной сим-картой. При использовании сим-чипа получается вообще уникальная ситуация, когда 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. Cделать приватный APN (VRF), где сервер приложений и устройства будут находиться в одной подсети, и назначить на устройства статические IP-адреса. Работать будет, но это почти нереализуемо, когда речь идет о парке из тысяч, десятков тысяч устройств.
4. Наконец, наиболее подходящий вариант: использовать IPv6, для него не нужен NAT, так как IPv6 адреса доступны из интернета напрямую. Однако даже в этом случае при перерегистрации устройства, оно получит новый IPv6 адрес и уже не будет доступно по предыдущему.
Соответственно необходимо отправлять некий инициализирующий пакет c идентификатором устройства на сервер, чтобы сообщить новый IP-адрес девайса. Потом дожидаться подтверждающего пакета от AS, что также влияет на энергоэффективность.
Эти способы хорошо работают для 2G/3G/LTE девайсов, где к устройству не предъявляется жестких требований в автономности и, как следствие, нет ограничений по времени в эфире и трафику. Для NB-IoT эти способы не подходят в виду их большой энергозатратности.
SCEF решает эту проблему: так как единственным идентификатором устройства для AS является external ID, AS достаточно отправить пакет данных на SCEF для конкретного external 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.
Давайте подробнее рассмотрим каждое из событий мониторинга:
Loss of connectivity — информирует 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 до истечения “Mobile reachability timer” не сделало TAU, сеть считает ее более недоступной.
UE reachability – Показывает, когда UE становится доступна для DL трафика или SMS. Это происходит, когда UE становится доступной для пейджинга (для UE в режиме eDRX) или когда UE переходит в режим ECM-CONNECTED (для UE в режиме PSM или eDRX), т.е. делает TAU или отправляет uplink-пакет.
Location reporting – Данный вид мониторинговых событий позволяет AS запросить данные о местоположении UE. Может быть запрошено либо текущее местоположение (Current Location), либо последнее известное (Last Known Location, определяется по cell ID из которого устройство делало TAU или передавало трафик в последний раз), что актуально для устройств, находящихся в режимах энергосбережения PSM или eDRX. Для “Current Location” AS может запросить повторяющиеся репотры, при этом MME будет информировать AS каждый раз при смене местоположения устройства.
Change of IMSI-IMEI Association – При активации данного события SCEF начинает отслеживать изменение связки IMSI (идентификатора сим-карты) и IMEI (идентификатора устройства). При наступлении события — информирует AS. Может применяться для автоматической перепривязки external ID к устройству в ходе плановых работ по замене или служить идентификатором кражи устройства.
Roaming Status – данный вид мониторинга используется AS, что бы определить находится UE в домашней сети или в сети роумингового партнера. Опционально может быть передан PLMN (Public Land Mobile Network) оператора, в котором устройство зарегистрировано.
Communication failure — Данный тип мониторинга информирует AS о сбоях в коммуникации с устройством, основываясь на причинах обрыва соединения (release cause code) полученных от сети радиодоступа (протокол S1-AP). Это событие может помочь определить, по какой причине произошел сбой коммуникации — из-за проблем на сети, например, при перегрузке eNodeb (Radio resources not available) или по причине сбоя самого устройства (Radio Connection With UE Lost).
Availability after DDN Failure – данное событие информирует AS, что устройство стало доступно после сбоя коммуникации. Может использоваться, когда необходимо передать данные на устройство, но предыдущая попытка была не успешна, так как UE не ответила на нотификацию от сети (пейджинг), и данные не были доставлены. Если данный тип мониторинга был запрошен для UE, то как только устройство произведет входящую коммуникацию, сделает TAU или отправит данные в uplink, AS будет проинформирован, что устройство стало доступно. Так как процедура DDN (downlink data notification) работает между MME и S/P-GW, то данный вид мониторинга доступен только для IP-девайсов.
PDN Connectivity Status – информирует AS при изменение статуса устройства (PDN connectivity status) — подключении (активации PDN) или отключении (удаление PDN). Это может быть использовано AS для инициации коммуникации с UE, или наоборот, для понимания, что коммуникация более не возможна. Данный тип мониторинга доступен для IP и для non-IP девайсов.
Number of UEs present in a geographic area – данный тип мониторинга используется AS, чтобы определить количество UE в определенной географической зоне.
Триггеринг устройств (Device triggering)
В 2G/3G сетях процедура регистрации в сети была двухступенчатая: сначала устройство регистрировалось в SGSN (процедура attach), потом при необходимости передать данные активировало PDP context – соединение с пакетным шлюзом (GGSN). В 3G сетях эти две процедуры шли последовательно, т.е. устройство не дожидалось момента, когда надо передать данные, а активировало PDP сразу по завершении процедуры attach. В LTE эти две процедуры были объединены в одну, то есть при attach устройство сразу запрашивало активацию PDN connection (аналог 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 уже стандартизированы более десятка сервисов. Сейчас мы затронули только основные и востребованные со стороны разработчиков функции, об остальных мы поговорим в будущих статьях.
Сразу же возникает вопрос, как получить тестовый доступ к этому «чудо»-узлу для предварительного тестирования и отладки возможных кейсов? Все очень просто. Любой разработчик может отправить запрос на nidd_scef@mts.ru, в котором достаточно указать цель подключения, описание возможного кейса и контактную информацию для связи.
До новых встреч!
Авторы:
