Создание маломощного сетевого устройства Интернета вещей – CodesCode

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

Построение батарейного IOT устройства является очень интересным вызовом. Прогресс в технологиях позволил чипам IOT-модулей выполнять больше функций, чем когда-либо ранее. Существуют наборы микросхем, которые сегодня имеют размер меньше пенни, но при этом обладают GPS, Wi-Fi, сотовой связью и возможностями обработки приложений. С этими достижениями настал подходящий момент для создания малогабаритных устройств IoT, которые могут подключаться к облаку и решать интересные задачи во всех областях.

Существует множество приложений, где необходимо внешнее подключение к IOT-устройству для запроса выполнения определенной задачи. Подумайте об устройстве умного домашнего замка, которое должно открывать и закрывать дверной замок с помощью мобильного приложения. Или об отслеживающем активы устройстве, которое должно начинать регистрировать своё местонахождение по запросу. Основная идея заключается в возможности отправки команд на эти устройства и заставления их выполнять определенные действия.

Постановка проблемы

На первый взгляд, может показаться достаточно простым достичь этого. Подключите IOT-устройство к сети, свяжите его с сервером и заставьте его ожидать команд. Что тут такого, спросите вы? Однако есть несколько препятствий для работы в низкопотребляющей батарейной конфигурации.

Сотовое радио требует больших энергозатрат на батарею. Устройство, постоянно подключенное к сети, быстро разряжает батарею. За поддержание постоянного сетевого соединения требуется значительное количество энергии, что сокращает срок службы батареи до неприемлемого уровня для большинства батарейных приложений, ожидаемый срок службы от нескольких месяцев до нескольких лет. Такое устройство должно быть спроектировано таким образом, чтобы как можно больше экономить энергию и продлить его срок службы.

Применяя первопричинное мышление к проблеме большого энергопотребления, вызванного сотовыми подключениями, мы можем задать критический вопрос: Необходимо ли устройству оставаться подключенным к сети всегда? В большинстве случаев устройству может не потребоваться передавать или принимать какие-либо данные, и нет смысла держать его подключенным к сети. Что, если бы мы могли заставить его оставаться в режиме «сна» и периодически просыпаться, чтобы проверить наличие входящих команд? Это означало бы, что устройство подключается к сети только при необходимости, таким образом экономя энергию. Это основная идея режимов энергосбережения LTE-M. LTE-M предлагает два режима: PSM и eDRX. Давайте рассмотрим их подробнее.

Режим PSM

В режиме PSM IoT-устройство может запросить вход в спящий режим (RRC Idle) на протяжении до 413 дней. Этот режим особенно полезен для устройств, которым нужно периодически передавать данные по сети и затем возвращаться в режим сна. Следует отметить, что устройство полностью недоступно во время нахождения в спящем состоянии.

Это профили питания устройства в режиме PSM.

[Рис. 1: Профиль мощности PSM]

Устройство остается в спящем состоянии на протяжении продолжительного времени, пока не проснется, чтобы передать данные. Кроме того, есть короткое окно просмотра, в течение которого устройство доступно для взаимодействия, после чего оно возвращается в режим сна. Увеличение времени сна может привести к большей экономии энергии, но может потребовать снижения частоты передачи данных. В конечном итоге, разработчику придется найти оптимальный баланс между временем сна и требуемым разрешением данных в зависимости от требований приложения. Умный счетчик энергии, возможно, прекрасно работает с обновлениями раз в день, но GPS-трекеру, который нуждается в более частых обновлениях, может понадобиться короткое время сна.

Режим eDRX

Термин eDRX означает “расширенная разрывная приемная работа”. Концепция схожа с режимом PSM, где устройство переходит в RRC Idle, но в отличие от режима PSM, в eDRX устройство периодически просыпается для “проверки” сети каждый период eDRX цикла.

Максимальное время сна для устройств eDRX составляет до 43 минут для устройств, использующих LTE-M.

[Рис. 2: Профиль мощности eDRX]

