ПНСТ 462-2020 Интеллектуальные транспортные системы. Выделенная радиосвязь ближнего действия (DSRC). Прикладной уровень

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

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

Интеллектуальные транспортные системы

ВЫДЕЛЕННАЯ РАДИОСВЯЗЬ БЛИЖНЕГО ДЕЙСТВИЯ (DSRC)

Прикладной уровень

(ISO 15628:2013, NEQ)

Издание официальное

Москва Стаида ртмнформ 2020

Предисловие

• 1 РАЗРАБОТАН Московским автомобильно-дорожным государственным техническим университетом (МАДИ)

• 2 ВНЕСЕН Техническим комитетом по стандартизации ТК 57 «Интеллектуальные транспортные системы»

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

• 4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта ИС0 15628:2013 «Интеллектуальные транспортные системы. Выделенная радиосвязь ближнего действия (DSRC). Прикладной уровень» (ISO 15628:2013 «Intelligent transport systems — Dedicated short range communication (DSRC) — DSRC application layer», NEC)

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

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и пред-ложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 125319 Москва. Ленинградский проспект. 64 и/или в Федеральное агентство по техническому регулированию и метрологии по адресу: 123112 Москва. Пресненская набережная, д. 10. стр. 2.

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

© Стзндартинформ. оформление. 2020

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

Содержание

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

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

• 3 Сокращения

• 4 Структура ядра прикладного уровня

• 5 Ядро передачи

• 6 Ядро инициализации

• 7 Ядро широковещания

• 8 Расширенные определения для различных служб нижнего уровня и интерфейсов приложений

Приложение А (обязательное) Структуры данных

Приложение Б (обязательное) Наименование и регистрация

Приложение В (справочное) Примеры кодирования

Приложение Г (обязательное) Декларация поддерживаемых функций прикладного уровня

Приложение Д (справочное) Сервисы нижнего уровня

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

Введение

Требования к системе связи многих приложений интеллектуальных транспортных систем (ИТС-приложений) могут быть удовлетворены путем использования выделенной связи ближнего действия (DSRC). Международные стандарты, касающиеся DSRC. регламентируют возможности соответствующих систем коммуникации обслуживать разнообразные ИТС-приложения параллельно.

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

Данный стандарт описывает архитектуру и сервисы, предлагаемые прикладным уровнем DSRC.

Рисунок 1 — Стек протоколов DSRC

ПНСТ 462—2020

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

Интеллектуальные транспортные системы ВЫДЕЛЕННАЯ РАДИОСВЯЗЬ БЛИЖНЕГО ДЕЙСТВИЯ (DSRC) Прикладной уровень

Intelligent transport systems. Dedicated short range communication (DSRC). Application layer

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

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

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

В наименовании стандарта указан «прикладной уровень», однако он не охватывает функциональность всех семи уровней модели OSI. но включает в себя функционалы нижних слоев. Настоящий стандарт рассматривает сервисы канального уровня DSRC и функциональность промежуточных уровней в соответствии с [1]. На рисунке 2 показана схема информационных потоков между различными элементами стека протоколов DSRC (физический уровень, канальный уровень, прикладной уровень) и приложениями.

Данный стандарт включает в себя следующее:

• - структуру и область действия прикладного уровня;

• - сервисы для передачи данных и удаленных операций;

• - процедуру мультиплексирования приложений;

. процедуру фрагментации:

• * процедуру конкатенации и связывания;

• - общие правила кодирования при трансляции данных, представленных в абстрактной синтаксической нотации версии один [2]. в формат данных для передачи [3] и наоборот;

• - инициализацию и выполнение коммуникационных процедур;

• - поддержку сервиса широковещания;

. поддержку функций управления DSRC. включая управление коммуникационным профилем;

• * расширения для различных сервисов нижнего уровня и сервисов приложений.

Издание официальное

Рисунок 2 — Архитектура и потоки информации между различными элементами стека протоколов DSRC и приложениями

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

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

• 2.1 приложение: Пользователь сервисов, предлагаемых коммуникационным стеком DSRC.

• 2.2 атрибут: Величина, которая может иметь структуру, состоящую из набора или последовательности элементов данных.

• 2.3 идентификатор атрибута: Идентификатор, который однозначно определяет атрибут в множестве других атрибутов.

• 2.4 таблица обслуживания маяка: Структура данных, передаваемых RSU с указанием доступных сервисов.

• 2.5 пул данных широковещания: Структура данных, передаваемая RSU для OBU в режиме широковещания.

• 2.6 связывание: Функция, выполняемая ядром передачи для связывания примитивов сервиса.

• 2.7 конкатенация: Функция, выполняемая ядром передачи, для группирования множества фрагментов T-APDU в один блок, обрабатываемый сервисом канального уровня.

Примечание — Обратная функция называется разделение или деконкатенация.

2.6 элемент: Связный набор данных и функциональности.

• 2.9 идентификатор элемента: Идентификатор, который однозначно определяет элемент среди других элементов в том же самом OBU.

• 2.10 фрагментация: Функция, выполняемая ядром передачи, для позиционирования одного ASDU на множестве LSDU.

• 2.11 упорядочивание очереди: Дисциплина упорядочивания (иногда называемая формирование очереди с жестким или фиксированным приоритетом), где очереди обслуживаются в приоритетном порядке.

Примечание — Очередь с низким приоритетом обслуживается только после того, как see очереди с высоким приоритетом будут обслужены. Дисциплина обслуживания внутри группы пользователей с одинаковым приоритетом; «Первым пришел, первым обслужен*. Каждый новый пользователь встает впереди всех пользователей с более низким приоритетом, но позади всех пользователей с одинаковым или более высоким приоритетом.

• 2.12 управление: Определение и распределение значения параметров связи при управлении стеком протоколов DSRC.

• 2.13 мультиплексирование: Функция ядра передачи, обеспечивающая поддержку более одного приложения, запущенного водном OBU.

• 2.14 операция: Абстрактное представление поведения, формируемого некоторой сущностью.

• 2.15 профиль: Информация, касающаяся возможностей и настроек различных уровней DSRC.

• 2.16 одиночный T-APDU фрагмент: T-APDU. который содержит полный PDU.

• 2.17 T-APDU фрагмент: Заголовок фрагмента, за которым следуют часть или все коды данных, закодированные в соответствии с ASN.1. типа T-APDU.

• 2.18 время: Количество секунд, прошедших с 1 января 1970 года (00:00) UTC.

• 2.19 таблица сервисов транспортного средства: Структура данных, передаваемая OBU и по* казывающая доступные сервисы.

• 3 Сокращения

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

ADU — блок данных приложения:

AID — идентификатор приложения;

APDU — блок данных протокола приложения;

ARIB — Ассоциация радиопромышленности и бизнеса:

ASDU — блок данных сервиса приложения;

ASN.1 — абстрактная синтаксическая нотация версии один (см. [2]);

ASTM — Американское общество по испытанию материалов;

B-Kemel — ядро широковещания:

BST— таблица сервисов маяка;

CEN — Европейский комитет по стандартизации:

EID — идентификатор элемента;

EVENT«RT — сообщение-отчет;

FCS — последовательность проверки фрейма:

ID — идентификатор;

IEEE — Институт инженеров электротехники и электроники;

IID — идентификатор вызывающего элемента;

ЬКете! — ядро инициализации;

LID — идентификатор управления логической связью;

LLC — управление логической связью:

LPDU — блок данных протокола управления логической связью;

LSDU — блок данных сервиса управления логической связью;

L1 — уровень 1 DSRC (физический уровень);

L2 — уровень 2 DSRC (канальный уровень);

L7 — ядро прикладного уровня 2 DSRC;

МАС — управление доступом к среде:

NEN — Институт стандартизации Нидерландов;

OBU — бортовое устройство.

Примечание — Данное оборудование устанавливается на борту транспортного средства;

PDU — блок данных протокола;

PPDU — блок данных протокола физического уровня;

PSDU — блок данных сервиса физического уроеня;

PER — правила кодирования пакетированных данных (см. (3]);

RSU — устройство придорожной инфраструктуры.

Примечание — Данный термин часто относится к маякам:

RTTT — телематика автомобильного транспорта и систем управления транспортными потоками:

SDU — блок данных сервиса;

T-APDU — блок данных протокола передачи прикладного уровня:

T-Kemel — ядро передачи:

UTC — всемирное время;

VST — таблица сервисов транспортного средства.

• 4 Структура ядра прикладного уровня

Ядро прикладного уровня должно включать ядро протокола передачи (T-Kernel) и либо ядро инициализации (l-Kemel). либо ядро широковещания (B-Kemel). либо и то и другое. На рисунке 3 показаны ядра прикладного уровня и их взаимодействия с внешними субъектами.

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

oeu

Прмлйжнмя

•Hi и.........у if

ми

