ПНСТ 423-2020
(ИСО/МЭК 20005:2013)

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

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

СЕТИ СЕНСОРНЫЕ

Службы и интерфейсы, поддерживающие совместную обработку данных в интеллектуальных сенсорных сетях

Information technology. Sensor networks. Services and interfaces supporting collaborative information processing in intelligent sensor networks

ОКС 35.110
         35.020

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

Предисловие

     

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

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

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

4 Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО/МЭК 20005:2013* "Информационные технологии. Сенсорные сети. Службы и интерфейсы, поддерживающие совместную обработку данных в интеллектуальных сенсорных сетях" (ISO/IEC 20005:2013 "Information technology - Sensor networks - Services and interfaces supporting collaborative information processing in intelligent sensor networks", MOD) путем изменения отдельных фраз (слов, значений показателей, ссылок), которые выделены в тексте курсивом**. Внесение указанных технических отклонений направлено на учет потребностей национальной экономики Российской Федерации.

________________

* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей.

** В оригинале обозначения и номера стандартов и нормативных документов приводятся обычным шрифтом, кроме отмеченного в разделе "Предисловие" знаком "**". - Примечания изготовителя базы данных.

           

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

5 Некоторые элементы настоящего стандарта могут быть объектами патентных прав. Международная организация по стандартизации (ИСО) и Международная электротехническая комиссия (МЭК) не несут ответственности за установление подлинности каких-либо или всех таких патентных прав

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

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

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

Введение

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

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

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

Настоящий стандарт устанавливает:

- функциональные возможности CIP и функциональную модель CIP;

- общие службы поддержки CIP;

- общие интерфейсы служб для CIP.

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

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

ГОСТ Р ИСО/МЭК 7498-1 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель

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

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

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

3.1 регистрация данных (data registration): Процесс преобразования различных наборов данных в одну систему координат.

3.2 событие (event): Все, что происходит или рассматривается как происходящее в одно мгновение или за определенный промежуток времени.

3.3 набор служб/поднабор служб (service set/service subset): Группа или подгруппа служб, обеспечивающих общие механизмы или средства для удовлетворения определенных требований пользователей или приложений.

     4 Сокращения

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

CDE - сущность декларации возможностей (Capability Declaration Entity);

CIP - совместная обработка информации (Collaborative Information Processing);

CRSE - сущность спецификации требований связи (Communication Requirement Specification Entity);

CS - основная служба (Core Service);

CSPE - сущность планирования совместной стратегии (Collaborative Strategy Planning Entity);

ES - расширенная служба (Enhanced Service);

FAR - вероятность ложных тревог (False Alarming Rate);

FCR - требование к функциональным возможностям (Functional Capability Requirement);

GSR - обобщенное системное требование (Generalized System Requirement);

OSI/RM - взаимосвязь открытых систем/эталонная модель (Open Systems Interconnection/ Reference Model);

QoS - качество обслуживания (Quality of Service);

SAP - точка доступа к службе (Service Access Point).

     5 Общее описание
     

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

Система из одной или более сенсорных сетей интегрирует процессы восприятия, передачи и обработки данных/информации и предоставления информации. На рисунке 1 представлено функциональное многоуровневое архитектурное представление системы сенсорных сетей.

     

Рисунок 1 - Многоуровневое представление системы сенсорных сетей

Уровень базовых функций реализует базовую функциональность, выполняемую на нижних уровнях эталонной модели взаимосвязи открытых систем (OSI/RM по ГОСТ Р ИСО/МЭК 7498-1), в том числе на физическом, канальном, сетевом и другом необязательном уровнях связи. Выше уровня базовых функций находятся уровень приложений и уровень служб. Уровень приложений предоставляет службы отдельным приложениям и/или пользователям и реализует такие функции, как публикация информации, индексирование, обработка информации и т.д. Уровень служб предоставляет общие универсальные службы для сущностей на прикладном уровне, в том числе службу локализации, службу синхронизации времени, службу защиты и др.

     5.2 Требования к интеллектуальным сенсорным сетям

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

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

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

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

     5.3 Обзор совместной обработки информации (CIP)

Системы сенсорных сетей собирают исходные сенсорные данные из физического мира и извлекают из исходных данных информацию о свойствах, информацию для принятия решений и знания о физическом мире.

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

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

CIP может быть представлена с трех разных точек зрения. На рисунке 2 показана трехмерная концептуальная модель CIP.

Первая точка зрения рассматривает уровни обработки CIP. С этой точки зрения CIP может быть реализована на уровне данных, уровне функций и уровне решений.

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

Рисунок 2 - Концептуальная модель CIP

Третья точка зрения рассматривает компоненты задач CIP. Компоненты задач зависят от конкретных сценариев применения сенсорных сетей. В системе защиты от вторжений компонентами задач являются обнаружение цели, классификация, локализация и отслеживание для служб безопасности. В системе медицинского контроля компоненты задач могут включать измерение артериального давления/температуры, проверку дыхания и анализ походки. На рисунке 2 показано, что для компонента задач CIP "отслеживание" для приложения 1 применяется обработка на уровне решений и на уровне свойств и используются сущности датчиков и модулей обработки.

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

     5.4 Функциональная модель CIP

На рисунке 3 показана функциональная модель CIP. CIP характеризуется тремя сущностями, а именно сущностью декларации возможностей (CDE), сущностью планирования совместной стратегии (CSPE) и сущностью спецификации требований связи (CRSE).

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

Наиболее важной сущностью CIP является сущность планирования совместной стратегии (CSPE). CSPE использует информацию, предоставленную CDE, и решает, как будет осуществляться совместная обработка информации. CSPE принимает решение, при котором может быть достигнута лучшая производительность обработки информации при эффективном использовании ресурсов. Для принятия решения используются функции стоимости или критерии полезности.

Для реализации выбранного решения могут быть использованы две парадигмы вычислений: централизованные вычисления и распределенные вычисления. В парадигме распределенных вычислений существует несколько локальных вычислительных центров/центров объединения. В парадигме централизованных вычислений существует только один центральный вычислительный центр/центр объединения. Парадигма определяется сущностью CSPE. Сущность CSPE должна указывать пространственную и временную корреляцию между различными локальными центрами, которая может быть динамической.

Рисунок 3 - Функциональная модель CIP

Сущность спецификации требований к связи (CRSE) действует как интерфейс между поставщиком информационных служб и обменом информацией. CRSE определяет параметры и протоколы связи. Должны быть указаны такие требования, как сквозная задержка, временный джиттер, битовая ошибка и другие параметры QoS.

     5.5 Службы, поддерживающие CIP

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