По сравнению с eDRX устройство в режиме PSM требует гораздо большего времени для пробуждения из режима сна и оставшейся активности, так как оно должно установить соединение с сетью, прежде чем сможет получить данные приложения. При использовании eDRX, устройству достаточно проснуться и прослушать 1 мс, в то время как с PSM устройство должно проснуться, принять и передать управляющие сообщения примерно 100-200 мс, прежде чем оно сможет получить сообщение от облачного приложения, что приводит к разнице в 100 раз. [1]

Хотя эти режимы питания кажутся многообещающими для низкопотребляющего сетевого устройства Интернета вещей, создание достижимого устройства, то есть устройства, которое может отправлять пакет сообщения внешне через сеть, по-прежнему представляет сложность. Мы рассмотрим детали вызовов, с которыми сталкиваются протоколы TCP, SMS и UDP-коммуникации.

Соображения по коммуникационным протоколам

Существует множество коммуникационных протоколов Интернета вещей, которые подходят для различных видов приложений Интернета вещей, но для целей данной статьи мы классифицируем их на два вида.

Протоколы, основанные на соединении: TCP-протоколы MQTT, Websockets, HTTP
Протоколы без соединения: UDP-протоколы MQTT-SN, CoAP, LWM2M и SMS.

Протоколы, основанные на соединении

Для передачи данных эти коммуникационные протоколы требуют активного соединения через сеть. Соединение устанавливается посредством трехстороннего рукопожатия и выглядит примерно так:

[Рис. 3: Иллюстрация трехстороннего рукопожатия]

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

Во-вторых, обратите внимание, что в иллюстрации инициатором соединения является клиент; это осознанное ограничение протоколов на основе соединения (TCP, MQTT и т. д.) при применении сетевого достижимого устройства, которое требует, чтобы устройство отвечало на запрос сервера.

Клиент может инициировать первое соединение и держать его открытым, но для поддержания соединения необходимо периодически отправлять пакеты keep-alive через предопределенные интервалы, что также вызывает большую нагрузку на аккумуляторную батарею, что делает эти протоколы непригодными и неэффективными для низкопотребляющего сетевого достижимого устройства.

[Рис. 4: Энергопрофиль для протокола TCP]

Протоколы без соединения

Протоколы без соединения не требуют активного соединения с сервером для передачи данных. Они предлагают гораздо более перспективные возможности для приложения сетевого достижимого устройства Интернета вещей. Некоторые примеры таких протоколов – MQTT-SN, CoAP и LWM2M, реализованные поверх UDP.

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

Несмотря на то, что сами протоколы не требуют соединения, в подлежащей сети все же требуется периодическая передача данных для поддержания активных NAT-переводов. NAT (Network Address Translation) – это устройства, обычно используемые в домашних и корпоративных сетях, которые имеют время ожидания для записей перевода в своих таблицах. Если устройство, использующее протоколы без соединения, остается неактивным в течение продолжительного времени, превышающего время ожидания NAT, соответствующая запись перевода удаляется, что делает изначального клиента недоступным для сети. Для решения этой проблемы необходимо реализовать периодическую отправку сообщений keep-alive или другие механизмы для поддержания NAT-переводов и обеспечения непрерывной сетевой доступности устройств Интернета вещей, использующих протоколы без соединения, но это очень дорогое решение для аккумулятора и не идеально для устройства Интернета вещей, где аккумулятор – ресурс с ограниченными возможностями.

Вывод

Как мы рассмотрели в этой статье, создание сетевого достижимого устройства является вызовом на всех уровнях, от ограничений устройства до ограничений инфраструктуры. Протоколы связи на основе UDP предлагают многообещающее будущее для низкопотребляющих сетевых достижимых устройств, потому что фундаментальная логистическая проблема с тайм-аутами NAT, упомянутая выше, может быть устранена с использованием частной сети и обходом NAT в целом. По мере роста интереса к потребности в сетевых достижимых устройствах мы должны увидеть конкретные коммерческие сетевые инфраструктуры, предлагающие готовые решения для этих вызовов.