И снова привет, Хабр! Эта статья — продолжение цикла материалов, в которых обсуждаем состав и основные принципы работы инфраструктуры NB-IoT. Напомним, что цикл подготовлен на основе собственного практического опыта развёртывания и эксплуатации сети NB-IoT, проведения интеграции с разнообразными устройствами NB-IoT и платформами приложений в различных областях — от экологического мониторинга до энергетики.

Первая статья цикла доступна вот по этой ссылке. Сегодня поговорим об основных методах интеграции с сетью NB-IoT. В частности, обсудим общую часть схемы — это сеть радиодоступа с абонентскими устройствами. Всё самое интересное, как всегда, — под катом.

TCP/IP и UDP/IP поверх NB-IoT

Сервер приложений может быть подключён непосредственно к PGW. Данные передаются через интерфейс PGW SGi. Адрес сервера приложений определяется при установлении устройством IP-соединения. В случае, если нужна конверсия протоколов, интеграция может осуществляться через IoT HUB.

Интеграция применима ко всем протоколам, базирующимся на IP: TCP, UDP, CoAP, lwM2M, HTTP, MQTT и т. д. Она может быть проведена как для внешних серверов приложений, так и для доверенных серверов приложений, расположенных внутри контура МТС. M2M-менеджер используется для управления услугами и SIM-картами.

Интеграция TCP/IP и UDP/IP поверх NB-IoT
Интеграция TCP/IP и UDP/IP поверх NB-IoT

Какое преимущество у этого метода интеграции? Он ближе всего к «классическим методам», используемым в сетях 2G/3G/LTE. Для передачи данных устройство также должно установить IP-сессию, после чего данные передаются непосредственно на IP-адрес сервера приложений.

Важный момент: этот метод интеграции не является целевым. Мы не рекомендуем его применять массово, так как в этом случае неэффективно используются ресурсы сети и не удаётся использовать все преимущества технологии NB-IoT. В качестве исключения можно применять интеграцию при использовании протокола UDP, так как он имеет меньшую избыточность по сравнению с TCP/IP.

NIDD без SCEF через интерфейс SGi

В случае отсутствия SCEF non-IP данные к AS могут передаваться через Point-to-Point (PtP) тоннель от PGW. В этом случае инкапсуляция в IP будет производиться уже на нём. Сервер приложений может быть подключён непосредственно к PGW. Адрес сервера приложений определяется на этапе создания APN. Если же нужна конверсия протоколов, интеграцию можно реализовать через IoT HUB.

Интеграция применима ко всем протоколам, базирующимся на UDP: CoAP, lwM2M, проприетарные протоколы. Она может быть проведена как для внешних серверов приложений, так и для доверенных серверов приложений, расположенных внутри контура МТС.

Интеграция NIDD без SCEF через интерфейс SGi
Интеграция NIDD без SCEF через интерфейс SGi

M2M-менеджер используется для управления услугами и SIM-картами, кроме услуг NIDD.

Для этого вида интеграции есть некоторые ограничения:

  • Требуется поддержка UDP API со стороны AS. Это актуально для систем, которые работают с устройствами по протоколу TCP/IP.

  • Требуется реализация идентификации и аутентификации устройств на уровне приложения как со стороны AS, так и со стороны устройства. Это приводит к увеличению передаваемого объёма служебной информации и увеличивает нагрузку на сеть NB-IoT. При работе с SCEF это не требуется, т. к. идентификация и аутентификация обеспечиваются API SCEF.

  • Обратный канал (управления устройством) недоступен в произвольные моменты времени. Он используется лишь в короткие промежутки времени после передачи данных от устройства, что обусловлено наличием узла NAT в схеме. Снятие этого ограничения возможно с применением статических IP-адресов и выделенного корпоративного APN.

  • Доставка данных не гарантируется на уровне транспортного протокола UDP при передаче между CSGN/PGW и AS, необходима реализация гарантированной доставки на уровне приложения (протоколы CoAP, lwM2M и др.).

  • Взаимодействие возможно только с 1 AS PtP.

Преимущества решения:

  • Возможность работы устройства с передачей данных Non-IP в роуминге в случае, если у роумингового партнёра нет SCEF.

Прямая интеграция с SCEF для передачи данных NIDD

Для интеграции с доверенными серверами приложений, расположенными в контуре МТС, стоит использовать прямую интеграцию с SCEF. Это же относится и к приложениям, подключённым через частные VPN. Все внешние серверы приложений интегрируются через M2M-менеджер.

Прямая интеграция с SCEF для передачи данных NIDD
Прямая интеграция с SCEF для передачи данных NIDD

Взаимодействие сервера приложений с SCEF реализуется при помощи NIDD REST API. Информация о доступности устройств передаётся по MONTE REST API. M2M-менеджер в этом способе интеграции не используется. И есть ещё важный момент: требуется предварительное согласование с клиентом данных по NIDD APN и eхеernalID его устройств.

Интеграция с SCEF через M2M-менеджер

Интеграция с SCEF через M2M-менеджер
Интеграция с SCEF через M2M-менеджер

У этого способа интеграции есть несколько отличий по сравнению с предыдущим вариантом:

  • Предварительные настройки NIDD APN, ExternalID и т. д. осуществляются администратором клиента непосредственно в личном кабинете M2M-менеджера.

  • Эндпоинт API NIDD SCEF — M2M-менеджер.

  • Информация о доступности устройств передаётся посредством MONTE WebHook.

 Интеграция с SCEF через IoT HUB

Интеграция с SCEF через IoT HUB
Интеграция с SCEF через IoT HUB

Это расширенный вариант интеграции, описанной в пункте «Прямая интеграция с SCEF для передачи данных NIDD». Он используется в том случае, когда требуется поддержка взаимодействия сервера приложений по одному из стандартных протоколов, таких как CoAP, MQTT, lwM2M и т. д., либо по проприетарным протоколам.

Альтернативный метод доставки данных через SMS

Помимо NIDD доступен альтернативный механизм доставки данных по SMS — Device Triggering. Его появление обусловлено наличием разных способов подключения устройств к сети NB-IoT, т. н. Attach without PDN. В этом случае устройство регистрируется, но не запрашивает PDN-соединение для передачи данных. Устройство недоступно для передачи трафика и может только принимать или отправлять SMS.

В случае использования устройством «серого» IP-адреса, когда сервер приложений расположен в интернете, общение проходит через узел NAT. Узел NAT обеспечивает трансляцию «серого» адреса в «белый». Связка «серого» и «белого» IP-адресов держится ограниченное время. В среднем для TCP или UDP — не более пяти минут. То есть если в течение 5 минут не было обмена данными с этим устройством, связка распадётся, и устройство перестанет быть доступным по «белому» адресу. На помощь может прийти Device Triggering. AS может отправить сообщение по SMS на устройство с командой установить сессию с AS для передачи информации.

Существует 2 интерфейса доставки данных по SMS: SMPP (базовый) либо DT REST API через SCEF.

Доставка данных на устройство NB-IoT посредством SMS
Доставка данных на устройство NB-IoT посредством SMS

Если у вас есть вопросы или дополнения к статье, поделитесь в комментариях — обсудим. В ближайшее время опубликуем третью статью из нашего цикла, так что не переключайтесь.

Комментарии (2)


  1. beho1der
    31.05.2023 02:21

    Лучше бы примеры с реальными устройствами.


  1. prbs
    31.05.2023 02:21

    копи из инструкции по эксплуатации?