Рисунок 3 — Структура и взаимодействие ядра прикладного уровня с внешними приложениями

• 5 Ядро передачи

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

Ядро передачи должно передавать информацию между двумя одноранговыми ядрами или приложениями. при этом оно должно абстрагироваться от способа реализации передачи.

Ядро T-Kemel должно предлагать свои сервисы посредством примитивов, которые описаны в 5.2.2.

Ядро T-Kernei должно передавать информацию, используя блоки данных T-APDU. описанные в приложении А.

Ядро T-Kernel должно передавать информацию, используя протокол, характеристики которого описаны в 5.2.5.

Ядро T-Kemel должно использовать сервисы управления логической связью подуровня канального уровня DSRC. который описан в разделе 8 и приложении Г.

Примечание — Характеристики протокола, описанные 5.2.5. не гарантируют, что элементы сервиса с одинаковыми приоритетами будут доставляться в принимающее приложение в том же порядке, в каком они передаются ядру T-Kernel на передающей стороне.

• 5.2 Сервисы

  • 5.2.1 Общие положения

Ядро T-Kemel должно обеспечить следующие сервисы:

«GET вызов сервиса GET приложением приводит к извлечению (чтению) информации (то есть атрибутов) из однорангового приложения. Услуга запрашивается только в режиме подтверждения, при этом ожидается ответ;

•SET: Вызов сервиса SET приложением приводит к модификации (записи) информации (то есть атрибутов) соответствующим одноранговым с ним приложением. Услуга может быть запрошена в под* твержденном или неподтвержденном режиме. В режиме подтверждения ожидается ответ;

«ACTION: Вызов сервиса ACTION приложением приводит к выполнению действий соответствующего однорангового приложения. Действие дополнительно квалифицируется значением ActionType (см. [4}). Сервис может быть запрошен в подтвержденном или неподтвержденном режиме. В режиме подтверждения ожидается ответ;

• - EVENT-REPORT: Вызов сервиса EVENT«REPORT приложением или ядром l-Kemel приведет к уведомлению о некотором событии соответствующего однорангового взаимодействующего с ним приложения. Сервис может запускаться с подтверждением или без подтверждения. В режиме подтверждения ожидается ответ;

• - INITIALIZATION: Запуск сервиса INITIALIZATION ядром l-Kernel приведет к попытке инициализации связи между некоторым RSU и каждым OBU. который еще не установил связь с этим RSU. Сервис INITIALIZATION должен использоваться только ядром l«Kemel.

• 5.2.2 Сервисные примитивы

Ядро T-Kernel должно предоставлять сервисы, указанные в 5.2.1, с использованием следующих сервисных примитивов:

• - GET request

«GET.indication;

• • GET.responce;

• • GEToonfirm;

«SET.request;

• - SET.indication;

• - SET. response:

• • SET.confirm;

• • ACTION.request:

• - ACTION.indication;

• • ACTION.responce;

• • ACTION.confirm;

• - EVENT-REPORT.request;

« EVENT-REPORT.indication;

• - EVENT-REPORT.response;

• - EVENT-REPORT.confirm;

• - INITIALISATION.request:

• • INITIALISATION.indication;

• • INITIALISATION.response;

• • INITIALISATION.confirm.

Примитивы INITIALISATION.request и INITIALISATION.confirm следует использовать только на RSU. Примитивы INITIALISATION.indication и INITIALISATION.response следует использовать только на OBU.

На рисунке 4 показана схема использования сервисов с подтверждением.

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

• 5.2.3 Формат сервисных примитивов

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

Таблица1 — Определения символов и выражений, используемых в таблицах 2—6

Таблица 2 — Формат примитивов сервиса GET

Таблица 3 — Формат примитивов сервиса SET

Таблица 4 — Формат примитивов сервиса ACTION

Таблица 5 — Формат примитивов сервиса EVENT-REPORT

Окончание таблицы 5

Таблица 6 — Формат примитивов сервиса INITIALIZATION

• 5.2.4 Параметры

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

Идентификатор вызывающего элемента (IID) должен иметь ASN.1 типа DSRC-EID и содержать идентификатор элемента, инициализирующего запрос или ответ, соответственно. Этот параметр не используется, если ответ посылается вызывающему элементу по умолчанию. Если IID используется, он должен содержать EID ответа на этот примитив. LID должен быть выбран ядром l-Kernel на стороне OBU. как определено в 6.3.2.

Идентификатор управления логической связью (LID) должен выбираться ядром l-Kernel на стороне OBU. как это определено в 6.3.2. Формирование цепочки — это логический параметр. При его значении «Истина» выполняется «конкатенация и связывание», как определено в 5.2.11.

Идентификатор элемента (EID) должен иметь ASN.1 типа DSRC-EID и содержать идентификатор элемента, который должен получить индикации или подтверждение, относящееся к запросу или. соответственно. ответу. Данный EID используется ядром T-Kemel на стороне приемника для передачи индикации или подтверждения адресуемому элементу. В случае если IID используется в запросе, то элемент, вызывающий ответ, должен использовать этот IID в качестве EID.

AtriblDList должен быть списком идентификаторов атрибутов элемента, получающего GET. indication. Значения этих атрибутов должны передаваться через GET.response и GET.confirm элементу, инициирующему GET.request. если были выполнены соответствующие условия.

Параметр FlowControl должен содержать характеристики коммуникационного сервиса нижнего уровня. Этот параметр должен быть установлен ядром T-Kemel на соответствующем сервисе LLC. Отношения между параметром FlowControl. характеристиками прикладного уровня и сервисом LLC должны быть такими, как описано в таблице 7. Другие сервисы LLC нижнего уровня, относящиеся или не относящиеся к данной таблице, описаны в разделе 6 и приложении Г.

Таблица 7 — Отношения между параметром FlowControl. характеристиками прикладного уровня и сервисом LLC

Окончание таблицы 7

Atrib.List должен быть последовательностью атрибутов, посылаемых примитивами Set.request/ SET.indication или GET.response/GET.confirm. Элемент, принимающий SET.indication. должен модифицировать значения атрибутов, указанных в списке AtnblD.List. значениями из Atrib.List. при условии, что соответствующие условия доступа были выполнены. В случае GET.response/GET.confirm элемент, который получил соответствующий GET.indication, должен послать значения атрибутов, адресованных в Atrib.List примитива GET.indication. элементу, вызвавшему примитив GET.request. при условии, что соответствующие условия доступа были выполнены.

Ret — код возврата, сформированный в качестве ответа на service.indication. Предопределены следующие коды:

• * noError: операция запроса выполнена успешно;

• * accessDenied; запрошенная операция не была выполнена по причине нарушения условий без* опасности системы;

•argumentError не выполнен доступ к одному или более атрибутам, по причине нераслоэнавания идентификатора атрибута, или значение специфицированного атрибута находилось вне допустимых пределов, или действие вызванного сервиса event.report не было поддержано;

■ complexityLimitation: запрошенная операция не была выполнена из-за сложности параметра;

• - processingFailure; обнаружен общий сбой в обработке операции;

• * processing; запрошенная операция обрабатывается, но результат еще не доступен;

• - chainingError; запрошенная операция не была выполнена в соответствии с правилами, изложенными в 5.2.11 «конкатенация и связывание».

Режим должен быть логическим параметром: Если истина, то должен поступить ответ сервиса на индикацию сервиса (режим подтверждения).

ActionType должен идентифицировать операцию элемента, который получает ACTION.indication и который должен быть вызван.

ActionParameter должен получать информацию, необходимую для вызова операции, идентифицированной в ACTION.indication.

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

EventType идентифицирует сообщение, которое должно быть доставлено элементу, получающему EVENT-REPORT.indicator.

EventParameter должен содержать дополнительную информацию, необходимую для сообщения, посылаемого с помощью сервисов EVENT-REPORT.request и EVENT-REPORT.indicator соответственно.

Параметр инициализации должен содержать информацию, необходимую для инициализации связи (т. е. BST по нисходящему каналу и VST по восходящему каналу) с использованием сервиса инициализации.

• 5.2.5 Характеристика протокола передачи

Протокол передачи должен включать следующие шаги, описанные в 5.2.6 и 5.2.17:

а) передача SDU для T-APDU;

б) кодирование T-APDU;

в) фрагментация T-APDU;

г) мультиплексирование фрагментов T-APDU;

д) конкатенация коротких фрагментов T-APDU;

е) доступ к LLC;

ж) обращение из LLC;

и) демультиплексирование фрагментов T-APDU;

к) фрагментация не конкатенированных фрагментов T-APDU;

л) декодирование и разделение T-APDU, возможно конкатенированных с одним или более единичным фрагментом T-APDU;

м) перевод PDU в SDU и рассылка адресату.

Примечания

