"ГОСТ Р 71840-2024 (ИСО/МЭК 30161-1:2020). Национальный стандарт Российской Федерации. Информационные технологии. Интернет вещей. Требования к платформе обмена данными для различных служб интернета вещей. Часть 1. Общие требования"
(утв. и введен в действие Приказом Росстандарта от 29.11.2024 N 1798-ст)

1 ПОДГОТОВЛЕН Федеральным государственным бюджетным учреждением "Российский институт стандартизации" (ФГБУ "Институт стандартизации") и Автономной некоммерческой организацией содействия развитию цифровизации многоквартирных домов "Умный многоквартирный дом" (АНО "Умный многоквартирный дом") на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 194 "Киберфизические системы"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 ноября 2024 г. N 1798-ст

4 Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО/МЭК 30161-1:2020 "Интернет вещей. Требования к платформе обмена данными для различных служб интернета вещей. Часть 1. Общие требования и архитектура" (ISO/IEC 30161-1:2020 Internet of Things (IoT) - Data exchange platform for IoT services - Part 1: General requirements and architecture, MOD), путем изменения отдельных фраз (слов, значений показателей, ссылок), которые выделены в тексте курсивом. Внесение указанных технических отклонений направлено на учет потребностей национальной экономики Российской Федерации.

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).

Протокол связи для NIDD приведен в дополнительном приложении ДА.

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

Сопоставление структуры настоящего стандарта со структурой указанного международного стандарта приведено в дополнительном приложении ДВ

5 ВВЕДЕН ВПЕРВЫЕ

6 ДЕЙСТВУЕТ ВЗАМЕН ПНСТ 433-2020

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

- при горизонтальном подходе службы ИВ должны сосуществовать с ранее разработанными службами в сетях связи (включая Интернет);

- службы ИВ требуют различных эксплуатационных характеристик оконечных точек в сетях связи;

- сети связи для служб ИВ подразделяются на несколько типов. Некоторые типы должны поддерживать специальные функции ИВ для эффективного развертывания служб ИВ;

- для реализации служб ИВ необходимы дополнительные структуры и требования к сетям связи;

- для служб ИВ целесообразна унификация типовых компонентов.

В настоящем стандарте приведены требования и рекомендации по приведенным выше перечислениям.

Настоящий стандарт устанавливает требования к платформе обмена данными интернета вещей для различных служб.

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

Настоящий стандарт содержит рекомендации по внедрению указанных компонентов.

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ Р 70924 (ИСО/МЭК 30141:2018) Информационные технологии. Интернет вещей. Типовая архитектура

Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

В настоящем стандарте применены термины по ГОСТ Р 71777, а также следующий термин с соответствующим определением (см. также [1]):

3.1 узловая точка (nodal point): Точка анализа информации из блоков передачи данных в соответствии с протоколами связи.

В настоящем стандарте применены следующие сокращения:

ИВ - интернет вещей (Internet of things);

API - программный интерфейс приложения (Application Programming Interface);

AS - сервер приложений (Application Server);

ASD - домен приложений и служб (Application & Service Domain);

ASIC - интегральная схема специального назначения (Application-Specific Integrated Circuit);

CAC - контроль коммуникационного доступа (Communication Access Control);

CCN - контентно-ориентированная сеть (Information Centric Network);

DEP - платформа обмена данными интернета вещей (Data Exchange Platform);

DNS - служба доменных имен (Domain Name Service);

ICN - информационно-ориентированная сеть (Information Centric Network);

IP - Интернет-протокол (Internet Protocol);

MQTT - протокол организации очередей доставки телеметрических сообщений (Message Queuing Telemetry Transport);

OBD - домен объектов (Object Domain);

OMD - домен эксплуатации и управления (Operation and Management Domain);

OSI - взаимодействие открытых систем (Open Systems Interconnection);

PKI - инфраструктура открытых ключей (Public Key Infrastructure);

RFID - радиочастотная идентификация (Radio-Frequency Identification);

RID - домен обмена ресурсами (Resource Interchange Domain);

SCD - домен восприятия и контроля (Sensing and Controlling Domain);

SCEF - узел экспонирования сервисных возможностей (Service Capability Exposure Function);

TCP - протокол управления передачей (Transmission Control Protocol);

UD - домен пользователей (User Domain);

UDP - протокол пользовательских датаграмм (User Datagram Protocol);

