Размышления про национальный стандарт NB-Fi и биллинговые системы

Коротко о главном

В 2017 году на Хабре появилась заметка “В Росстандарт подали проект национального стандарта NB-FI для Интернета вещей”. В 2018 году технический комитет “Киберфизические системы” работал над тремя проектами IoT:

ГОСТ Р «Информационные технологии. Интернет вещей. Термины и определения»,
ГОСТ Р «Информационные технологии. Интернет вещей. Эталонная архитектура интернета вещей и индустриального интернета вещей», ГОСТ Р «Информационные технологии. Интернет вещей. Протокол обмена для интернета вещей в узкополосном спектре (NB-FI)».

В феврале 2019 года был утвержден ПНСТ-2019 «Информационные технологии. Интернет вещей. Протокол беспроводной передачи данных на основе узкополосной модуляции радиосигнала NB-Fi». С 1 апреля 2019 года он начал действовать и завершит свое действие 1 апреля 2022 года. За три года действия предварительный стандарт должен быть опробован на практике, должен быть оценен его рыночный потенциал, подготовлены поправки в стандарт.

В СМИ документ активно позиционируется как “первый национальный стандарт IoT РФ, с перспективой стать международным стандартом” и в пример приводится реализованный на NB-Fi “ВАВИОТ” проект в Казахстане.

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

Про стандарты передачи данных IoT

В сети можно наткнуться на значение около 300 протоколов/технологий передачи данных между устройствами, которые можно отнести к IoT. Живем мы в России, работаем на B2B, поэтому в публикации затронем лишь несколько:

• NB-IoT

Стандарт сотовой связи для устройств телеметрии. Один из трех, которые реализуются в сетях LTE Advanced — NB-IoT, eMTC и EC-GSM-IoT. Большая тройка сотовых операторов РФ в 2017-2018 годах развернули участки сетей, работающие с NB-IoT. Про eMTC и EC-GSM-IoT операторы не забывают, но выделять их отдельно сейчас не будем.

• LoRa

Работает на нелицензируемых частотах. Хорошо о стандарте рассказано в статье конца 2017 года “Что такое LoRaWan” на Хабре. Живет на чипах Semtech.

• “Стриж”

Работает на нелицензируемых частотах. Отечественный поставщик решений для ЖКХ и других отраслей. Использует свой протокол XNB. Говорят о производстве в России, но обещают обеспечить массовое производство чипов в России только в 2020 году, пока живут на ОN Semiconductor (ON Semiconductor AX8052F143).

• Свежий NB-Fi

Работает на нелицензируемых частотах. Использует тот же чип ON Semiconductor AX8052F143 что и “Стриж”, ТТХ аналогичны, тоже анонсы производства собственных чипов в России. В общем, взаимосвязь прослеживается. Протокол открытый.

Про интеграцию с биллингами

Для тех, кто пытался собрать себе “умный дом”, быстро становится очевидно, что использование датчиков разных производителей существенно осложнено. Даже если на двух устройствах видим одну надпись о технологии связи — выясняется, что коммуницировать они друг с другом не хотят.

В B2B сегменте ситуация аналогична. Разработчики протоколов, чипов хотят зарабатывать. Начиная проект с LoRa нужно будет в любом случае покупать оборудование на чипах Semtech. Обращая внимание на отечественного производителя можно получить в нагрузку покупку сервисов и базовых станций, а в будущем, при успешном запуске производства чипов в России, потенциально оборудование/элементную базу можно будет купить только у ограниченного количества вендоров.

Мы работаем с телеком оборудованием и для нас привычно получать данные по телеметрии оборудования, агрегировать, нормализовывать и передавать дальше в различные информационные системы. За этот блок работ у нас отвечает Forward TI (Traffic Integrator). В типовом варианте это выглядит так:

В случае с расширением потребностей заказчика по сбору данных подключаются дополнительные модули:

Ориентировочная скорость роста рынка IoT-устройств — 18-22% в год в мире и до 25% в России. В апреле на IoT Tech Spring 2019 в Москве Андрей Колесников, директор Ассоциации интернета вещей, озвучивал годовой рост в 15-17%, но по сети разная информация ходит. На РИФ в апреле 2019 на слайдах давали данные о ежегодном росте российского рынка Интернета вещей в 18% до 2022 года, там же был указан объем российского рынка в 2018 году — $3.67 миллиарда. Что характерно, на этом же слайде поминали и повод для сегодняшней статьи «Утвержден первый российский документ по стандартизации в области IoT…». По нашему мнению, назрела уже реальная потребность штатно интегрировать базовые станции UNB/LPWAN и телекоммуникационных серверов в биллинговые системы.