• 1 Реализация отдельных этапов выходит за рамки настоящего стандарта до тех пор. пока их (внешне наблюдаемое) поведение соответствует приведенным ниже требованиям. Реализация может даже измените порядок шагов при условии, что это не имеет никакого значения для его одноранговой реализацш и для общего поведения всей последовательности шагов, то есть для T-APDU и LPDU.

• 2 Стрелки, показанные на рисунках 6—8 и 10—17. отображают гроцесс преобразования.

  
  
  

  TA3DU

  
  

  вар

  
  

  T-ASDU

  
  

  3*Р

  
  
  

  ЪЛРОи

  
  

  TAPDU

  
  

  ) КМФ 4жоифроммш0 т

  
  

  CWMiHieiuv

  
  

  4p«NMWW fW

  
  

  Твют Jixiwitril

  FOU или mniMfoKWJJUJ tf ммовяатммжны» т

  
  
  
  
  

  Виями инне остет

  «piJWfW

  «XX Мультиуимяр. с юнитлмицией

  
  

  L8DU

  
  

  Двфржшнтггор 0

  
  

  «х/ Дмцптплеаф

  
  

  LBOU

  
  

  IMP

  
  

Рисунок 6 — Функциональность ядра T-Kemel

• 5.2.6 Перевод блока данных сервиса (SDU) в блок данных протокола (PDU)

Ядро T-Kemel должно перевести сервис примитивы запросов и ответов в T-APDUs (рисунок 7) в соответствии со следующими правилами:

service.request переводится в соответствующий сервис-запрос T-APDU. определенный в приложении А:

service.response переводится в соответствующий сервис-ответ T-APDU. определенный в приложении А.

Идентификатор LID должен быть удален, и должно быть предоставлено управление логической связью LLC в каждом примитиве обслуживания LLC. как определено в 5.2.12.

В случае INITIALISATION.request значение поля LID должно быть 1111 1111₂.

Рисунок 7 — Перевод блока данных сервиса SDU в блок данных протокола PDU

• 5.2.7 Кодирование

Ядро T-Kernel должно кодировать запрос и ответ PDU в соответствии с ASN.1 8ASIC-PER. UNALIGNED (см. [3]). Кодируемые ASN.1 типы указаны в приложении А. Бит заполнения ASN.I-опреде-ление типа должен быть равен нулю.

Примечание — Для смягчения последствий невыровненного кодирования некоторые биты заполнения включены в ASN.I-определение типа в приложении А Результат кодирования всегда является целым кратным восьми битам (октету). Процедуры выравнивания и распределения октетов выполняются на этапах кодирования и декодирования PDU. есгм это необходимо.

Процедуры выравнивания октетов и согласования октетов, на которые не распространяется на-стоящий стандарт, описаны в пункте 10.1 {3].

Set-Request>SEQUENCE{

All BITSTRING (SJZE(l)),

mode BOOLEAN,

eld Dsrc-EID

accessCredentials OCTET STRING (SIZE(O-127,.)) OPTIONAL,

attrLIst AttributcLisL

ltd Dsrc-ЕЮ OPTIONAL

Рисунок 8 — Кодирование

• 5.2.8 Фрагментация

Ядро T-Kemel должно фрагментировать закодированные блохи данных протокола передачи прикладного уровня (T-APDU) до фрагментов T-APDU, которые включают в себя заголовок фрагментации. Заголовок фрагментации должен иметь длину не менее 1 октета и не более 3 октетов. Длина фрагмента T-APDU не должна превышать максимальную длину фрейма LLC. Количество битов внутри фрагмента должно быть кратно 8 битам. Все фрагменты, кроме последнего, должны иметь одинаковую длину. Фрагментация должна быть выполнена от наиболее значимого бита до наименее значимого бита в соответствии cASN.1 BASIC-PER (рисунок 9).

Примечания

• 1 Фрагментация основана на свойстве кодированного T-APDU. длина которого кратна восьми битам. Фрагментация нескольких PDU должна производиться параллельно.

• 2 Поскольку фрагментация выполняется параппегъно. фрагментация небольшого T-APDU может быть за* вершена до фрагментации болев крупного T-APDU. который был получен из SAP раньше меньшего фрагмента. Как следствие. T-APDU с гем же приоритетом не могут быть отравлены в том же порядке, в каком они были получены от SAP.

Фрагмент T-APDU. содержащий полный T-APDU, называется одиночным T-APDU.

• 5.2.8.1 Заголовок фрагментации

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

• 5.2.8.2 Структура заголовка фрагментации

Заголовок фрагментации должен состоять из одного индикатора фрагментации, одного номера PDU. одного счетчика фрагментов и одного индикатора расширения номера части. Положение связанных битое показано на рисунке 9. Биты нумеруются от 7 до 0. где бит 7 является наиболее значимым, а бит 0 — наименьшим значащим битом.

Рисунок 9 — Структура заголовка фрагментации длиной один октет

• 5.2.8.3 Индикатор фрагментации

Самый значимый бит (бит 7) любого заголовка фрагментации должен быть индикатором фрагментации. Этот показатель фрагментации должен быть равен 1₂. если этот фрагмент является последним из последовательности фрагментов, принадлежащих одному PDU, или если PDU не фрагментирован. Индикатор фрагментации должен быть равен 0₂. если фрагментация выполняется и если это не последний фрагментированный кадр в сообщении.

• 5.2.8.4 Номер PDU

Биты 6-3 первого октета представляют собой номер PDU. который должен быть уникальным для каждого LID во время дефрагментации в принимающих объектах и одинаковым во всех фрагментах T-APDU. принадлежащих одному T-APDU. Номера PDU 0000₂ и 0001₂ должны использоваться только фрагментами T-APDU, которые отправляются ядром B-Kemel.

• 5.2.8.5 Заголовок фрагментации длиной один октет

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

Биты 2 и 1 должны интерпретироваться как целое число без знака, где старший значащий бит является битом 2. первый октет и наименее значимый бит — это бит 1 первого октета. Бит 0 должен быть установлен в 1₂. Если фрагментация выполняется, то первому фрагменту присваивается значение счетчика фрагментов 0. второму фрагменту значение счетчика фрагментов 1 и др. Если фрагментация не выполняется, то значение счетчика фрагментов будет 0.

• 5.2.8.6 Заголовок фрагментации длиной два октета

Заголовок фрагментации длиной два октета должен использоваться для фрагментов от 4 до 511 бит; значение бита 0 первого октета должно быть установлено в 0₂. Биты 2 и 1 первого октета и биты 7-1 второго октета интерпретируются как целое число без знака, где старший значащий бит — это бит 2 первого октета и наименее значимый бит — бит 1 второго октета. Бит 0 второго октета должен быть установлен на 1₂. Номера фрагментов должны назначаться, как указано в пункте 5.2.8.5.

• 5.2.8.7 Заголовок фрагментации длиной три октета

Заголовок фрагментации с тремя октетами должен использоваться для фрагментов от 512 до 65535 бит; бит 0 первого октета должен быть установлен в 0₂. Биты 2 и 1 первого октета, биты 7x1 второго октета и биты 7 к 1 из третьего октета интерпретируются как целые числа без знака, где старший значащий бит — это бит 2 первого октета и наименее значимый бит — это бит 1 третьего октета. Бит О второго октета должен быть установлен в 0₂ и бит 0 третьего октета должен быть установлен в 1₂. Номера фрагментов присваиваются фрагменту, как указано в 5.2.8.5.

• 5.2.9 Мультиплексирование

Ядро Т должно мультиплексировать фрагменты T-APDU в соответствии со стратегией «Начало очереди», где приоритеты задаются ядром l-Kemel (см. 6.3.2).

Примечание — Помимо соблюдения приоритетов, настоящий стандарт не накладывает никаких ограничений на то, как мультиплексор должен обслуживать очереди. Как следствие. T-APDU с одинаковым приоритетом могут не отправляться в том же порядке, как они были фрагментированы (рисунок 11).

Рисунок 11 — Мультиплексирование

• 5.2.10 Конкатенация

Несколько последовательных фрагментов T-APDU могут быть назначены на один сервис LLC. если сервисы и LID. используемые в службах, одинаковы и ограничения по размеру для кадров LLC не нарушаются. Порядок фрагментов T*APDU внутри LSDU должен быть тот. который задан процедурой мультиплексирования.

Примечание — Эти условия для объединения будут иметь место только в следующих двух ситуациях:

• • один или несколько фрагментов T-APDU. каждьм из которых содержит один короткий не фрагментированный T-APDU. отображаются на один LSDU;

• • один или несколько фрапиентов T-APDU. каждый из которых содержит один короткий не фрагментированный T-APDU. отображаются на один LSDU после последнего фрагмента из серии фрагментов T-APDU. принадлежащих одному T-APDU.

ЕЛИ ЕШЗ

I

DL«UNITDATA.reauest(L!D.rrm ПТП1

Рисунок 12 — Конкатенация

• 5.2.11 Конкатенация с формированием цепочки

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

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

Если фрагмент цепочки T-APDU генерирует ответный фрагмент T-APDU с RetumStatus. отличающимся от «без ошибок», то ни одна из операций, вызванных последующими фрагментами T-APDU той же цепочки, не должна быть выполнена, и все связанные ответы должны содержать RetumStatus «chainingError».

Примечание — Если параметр сцепления имеет значение «true» и процедуры, определенные в 5.2.11, игнорируются, он не будет влиять на весь одноранговый протокол, потому что параметры цепочки получателю не передаются.

• 5.2.12 Доступ к сервису LLC

Ядро T-Kernel должно использовать службу LLC, назначенную параметром FlowControl T-ASDU (рисунок 13).

Параметр FlowControl должен интерпретироваться, как определено в 5.2.4. Для услуги INITIALISATION.request должна использоваться услуга «DL-UNtTDATA.request с запросом ответа»; для ИНИЦИАЛИЗАЦИИ. Служба ответа должна использовать службу «DL-UNITDATA.request без ответа».

ГЛ Н 11 И 111

I

DL-UNITDATA.reque$t(LID,HI I I I I 111 I 11

Рисунок 13 — Доступ к сервису LLC

• 5.2.13 Доступ из подуровня LLC

Ядро T-Kernel на принимающей стороне должно принимать LSDU в примитивах индикации LLC через LSAP.

• 5.2.14 Демультиплексирование

Ядро T-Kemel должно демультиплексировать LSDU. содержащие один или несколько сцепленных фрагментов T-APDU в соответствии с номером PDU в первом заголовке фрагментации. Ядро Т должно демультиплексировать LSDU. содержащие сцепленные фрагменты T-APDU в соответствии с номером PDU в первом фрагменте заголовка. LSDU с недопустимым первым заголовком фрагментации должен быть отброшен.

Примечания

1 Это приводит к очередям, в которых все LSDU имеют одинаковый номер PDU в заголовке первого фрагмента. Поскольку последующие фрагменты T-APDU в LSDU могут быть только одиночными фрагментами T-APDU, то асе фрагменты T-APDU из T-APDU будут поставлены в ту же очередь.

2 Поскольку только декодер, который знает тип PDU. подлежащего декодированию, может определять длину PER-encoded. PDU. демультиплексор не может определить длину сцепленных фрагментов T-APDU. Следовательно. разделение сцепленных фрагментов T-APDU откладывается до этапа декодирования. Так как этот шаг демугътиплексмрования гарантирует, что любые два фрагмента T-APDU с одинаковым номером PDU всегда будут помещаться в одну и ту же очередь, это демультиплексирование {разделение) действительно может быть решено позже.

Рисунок 14 —Демультиплексирование

• 5.2.15 Дефрагментация

Ядро T-Kernel должно дефрагментировать LSDU по очереди, то есть все LSDU с одинаковым номером PDU в первом заголовке фрагментации, удаляя в каждом LSDU первый заголовок фрагментации и объединяя остальные части LSDU в соответствии с номером фрагмента в первом заголовке фрагментации.

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

Примечания

• 1 Эта дефрагментация приводит к тому, что строки октетов, которые содержат один полный T-APDU. возможно. сцеплены с одним или несколькими фрагментами T-APDU.

• 2 Поскольку только декодер, который знает тип PDU. подлежащих декодированию, может определять длину PER-encoded. PDU. дефрагментатор не может определить длину первого T-APDU и. следовательно, не может разделить T-APDU из любых сцепленных фрагментов с одним T-APDU. Разделение сцепленных фрапнентов T-APDU откладывается до шага декодирования.

• 3 Поскольку один дефектный первый заголовок фрагментации приведет к удалению всех LSDU с тем же номером PDU в их первом заголовке фрагментации, такой дефект приведет к удалению любого сцепленного одиночного T-APDU фрагмента.

Если один или несколько заголовков фрагмента T-APDU все еще отсутствуют, когда принимаются фрагменты T-APDU с восемью более высокими номерами PDU (из 14 циклически используемых значений). все LSDU с номером PDU. равным номеру PDU отсутствующего фрагмента T-APDU, отбрасываются.

Примечание — Поскольку фрагменты Т-APDU не могут быть интерпретированы, ядро T-Kemei не может определить, является ли отброшенный Т- APDU частью индикации (см. рисунки 4. 5) или частью сервисного примитива соответствующего приложения, или был ли он частью действия, события-отчета, отправки или получения. Поэтому T-Kernel не может генерировать или помогать элементу приложения в генерации Т- APDU с правильным значением RelumStatus.

Рисунок 15 — Дефрагментация

• 5.2.16 Декодирование и разделение

Ядро T-Kernel должно декодировать дефрагментированный T-APDU в соответствии с ASN.1 BASIC-PER, UNALIGNED (см.[3]). Декодируемые типы ASN.1 указаны в приложении А.

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

• 1) Он декодирует T-APDU.

• 2) Если не удается декодировать T-APDU. вся октетная строка отбрасывается.

• 3) Если ему удается декодировать T-APDU. он передает декодированный T-APDU следующей процедуре (см. 5.2.17).