VPN - виртуальная частная сеть (Virtual Private Network).

В ИВ малые блоки данных от различных датчиков передаются по сетям. Для уменьшения объема трафика и соответствия различным требованиям пользователей целесообразно развертывание DEP. DEP находится на прикладном уровне модели OSI. Передача данных ИВ должна осуществляться через существующие сети связи, например Интернет. DEP должна соответствовать типовой архитектуре ИВ по ГОСТ Р 70924.

DEP не должна влиять на обмен данными, кроме данных ИВ, и допускать обмен данными ИВ и другими данными. В настоящем стандарте принят подход, который изолирует обмен данных ИВ от обмена другими данными. Настоящий стандарт не соответствует стандартам облачных вычислений и граничных вычислений, которые определяют распределенные операции для каждого уровня базовой модели OSI.

Сценарии использования ИВ, использованные при разработке настоящего стандарта, кратко изложены в приложении A.

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

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

Сети, приведенные на рисунке 1, показаны более подробно, с делением на службы ИВ, на рисунке 2. Структура сети для ИВ включает в себя пять типов служб. Тип службы 1 предоставляет локальные службы для ограниченных областей. Типы служб 2 - 5 предоставляют глобальные службы. В глобальных службах для связи между пользователями ИВ и устройствами ИВ может использоваться шлюз ИВ. Сеть ближнего действия обеспечивает связь для ограниченных областей. Для глобальных служб развертываются пользовательская сеть, сеть служб и сеть доступа. Пользовательская сеть используется для приложений ИВ и управляется пользователем ИВ. Сеть служб и сеть доступа поддерживают общие приложения, в том числе специальные приложения ИВ и существующие приложения (например, телефонию, распространение видео и доступ в Интернет). Сеть служб включает в себя функции переключения между местоположениями. Сеть доступа обеспечивает функции мультиплексирования потока трафика из определенной области.

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

С помощью структуры DEP системы ИВ пять служб сети, указанных на рисунке 2, объединяются в три (см. рисунок 3). Типы служб 1, 2 и 3, 4 и 5 переопределены как X, Y и Z соответственно.

DEP обеспечивает совместную работу с информацией в системах ИВ. В настоящем стандарте не рассматриваются технологии облачных вычислений, включая интерфейсы связи с облаком.

DEP распространяется на сущности ИВ и работает как платформа для объединения распределенных частей.

Функции DEP реализуются у пользователя ИВ, в подсистеме доступа и обмена ресурсами, шлюзе ИВ и устройствах ИВ, которые указаны в модели на основе сущностей согласно ГОСТ Р 70924.

Взаимосвязь между DEP и типовой моделью ИВ показана на рисунке 4. В типовой архитектуре ИВ определена типовая модель на основе сущностей и на основе доменов. На рисунке 4 показано расположение функций DEP, объясняющее взаимосвязь между двумя типовыми моделями.

DEP реализует передачу данных в приложения ИВ. DEP не включает в себя обработку данных и облачные вычисления.

DEP должна обеспечивать следующую функциональность:

- DEP должна функционировать независимо от средств и протоколов связи для обеспечения эффективных служб приложений ИВ. DEP должна осуществлять передачу данных между пользователями ИВ и устройствами ИВ через шлюз ИВ, узел NIDD или напрямую. Например, когда большой объем данных с датчиков передается по глобальным сетям с использованием интернет-технологий или NIDD, DEP обеспечивает передачу данных с небольшими накладными расходами (например, с небольшой задержкой обработки и/или небольшим объемом трафика) за счет уменьшения обработки на сложных протоколах, связанных с IP;

- DEP должна динамически контролировать соответствующие функции для приложений ИВ, например контролировать потоки трафика для приложений ИВ и предоставлять требуемое качество обслуживания;

- DEP должна управлять проверкой путей связи и устройств ИВ.

На рисунке 5 показаны точки развертывания функций DEP в четырех сценариях использования: A, B, C, D. В данном подразделе определены требуемые функции DEP. В сценариях использования C и D приложения ИВ, предоставляемые DEP, взаимодействует с ранее разработанными приложениями (например, телефонией, распространением видео и доступом в Интернет). На рисунке 5 показана логическая структура. С точки зрения реализации совместно с узловыми точками для ранее разработанных приложений могут использоваться шлюз ИВ и подсистема доступа и обмена ресурсами, поддерживающие функции DEP.

В каждом сценарии использования DEP функционирует следующим образом:

- сценарий использования A: DEP должна разделять последовательные потоки данных от пользователя ИВ на блоки данных. Далее блоки должны быть переданы подключенным сетевым интерфейсам, как показано на рисунке 6. Подключенные сетевые интерфейсы поддерживают общие службы (например, Интернет). DEP должна изолировать каналы связи для приложений ИВ от других каналов для обеспечения требуемого качества обслуживания. В данном сценарии использования должны применяться технологии виртуализации;

- сценарий использования B: DEP выполняет роль узловой точки. Типы сетей включают в себя сети ближнего действия, сети доступа, сети служб и пользовательские сети. DEP должна применяться во всех типах сетей, кроме сетей ближнего действия. Как показано на рисунке 7, DEP передает приложения ИВ между сетевыми интерфейсами. Другие приложения должны передаваться между сетевыми интерфейсами без участия DEP. DEP должна изолировать каналы связи для приложений ИВ от других приложений для обеспечения требуемого качества обслуживания;

- сценарий использования C: DEP интегрирована в шлюз ИВ. Шлюз ИВ подключается между сетями ближнего действия и сетями доступа. DEP передает приложения ИВ между сетями ближнего действия и сетями доступа, как показано на рисунке 8. DEP должна изолировать каналы связи для приложений ИВ от других приложений для обеспечения требуемого качества обслуживания;

- сценарий использования D: DEP интегрирована с устройствами ИВ, которые включают в себя физические сущности (например, датчики и исполнительные устройства). На основе сигналов от физических сущностей формируются блоки данных. Блоки данных передаются в сеть ближнего действия, как показано на рисунке 9.

DEP системы ИВ должна соответствовать требованиям настоящего раздела. Требования настоящего раздела применяются ко всем сценариям использования, приведенным в разделе 7, если не указано иное. Рекомендации по реализации DEP системы ИВ для каждого сценария использования описаны в приложении B.

DEP состоит из функциональных блоков в соответствии с рисунком 10.

В таблице 1 приведены взаимосвязи между функциональными блоками DEP и сценариями использования. Например, в сценарии использования A не требуется контроль данных и трансляция данных, поскольку DEP расположена на границе служб. В сценарии использования D не требуется контроль данных, поскольку DEP находится в точке соединения с устройствами. Однако сценарий использования D должен включать в себя трансляцию данных, т.к. DEP собирает сигналы от устройств в блоки данных. В сценариях использования B и C DEP действует как узловая точка.

CAC должен обеспечивать обработку протокола для приложений ИВ, как показано на рисунке 11.

CAC в DEP должен транслировать в оконечных точках исходные данные от устройств ИВ или пользователей ИВ в блоки данных и наоборот. В узловых точках CAC должен передать блоки данных другим CAC, независимо от протоколов нижнего уровня и среды передачи.

В блоке CAC должен проводиться контроль большого числа малых блоков данных от датчиков и исполнительных устройств и к ним. Такой контроль позволит упростить операции (например, уменьшенные издержки и простые последовательности связи). Для контроля могут применяться новые сетевые технологии, например, технология ICN, кратко изложенная в приложении C. В технологии ICN выполняются простые последовательности связи с уменьшенными издержками, поскольку отсутствует необходимость определения физических адресов из информации о передаче. Например, в Интернете IP-адреса обнаруживаются DNS. В технологиях ICN процесс обнаружения не требуется. Данный блок должен применяться во всех сценариях использования.

DEP относится к прикладному уровню, как показано на рисунке 12. Следовательно, CAC должен быть адаптирован между приложениями ИВ и нижними уровнями, как показано на рисунке 13. CAC должен абстрагировать протоколы нижнего уровня. В приложениях ИВ для передачи данных могут быть развернуты различные сети. CAC должен обеспечить независимость этих сетей для приложений ИВ, при этом CAC не должен исследовать или изменять содержимое в блоках данных приложений ИВ. В настоящем стандарте механизмы защиты не рассматриваются.

DEP должна обеспечивать сосуществование между приложениями ИВ и другими приложениями (например, ранее разработанными приложениями в Интернете), если другие приложения развернуты. Архитектура сосуществования показана на рисунке 14.

На транспортном уровне и нижнем уровне, называемом инфраструктурой Интернета (см. рисунок 14), приложения ИВ и другие приложения могут работать параллельно. CAC не должен запрашивать модификации инфраструктуры Интернета, если эта инфраструктура развернута. CAC должен работать через интерфейсы транспортных уровней (например, TCP или UDP, или NIDD) и изолировать приложения ИВ от других приложений, используя определенные технологии (например, технологии виртуализации).

Контроль данных кэширует данные в сетях, чтобы уменьшить потоки трафика за счет устранения повторной передачи тех же данных. Контроль данных уменьшает объем трафика в сетях и должен быть установлен в узловых точках (т.е. в сценариях использования B и C).

Трансляция данных должна формировать блоки данных из битовых потоков от устройств ИВ (например, датчиков). Трансляция данных должна проводиться в сценарии использования D.

Контроль ИВ должен предоставлять эксплуатационные параметры для CAC и проводить мониторинг рабочего состояния. Блок должен управлять передачей маршрутов приложений ИВ в сетях. Блок должен быть развернут во всех сценариях использования.

Управление ИВ должно проводить мониторинг сбоев DEP и маршрутов связи между DEP и другой DEP.

Предполагается, что DEP работает на транспортном уровне в стеке протоколов, определенном в 8.3. В других случаях сетевой уровень или нижние уровни подключаются к DEP через функцию адаптации. Функция адаптации зависит от реализации DEP.

Требования к DEP определяются с точки зрения протокола связи. DEP должна позиционироваться как верхний уровень протоколов связи (например, протокол прикладного уровня, приведенного на рисунке 15). При работе на транспортном уровне DEP должна быть подключена к протоколам транспортного уровня (TCP, UDP и NIDD) через обычные сокеты. При работе на других уровнях нижние уровни должны быть адаптированы к DEP через функцию адаптации.

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

Физическое расположение DEP показано на рисунке 16. Для развертывания служб в различных сценариях использования DEP должна абстрагироваться от структуры сети, протоколов и служб. Без использования DEP схема взаимодействия будет сложнее (см. рисунок 17).

- поток пользовательских данных;

- поток данных контроля

Операции DEP показаны на рисунке 18 и определены далее.

Операции DEP:

1) предустановленные маршруты передачи. При подписке пользователей на приложение ИВ управление ИВ устанавливает маршруты передачи в DEP;

2) запрос на сбор данных. При сборе пользователями ИВ данных от устройств ИВ (например, датчиков) передается сообщение запроса в DEP в сетях, использующих предустановленные маршруты. Для данной операции не требуется DNS, хотя он является обязательным для Интернета. В случае нескольких предустановленных маршрутов DEP разрешает выбор маршрута. IP и связанные с ним протоколы изолированы от данной операции;

3) передача данных. Устройство ИВ передает данные в DEP в сетях, описанных в операции 2). DEP может кэшировать данные. Впоследствии, когда пользователь ИВ запрашивает передачу данных, DEP передает данные из кэша вместо устройства ИВ. К механизмам передачи данных применяются технологии ICN (см. приложение C) и NIDD (см. приложение ДА);

4) схемы доступа к данным. В операциях 2) и 3) возможно применение следующих схем:

- синхронная схема: применяются последовательности запроса/данных в CCN, который является типом ICN. Сообщение запроса применяется для запроса на сбор данных. Сообщение данных применяется для передачи данных, соответствующих сообщению запроса. Последовательности запроса/данных являются парными;

- асинхронная схема: применяются последовательности сообщений публикации/подписки в протоколе MQTT, который является типом ICN. Сообщение подписки используется для получения данных. Сообщение публикации используется для передачи данных. Сообщения публикации и подписки вызываются независимо. DEP должна управлять взаимосвязью между этими сообщениями в соответствии с приложениями ИВ.

Примечание - Выбор конкретной схемы определяется разработчиком.

A.1 Система отслеживания сельскохозяйственной продукции: участники и обмен информацией

На рисунке A.1 представлена схема системы ИВ для безопасного распределения сельскохозяйственной продукции среди потребителей.

На представленной схеме различные сенсорные данные (например, данные RFID, данные о сельскохозяйственной продукции, данные сенсорной карты сотрудника) собираются на каждой стадии в цепочке поставок (например, при производстве, обработке, транспортировании и продаже). Проводится централизованный административный контроль данных.

