Товары в корзине: 0 шт Оформить заказ
Стр. 1 

35 страниц

487.00 ₽

Купить ГОСТ Р 54708-2011 — бумажный документ с голограммой и синими печатями. подробнее

Распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО "ЦНТИ Нормоконтроль"

Наши цены ниже, чем в других местах, потому что мы работаем напрямую с поставщиками документов.

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

Относится к системе DRM, осуществляющей цифровое звуковое вещание в соответствии ETSI [1]. Стандарт устанавливает требования для распределения в системе DRM коммуникаций общего применения, подходящих для многоадресной передачи данных многим получателям (абонентам), использующим однонаправленные сети связи.

 Скачать PDF

Оглавление

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

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

3 Термины, определения, обозначения и сокращения

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

     4.1 Обзор системы

     4.2 Архитектура системы

     4.2.1 TAG элементы, AF пакеты и PFT фрагменты

5 TAG уровень

     5.1 TAG пакет

     5.1.1 Основные правила

     5.2 TAG элемент

     5.2.1 Иерархические TAG элементы - пример кодирования

     5.2.2 Специальные TAG элементы

     5.2.2.1 Тип протокола и версия, *prt

     5.2.2.1.1 Нумерация версий

     5.2.2.2 Фиктивное заполнение, *dmy

6 Уровень разделения на фреймы

     6.1 Структура AF пакета

     6.2 История версий

7 Уровень PFT

     7.1 Структура фрагмента PFT

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

     7.2.1 Известные значения

     7.2.2 Расчетные значения

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

     7.3.1 Код Рида-Соломона

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

     7.3.3 Транспортная адресация

     7.4 Процесс декодирования

     7.4.1 Синхронизация

     7.4.2 Транспортная адресация

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

     7.4.4 Декодирование Рида-Соломона

Приложение А (обязательное) Расчет слова СЕС

Приложение Б (обязательное) Физическое отображение

     Б.1 Пакетные связи

     Б.1.1 UDO/IP

     Б.2 Потоковые связи

     Б.3 Файл

     Б.3.1 Файл IO(fiо_)

     В.3.1.1 IDCP через UDP/IР

     В.3.1.2 Метка времени (time)

Приложение В (справочное) Сигнализация основных уровней передачи и параметров

     В.1 DCP через UDP/IP

     В.2 DCP через транспарентные (последовательные) каналы связи

     В.3 DCP в/из файла с использованием файла IO

     В.4 DCP через TCP/IP

Приложение Г (обязательное) DCP профили и DCP параметры

     Г.1 Определения профилей DCP

     Г.1.1 Профиль А DCP

     Г.1.2 Профиль В DCP

     Г.1.3 Профиль С DCP

     Г.2 Определения параметров DCP

     Г.2.1 AFRevision

     Г.2.2 AFMaxLen

     Г.2.3 PFTMaxLen

     Г.2.4 PFTMaxFragCnt

     Г.2.5 PFTMaxAFFragCache

Приложение Д (справочное) Рекомендации по реализации DCP

     Д.1 Используемый интерфейс

     Д.2 Переупорядочение AF пакетов

     Д.3 Ошибочное поведение

Приложение Е (справочное) DCP структура двунаправленной связи

     Е.1 Типовые требования связи

     Е.1.1 Транзакции

     Е.1.2 Классы транзакций

     Е.1.2.1 Транзакция передачи

     Е.1.2.2 Транзакция выборки

     Е.1.2.3 Транзакция подписки/отказа от подписки

     Е.2 DCP пакет сообщения

     Е.2.1 Общая структура

     Е.2.2 Типы транзакций

     Е.2.2.1 Транзакция передачи

     Е.2.2.2 Транзакция выборки

     Е.2.2.3 Транзакция подписки/отказа от подписки. Транзакция доставки

     Е.2.3 Поле флага типа ответа

     Е.2.4 данные команды

     Е.2.4.1 Поле данных команды, несущее полный TAG пакет

     Е.2.4.2 Связанные данные команды в главном уровне иерархии пакета сообщения

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

 
Дата введения01.09.2012
Добавлен в базу01.09.2013
Актуализация01.01.2021

Этот ГОСТ находится в:

Организации:

13.12.2011УтвержденРосстандарт869-ст
РазработанФГУП ВНИИНМАШ
РазработанФилиал ФГУП НИИР - СОНИИР
ИзданСтандартинформ2012 г.

Digital audio broadcasting system DRM. Distribution and communication protocol (DCP)

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30

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

ГОСТР

54708-

2011

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

СИСТЕМА ЦИФРОВОГО ЗВУКОВОГО РАДИОВЕЩАНИЯ DRM

Протокол распределения и коммуникации (DCP)

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

Москва

Стандартинформ

2012


Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации — ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения»

Сведения о стандарте

1    РАЗРАБОТАН Федеральным государственным унитарным предприятием «Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении» (ФГУП «ВНИИНМАШ») и Федеральным государственным унитарным предприятием «Ордена Трудового Красного Знамени научно-исследовательский институт радио, Самарский филиал «Самарское отделение научно-исследовательского института радио» (филиал ФГУП «НИИР-СОНИИР»)

2    ВНЕСЕН Управлением технического регулирования и стандартизации Федерального агентства по техническому регулированию и метрологии

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

4    Настоящий стандарт разработан с учетом основных нормативных положений документа Европейского института по стандартизации в области телекоммуникаций (ЕТСИ) «Всемирное цифровое радио (DRM). Протокол распределения и коммуникации (DCP)» (ETSI TS 102 821 vl .3.1 (2010—12) «Digital Radio Mondiale (DRM); Distribution and Communications Protocol (DCP)»)

5    ВВЕДЕН ВПЕРВЫЕ

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

© Стандартинформ, 2012

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

ГОСТ P 54708—2011

TAG пакет

TAG

элемент

TAG

элемент

TAG

элемент

^ ^

TAG

название

TAG

длина

TAG значение

TAG пакет

TAG

элемент

TAG

элемент

TAG

элемент

Заполнение TAG пакета

TAG

название

TAG

длина

TAG значение

«Щ»

TAG пакет

TAG

элемент

TAG

элемент

TAG

элемент

Заполнение TAG пакета

«*■*

---

—__^

TAG

название

TAG

длина

TAG значение

Заполнение TAG элемента

Рисунок 6 — Иерархические TAG элементы

TAG пакет верхнего уровня содержит TAG элементы ...

... но каждый TAG элемент может содержать полный TAG пакет, который, в свою очередь содержит дополнительные TAG элементы ...

...и так далее для многих уровней, как требуется по приложению

5.2.2 Специальные TAG элементы

Каждое приложение может свободно определить соответствующие названия TAG элементов, единственное исключение — все названия, начинающиеся с символа ASCII “*”, 42 (десятичное число) или 2А16, зарезервированы какуправляющиеТАв элементы.

5.2.2.1 Тип протокола и версия, *ptr

Каждое приложение, использующее DCP, должно объявить тип протокола и версию в каждом TAG пакете, используя TAG элемент *ptr, как показано на рисунке 7.

TAG название    TAG    длина    TAG    значение

ASCir*ptr"

64 бита

Наименование

протокола

Версия протокола

*

Р

t

г

со

о"

о

со

о"

О

со

о"

о

4016

например, ASCII

старший

младший

4 байта

4 байта

4 байта

2 байта

2 байта

Рисунок 7 — Тип протокола и версия

Тип протокола: наименование протокола. Как правило, это будет кодироваться с использованием значений кода ASCII в диапазоне от 2000 до 7F16, но значения вне этого диапазона могут при желании использоваться.

Старшая версия: двоичный счетчик, представляющий старший номер версии протокола, начинающийся от000016.

6


Младшая версия: двоичный счетчик, представляющий младший номер версии протокола, начинающийся от 000016.

TAG элемент *ptr не требует заполнения TAG элемента.

5.2.2.1.1 Нумерация версий

Каждому приложению разрешено использовать любую нумерацию версий в соответствии с требованиями, однако рекомендуется, чтобы версии были совместимы с ближайшими предыдущими версиями. Таким образом, реализация, осуществляя версию 4.3 протокола WXYZ, должна быть в состоянии декодировать версии 4.0, 4.1 и 4.2 в дополнение к 4.3, но не обязательно должна поддерживать версию 3.1 или 5.0. Дополнительно пакеты версии 4.5 должны быть обработаны, как будто они были версией 4.3 с любыми новыми особенностями, добавленными в проигнорированной версии 4.4 или 4.5.

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

5.2.2.2 Фиктивное заполнение, *dmy

Чтобы обеспечить выравнивание слова, когда это необходимо, TAG элемент *dmy позволяет вставить в TAG пакет больше 8 байтов заполнения (неопределенные данные): если требуется заполнение меньше 8 байтов, то будет использоваться обычное заполнение TAG пакета (рисунок 8).


Заполнение

TAG название    TAG    длина    TAG    значение    TAG    элемента

*

d

m

У

Длина TAG значение (в битах)

Неопределенные данные

Как

требуется

4 байта

4 байта

Переменная длина

< 8 битов

Рисунок 8 — Фиктивное заполнение TAG элемента


6 Уровень разделения на фреймы

AF уровень инкапсулирует одиночный TAG пакет в простую структуру, которая является подходящей для прохождения между оборудованием, связанным каналами связи без ошибок. Такие каналы связи можно обеспечить сетями, такими как TCP/IP или PFT уровня, описанные в разделе 7.

6.1 Структура AF пакета

Базовая структура AF пакета приведена на рисунке 9.


AF заголовок

Полезная нагрузка

CRC

10 байтов

LEN байтов

2 байта



SYNC

LEN

SEQ

AR

РТ

2 байта

4 байта

2 байта

( 1 байт

1 байт


CF

MAJ

MIN

1 бит

3 бита

4 бита

Рисунок 9 — AF уровень


7


SYNC (синхронизация): двухбайтовое представление “AF” в коде ASCII.

LEN: длина полезной нагрузки в байтах.

SEQ: порядковый номер. Каждый посланный AF пакет должен увеличить порядковый номер на единицу независимо от контента (содержания). Не должно быть никакого требования, чтобы первый полученный пакет имел определенную величину. Счетчик делает свертку от FFFF16 до 000016, таким образом величина будет принимать значения FFFE16, FFFF16, 000016, 000116 и т. д.

AR: пересмотр AF протокола — область, комбинирующая CF, MAJ и MIN поля.

CF: CRC флаг: имеет значение 0, если CRC поле не используется (CRC значение должно быть 000016) или 1, если CRC поле включает действительный CRC.

MAJ: используется старший пересмотр AF протокола (см. 6.2).

MIN: используется младший пересмотр AF протокола (см. 6.2).

РТ (тип протокола): один байт, кодирующий протокол данных, переносимых в полезной нагрузке. Для TAG пакетов, значение в коде ASCII представляется как«Т».

CRC: CRC рассчитывается, как описано в приложении А, по nontoAF заголовка и полезной нагрузки, если поле CF есть 1, в противном случае (CF равно нулю) CRC значение равно 000016.

6.2 История версий

История версий AF протокола приведена в таблице 1.

Таблица 1 — История версий

Старшая версия

Младшая версия

Дата

Изменения

Olie

О

о

ст>

2003—01—28

Начальный публичный выпуск

7 Уровень PFT

Уровень PFT (дополнительная защита, фрагментация и транспортировка) осуществляет согласно названиютриотдельные функции. Первая — защита от ошибоксиспользованием кода Рида-Соломона, который может обнаруживать и исправлять индивидуальные битовые ошибки, а также восстанавливать целые потерянные пакеты. Вторая — фрагментация, разделение больших пакетов на меньшие части, подходящие для каналов передачи данных и которые предписываются ниже MTU. Наконец, уровень PFT позволяет использовать такую ограниченную форму адресации транспортировки, чтобы те нижние уровни, которые не включают адресацию (например, RS-232 для последовательных связей), могли бы использоваться с многократными транспортными потоками. Совсем не обязательно, чтобы все три функции использовались одновременно, и использование дополнительных полей заголовка минимизирует затраты, когда определенных требований не предъявляется.

Разрешены следующие сочетания:

-    инкапсулирование;

-    простая фрагментация;

-    использование кода Рида-Соломона с FEC и фрагментация.

Кроме того, каждое из вышеупомянутых трех сочетаний может быть объединено при желании с адресацией транспортировки. Эти варианты представлены на рисунке 10.

8

AF пакет



Инкапсули

рование

Транспор

тировка

Фрагмен

тация

Фрагментация и транспортировка

Код Рида -Соломона

Код Рида -Соломона и транспортировка

Код Рида-Соломона, пакет

PFT фрагмент(ы)

Рисунок 10 — Доступные опции с использованием уровня PFT


7.1 Структура фрагмента PFT

Структура фрагмента PFT представлена на рисунке 11.

Psync: ASCII строка “PF” используется как слово синхронизации для уровня PFT.

Pseq: 16-битовый счетчик, увеличивающийся на единицу с каждым полученным AF пакетом. Значение должно быть в пределах от 216—1 до 0, например...., 216—2, 216—1,0,1 Приемник не должен

ожидать определенное значение в первом полученном фрагменте. Значение поля Pseq не имеет никакой связи со значением поля SEQ AF пакетов.


PFT заголовок

Полезная нагрузка

14, 16, 18 или 20 байтов (в зависимости от опции)

Plen, байты

Когда FEC = 1


Опционально RS заголовок

Psync

Pseq

Findex

Fcount

FEC

Addr

Plen

RSk

RSz

Source

Dest

HCRC

16 битов

16 битов

24 бита

24 бита

1 бит

1 бит

14 битов

8 битов

8 битов

16 битов

16 битов

16 битов

Когда Add г = 1

Опционально

заголовок

транспорта


■т

I


Рисунок 11 — Фрагмент PFT


9


Findex: 24-битовый счетчик, увеличивающийся на единицу с каждым фрагментом, который является частью единого AF пакета. Первый фрагмент из каждого AF пакета должен иметь значение нуль. Это значение не должно свертываться, налагая таким образом предел на максимальный размер AF пакета, который может быть перенесен. Максимальный размер может изменяться в зависимости от максимального блока данных (MTU) связи, но обычно составляет несколько гигабайтов.

Fcount: число фрагментов, полученных из данного AF пакета, в диапазоне от 1 до224—1. Значение нуль не должно использоваться.

FEC: когда этот однобитовый флаг установлен на 1, то дополнительный RS заголовок присутствует.

Addr: когда этот однобитовый флаг установлен на 1, то дополнительный транспортный заголовок присутствует.

Plen: длина, в байтах, полезной нагрузки этого фрагмента.

RSk: длина слова данных кода Рида-Соломона — см. 7.2.2. Представлено только для случая, когда поле FEC равно 1.

RSz: число байтов заполнения в последнем блоке кода Рида-Соломона — см. 7.2.2. Представлено только для случая, когда поле FEC равно 1.

Source: свободный формат 16-битового идентификатора источника. Представлено для случая, когда поле Addr равно 1.

Dest: свободный формат 16-битового идентификатора предназначения. Представлено для случая, когда поле Addr равно 1.

HCRC: PFT заголовок CRC, рассчитанный через поля PFT заголовка от Psync, включая любой опциональный заголовок. CRC должен быть рассчитан, как описано в приложении А.

Когда FEC и Аббгустановлены на 1 (когда оба опциональных заголовка присутствуют), эти два заголовка должны появляться в порядке, приведенном на рисунке 11.

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

Далее по всему тексту стандарта должны применяться следующие определения.

7.2.1    Известные значения

/ — общая длина оригинального AF пакета, включающая заголовок и CRC;

тах — максимальное значение к, имеющее значение 207;

р — число байтов четности кода Рида-Соломона в фрагменте, имеющее значение 48;

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

MTU — максимальный передаваемый размер блока (в байтах) для основного транспортного уровня. Когда транспортный уровень не имеет никакого MTU и когда MTUбольше чем 214, тогда значение MTU должно быть 214;

h — длина заголовка PFT в байтах. Значения должны быть 12,14,16 или 18 байтов в зависимости от вариантов использования.

7.2.2    Расчетные значения

с — число фрагментов Рида-Соломона (фиксируется как нуль, если код Рида-Соломона не используется);

к — длина данных каждого фрагмента, передается в поле RSk заголовка PFT (нуль, если код Рида-Соломона не используется);

z — число нулевых байтов, добавленных к последнему фрагменту Рида-Соломона, передается в поле RSz заголовка PFT (нуль, если код Рида-Соломона не используется);

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

f— число фрагментов, переносимых в поле Fcount PFT заголовка;

s — действительная величина фрагмента (ов), в байтах;

L — длина (в байтах) пакета, который будет фрагментирован. Когда код Рида-Соломона используется, L имеет величину f- s, если нет, то /.

с =


/

"max


к =


-1 ■ с



(1)

(2)


(3)


Smax = MIN


с_р

т


MTU-h


для m > 0;


(4)


Smax = MTU - h    для    гп    =    0;

l + c-p+z .

®max

l + c-p+z

S =     .

f


(5)

(6)

(7)


Примечание — В предыдущей версии настоящего стандарта алгоритм расчета smax для случая (т > 0) определялся следующим образом


Smax = MIN


С-Р т +1


, MTU-h


Следствием этой формулы является то, что даже при низких степенях защиты т = 1 (т. е. предназначенных для защиты от потери одного фрагмента) DCP кодер генерировал большее количество фрагментов, чем технически было необходимо, a DCP декодер исправлял два фрагмента вместо необходимого одного фрагмента. Кроме того, для каждого более высокого значения т еще один потерянный фрагмент, чем указанное значение т, могло быть восстановлено DCP декодером за счет неоправданно большого количества сгенерированных фрагментов.

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

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

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

7.3.1 Код Рида-Соломона

Оригинальный пакет сначала делится на с фрагментов Рида-Соломона по /с-байтов каждый; z нулевых байтов заполнения добавляются к последнему фрагменту при необходимости. Четные байты Рида-Соломона тогда рассчитываются и добавляются к каждому фрагменту, и полученный RS блок подвергается перемежению до формы RS пакета. Схематически это показано на рисунке 12.

Полный код Рида-Соломона должен быть RS (255, 207), вычисленный через поле Галуа (Galois Field GF) (28) с использованием полиномиального генератора

Р(х) = х8 + х4 + х3 + х2 + 1.

Когда расчетное значение для к меньше чем 207, байты к до 206 (включительно), закодированные RS (255, 207) кодом, должны все быть равны нулю и не должны быть включены в результирующий RS блок, таким образом производя RS (к + р, к) код.

Полиномиальный код должен быть

48

е(х) = П (*-<*')■    (8)

/=1


Байты /сданных и р проверочные байты кода Рида-Соломона отражаются как коэффициенты соответствующих полиномиалов в порядке уменьшения степени х. Если порядок байтов данных в RS блоке— от d0 до dk_v сопровождаемому проверочными байтами от rs0 до rsp_v то от d0 до dk_ 1 — коэффициенты от х254 до х255~к соответственно, йот rs0 до rsp_ 1 — коэффициенты от хр~ ''дох0 в кодовом слове полинома, который имеет G(x) как фактор.


11


ГОСТ P 54708—2011

AF пакет

Z |

i /байтов

! /-(с-1)./сба 1 I 1

йтов

г

Данные

Данные

Данные

Заполнение

RS фрагмент 1

RS фрагмент 2

RS фрагмент с

Оригинальные данные

Шаг 1:

к байтов

Р э

к байтов

* \

Р ^

к байтов

Р

RS фрагмент 1

RS

Р1

RS фрагмент 2

RS

Р2

RS фрагмент С

RS

Рс

V_)

_J

к_/

TZJ

1^

/+ (с.р) + z байтов

1 1

RS блок

0 1 2

Z+cp+z-3 Z+cp+z-2 /+cp+z-1

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

Шаг 2:

Добавление р байтов четности Рида-Соломона (RS Рп) к каждому фрагменту

Шаг 3:

Объединение с RS фрагментов (включая четные) в единый RS блок

I


Шаг 4:

Запись данных в перемежающее множество в порядке; слева направо и сверху вниз, заполняя неиспользованные элементы в нижнем ряду нулями, если необходимо (заштриховано)

1 udHiue

0

1

f-2

M

s байтов

f

f+ 1

2f-2

2f-1

2 f

2 f+ 1

3f-2

3f-1

(s-2)f

(s- 2)f + 1

(s- 1)f-2

(s-l)f-l

(•-i )f

(s -1 )f + 1

°°16

°°16


*

'

2f

...

(s-2 У

(s-1 У

'

f+ 1

...

(s-1)f-2

00,6

...

(s-l)f-l

00

16

RS пакет

i{=L) байтов

Шаг 5:

Чтение данных перемежающего множества в порядке: сверху вниз, слева направо, рекомбинация данных в один RS пакет

Рисунок 12 — Формирование пакета Рида-Соломона

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

Фрагментация может быть применена непосредственно к AF пакету или к предварительно обработанному RS пакету. Фрагментация разделяет данные оригинального AF или RS пакета на множество отдельных фрагментов. Когда передается перемежеванный пакет Рида-Соломона, до т этих фрагментов может быть потеряно из каждого пакета без потери данных. Процесс фрагментации показан схематически на рисунке 13.



*

Фрагмент 0

Фрагмент п

Фрагмент М

0 ... s-1

®start(^' ®) ^ ®)

s(M)... L-1

sбайтов

s байтов

<= s байтов

Bs,JnL's) = n-s;

Be Jn, L, s) = MIN [s (n + 1)- 1, L- 1].

(9) (10)

Рисунок 13 — Фрагментация AF или RS пакета

Каждый фрагмент PFT, сформированный из одного AF или RS пакета, должен иметь те же самые значения во всех полях заголовка PFT, за исключением полей Findex, Plen и HCRC.

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

Поле Plen всех фрагментов должно иметь величину s для начальных f- 1 фрагментов и s-(/_%f) (оператор модуля) для финального фрагмента. Когда используется код Рида-Соломона, все фрагменты будут иметь длину s.

Поле HCRC должно быть вычислено правильно для каждого фрагмента PFT.

7.3.3 Транспортная адресация

Поля адресации Source и Dest уровня PFT предназначены, чтобы использоваться при идентификации отправителя (Source) и получателя (Dest) пакета. Значение FFFF16 должно использоваться, чтобы указать “передачу”, все другие значения указывают определенный адрес. Если устройство конфигурировано с определенным источником и/или адресами назначения, то должны игнорироваться все фрагменты PFT, принятые с неправильным невещательным адресом.

7.4 Процесс декодирования

Процесс декодирования PFT фрагментов состоит из 4 стадий в следующем порядке:

1)    синхронизация;

2)    отказ от неправильно адресованных фрагментов (если транспортная адресация позволяет);

3)    дефрагментация (если используется код Рида-Соломона либо простая фрагментация);

4)    код Рида-Соломона обнаруживает и исправляет ошибки (если код Рида-Соломона разрешен).

7.4.1 Синхронизация

Для потоковых каналов связи (например, асинхронный последовательный или TCP/IP) должны использоваться следующие процессы для синхронизации поступающего потока; синхронизация может также применяться при чтении файла:

1)    обнаружение битовой комбинации 01010000010001102 (504616), соответствующей синхронизирующему слову “PF” в коде ASCII, чтобы найти начало заголовка PFT кандидата;

2)    вычисление CRC по заголовку кандидата — это может быть выполнено эффективно непрерывной байтовой реализацией CRC, используя тот факт, что CRC заголовка PFT, включающее поле CRC, будет иметь постоянное значение 1D0F16;

3)    проверка длины заголовка, которая соответствует отобранным вариантам: если слишком короткая — продолжите от шага (2), если слишком длинная, возвратитесь к шагу (1), если соответствует, синхронизация была достигнута и поле Plen может использоваться, чтобы определить длину фрагмента.

13

Для пакетных каналов связи (например, UDP/IP) понятие синхронизации не нужно, поскольку транспортный протокол будет предъявлять полные фрагменты уровню PFT. Необходимо только проверить, что CRC и длина пакета правильны перед передачей пакета для дальнейшей обработки. Когда CRC и длина неправильны, пакет считается поврежденным и может не учитываться.

7.4.2    Транспортная адресация

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

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

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

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

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

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

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

продолжительных потерь связи.

Примечание 2 — PFT фрагменты, которые совпадают с ранее полученными PFT фрагментами и затем собранными в AF пакеты, должны быть отброшены.

7.4.4    Декодирование Рида-Соломона

Декодирование Рида-Соломона — процесс, обратный кодированию.

Длина RS пакета может быть рассчитана следующим образом:

Стах

f S к + р\

^Xmin

стах'Р

S

где f— число фрагментов, полученных из этого пакета, несущего поле с заголовком Fcount;

s — размере байтах фрагментов PFT, переносимых в поле заголовка Plen всех фрагментов, за исключением последнего фрагмента (где Fcount равняется [Findex- 1]); к — размер данных в байтах кода Рида-Соломона, переносимых в поле заголовка RSk; р — число байтов четности кода Рида-Соломона, должно иметь значение 48; стах — максимальное число фрагментов кода Рида-Соломона, которые могут быть посланы;

Rxmin — минимальное число фрагментов, которые должны быть получены, прежде чем может быть начато декодирование кода Рида-Соломона. Дополнительные фрагменты могут потребоваться, если произошли ошибки или если один из полученных фрагментов является последним.

Rxmin PFT фрагментов могут быть получены один раз, оставшиеся байты могут быть заполнены нулями и предпринята попытка декодирования кода Рида-Соломона с успешным получением неискаженного AF пакета с помощью правильного CRC.

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