• 4) Он должен искать завершающие октеты и предполагать, что эти оставшиеся октеты содержат еще один одиночный TAPDU фрагмент.

• 5) Он должен проверить достоверность заголовка первого фрагмента оставшейся октетной строки (биты со 2 до бита 0 должны иметь значение «001₂ »).

• 6) Если заголовок первого фрагмента недействителен, все оставшиеся фрагменты T-APDU должны быть отброшены.

• 7) Если заголовок первого фрагмента T-APDU действителен, заголовок фрагмента должен быть удален и декодер (разделитель) должен продолжить декодирование с шага 1.

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

Set-Reqtieslz=SEQUENCE( fill mode cid accessCredenttals attrLIst ltd

BIT STRING (SlZE(l)),

BOO1£AN.

Dsrc-EID

OCTET STRING (51ZE(O-127_)) OPTIONAL, Attribute Ust.

Dsrc-EID OPTIONAL

Рисунок 16 — Декодирование

• 5.2.17 Перевод блока данных протокола (PDU) в блок данных сервиса (SDU)

Декодированный T-APDU должен использоваться для построения T-ASDU в соответствии со следующими правилами.

Запрос на обслуживание должен быть переведен в соответствующий sennce.indication T-ASDU. Сервисный ответ должен быть переведен в соответствующий service.confirm T-ASDU.

T-ASDU должен доставляться элементу, указанному в параметре EID T-APDU. но не самому ядру T*Kemel. SDU INITIALISATION.indication должен быть доставлен ядру l-Kemel.

Если адресный элемент отсутствует. T-ASDU должен быть отброшен.

Ядро T-Kernel должно информировать управление о LID этого SDU.

Рисунок 17 — Перевод блока данных протокола (PDU) в блок данных сервиса (SDU)

• 6 Ядро инициализации

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

Ядро l-Kemel должно осуществлять инициализацию связи между OBU и RSU путем обмена информацией о профилях и приложениях с его одноранговым модулем. Оно информирует заявки внутри OBU о наличии одноранговой заявки внутри RSU. Оно должно обрабатывать LID OBU.

Ядро l-Kernel должно предлагать свои услуги посредством сервисных примитивов, определенных в 6.2.

Ядро l-Kernel должно инициализировать связь посредством BST, как определено в приложении А. BST должна быть передана в один сервисный примитив LLC.

Ядро l-Kemel может инициализировать связь посредством VST. как определено в приложении А. Ядро l-Kernel должно выполнить инициализацию по протоколу в порядке, определенном в 6.3.

Ядро l-Kemel должно выполнять свои функции, используя LID. BST и механизм освобождения.

• 6.2 Сервисы

  • 6.2.1 Описание сервисных примитивов

Ядро l-Kemel должно предоставлять следующие сервисы другим ядрам или приложениям:

• RegisterApplicationRSU: вызов службы RegisterApplicationRSU приложением со стороны RSU должен привести к регистрации этого приложения в списке приложений ядра l-Kernel.

• - RegisterAppiicationOBU: вызов службы RegisterAppiicationOBU приложением со стороны OBU должен привести к регистрации этого приложения в списке приложений ядра l-Kernel.

• - DeregisterApplication: вызов приложения DeregisterApplication приложением должен привести к удалению связанной записи в списке приложений.

• - NotifyApplicationOBU: l-Kemel использует сервис NotifyApplicationOBU для информирования приложения на стороне OBU о наличии потенциального партнера по коммуникациям (т. е. со стороны RSU) и UD. сгенерированного OBU.

• - NotifyApplicationRSU: l-Kernel использует сервис NotifyApplicationRSU для информирования приложения на стороне RSU о наличии потенциального партнера по коммуникациям (то есть приложения со стороны OBU) и LID соответствующего OBU.

• - EndApplication: вызов службы EndApplication приложением должен привести к уведомлению ядра l-Kernel о том. что LID больше не нужен для этого приложения.

• 6.2.2 Формат сервисных примитивов

Форматы инициализации ASDU сервисных примитивов определены в таблицах 6—13.

Таблица 8 — Инициализация сервиса RegisterApplicationRSU

Окончание таблицы 8

Таблица 9 — Инициализация сервиса RegtsterAppHcalionOBU

Таблица 10 — Инициализация сервиса DeregisterApplication

Таблица 11 — Инициализация сервиса NolrfyApplicationRSU

Таблица 12 — Инициализация сервиса NotifyApplicationOBU

Таблица 13 — Инициализация сервиса EndApplication

• 6.2.3 Параметры

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

• AID идентифицирует приложение DSRC.

• - MandatoryApplication имеет значение «true», если приложение является обязательным, и «false», если оно не является обязательным.

• • Priority является приоритетом приложения. Малое значение представляет высокий приоритет, большое значение представляет низкий приоритет. Ядро l-Kernel может учитывать этот параметр при принятии решения о приоритете приложения.

Параметр EID включает в себя следующее:

• - для службы RegisterApplicationRSU EID идентифицирует элемент, подлежащий регистрации. EID не используется, если приложение является единственным приложением по умолчанию:

• • для службы RegisterApplicationOBU EID идентифицирует элемент, подлежащий регистрации:

-для сервисов NotifyApplication EID идентифицирует элемент однорангового приложения, если таковой имеется.

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

Parameter является необязательной информацией для сервисов RegisterApplicationRSU и RegisterApplicationOBU. Если Parameter присутствует, он передается в сервисы NotifyApplicationOBU или NotifyApplicationRSU соответственно. Параметр имеет тип ApplicationContextMark, который должен иметь блок CHOICE тип OCTET STRING (Размер (0..127....)).

RSU указывает идентификацию RSU. который предлагает услугу.

ObeConfiguration описывает конфигурацию и состояние OBU. относящегося к LID, указанному в NotifyApplicationRSU.

• 6.2.4 Предоставление сервисов

На стороне RSU ядро l-Kernel должно предоставить сервисы RegisterApplicationRSU, Deregister-Application. NotifyApplicationRSU и EndApplication.

На стороне OBU ядро l-Kemel должно предоставить сервисы RegisterApplicationOBU. DeregisterApplication. NotifyApplicationOBU и EndApplication.

• 6.3 Описание режима работы

  • 6.3.1 RSU: повторная передача BST

    • 6.3.1.1 Причина

Внедрение системы требует передачи BST.

• 6.3.1.2 Описание

На стороне RSU l-Kernel должно передавать BST. определенное в приложении А. Оно должно использовать INITIALISATION.request сервис ядра T-Kemel со следующими настройками: параметр инициализации = BST. Время между последующими передачами BST является задачей реализации системы и находится за пределами области применения этого стандарта.

• 6.3.2 OBU: прием BST и передача VST

  • 6.3.2.1 Причина

Ядро l-Kerrrel OBU получает BST используя сервис INITIALISATION.indication T-Ядра со значением параметра инициализации = BST.

• 6.3.2.2 Описание режима работы

Пусть выполняется хотя бы одно из следующих условий:

а) BeaconlD отличается от последнего полученного BeaconlD.

б) время между последним полученным BST и текущим полученным BST превышает Т секунд, значение которых определено в разделе 8.

Тогда ядро l-Kernel OBU должно:

• - информировать управление о профиле, полученном е BST. Этот профиль должен быть профилем по умолчанию для связи;

-сравнивать идентификаторы DSRCApplicationEntitylD. указанные в списке приложений внутри BST. с зарегистрированными DSRCApplicationEntitylD.

Для всех зарегистрированных DSRCApplicationEntitylD. которые находятся внутри BST:

• - добавить DSRCApplicationEntitylD и, если они присутствуют в связанном RegisterApplicationOBU. EID и параметры в списке приложений VST;

• - уведомить зарегистрированный элемент с помощью NotifyApplicationOBU со следующими параметрами:

• - RSU = BeaconlD. указанный в 8ST;

• - Priority = позиция в обязательном ApplicationList BST для всех DSRCApplicationEntitylD внутри обязательного ApplicationList или число DSRCApplicationEntitylD в обязательном ApplicationList плюс зарегистрированный приоритет для всех DSRCApplicationEntitylD внутри необязательного ApplicationList;

■ Link identifier - LID. выбранный ядром I-Kemel:

• - Parameter - Parameter из таблицы BST. если он там отсутствует, то параметр не заполняется.

Ядро I-Kemel должно выбрать случайный LID, имеющий приблизительно равномерное распределение в диапазоне возможных значений е соответствии с требованиями LID. как определено в разделе 8.

Ядро t-Kernel должно информировать ядро T-Kemel через управление приоритетами уведомленного приложения.

Ядро l-Kemei должно выбрать профиль из profileList BST. который поддерживается в OBU (то есть который известен одру I-Kemel) и должно установить элемент данных профиля VST в этом профиле.

VST относится к VST типа ASN.1, как определено в приложении А.

Ядро l-Kemel должно передавать VST. Оно должно использовать сервис INITIALISATION.response ядра T-Kernel со следующими настройками параметров:

• - идентификатор ссылки - LID;

• - параметр инициализации - VST.

Ядро должно хранить BeaconlD и время.

Ядро I-Kemel должно хранить Application List VST вместе с LID, до тех пор. пока LID действителен.

• 6.3.3 RSU: ответ VST

  • 6.3.3.1 Причина

Ядро I-Kemel RSU для получения VST использует INITIALISATION.confirm ядра T-Kernel с параметрами:

• - идентификатор ссылки = LID;

• - параметр инициализации - VST.

• 6.3.3.2 Описание режима работы

Для всех DSRCApplicationEntitylD внутри VST ядро l-Kernel должно уведомить зарегистрированный элемент с помощью сервиса NotifyApplicationRSU со следующими параметрами:

• - Priority = позиция в списке обязательных приложений. mandApplication BST для всех DSRCApplicationEntitylD внутри mandApplication или количество DSRCApplicationEntitylD в mandApplications плюс позиция в nonmandApplications для всех DSRCApplicationEntitylD внутри nonmandApplications;

• - EID = EID из таблицы VST, если он там отсутствует, то параметр не заполняется;

• - LID = LID. полученный в INTITIALISATION.confirm;

• - Parameter = Parameter из таблицы VST. если он там отсутствует, то параметр не заполняется;

• ObeConfiguration - ObeConfiguration, полученная в VST.

Ядро I-Kemel должно информировать управление об отношении между LID и профилем, указанным внутри VST. Этот профиль должен использоваться для дальнейшей связи с OBU с этим LID, т. в. исходящие данные должны быть отправлены с использованием этого профиля и входящие данные должны быть получены с использованием этого профиля.

Ядро I-Kemel должно хранить ApplicationList VST вместе с LID. указанным в INITIALISATION, confirm.

• 6.3.4 RSU: ReglsterApplicationRSU

  • 6.3.4.1 Причина

Причиной является вызов приложения на стороне RSU.

• 6.3.4.2 Характеристика режима работы

Получив примитив RegisterApplicationRSU. ядро I-Kemel RSU должно вставить предоставленную информацию е примитиве в ApplicationList для обязательных или необязательных приложений, если это применимо. I-Kernel может использовать информацию, указанную в параметрах MandatoiyApplication и Priority. Если ядро B-Kemel присутствует, то приоритет ядра B-Kemel определяется ядром I-Kernel. Профили могут быть вставлены в ProfileList BST.

• 6.3.5 OBU: RegisterApplicatlonOBU

  • 6.3.5.1 Причина

Причиной этого является вызов приложением.

• 6.3.5.2 Описание режима работы

Получив RegisterApplicationOBU. Я-ядро OBU должно добавить соответствующее приложение в список зарегистрированных приложений.

Каждый элемент в OBU должен иметь уникальный номер. Процесс должен гарантировать, что для каждого элемента выделяется один уникальный EID. зарегистрированный в OBU (EID - 0 зарезервировано для системы).

• 6.3.6 OBU: DeregisterAppllcation

  • 6.3.6.1 Причина

Причиной этого является вызов приложением.

Получив DeregisterApplicaton. ядро l-Kemel должно удалить соответствующее приложение из списка зарегистрированных приложений.

• 6.3.7 RSU: DeregisterAppllcation

  • 6.3.7.1 Причина

Причиной этого является вызов приложением.

• 6.3.7.2 Описание режима работы

Получив DeregisterAppllcation. ядро l-Kemel должно удалить соответствующее приложение из списка зарегистрированных приложений BST.

• 6.3.8 RSU: Сброс приложения

  • 6.3.8.1 Причина

Причиной этого является вызое приложением.

