Привет, Хабр! Мы – старший менеджер центра развития сетей и решений на базе устройств интернета вещей Виталий Бачук и старший эксперт отдела внедрения новых технологий и мультимедийных сервисов Сергей Новиков – работаем в МТС. В этой статье мы расскажем о практике применения сервиса MONTE, который позволяет разработчику обеспечить быстрое создание и внедрение сервисов за счет простоты и делегирования большей части функционала оператору. А это ведет к сокращению затрат на разработку и удешевлению стоимости устройства.
Ранее в блоге МТС на Хабре вышла статья «NB-IoT: как он работает? Часть 3: SCEF – единое окно доступа к услугам оператора», в которой мы рассказали про уникальный узел SCEF на сети NB-IoT и быстро прошлись по новым возможностям, доступным разработчикам M2M/IoT-сервисов.
Этот материал посвящен практическому применению функционала SCEF. А именно – сервису контроля состояния устройств (мониторинг устройств), именуемому MONTE (Monitoring Events) – события мониторинга.
В комплексных решениях Интернета Вещей, включающих большое количество подключенных энергоэффективных беспроводных устройств, важно контролировать доступность устройств.
Для ясности отметим, что энергоэффективными называются IoT устройства, работающие от одной батареи длительный период времени. При качественной поддержке технологических стандартов и новых фич NB-IoT можно обеспечить срок автономной работы устройства до десяти лет и более от одной батареи. Под доступностью устройства подразумевается возможность отправить данные на IoT платформу или принять запрос от нее.
Для устройств, работающих по беспроводному каналу передачи данных причины, по которым устройства «теряются», могут быть различными. К примеру, мобильное устройство может быть перемещено в локацию, где нет покрытия сети. Устройство могут повредить вандалы, и наконец, (самая банальная причина) может исчерпаться заряд батареи.
С целью сокращения энергопотребления устройство может активировать специальные режимы энергосбережения (PSM, eDRX). В них устройство большую часть времени «спит» и только в определенные моменты времени оно доступно.
Для контроля за доступностью устройств разработчики предусматривают передачу специальных периодических heartbeat пакетов. Так IoT платформа узнает, что устройство работает в штатном режиме. Например, датчику контроля проникновения в канализационный колодец не нужно передавать данные регулярно, а только по событию открытия крышки люка. Тем не менее, приходится хотя бы раз в сутки отправлять heartbeat пакет на IoT платформу для уверенности, что батарея не села, датчик работает штатно и, в случае попытки проникновения в колодец, устройство выполнит свою основную функцию – отправит аварийное сообщение. Что, в свою очередь, запустит бизнес логику событий, и на объект отправятся аварийная бригада или сотрудники охранного предприятия.
Недостаток описанного выше сценария работы датчика в том, что, отправляя heartbeat пакеты, устройство расходует заряд батареи. А значит, устройство проработает от батареи меньше, чем могло бы. Скажем, 5 лет вместо 10 лет. Поэтому возникают дополнительные затраты эксплуатирующей организации на замену батареи.
Вот здесь и приходит на помощь сервис контроля состояния устройств (мониторинг устройств) MONTE. Для технологии NB-IoT в архитектуре сети с SCEF существует возможность улучшить функциональность IoT решения в целом, снизить затраты энергии
устройств в частности и в конечном итоге отказаться от энергозатратных heartbeat пакетов за счет использования специальных уведомлений/событий UE_REACHABILITY и LOSS_OF_CONNECTIVITY. Сеть формирует их и передает на IoT-платформу.
Рассмотрим, как устроены эти MONTE-события.
При регистрации в сети NB-IoT устройство согласовывает с сетью параметры путем обмена служебной информацией. Один из этих параметров отвечает за то, как часто устройство должно информировать сеть о своей доступности – это таймер T3412 либо T3412-E. Таймер T3412-E используется при поддержке устройством режима энергосбережения PSM. Максимальное значение таймера T3412 - 186 минут, при поддержке же PSM и использовании T3412-E таймер может достигать 413 дней. За периодическое информирование сети о том, что устройство по-прежнему доступно, отвечает процедура актуализации TAU (Tracking Area Update). В рамках этой процедуры указанные выше таймеры при необходимости могут быть изменены как устройством, так и сетью. Более детальная информация об этом – в статье: «NB-IoT: как он работает? Часть 2».
Сервис MONTE позволяет «приподнять завесу тайны» служебного обмена данными между устройством и сетью, а также предоставить IoT платформе дополнительный источник информации о состоянии устройства. В таком случае уже не нужно формировать heartbeat пакеты и лишний раз расходовать заряд батареи, ведь сеть сама сообщит IoT платформе о состоянии устройства посредством MONTE-событий.
Событие UE_REACHABILITY передается сетью на IoT платформу всякий раз, когда устройство инициирует процедуру TAU или передает собственные данные через сеть NB-IoT. При активации устройством режима энергосбережения PSM, событие UE_REACHABILITY будет содержать параметр maxUEAvailabilityTimer, указывающий на то, до какого времени устройство будет доступно для получения данных из сети.
Событие LOSS_OF_CONNECTIVITY передается сетью на IoT платформу по истечению определенного таймера, так называемого reachability-timer, когда устройство не сообщило о себе в оговоренный с сетью период времени, не инициировало процедуру TAU (reachability timer всегда больше TAU и зависит от настроек оператора). После чего сеть дает дополнительное время устройству для выхода на связь, так называемого implicitly timer (на практике, порядка 1 часа), по истечению которого информация о регистрации устройства удаляется сетью. И устройству для доступа в сеть NB-IoT повторно требуется провести энергозатратную процедуру регистрации (attach).
Событие LOSS_OF_CONNECTIVITY содержит параметр lossOfConnectReason, который указывает на причину потери служебного обмена данными между устройством и сетью. Если устройство не вышло на связь по истечению reachability timer, то параметр lossOfConnectReason примет значение 2 (так называемое MAX_DETECTION_TIME_EXPIRED_MME). Если устройство выполнило detach или сеть удалила информацию о регистрации устройства, то параметр lossOfConnectReason примет значение 0 (UE_DETACHED_MME).
С точки зрения IoT платформы о штатной работе устройства будут свидетельствовать последовательные уведомления UE_REACHABILITY. При не штатной работе устройства (например, исчезновения его из сети) IoT платформа получит уведомление LOSS_OF_CONNECTIVITY.
Как все это работает на практике?
Чтобы понять это – рассмотрим сервис «NB-IoT. Подписка на события Monitoring Events (MONTE)», реализованного на базе платформы «M2M менеджер» оператора МТС.
После активации сервиса на SIM-карте через Личный Кабинет платформы «M2M менеджер», уведомления UE_REACHABILITY и LOSS_OF_CONNECTIVITY будут передаваться на IoT платформу в виде webhook.
"payload": "{"web_hook_key":"nidd_monte_webhook","type":"UE_REACHABILITY","description":null,"event_time":"2022-06-06T12:06:40.000Z","sim_item_id":3177761,"contract_id":1000003699,"parameters":{"monitoringEventReports":[{"eventTime":"2022-06-06T12:06:40Z","msisdn":"79861300129","monitoringType":"UE_REACHABILITY","reachabilityType":"DATA", "maxUEAvailabilityTime": "2022-06-06T12:06:50Z"}]}}"
Пример уведомления LOSS_OF_CONNECTIVITY:
"payload": "{"web_hook_key":"nidd_monte_webhook","type":" LOSS_OF_CONNECTIVITY ","description":null,"event_time":"2022-06-06T15:12:40.000Z","sim_item_id":3177761,"contract_id":1000003699,"parameters":{"monitoringEventReports":[{"eventTime":"2022-06-06T15:12:40Z","msisdn": "79861300129", "lossOfConnectReason":2, "monitoringType":"LOSS_OF_CONNECTIVITY"}]}}”
Можно также отслеживать уведомления в интерфейсе личного кабинета (ЛК) «M2M менеджер». Выглядит это так:
Приведем два типовых сценария работы устройств NB-IoT с использованием сервиса MONTE.
Сценарий 1:
Автономное устройство - питание от батареи, устройство активирует режим энергосбережения PSM.
Допустим, что у нас есть датчик контроля проникновения в канализационный колодец. Датчик работает в штатном режиме при условии, что крышка канализационного люка не изменяет своего положения, то есть не зафиксировано несанкционированное проникновение в колодец, а регламентные работы в колодце не проводятся. Уведомления UE_REACHABILITY приходят на IoT платформу с периодичностью, обусловленной таймером сна T3412_E режима PSM, активированного на устройстве. Например, каждые 12 часов, устройство «просыпается» и сразу «засыпает», таким образом сообщая о себе в рамках служебного обмена с сетью.
Представим теперь, что у устройства села батарея, сообщить об этом оно по понятной причине не может. Но эта информация необходима IoT платформе, чтобы инициировать работы по замене батареи и вернуть колодец под контроль от несанкционированного проникновения.
В этом случае спустя 12 часов после последнего успешного события UE_REACHABILITY устройство не «проснется» и не сообщит о себе. Соответственно, сеть не направит на IoT платформу очередное уведомление UE_REACHABILITY. Так IoT платформа получит первый косвенный сигнал, что с устройством что-то не в порядке. По истечению reachability timer сеть отправит на IoT платформу уведомление LOSS_OF_CONNECTIVITY, что будет вторым сигналом о проблеме с устройством.
Период получения уведомлений можно сократить, изменяя таймер сна T3412-E режима PSM на устройстве. Например, NB-IoT LBS трекеры от МТС для мониторинга активов «просыпаются» каждые полчаса, соответственно при возникновении проблемы с устройством, IoT платформа узнает об этом в течение 30 минут.
Разберем подробно зависимость периодов уведомлений от таймера сна T3412-E режима PSM.
В момент очередной процедуры TAU, либо при передаче данных, инициированных устройством, в зависимости от параметров PSM рассчитывается значение и активируется таймер сети (reachability timer=11160 сек.). По истечении этого таймера приходит первое уведомление LOSS_OF_CONNECTIVITY с параметром lossOfConnectReason = "2" (не выход устройства на связь), после чего активируется еще один таймер сети (implicitly timer=3480 сек.). По истечении последнего таймера приходит второе и финальное уведомление LOSS_OF_CONNECTIVITY с параметром lossOfConnectReason = "0" (данные о регистрации устройства удалены сетью).
Сценарий 2:
Устройство с внешним питанием, которое не активирует режим энергосбережения PSM. В нормальном режиме работы радиомодуль находится в состоянии IDLE, питание с радиомодуля не снимается.
В нашем примере – электросчетчик со встроенным модемом NB-IoT. Как правило, обычный однофазный бытовой электросчетчик передает данные не чаще одного раза в сутки. В штатном режиме работы уведомления UE_REACHABILITY будут приходить на IoT платформу (в данном случае АСКУЭ) с периодичностью 6 часов.
Представим, что происходит отключение питания на линии, электросчетчик тоже отключается и, поскольку у встроенного в счетчик модема нет батареи для автономной работы, счетчик не успевает отправить аварийное сообщение об отключении питания на IoT платформу.
Спустя 6 часов с момента последнего уведомления UE_REACHABILITY IoT платформа не получит очередное уведомление. Это будет первым косвенным сигналом, что с устройством что-то не в порядке. Далее еще через 36 минут сеть отправит на IoT платформу уведомление LOSS_OF_CONNECTIVITY, что будет вторым сигналом о проблеме с устройством.
Для уменьшения периода времени с момента возникновения аварии до получения уведомления LOSS_OF_CONNECTIVITY на IoT платформе можно даже для устройства с внешним питанием, каковым является электросчетчик, включать режим энергосбережения PSM с относительно небольшим периодом сна (например, 1 час). В таком случае мы возвращаемся к Сценарию 1, описанному выше.
Остановимся на периодах уведомлений для режима работы устройства без активации PSM.
Штатный режим – получение уведомлений UE_REACHABILITY каждые 6 часов или каждые 3 часа в зависимости от настроек радиомодуля. Нештатная ситуация – обрыв питания или потеря сигнала сети устройством. По истечении 6 часов или 3 часов и 6 минут (в зависимости от настроек радиомодуля) не приходит очередное уведомление UE_REACHABILITY. С момента последней процедуры TAU, либо передачи данных, инициированных устройством, рассчитывается значение и активируется таймер сети (reachability timer=23760 сек. или 11160 сек. в зависимости от настроек радиомодуля). По истечении этого таймера приходит первое уведомление LOSS_OF_CONNECTIVITY с кодом "2" (не выход устройства на связь), после чего активируется еще один таймер сети на 58
минут (implicitly-timer) и приходит второе уведомление LOSS_OF_CONNECTIVITY с кодом "0" (данные о регистрации устройства удалены сетью).
Важно отметить, что сервис контроля состояния устройств MONTE не ограничивается описанными событиями. Существуют и другие триггерные события MONTE, все события можно разделить на 4 основные группы:
отвечающие за доступность устройства;
связанные с местоположением;
связанные с разного рода сбоями при передачи данных.
И последняя группа отвечает за контроль за устройством (например, контроль перехода устройства в роуминговую сеть).
Мы рассказали о наиболее востребованных MONTE-событиях, но останавливаться на достигнутом не намерены. Ожидайте новых статей из нашего цикла публикаций о MONTE в блоге МТС на Хабре.
Надеемся, что этот материал будет вам полезен. Если у вас есть вопросы или замечания – с радостью ответим на них в комментариях.
P.S. Контакт для обратной связи прежний. Любой разработчик может отправить запрос на nidd_scef@mts.ru, в письме достаточно указать описание возможного кейса и контактную информацию для связи. Команда МТС оперативно свяжется с вами и предложит наиболее оптимальный вариант при реализации IoT-сервиса, опыт реализации которых накоплен огромный.