Размышления

Первая линия

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

Значит в условной локации будут организовывать сеть по одному принципу и собирать данные будет одна организация. Назовем такую организацию оператор-агрегатор данных.

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

Много раз видел, как люди выгребают из почтового ящика штук по 5 квитанций ежемесячно, для меня самого такая ситуация знакома. Отдельная квитанция на газ, отдельная на электричество, отдельная на капитальный ремонт, отдельная на воду, отдельная на обслуживание дома. И это не считая оплаты ежемесячных счетов, которые существуют только в онлайне – оплата доступа в интернет, сотовые, подписки на различные сервисы поставщиков контента. Где-то можно настроить автооплату, где-то нельзя. Но общая ситуация такая, что это уже становится традицией – садиться раз в месяц и оплачивать все счета, процесс может растягиваться на полчаса-час, а если в очередной раз что-то в информационных системах поставщиков глючит, то приходится переносить часть оплат на другой день. Я бы предпочел взаимодействовать с одним поставщиком услуг по всем вопросам, а не разделять внимание на десяток платежек и сайтов. Современные банки упрощают жизнь, но не полностью.

Поэтому автоматический сбор данных по потребленным услугам и перенос для конечного клиента оплаты услуг в одно «окно» — это благо. Упомянутый выше сбор данных через трафик интеграторы, типа нашего Forward TI – это лишь вершина айсберга. Трафик интегратор представляет собой первую линию, через которую будут собираться данные телеметрии и полезная нагрузка и в отличие от провайдеров, которым важен объем потребления трафика сам по себе, в IoT приоритет будет отдаваться полезной нагрузке.

Давайте на близком нам примере из телекома рассмотрим, чем занимается первая линия. Есть оператор, оказывающий услуги связи. Происходит звонок длительностью в 30 минут. 15 минут звонка попали в одни сутки, 15 в другие. Телефонная станция на границе суток разделила звонок и записала его в 2 CDRa, по сути сделала из одного звонка два. TI по косвенным признакам склеит такой звонок и передаст в систему тарификации данные об одном звонке, хотя с оборудования данные пришли о двух. На уровне сбора данных должна быть система, умеющая разрешать такие коллизии. А вот следующая система должна получать уже нормализованные данные.

Информация в трафик интеграторе не только нормализуется, но и обогащается. Еще один пример: с телефонной станции не приходят данные для зональной тарификации, но мы знаем из какой локации был произведен звонок и TI добавляет информацию о географических зонах тарификации в данные, которые передает в следующую информационную систему. Аналогично можно проставлять любые вычисляемые параметры. Это пример простого зонирования или обогащения данных.

Еще одна функция трафик интегратора – агрегация данных. Пример: с оборудования приходят данные каждую минуту, а в учетную систему TI отдает данные за час. В учетной системе остаются только данные требующиеся для тарификации и выставления счетов, вместо 60 записей делается только одна. При этом происходит резервное копирование “сырых” данных на случай необходимости их обработки.

Вторая линия

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

Минутка саморекламы, потому что проще на своем софте иллюстрировать, чем придумывать абстрактные примеры.

На этой линии агрегатор использует в своем инвентаре:

• Billing, учитывающий поступления подготовленных данных от TI, привязку их к зарегистрированным потребителям (абонентам), корректную тарификацию этих данных в соответствии с используемым тарифным планом, формирование счетов и квитанций, прием средств от абонентов и разнесение их на соответствующие счета и балансы.
• PC (Product Catalog) для создания комплексных пакетных предложений и управления услугами в составе этих пакетов, задания правил подключения дополнительных услуг.
• BMS (Баланс-менеджер), данная система обязательно должна быть многобалансовая, потребуется гибкое управление списаниями за различные услуги, также она даст возможность использования нескольких специализированных биллинговых систем обслуживающих отдельные услуги и агрегации полученных от них расчетов применительно к общему балансу абонента.
• eShop для взаимодействия с конечными потребителями, создания публичной витрины услуг, предоставления доступа в Личный кабинет со всеми современными плюшками типа статистики использования услуг, переключения услуг в онлайне, обращений за новыми услугами.
• BPM (Бизнес-процессы) автоматизация бизнес-процессов агрегатора направленных как на обслуживание абонентов, так и на взаимодействие с поставщиками услуг.

Третья линия

Вот тут начинается самое интересное с моей точки зрения.