Службы, поддерживающие CIP, включают два класса: основные службы (CS) и расширенные службы (ES) (см. рисунок 4). Основные службы включают фундаментальные и обязательные службы. Расширенные службы реализуются путем объединения служб, например интеграции двух или более основных служб или других общих служб.

Рисунок 4 - Обзор служб, поддерживающих CIP

5.5.1 Основные службы, поддерживающие CIP

Основные службы, поддерживающие CIP:

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

- служба логической группировки. Служба реализует функции, связанные с созданием и управлением логической группой для реализации CIP на уровне приложений. Логическая группа - это логический набор сущностей сенсорной сети, участвующих в задачах обработки информации, таких как обнаружение цели, классификация, локализация и отслеживание цели. Служба логической группировки обеспечивает механизм установления отношений сотрудничества между сущностями;

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

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

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

- служба межузловой активации. Служба предоставляет механизмы инициирования выполнения задач и запуска модулей в одном сенсорном узле из другого сенсорного узла. Служба обеспечивает динамическое управление задачами;

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

5.5.2 Расширенные службы, поддерживающие CIP

Расширенные службы, поддерживающие CIP:

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

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

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

     6 Основные службы и интерфейсы
     

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

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

Таблица 1 - Основные службы и наименования SAP

     6.2 Служба событий

Сервис мероприятий предоставляется через EVENT-SAP. EVENT-SAP - это логический интерфейс между службой событий на уровне служб и сущностью CIP на уровне приложения. Логический интерфейс включает в себя набор примитивов (см. таблицу 2) и их параметры (см. таблицу 3).

Таблица 2 - Примитивы EVENT-SAP

Таблица 3 - Параметры примитивов EVENT-SAP

6.2.1 EVENT-SUB.request

Примитив запрашивает процесс подписки на события. Параметры примитива:

EVENT-SUB.request {
EVSubSourceID,
EVSubDestinationID,
EVSubModel,
EVSubValue
}
     

Параметры примитива приведены в таблице 3.

Примитив используется сущностью CIP для подписки на события. После получения примитива сущность, предоставляющая службу событий, реализует подписку на события в узле EVSubDestinationID для узла EVSubSourceID.

6.2.2 EVENT-SUB.indication

Примитив указывает сущности CIP подписку на событие. Параметры примитива:

EVENT-SUB.indication {
EVSubSourceID,
EVSubDestinationID,
EVSubModel,
EVSubValue
}
     

Параметры примитива приведены в таблице 3.

Примитив используется для указания подписки на событие уровнем служб.

6.2.3 EVENT-SUB.confirm

Примитив подтверждает подписку на событие уровнем служб. Параметры примитива:

EVENT-SUB.confirm {
EVSubSourceID,
EVSubDestinationID,
EVSubResultCode
}
     

Параметры примитива приведены в таблице 3.

Примитив сообщает о результате запроса на подписку на событие. Результат подписки указывается в параметре EVSubResultCode.

6.2.4 EVENT-REG.indication

Примитив указывает сущности CIP на возникновение события. Параметры примитива:

EVENT-REG.indication {
EVSubSourceID,
EVSubDestinationID,
EV_Time
}
     

Параметры примитива приведены в таблице 3.

Примитив для указания уровнем служб возникновения события. При возникновении нескольких событий примитив генерируется более одного раза. При получении примитива сущности CIP сообщается о возникновении события. Время возникновения или обнаружения события указывается в EV_Time.

6.2.5 EVENT-UNSUB.request

Примитив запрашивает отмену подписки на события. Параметры примитива:

EVENT-UNSUB.request {
EVSubSourceID,
EVSubDestinationID,
EVSubmodel,
EVSubValue
}
     

Параметры примитива приведены в таблице 3.

Примитив используется сущностью CIP для отмены подписки. При получении примитива сущность, предоставляющая службу событий, отменяет подписку на событие в узле EVSubDestinationID для узла EVSubSourceID.

6.2.6 EVENT-UNSUB.confirm

Примитив подтверждает отмену подписки на событие. Параметры примитива:

EVENT-UNSUB.confirm {
EVSubSourceID,
EVSubDestinationID,
EVSubResultCode
}
     

Параметры примитива приведены в таблице 3.

Примитив подтверждает отмену подписки на событие. Результат отмены указывается в параметре EVSubResultCode.

     6.3 Служба логической группировки

Служба логической группировки предоставляется через LG-SAP. LG-SAP - это логический интерфейс между сущностью службы логической группировки на уровне служб и сущностью CIP на уровне приложения. Логический интерфейс включает в себя набор примитивов (см. таблицу 4) и их параметры (см. таблицу 5).

Таблица 4 - Примитивы LG-SAP

Таблица 5 - Параметры примитивов LG-SAP

6.3.1 LG-ESTABLISH.request

Примитив запрашивает создание логической группы. Параметры примитива:

LG-ESTABLISH.request {
LGRequestorID,
LGCoordinatorID,
LGMaxNum
}
     

Параметры примитива приведены в таблице 5.

Примитив используется сущностью CIP для запроса создания логической группы. При получении примитива узел LGCoordinatorID создает логическую группу и объявляет себя в качестве координатора новой логической группы. LGCoordinatorID используется в качестве имени или идентификатора новой логической группы. Устанавливается таблица участников в логической группе с количеством записей LGMaxNum. Таблица поддерживается в узле LGCoordinatorID. Узел может быть одновременно координатором не более чем одной логической группы, но участником нескольких логических групп.

6.3.2 LG-ESTABLISH.indication

Примитив указывает создание логической группы. Параметры примитива:

LG-ESTABLISH.indication {
LGRequestorID,
LGCoordinatorID,
LGMaxNum
}
     

Параметры примитива приведены в таблице 5.

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

6.3.3 LG-ESTABLISH.confirm

Примитив подтверждает установление логической группы уровнем служб. Параметры примитива:

LG-ESTABLISH.confirm {
LGRequestorID,
LGCoordinatorID,
LGResultCode
}
     

Параметры примитива приведены в таблице 5.

Примитив сообщает результат запроса на установление логической группы. Параметр LGResultCode указывает на успешный результат, если создана логическая группа, координируемая узлом LGCoordinatorID. В противном случае узлу LGRequestorID указывается ошибка.

6.3.4 LG-MEMBERIN.request

Примитив запрашивает участие в логической группе. Параметры примитива:

LG-MEMBERIN.request {
LGCoordinatorID,
LGMemberINID
}
     

Параметры примитива приведены в таблице 5.

Примитив используется сущностью CIP из уровня приложений в узле LGMemberINID для запроса участия в логической группе, которая координируется узлом LGCoordinatorID. При получении примитива если текущее число участников меньше максимального числа участников логической группы, то узел LGCoordinatorID добавляет LGMemberINID в таблицу участников логической группы, и текущее число участников увеличивается на 1. В противном случае генерируется значение LGResultCode для указания заполнения логической группы.

6.3.5 LG-MEMBERIN.confirm

Примитив подтверждает результат запроса участия в логической группе сущности CIP. Параметры примитива:

LG-MEMBERIN.confirm {
LGCoordinatorID,
LGMemberINID,
LGResultCode
}
     

Параметры примитива приведены в таблице 5.

Примитив сообщает результат запроса участия в логической группе. В LGResultCode записывается успешный результат, если узел LGMemberINID присоединился к логической группе, координируемой узлом LGCoordinatorID. В противном случае указывается ошибка.

6.3.6 LG-MEMBEROUT.request

Примитив запрашивает выход из логической группы. Параметры примитива:

LG-MEMBEROUT.request {
LGCoordinatorID,
LGMemberOUTID
}
     

Параметры примитива приведены в таблице 5.

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

6.3.7 LG-MEMBEROUT.confirm

Примитив подтверждает для сущности CIP результат запроса выхода из логической группы. Параметры примитива:

LG-MEMBERIN.confirm {
LGCoordinatorID,
LGMemberOUTID,
LGResultCode
}
     

Параметры примитива приведены в таблице 5.

Примитив сообщает результат запроса выхода из логической группы. Параметр LGResultCode указывает успешный результат, если узел LGMemberINID выходит из логической группы, координируемой узлом LGCoordinatorID. В противном случае указывается ошибка.

6.3.8 LG-DISMISS.request

Примитив запрашивает из уровня приложений удаление логической группы. Параметры примитива:

LG-DISMISS.request {
LGRequestorID,
LGCoordinatorID
}
     

Параметры примитива приведены в таблице 5.

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

6.3.9 LG-DISMISS.indication

Примитив указывает сущности CIP удаление логической группы. Параметры примитива:

LG-DISMISS.indication {
LGRequestorID,
LGCoordinatorID
}
     

Параметры примитива приведены в таблице 5.

Примитив используется, когда уровень служб указывает сущности CIP удаление логической группы в узле LGCoordinatorID.

6.3.10

 LG-DISMISS.confirm

Примитив подтверждает сущности CIP в узле LGRequestorID удаление логической группы. Параметры примитива:

LG-DISMISS.confirm {
LGRequestorID,
LGCoordinatorID,
LGResultCode
}
     

Параметры примитива приведены в таблице 5.

Примитив сообщает о результате запроса на удаление логической группы. Параметр LGResultCode указывает успешный результат, если логическая группа, координируемая узлом LGCoordinatorID, была удалена. В противном случае указывается ошибка.

6.3.11

 LG-QUERY.request

Примитив запрашивает из уровня приложений атрибуты логической группы. Параметры примитива:

LG-QUERY.request {
LGRequestorID,
LGCoordinatorID,
LGAttributeNum,
LGAttribute
}
     

Параметры примитива приведены в таблице 5.

Примитив используется сущностью CIP в узле LGRequestorID для запроса атрибутов логической группы, которая координируется узлом LGCoordinatorID. После получения примитива узел LGCoordinatorID запрашивает число атрибутов LGAttributeNum текущей логической группы. Имена и значения атрибутов структурированы в LGAttribute.

6.3.12

 LG-QUERY.confirm

Примитив возвращает сущности CIP атрибуты логической группы. Параметры примитива:

LG-QUERY.confirm {
LGRequestorID,
LGCoordinatorID,
LGAttributeNum,
LGAttribute,
LGResultCode
}
     

Параметры примитива приведены в таблице 5.

Примитив возвращает результат запроса атрибутов логической группы, координируемой узлом LGCoordinatorID. LGResultCode указывает успешный результат, если атрибуты LGAttributeNum возвращены в параметре LGAttribute. В противном случае указывается ошибка.

6.3.13

 LG-SET.request

Примитив запрашивает установку значений определенных атрибутов логической группы. Параметры примитива:

LG-SET.request {
LGRequestorID,
LGCoordinatorID,
LGAttributeName,
LGAttributeValue
}

Параметры примитива приведены в таблице 5.

Примитив используется сущностью CIP для установки значений определенных атрибутов логической группы. При получении примитива сущность уровня служб в узле LGCoordinatorID пытается извлечь атрибут LGAttributeName. Если атрибут LGAttributeName недействителен, то генерируется ошибка. В противном случае узел LGCoordinatorID пытается установить значение атрибута LGAttributeName с помощью LGAttributeValue. Может быть применена дополнительная процедура для проверки действительности значения LGAttributeValue для атрибута LGAttributeName. Если значение недействительно, генерируется код ошибки.

6.3.14

 LG-SET.indication

Примитив указывает сущности CIP, что был получен запрос установки значения определенного атрибута логической группы. Параметры примитива:

LG-SET.indication {
LGRequestorID,
LGCoordinatorID,
LGAttributeName
}
     

Параметры примитива приведены в таблице 5.

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

6.3.15

 LG-SET.confirm

Примитив подтверждает изменение значения атрибута логической группы. Параметры примитива:

LG-SET.confirm {
LGRequestorID,
LGCoordinatorID,
LGAttributeName,
LGResultCode
}
     

Параметры примитива приведены в таблице 5.

LGResultCode указывает успешный результат, если установлено значение атрибута LGAttributeName. Если значение атрибута LGAttributeName не установлено, то указывается ошибка.

     6.4 Служба группировки данных

Служба группировки данных предоставляется через DG-SAP. DG-SAP является логическим интерфейсом между сущностью службы группировки данных на уровне служб и сущностью CIP на уровне приложений. Логический интерфейс включает в себя набор примитивов (см. таблицу 6) и их параметры (см. таблицу 7).

Таблица 6 - Примитивы DG-SAP

Таблица 7 - Параметры примитивов DG-SAP

6.4.1 DG-DGQUERY.request

Этот примитив запрашивает значение эталонного времени для группировки данных по объектам CIP на прикладном уровне.

Параметры примитива:

DG-DGQUERY.request {
DGSrcID,
DGDstID,
DGTimeRef
}
     

Параметры примитива приведены в таблице 7.

Примитив используется сущностью CIP для запроса значения эталонного времени, которое требуется для процесса группировки данных в узле DGSrcID. При получении примитива узел DGDstID получает текущее эталонное время для генерации сенсорных данных, которое возвращается с помощью DGTimeRef.

6.4.2 DG-DGQUERY.confirm

Примитив возвращает значения эталонного времени сущности CIP. Параметры примитива:

DG-DGQUERY.confirm {
DGSrcID,
DGDstID,
DGTimeRef,
DGResultCode
}

Параметры примитива приведены в таблице 7.

DGResultCode указывает успешный результат, если значение эталонного времени для генерации сенсорных данных возвращено в параметре DGTimeRef. В противном случае указывается ошибка.

6.4.3 DG-DGEXEC.request

Примитив запрашивает выполнение группировки данных. Параметры примитива:

DG-DGEXEC.request {
DGSrcID,
DGDstID,
DGExecVal
}
     

Параметры примитива приведены в таблице 7.

Примитив используется сущностью CIP в узле DGSrcID для запроса выполнения группировки данных в узле DGDstID. При получении примитива узел DGDstID выполняет процесс группировки данных с использованием DGExecVal.

6.4.4 DG-DGEXEC.indication

Примитив указывает выполнение процесса группировки данных. Параметры примитива:

DG-DGEXEC.indication {
DGSrcID,
DGDstID,
DGExecVal
}
     

Параметры примитива приведены в таблице 7.

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

6.4.5 DG-DGEXEC.confirm

Примитив подтверждает выполнение группировки данных. Параметры примитива:

DG-DGEXEC.confirm {
DGSrcID,
DGDstID,
DGResultCode
}
     

Параметры примитива приведены в таблице 7.

Примитив сообщает сущности CIP результат выполнения процесса группировки данных. DGResultCode указывает успешный результат, если эталонное время для генерации сенсорных данных в узле DGDstID успешно синхронизировано с эталонным временем в узле DGSrcID. В противном случае указывается ошибка.

     6.5 Служба регистрации данных

Служба регистрации данных предоставляется через REG-SAP. REG-SAP является логическим интерфейсом между сущностью службы регистрации данных на уровне служб и сущностью CIP на уровне приложений. Логический интерфейс включает в себя набор примитивов (см. таблицу 8) и их параметры (см. таблицу 9).

Таблица 8 - Примитивы REG-SAP

Таблица 9 - Параметры примитивов REG-SAP

6.5.1 REG-REGQUERY.request

Примитив запрашивает ссылочные атрибуты для процесса регистрации данных. Параметры примитива:

REG-REGQUERY.request {
REGSrcID,
REGDstID,
REGRef
}
     

Параметры примитива приведены в таблице 9.

Примитив используется сущностью CIP из узла REGDstID для запроса значения атрибута REGRef, которое требуется для процесса регистрации данных в узле REGSrcID.

6.5.2 REG-REGQUERY.confirm

Примитив возвращает сущности CIP результат запроса значения атрибута REGRef. Параметры примитива:

REG-REGQUERY.confirm {
REGSrcID,
REGDstID,
REGRef,
REGResultCode
}
     

Параметры примитива приведены в таблице 9.

Примитив возвращает результат запроса значения атрибута REGRef в узле REGDstID. Параметр REGResultCode указывает успешный результат, если значение атрибута REGRef возвращено в параметре REGRef. В противном случае указывается ошибка.

6.5.3 REG-REGEXEC.request

Примитив запрашивает сущностью CIP выполнение регистрации данных. Параметры примитива:

REG-REGEXEC.request {
REGSrcID,
REGDstID,
REGRefDimension,
REGExecVal
}
     

Параметры примитива приведены в таблице 9.

Примитив используется сущностью CIP в узле REGSrcID для запроса выполнения регистрации данных в узле REGDstID. При получении примитива узел REGDstID выполняет процесс регистрации данных, в котором для выполнения регистрации данных используется REGExecVal. Размерность REGExecVal указывается с помощью REGRefDimension.

6.5.4 REG-REGEXEC.indication

Примитив указывает выполнение процесса регистрации данных. Параметры примитива:

REG-REGEXEC.indication {
REGSrcID,
REGDstID
}
     

Параметры примитива приведены в таблице 9.

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

6.5.5 REG-REGEXEC.confirm

Примитив подтверждает выполнение регистрации данных. Параметры примитива:

REG-REGEXEC.confirm {
REGSrcID,
REGDstID,
REGResultCode
}
     

Параметры примитива приведены в таблице 9.

Примитив сообщает сущности CIP результат выполнения процесса регистрации данных. REGResultCode указывает успешный результат, если процесс регистрации данных выполнен в узле REGDstID. В противном случае указывается ошибка.

     6.6 Служба описания информации

Служба описания информации предоставляется через INFO-SAP. INFO-SAP является логическим интерфейсом между сущностью службы описания информации на уровне служб и сущностью CIP на уровне приложений. Логический интерфейс включает в себя набор примитивов (см. таблицу 10) и их параметры (см. таблицу 11).

Таблица 10 - Примитивы INFO-SAP

Таблица 11 - Параметры примитивов INFO-SAP

6.6.1 INFO-LEVELGET.request

Примитив запрашивает уровни описания информации. Параметры примитива:

INFO-LEVELGET.request {
InfoSrcID,
InfoDstID,
LevelVal
}
     

Параметры примитива приведены в таблице 11.

Примитив используется сущностью CIP для запроса уровня описания информации узла InfoDstID, который требуется узлу InfoSrcID. При получении примитива узел InfoDstID получает текущий уровень описания информации.

6.6.2 INFO-LEVELGET.confirm

Примитив возвращает уровень описания информации сущности CIP. Параметры примитива:

INFO-LEVELGET.confirm {
InfoSrcID,
InfoDstID,
LevelVal,
InfoResultCode
}
     

Параметры примитива приведены в таблице 11.

Примитив возвращает узлу InfoSrcID результат запроса уровня описания информации. Параметр InfoResultCode указывает успешный результат, если уровень описания информации узла InfoDstID возвращен в параметре LevelVal. В противном случае указывается ошибка.

6.6.3 INFO-LEVELSET.request

Примитив устанавливает уровень описания информации. Параметры примитива:

INFO-LEVELSET.request {
InfoSrcID,
InfoDstID,
LevelVal
}
     

Параметры примитива приведены в таблице 11.

Примитив используется сущностью CIP в узле InfoSrcID для установки уровня описания информации узла InfoDstID в LevelVal. При получении примитива узел InfoDstID устанавливает уровень описания информации. Уровни описания информации соответствуют этапам обработки информации. Различные уровни имеют разные типы, структуры и объем информации. После установки уровня описания информации могут применяться соответствующие процедуры или алгоритмы обработки информации. Узел может одновременно поддерживать более одного уровня описания информации.

6.6.4 INFO-LEVELSET.indication

Примитив указывает установку уровней описания информации. Параметры примитива:

INFO-LEVELSET.indication {
InfoSrcID,
InfoDstID,
LevelVal
}
     

Параметры примитива приведены в таблице 11.

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

6.6.5 INFO-LEVELSET.confirm

Примитив подтверждает установку уровней описания информации. Параметры примитива:

INFO-LEVELSET.confirm {
InfoSrcID,
InfoDstID,
LevelVal,
InfoResultCode
}
     

Параметры примитива приведены в таблице 11.

Примитив сообщает сущности CIP результат установки уровней описания информации. InfoResultCode указывает успешный результат, если уровень описания информации в узле InfoDstID успешно установлен на LevelVal. В противном случае указывается ошибка.

6.6.6 INFO-DATA.request

Примитив запрашивает передачу информации о конкретных уровнях описания информации. Параметры примитива:

INFO-DATA.request {
InfoSrcID,
InfoDstID,
LevelVal,
InfoDataDimension,
InfoData
}
     

Параметры примитива приведены в таблице 11.

Примитив используется сущностью CIP в узле InfoSrcID для запроса передачи информации определенного уровня описания информации узла InfoDstID. При получении примитива уровень служб отправляет InfoData на уровне описания информации LevelVal равноправной сущности уровня служб в узле InfoDstID. InfoDataDimension указывает измерение InfoData.

6.6.7 INFO-DATA.indication

Примитив указывает сущности CIP, что блок данных с определенным уровнем описания информации был принят. Параметры примитива:

INFO-DATA.indication {
InfoSrcID,
InfoDstID,
LevelVal,
InfoDataDimension,
InfoData
}
     

Параметры примитива приведены в таблице 11.

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

6.6.8 INFO-DATA.confirm

Примитив подтверждает передачу блока данных определенного уровня описания информации. Параметры примитива:

INFO-DATA.confirm {
InfoSrcID,
InfoDstID,
LevelVal,
InfoResultCode
}
     

Параметры примитива приведены в таблице 11.

Примитив сообщает сущности CIP результат передачи блока данных уровня описания информации LevelVal. InfoResultCode указывает успешный результат, если блок данных уровня описания информации LevelVal передан из узла InfoSrcID в узел InfoDstID. В противном случае указывается ошибка.

     6.7 Служба межузловой активации

Служба межузловой активации обеспечивается через N2NACT-SAP. N2NACT-SAP является логическим интерфейсом между сущностью службы межузловой активации на уровне служб и сущностью CIP на уровне приложений. Логический интерфейс включает в себя набор примитивов (см. таблицу 12) и их параметры (см. таблицу 13).

Таблица 12 - Примитивы N2NACT-SAP

Таблица 13 - Параметры примитивов N2NACT-SAP

6.7.1 N2NACT.request

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

N2NACT.request {
N2NSrcID,
N2NDstID,
N2NACTMode,
N2NACTDataAttributeNum,
N2NACTDataAttribute
}
     

Параметры примитива приведены в таблице 13.

Примитив используется сущностью CIP от узла N2NSrcID для запроса активации в узле N2NDstID. При получении примитива сущность уровня службы в узле N2NSrcID отправляет запрос на активацию одноранговой сущности уровня службы в узле N2NDstID. Если узел N2NDstID успешно принимает запрос, процесс активации выполняется в режиме N2NACTMode. Могут поддерживаться различные режимы. Данные контекста для процесса активации задаются N2NACTDataAttribute. N2NACTDataAttributeNum указывает номер атрибута в N2NACTDataAttribute.

6.7.2 N2NACT.confirm

Примитив подтверждает результат процесса межузловой активации. Параметры примитива:

N2NACT.confirm {
N2NSrcID,
N2NDstID,
N2NACTMode,
N2NResultCode
}
     

Параметры примитива приведены в таблице 13.

Примитив сообщает сущности CIP в узле N2NSrcID результат процесса межузловой активации. N2NResultCode указывает успешный результат, если узел N2NDstID успешно активирован узлом N2NSrcID в режиме N2NACTMode. В противном случае указывается ошибка.

     6.8 Служба адаптации параметров

Служба адаптации параметров предоставляется через PAR-SAP. PAR-SAP является логическим интерфейсом между сущностью службы адаптации параметров на уровне служб и сущностью CIP на уровне приложений. Логический интерфейс включает в себя набор примитивов (см. таблицу 14) и их параметры (см. таблицу 15).

Таблица 14 - Примитивы PAR-SAP

Таблица 15 - Параметры примитивов PAR-SAP

6.8.1 PAR.request

Примитив запрашивает процесс адаптации параметров. Параметры примитива:

PAR.request {
PARSrcID,
PARDstID,
PARParameterName,
PARParameterLength,
PARParameter
}
     

Параметры примитива приведены в таблице 15.

Примитив используется сущностью CIP в узле PARSrcID для запроса адаптации параметра в узле PARDstID. При получении примитива сущность уровня служб в узле PARDstID пытается получить свой локальный параметр с именем PARParameterName. Если узел успешно находит параметр PARParameterName, значение этого параметра обновляется параметром PARParameter. PARParameterLength указывает длину PARParameter. В противном случае генерируется код ошибки.

6.8.2 PAR.indication

Примитив указывает сущности CIP, что был получен запрос адаптации параметров. Параметры примитива:

PAR.indication {
PARSrcID,
PARDstID,
PARParameterName,
}
     

Параметры примитива приведены в таблице 15.

Примитив используется, когда уровень служб указывает сущности CIP процесс адаптации параметров в узле PARDstID.

6.8.3 PAR.confirm

Примитив подтверждает результат адаптации параметра. Параметры примитива:

PAR.confirm {
PARSrcID,
PARDstID,
PARParameterName,
PARResultCode
}
     

Параметры примитива приведены в таблице 15.

Примитив сообщает сущности CIP в узле PARSrcID результат процесса адаптации параметров. PARResultCode указывает успешный результат, если параметр PARParameterName в узле PARDstID обновлен. В противном случае указывается ошибка.

     7 Расширенные службы и интерфейсы
     

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

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

Таблица 16 - Названия точек доступа к службе (SAP)

     7.2 Служба управления QoS

Служба управления QoS предоставляет механизмы определения, обновления и применения профилей QoS. Служба управления QoS использует службу логической группировки и службу адаптации параметров (рисунок 5).

     

Рисунок 5 - Служба управления QoS и другие службы

Служба управления QoS предоставляется через QoS-SAP. QoS-SAP является логическим интерфейсом между сущностью службы управления QoS на уровне служб и сущностью CIP на уровне приложений. Логический интерфейс включает в себя набор примитивов (см. таблицу 17) и их параметры (см. таблицу 18).

Таблица 17 - Примитивы QoS-SAP

Таблица 18 – Параметры примитивов QoS-SAP

7.2.1 QoS-PROFILE-ESTABLISH.request

Примитив запрашивает установление профиля QoS для управления QoS. Параметры примитива:

QoS-PROFILE-ESTABLISH.request {
QoSRequestorID,
QoSProfileManagerID,
QoSProfileID
}
     

Параметры примитива приведены в таблице 18.

Примитив используется сущностью CIP в узле QoSRequestorID для запроса установления профиля QoS в узле QoSProfileManagerID. При получении примитива узел QoSProfileManagerID сначала проверяет, поддерживается ли служба управления QoS самим узлом. Если поддерживается, создается новый профиль QoS. Новый профиль QoS будет идентифицирован с помощью QoSProfileID.

7.2.2 QoS-PROFILE-ESTABLISH.indication

Примитив указывает на создание профиля QoS. Параметры примитива:

QoS-PROFILE-ESTABLISH.indication {
QoSRequestorID,
QoSProfileManagerID,
QoSProfileID
}
     

Параметры примитива приведены в таблице 18.

Примитив используется службой управления QoS для указания сущности CIP установления профиля QoS в узле QoSProfileManagerID.

7.2.3 QoS-PROFILE-ESTABLISH.confirm

Примитив подтверждает установление нового профиля QoS. Параметры примитива:

QoS-PROFILE-ESTABLISH.confirm {
QoSRequestorID,
QoSProfileManagerID,
QoSProfileID,
QoSResultCode
}
     

Параметры примитива приведены в таблице 18.

Примитив сообщает результат запроса на установление профиля QoS. QoSResultCode указывает успешный результат, если новый профиль QoS, идентифицируемый QoSProfileID в узле QoSProfileManagerID, успешно установлен. В противном случае указывается ошибка.

7.2.4 QoS-PROFILE-UPDATE.request

Примитив запрашивает обновление профиля QoS для управления QoS. Параметры примитива:

QoS-PROFILE-UPDATE.request {
QoSRequestorID,
QoSProfileManagerID,
QoSProfileID,
QoSProfileUpdateMode,
QoSProfileLGlist,
QoSProfilePARlist
}

Параметры примитива приведены в таблице 18.

Примитив используется сущностью CIP в узле QoSRequestorID для запроса обновления профиля QoS с идентификатором QoSProfileID в узле QoSProfileManagerID. Режим обновления определяется QoSProfileUpdateMode.

7.2.5 QoS-PROFILE-UPDATE.confirm

Примитив подтверждает результат обновления профиля QoS. Параметры примитива:

QoS-PROFILE-UPDATE.confirm {
QoSRequestorID,
QoSProfileManagerID,
QoSProfileID,
QoSProfileUpdateMode,
QoSResultCode
}
     

Параметры примитива приведены в таблице 18.

Примитив используется службой управления QoS для подтверждения результата обновления профиля QoS с идентификатором QoSProfileID и режимом QoSProfileUpdateMode в узле QoSProfileManagerID. QoSResultCode указывает успешный результат, если выполнено обновление профиля. В противном случае указывается ошибка.

7.2.6 QoS-PROFILE-APPLY.request

Примитив запрашивает применение профиля QoS для управления QoS. Параметры примитива:

QoS-PROFILE-APPLY.request {
QoSRequestorID,
QoSProfileManagerID,
QoSProfileID
}
     

Параметры примитива приведены в таблице 18.

Примитив используется сущностью CIP в узле QoSRequestorID, чтобы запросить применение профиля QoS с идентификатором QoSProfileID. Когда применяется профиль QoS, QoSProfileManagerID запускает серию процессов, используя службу логической группировки и службу адаптации параметров. Все логические группы, определенные QoSProfileLGlist, обновляют параметры со значениями, указанными QoSProfilePARlist.

7.2.7 QoS-PROFILE-APPLY.confirm

Примитив подтверждает результат применения профиля QoS. Параметры примитива:

QoS-PROFILE-APPLY.confirm {
QoSRequestorID,
QoSProfileManagerID,
QoSProfileID,
QoSResultCode
}
     

Параметры примитива приведены в таблице 18.

Примитив используется службой управления QoS для подтверждения результата применения профиля QoS с идентификатором QoSProfileID в узле QoSProfileManagerID. Параметр QoSResultCode указывает на успешный результат, если профиль применен успешно. В противном случае указывается ошибка.

7.2.8 QoS-PROFILE-DELETE.request

Примитив запрашивает удаление профиля QoS для управления QoS. Параметры примитива:

QoS-PROFILE-DELETE.request {
QoSRequestorID,
QoSProfileManagerID,
QoSProfileID
}
     

Параметры примитива приведены в таблице 18.

Примитив используется сущностью CIP в узле QoSRequestorID для запроса удаления профиля QoS в узле QoSProfileManagerID. При получении примитива узел QoSProfileManagerID сначала пытается найти запись профиля QoS с идентификатором QoSProfileID. Если профиль QoSProfileID найден успешно, запись профиля QoS удаляется.

7.2.9 QoS-PROFILE-DELETE.indication

Примитив указывает удаление профиля QoS. Параметры примитива:

QoS-PROFILE-DELETE.indication {
QoSRequestorID,
QoSProfileManagerID,
QoSProfileID
}
     

Параметры примитива приведены в таблице 18.

Примитив используется службой управления QoS для указания сущности CIP удаления профиля QoS в узле QoSProfileManagerID.

7.2.10 QoS-PROFILE-DELETE.confirm

Примитив подтверждает удаление профиля QoS. Параметры примитива:

QoS-PROFILE-DELETE.confirm {
QoSRequestorID,
QoSProfileManagerID,
QoSProfileID,
QoSResultCode
}
     

Параметры примитива приведены в таблице 18.

Примитив сообщает о результате запроса на удаление профиля QoS. Параметр QoSResultCode указывает на успешный результат, если профиль QoS с идентификатором QoSProfileID в узле QoSProfileManagerID удален. В противном случае указывается ошибка.

     7.3 Служба планирования на основе CIP

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

     

Рисунок 6 - Служба планирования на основе CIP и другие службы

Служба планирования на основе CIP предоставляется через SCHEDULING-SAP. SCHEDULING-SAP - это логический интерфейс между службой планирования на основе CIP на уровне служб и сущностью CIP на уровне приложений. Логический интерфейс включает в себя набор примитивов (см. таблицу 19) и их параметры (см. таблицу 20).

Таблица 19 - Примитивы SCHEDULING-SAP

Таблица 20 - Параметры примитивов SCHEDULING-SAP

7.3.1 SCHEDULING-SCHEME-ESTABLISH.request

Примитив запрашивает установление схемы для службы планирования на основе CIP. Параметры примитива:

SCHEDULING-SCHEME-ESTABLISH.request {
SCHEDULINGRequestorID,
SCHEDULINGSchemeManagerID,
SCHEDULINGSchemeID
}

Параметры примитива приведены в таблице 20.

Примитив используется сущностью CIP в узле SCHEDULINGRequestorID для запроса установления схемы в узле SCHEDULINGSchemeManagerID. При получении примитива узел SCHEDULINGSchemeManagerID сначала проверяет, поддерживается ли служба планирования на основе CIP самим узлом. Если поддерживается, то создается запись новой схемы планирования с идентификатором SCHEDULINGSchemeID.

7.3.2 SCHEDULING-SCHEME-ESTABLISH.indication

Примитив указывает на создание схемы для службы планирования на основе CIP. Параметры примитива:

SCHEDULING-SCHEME-ESTABLISH.indication {
SCHEDULINGRequestorID,
SCHEDULINGSchemeManagerID,
SCHEDULINGSchemeID
}
     

Параметры примитива приведены в таблице 20.

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

7.3.3 SCHEDULING-SCHEME-ESTABLISH.confirm

Примитив подтверждает создание схемы для службы планирования на основе CIP. Параметры примитива:

SCHEDULING_SCHEME-ESTABLISH.confirm {
SCHEDULINGRequestorID,
SCHEDULINGSchemeManagerID,
SCHEDULINGSchemeID,
SCHEDULINGResultCode
}
     

Параметры примитива приведены в таблице 20.

Примитив сообщает результат запроса на установление схемы. Параметр SCHEDULINGResultCode указывает успешный результат, если в узле SCHEDULINGSchemeManagerID установлена схема с идентификатором SCHEDULINGSchemeID. В противном случае указывается ошибка.

7.3.4 SCHEDULING-SCHEME-UPDATE.request

Примитив запрашивает обновление схемы для службы планирования на основе CIP. Параметры примитива:

SCHEDULING-SCHEME-UPDATE.request {
SCHEDULINGRequestorID,
SCHEDULINGSchemeManagerID,
SCHEDULINGSchemeID,
SCHEDULINGMode,
SchemeEVSubNodelist,
SchemeEVSubTypelist,
SchemePARlist
}
     

Параметры примитива приведены в таблице 20.

Примитив используется сущностью CIP в узле SCHEDULINGRequestorID для запроса на обновление схемы с идентификатором SCHEDULINGSchemeID в узле SCHEDULINGSchemeManagerID. При получении примитива узлу SCHEDULINGSchemeManagerID предлагается обновить схему с идентификатором SCHEDULINGSchemeID. SCHEDULINGMode определяет режим планирования на основе CIP. SchemeEVSubNodelist, SchemeEVSubTypelist и SchemePARlist определяют список узлов подписки на события, список типов событий и список параметров в схеме.

7.3.5 SCHEDULING-SCHEME-UPDATE.confirm

Примитив подтверждает результат обновления схемы. Параметры примитива:

SCHEDULING-SCHEME-UPDATE.confirm {
SCHEDULINGRequestorID,
SCHEDULINGSchemeManagerID,
SCHEDULINGSchemeID,
SCHEDULINGResultCode
}
     

Параметры примитива приведены в таблице 20.

Примитив используется службой планирования на основе CIP, чтобы подтвердить результат обновления схемы с идентификатором SCHEDULINGSchemeID в узле SCHEDULINGSchemeManagerID. При получении примитива узел SCHEDULINGRequestorID получает подтверждение результата обновления схемы SCHEDULINGSchemeID в узле SCHEDULINGSchemeManagerID. Параметр SCHEDULINGResultCode указывает успешный результат, если схема успешно обновлена. В противном случае указывается ошибка.

7.3.6 SCHEDULING-SCHEME-APPLY.request

Примитив запрашивает применение схемы для службы планирования на основе CIP. Параметры примитива:

SCHEDULING-SCHEME-APPLY.request {
SCHEDULINGRequestorID,
SCHEDULINGSchemeManagerID,
SCHEDULINGSchemeID
}
     

Параметры примитива приведены в таблице 20.

Примитив используется сущностью CIP в узле SCHEDULINGRequestorID для запроса применения схемы с идентификатором SCHEDULINGSchemeID. После получения примитива узел SCHEDULINGSchemeManagerID должен применить схему с идентификатором SCHEDULINGSchemeID. Когда применяется схема планирования, SCHEDULINGSchemeManagerID запускает серию процессов с использованием службы событий, службы логического группирования, службы адаптации параметров, службы межузловой активации, а также других общих служб, включая службу поиска соседей. События, указанные в службе событий, могут быть заменены службой поиска соседей. Логическая группировка выполняется на основе отношений соседей. В соответствии с другим режимом планирования выполняется процесс межузловой активации с определенным режимом взаимной активации, за которым следует процесс адаптации параметров через службу адаптации параметров.

7.3.7 SCHEDULING-SCHEME-APPLY.confirm

Примитив подтверждает результат применения схемы планирования. Параметры примитива:

SCHEDULING-SCHEME-APPLY.confirm {
SCHEDULINGRequestorID,
SCHEDULINGSchemeManagerID,
SCHEDULINGSchemeID,
SCHEDULINGResultCode
}
     

Параметры примитива приведены в таблице 20.

Примитив используется службой планирования на основе CIP, чтобы подтвердить результат применения схемы с идентификатором SCHEDULINGSchemeID в узле SCHEDULINGSchemeManagerID. После получения примитива узел SCHEDULINGRequestorID получает подтверждение результата применения схемы SCHEDULINGSchemeID. Параметр SCHEDULINGResultCode указывает успешный результат, если схема применяется успешно. В противном случае указывается ошибка.

7.3.8 SCHEDULING-SCHEME-DELETE.request

Примитив запрашивает удаление схемы для службы планирования на основе CIP. Параметры примитива:

SCHEDULING-SCHEME-DELETE.request {
SCHEDULINGRequestorID,
SCHEDULINGSchemeManagerID,
SCHEDULINGSchemeID
}
     

Параметры примитива приведены в таблице 20.

Примитив используется сущностью CIP в узле SCHEDULINGRequestorID для запроса удаления схемы в узле SCHEDULINGSchemeManagerID. При получении примитива узел SCHEDULINGSchemeManagerID пытается найти схему с идентификатором SCHEDULINGSchemeID. Если схема SCHEDULINGSchemeID найдена успешно, то она удаляется.

7.3.9 SCHEDULING-SCHEME-DELETE.indication

Примитив указывает на удаление схемы планирования. Параметры примитива:

SCHEDULING-SCHEME-DELETE.indication {
SCHEDULINGRequestorID,
SCHEDULINGSchemeManagerID,
SCHEDULINGSchemeID
}
     