Байты заполнения, добавленные в течение процесса перемежения кода Рида-Соломона, могут в результате привести к большему количеству восстановленных данных, чем первоначально передавалось для очень больших пакетов. Эти дополнительные данные все будут нулями, и могут быть дифференцированы, начиная с z нулевых байтов, добавленных при шифровании кодом Рида-Соломона, используя значение поля заголовка RSz (z — число байтов заполнения кода Рида-Соломона, переносимых в поле заголовка RSz (z— число байтов заполнения кода Рида-Соломона, переносимых в поле заголовка RSz). Размер конечного AF пакета может быть определен из поля LEN AF.

ГОСТ Р 54708-2011

Приложение A (обязательное)

Расчет слова CRC

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

CRC код определяется полиномом в степени п:

G(x) = х" + g^x"-1 + ... + д2х2 + д,х + 1,

где: п > 1.

д,- е {0,1}, / = 1 ... п - 1.

Расчет CRC может быть выполнен посредством сдвигового регистра, содержащего п ступеней, эквивалентных степени полинома (см. рисунок А. 1). Ступени обозначены отЬ0 до Ьп _ 1, где Ь0 соответствует 1, Ь1 соответствует х, Ь2 соответствует х2, Ьп _ 1 соответствует хп ~1.

Сдвиговый регистр функционирует, включая элементы XORs (исключающее ИЛИ) на входах тех регистров, где корреспондирующий коэффициентд, полинома равен “1”.

В начале вычисления CRC все содержимое регистров калибруется одинаково.

После поступления на вход регистра первого бита блока данных (первый — MSb), сдвиговые тактовые импульсы заставляют регистр перемещать его содержимое вперед на одну ступень к MSb(bn_ в то же время загружая следующие ступени результатом соответствующих XOR операций. Процедура затем повторяется для каждого бита данных. Вслед за сдвигом после поступления на вход последнего бита (LSb) блока данных, сдвиговый регистр содержит слово CRC, которое затем считывается. Данные и CRC слова передаются, начиная с MSb.

CRC должен быть инвертирован (дополнен единицами) перед передачей.

Должен использоваться генератор полинома G(x) = х16 + х12 + х5 + 1.

Если CRC будет приложен к оригинальным данным, то второй CRC, рассчитанный по всей длине, приведет к постоянному значению 1D0F16.

15

ГОСТ Р 54708-2011

Содержание

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

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

3    Термины, определения, обозначения и сокращения...............................1

4    Общее описание.....................................................2

4.1    Обзор системы....................................................2

4.2    Архитектура системы................................................2

4.2.1    TAG элементы, AF пакеты и PFT фрагменты.............................4

5    TAG уровень........................................................4

5.1    TAG пакет.......................................................4

5.1.1    Основные правила.............................................5

5.2    TAG элемент.....................................................5

5.2.1    Иерархические TAG элементы — пример кодирования......................5

5.2.2    Специальные TAG элементы.......................................6

5.2.2.1    Тип протокола и версия, *ptr..................................6

5.2.2.1.1 Нумерация версий....................................7

5.2.2.2    Фиктивное заполнение, *dmy..................................7

6    Уровень разделения на фреймы...........................................7

6.1    Структура AF пакета................................................7

6.2    История версий...................................................8

7    Уровень PFT........................................................8

7.1    Структура фрагмента PFT.............................................9

7.2    Определения....................................................10

7.2.1    Известные значения............................................10

7.2.2    Расчетные значения............................................10

7.3    Кодирование....................................................11

7.3.1    Код Рида-Соломона............................................11

7.3.2    Фрагментация................................................12

7.3.3    Транспортная адресация.........................................13

7.4    Процесс декодирования.............................................13

7.4.1    Синхронизация...............................................13

7.4.2    Транспортная адресация.........................................14

7.4.3    Дефрагментация..............................................14

7.4.4    Декодирование Рида-Соломона....................................14

Приложение А (обязательное) Расчет слова CRC.................................15

Приложение Б (обязательное) Физическое отображение............................16

Б.1 Пакетные связи..................................................16

Б.1.1 UDP/IP....................................................16

Б.2 Потоковые связи..................................................16

Б.З Файл.........................................................16

Б.3.1 Файл 10 (fio_)................................................16

III

Приложение Б (обязательное)

Физическое отображение

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

Б.1 Пакетные связи

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

Б.1.1 UDP/IP

UDP/IP — одна из самых популярных сетей пакетной коммутации в настоящее время. PFT фрагменты и AF пакеты могут быть отображены точно в пакеты UDP /1Р, если предусмотреть соблюдение MTU уровня UDP/IP. PFT фрагментация или PFT фрагментация Рида-Соломона должна использоваться, чтобы гарантировать, что единственный исходный пакет не будет фрагментирован. Любой определенный IP транспортный интерфейс для UDP/IP может использоваться, включая (но не ограничивая), 10Base-T Ethernet или РРР (двухточечной) связи.

UDP/IP предоставляет источник и номера портов назначения, следовательно, необходимость использования дополнительного PFT транспортного заголовка маловероятна, однако его использование не запрещено.

UDP/IP не гарантирует доставку пакетов, следовательно использование заголовка PFT Рида-Соломона настоятельно рекомендуется, но не является обязательным.

Б.2 Потоковые связи

Потоковые коммуникации в этом контексте описывают любой тип не пакетных коммуникаций. Примерами таких коммуникаций служат асинхронные последовательные каналы связи, синхронные последовательные каналы связи и каналы связи TCP/IP. Отличительная особенность таких каналов состоит в том, что наивысшие уровни (например, AF или PFT уровень) обязаны устанавливать пакетную синхронизацию прежде, чем пытаться декодировать поток.

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

Для физических каналов, которые не гарантируют безошибочный прием, рекомендуется использование дополнительного механизма кода Рида-Соломона с FEC, обеспеченного PFT уровнем. Каналы типа TCP/IP гарантируют обеспечение безошибочной связи, не нуждающейся в использовании защитного кода Рида-Соломона, однако линии связи, использующие RS-232, могут быть подвержены ошибкам и, следовательно, использование дополнения в виде кода Рида-Соломона с FEC целесообразно.

Б.З Файл

PFT фрагменты или AF пакеты могут быть сохранены в виде файла для офлайнового распределения, архивации или любой другой цели. Стандартное отображение было определено путем использования опционально доступного иерархического TAG элемента, однако в будущем другие отображения могут быть определены, либо предложено использование его расширения. TAG элемент верхнего уровня имеет TAG название fio_ и используется для инкапсуляции TAG пакета, одна часть которого является AF пакетом или PFT фрагментом в TAG элементе afpf. Были определены дополнительные ТAG элементы, чтобы контролировать прием или управлять воспроизведением пакетов.

Б.3.1 Файл 10 (fio_) (рисунок Б.1)

TAG элемент “fio_” — самый высокий уровень TAG элемента в иерархии файлов TAG элементов.

Этот TAG элемент действует как контейнер для TAG элемента afpf. TAG элемент time (метка времени) может быть представлен опционально.

ГОСТ Р 54708-2011

Б.3.1.1 AF пакет/PFT фрагмент (afpf)...................................17

Б.3.1.2 Метка времени (time)........................................17

Приложение В (справочное) Сигнализация основных уровней передачи и параметров.........18

В.1    DCP через UDP/IP.................................................19

В.2 DCP через транспарентные (последовательные) каналы связи....................19

В.З DCP в/из файла с использованием файла 10................................19

В.4    DCP через TCP/IP.................................................20

Приложение Г (обязательное) DCP профили и DCP параметры........................21

Г.1    Определения профилей DCP..........................................21

Г. 1.1 Профиль A DCP..............................................21

Г. 1.2 Профиль В DCP..............................................21

Г. 1.3 Профиль С DCP..............................................21

Г.2    Определения параметров DCP.........................................21

Г.2.1 AFRevision..................................................21

Г.2.2 AFMaxLen..................................................21

Г.2.3 PFTMaxLen.................................................22

Г.2.4 PFTMaxFragCnt...............................................22

Г.2.5 PFTMaxAFFragCache...........................................22

Приложение Д (справочное)    Рекомендации по реализации DCP.......................23

Д.1    Используемый интерфейс............................................23

Д.2    Переупорядочение AF пакетов.........................................23

Д.З    Ошибочное поведение..............................................23

Приложение Е (справочное) DCP структура двунаправленной связи.....................24

Е.1    Типовые требования связи...........................................24

Е.1.1 Транзакции.................................................24

Е.1.2 Классы транзакций............................................24

Е.1.2.1 Транзакция передачи.......................................24

Е.1.2.2 Транзакция выборки.......................................25

Е.1.2.3 Транзакция подписки/отказа от подписки..........................25

Е.2    DCP пакет сообщения..............................................25

Е.2.1 Общая структура..............................................25

Е.2.2 Типы транзакций..............................................26

Е.2.2.1 Транзакция передачи (запрос “*tsq”, ответ “*tss”)......................26

Е.2.2.2 Транзакция выборки (запрос “*tfq”, ответ “*tfs”).......................26

Е.2.2.3 Транзакция подписки/отказа от подписки (запрос “*tuq”/“*tnq”, ответ “*tus”/“*tns”).

Транзакция доставки (запрос “*tdq”, ответ “*tds”)...........................27

Е.2.3 Поле флага типа ответа.........................................27

Е.2.4 Данные команды..............................................28

Е.2.4.1 Поле данных команды, несущее полный TAG пакет....................28

Е.2.4.2 Связанные данные команды в главном уровне иерархии пакета сообщения .... 28 Библиография........................................................30

IV

Введение

ETSITS 102 821 vl .3.1 (2010—12) создан Объединенным техническим комитетом (JTC) «Радиовещание» Европейского радиовещательного союза (EBU), Европейского комитета по стандартизации в электротехнике (CENELEC) и Европейского института по стандартизации в области телекоммуникаций (ETSI).

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

V

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

СИСТЕМА ЦИФРОВОГО ЗВУКОВОГО РАДИОВЕЩАНИЯ DRM

Протокол распределения и коммуникации (DCP)

Digital audio broadcasting system DRM.

Distribution and communication protocol (DCP)

Дата введения — 2012—09—01

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

Настоящий стандарт относится к системе DRM, осуществляющей цифровое звуковое вещание в соответствии ETSI [1].

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

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

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

3    Термины, определения, обозначения и сокращения

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

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

3.1.1    байт(Ьу1е): Совокупность из 8 битов.

3.1.2    протокол распределения и коммуникации (Distribution and Communication Protocol; DCP): Протокол связи транспортного уровня, предусматривающий фрагментацию, адресацию и/или надежную передачу данных по каналам с ошибками с использованием кода Рида-Соломона для обеспечения прямой коррекции ошибок.

3.1.3    разделение на фреймы (Application Framing; AF): Уровень DCP, обеспечивающий логическую группировку множества TAG элементов.

3.1.4    AF пакет (AF Packet): Совокупность TAG элементов с заголовком, несущая связанный и независимый блокданных.

3.1.5    TAG значение (TAG Value): Полезная нагрузка TAG элемента.

3.1.6    TAG название (TAG Name): Название поля в индивидуальном TAG элементе, используемое для идентификации индивидуальной части информации.

3.1.7    TAG пакет (TAG Packet): Набор TAG элементов, переносящий связанный и модульный блок данных.

3.1.8    TAG элемент (TAG Item): DCP элементный тип, объединяющий в единых логических данных название, длину и значение данных.

3.2 Обозначения

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

Nx — значение «N», выраженное в основании «х». Основание «х» должно быть десятичным, таким образом 2А16 есть шестнадцатиричное представление десятичного числа 42;

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

[х~\ — наименьшее целое число, численно большее, чемх. Иногда известно как функция «потолка»;

[xj — наибольшее целое число, численно меньшее, чемх. Иногда известно как функция «пола»;

-    — результат деления величины хна величину/;

У

MIN {а, ... ,т) — наименьшая величина в перечне.

3.3 Сокращения

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

AF (Application Framing (a DCP Protocol Layer) — разделение на фреймы (уровень DCP протокола);

ASCII (American Standart Code for Information Interchange) — американский 8-битовый стандартный код для обмена информацией;

CRC (Cyclic Redundancy Check) — циклический контроль с избыточностью (метод обнаружения ошибок с использованием полиномиального кода);

DCP (Distribution and Communication Protocol) — протокол распределения и коммуникации;

DRM (Digital Radio Mondiale) — Всемирное цифровое радио;

FEC (Forward Error Correction) — прямая коррекция ошибок;

IP (Internet Protocol) — Интернет-протокол;

LSb (Least Significant bit) — младший значащий бит;

LSB (Least Significant Byte) — младший значащий байт;

MSb (Most Significant bit) — старший значащий бит;

MSB (Most Significant Byte) — старший значащий байт;

MTU (Maximum Transmit Unit) — максимальный блок передачи;

PFT (Protection, Frangmentation and Transportation) — защита, фрагментация, транспортировка;

PPP (point-to-point protocol) — протокол двухточечного соединения;

RS (Reed Solomon) — Рид-Соломон;

TAG (Tag, Length, Value) — тег, длина, значение;

TCP (Transmission Control Protocol) — протокол управления передачей, один из основных сетевых протоколов Интернета, предназначенный для управления передачей данных в сетях TCP/IP;

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

Примечание — В тексте стандарта, если не указано иное, принято следующее соглашение о порядке следования битов:

-    на рисунках бит или байт, показанный слева, рассматривается как первый;

-    в таблицах бит или байт, показанный слева, рассматривается как первый;

-    в полях байта старший значащий бит (MSb) рассматривается первым и обозначается большим числом. Например, MSb одного байта обозначается “Ь7”, а младший значащий бит (LSb) обозначается “Ь0”;

-    в векторах (математических выражениях) бит с наименьшим индексом рассматривается как первый.

Порядок передачи (MSb — сначала или LSb — сначала) должен использоваться установленным порядком

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

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

4.1    Обзор системы

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

Примечание — Этот универсальный DCP протокол не определяет никаких правил или ограничений при выборе передачи. Выбор правил определяется конкретным приложением и поэтому рассматривается индивидуально для каждого определения прикладного протокола.

4.2    Архитектура системы

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

2

Сервер приложений


_Логический "канал связи'


Клиент-приложения


Тег, длина, значение (TAG)


Тег, длина, значение (TAG)


Разделение на фреймы (AF)


Защита, фрагментация и транспортировка (PFT - опционально)


Протоколы распределения и коммуникации (DCP)


Разделение на фреймы (AF)


Защита, фрагментация и транспортировка (PFT - опционально)


Надежный канал связи


Канал связи с ошибками


Рисунок 1 — Стек DCP протокола


Данные каждого уровня инкапсулированы в серии пакетов. Уровень TAG инкапсулирует элементарные элементы данных произвольной длины, в то время как уровень AF комбинирует элементарные данные в единый блок связанных данных. Дополнительный (опционально) уровень PFT позволяет осуществлять фрагментацию потенциально больших AF пакетов и добавляет возможность адресации и прямого исправления ошибок (FEC). Пакеты AF или фрагменты PFT могут тогда транспортироваться по любому из множества физических каналов, включая (не ограничивая) асинхронный последовательный, UDP/IP и даже сохраненный как файл на диске. Пример возможного варианта уровней связи показан на рисунке 2.


Разделение на фреймы (AF)

TCP/IP

Защита, фрагментация и транспортировка (PFT - опционально)

Последо

вательный

Файл

UDP/IP

U


Разделение на фреймы (AF)

Защита, фрагментация и транспортировка (PFT - опционально)

TCP/IP

UDP/IP

Файл

Последо

вательный

U


Однонаправленный канал связи с ошибками


Надежный двунаправленный канал связи


Рисунок 2 — Пример уровней связи DCP


3


ГОСТ P 54708—2011


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

4.2.1 TAG элементы, AF пакеты и PFT фрагменты

Краткий обзор структуры данных на различных уровнях приведен на рисунке 3.


TAG пакет


TAG элемент

TAG

TAG

TAG

Заполнение

название

длина

значение

TAG элемента


TAG

TAG

TAG

TAG

Заполнение

элемент

элемент

элемент

элемент

TAG пакета


CRC


AF пакет

AF

заголовок

Полезная нагрузка (TAG пакет)

_V

/\

^ ч

PFT фрагменты

PFT

Полезная

PFT

Полезная

PFT

Полезная

(если используются)

заголовок

нагрузка

заголовок

нагрузка

заголовок

нагрузка

Рисунок 3 — TAG элементы, AF пакеты и PFT фрагменты


5 TAG уровень

TAG уровень формирует интерфейс между приложением и DCP. В пределах TAG уровня TAG элементы инкапсулированы как индивидуальные элементы данных. TAG элементы объединены в TAG пакет, чтобы сформировать логически связанный блок данных согласно приложению. Таким образом, чтобы определить новое приложение, необходимо просто определить ряд TAG элементов и наложить любые необходимые ограничения на особенности DCP, например, определяя, что PFT уровень должен всегда использоваться или что физической линией должен всегда быть Ethernet и т. д.

5.1 TAG пакет

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


TAG пакет


I    I

I    I

I    I

TAG

элемент

TAG

элемент

TAG

элемент

Заполнение TAG пакета

j4 <8 байтов tj

Рисунок 4 — TAG пакет


TAG пакет (рисунок 4) может включать до 7 байтов заполнения после последнего TAG элемента— данные, которые содержатся в заполнении, должны быть неопределенными. Такое заполнение


4


ГОСТ Р 54708-2011

должно игнорироваться всеми приемниками. Так как самая короткая длина TAG элемента составляет 8 байтов, заполнение TAG пакета может быть легко идентифицировано. Если требуется больше чем 7 байтов заполнения, то должен быть использован специальный TAG элемент *dmy согласно 5.2.2.2.

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

5.1.1 Основные правила

Приложение может определить, имеет ли порядок TAG элементов в пределах TAG пакета какое-нибудь значение. Очень настоятельно рекомендуется, чтобы порядок TAG элементов не был существенен.

Приложение может определить, может ли один TAG пакет содержать многие TAG элементы с тем же самым названием.

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

Название TAG элемента может включить любые четыре байта и не должно быть ограничено символами ASCI I . Одно общее огран ичен ие дано в 5.2.2. Приложения могут определять дополнительные ограничения.

5.2 TAG элемент

Структура одного TAG элемента приведена на рисунке 5.

TAG

название

TAG

длина

TAG

значение

Заполнение TAG элемента

4 байта

4 байта

Переменная длина

< 8 битов

f

___^

'-г""

1____

__________1

U-

Полная длина -

всегда целое число 8 битовых байтов

_j

Рисунок 5 — Структура TAG элемента

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

TAG длина: четырехбайтовая величина, представляющая число битов в поле TAG значение.

TAG значение: любое значение, требуемое приложением.

Заполнение TAG элемента: до семи битов неопределенного значения, как требуется, чтобы сделать полную длину TAG элемента целым числом байтов.

5.2.1 Иерархические TAG элементы — пример кодирования

Если требуется приложением, один TAG элемент может инкапсулировать в себе дополнительные TAG элементы, как показано на рисунке 6. Глубина иерархии может быть при необходимости ограничена приложением.

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

5