Данные собираются из разных цепочек поставок, поэтому увеличивается объем трафика. Для каждого типа данных ИВ требуется разное качество обслуживания. Для решения этих вопросов для сбора данных развертывается DEP в абстрактных сетях. DEP устанавливается в домене восприятия и контроля, как показано на рисунке A.1.

A.2 Система мониторинга оконечных точек ИВ

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

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

DEP развернута в системе мониторинга как общая платформа для всех приложений. DEP установлена на данные оконечной точки, систему мониторинга и/или шлюз ИВ, как показано на рисунке A.2.

A.3 Система управления энергопотреблением на основе ИВ для промышленных объектов

На рисунке A.3 показана система управления энергопотреблением с использованием сбора различных данных с помощью ИВ. Эта система предоставляет некоторые приложения, использующие собранные данные. На рисунке A.4 показаны ключевые блоки из рисунка A.3.

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

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

B.1 Общие положения

В настоящем приложении приведены рекомендации по функциональной совместимости в DEP, определенных как сценарии использования A, B, C и D. Сущности, включающие DEP для связи, как правило, конфигурируются в соответствии с рисунком B.1. DEP реализуется без адаптации на транспортном уровне. При наличии функции адаптации в DEP могут быть включены функции нижнего уровня согласно рисунку B.2.

В настоящем приложении представлены следующие конфигурации реализации:

- абстракция нижнего уровня в DEP;

- внутренние связи в компоненте DEP.

B.2 Абстракция нижнего уровня в DEP

При работе на транспортном уровне DEP должна быть подключена к этому уровню через интерфейс сокетов, указанный в TCP или UDP. Интерфейс сокетов идентифицируется номерами портов, например присвоенными известными портами или согласованными портами.

Когда контроль коммуникационного доступа в DEP поддерживает несколько протоколов доступа с различными технологиями ICN (см. приложение C) и NIDD (см. приложение ДА), для интерфейсов между DEP и транспортным уровнем следует назначить несколько портов для идентификации каждого протокола доступа (см. рисунок B.3).

Когда в DEP запрашиваются различные возможности связи для передачи информации на нижних уровнях, например маршрут передачи, для интерфейсов между DEP и транспортным уровнем следует назначить несколько портов, чтобы идентифицировать возможности передачи (см. рисунок B.4). Выбор порта вызывается в контроле коммуникационного доступа DEP.

При работе на канальном или физическом уровне DEP должна быть подключена к уровню через функцию адаптации. Функция адаптации объединяет различные интерфейсы на канальном или физическом уровне с интерфейсом сокета (см. рисунок B.5).

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

C.1 В настоящем приложении представлены технологии информационно-ориентированной сети (ICN) в качестве примера платформы обмена данными.

Технологии ICN включают в себя четыре типа. Механизмы типов различны, но основные концепции остаются теми же: уменьшение издержек в Интернете, таких как маршрутизация на основе расположения и обнаружение данных, а также уменьшение объема трафика с использованием сетевого кэша. Существуют следующие типы:

- сетевая архитектура, ориентированная на данные (DONA);

- контентно-ориентированная сеть (CCN);

- парадигма "издатель-подписчик интернет-маршрутизации" (PSIRP);

- сеть информации (NetInf).

PSIRP - это асинхронная архитектура с использованием публикации и подписки. Протокол MQTT относится к данному типу. Другие типы являются синхронной архитектурой с использованием запроса данных по требованию и ответа, которые являются парными. Свойства типов представлены в таблице C.1 (см. также [1]).

Для интеграции с доверенными серверами приложений, расположенными в контуре сети, и с приложениями, подключенными через частные VPN, может быть использована прямая интеграция с SCEF.

Архитектура сети для передачи NIDD через SCEF представлена на рисунке ДА.1 (см. ГОСТ Р 59026).

Взаимодействие сервера приложений с SCEF осуществляется по NIDD REST API. Информация о доступности устройств передается по MONTE REST API.

Технология оптимизации передачи данных NIDD NB-IoT не использует стек протоколов IP и позволяет сократить время нахождения устройств в активном состоянии, обеспечивает обслуживание большего количества устройств в одной локации, улучшает энергоэффективность и обеспечивает безопасность устройств при доступе извне, так как взаимодействие с устройством осуществляется через узел SCEF без прямого доступа устройства в сеть Интернет.