NB-IoT: как он работает? Часть 2

    В прошлый раз мы говорили об особенностях нового стандарта NB-IoT с точки зрения архитектуры сети радиодоступа. Сегодня порассуждаем, что изменилось в ядре сети (Core Network) при NB-IoT. Итак, поехали.


    image

    В ядре сети произошли значительные изменения. Начнем с того, что появился новый элемент, а также ряд механизмов, которые определены стандартом как “CIoT EPS Optimization” или оптимизации опорной сети для сотового интернета вещей.

    Как известно, в мобильных сетях существует два основных канала коммуникаций, которые называются Control Plane (CP) и User Plane (UP). Control Plane предназначен для обмена служебными сообщениями между различными элементами сети и служит для обеспечения мобильности (Mobility management) устройств (UE) и установления/поддержания сессии передачи данных (Session Management). User Plane — это, собственно, канал передачи пользовательского трафика. В классическом LTE распределение CP и UP по интерфейсам выглядит следующим образом:

    image

    Механизмы оптимизации CP и UP для NB-IoT реализовываются на узлах MME, SGW и PGW, которые условно объединяются в единый элемент под названием C-SGN (Cellular IoT Serving Gateway Node). Также стандарт предполагает появление нового элемента сети — SCEF (Service Capability Exposure Function). Интерфейс между MME и SCEF называется T6a и реализован на базе протокола DIAMETER. Несмотря на то, что DIAMETER это сигнальный протокол, в NB-IoT он адаптирован для передачи малых объемов non-IP данных.

    image

    Исходя из названия, SCEF — это узел экспонирования сервисных возможностей. Другими словами, SCEF скрывает сложность сети оператора, а также снимает с разработчиков приложений необходимость идентификации и аутентификации мобильных устройств (UE), предоставляя возможность серверам приложений (Application Server, далее AS) получать данные и управлять устройствами через единый API интерфейс.

    Идентификатором UE становится не телефонный номер (MSISDN) или IP адрес, как это было в классической сети 2G/3G/LTE, а так называемый «external ID», который определен стандартом в привычном для разработчиков приложений формате «<Local Identifier>@<Domain Identifier>». Это отдельная большая тема, заслуживающая отдельного материала, поэтому подробно об этом сейчас говорить не будем.

    Теперь разберемся c наиболее значимыми нововведениями. «CIoT EPS Optimization» — это оптимизация механизмов передачи трафика и управления абонентскими сессиями. Вот основные из них:

    • DoNAS
    • NIDD
    • Механизмы энергосбережения PSM и eDRX
    • HLCOM

    DoNAS (Data over NAS):

    Это механизм, разработанный для оптимизации передачи малых объемов данных.

    В классическом LTE абонентское устройство при регистрации в сети устанавливает PDN connection (далее PDN) через eNodeB к MME-SGW-PGW. Соединение UE-eNodeB-MME — это так называемый “Signaling Radio Bearer” (SRB). При необходимости передать/получить данные UE устанавливает еще одно соединение с eNodeB — “Data Radio Bearer” (DRB), для передачи пользовательского трафика к SGW и далее на PGW (интерфейсы S1-U и S5 соответственно). По окончании обмена и при отсутствии трафика в течение некоторого времени (обычно 5-20 секунд) эти соединения разрываются и устройство переходит в режим ожидания или “Idle Mode”. При необходимости обмена новой порцией данных SRB и DRB переустанавливаются.

    В NB-IoT передача пользовательского трафика может осуществляться через сигнальный канал (SRB), в сообщениях протокола NAS (http://www.3gpp.org/more/96-nas). Установление DRB больше не требуется. Это значительно снижает сигнальную нагрузку, экономит радиоресурсы сети и, самое важное — продлевает срок жизни батареи устройства.

    На участке eNodeB — MME пользовательские данные начинают передаваться по интерфейсу S1-MME, чего не было в классической технологии LTE, и используется для этого протокол NAS, в котором появляется “User data container”.

    image

    Для осуществления передачи “User Plane“ от MME к SGW появляется новый интерфейс S11-U, который предназначен для передачи малых объемов пользовательских дынных. В основе протокола S11-U лежит GTP-U v1, который используется для передачи User Plane и на других интерфейсах сети 3GPP-архитектуры.
    image
    NIDD (non-IP data delivery):

    В рамках дальнейшей оптимизации механизмов передачи малых объемов данных, в дополнение к уже существующим типам PDN, таким как IPv4, IPv6 и IPv4v6, появился еще один тип — non-IP. В этом случае UE не присваивается IP адрес, и данные передаются без использования протокола IP. На то есть несколько причин:

    1. IoT устройства, такие как датчики, могут передавать очень малые объемы данных, 20 байт и даже меньше. Учитывая, что минимальный размер IP заголовка — 20 байт, инкапсуляция в IP иногда может быть достаточно дорогим удовольствием;
    2. Нет необходимости реализации в чипе IP-стека, что ведет к их удешевлению (вопрос к обсуждению в комментариях).

    По большому счету, IP адрес необходим IoT устройствам, чтобы передавать данные через интернет. В концепции NB-IoT SCEF выступает в роли единой точки подключения AS, и обмен данными между устройствами и серверами приложений происходит посредством API. При отсутствии SCEF non-IP данные к AS могут передаваться через Point-to-Point (PtP) тоннель от PGW и инкапсуляция в IP будет производиться уже на нем.

    Все это вписывается в парадигму NB-IoT — максимальное упрощение и удешевление устройств.

    Механизмы энергосбережения PSM и eDRX:

    Одним из ключевых преимуществ LPWAN сетей является энергоэффективность. Заявляется срок до 10 лет автономной работы устройства на одной батарее. Разберемся, каким образом достигаются такие значения.

    Когда устройство потребляет меньше всего энергии? Правильно, когда оно выключено. И если полностью обесточить девайс нельзя, давайте обесточим радио модуль, на то время, пока в нем нет необходимости. Только предварительно надо согласовать это с сетью.

    PSM (Power saving mode):

    Режим энергосбережения PSM позволяет устройству надолго выключать радио модуль, оставаясь при этом зарегистрированным в сети, и не переустанавливать PDN каждый раз при необходимости передать данные.

    Чтобы сеть знала, что устройство по-прежнему доступно, оно периодически инициирует процедуру актуализации — Tracking Area Update (TAU). Частота этой процедуры задается сетью при помощи таймера T3412, значение которого передается устройству во время процедуры Attach или очередного TAU. В классическом LTE дефолтное значение этого таймера 54 минуты, а максимальное — 186 минут. Однако, для обеспечения высокой энергоэффективности, необходимость выхода в радиоэфир каждые 186 минут — это слишком дорогое удовольствие. Для решения этой проблемы и был разработан механизм PSM.

    Устройство активирует режим PSM передавая в сообщениях «Attach Request» или «Tracking Area Request» значения двух таймеров T3324 и T3412-Extended. Первый определяет время, которое устройство будет доступно после перехода в «Idle Mode». Второй — это время, через которое должен быть произведен TAU, только теперь его значение может достигать 35712000 секунд или 413 дней. В зависимости от настроек, MME может принять значения таймеров, полученные от устройства, или изменить их, передав новые значения в сообщениях «Attach Accept» или «Tracking Area Update Accept». Теперь устройство может не включать радио модуль 413 дней и оставаться при этом зарегистрированным в сети. В результате получаем колоссальную экономию ресурсов сети и энергоэффективность устройств!

    image

    Однако в этом режиме устройство недоступно только для входящих коммуникаций. При необходимости передать что-либо в сторону сервера приложений устройство может в любой момент выйти из PSM и отправить данные, оставшись после этого активным в течение таймера T3324 для приема информационных сообщений от AS (если таковые будут).

    eDRX (extended discontinuous reception):

    eDRX, расширенный режим прерывистого приема. Чтобы передать данные на устройство, которое находится в «Idle mode», сеть выполняет процедуру оповещения — «Paging». При получении пейджинга устройство инициирует установление SRB для дальнейшей коммуникации с сетью. Но чтобы не пропустить адресованное ему сообщение Paging, устройство должно постоянно мониторить радиоэфир, что также достаточно энергозатратно.

    eDRX — это режим, при котором устройство принимает сообщения от сети не постоянно, а периодически. Во время процедур Attach или TAU устройство согласовывает с сетью временные промежутки, в которые оно будет «слушать» эфир. Соответственно, в эти же промежутки будет производиться процедура Paging. В режиме eDRX работа устройства разбивается на циклы (eDRX cycle). В начале каждого цикла идет так называемое «окно пейджинга» (Paging Time Window, далее PTW) — это время, которое устройство слушает радиоканал. По окончании PTW устройство отключает радио модуль до конца цикла.
    image
    HLCOM (high latency communication):

    При необходимости передать данные в Uplink устройство может выйти из любого из этих двух режимов энергосбережения, не дожидаясь окончания PSM или eDRX цикла. Но вот передать данные на устройство возможно, только когда оно активно.

    Функционал HLCOM или коммуникация с высокими задержками — это буферизация Downlink пакетов на SGW на время, пока устройство находится в режиме энергосбережения и недоступно для коммуникации. Буферизированные пакеты будут доставлены, как только устройство выйдет из PSM, сделав TAU или передав Uplink трафик, или, когда наступит PTW.

    Это, безусловно, требует осознания со стороны разработчиков IoT-продуктов, поскольку общение с устройством получается не в реальном времени и требует определенного подхода к конструированию бизнес логики работы приложений.

    В заключении скажем: внедрение нового всегда захватывает, а сейчас мы имеем дело со стандартом, до конца не обкатанным даже у мировых «зубров», вроде Vodafone и Telefonica – поэтому это захватывает вдвойне. Наше изложение материала не претендует на абсолютную полноту, но надеемся обеспечивает достаточное понимание технологии. Будем признательны за обратную связь.

    Автор: Эксперт отдела конвергентных решений и мультимедийных сервисов Алексей Лапшин
 aslapsh
    • +19
    • 4,3k
    • 8
    МТС
    96,00
    Компания
    Поделиться публикацией

    Комментарии 8

      +1
      Все таки по NB-iot. Я, если честно, один вопрос для себя не только не прояснил но еще больше запутался после прочтения статей :(

      Вот есть у меня устройство, оно подключается к сети, а как я как администратор буду эти данные получать? Мне необходимо будет в сети оператора развернуть свой сервер, или оператор все мои пакеты будет мне заворачивать? Извиняюсь за глупые вопросы, но банально в живую пощупать не могу вот и приходится выглядеть идиотом :)
        0

        Есть ваш девайс с модулем связи. Он регистрируется в сети и временно получает свой IPv4 адрес за NATом оператора. Отправляя пакет на свой сервак в интернете вы можете "пробить дырку" и вести сессию обмена по UDP.
        Фишка NB-IoT в том, что устройство оффлайн 99% времени, иногда выходя в инет по расписанию, выкачивая свои данные и загружая то, что скопилось для него в облаке. Разумеется для такого решения практичнее какой-нибудь протокол CoAP, вместо традиционных HTTP, MQTT и прочих, основанных на TCP.
        Если я правильно помню документашку на модуль связи, то у него также есть функционал приема и отправки SMS, но вот до этого руки не доходили

          +1
          Статья вносит еще больше смятения…
          в статье пишут <Нет необходимости реализации в чипе IP-стека>, вы пишете IPv4.
          Я еще меньше что то понимаю…
          <Фишка NB-IoT в том, что устройство оффлайн 99% времени> это на самом деле не фишка это умеет почти любая железка которая расчитана на работу годами от батареек, ЛОра, зигби, треад, все умеют спать годами и один раз выйдя в сеть слать и забирать инфу.
            0
            в статье пишут <Нет необходимости реализации в чипе IP-стека>, вы пишете IPv4.
            non-IP это отдельная фишка. Есть классический IPv4/IPv6, а есть передача данных от устройства до ядра сети оператора без получения IP. А вот от сети МТС забрать данные со своего устройства можно несколькими способами, через SCEF или туннелем до ядра.
          0
          Есть несколько вариантов как получить данные от устройства. Самый простой- разместить сервер (AS) в интернете и указать на устройстве его адрес в качестве «destination IP». В таком режиме поддерживается как IPv4 так и IPv6. Этот способ не требеут интеграции с сетью опретора.

          Для работы с non-IP необходимо поднимать туннель от PGW до AS. Подойдет любой: IPsec, GRE, l2tp, но самый простой вариант- UDP.
          Также можно проинтегрировать сервер с SCEF и получать данные от устройств через API. Тут уже появляются возможности не только обмена данными с устройствами, но и, например, их мониторинга. Правда это уже «enterprise» решение с полноценной интеграцией и разработкой.
          0
          В МТС можно уже потестировать NB-IoT?
            0
            как обычная связь TCP/UDP, HTTP, MQTT…
            или связь — non IP (сокет без IP)
              0
              Данные с Вашего устройства с NB-IoT модемом снимаете точно так же как с устройства с GPRS/EDGE/LTE модемом по IPv4/6, т.е. client pull mode — устройство просыпается, идет на предопределенный FQDN/IPv4/IPv6 адрес сервера, либо если передаваемых данных совсем мало — по новому протоколу, свойственному NB-IoT который NIDD, через шлюз оператора посредством некого API.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое