ПНСТ 433-2020

ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии

ИНТЕРНЕТ ВЕЩЕЙ

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

Information technology. Internet of things. Requirements to data exchange platform for various internet of things services

ОКС 35.110

Срок действия с 2021-01-01
до 2024-01-01

Предисловие

     

1 РАЗРАБОТАН Акционерным обществом "Всероссийский научно-исследовательский институт сертификации" (АО "ВНИИС") и Акционерным обществом "Российская венчурная компания" (АО "РВК")

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

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

Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТ Р 1.16-2011 (разделы 5 и 6).

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 121205 Москва, Инновационный центр Сколково, ул.Нобеля, д.1, e-mail: info@tc194.ru и/или в Федеральное агентство по техническому регулированию и метрологии: 123112 Москва, Пресненская набережная, д.10, стр.2.

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В настоящем стандарте применены следующие термины c соответствующими определениями (см. также [1]*):

________________

* Поз. [1]-[2] см. раздел Библиография, здесь и далее по тексту. - Примечание изготовителя базы данных.

3.1 механизм связи (communication mechanism): Механизм, определяющий последовательности и форматы сообщений, которые используются сущностями с интерфейсами связи.

3.2 платформа обмена данными ИВ (IoT data exchange platform): Платформа, включающая в себя функциональные блоки, которые обеспечивают абстракцию малых блоков данных ИВ.

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

3.3 промежуточный программный компонент (middleware component): Компонент, реализуемый программными модулями и включающий в себя базовые функциональные программы с интерфейсами связи.

3.4 функциональность сети (network functionality): Функциональность, предоставляемая функциональными блоками путем обработки информации для передачи в сущность с интерфейсами связи.

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

3.6 сокет (socket): Интерфейс между прикладным уровнем и транспортным уровнем, идентифицируемый номерами портов.

     4 Сокращения

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

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

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

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

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

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

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

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

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

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

     6 Конфигурации сети для служб ИВ

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

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

     Рисунок 1 - Сети в типовой архитектуре ИВ

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

     Рисунок 2 - Конфигурации сети для различных служб

     7 Платформа обмена данными в типовой архитектуре ИВ
     

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

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

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

     7.2 Конфигурации сети для DEP

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

С помощью конфигурации сети для DEP пять конфигураций сети, указанных на рисунке 2, объединяются в три конфигурации (рисунок 3). Конфигурации 1-5 переопределены как конфигурации X, Y и Z.

     Рисунок 3 - Конфигурации сети для DEP

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

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

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

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

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

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

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

     Рисунок 4 - Функции DEP в типовых моделях ИВ

На рисунке 4 подсистема доступа и обмена ресурсами установлена как узловая точка для каждой сети, показанной на рисунке 3.

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

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

     Рисунок 5 - Сценарии использования DEP и взаимосвязь между службами ИВ и другими службами

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

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

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

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

     Рисунок 7 - Функционирование DEP в сценарии использования Б

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

     Рисунок 8 - Функционирование DEP в сценарии использования В

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

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

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

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

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

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

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

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

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

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

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

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

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

     Рисунок 11 - Взаимодействия между блоками САС

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

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

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

     Рисунок 12 - Структура уровней платформы обмена

     Рисунок 13 - Независимость между САС и низкоуровневыми протоколами

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

     Рисунок 14 - Архитектура сосуществования приложений ИВ и других приложений

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

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

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

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

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

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) через обычные сокеты. При работе на других уровнях нижние уровни должны быть адаптированы к DEP через функцию адаптации.

     
     Рисунок 15 - Передача данных между протоколами связи в DEP
     

     8.4 Схема служб

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

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

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

     

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

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

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

     9 Операции платформы обмена данными ИВ

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

- стационарные сети;

- DEP;

- маршруты, предустановленные функциями управления;

- поток данных для приложения ИВ 1;

- поток данных для приложения ИВ 2

     Рисунок 18 - Операции контроля информации с использованием DEP

Операции DEP:

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

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

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

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

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

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

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

Примеры систем на основе платформы обмена данными

     

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

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

     Рисунок А.1 - Система отслеживания сельскохозяйственной продукции

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

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

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

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

     Рисунок А.2 - Система мониторинга оконечных точек ИВ

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

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

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

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

     

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

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

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

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

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

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

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

Таблица Б.1 - Свойства типов технологий ICN

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

Рекомендации по реализации DEP

     

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

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

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

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

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

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

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

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

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

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

     Рисунок В.3 - Реализация поддержки нескольких протоколов доступа в DEP

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

     Рисунок В.4 - Реализация поддержки нескольких интерфейсов сокетов в DEP

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

     Рисунок В.5 - Реализация поддержки нескольких интерфейсов сокетов в DEP с функцией адаптации

В.3 Внутренние соединения в DEP

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

Библиография