Параметры примитива приведены в таблице 20.

Примитив используется службой планирования на основе CIP для указания сущности CIP удаления схемы в узле SCHEDULINGSchemeManagerID.

7.3.10 SCHEDULING-SCHEME-DELETE.confirm

Примитив подтверждает удаление схемы. Параметры примитива:

SCHEDULING-SCHEME-DELETE.confirm {

SCHEDULINGRequestorID,

SCHEDULINGSchemeManagerID,

SCHEDULINGSchemeID,

SCHEDULINGResultCode

}

Параметры примитива приведены в таблице 20.

Примитив сообщает результат запроса на удаление схемы планирования. Параметр SCHEDULINGResultCode указывает успешный результат, если схема с идентификатором SCHEDULINGSchemeID в узле SCHEDULINGSchemeManagerID удалена. В противном случае указывается ошибка.

     7.4 Служба адаптивного восприятия

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

Рисунок 7 - Служба адаптивного восприятия и другие службы

Служба адаптивного восприятия предоставляется через ADSENSING-SAP. ADSENSING-SAP является логическим интерфейсом между сущностью службы адаптивного восприятия на уровне служб и сущностью CIP на уровне приложений. Логический интерфейс включает в себя набор примитивов (см. таблицу 21) и их параметры (см. таблицу 22).

Таблица 21 - Примитивы ADSENSING-SAP

Таблица 22 - Параметры примитивов ADSENSING-SAP

7.4.1 ADSENSING-APPLY.request

Примитив запрашивает применение механизма адаптивного восприятия. Параметры примитива:

ADSENSING-APPLY.request {
ADSENSINGRequestorID,
ADSENSINGTargetID,
ADSENSINGTargetSensorID,
ADSENSINGEVNodeList,
ADSENSINGEVTypeList,
ADSENSINGSensorPARlist
}
     

Параметры примитива приведены в таблице 22.

Примитив используется сущностью CIP в узле ADSENSINGRequestorID для запроса применения адаптивного механизма восприятия в узле ADSENSINGTargetID. При получении примитива узел ADSENSINGTargetID сначала проверяет, поддерживается ли служба адаптивного восприятия самим узлом. Если поддерживается, конфигурация датчика с идентификатором ADSENSINGTargetSensorID в узле ADSENSINGTargetID, связывается с событиями, определенными ADSENSINGEVNodeList и ADSENSINGEVTypeList. ADSENSINGSensorPARlist предоставляет параметры для конфигурации датчика.

7.4.2 ADSENSING-APPLY.confirm

Примитив подтверждает результат запроса применения механизма адаптивного восприятия. Параметры примитива:

ADSENSING-APPLY.confirm {
ADSENSINGRequestorID,
ADSENSINGTargetID,
ADSENSINGTargetSensorID,
ADSENSINGResultCode
}
     

Параметры примитива приведены в таблице 22.

Примитив используется службой адаптивного восприятия для подтверждения результата применения механизма адаптивного восприятия в узле ADSENSINGTargetID. При получении примитива узел ADSENSINGRequestorID получает подтверждение результата применения адаптивного восприятия к датчику ADSENSINGTargetSensorID. Параметр ADSENSINGResultCode указывает успешный результат, если механизм применен. В противном случае указывается ошибка.

7.4.3 ADSENSING-CANCEL.request

Примитив запрашивает отмену механизма адаптивного восприятия. Параметры примитива:

ADSENSING-CANCEL.request {
ADSENSINGRequestorID,
ADSENSINGTargetID,
ADSENSINGTargetSensorID
}
     

Параметры примитива приведены в таблице 22.

Примитив используется сущностью CIP в узле ADSENSINGRequestorID для запроса отмены механизма адаптивного восприятия в узле ADSENSINGTargetID. При получении примитива все события, связанные с датчиком ADSENSINGTargetSensorID в узле ADSENSINGTargetID, становятся не связанными с датчиком.

7.4.4 ADSENSING-CANCEL.confirm

Примитив подтверждает результат запроса отмены механизма адаптивного восприятия. Параметры примитива:

ADSENSING-CANCEL.confirm {
ADSENSINGRequestorID,
ADSENSINGTargetID,
ADSENSINGTargetSensorID,
ADSENSINGResultCode
}
     

Параметры примитива приведены в таблице 22.

Примитив используется службой адаптивного восприятия для подтверждения результата отмены механизма адаптивного восприятия в узле ADSENSINGTargetID. При получении примитива узел ADSENSINGRequestorID получает подтверждение результата отмены адаптивного восприятия для датчика ADSENSINGTargetSensorID. Параметр ADSENSINGResultCode указывает успешный результат, если механизм отменен. В противном случае указывается ошибка.

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

Пример основных служб и интерфейсов

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

Обнаружение и распознавание целей являются очень важными технологиями обработки информации для системы защиты от вторжений. Могут быть использованы разные виды датчиков. Как показано на рисунке A.1, по периметру развернуты три различных типа сенсорных узлов: тип C, тип D и тип E. Когда любой из этих сенсорных узлов обнаружит цель, сообщение о событии будет сгенерировано и отправлено в головной узел кластера (узел A). Чтобы распознать цель, узел A может запрашивать данные или информацию от сенсорных узлов, развернутых по периметру. Уровни описания информации от сенсорных узлов отличаются друг от друга. По результатам распознавания цели узел В видеокамеры может быть активирован узлом A для получения подтверждения посредством сбора изображения.

Рисунок А.1 - Обнаружение и распознавание целей на основе основных служб, поддерживающих CIP

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

Рисунок А.2 - Рабочий поток на базе основных служб

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

Пример расширенных служб и интерфейсов

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

Отслеживание целей является еще одной важной технологией обработки информации в системе защиты от вторжений. Как показано на рисунке B.1, когда длина периметра очень велика, для получения полного схода по периметру могут быть использованы сотни датчиков. Для повышения производительности системы может быть развернут второй виртуальный периметр. На рисунке B.1 есть три логические группы, которые координируются соответственно узлом A, узлом B и узлом F. Командный и управляющий узел (узел G) работает в качестве координатора узла A, узла B и узла F.

Рисунок B.1 - Отслеживание целей на основе расширенных служб, поддерживающих CIP

Для реализации отслеживания целей используются расширенные службы, поддерживающие CIP, включая службу управления QoS и службу планирования на основе CIP. На рисунке B.2 показан рабочий поток использования расширенных сервисов для поддержки отслеживания целей в системе защиты от вторжений.

Рисунок B.2 - Рабочий поток на базе расширенных служб

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

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

Таблица ДА.1

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