И снова привет, Хабр! Эта статья — продолжение цикла материалов, в которых обсуждаем состав и основные принципы работы инфраструктуры NB-IoT. Напомним, что цикл подготовлен на основе собственного практического опыта развёртывания и эксплуатации сети NB-IoT, проведения интеграции с разнообразными устройствами NB-IoT и платформами приложений в различных областях — от экологического мониторинга до энергетики.
Первая статья цикла доступна вот по этой ссылке. Сегодня поговорим об основных методах интеграции с сетью NB-IoT. В частности, обсудим общую часть схемы — это сеть радиодоступа с абонентскими устройствами. Всё самое интересное, как всегда, — под катом.
![](https://habrastorage.org/getpro/habr/upload_files/8f5/6b4/3a1/8f56b43a120550b1a0a9e993d9e806ee.png)
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](https://habrastorage.org/getpro/habr/upload_files/711/1e8/ae8/7111e8ae841690fc0608110c1fa82014.png)
Какое преимущество у этого метода интеграции? Он ближе всего к «классическим методам», используемым в сетях 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](https://habrastorage.org/getpro/habr/upload_files/863/d36/b37/863d36b37e80a6a848445d34a40fca9e.png)
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](https://habrastorage.org/getpro/habr/upload_files/0fd/b35/10d/0fdb3510d083f3a38c09e36aa90dbda0.png)
Взаимодействие сервера приложений с SCEF реализуется при помощи NIDD REST API. Информация о доступности устройств передаётся по MONTE REST API. M2M-менеджер в этом способе интеграции не используется. И есть ещё важный момент: требуется предварительное согласование с клиентом данных по NIDD APN и eхеernalID его устройств.
Интеграция с SCEF через M2M-менеджер
![Интеграция с SCEF через M2M-менеджер Интеграция с SCEF через M2M-менеджер](https://habrastorage.org/getpro/habr/upload_files/534/d42/e71/534d42e71e3ffbd8b6ef1ae7d00f1ba4.png)
У этого способа интеграции есть несколько отличий по сравнению с предыдущим вариантом:
Предварительные настройки NIDD APN, ExternalID и т. д. осуществляются администратором клиента непосредственно в личном кабинете M2M-менеджера.
Эндпоинт API NIDD SCEF — M2M-менеджер.
Информация о доступности устройств передаётся посредством MONTE WebHook.
Интеграция с SCEF через IoT HUB
![Интеграция с SCEF через IoT HUB Интеграция с SCEF через IoT HUB](https://habrastorage.org/getpro/habr/upload_files/103/572/717/103572717c137a12a3340c14557d3be3.png)
Это расширенный вариант интеграции, описанной в пункте «Прямая интеграция с 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](https://habrastorage.org/getpro/habr/upload_files/a0f/164/43b/a0f16443bc2369e2e33e529c95b675a2.png)
Если у вас есть вопросы или дополнения к статье, поделитесь в комментариях — обсудим. В ближайшее время опубликуем третью статью из нашего цикла, так что не переключайтесь.