При получении EndApplication ядро l-Kernel должно удалить приложение из сохраненного AppticationLtst VST. Если список приложений пуст (то есть все приложения закончились), ядро l-Kemel передает задачу сброса на одноранговое ядро l-Kemel. Оно должен использовать службу EVENT-REPORT.reguest ядра Т-Kernel со следующими параметрами:

• * Invoker identifier = (empty);

• - Link identifier = LID;

• - Element identifier = EID = 0;

• * EventType = Release (0):

• * EventParameter = (empty);

• * Mode ⁼ FALSE;

• - FlowControl = 1.

• 6.3.9 Прием Сброса

  • 6.3.9.1 Причина

Ядро l-Kemel получает сброс посредством сервиса EVENT-REPORT.indication ядра T-Kemel с параметрами:

• - Invoker identifier = (empty);

• - Link identifier = LID:

• - EventType = Release (0);

• - EventParameter = (empty);

• - Mode = FALSE.

Примечание — Параметры EID и FlowControl являются обязательными в табгыце 5. Однако сервис EVENT-REPORT.indication не нуждается в этих параметрах в контексте процесса подачи заявления на сброс RSU. Поэтому они опущены.

• 6.3.9.2 Поведение

Ядро l-Kemel должно удалить VST, относящееся к LID. Данный LID больше не действует.

• 7 Ядро широковещания

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

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

Ядро B-Kernel должно предлагать свои услуги посредством сервисных примитивов, определенных в 7.2.

Ядро B-Kemel должно осуществлять связь, отправляя BroadcastPool. определенный в приложении А. Ядро B-Kemel должно осуществлять трансляцию по протоколу с поведением, определенным в 7.3.

• 7.2 Сервисы

  • 7.2.1 Описание сервисных примитивов

Ядро B-Kemel должно предоставлять следующие услуги:

■ BroadcastData: вызов службы BroadcastData приложением на стороне RSU должно приводить к передаче информации одноранговому приложению на стороне OBU или обновлению этой информации;

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

• 7.2.2 Формат сервисных примитивов

ASDU широковещания для сервисных примитивов должны иметь форматы, определенные в таблицах 14 и 15.

Таблица 14 — BroadcastData

Таблица 15 — GetBroadcastData.request

• 7.2.3 Параметры

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

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

• - имя файла должно быть FileName, который должен быть извлечен из пула вещания;

• • EID должен быть Dsrc-EID элемента, вызывающего сервис GetBroadcastData.

• 7.2.4 Распределение предоставляемых сервисов

На стороне RSU ядро B-Kemel должно предоставлять примитив BroadcastData. На стороне OBU ядро B-Kernel предоставляет примитивы GetBroadcastData.request и GetBroadcastData.confirm.

• 7.3 Описание режима работы

  • 7.3.1 RSU: передача Broadcastpool

    • 7.3.1.1 Причина

Использование системы основано на передаче пула вещания.

• 7.3.1.2 Характеристика режима работы

На стороне RSU В-ядро должно передавать BroadcastPool. определенный в приложении А. Оно должно периодически запрашивать сервис SET.request ядра T-Kemel со следующими настройками параметров:

• - идентификатор Invoker = (пусто);

• - идентификатор ссылки = 1111 1111₂;

• • идентификатор элемента - EID - 0;

• - список атрибутов = (0. BroadcastPool);

• - режим = FALSE;

• • FlowControl = 1.

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

• 7.3.2 OBU: получение пула широковещания

  • 7.3.2.1 Причина

Ядро 8-Kemel OBU получает пул широковещания, используя сервис SETindication ядра T-Kernel со следующими параметрами:

• - идентификатор вызывающего элемента = (пусто);

• • идентификатор ссылки = 1111 1111₂;

• - список атрибутов = (0. BroadcastPool):

• - режим = FALSE.

• 7.3.2.2 Описание режима работы

На стороне OBU ядро B-Kernel должно заменить текущее значение BroadcastPool новым значением BroadcastPool.

• 7.3.3 RSU: BroadcastData

  • 7.3.3.1 Причина

Причиной является вызов приложения.

• 7.3.3.2 Описание режима работы

Ядро B-Kemel должно вставить файл NamedFile в содержимое BroadcastPool и FileName в каталог.

Если содержимое BroadcastPool есть файл с тем же FileName. этот файл заменяется на новый файл.

• 7.3.4 OBU: GetBroadcastData.request

  • 7.3.4.1 Причина

Причиной этого является вызов приложения.

• 7.3.4.2 Описание режима работы

Ядро B-Kemel должно извлечь файл с заданным FileName и передать его приложению с Dsrc-EID (EID) с помощью сервисного примитива GetBroadcastData.confirm.

• 8 Расширенные определения для различных служб нижнего уровня и интерфейсов приложений

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

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

• 8.2 Расширенные определения

  • 8.2.1 CEN

Расширенные определения в стандартах CEN DSRC для дорожного транспорта и транспортной телематики описаны 8.2.1.2. Соединение канала канального уровня и инициализация прикладного уровня одновременно выполняется во взаимодействии (см. рисунок 18).

• 8.2.1.1 Определения

Особенности расширенных определений следующие:

• - параметры примитивов, определенные в 5.2.3. описанные ниже, являются обязательными:

• • параметр FlowControl каждого GET.confirm. SET.confirm. ACTION.confirm и EVENTREPORT подтверждать обязательно;

• • LID of INITIALISATION.request/индикация. определенная в таблице 6. должна быть адресом широковещания:

• - время между последним полученным BST и текущим полученным BST. определенным в 6.3.2. должно составлять 255 секунд;

• ■ Я-ядро должно выбрать случайный LID в поведении передачи VST. определенном в 6.3.2;

-EID сервиса SET.request для передачи пула широковещания, определенного в 7.3.1, должен быть 0;

• ■ механизмы восстаноаления/повторной передачи определены на нижнем уровне;

• • определение ActionType и присвоения значений доступны по адресу //www.tc278.eu/:

• - присвоение номеров профиля в соответствии с приложением А(5] основано на определении профилей DSRC, как указано в [6].

Примечание — Информацию о CEN ; DSRC-стандарте, представляющем собой набор из четырех стандартов. см.на сайте http:/Avww.tc278.eu/.

• 8.2.1.2 Справочные ссылки

Справочные ссылки включают [4]. [6]. [7].

At

Рисунок 16 — Оценивание BST

• 8.2.2 IEEE/ASTM International

Расширенные определения в стандартах IEEE и ASTM (см. соответствующий эталонный стандарт, представленный в 8.2.2.2).

Примечания

• 1 Информацию о IEEE см. на сайте //www.ieee.org.

• 2 ASTM International см. на сайте //www.astm.ofg.

• 8.2.2.1 Определения

Детали расширенных определений должны быть описаны.

• 8.2.2.2 Справочная ссылка

См. (8].

• 8.2.3 ARIB

Расширенные определения из [9] описаны в этом пункте. В этом стандарте ARIB DSRC обмен BST/VST для инициализации прикладного уровня выполняется с использованием PDU после установления соединения с канальным уровнем. Его LID является частным адресом, случайно выбранным ядром l-Kemel. и он передается канальному уровню для связи со службами управления.

• 8.2.3.1 Определения

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

• параметр FlowControl каждого GET.confirm. SET.confirm. ACTION.confirm и EVENTREPORT не применяется;

■ LID сервиса INITIALISATION.request/indication, определенный в таблице 6. должен быть частным адресом (случайно выбранный LID):

-дополнительный 12-й параметр сервиса FlowControl определен в таблице 16. запрос ответа ожидания DL-UNlTDATA.request в таблице 7.

Таблица 16 — Дополнительный параметр сервиса FlowControl

- дополнительный параметр Norm_end к EndApplication таблицы 13 в 6.2.2 определен в таблице 17 как необязательный.

Norm_end указывает условие EndApplication после завершения функции приложения. Ядро l-Kemel может использовать этот параметр для определения значения таймера Т. определенного в 6.3.2.

Таблица 17 — Необязательный параметр сервиса EndApplication

Время между последним полученным 8ST и текущим полученным BST. определенным в 6.3.2. должно быть от 0 до 255 с.

Ядро l-Kernel должно использовать частный (случайно выбранный) LID в поведении передачи VST. определенном в 6.3.2.

EID сервиса SET.request для передачи пула вещания, определенной в 7.3.1. может быть любым числом.

Примечания

• 1 Эталонные стандарты для стандарта DSRC ARIB определены в 8.2.3.2 (см. httpJ/www.ahb.or.jp или http.Wwww.arib или jp/english/).

• 2 Значение таймера является параметром реализации. Если требуется значение таймера более 255 секунд, максимальное значение таймера может быть изменено.

• 3 В соответствии с этим ARIB реализация функциональности ядра широковещательной передачи не известна. Функциональность ядра широковещательной рассылки должна быть дополнительно рассмотрена в отношении определения EID.

