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

        ПНСТ 462-2020

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

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

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

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

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

ОКС 43.040.15

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

до 2024-06-01

Предисловие

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

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

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

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

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

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

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

Введение

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

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

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

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

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.8 элемент: Связный набор данных и функциональности.

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

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

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

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

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 Сокращения

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

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

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

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

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

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

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

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

B-Kernel - ядро широковещания;

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

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

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

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

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

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

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

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

l-Kernel - ядро инициализации;

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

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

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

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

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

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

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

MAC - управление доступом к среде;

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

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

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

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

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

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

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

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

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

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

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

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

T-Kernel - ядро передачи;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2 Сервисы

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

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

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

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

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

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

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

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

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

- GET.request;

- GET.indication;

- GET.responce;

- GET.confirm;

- 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 показана схема использования сервисов без подтверждения.

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

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

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

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

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

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

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

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

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

Таблица 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-Kernel на стороне приемника для передачи индикации или подтверждения адресуемому элементу. В случае если IID используется в запросе, то элемент, вызывающий ответ, должен использовать этот IID в качестве EID.

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

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

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

Atrib.List должен быть последовательностью атрибутов, посылаемых примитивами Set.request/SET.indication или GET.response/GET.confirm. Элемент, принимающий SET.indication, должен модифицировать значения атрибутов, указанных в списке AtriblD.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, отображают процесс преобразования.

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

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

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

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

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

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

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

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

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

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

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

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

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

Ядро T-Kernel должно фрагментировать закодированные блоки данных протокола передачи прикладного уровня (T-APDU) до фрагментов T-APDU, которые включают в себя заголовок фрагментации. Заголовок фрагментации должен иметь длину не менее 1 октета и не более 3 октетов. Длина фрагмента T-APDU не должна превышать максимальную длину фрейма LLC. Количество битов внутри фрагмента должно быть кратно 8 битам. Все фрагменты, кроме последнего, должны иметь одинаковую длину. Фрагментация должна быть выполнена от наиболее значимого бита до наименее значимого бита в соответствии с ASN.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 Индикатор фрагментации

5.2.8.4 Номер PDU

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

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

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

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

Рисунок 10 - Фрагментация

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

Ядро Т должно мультиплексировать фрагменты T-APDU в соответствии со стратегией "Начало очереди", где приоритеты задаются ядром l-Kernel (см. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Ядро T-Kernel должно демультиплексировать 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, отбрасываются.

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

Рисунок 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) Он должен искать завершающие октеты и предполагать, что эти оставшиеся октеты содержат еще один одиночный T-APDU фрагмент.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.2 Сервисы

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

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

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

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

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

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

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

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

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

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

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

Таблица 9 - Инициализация сервиса RegisterApplicationOBU

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

Таблица 11 - Инициализация сервиса NotifyApplicationRSU

Таблица 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-Kernel должно предоставить сервисы 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-Kernel со следующими настройками: параметр инициализации = BST. Время между последующими передачами BST является задачей реализации системы и находится за пределами области применения этого стандарта.

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

6.3.2.1 Причина

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

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

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

а) BeaconID отличается от последнего полученного BeaconID,

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

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

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

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

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

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

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

- RSU = BeaconID, указанный в BST;

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

- Link identifier = LID, выбранный ядром l-Kernel;

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

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

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

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

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

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

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

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

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

Ядро l-Kernel должно хранить ApplicationList VST вместе с LID, до тех пор, пока LID действителен.

6.3.3 RSU: ответ VST

6.3.3.1 Причина

Ядро l-Kernel 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, полученный в INITIALISATION.confirm;

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

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

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

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

6.3.4 RSU: RegisterApplicationRSU

6.3.4.1 Причина

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

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

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

6.3.5 OBU: RegisterApplicationOBU

6.3.5.1 Причина

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

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

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

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

6.3.6 OBU: DeregisterApplication

6.3.6.1 Причина

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

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

6.3.7 RSU: DeregisterApplication

6.3.7.1 Причина

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

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

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

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

6.3.8.1 Причина

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

При получении EndApplication ядро l-Kernel должно удалить приложение из сохраненного ApplicationList VST. Если список приложений пуст (то есть все приложения закончились), ядро l-Kernel передает задачу сброса на одноранговое ядро l-Kernel. Оно должен* использовать службу EVENT-REPORT.request ядра T-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-Kernel получает сброс посредством сервиса EVENT-REPORT.indication ядра T-Kernel с параметрами:

- 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-Kernel должно удалить VST, относящееся к LID. Данный LID больше не действует.

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

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

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

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

Ядро B-Kernel должно осуществлять связь, отправляя BroadcastPool, определенный в приложении А.

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

7.2 Сервисы

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

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

- 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-Kernel должно предоставлять примитив 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-Kernel со следующими настройками параметров:

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

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

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

- режим = FALSE;

- FlowControl = 1.

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

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

7.3.2.1 Причина

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

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

- список атрибутов = (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-Kernel должно вставить файл NamedFile в содержимое BroadcastPool и FileName в каталог.

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

7.3.4 OBU: GetBroadcastData.request

7.3.4.1 Причина

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

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

Ядро B-Kernel должно извлечь файл с заданным 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 и присвоения значений доступны по адресу http://www.tc278.eu/;

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

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

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

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

Рисунок 18 - Оценивание BST

8.2.2 IEEE/ASTM International

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

Примечания

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

2 ASTM International см. на сайте http://www.astm.org.

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

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

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

См. [8].

8.2.3 ARIB

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

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

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

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

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

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

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

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

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

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

Время между последним полученным BST и текущим полученным 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 (см. http://www.arib.or.jp или http://www.arib или jp/english/).

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

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

Приложение А

(обязательное)

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

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

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

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

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

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

DSRCData {iso(1) standard(0) src(15628) dsrcData(0) version (1)} DEFINITIONS

AUTOMATIC TAGS::= BEGIN

-- ИМПОРТ

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

-- Type 1, Type2 FROM ModuleA;

-- где:

-- - Type1 и Type2 должны быть заменены на названия типов, которые будут импортированы.

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

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

Action-Request::=SEQUENCE{

mode BOOLEAN,

eid Dsrc-EID,

actionType ActionType,

accessCredentials OCTET STRING (SIZE (0..127,...))

OPTIONAL,

actionParameter

Cotainer OPTIONAL, iid Dsrc-EID OPTIONAL

}

Action-Response::=SEQUENCE{

fill BIT STRING (SIZE(1)),

eid Dsrc-EID,

ReturnStatus

OPTIONAL}

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

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

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

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

-- 1 : setStamped (задать ярлык)

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

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

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

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

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

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

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

-- 9 : сору (копировать)

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

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

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

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

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

-- 15 : echo (эхо)

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

ApplicationContextMark::=Container - OCTET STRING (SIZE(0..127,...))

-- Пример ApplicationContextMark

-- может быть найден в ИСО 14906, как "EFC-ContextMark"

ApplicationList::=SEQUENCE (SIZE (0..127,...)) OF

SEQUENCE {

aid DSRCApplicationEntitylD,

eid Dsrc-EID OPTIONAL, parameter ApplicationContextMark OPTIONAL

}

AttributeldList::=SEQUENCE (SIZE(0.. 127,...)) OF INTEGER(0..127,...)

AttributeList::=SEQUENCE

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

Attributes::=SEQUENCE{

attributeld INTEGER

(0..127,...),

attributeValue Contaier

}

BeaconlD::=SEQUENCE{

Manufacturerid

INTEGER

(0..65535),

individualid

INTEGER

(0.. 134217727)

} - для регистрации идентификатора

производителя см. www.nen.nl/cen278

BroadcastPool::=SEQUENCE{

directoryvalue Directory,

content SEQUENCE (SIZE(0..127,...)) OF File

}

BST::=SEQUENCE{

rsu BeaconID,

time Time,

profile Profile,

mandApplications

ApplicationList,

nonmandApplications

ApplicationList OPTIONAL,

profileList SEQUENCE (SIZE(0..127,...)) OF

Profile

}

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

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

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

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

… - маркер расширения

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

-- componentName1 [i] ModuleA.Type1

-- где

-- - "componentName1" - уникальное имя для определения контейнера

-- - "i" зарегистрированный тег, выбранный из указанных выше диапазонов.

-- - "Type1" имя импортированного типа, а

-- "ModuleA" название модуля, из которого импортируется тип Type1.

-- Префикс "ModuleA" требуется только в случае конфликта имен,

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

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

}

Directory::=SEQUENCE

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

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

-- (22..28) зарезервированы для ИCO/CEN-DSRC-пpилoжeний

-- (29..30) зарезервированы для личного использования

-- 31 зарезервированы для ИCO/CEN-DSRC-приложений

}(0..31,...)

-- - Для дальнейшего стандартного использования определений в приложении

-- - см. Раздел 8.

-- - Например, приложение "electronic-fee-collection (1)"

-- - стандартизировано в ИСО 14906

Event-Report-Request::=SEQUENCE{

mode BOOLEAN,

eid Dsrc-EID,

eventType EventType,

accessCredentials OCTET STRING (SIZE(0..127,...)) OPTIONAL,

eventParameter Container OPTIONAL,

iid Dsrc-EID OPTIONAL

}

Event-Report-Response::=SEQUENCE{

fill BIT STRING (SIZE(2)),

eid Dsrc-EID,

iid Dsrc-EID OPTIONAL,

ret ReturnStatus 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 INTEGER(0..127,...)

}

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

Get-Request::=SEQUENCE{

fill BIT STRING (SIZE(1)),

eid Dsrc-EID,

accessCredentials OCTET STRING (SIZE(0..127,...)) OPTIONAL,

iid Dsrc-EID OPTIONAL,

attrldList AttributeldList OPTIONAL

}

Get-Response::=SEQUENCE{

fill BIT STRING (SIZE(1)),

eid Dsrc-EID,

iid Dsrc-EID OPTIONAL,

attributelist AttributeList OPTIONAL,

ret ReturnStatus OPTIONAL

}

Initialisation-Request::=BST

lnitialisation-Response::=VST

NamedFile::=SEQUENCE{

name FileName,

file File

}

-- NamedFile будет использоваться в T-Kernel с GetBroadcastData-Request,

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

ObeConfiguration::=SEQUENCE{

equipmentClass INTEGER(0..32767),

manufacturerlD INTEGER(0..65535),

obeStatus INTEGER(0..65535) OPTIONAL

}

Profile::=INTEGER(0..127,...)

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

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

Record::=CHOICE{ simple VisibleString,

}

ReturnStatus::=INTEGER{

noError (0),

accessDenied (1),

argumentError (2),

complexityLimitation (3),

processingFailure (4),

processing (5),

chainingError (6)

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

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

}(0..127,...)

Set-Request::=SEQUENCE{

fill BIT STRING (SIZE(1)),

mode BOOLEAN,

eid Dsrc-EID,

accessCredentials OCTET STRING (SIZE(0..127,...)) OPTIONAL,

attrList AttributeList,

iid Dsrc-EID OPTIONAL

}

Set-Response::=SEQUENCE{

fill BIT STRING (SIZE(2)),

eid Dsrc-EID,

iid Dsrc-EID OPTIONAL,

ret ReturnStatus OPTIONAL

}

Time::=INTEGER(0..4294967295)

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

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

T-APDUs::=CHOICE{

action-request [0] Action-Request

(Запрос действия),

action-response [1] Action-Response

(Ответ действия),

event-report-request [2] Event-Report-Request

(Запрос отчета о событии),

event-report-response [3] Event-Report-Response

(Ответ отчета о событии),

set-request [4] Set-Request

(Задать запрос),

set-response [5] Set-Response

(задать ответ),

get-request [6] Get-Request

(получить запрос),

get-response [7] Get-Response

(получить ответ),

initialisation-request [8] Initialisation-Request

(Запрос инициализации),

initialisation-response [9] Initialisation-Response

(Ответ инициализации)

}

VST:=SEQUENCE{

fill BIT STRING (SIZE(4)),

profile Profile,

applications ApplicationList,

obeConfiguration ObeConfiguration

}

END

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

dsrctransferData(1) version (1)}

DEFINITIONS::= BEGIN

IMPORTS T-APDUs

FROM DSRCData {iso(1) standard(0) dsrc(15628) dsrcData(0) version (1)};

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

Message::= T-APDUs --Сообщение передается при помощи связи DSRC;

END

Приложение Б

(обязательное)

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

Б.1 Введение

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

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

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

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

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

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

manufacturerlD: "ID производителя" - всемирный уникальный идентификатор производителей оборудования DSRC.

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

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

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

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

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

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

Примечание - NEN содержит список значений "ActionType" и "EventType", назначенных стандартами DSRC-приложений (см. http:/www.tc278.eu/)

Приложение В

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

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

В данном примере показано содержимое прикладного уровня обмена данными BST (сервисная таблица радиомаяка)/VST (сервисная таблица транспортного средства), которое определено в разделе 7, для приложения электронного сбора платежей.

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

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

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

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

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

Приложение Г

(обязательное)

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

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

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

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

Приложение Д

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- DL-REPLY.indication (указание повтора),

- DL-REPLY-STATUS.indication (указание статуса ответа),

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

- DL-REPLY-UPDATE-STATUS.indication (указание статуса обновления ответа);

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

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

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

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

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

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

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

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

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

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

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

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