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

(утв. и введен в действие Приказом Росстандарта от 29.11.2024 № 1798-ст)

ИСТОРИЯ ИЗМЕНЕНИЙ НОРМАТИВНО-ТЕХНИЧЕСКИХ АКТОВ

flowchart LR
  n0["ПНСТ 433-2020"]:::rst
  click n0 "https://bukva.ai/docs/standart-pnst-433-2020" "ПНСТ 433-2020. Предварительный национальный стандарт Российской Федерации. Информационные технологии. Интернет вещей. Требования к платформе обмена данными для различных служб... ("
  n1["ГОСТ Р 71840-2024"]:::doc
  click n1 "https://bukva.ai/docs/standart-gost-r-71840-2024" "ГОСТ Р 71840-2024. Национальный стандарт Российской Федерации. Информационные технологии. Интернет вещей. Требования к платформе обмена данными для различных служб интернета вещей."
  n0 --> n1
classDef rst fill:#FFEBEB,stroke:#8B0000,color:#000;
classDef doc fill:#EBFFEB,stroke:#006400,color:#000;
classDef notEnt fill:#FFFFEB,stroke:#FF8C00,color:#000;

1 февраля 2025 года

Предисловие

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

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

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

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

Введение

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

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

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

1 Область применения

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

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

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

2 Нормативные ссылки

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

ГОСТ Р 59026 Информационные технологии. Интернет вещей. Протокол беспроводной передачи данных NB-IoT. Основные параметры

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

ГОСТ Р 71777 (ИСО/МЭК 20924:2024) Информационные технологии. Интернет вещей. Термины и определения

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

3 Термины и определения

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

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

4 Сокращения

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

ИВ — интернет вещей (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);

NIDD — передача данных без использования стека протоколов IP (Non-IP data delivery);

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).

5 Краткие сведения о службах ИВ

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

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

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

6 Структура сети для служб ИВ

6.1 Структура сети для ИВ

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

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

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

6.2 Модели сети для DEP системы ИВ

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

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

7 DEP в типовой архитектуре ИВ

7.1 Общие положения

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

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

7.2 Описание

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

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

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

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

7.3 Функционирование DEP в системе ИВ

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

Рисунок 5 — Сценарии использования DEP и взаимосвязь

Рисунок 6 — Функционирование DEP в сценарии использования A

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

Рисунок 9 — Функционирование DEP в сценарии использования D

8 Требования к DEP системы ИВ

8.1 Общие положения

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

8.2 Требования к функциональным блокам

8.2.1 Функциональные блоки

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

Рисунок 10 — Функциональные блоки DEP

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

Таблица 1

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

8.2.2 Контроль коммуникационного доступа

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) и изолировать приложения ИВ от других приложений, используя определенные технологии (например, технологии виртуализации).

8.2.3 Контроль данных

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

8.2.4 Трансляция данных

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

8.2.5 Контроль ИВ

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

8.2.6 Управление ИВ

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

8.2.7 Адаптация

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

8.3 Протоколы связи

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

8.4 Схема служб

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

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

Рисунок 17 — Связи между пользователями ИВ и службами ИВ без использования DEP

9 Операции DEP

	- стационарные сети;
	- DEP;
	- маршруты, предустановленные функциями управления;
	- поток данных для приложения ИВ 1;
	- поток данных для приложения ИВ 2

Операции 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 (справочное)

ПРИМЕРЫ СИСТЕМ НА ОСНОВЕ DEP

Рисунок A.1 — Система отслеживания

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

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

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

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

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

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

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

Рисунок A.4 — Ключевые блоки, указанные на рисунке A.3

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

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

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

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

Рисунок B.1 — Конфигурация сущностей, включающих DEP

Рисунок B.2 — Конфигурация сущностей, включающих DEP без адаптации

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

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

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

нескольких интерфейсов сокетов в DEP

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

Рисунок B.5 — Реализация поддержки нескольких

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

(справочное)

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

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

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

Таблица C.1

Свойства типов технологий ICN

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

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

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

Приложение ДБ (справочное)

МЕЖДУНАРОДНЫМ СТАНДАРТАМ, ИСПОЛЬЗОВАННЫМ В КАЧЕСТВЕ

СОПОСТАВЛЕНИЕ СТРУКТУРЫ НАСТОЯЩЕГО СТАНДАРТА СО СТРУКТУРОЙ

БИБЛИОГРАФИЯ