Структуры данных

А.1 Использование модулей

В настоящем приложении указываются справочные структуры данных, которые были определены а разделах 5—7. Согласно этому приложению, любой, кто использует данный стандарт, должен указывать структуры данных для пользовательской системы, и T-Kemel в такой системе должен использовать модули DSRCData и DSRCTransferOata в соответствии с приведенными структурами данных.

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

Примечание — Реализация импорта (IMPORT) и экспорта (EXPORT) определена в [1].

А.2 Модули ASN.1

DSRCData (iso(1) standard(O) src(15628) dsrcData(O) version (1)} DEFINITIONS AUTOMATIC TAGS::» BEGIN -ИМПОРТ

• - Новые определения типов должны быть импортированы следующим образом:

• - Typel. Туре2 FROM ModuteA: -где:

• - - Туре! и Туре2 должны быть заменены на названия типов, которые будут импортированы.

• - - ModuleA должен быть заменен на модуль экспорта из ASN.1

• - ЭКСПОРТИРУЕТ все:

Acbon-Request::»SEQUENCE( mode BOOLEAN, etd Dsrc-EID. actionType ActionType. accesscredentials OCTET STRING (SIZE (0..127,...)) OPTIONAL, action Paranre ter Cotainer OPTIONAL, iid Dsrc-EID OPTIONAL

Acbon-Response::»SEOUENCE{ ПН BIT STRING (SIZE(D).

etd Dsrc-EID.

RetumS talus OPTIONAL}

ActionType::=INTEGER(0..127....)

• - (0..11В)Зареэер8ированы для использования стандартами ИСО/CEN.

• - Типы действий, представленные ниже, определены в стандарте ИСО 14906

• - 0: getStamped (получить ярлык)

• - 1: setStamped (задать ярльж)

• - 2 : getSecure (получить безопасность)

• - 3 : setSecure (задать безопасность)

• - 4 : getlnstance (получить пример)

• - 5: setinstance (задать пример)

• - 6 : getNonce (получить данное время)

• - 7 : setNonce (задать данное время)

• - 8 : transferchannel (канал трансфера)

• - 9: copy (копировать)

• - 10 : setMMI (задать)

• - 11: substract (субподряд)

• - 12: add (добавить)

• - 13 : debit (дебет)

• - 14 : credit (кредит)

• - 15 : echo (эхо)

• - (119 —127) Зарезервировано для личного использования

ApplicabonContextMark::=Container -- OCTET STRING (SIZE(O..127,...))

• - Пример ApplicationContextMark

• - может быть найден в ИСО 14906. как «EFC-ContextMark» Applicat*onList::=SEQUENCE (SIZE (0..127,...)) OF

SEQUENCE{ aid DSRCApplicabonEntitylD. e»d Dsrc-EtD OPTIONAL, parameter AppticabonContextMark OPTIONAL )

AttribuleldList;;=SEQUENCE (SIZE(0.. 127....)) OF INTEGER(0..127....) AttribuleList::=SEQUENCE (StZE(0..127....)) OF Attributes Attnbutes:;=SEQUENCE{ attributeld INTEGER (0..127....), attnbuteVatue Contaier )

BeaconlD::=SEQUENCE{ Manufacturerid INTEGER

(0..65535). iodrvidualid INTEGER (0..134217727)

) — для регистрации идентификатора производителя см. www.nen.nl/cen278 Broad castPool::=SEQUENCE{ directoryvaiue Directory, content SEQUENCE (SIZE(0..127....)) OF File >

BST::=SEQUENCE{ rsu BeaconlD. time Time, profile Profile. mandAppiications

ApplicabonList. nonmandAppticabons ApplicabonList OPTIONAL. profileList SEQUENCE (StZE(0..127....)) OF

Profile }

Container;:=CHOlCE{

• - теги [17..69] определены в ИСО 14906 для использования в приложении CEN DSRC

• - теги [70. .86] зарезервированы для использования в приложении ИСО/ CEN DSRC

• - теги [87.. 127] зарезервированы для личного использования и предназначены для

• - адресации соответствующих идентификаторов личных атрибутов.

... — маркер расширения

• - Новые атрибуты должны быть инициализированы как:

• - componentNamel [i] ModuleA.Type1

• - где

• - - «componentNamel» - уникальное имя для определения контейнера

• - - «I» зарегистрированный тег. выбранный из указанных выше диапазонов.

• - - «Туре1» имя импортированного типа, а

• - «МобЫеАв название модуля, из которого импортируется тип Туре1.

• - Префикс «ModuleA» требуется только в случав конфликта имен.

• - если имя «Туре1» также не определено в модуле «DSRCData» и

• - не импортировано из другого модуля, префикс «ModuleA» должен быть опущен.

}

Directory::=SEQUENCE

(SIZE(0..127,...)) OF RleName

Dsrc-EID::=INTEGER(0..127. .„)

}

Event-Report-Response::=SEQUENCE{ fill BIT STRING (SIZE(2)).

eid Dsrc-EID.

iid Dsrc-EID OPTIONAL.

ret RetumStatus OPTIONAL

)

EventType:;=INTEGER{

release (0)

• - (1..118) зарезервированы для использования ИСО/CEN

• - (119..127) зарезервированы для личного использования И0..127....)

File::=SEQUENCE (SIZE(0..127....)) OF Record FileName::=SEQUENCE{

aselD Dsrc-EID,

filelD INTEGERS. .127„..)

}

• - He определен. Может быть определен в будущей версии.

Get-Req ue st::=SEQUENCE{ fill BIT STRING (SiZE(1)),

e«d Dsrc -EID.

accesscredentials OCTET STRING (SiZE(0.. 127,...)) OPTIONAL, iid Dsrc-EID OPTIONAL.

attrldList AtlributeldList OPTIONAL

Get-Res ponse::=SEQUENCE{ 611 etd iid attributelist AtlributeList ret

Initialisation- Request::=BST lnrtialcsation-Response:;=VST NamedF9e::^sSEOUENCE( name FileName. file File

• - NamedFile будет использоваться в T-Kemet с GetBroadcaslData-Request.

• - это может быть указано в T-APDU в будущей версии.

ObeConfiguration::=SEOUENCE{ equipmentclass INTEGER(0..32767). manufacturerlD obeStatus

Profite::=INTEGER (0..127....)

• - (0..118) зарезервированы для использования ИСО/CEN.

• - {119..127) зарезервированы для личного использования Recofd::=CHOICE{ simple VisibleStnng.

)

RelumStatus::=INTEGER{

noError

accessDenied

argumentError

complexityLimitation

processingFailure

processing

chainingError

• - (7..9Э) зарезервированы для будущего использования ИСО/CEN.

• - (100.. 127) зарезервированы для личного использования И0..127....)

Set-Request::-SEQUENCE{

fill ВГГ STRING (SiZE(l)),

mode BOOLEAN,

©id Dsrc-EID.

accesscredentials OCTET STRING (SIZE(0..127....)) OPTIONAL.

attrList Atlr ibuteLst.

»d Dsrc-EID OPTIONAL

} Set-Response::=SEQUENCE{ fill BIT STRING (SIZE(2)).

©id Dsrc-EID.

i*d Dsrc-EID OPTIONAL,

ret RetumStatus OPTIONAL

}

Tene:;=INTEGER(0..4294967295)

• - Количество секунд, прошедших с

• - 1 января 1970. 00:00 (UTC)

T-APDUs::=CHOICE{

VST::=SEOUENCE{ fiD BIT STRING (SIZE(4)).

profile Profile,

applications AppficationList.

obeConfiguration ObeConfiguration }

END

DSRCtransferData {iso( 1) standard{0) dsrc(15628)

dsrctransferData( 1) version (1)}

DEFINITIONS::® BEGIN

IMPORTS T-APDUs

FROM DSRCData {iso(1J standard(O) dsrc(15628) dsrcData(0) version (1)):

- ЭКСПОРТИРУЕТ все:

Message::® T-APDUs -Сообщение передается при лающи связи DSRC:

END

Наименование и регистрация

Б.1 Введение

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

Для контроля однозначности имен существует два способа:

• • регистрации идентификаторов через регистрирующий орган;

• • определение а стандартах применения.

Б.2 Объекты регистрации

Следующие компоненты прикладного уровня DSRC должны быть зарегистрированы с уникальным идентификатором в соответствии с процедурами регистрации, установленными в (10]:

manufacturerlD: «ID производителя» — всемирный уникалышй идентификатор производителей оборудования DSRC.

Б.З Элементы, определенные стандартами приложения

Стандарты ИСО и стандарты регионального применения, описанные в разделе 8. используются для определения и управления однозначностью следующих элементов. Однако они не входят в сферу применения данного стандарта для определения элементов, используемых приложениями.

Стандартами DSRC-приложения определены следующие пункты:

• • ActionType: «Тип Действия» должен быть универсальным уникальным идентификатором действия;

• • AttributelD: «Атрибуты ID» должны быть унихагъными в контексте каждого элемента. Стандарты приложений могут назначать идентификаторы атрибутов, на которые распространяется этот стандарт;

• • EventType: «Тип События» должен быть универсальным уникальным идентификатором события.

Примечание — NEN содержит список значений «АсЬопТуре» и «EventType». назначенных стандартами DSRC-приложений (см. http:/ www.tc278.eu/)

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

Примеры кодирования

В данном примере показано содержимое прикладного уровня обмена данньши BST (сервисная таблица радиомаякауУЗТ(сервисная таблица транспортного средства), которое определено в разделе 7, для приложения электронного сбора платежей.

Примечание — Для приложений электронных сборов платежей [4] определяет дополнительные детали к настоящему стандарту.

Дано только содержимое прикладного уровня DSRC. Должны быть добавлены поля канала связи DSRC в соответствии с ИСО и региональными стандартами (LID, MAC, LLC. FCS и т.д.). Важно понимать, что для того, чтобы бортовой модуль мог передавать VST (сервисную таблицу транспортного средства), он должен запросить RSU (устройство придорожной инфраструктуры) о расположении среды передачи данных. Убавление функциональностью доступа к среде передачи данных является задачей канального уровня DSRC. Связанные сообщения запроса частного окна (восходящая связь) и сообщения о выделении частного окна (нисходящая связь) здесь не показаны.

Таблица В.1 — Пример BST (сервисной таблицы радиомаяка). Одно обязательное приложение (AID = 1 означает EFC)

Окончание таблицы В. 1

Таблица В.2 — Пример VST (сервисной таблицы транспортного средства). Слисок приложений, доступных на мобильном оборудовании

Окончание таблицы В.2

Примечание — В [3]. приложение В. приведен более подробный пример.

Декларация поддерживаемых функций прикладного уровня

Для каждого элемента оборудования DSRC. соответствующему данному стандарту, должны быть объявлены реализованные функции в соответствии с таблицей Г.1.

Профиль представляет функции (характеристики) партнеров по связи и должен быть включен в элементы (параметры) другого уровня, поскольку каждый протокол уровня взаимодействует с элементом другого уровня. Профили, определенные в приложении А, могут быть обработаны l-Kernel. как это описано в разделе 8. и переданы в BST. Когда бортовое устройство входит в зону действия RSU дорожного блока, блоки обмениваются между собой BST и VST. RSU и OBU сообщат профилю(ям). что они обменялись таблицами, используя VST и BST для согласования профиля подключения.

Таблица Г.1 — Форма объявления функций прикладного уровня приложения

Примечание — Если значение «Timer Т» более 255 секунд или не определено, следует заполнить столбец точным значением (временем) или н.п. (не применяется).

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

Сервисы нижнего уровня

Д.1 Описания возможностей

Д.1.1 Общие положения

Прикладной уровень требует сервисный интерфейс для взаимодействия с сервисами нижнего уровня. Кон* кретньм синтаксис и семантика реализации выходят за рамки настоящего стандарта. По згой причине определения сервисов даны в общем виде, а не для конкретных сервисных примитивов. Однако любой соответствующий нижний уровень сервиса должен предоставлять услуги, которые соответствуют каждой из общих функций сервиса, определенных в подразделе Д. 1.2. Дополнительные сервисы нижнего уровня могут быть предоставлены в качестве ретранслирующей функции. Реализация каждого из этих сервисов не имеет импликаций, касающихся отношений между исходным оборудованием, делающим исходный запрос, и отвечающим оборудованием. Эти функции могут быть реализованы в одноранговых связях или связях типа ведущий — ведомый.

Д.и Функции, предоставляемые нижнем уровнем

Д. 1.2.1 Общие положение

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

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

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

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

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

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

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

• 2) прием данных. Отвечающее оборудование нижнего уровня оборудования отправляет блок(и) данных, содержащий данные ответа от соответствующего прикладного уровня, инициирующему оборудованию. Это относится к сервисам с подтверждением услуг передачи данных без установления соединения;

• 3) передача данных в отчет на запрос. Отвечающее оборудование нижнего уровня отправляет блок(и) данных. содержащие данные ответа от соответствующего прикладного уровня. Это относится к сервисам с подтверждением услуг передачи данных без установления соединения;

• 4) ответ о состоянии. Удаленное одноранговое оборудование отвечает индикацией состояния соответствующего их блока(ов) данных. Запрос состояния может быть сделан без сопровождающего информационного поля данных. Блок данных ответа может не иметь информационного поля данных. Информация состояния должна включать следующую информацию: отправляется ли ответ в ответ на соответствующий запрос; и доступен ли запрашиваемый ответ:

• 5) подтверждение уровня 2(АСК). Подтверждение канального уровня представляет собой запрос о том. что канальный уровень выполняет функцию подтверждения, при передаче соответствующего передается блок данных, к которой (функции) он (блок) применяется. Подтверждение уровня 2 может состоять из переданного ответного блока данных сгенерированного канальным уровнем в ответ на блок передаваемых данных, включающий в себя запрос подтверждение уровня 2. Блок данных ответа подтверждения может указывать, был ли блок с действительной FCS (проверкой последовательностью кадров) данных принят верно. Если блок данных был принят зерно, ответ может быть определен положительно или АСК (см рисунок ДЗ).

Разрешаются следующие дополнительные функции;

• 6) периодическая ретрансляция. Это специальная форма сервиса передачи бпока(ов) данных, в которой канал передачи данных периодически повторяет блок передаваемых данных. Частота повторения должна быть предоставлена нижнему уровню. Частота повторения, равная нулю, служит для прекращения передачи. Когда от-36

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

7) определения адреса. Нижний уровень различает публичную и частную адресацию

Д.1.2.2 Общие услуги

Общие услуги - это возможности, предлагаемые пользователю службы (прикладной уровень L7) от поставщика услуг [нижний уровень (канальный уровень L2>] для предоставления функций сервиса в качестве передачи информации от инициализирующего оборудования к удаленному или обратно (см. таблицу Д.1).

Рисунок Д.1 показывает отношения (последовательная схема) между данными логическими сервисами.

Таблица Д.1 — Функциональные сервисы

АР L7 12 12 L7 Я»

Рисунок Д.1 — Отношения между общими службами

Д.2 Сервисные примитивы нижнего уровня

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

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

• • DL-UNITDATA.request without response request (запрос блока данных без запроса ответа).

• • DL-UNITDATA.request with response request (запрос блока данных с запросом ответа),

• • DL-UNITDATA.request wait response request (запрос блока данных, ожидая ответ на запрос).

• • DL-UNITDATA.indicatron (указание блока данных).

• • DL-OATA-ACK.request (запрос даншх ответа),

• • DL-OATA-ACK.ind>cation (указание данных ответа).

• • DL-DATA-ACK-STATUS.indication (указание статуса данных ответа).

• • DL-REPLY.request (запрос повтора).

• • DL-REPLY.>ndicalion (указаюю повтора).

• • DL-REPLY-STATUS.ind>cation (указание статуса ответа).

• • DL-REPLY-UPDATE.request (запрос обновления ответа), и

• • DL-REPLY-UPDATE-STATUS.ind*cation (указание статуса обновления ответа):

б) У примитивов есть три типа сервисов: запрос, указание и подтверждение. К ним относятся:

• • DATASEND_NORESPOND (запрос отправки данных без ответа), и

• • DATASEND_NORESPOND_REPEAT (повтор запроса отправки данных без ответа):

в) У примитивов есть полный набор сервисных успут: запрос, указание, ответ, подтверждение. К ним относятся:

• • DATASEND_RESPOND (ответ на запрос данных).

• • DATASEND_RESPOND_REPEAT (повторный запрос отправки данных).

• • SEND_BST_RESPOND (запрос отправки СТР), и

• • SEND_BST_RESPOND_REPEAT (повторный запрос отправки СТР).

Примечание — Принципиально у прикытивов есть специальные FlowControl-лараметры. описанные в 6.2.4 и разделе 8.

Рисунок Д.2 — Услуга передачи данных без подтверждения

Рисунок Д.З — Услуга передачи данных с подтверждением

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

УДК 654.02:006.354

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

Редактор Л.В. Каретникова Технический редактор В.Н. Прусакова Корректор O.S. Лазарева Компьютерная верстка Е.О. Асташина

Сдано а набор 21.10.2020 Подписано в почать 24.11.2020. Формат вО’64¹^ Гарнитура Ариал Усп. пем. л. 5.12. Уч.-иад. л. 4,25

Подготовлено на основе электронной ворсим, предоставленной разработчиком стандарта

Создано в единичном исполнении во . 117418 Моссва. Наяиыовский пр-т. д. 31. к. 2.

www.gosbnfo.ruinioQgosbnfo.ru