Во-первых, появляется необходимость в системах класса PRM (Partner Management System), которая позволит гибко управлять агентскими и партнерскими схемами. Без такой системы управлять работой партнеров и поставщиков будет сложно.

Во-вторых, появляется потребность в DWH (Data Warehouse) для анализа. Тут есть где развернуться с BigData на данных телеметрии и полезной нагрузки, сюда же пойдет создание витрин для BI-средств и анализа различного уровня.

В-третьих, ну и как вишенка на торт, можно дополнить комплекс системой для прогнозирования типа Forward Forecast. Данная система позволит обучить математическую модель лежащую в основе системы, сегментировать абонентскую базу, формировать прогнозы потребления и поведения абонентов.

Совокупно вырисовывается довольно сложная информационная архитектура оператора-агрегатора.

Почему мы выделяем в статье три линии, а не объединяем их? Дело в том, что бизнес-системе обычно важны несколько агрегированных параметров. Остальное нужно для мониторинга, обслуживания, анализа отчетности и прогнозирования. Детальная информация требуется для безопасности и Big Data, потому что мы часто не знаем, какие параметры и по каким критериям заходят анализировать в Big Data аналитики, поэтому в DWH передаются все данные в исходном виде.

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

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

Что мы ожидаем в будущем и про экономику проектов IoT

Сначала про экономику. Выше мы писали про объем рынка. Кажется, что достаточно большие деньги уже задействованы. Но мы видели, как не сходится экономика проектов, которые пытались реализовать с нашей помощью или на которые нас приглашали для оценки. Например, мы просчитывали создание MVNO для M2M с использованием sim-карт для сбора телеметрии с определенного типа оборудования. Проект не запустили, потому что экономическая модель оказалась нежизнеспособной.

Крупные телеком-организации продвигаются на рынок IoT – у них есть инфраструктура, готовые технологии. Новых абонентов-людей в России появляется довольно мало. А вот рынок IoT дает прекрасные возможности для роста и извлечения дополнительной прибыли из своих сетей. Пока тестируется предварительный национальный стандарт, пока небольшие компании-энтузиасты выбирают разные варианты реализации UNB/LPWAN крупный бизнес будет вливать средства в захват рынка.

Мы считаем, что со временем какой-то один стандарт/протокол передачи данных начнет доминировать, как это было с сотовой связью. После этого риски уменьшатся, оборудование станет доступнее. Но рынок к тому моменту уже может быть наполовину захвачен.

Обычные люди привыкают к сервису, им удобно, когда автоматизированные устройства учитывают воду, газ, свет, интернет, канализацию, тепло, обеспечивают работу охранной и пожарной сигнализации, тревожной кнопки, видеонаблюдения. Люди созреют к массовому использованию IoT в сфере ЖКХ в перспективе ближайших 2-5 лет. Чуть больше уйдет на то, чтобы доверить роботам холодильник и утюг, но это время тоже не за горами.

Опасения

О предварительном национальном стандарте NB-Fi громко заявили, как претенденте на международное признание. Среди плюсов названа низкая стоимость радиопередатчиков для устройств и возможность их производства в России. Еще в 2017 году в вышеупомянутой статье на Хабре анонсировалось:

Базовая станция стандарта NB-FI будет стоить в районе 100-150 тыс. руб., радиомодуль для подключения устройства к Сети — около 800 руб., стоимость контроллеров для сбора и передачи информации со счётчика — до 200 руб, стоимость батарейки — 50-100 руб.

Но пока это лишь планы и фактически важная часть элементной базы для устройств производится за рубежом. В самом ПНСТ прописан в явном виде ON Semiconductor AX8052F143.

Хочется надеяться, что протокол NB-Fi будет действительно открытым и доступным, без спекуляций на импортозамещении и навязывании. Станет конкурентным продуктом.

IoT — это модно. Но надо помнить, что в первую очередь “интернет вещей” не про итемизацию и навешивание отправки данных в облако со всего, что можно. “Интернет вещей” про инфраструктуру и оптимизацию Machine-to-Machine. Беспроводной сбор данных со счетчиков электроэнергии сам по себе не IoT. А вот автоматизированное распределение электроэнергии по потребителям из нескольких источников — государственных, частных поставщиков — для всего населенного пункта уже похоже на оригинальную концепцию интернета вещей.

На базе какого стандарта вы бы стали строить свою сеть сбора данных? Возлагаете какие-то надежды на NB-Fi, стоит вкладывать средства в развитие биллинговых систем для сбора данных с устройств этого стандарта? Может быть участвовали в реализации проектов IoT? Поделитесь своим опытом в комментариях.

И удачи!

Источник: habr.com