В статье " NB-IoT: как это работает? Часть 2 «Говоря об архитектуре пакетного ядра сети NB-IoT, мы упомянули о появлении нового узла SCEF. В третьей части объясняем, что это такое и зачем он нужен? 
При создании M2M-сервиса перед разработчиками приложений возникают следующие вопросы:
Для их решения необходимо создавать собственные технически «тяжелые» решения, что приводит к увеличению трудозатрат и сроков вывода услуг на рынок.
Вот здесь-то и приходит на помощь новый узел SCEF. Согласно определению 3GPP, SCEF (функция раскрытия возможностей сервиса) — это совершенно новый компонент архитектуры 3GPP, функция которого заключается в безопасном предоставлении услуг и возможностей, предоставляемых сетевыми интерфейсами 3GPP, через API. Простыми словами, SCEF — это посредник между сетью и сервером приложений (АС), единое окно доступа к сервисам оператора для управления вашим M2M-устройством в сети NB-IoT через интуитивно понятный стандартизированный API-интерфейс.
SCEF скрывает сложность сети оператора, позволяя разработчикам приложений абстрагироваться от сложных, специфичных для устройства механизмов взаимодействия с устройствами.
Преобразуя сетевые протоколы в знакомый API для разработчиков приложений, API SCEF облегчает создание новых сервисов и сокращает время вывода на рынок.
Новый узел также включает в себя функции идентификации/аутентификации мобильных устройств, определения правил обмена данными между устройством и AS, избавляет разработчиков приложений от необходимости реализовывать эти функции на своей стороне, перекладывая эти функции на плечи оператора.
SCEF охватывает интерфейсы, необходимые для аутентификации и авторизации серверов приложений, поддержания мобильности UE, передачи данных и срабатывания устройств, доступа к дополнительным сервисам и возможностям операторской сети.
Что касается AS, существует единый интерфейс T8, API (HTTP/JSON), стандартизированный 3GPP. Все интерфейсы, за исключением Т8, работают на основе протокола DIAMETER (рис.
1).
T6a – интерфейс между SCEF и MME. Используется для процедур управления мобильностью/сессией, передачи неIP-данных, обеспечения мониторинга событий и получения отчетов о них.
S6t – интерфейс между SCEF и HSS. Требуется для аутентификации абонентов, авторизации серверов приложений, получения комбинации внешнего идентификатора и IMSI/MSISDN, обеспечения мониторинга событий и получения отчетов по ним.
S6m/T4 – интерфейсы от SCEF к HSS и SMS-C (3GPP определяет узел MTC-IWF, который используется для запуска устройств и передачи SMS в сетях NB-IoT. Однако во всех реализациях функционал этого узла интегрирован в SCEF, поэтому для упрощения схемы отдельно рассматривать его не будем).
Используется для получения маршрутной информации для отправки СМС и взаимодействия с СМС-центром.
T8 – API-интерфейс для взаимодействия SCEF с серверами приложений.
Через этот интерфейс передаются как команды управления, так и трафик.
*на самом деле интерфейсов больше; здесь перечислены только самые основные.
Полный список приведен в 3GPP 23.682 (4.3.2 Список контрольных точек).
Ниже приведены ключевые функции и услуги SCEF: привязка идентификатора SIM-карты (IMSI) к внешнему ID; передача не-IP-трафика (Non-IP Data Delivery, NIDD); групповые операции с использованием внешнего идентификатора группы; поддержка режима передачи данных с подтверждением; буферизация данных MO (исходящее мобильное соединение) и MT (завершенное мобильное соединение); аутентификация и авторизация устройств и серверов приложений; одновременное использование данных одного UE несколькими AS; поддержка специальных функций мониторинга состояния UE (MONTE – Monitoring Events); срабатывание устройства; обеспечение роуминга данных без IP. Основной принцип взаимодействия AS и SCEF основан на так называемой схеме.
Подписки.
Если необходимо получить доступ к какому-либо сервису SCEF для конкретного UE, серверу приложений необходимо создать подписку, отправив команду конкретному API запрошенного сервиса и получить в ответ уникальный идентификатор.
После чего все дальнейшие действия и связь с UE в рамках данной услуги будут происходить с использованием этого идентификатора.
Внешний идентификатор: универсальный идентификатор устройства.
Одним из важнейших изменений в схеме взаимодействия AS и устройств при работе через SCEF является появление универсального идентификатора.
Теперь вместо номера телефона (MSISDN) или IP-адреса, как это было в классической сети 2G/3G/LTE, идентификатором устройства для сервера приложений становится «внешний идентификатор».
Это определено стандартом в « @ Формат, знакомый разработчикам приложений.
Разработчикам больше не нужно реализовывать алгоритмы аутентификации устройств; сеть полностью берет на себя эту функцию.
Внешний ID привязан к IMSI, и разработчик может быть уверен, что при обращении к конкретному внешнему ID он взаимодействует с конкретной SIM-картой.
При использовании SIM-чипа вы получаете совершенно уникальную ситуацию, когда внешний идентификатор однозначно идентифицирует конкретное устройство! Более того, к одному IMSI можно привязать несколько внешних идентификаторов — еще более интересная ситуация возникает, когда внешний идентификатор однозначно идентифицирует конкретное приложение, отвечающее за конкретный сервис на конкретном устройстве.
Также появляется идентификатор группы — идентификатор внешней группы, включающий в себя набор индивидуальных внешних идентификаторов.
Теперь одним запросом к SCEF AS может инициировать групповые операции — отправку данных или команд управления множеству устройств, объединенных в одну логическую группу.
В связи с тем, что для разработчиков AS переход на новый идентификатор устройства не может быть мгновенным, SCEF оставил возможность связи AS с UE через стандартный номер – MSISDN. Передача не-IP-трафика (Non-IP Data Delivery, NIDD) В NB-IoT в рамках оптимизации механизмов передачи небольших объемов данных помимо уже существующих типов PDN, таких как IPv4, IPv6 и IPv4v6, появился еще один тип — неIP. В этом случае устройству (UE) не присваивается IP-адрес и данные передаются без использования IP-протокола.
Трафик для таких подключений можно маршрутизировать двумя способами: классическим — MME -> SGW -> PGW и далее через PtP-туннель к AS (рис.
2) или с помощью SCEF (рис.
3).
Классический метод не дает особых преимуществ перед IP-трафиком, кроме уменьшения размера передаваемых пакетов за счет отсутствия IP-заголовков.
Использование SCEF открывает ряд новых возможностей и существенно упрощает процедуры взаимодействия с устройствами.
При передаче данных через SCEF появляются два очень важных преимущества перед классическим IP-трафиком: Доставка МТ-трафика на устройство через внешний идентификатор Чтобы отправить сообщение на классическое IP-устройство, AS должна знать его IP-адрес.
Здесь возникает проблема: поскольку устройство обычно при регистрации получает «серый» IP-адрес, оно общается с сервером приложений, который находится в Интернете, через узел NAT, где серый адрес транслируется в белый.
Комбинация серого и белого IP-адресов действует ограниченное время, в зависимости от настроек NAT. В среднем по TCP или UDP — не более пяти минут. То есть, если в течение 5 минут не будет обмена данными с этим устройством, соединение разорвется и устройство перестанет быть доступным по белому адресу, с которого была инициирована сессия с AS. Есть несколько решений: 1. Используйте пульс.
После того как соединение установлено, устройство должно обмениваться пакетами с AS каждые несколько минут, тем самым предотвращая закрытие трансляций NAT. Но ни о какой энергоэффективности здесь не может быть и речи.
2. Каждый раз при необходимости проверять наличие пакетов для устройства на АС - отправлять сообщение в аплинк.
3. Создайте частную точку доступа (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. Те.
если на одно UE подписано несколько AS, то после получения данных от UE SCEF отправит их всем подписанным AS. Это хорошо подходит для случаев, когда создатель парка специализированных устройств разделяет данные между несколькими клиентами.
Например, создав сеть метеостанций, работающих на NB-IoT, вы сможете продавать данные с них множеству сервисов одновременно.
Гарантированный механизм доставки сообщений Reliable Data Service — это механизм гарантированной доставки сообщений MO и MT без использования специализированных алгоритмов на уровне протокола, таких как, например, рукопожатие в TCP. Он работает путем включения специального флага в служебную часть сообщения при обмене между UE и SCEF. Активировать или нет этот механизм при передаче трафика решает AS. Если механизм активирован, UE включает специальный флаг в служебную часть пакета, когда оно требует гарантированной доставки трафика МО.
После получения такого пакета SCEF отвечает UE подтверждением.
Если UE не принимает пакет подтверждения, пакет SCEF будет отправлен повторно.
То же самое происходит и с MT-трафиком.
Мониторинг устройств (мониторинг событий - MONTE) Как уже говорилось выше, функционал SCEF, помимо прочего, включает в себя функции контроля состояния UE, т.н.
мониторинг устройства.
И если новые идентификаторы и механизмы передачи данных — это оптимизация (пусть и очень серьёзная) существующих процедур, то MONTE — это совершенно новый функционал, которого нет в сетях 2G/3G/LTE. MONTE позволяет AS отслеживать такие параметры устройства, как состояние подключения, доступность связи, местоположение, статус роуминга и т. д. О каждом из них мы поговорим подробнее чуть позже.
Если необходимо активировать какое-либо событие мониторинга для устройства или группы устройств, AS подписывается на соответствующую услугу, отправляя SCEF соответствующую команду API MONTE, которая включает в себя такие параметры, как внешний идентификатор или идентификатор внешней группы, идентификатор AS, мониторинг.
тип, количество отчетов, которые хочет получать 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 больше не доступно ни для трафика данных, ни для сигнализации.
Событие происходит, когда в MME истекает «таймер мобильной достижимости» для UE. В запросе на этот тип мониторинга AS может указать свое значение «Максимальное время обнаружения» — если за это время UE не проявит никакой активности, AS будет проинформирована о том, что UE недоступно, с указанием причины.
Событие также происходит, если UE было принудительно удалено сетью по какой-либо причине.
* Чтобы сеть знала, что устройство все еще доступно, она периодически инициирует процедуру обновления — Tracking Area Update (TAU).
Частота этой процедуры задается сетью с помощью таймера T3412 или (T3412_extended в случае PSM), значение которого передается устройству во время процедуры Attach или следующего TAU. Таймер доступности мобильного телефона обычно на несколько минут дольше, чем T3412. Если UE не выполнило TAU до истечения «Таймера мобильной достижимости», сеть считает, что оно больше недоступно.
Доступность UE — показывает, когда UE становится доступным для DL-трафика или SMS. Это происходит, когда UE становится доступным для поискового вызова (для UE в режиме eDRX) или когда UE входит в режим ECM-CONNECTED (для UE в режиме PSM или eDRX), т. е.
создает TAU или отправляет пакет восходящей линии связи.
Отчет о местоположении.
Этот тип событий мониторинга позволяет AS запрашивать местоположение UE. Может быть запрошено либо текущее местоположение (Current Location), либо последнее известное местоположение (определяемое идентификатором ячейки, из которой устройство выполнило TAU или передало трафик в последний раз), что актуально для устройств в режимах энергосбережения PSM или eDRX. Для «Текущего местоположения» AS может запрашивать повторные ответы, при этом MME информирует AS каждый раз, когда местоположение устройства меняется.
Изменение ассоциации IMSI-IMEI — при активации этого события SCEF начинает отслеживать изменения ассоциации IMSI (идентификатор SIM-карты) и IMEI (идентификатор устройства).
При возникновении события сообщает AS. Может использоваться для автоматической перепривязки внешнего идентификатора к устройству при плановых работах по замене или служить идентификатором при краже устройства.
Статус роуминга – этот тип мониторинга используется AS для определения того, находится ли UE в домашней сети или в сети партнера по роумингу.
Опционально может передаваться PLMN (публичная наземная мобильная сеть) оператора, у которого зарегистрировано устройство.
Сбой связи – данный тип мониторинга информирует АС о сбоях связи с устройством на основании причин сбоя соединения (кода причины освобождения), полученных от сети радиодоступа (протокол S1-AP).
Это событие может помочь определить, почему произошел сбой связи — из-за проблем в сети, например, когда eNodeb перегружен (Радиоресурсы недоступны) или из-за сбоя самого устройства (Потеря радиосоединения с UE).
Доступность после сбоя DDN – это событие сообщает AS, что устройство стало доступным после сбоя связи.
Может использоваться, когда есть необходимость передать данные на устройство, но предыдущая попытка не увенчалась успехом, поскольку UE не ответило на уведомление из сети (пейджинг) и данные не были доставлены.
Если этот тип мониторинга был запрошен для UE, то как только устройство осуществит входящую связь, осуществит TAU или отправит данные в восходящий канал, AS будет проинформирована о том, что устройство стало доступным.
Поскольку процедура DDN (уведомление о данных нисходящей линии связи) работает между MME и S/P-GW, этот тип мониторинга доступен только для IP-устройств.
PDN Connectivity Status – информирует AS об изменении статуса устройства (состояние подключения PDN) – подключении (активация PDN) или отключении (удаление PDN).
Это может использоваться AS для инициации связи с UE или наоборот, чтобы понять, что связь больше невозможна.
Этот тип мониторинга доступен для IP- и не-IP-устройств.
Количество UE, присутствующих в географической области.
Этот тип мониторинга используется AS для определения количества UE в определенной географической области.
Запуск устройства ) В сетях 2G/3G процедура регистрации в сети была двухэтапной: сначала устройство регистрировалось в SGSN (процедура присоединения), затем, при необходимости, активировало контекст PDP - соединение с пакетным шлюзом (GGSN).
для передачи данных.
В сетях 3G эти две процедуры происходили последовательно, т.е.
устройство не ждало момента, когда ему потребуется передать данные, а активировало PDP сразу после завершения процедуры присоединения.
В LTE эти две процедуры были объединены в одну, то есть при подключении устройство сразу запрашивало активацию соединения PDN (аналога PDP в 2G/3G) через eNodeB к MME-SGW-PGW. NB-IoT определяет метод подключения как «подключение без PDN», то есть UE подключается без установления соединения PDN. В этом случае он недоступен для передачи трафика, а может только принимать или отправлять SMS. Для отправки такому устройству команды на активацию ПДН и подключение к АС был разработан функционал «Запуск устройства».
При получении команды на подключение такого UE от AS SCEF инициирует отправку управляющего SMS на устройство через SMS-центр.
При получении SMS устройство активирует PDN и подключается к AS для получения дальнейших инструкций или передачи данных.
Могут быть случаи, когда срок действия подписки вашего устройства на SCEF истекает. Да, у подписки есть свой срок действия, установленный оператором или согласованный с AS. По истечении срока действия PDN будет деактивирован на MME, и устройство станет недоступно для AS. В этом случае также поможет функционал «Срабатывание устройства».
При получении новых данных от AS SCEF узнает статус подключения устройства и доставит данные по SMS-каналу.
Заключение Функционал SCEF, конечно же, не ограничивается описанными выше сервисами и постоянно развивается и расширяется.
В настоящее время для SCEF стандартизировано уже более десятка сервисов.
Сейчас мы коснулись только основных функций, которые востребованы у разработчиков; Об остальном мы поговорим в будущих статьях.
Сразу возникает вопрос: как получить тестовый доступ к этому «чудо» узлу для предварительного тестирования и отладки возможных случаев? Все очень просто.
Любой разработчик может отправить запрос на почту [email protected], в котором достаточно указать цель подключения, описание возможного случая и контактные данные для связи.
Еще увидимся! Авторы: старший эксперт отдела конвергентных решений и мультимедийных сервисов Сергей Новиков санов , эксперт отдела конвергентных решений и мультимедийных сервисов Алексей Лапшин удар Теги: #iot #Интернет вещей #it-инфраструктура #Сотовая связь #МТС #nb-iot #стандарты связи #передача данных
-
Универсальный Манипулятор
19 Oct, 24 -
Питоновые Пасхальные Яйца
19 Oct, 24 -
Университет Внутри Epam
19 Oct, 24 -
Табы В Прошлом? Новый Интерфейс Фф
19 Oct, 24
