allgosts.ru33.170 Теле- и радиовещание33 ТЕЛЕКОММУНИКАЦИИ. АУДИО- И ВИДЕОТЕХНИКА

ГОСТ Р 59804-2021 Телевидение вещательное цифровое. Технические требования DVB для вещания данных

Обозначение:
ГОСТ Р 59804-2021
Наименование:
Телевидение вещательное цифровое. Технические требования DVB для вещания данных
Статус:
Действует
Дата введения:
06.01.2022
Дата отмены:
-
Заменен на:
-
Код ОКС:
33.170

Текст ГОСТ Р 59804-2021 Телевидение вещательное цифровое. Технические требования DVB для вещания данных

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

ГОСТР 59804— 2021



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

ТЕЛЕВИДЕНИЕ ВЕЩАТЕЛЬНОЕ ЦИФРОВОЕ

Технические требования DVB для вещания данных

[ETSI EN 301 192 V 1.6.1 (2015-08), NEQ]

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

Москва Российский институт стандартизации 2021

Предисловие

  • 1 РАЗРАБОТАН Автономной некоммерческой организацией «Научно-технический центр информатики» (АНО «НТЦИ»)

  • 2 ВНЕСЕН Техническим комитетом по стандартизации ТК 480 «Связь»

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

  • 4 Настоящий стандарт разработан с учетом основных нормативных положений документа Европейского института по стандартизации в области телекоммуникаций ETSI EN 301 192 V1.6.1 (2015-08) «Телевидение вещательное цифровое. Спецификация DVB для вещания данных» [ETSI EN 301 192 V1.6.1 (2015-08) «Digital Video Broadcasting (DVB); DVB specification for data broadcasting», NEQ]

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

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

© Оформление. ФГБУ «РСТ», 2021

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

Содержание

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

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

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

  • 4 Конвейерная передача данных

  • 4.1 Общие характеристики конвейерной передачи данных

  • 4.2 Параметры конвейерной передачи данных

  • 5 Потоковая передача данных

  • 5.1 Общие характеристики потоковой передачи данных

  • 5.2 Параметры асинхронной потоковой передачи данных

  • 5.3 Параметры синхронной и синхронизированной потоковой передачи данных

  • 6 Передача данных при многопротокольной инкапсуляции

  • 6.1 Требования к передаче дейтаграмм в составе транспортного потока MPEG-2 при многопротокольной инкапсуляции

  • 6.2 Параметры информации о службах (SI) и информации о конкретной программе (PSI) при многопротокольной инкапсуляции

  • 7 Таблица уведомлений IP/МАС для многопротокольной инкапсуляции

  • 7.1 Связь многопротокольной инкапсуляции с DVB

  • 7.2 Принципы использования таблицы уведомлений IP/MAC

  • 7.3 Требования к сетевой сигнализации

  • 7.4 Параметры сигнализации информации о конкретной программе (PSI)

  • 7.5 Параметры таблицы уведомлений IP/MAC

  • 8 Передача данных средствами карусели данных

  • 8.1 Общие характеристики службы вещания карусели данных

  • 8.2 Параметры дескрипторов карусели передачи данных

  • 8.3 Параметры информации о конкретной программе (PSI) и информации о службах (SI) при использовании карусели данных

  • 9 Передача данных средствами карусели объектов

  • 9.1 Область применения службы вещания карусели объектов

  • 9.2 Спецификация карусели объектов

  • 9.3 Параметры дескрипторов карусели объектов

  • 10 Высшие протоколы передачи асинхронных потоков данных

  • 10.1 Спецификация высших протоколов передачи данных

  • 10.2 Характеристики информации о конкретной программе (PSI) и информации о службе (SI)... .28

  • 11 Модель декодера

Приложение А (обязательное) Набор услуг BouquetJD

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

ТЕЛЕВИДЕНИЕ ВЕЩАТЕЛЬНОЕ ЦИФРОВОЕ

Технические требования DVB для вещания данных

Digital Video Broadcasting (DVB). DVB technical requirements for data broadcasting

Дата введения — 2022—06—01

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

Настоящий стандарт распространяется на систему цифрового вещательного телевидения (Digital Video Broadcasting; DVB), обеспечивающую средство доставки транспортных потоков (transport stream; TS) MPEG-2 через различные средства передачи.

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

  • - профиль конвейерной передачи данных;

  • - профиль поточного вещания данных;

  • - профиль многопротокольной инкапсуляции;

  • - профиль карусели данных;

  • - профиль карусели объектов;

  • - профиль протоколов высоких уровней асинхронных потоков данных.

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

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

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

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

ГОСТ 7.75 Система стандартов по информации, библиотечному и издательскому делу. Коды наименований языков

ГОСТ Р 52591—2006 Система передачи данных пользователя в цифровом телевизионном формате. Основные параметры

ГОСТ Р 53528—2009 Телевидение вещательное цифровое. Требования к реализации протокола высокоскоростной передачи информации DSM-CC. Основные параметры

ГОСТ Р 54994 Телевидение вещательное цифровое. Передача служб DVB по сетям с IP протоколами. Общие технические требования

ГОСТ Р 54995 Телевидение вещательное цифровое. Требования к кодированию аудио и видеосигналов для приложений вещания, основанных на транспортных потоках MPEG-2. Общие технические требования

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

ГОСТ Р 55697 Телевидение вещательное цифровое. Сервисная информация. Общие технические требования

ГОСТ Р 56170 Телевидение вещательное цифровое. Домашняя мультимедийная платформа. Класс 1.2. Основные параметры

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

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

    • 3.1 В настоящем стандарте применены термины по ГОСТ Р 53528, ГОСТ Р 54994, ГОСТ Р 52591, ГОСТ Р 56170, ГОСТ Р 55697, а также следующие термины с соответствующими определениями:

      • 3.1.1 букет (bouquet): Набор услуг, предоставляемых оператору как единое целое.

      • 3.1.2 информация о конкретной программе; PSI (Program Specific Information, PSI): Информация, содержащая сведения о составе программ и идентификаторах их компонентов.

      • 3.1.3 информация о службах; SI (Service Information, SI): Информация, описывающая систему доставки, а также содержание и планирование служб и событий.

Примечание — Информация о службах (услугах) включает в себя PSI MPEG-2 вместе с расширениями, определяемыми DVB.

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

  • 3.1.5 сеть (network): Управляемый набор транспортных потоков DVB, передаваемых в одной или нескольких системах доставки, как правило, в одной и той же физической среде.

Примечания

  • 1 В одной сети допускается использование систем доставки первого и второго поколений, (например, DVB-T и DVB-T2).

  • 2 Сеть идентифицируется networkjd. Сеть может состоять из одного или нескольких излучающих сайтов.

  • 3.1.6 служба (service): Набор элементарных потоков, который предлагается пользователю в виде программы.

Примечание — Элементарные потоки связаны общей синхронизацией. Набор элементарных потоков формируется из различных данных, например видео-аудио, данных субтитров, других данных таблицы структуры (карты) программы (Program Map Table; РМТ).

  • 3.1.7 событие (event): Событие, определяемое как набор элементарных потоков с общей временной базой, связанных временем начала и временем окончания передачи данных.

  • 3.1.8 транспортный поток DVB (DVB transport stream): Транспортный поток MPEG-2, содержащий сигнализацию DVB-SL

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

  • 3.1.10 элементарный поток; ES (Elementary Stream; ES): Общий термин для одного из кодированных потоков битов в пакетах PES.

Примечание — Один элементарный поток передается в последовательности пакетов PES только с одним streamjd.

  • 3.1.11 профиль карусели данных (data carousel): Карусели данных, выполняющие вещание данных при периодической передаче данных.

Примечание — Карусель данных DVB основана на технологии каруселей данных системы команд и управления для средств цифровой записи (Digital Storage Media — Command and Control; DSM-CC).

  • 3.1.12 профиль карусели объектов (object carousel): Карусели объектов, в качестве основы использующие технологии каруселей данных и обеспечивающие дополнительные иерархическую структуру и метаданные, необходимые для построения иерархической файловой системы.

  • 3.1.13 профиль многопротокольной инкапсуляции (multiprotocol encapsulation): Профиль вещания данных при многопротокольной инкапсуляции, поддерживающий передачу данных в составе дейтаграмм.

Примечание — Передача дейтаграмм выполняется в формате секций частных данных в соответствии с DSM-CC.

  • 3.1.14 профиль поточного вещания данных (Data Streaming): Профиль поточного вещания данных, поддерживающий службы вещания данных, ориентированных на передачу непрерывных потоков больших объемов в составе пакетированных элементарных потоков PES через сети вещания DVB.

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

  • 3.1.15 профиль протоколов высоких уровней асинхронных потоков данных (profie of protocols of acynohronous data flows): Профиль вещания данных при использовании протоколов высоких уровней, основанный на асинхронных потоках данных и поддерживающий передачу протоколов, которые требуют потоковой доставки асинхронных данных через сети вещания DVB.

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

  • ARP — протокол разрешения адресов (Address Resolution Protocol);

ВАТ — таблица объединения букета программ (Bouquet Association Table);

bslbf — мнемоническое обозначение: последовательность битов, левый бит первый (bit string left bit first);

CRC — циклический контроль по четности (Cyclic Redundancy Check);

DSM-CC — система команд и управления для средств цифровой записи (Digital Storage Me

dia — Command and Control);

DVB-T — стандарт передачи цифровых сигналов по сетям эфирного телевидения, первая версия (DVB Terrestrial Modulation, first generation);

DVB-T2 — стандарт передачи цифровых сигналов по сетям эфирного телевидения, вторая версия (DVB Terrestrial Modulation, second generation);

EBU — европейский вещательный союз (European Broadcasting Union);

gi — поле дескрипторов (GroupInfoByte);

GNSS — глобальные навигационные спутниковые системы (Global Navigation Satellite Systems);

INT — таблица уведомлений IP (IP Notification Table);

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

IPv4 — интернет-протокол, версия 4 (Internet Protocol version 4);

IPv6 — интернет-протокол, версия 6 (Internet Protocol version 6);

ISO — международная организация по стандартизации (International Organization for

Standardization);

LLC — управление логической связью (Logical Link Control);

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

MAC — управление доступом к среде (Media Access Control);

МНР — мультимедийная домашняя платформа (Multimedia Home Platform);

MPE — многопротокольная инкапсуляция (Multi-Protocol Encapsulation);

MPEG — группа экспертов по движущимся изображениям (Moving Pictures Expert Group);

MPEG-2 — стандарт цифрового сжатия аудио- и видеоинформации;

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

NDP — протокол обнаружения соседей (Neighbor Discovery Protocol);

NIT — таблица сетевой информации (Network Information Table);

NSAP — точка доступа к службе сети (Network Service Access Point);

OSI — взаимодействие открытых систем (Open Systems Interconnection);

OUI — уникальный идентификатор организации (Organizational Unique Identifier);

PCR — ссылка на программные часы (Program Clock Reference);

PES — пакетированный элементарный поток (Packetised Elementary Stream);

PID — идентификатор пакета (Packet Identifier);

PMT — таблица структуры программы (Program Map Table);

PTS — разрешение времени данных (Presentation TimeStamps);

RARP — обратный протокол преобразования адресов (Reverse Address Resolution Protocol); rpchof — коэффициенты остаточного полинома, самый старший коэффициент обрабатывается первым (remainder polynomial coefficients, highest order first);

SIS — системы интерактивных служб (Systems for Interactive Services);

SNAP — точка подсоединения к субсети (SubNetwork Attachment Point);

TPEG — группа экспертов по транспортному протоколу (Transport Protocol Experts Group);

TS — транспортный поток (Transport Stream);

T-STD — целевой декодер транспортной системы (Transport System Target Decoder);

uimsbf — мнемоническое обозначение последовательности битов «целое число без знака,

старший бит следует первым» (unsigned integer most significant bit first);

UNT — таблица уведомлений об обновлении (Update Notification Table);

U-U — обозначение абонентов службы обмены данными: пользователь-пользователь

(User-to-User);

XOR — логическая операция: исключающее ИЛИ [эксклюзивная дизъюнкция] (exclusive OR);

mi — поле, которое содержит дескрипторы с необходимой информацией, в том числе

указатель на локацию сообщений DownloadDataBlock (ModulelnfoBytes);

DVB Project — международная организация, занимающаяся разработкой стандартов в области цифрового телевидения для Европы (Digital Video Broadcasting Project);

servicejd — уникальный идентификатор службы в транспортном потоке DVB.

  • 4 Конвейерная передача данных

    • 4.1 Общие характеристики конвейерной передачи данных

Вещание данных методом конвейерной передачи в асинхронном режиме выполняется по сети телевизионного вещания (DVB) при размещении данных в полезной нагрузке пакетов пакетированных элементарных потоков (Packetised Elementary Stream; PES) в составе транспортного потока MPEG-2.

  • 4.2 Параметры конвейерной передачи данных

    4.2.1 Общие правила

    Параметры службы конвейерной передачи данных определены ГОСТ Р 52591. Использование канала службы вещания данных обозначается включением в информацию о службах (Service Information; SI) дескрипторов data_broadcast_descriptors согласно ГОСТ Р 52591—2006 (подпукт 5.1.1.2).

Каждый дескриптор data_broadcast_descriptor должен быть связан с конкретным каналом конвейерной передачи данных идентификатором component_tag (согласно ГОСТ Р 52591—2006 (подпункт 5.1.1.3).

Семантика полей дескриптора data_broadcast_descriptor для случая конвейерной передачи должна применяться со следующими уточнениями:

  • - поле data_broadcast_id должно содержать значение 0x0001;

  • - поле component_tag должно содержать значение поля дескриптора stream_identifier_descriptor (если он присутствует в секции таблицы PSI) для потока, используемого в качестве конвейера данных;

  • - поле selector_length должно содержать 0;

  • - поле stream_type не должно использоваться.

Ввод данных пользователя в систему передачи данных цифрового телевизионного вещания данных выполняется в соответствии с ГОСТ Р 52591—2006 (подраздел 5.2).

Структура пакетов транспортного потока в системе передачи данных пользователя в цифровом телевизионном формате представлена в ГОСТ Р 52591—2006 (подраздел 5.3).

Вывод данных пользователя в системе передачи данных цифрового телевизионного формата выполняется в соответствии с ГОСТ Р 52591—2006 (подраздел 5.4).

  • 5 Потоковая передача данных

    • 5.1 Общие характеристики потоковой передачи данных

В режиме потоковой передачи данных, данные в форме непрерывного потока, вводятся в пакеты PES вещательной передачи. Пакеты PES должны иметь ненулевую длину и размещаться в пакетах транспортного потока MPEG-2 (см. ГОСТ Р 54995).

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

При передаче синхронных данных на выходе приемника обеспечивается восстановление тактовой частоты потока данных.

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

  • 5.2 Параметры асинхронной потоковой передачи данных

    5.2.1 Общие характеристики асинхронной потоковой передачи данных

    Правила отображения пакетов PES в пакеты транспортного потока MPEG-2 определены стандартом системы MPEG-2.

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

  • - поле stream_id должно содержать значение OxBF (private_stream_2);

  • - поле PES_packet_length должно содержать значение, отличное от нуля.

  • 5.2.2 Параметры информации о службах (SI) и информации о конкретной программе (PSI)

При потоковой передаче асинхронного потока данных список SI должен содержать дескриптор вещания данных data_broadcast_descriptor. Каждый дескриптор должен быть связан с конкретным потоком идентификатором component_tag, значение которого должно быть идентично значению поля component_tag дескриптора stream_identifier_descriptor, который может присутствовать в таблице PSI используемого потока данных.

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

  • - поле data_broadcast_id должно содержать значение 0x0002;

  • - поле selector_length должно содержать значение «0»;

  • - поле selector_byte не должно использоваться.

Присутствие асинхронного потока данных в службе должно указываться в таблице структуры программы (РМТ) установкой для типа этого потока значения 0x06 или значения частного пользователя.

  • 5.3 Параметры синхронной и синхронизированной потоковой передачи данных

    5.3.1 Общие характеристики синхронной и синхронизированной потоковой передачи данных

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

  • - stream_id должно содержать значение OxBD (private_stream_1);

  • - PES_packet_length должно содержать значение, отличное от нуля.

Данные должны размещаться в пакетах PES с использованием структуры PES_data_packet. Синтаксис полей структуры PES_data_packet определен в таблице 1.

Таблица 1 — Синтаксис структуры PES_data_packet

Синтаксис

Количество бит

Мнемоника

PES_data_packet () {

datajdentifier

8

uimsbf

sub_stream_id

8

uimsbf

PTS_extension_flag

1

bslbf

output_data_rate_flag

1

bslbf

reserved

2

bslbf

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

Синтаксис

Количество бит

Мнемоника

PES_data_packet_header_length if (PTS_extension_flag==«1») {

4

uimsbf

reserved

7

bslbf

PTS_extension

}

if (output_data_rate_flag==«1») {

9

bslbf

reserved

4

bslbf

output_data_rate

}

for (i=0; i<N; i++) {

28

uimsbf

PES data_private_data_byte }

for (i=0; i<N; i++) {

8

bslbf

PES_data_byte } }

8

bslbf

Семантика структуры PES_data_packet должна быть следующей:

data_identifier — определяет тип данных, переносимых в пакете PES. Кодирование типа данных выполняется в соответствии с таблицей 2. Поле data_identifier должно содержать одинаковые значения для каждого пакета PES, передающего данные в одном потоке данных;

Таблица 2 — Кодирование типа данных datajdentifier

Тэги

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

От 0x00 до OxOF

Зарезервировано для использования в будущем

От 0x10 до 0x1 F

Зарезервировано для данных EBU

0x20

Субтитры DVB

0x21

Синхронный поток данных DVB

0x22

Синхронизированный поток данных DVB

От 0x23 до 0x7F

Зарезервировано для использования в будущем

От 0x80 до OxFF

Определяется пользователем

sub_stream_id — содержание 8-битового поля определяет пользователь;

PTS_extension_flag — 1-битовое поле для синхронных потоков данных должно содержать «1». Для синхронизированных потоков данных значение «1» указывает на наличие в поле PES_data_packet поля PTS_extension. Если в синхронизированных потоках данных поле PTS_extension отсутствует, то в поле PTS_extension_flag должен устанавливаться «0»;

output_data_rate_flag — 1-битовое поле для синхронизированных потоков данных должно содержать «0». Для синхронных потоков данных значение «1» указывает на наличие в пакете PES_data_ packet поля output_rate. Для синхронных потоков данных, если поле output_rate отсутствует, то в поле PES_data_packet должен устанавливаться «0»;

PES_data_packet_header_length — 4-битовое поле определяет длину полей в заголовке пакета, включая поле PES_data_private_data_bytes;

PTS_extension — содержит 9-битовое расширение ссылки на программные часы (Program Clock Reference; PCR), изменяющее разрешение времени данных (Presentation TimeStamps) PTS (синхронных или синхронизированных) от стандартного разрешения MPEG-2 от 11,1 мкс (90 кГц) до 37 нс (27 МГц);

output_data_rate — содержит значение скорости передачи регенерированного сигнала для синхронного потока данных, которое кодируется как 28-битовое положительное целое число;

PES_data_private_data_byte — использование поля определяет пользователь. Приемники, совместимые с DVB, могут игнорировать содержание этого поля;

PES_data_byte — содержит данные для DVB-вещания.

  • 5.3.2 Параметры информации о службах (SI) и информации о конкретной программе (PSI)

При потоковой передаче синхронного потока данных в список SI должны включаться дескрипторы вещания данных data_broadcast_descriptors. Каждый дескриптор с каждым конкретным потоком должен быть связан идентификатором component_tag. Значение поля component_tag должно быть идентично значению поля component_tag дескриптора stream_identifier_descriptor, которое может присутствовать в секции PSI используемого потока данных.

  • 5.3.3 Параметры дескриптора потокового вещания данных data_broadcast_descriptor

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

  • - data_broadcast_id для обозначения синхронного потока данных должно содержать значение 0x0003, а для обозначения синхронизированных потоков данных в этом поле должно устанавливаться значение 0x0004;

  • - component_tag должно содержать то же значение, что и поле component_tag дескриптора stream_identifier_descriptor, если присутствует в секции PSI используемого потока данных;

  • - selector_length должно содержать 0.

  • 5.3.4 Тип потока в службе синхронного или синхронизированного потока данных

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

  • 6 Передача данных при многопротокольной инкапсуляции

    • 6.1 Требования к передаче дейтаграмм в составе транспортного потока MPEG-2 при многопротокольной инкапсуляции

Многопротокольная инкапсуляция поддерживает передачу данных в составе дейтаграмм. Дейтаграммы инкапсулируются в секции datagram_sections, соответствующие формату секций DSMCC_ section для частных данных (в соответствии с ГОСТ Р 53528—2009, приложение Б, пункт Б.2). Требования к преобразованию секций DSMCC_section в пакеты транспортного потока MPEG-2 должны соответствовать ГОСТ Р 53528—2009 (приложение Б, пункт Б.2).

Синтаксис datagram_section представлен в таблице 3.

Таблица 3 — Синтаксис datagram_section

Синтаксис

Количество бит

Мнемоника

datagram_section () {

tablejd

8

uimsbf

section_syntax_indicator

1

bslbf

privatejndicator

1

bslbf

reserved

2

bslbf

sectionjength

12

uimsbf

MAC_address_6

8

uimsbf

MAC_address_5

8

uimsbf

reserved

2

bslbf

payload_scrambling_control

2

bslbf

address_scrambling_control

2

bslbf

LLC_SNAP_flag

1

bslbf

current_next_indicator

1

bslbf

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

Синтаксис

Количество бит

Мнемоника

section_number

8

uimsbf

last_section_number

8

uimsbf

MAC_address_4

8

uimsbf

MAC_address_3

8

uimsbf

MAC_address_2

8

uimsbf

MAC_address_1

if (LLC_SNAP_flag == «1») {

LLC_SNAP()

} else {

for Q=0; j<N1;j++){

8

uimsbf

I P_datagram_data_byte

}

}

if (section_number = = last_section_number) { for (j=0; j<N2; j++) {

8

bslbf

stuffing_byte

}

}

if (section_syntax_indicator = =«0») {

8

bslbf

checksum

} else {

32

uimsbf

CRC.32 }

}

32

rpchof

Семантика полей в составе datagram_section должна быть следующей:

table_id — 8-битовое поле содержит значение ОхЗЕ;

section_syntax_indicator— содержит значение в соответствии с ГОСТ Р 53528—2009 (приложение Б, пункт Б.2);

private_indicator — содержит значение в соответствии с ГОСТ Р 53528—2009 (приложение Б, пункт Б.2);

reserved — 2д-битовое поле содержит значение 11;

section_length — содержит значение, соответствующее длине секции;

MAC_address_ [1..6] — 48-битовое поле содержит МАС-адрес пункта назначения. МАС-адрес разделен на шесть полей по восемь бит, помеченных MAC_address_1 - MAC_address_6;

MAC_address_1 — содержит старший значащий бит МАС-адреса (MSB), а поле MAC_address_6 содержит младший бит МАС-адреса (LSB). На рисунке 1 показано отображение байтов МАС-адреса в полях секции.

Примечание — Порядок битов в байтах не изменяется на противоположный, и старший бит (MSB) каждого байта по-прежнему передается первым;

MAC_address в соответствии с указанием в поле address_scrambling_control содержат скремблированный или нескремблированный МАС-адрес;

Рисунок 1 — Отображение байтов МАС-адреса в полях секции

payload_scrambly_control — содержит код режима скремблирования полезной нагрузки секции. Это поле включает в себя полезную нагрузку, начинающуюся после поля MAC_address_1, и не включает полей контрольной суммы или CRC32 (см. таблицу 4).

Таблица 4 — Кодирование payload_scrambling_control

Значение

Управление скремблированием полезной нагрузки

00

Не скремблировано

01

Определяет пользователь

10

Определяет пользователь

11

Определяет пользователь

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

address_scrambling_control — в соответствии с таблицей 5 содержит код режима скремблирования МАС-адреса в этой секции. Применяемый метод скремблирования определяет пользователь;

Таблица 5 — Кодирование address_scrambly_control

Значение

Управление скремблированием адреса

00

Не скремблировано

01

Определяет пользователь

10

Определяет пользователь

11

Определяет пользователь

LLC_SNAP_flag — указывает тип передаваемой дейтаграммы. Если флаг установлен в 1, то полезная нагрузка переносит инкапсулированную дейтаграмму управления логической связью/точки подсоединения к сети LLC/SNAP в поле MAC_address_1. Структура LLC/SNAP должна указывать тип передаваемой дейтаграммы, если этот флаг установлен на 0, то секция должна содержать дейтаграмму IP без инкапсуляции LLC/SNAP;

current_next_indicator — должно содержать 1, при переносе дейтаграммы в нескольких секциях указывает положение секции в процессе фрагментации. Если дейтаграмма переносится в одной секции, то в section_number должен быть установлен 0;

last_section_number — указывает номер последней секции в процессе фрагментации, используемого для передачи дейтаграммы;

IP_datagram_data_byte — содержит данные дейтаграммы. Если полезная нагрузка секции скремблируется (см. payload_scramble_mode), то байты дейтаграммы также скремблируются;

stuffing_byte — 8-битовое поле, если полезная нагрузка секции скремблируется (см. payload_ scramble_mode), то скремблируются и байты стаффинга. Количество используемых stuff!ng_bytes должно обеспечивать выравнивание данных, определенных в data_broadcast_descriptor;

checksum — содержит контрольную сумму, которая рассчитывается для всего поля datagram_ section;

структура LLC_SNAP — содержит дейтаграмму точки присоединения субсети (SNAP). Если полезная нагрузка секции скремблируется (см. payload_scramble_mode), то скремблируются и байты этой структуры.

Содержимое CRC рассчитывается по всему полю datagram_section.

Использование МАС-адресов в сетях вещания DVB позволяет идентифицировать каждый приемник сети и доставлять данные конкретному приемнику, формируя основу сети на канальном уровне модели OSI, которую используют протоколы сетевого уровня. Параметры процесса идентификации приемников на сети сетях вещания DVB представлены в разделе 7.

  • 6.2 Параметры информации о службах (SI) и информации о конкретной программе (PSI) при многопротокольной инкапсуляции

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

Служба вещания при передаче дейтаграмм должна включать в SI дескрипторы data_broad-cast_descriptor. Каждый дескриптор должен быть связан с потоком идентификатором component_tag. Значение поля component_tag должно быть идентично значению поля component_tag дескриптора stream_identifier_descriptor, который может присутствовать в таблице PSL

  • 6.2.2 Параметры дескриптора data_broadcast_descriptor

При многопротокольной инкапсуляции поля, входящие в состав broadcast_descriptor, должны иметь следующее:

  • - data_broadcast_id должно содержать значение 0x0005;

  • - selector_length должно содержать значение 0x02;

  • - selector_byte должно содержать структуру поля multiprotocol_encapsulation_info, синтаксис которой определен в таблице 6.

Таблица 6 — Синтаксис структуры multiprotocol_encapsulation_info

Синтаксис

Количество бит

Мнемоника

multiprotocol_encapsulation_info () {

MAC_address_range

3

uimsbf

MAC_IP_mapping_flag

1

bslbf

alignmentjndicator

1

bslbf

reserved

3

bslbf

max_sections_per_datagram }

8

uimsbf

Семантика структуры multiprotocol_encapsulation_info должна быть следующей:

MAC_address_range — 3-битовое поле должно указывать количество байтов МАС-адреса, которые служба использует для различения приемников в соответствии с таблицей 7;

Таблица 7 — Кодирование MAC_address_range

Тэги MAC адресов

Значение MAC_address в байтах

0x00

Зарезервировано

0x01

6

0x02

6, 5

0x03

6, 5,4

0x04

6, 5, 4, 3

0x05

6, 5, 4, 3, 2

0x06

6, 5, 4, 3, 2, 1

0x07

Зарезервировано

флаг MAC_IP_mapping_flag — 1-битовое поле. Служба устанавливает в «1», если она использует преобразование IP в МАС для адресов многоадресной рассылки IPv4 и IPv6. Если этот флаг установлен в 0, то процесс сопоставления IP-адресов с МАС-адресами настоящим стандартом не нормируется;

alignment_indicator— 1-битовое поле, указывает на необходимость выравнивания потоков байтов поля datagram_section и байтов транспортного потока. Размер выравнивания осуществляется в соответствии с таблицей 8;

Таблица 8 — Кодирование alignment-indicator

Значение

Размер выравнивания в битах

0

8 (по умолчанию)

1

32

reserved — 3-битовое поле содержит значение 111;

max_sections_per_datagram — 8-битовое поле указывает максимальное количество секций, которые могут использоваться для переноса одного блока дейтаграммы.

  • 6.2.3 Тип потока в службе вещания многопротокольной инкапсуляции

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

  • 7 Таблица уведомлений IP/MAC для многопротокольной инкапсуляции

    • 7.1 Связь многопротокольной инкапсуляции с DVB

В сетях вещания DVB МАС-адрес позволяет уникально идентифицировать каждый приемник сети и доставлять данные конкретному приемнику. Таким образом, МАС-адреса формируют основу сетей на канальном уровне модели OSI, которую используют протоколы более высокого (сетевого) уровня. Для преобразования МАС-адресов в адреса сетевого уровня и обратно применяют специальные протоколы (например, ARP и RARP в сетях IPv4 и NDP в сетях IPv6). В данном случае функции спецпротокола выполняет таблица уведомлений.

Использование таблицы уведомлений IP/МАС для многопротокольной инкапсуляции является опциональным.

  • 7.2 Принципы использования таблицы уведомлений IP/MAC

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

    Платформа IP/МАС является набором потоков IP/МАС и/или приемников. Платформа IP/MAC представляет собой согласованное (без конфликтов адресов) пространство IP/MAC-адресов. Платформа IP/MAC может включать несколько транспортных потоков в одной или нескольких сетях DVB. Несколько платформ IP/MAC могут сосуществовать в одном транспортном потоке. Платформа IP/MAC идентифицируется своим идентификатором platform_id.

Поток IP/MAC является потоком данных, включающим в себя заголовок адреса, содержащий IP и/или МАС-адрес. Поток инкапсулируется в мультиплекс транспортного потока MPEG-2. Примером может быть многоадресный поток IP, передаваемый в секциях МРЕ.

Идентификатор platform_id однозначно определяет платформу IP. После того, как приемник выбрал платформу IP/MAC или он был назначен этой платформе, все IP/MAC-адреса становятся уникальными. В пределах конкретной платформы IP/MAC конфликт адресов не допускается. Идентификатор platform_id назначается в офисе DVB Project. Настоящий стандарт не допускает пользователю использование идентификатора platform_id другими способами.

  • 7.2.2 Область применения таблицы уведомлений IP/MAC

Обработка информации о потоках IP/MAC в сетях DVB должна выполняться при использовании INT IP/MAC, которая формируется для переноса информации о локации потоков IP/MAC в сетях DVB. Функции, выполняемые INT, могут расширяться для выполнения дополнительных требований в области IP/MAC DVB.

Доступ к INT в различных сетевых конфигурациях обеспечивается через дескрипторы сцепления (linkage), расположенные в таблице сетевой информации (Network Information Table; NIT), или через таблицу объединения букета программ (Bouquet Association Table; ВАТ) в уведомлении IP/MAC. Уведомление IP/MAC при использовании таблиц NIT/BAT может размещаться в нескольких транспортных потоках сети вещания. Уведомление IP/MAC размещается на дополнительном уровне обращения через дескриптор сцепления в NIT. Эта последняя схема применима в основном для очень больших сетей.

  • 7.2.3 Типы уведомлений IP/MAC

Структура INT содержит несколько типов уведомлений IP/МАС, различающихся тэгами action_type.

Тип уведомления IP/МАС сигнализирует о локации потоков IP/МАС в сетях вещания DVB. Данный тип уведомления описывается в 7.3.

  • 7.3 Требования к сетевой сигнализации

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

    Дескриптор сцепления типа 0x0В (служба уведомления IP/МАС) определяет транспортный поток и службу, переносящую таблицу уведомлений IP/МАС в сети или букете. Этот дескриптор должен переноситься в первом цикле NIT или в первом цикле специально идентифицированной ВАТ.

Если оператору запрещается размещать этот дескриптор в NIT (например, из-за ограничений размера таблицы), то дескриптор может находиться в ВАТ уведомления I Р/М АС. ВАТ уведомления I Р/М АС маркируется идентификатором пакета IP/MAC bouquet_id. Правила назначения bouquetjd определены в приложении А.

Дескриптор сцепления может встречаться более одного раза, например, если таблица уведомлений IP/MAC передается в сети вещания DVB в нескольких транспортных потоках. На все таблицы уведомлений IP/MAC в сети вещания DVB должен ссылаться по крайней мере один дескриптор сцепления типа 0x0В.

Если таблицы BAT/NIT уведомлений IP/MAC объявляют о нескольких платформах IP/MAC, то приемник может выбрать платформу, используя ее имя. Приемники могут одновременно быть частью нескольких платформ IP/MAC.

Приемник данных DVB должен обращаться к NIT в своем транспортном потоке по умолчанию и сканировать эту NIT для поиска дескрипторов сцепления типа 0x0В. Если приемник обнаружит несколько дескрипторов сцепления, то он должен проверить идентичность идентификатора платформы IP/MAC. Если идентичность будет установлена, то приемник должен проверить INT транспортных потоков платформы IP/MAC. Если INT различны, то пользователю будет предложено выбрать платформу IP/MAC.

Для некоторых сетей DVB может оказаться нецелесообразным иметь в NIT несколько дескрипторов сцепления типа 0x0В. Поэтому, если приемник данных не может найти linkage_descriptor типа 0x0В, то он должен выполнить поиск linkage_type типа ОхОС и, если такой дескриптор будет найден, приемник должен дополнительно сканировать BAT/NIT в поисках типов сцепления 0x0В. Для обеспечения быстрого доступа к INT при переключении транспортных потоков приемник должен кэшировать таблицы, получаемые в процессе поиска.

Если приемник не находит в транспортном потоке дескриптор сцепления типа 0x0В или ОхОС, то он должен проверить наличие дескриптора сцепления типа 0x04, указывающего на транспортный поток, содержащий полную информацию о службах (SI) NIT или ВАТ.

  • 7.3.2 Параметры дескриптора сцепления для таблицы уведомлений IP/MAC

Синтаксис дескриптора сцепления типа 0x0В таблицы уведомлений IP/MAC представлен в таблице 9.

Таблица 9 — Синтаксис дескриптора сцепления типа 0x0В таблицы уведомлений IP/MAC

Синтаксис

Количество бит

Мнемоника

linkage_descriptor () {

descriptor_tag

8

uimsbf

descriptorjength

8

uimsbf

transport_stream_id

16

uimsbf

original_network_id

16

uimsbf

servicejd

16

uimsbf

linkage_type

if (linkage_type = = OxOB) {

8

uimsbf

platform_id_data_length

for (i=0; i<N; i++) {

8

uimsbf

platformjd

24

uimsbf

platform_name_loop_length for (i=0; i<N; i++) {

8

uimsbf

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

Синтаксис

Количество бит

Мнемоника

ISO_639_language_code

24

bslbf

platform_name_length

for (i=0; i<platform_name_length; i++)

{

8

uimsbf

text_char }

}

}

for (i=0; i<N; i++) {

8

uimsbf

private_data_byte

}

}

}

8

uimsbf

Ниже представлена семантика полей в составе дескриптора сцепления типа 0x0В:

transport_stream_id — 16-битовое поле, идентифицирует транспортный поток, содержащий INT;

original_network_id — 16-битовое поле, содержит метку, идентифицирующую network_id исходной системы доставки транспортного потока, переносящего INT;

service_id — 16-битовое поле, идентифицирует службу, содержащую INT;

linkage_type — 8-битовое поле, определяет тип сцепления, в нем должно быть установлено 0x0В; platform_id_data_length — определяет общую длину в байтах следующего цикла platform_id;

platform_id — 24-битовое поле, содержит platform_id организации, предоставляющей потоки IP/МАС для транспортных потоков/служб DVB;

platform_name_loop_length — 8-битовое поле, определяет длину в байтах следующего цикла имени платформы;

ISO_639_language_code — 24-битовое поле, содержит трехсимвольный код языка названия платформы согласно ГОСТ 7.75;

platform_name_length — определяет общую длину в байтах названия платформы;

text_char — содержит название платформы;

private_data_byte — 8-битовое поле, значение поля определяет пользователь.

  • 7.3.3 Параметры дескриптора отложенного сцепления для таблиц уведомлений IP/MAC

Дескриптор отложенного сцепления характеризует транспортный поток, переносящий ВАТ или NIT в составе уведомления IP/МАС, информирует о таблицах уведомлений IP/МАС. Тип дескриптора отложенного сцепления должен быть ОхОС и он должен размещаться в NIT.

Дескриптор отложенного сцепления ОхОС отличается от дескриптора сцепления типа 0x0В тем, что он не содержит данных, связанных с идентификатором платформы. Он может использоваться приемником для быстрого захвата мультиплекса, переносящего ВАТ или NIT уведомления IP/МАС, без необходимости сканировать все мультиплексы.

Синтаксис дескриптора сцепления типа ОхОС должен соответствовать таблице 10.

Таблица 10 — Синтаксис дескриптора сцепления типа ОхОС

Синтаксис

Количество бит

Мнемоника

linkage_descriptor () {

descriptor_tag

8

uimsbf

descriptorjength

8

uimsbf

transport_stream_id

16

uimsbf

original_network_id

16

uimsbf

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

Синтаксис

Количество бит

Мнемоника

servicejd

16

uimsbf

linkage_type

if (linkage_type = = 0х0С){

8

uimsbf

table_type

if (table_type = = 0x02){

8

bslbf

bouquetjd

}

}

}

16

uimsbf

Должны быть следующие поля дескриптора сцепления типа ОхОС:

transport_stream_id — 16-битовое поле, идентифицирует транспортный поток, содержащий ВАТ или NIT уведомления IP/MAC;

original_network_id — 16-битовое поле, содержит метку, идентифицирующую network_id исходной системы доставки ВАТ или NIT уведомления IP/MAC;

service_id — 16-битовое поле, должно содержать значение 0x0000;

linkage_type — 8-битовое поле, определяет тип сцепления и должно содержать значение ОхОС;

table_type — 8-битовое поле, указывает либо на ВАТ, либо на NIT уведомления IP/MAC в соответствии с таблицей 11;

Таблица 11 — Значения поля table_type

Значение

Описание

0x00

He определено

0x01

NIT

0x02

BAT

0x03—OxFF

Зарезервировано

bouquet_id — 16-битовое поле, идентифицирует букет, описываемый ВАТ уведомления IP/MAC.

  • 7.4 Параметры сигнализации информации о конкретной программе (PSI)

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

    Таблица уведомлений IP/MAC передается в составе службы DVB. Таблица структуры программы (РМТ) транспортного потока, переносящего INT, должна содержать дескриптор data_broadcast_id_ descriptor с идентификатором data_broadcast_id, равным 0x000В, который маркирует элементарный поток, используемый для таблицы уведомлений IP/MAC и обеспечивает ссылку на таблицу уведомлений IP/MAC.

Дескриптор может содержать идентификаторы платформы, в этом случае список идентификаторов платформ должен быть полным.

Дескриптор data_broadcast_id_descriptor в РМТ должен содержать ссылки (platform_id и action_type) каждой субтаблицы INT, которая транслируется в соответствующем элементарном потоке.

  • 7.4.2 Параметры структуры IP/MAC_notification_info таблицы уведомлений IP/MAC

Синтаксис структуры IP/MAC_notification_info таблицы уведомлений IP/MAC представлены в таблицей.

Семантика структуры IP/MAC IP/MAC_notification_info для data_broadcast_id 0x000В должна быть следующей:

platform_id_data_length — определяет общую длину в байтах следующего цикла platform_id;

platform_id — 24-битовое поле, идентифицирует платформу IP/MAC;

action_type — содержание 8-битового поля, которое должно соответствовать содержанию поля action_type, определенному в INT в таблице 13;

INT_versioning_flag — содержит 0, означает что информация о версиях не переносится в поле версии, если в поле установлена 1, а в поле INT_version должны отражаться изменения в INT;

INT_version — если INT_version_flag установлен в 1, версия должна увеличиваться при каждом изменении INT и должна совпадать с номером версии в заголовке раздела I NT.

Таблица 12 — Синтаксис структуры IP/MAC_notificationJnfo

Синтаксис

Количество бит

Мнемоника

IP/MAC_notificationJnfo () {

platformjd_datajength

for (i=0; i<N; i++) {

8

uimsbf

platformjd

24

uimsbf

actionjype

8

uimsbf

reserved

2

bslbf

INT_versioning_flag

1

bslbf

INT_version

}

for (i=0; i<N; i++) {

5

uimsbf

private_data_byte }

}

8

uimsbf

Таблица 13 — Кодирование действий action_type

Тип действия

Спецификация действия

0x00

Зарезервировано

0x01

Локация потоков IP/MAC в сетях DVB

0x02-0xFF

Зарезервировано для будущего использования

Значение поля private_data_byte определяет пользователь.

  • 7.4.3 Тип потока данных таблицы уведомлений IP/MAC

Наличие потока данных INT должно быть указано в разделе «Программная карта» путем установки значения типа этого потока, равного 0x05, или значения, определяемого пользователем.

  • 7.5 Параметры таблицы уведомлений IP/MAC

    7.5.1 Описание таблицы уведомлений IP/MAC

    INT IP/MAC используется с дескриптором data_broadcast_id_descriptor, имеющим значение 0x000В, где action_type устанавливается в одно из значений, указанных в таблице 13.

INT транслируется в формате таблицы SL Максимальная длина секции INT составляет 4096 байт.

INT разделена на субтаблицы. Субтаблица INT является набором секций с одинаковыми значениями полей table_id, platform_id, platformjd и action_type. INT идентифицируется по своим platform_ id и action_type.

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

Все потоки IP/MAC, размещенные в одном транспортном потоке, могут анонсироваться с помощью поля action_type INT, имеющим значение 0x01.

INT, опционально, может анонсировать потоки IP/MAC в других транспортных потоках.

  • 7.5.2 Сигнализация таблиц PSI, SI и связанных INT

РМТ ссылается на INT, включая дескриптор data_broadcast_id_descriptor (data_broadcast_id = 0x000В) в элементарном потоке, где action_type в IP/MAC_Notification_info устанавливается в поле INT action_type. Поле IP/MAC_Notification_info platformjd содержит идентификатор platformjd, соответствующий идентификатору platformjd INT IP/MAC.

  • 7.5.3 Параметры идентификации и локации дескрипторов

Область применения INT IP/МАС включает в себя сигнализацию наличия потоков и сигнализацию локации потоков I Р/М АС в сетях DVB (action_type = 0x01).

Все потоки IP/МАС сети DVB может обрабатывать одна или несколько INT. На INT ссылается data_broadcast_id_descriptor (data_broadcast_id = 0x000В) в цикле ES_info РМТ, где action_type в IP/MAC_Notification_info_structure равен значению поля action_type в INT. Идентификатор platform_ id таблицы INT должен соответствовать полю platform_id, закодированному в одной из субтаблиц INT.

Для обеспечения возможности приемникам поиска необходимой субтаблицы INT, идентификатор платформы в субтаблице INT хэшируется с использованием простой функции XOR и включается как часть table_id_extension (table_id_extension = platform_id_hash + action_type). Определение INT включает объявления потока IP/МАС информацией о локации и других типов операций.

Для обеспечения выполнения других операций поле action_type формирует часть индекса субтаблицы в форме table_id_extension. Для выбора наиболее подходящего action_type используется поле processing_order.

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

Секция субтаблицы разделяется на два независимых цикла:

  • - первый цикл (platform_descriptor_loop) используется для описания платформы IP/МАС, связанной с platform_id;

  • - второй цикл связывает operational_descriptor_loop с target_descriptor_loop.

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

Цикл operation_descriptor_loop содержит дескрипторы, относящиеся к процессам локализации или назначения. Дескрипторы в этом цикле имеют приоритет над дескрипторами в platform_descrip-tor_loop, если иное не указано в функциональном описании дескриптора. Цикл operation_descrip-tor_loop может быть пустым, что означает отсутствие необходимости в дополнительных дескрипторах (помимо тех, что указаны в platform_descriptor_loop).

  • 7.5.4 Параметры синтаксиса и семантики таблицы INT

Синтаксис IP/MAC_notification_section должен соответствовать таблице 14.

Таблица 14 — Синтаксис IP/MAC_notification_section

Синтаксис

Количество бит

Мнемоника

Значение no умолчанию

IP/MAC_notification_section () {

tablejd

8

uimsbf

0x4C

section_syntax_indicator

1

bslbf

1b

reserved_for_future_use

1

bslbf

1b

reserved

2

bslbf

11b

sectionjength

12

uimsbf

action_type

8

uimsbf

platform_id_hash

8

uimsbf

reserved

2

bslbf

11b

version_number

5

uimsbf

current_next_indicator

1

bslbf

1b

section_number

8

uimsbf

last_section_number

8

uimsbf

platformjd

24

uimsbf

processing_order

8

uimsbf

0x00

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

Синтаксис

Количество бит

Мнемоника

Значение по умолчанию

platform_descriptor_loop()

for (i=0, i<N1, i++) {

target_descriptor_loop()

operational_descriptor_loop()

}

CRC_32

}

32

rpchof

Семантика секции полей IP/MAC_notification_section должна быть следующей:

table_id — уникальное для IP/МАС содержит значение INT 0х4С;

section_syntax_indicator— 1-битовое поле должно содержать «1»;

section_length — 12-битовое поле. Содержит количество байтов секции, начиная сразу после section_length и включая CRC. Размер section_length не должен превышать 4093 байт при максимальной длине секции 4 096 байт;

action_type — определяет действие, которое нужно выполнить в соответствии с таблицей 13;

platform_id_hash — определяется использованием XOR для всех трех байтов platform_id между собой для формирования значения:

platform_id_hash = platform_id [23..16] Л platform_id [15..8] л platform_id [7..0];

version_number — содержит номер версии субтаблицы. Номер версии должен увеличиваться на 1 при изменении информации, переносимой в sub_table. Когда номер версии достигает значения 31, номер возвращается к 0. Когда current_next_indicator установлен в 1, то version_number должно соответствовать текущему применяемому sub_table, определяемого значениями table_id, platform_id и action_type. Когда current_next_indicator установлен на 0, version_number должно соответствовать следующему применяемому sub_table, определяемого значениями table_id, platform_id и action_type;

current_next_indicator — с установленной 1, указывает, что sub_table может использоваться в настоящее время. Когда в поле установлен «0», это указывает, что применение отправленного sub_ table еще не допустимо и что действительно применение следующего sub_table;

section_number — содержит номер секции. section_number первой секции sub_table должно содержать значение 0x00, значение section_number должно увеличиваться на 1 с каждой дополнительной секцией (с теми же значениями table_id, platform_id и action_type);

last_section_number — содержит номер секции с наибольшим номером section_number субтаблицы, частью которой является эта секция;

platform_id — является идентификатором данной платформы IP/MAC;

processing_order — указывает последовательность выполнения действий. Если INT требует более одного действия, то это поле может использоваться для указания порядка выполнения этих действий. Кодирование поля processing_order должно выполняться в соответствии с таблицей 15, если для одного и того же идентификатора платформы доступно более одной субтаблицы INT и это поле может использоваться для установки приоритета в разрешении IP/МАС адресов;

Таблица 15 — Кодирование требования processing_order

Требование обработки

Значение

0x00

Первое действие

0x01-OxFE

Последующие действия (по возрастанию)

OxFF

Не применяется

CRC_32 — содержит значение циклического избыточного кода;

platform_descriptor_loop — содержит информацию о платформе IP/МАС, синтаксис platform. descriptor_loop представлен в таблице 16;

Таблица 16 — Синтаксис platform_descriptor_loop

Синтаксис

Количество бит

Мнемоника

platform_descriptor_loop () { reserved

platform_ descriptorjoopjength

for (i=0; i<N1; i++) platform_descriptor()

}

4

12

bslbf uimsbf

target_descriptor_loop — содержит список всех таргетированных устройств, которые должны быть адресованы и к которым применяется рабочий цикл. Это поле цикла дескриптора может содержать дескрипторы целевого IP/MAC-адреса, дескрипторы таргетированной смарт-карты, а также частные и другие дескрипторы. Если этот цикл дескриптора пуст, то рабочий цикл применяется приемниками. Приемник, не распознающий таргетирующий дескриптор (новый или неизвестный таргетирующий дескриптор), должен предполагать, что этот таргетирующий дескриптор не предназначен для этого приемника. Синтаксис target_descriptor_loop представлен в таблице 17;

Таблица 17 — Синтаксис target_descriptor_loop

Синтаксис

Количество бит

Мнемоника

target_descriptor_loop () { reserved

taet_descriptor_loop_length

for (i = 0; i < N1; i++) target_descriptor()

}

4

12

bslbf uimsbf

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

Таблица 18 — Синтаксис operation_descriptor_loop

Синтаксис

Количество бит

Мнемоника

operational_descriptor_loop () { reserved

operational_descriptor_loop_length

for (i = 0; i < N1; i++) operational_descriptor()

}

4

12

bslbf uimsbf

  • 7.5.5 Идентификация и локация дескрипторов таблицы INT

Идентификация и локация дескрипторов таблицы INT должны соответствовать таблице 19.

Таблица 19 — Идентификация и локация дескрипторов INT

Синтаксис

Значение тэга

Разрешено применять в цикле

Платформа

Использование

Оперативный

Зарезервировано

0x00

-

-

-

target_smartcard_descriptor

0x06

-

*

-

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

Синтаксис

Значение тэга

Разрешено применять в цикле

Платформа

Использование

Оперативный

target_MAC_address_descriptor

0x07

-

*

-

target_serial_number_descriptor

0x08

-

*

-

target_IP_address_descriptor

0x09

-

*

-

target_IPv6_address_descriptor

ОхОА

-

*

-

IP/MAC_platform_name_descriptor

ОхОС

*

-

-

IP/MAC_platform_provider_name_descriptor

0x0D

*

-

-

target_MAC_address_range_descriptor

0х0Е

-

*

-

target_IP_slash_descriptor

OxOF

-

*

-

target_IP_source_slash_descriptor

0x10

-

*

-

target_IPv6_slash_descriptor

0x11

-

*

-

target_IPv6_source_slash_descriptor

0x12

-

*

-

IP/MAC_stream_location_descriptor

0x13

*

-

*

ISP_access_mode_descriptor

0x14

*

-

*

IP/MAC_generic_stream_location_descriptor

0x15

*

-

*

telephone_descriptor

0x57

*

-

*

private_data_specifier_descriptor

0x5F

*

*

*

user private

0x80—OxFE

-

-

-

зарезервировано

OxFF

-

-

-

Примечание — «*» означает «да», «-» означает «нет».

Дескрипторы диапазона значений от 0x40 до 0x7F в информации о службах DVB должны иметь стандартную семантику. Дескрипторы в диапазоне значений от 0x00 до 0x3F в INT не используются.

Тэги дескрипторов в диапазоне значений от 0x00 до 0x3F совместно используют пространство имен дескрипторов с дескрипторами таблицы уведомлений об обновлении (UNT).

Все дескрипторы могут появляться несколько раз в субтаблице INT, в местах, указанных в таблице 19.

  • 8 Передача данных средствами карусели данных

    • 8.1 Общие характеристики службы вещания карусели данных

      8.1.1 Общие характеристики карусели данных

      Карусель данных DSM-CC обеспечивает циклическую передачу данных приемником. Данные, передаваемые в карусели данных, размещены в модулях, разделенных на блоки. Все блоки модулей в карусели данных имеют одинаковый размер, за исключением последнего блока каждого модуля, который может быть меньшего размера. Модулями являются логически разделенные отдельные группы данных в карусели данных. По требованию сервисной службы модули могут быть сгруппированы в группу модулей, а группы могут быть объединены в супергруппы.

В спецификации карусели данных используются четыре сообщения загрузки DSM-CC. Данные передаются в сообщениях DownloadDataBlock. Управление модулями данных обеспечивается сообщениями Downloadlnfolndication, DownloadServerlnitiate и DownloadCancel.

Карусели данных могут иметь один или два уровня управления, как показано на рисунке 2.

Карусель данных с одним уровнем управления описывает одну группу данных. В этом случае таблицы SDT и EIT содержат data_broadcast_descriptor, который указывает на сообщение Downloadlnfolndication. Это сообщение описывает модули в карусели данных с помощью поля ModulelnfoByte. Это поле содержит дескрипторы, которые могут содержать необходимую информацию, в том числе указатель на локацию сообщений DownloadDataBlock.



6) Двухуровневая карусель данных


Рисунок 2 — Структура карусели данных

Карусель данных с двумя уровнями управления для описания различных групп в супергруппе использует сообщение DownloadServerlnitiate.

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

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

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

  • - тэг компонента, указатель на конкретный поток в службе;

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

Приемники могут использовать значения для выделения сообщений из потока. В сообщениях DownloadServerlnitiate и Downloadinfoindication указываются параметры модулей и блоков согласно ГОСТ Р 53528—2009, (приложение И, подпункты И.3.2.2, И.3.2.6).

Настоящий стандарт предусматривает использование дескриптора compatibilityDescriptor по прямой ссылке от сообщения DownloadServerlnitiate к сообщениям Downloadinfoindication.

Дескриптор compatibilityDescriptor сообщения DSI находится в поле Grouplnfolndication и groupCompatibility (). Все сообщения DownloadDataBlock и Downloadlnfolndication внутри супергруппы (в случае двухуровневой карусели данных) или группы (в случае одноуровневой карусели данных) имеют одинаковые идентификаторы загрузки. Это означает, что группы могут совместно использовать модули, потому что все module_id уникальны в границах применения downloaded.

Каждое управляющее сообщение содержит уникальный идентификатор сообщения transaction-id. Идентификаторы transaction_id и module_id допускается использовать для выделения данных из карусели данных на основе ниже приведенной семантики.

Двухуровневая карусель:

  • - для сообщений DownloadServerlnitiate два младших байта идентификатора транзакции должны находиться в диапазоне значений от 0x0000 до 0x0001;

  • - для сообщений Downloadlnfolndication два младших байта идентификатора транзакции должны находиться в диапазоне значений от 0x0002 до OxFFFF.

В случае одноуровневой карусели в сообщениях Downloadlnfolndication два младших байта идентификатора транзакции должны находиться в диапазоне значений от 0x0000 до 0x0001.

  • 8.1.2 Параметры сообщения DownloadServerlnitiate

Сообщение DownloadServerlnitiate используется для создания супергруппы при перечисленной ниже семантике карусели данных:

server_id (20 байт) должно содержать значение OxFF;

compatibleDescriptor () должно содержать поле compatibilityDescriptorLength, в котором должно быть установлено значение 0x0000;

privatedatalength определяет длину в байтах структуры Grouplnfolndication;

privateDataByte должно передавать структуру Grouplnfolndication

с синтаксисом полей, определенным в таблице 20.

Таблица 20 — Структура Grouplnfolndication

Синтаксис

Количество байтов

Grouplnfolndication () {

NumberOfGroups

for (i=0; i< numberOfGroups; i++) {

2

Groupld

4

GroupSize

GroupCompatibility ()

4

GroupInfoLength for (i=0; i<N; I++) {

2

groupInfoByte }

1

}

PrivateDataLength

for (i=0; i< privateDataLength; i++) {

2

privateDataByte }

}

1

Семантика структуры Grouplnfolndication должна быть следующей: numberOfGroups — содержит количество групп, описанных в цикле, следующем за этим полем; groupld — содержит значение поля transactions сообщения Downloadlnfolndication, описыва

ющего группу;

groupSize — содержит значение общего размера в байтах всех модулей в группе;

groupCompatibility — имеет структуру, соответствующую структуре дескриптора CompatibilityDescriptor в DSM-CC;

groupInfoLength — указывает длину в байтах следующего цикла дескриптора;

groupInfoByte — содержит список дескрипторов, каждый из которых определяет один или несколько атрибутов. Дескрипторы, включенные в цикл, описывают характеристики группы данных;

privateDataLength — определяет длину в байтах полей privateDataByte. Содержание поля privateDataByte определяет пользователь.

  • 8.1.3 Сообщение Downloadlnfolndication

Сообщение Downloadlnfolndication содержит описание модулей в группе, а также общие параметры карусели данных (например, downloadld и blockSize). Каждый модуль описывается рядом атрибутов. Атрибуты moduleld, moduleSize и moduleVersion являются полями в сообщении Downloadlnfolndication от DSM-CC. Другие атрибуты модуля должны передаваться в виде дескрипторов. Диапазон значений moduleld от OxFFFO до OxFFFF зарезервирован для приложений, совместимых с DAVIC.

Семантика сообщения Downloadlnfolndication для карусели данных DVB должна быть следующей: compatibleDescriptor() должна содержать поле compatibilityDescriptorLength для compatibilityDescriptor(), как определено DSM-CC.В поле compatibilityDescriptorLength должно быть установлено значение 0x0000;

moduleinfoLength определяет длину в байтах поля moduleinfo для описываемого модуля;

modulelnfoByte должно содержать список дескрипторов, каждый из которых определяет один или несколько атрибутов описанного модуля, за исключением случаев, когда moduleld находится в диапазоне значений от OxFFFO до OxFFFF. В этом случае структура modulelnfoByte содержит структуру Moduleinfo с полем privateDataByte этой структуры в виде цикла дескрипторов;

privateDataLength определяет длину в байтах поля privateDataByte. Содержание поля privateDataByte определяет пользователь.

  • 8.1.4 Сообщение DownloadDataBlock

Сообщения DownloadDataBlock содержат блоки фрагментированных модулей. Они передаются в полезной нагрузке пакетов транспортного потока MPEG-2, как указано в DSM-CC согласно ГОСТ Р 53528—2009 (приложение И).

  • 8.1.5 Сообщение DownloadCancel

Сообщение DownloadCancel сообщает приемникам, что карусель данных прервала периодическую передачу модулей. Сообщения DownloadCancel могут быть отправлены на уровне группы или супергруппы. Они передаются в полезной нагрузке пакетов транспортного потока MPEG-2 согласно ГОСТ Р 53528—2009, (приложение И).

  • 8.2 Параметры дескрипторов карусели передачи данных

    8.2.1 Характеристики идентификации и локации дескриптора

    Характеристики идентификации и локации дескриптора должны быть в соответствии с таблицей 21, которая содержит дескрипторы, определенные спецификациями карусели данных DVB. Эти дескрипторы имеют собственное пространство тэгов частных дескрипторов.

Таблица 21 — Характеристики идентификации и локации дескриптора

Наименование дескрипторов

Величина тэга

Dll-modulelnfo

DSI-groupinfo

Краткое описание

Зарезервирован

0x00

-

-

-

Туре

0x01

+

+

Тип дескрипторов данных

Name

0x02

+

+

Имя дескрипторов данных

Info

0x03

+

+

Текстовый дескриптор

modulejink

0x04

+

-

Модуль связанных данных

CRC32

0x05

+

-

Циклический контроль по четности

Location

0x06

+

+

Данные локации

est_downloadjime

0x07

+

+

Расчетное время загрузки

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

Наименование дескрипторов

Величина тэга

Dll-modulelnfo

DSI-g roupinfo

Краткое описание

groupjink

0x08

-

+

Сообщения сцепления DII с описанием группы

compressed_module

0x09

+

-

Индикация структуры компрессии

SSU_module_type

ОхОА

+

-

Система обновления программного обеспечения в системе DVB

subgroup_association

0x0В

-

+

Система обновления программного обеспечения в системе DVB

Примечание — «+» означает применяется, «-» означает не применяется.

Распределение значений тэгов для частных дескрипторов карусели данных DVB представлено в таблице 22.

Таблица 22 — Распределение значений тэгов для частных дескрипторов карусели данных DVB

Тэги частных дескрипторов карусели данных DVB

Значения

От 0x00 до 0x0В

Распределены DVB в таблице 21

От ОхОС до 0x6F

Зарезервированы для применений в DVB

От 0x70 до 0x7 F

Зарезервированы для применений в DVB МНР

От 0x80 до OxFF

Частные дескрипторы

  • 8.3 Параметры информации о конкретной программе (PSI) и информации о службах (SI) при использовании карусели данных

    • 8.3.1 Общие правила

Служба вещания данных должна указывать на использование карусели данных включением одного или нескольких дескрипторов data_broadcast_descriptors в SI [ГОСТ Р 52591—2006 (подпункты 5.1.2.6, 5.1.2.8)]. Каждый дескриптор должен быть связан с конкретным потоком через идентификатор. Значение поля component_tag должно быть идентично значению поля component_tag дескриптора stream_identifier_descriptor согласно ГОСТ Р 52591—2006 (подпункт 5.1.2.7), которое может присутствовать в секции PSI используемого потока данных.

  • 8.3.2 Параметры семантики дескриптора data_broadcast_descriptor

Семантика дескриптора data_broadcast_descriptor должна соответствовать следующим требованиям:

data_broadcast_id должно содержать значение 0x0006, идентифицирующее карусель данных DVB;

component_tag должно содержать значение, что и поле component_tag дескриптора stream_ identifier_descriptor (если присутствует в секции PSI) потока, который используется для вещания карусели данных;

selector_length должно содержать значение 0x10;

selector_byte должно содержать структуру data_carousel_info, синтаксис которой должен быть в соответствии с таблицей 23.

Таблица 23— Синтаксис структуры data_carousel_info_structure

Синтаксис

Количество бит

Мнемоника

data_carousel_info () {

carousel_type_id

2

bslbf

reserved

6

bslbf

transactionjd

32

uimsbf

time_out_value_DSI

32

uimsbf

time_out_value_DII

32

uimsbf

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

Синтаксис

Количество бит

Мнемоника

reserved leak_rate

}

2

22

bslbf

bslbf

Семантика полей структуры data_carousel_info должна быть следующей:

carousel_type_id — 2-битовое, указывает тип карусели данных. Кодирование типов карусели данных должно быть в соответствии с таблицей 24;

Таблица 24 — Типов карусели данных

Типы карусели данных

Значение

00

Зарезервировано

01

Карусель одного уровня управления

10

Карусель двух уровней управления

11

Зарезервировано

reserved — должно содержать значение 111111;

transaction_id — 32-битовое поле, должно иметь то же значение, что и значение transactions сообщения DownloadServerlnitiate или сообщения Downloadinfoindication. Значение OxFFFFFFFF указывает приемникам, что любое полученное сообщение DownloadServerlnitiate (в случае двухуровневой карусели) или сообщение Downloadinfoindication (в случае одноуровневой карусели) в соответствующем потоке является действительным;

time_out_value_DSI — 32-битовое поле, указывает рекомендуемый период ожидания в миллисекундах, который приемники должны ожидать для получения сообщения DownloadServerlnitiate. Значение OxFFFFFFFF указывает приемникам, что рекомендуемый период ожидания не пересылается;

time_out_value_DII — 32-битовое поле, указывает рекомендуемый период ожидания в миллисекундах, который приемники должны использовать для ожидания получения сообщения Downloadinfoindication. Значение OxFFFFFFFF указывает приемникам, что рекомендуемый период ожидания не пересылается;

reserved — 2-битовое поле, должно содержать значение 11;

leak_rate — 22-битовое поле, должно указывать скорость leak Rxn модели декодера карусели данных, которая применяется сервисной службой. Скорость leak Rxn кодируется как 22-битовое положительное целое число. Значение одного шага (уровня, единицы) для поля leak_rate соответствует 50 байт/с.

  • 8.3.3 Тип потока

Наличие карусели данных в службе должно быть указано в РМТ установкой значения типа потока 0x0В или значения, определенного пользователем.

  • 9 Передача данных средствами карусели объектов

    • 9.1 Область применения службы вещания карусели объектов

Карусели объектов должны поддерживать службы периодического вещания объектов DSM-CC от пользователя к пользователю (U-U) через совместимые DVB-сети вещания, в частности, для системы интерактивных служб (Systems for Interactive Services; SIS) DVB.

  • 9.2 Спецификация карусели объектов

    9.2.1 Введение

    Спецификация карусели объектов DVB основана на спецификации карусели объектов DSM-CC. Карусель объектов DVB представляет собой домен службы, который состоит из набора объектов DSM-CC U-U в сети DVB. Шлюз службы в составе домена службы предоставляет приемникам граф имен служб и объектов.

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

  • 9.2.2 Параметры адреса NSAP карусели

Адрес NSAP должен иметь структуру, представленную на рисунке 3.

AFI 1-байт

Туре 1-байт

carouselld 4-байта

specifier 4-байта

privateData 10-байт

Рисунок 3 — Структура адреса NSAP карусели

Семантика полей адреса NSAP карусели должна соответствовать изложенному ниже:

AFI должно содержать значение 0x00, указывающее использование формата NSAP для частного использования;

Туре (8-битовое поле) должно содержать значение 0x00, указывающее на использование адреса NSAP для каруселей объектов;

carouselld (32-битовое поле) должно содержать идентификатор каруселей объектов;

specifier (32-битовое поле), должно содержать поле спецификатора (установленное на значение 0x01) и код уникального идентификатора организации (OUI), определенного для DSM-CC органом регистрации;

privateData должно содержать структуру dvb_service_location, синтаксис которой должен соответствовать таблице 25.

Таблица 25 — Синтаксис структуры DVB_service_location

Синтаксис

Количество бит

Мнемоника

DVB_service_location () {

transport_stream_id

16

uimsbf

org_network_id

16

uimsbf

servicejd

16

uimsbf

Reserved

32

bslbf

}

Семантика полей структуры dvb_service_location должна соответствовать следующим требованиям: transport_stream_id (16-битовое поле) идентифицирует транспортный поток, в котором транслируется карусель;

org_network_id (16-битовое поле) идентиффицирует систему доставки данных для карусели объектов;

service_id (16-битовое поле) определяет идентификатор службы, содержащую карусель объектов. Значение Service_id совпадает со значением program_number в соответствующей секции рго-gram_map_section;

reserved зарезервировано для использования в будущем.

  • 9.3 Параметры дескрипторов карусели объектов

    9.3.1 Использование дескрипторов карусели данных

    Дескрипторы, определенные для каруселей данных DVB в 8.2, могут использоваться в каруселях объектов DVB.

    • 9.3.2 Характеристики информации о конкретной программе (PSI) и информации о службах (SI)

Служба вещания данных при работе в режиме карусели объектов DVB, включает в SI не менее одного дескриптора data_broadcast_descriptors. Каждый дескриптор должен указывать на одну карусель объектов DVB и должен быть связан с конкретным потоком через идентификатор. Значение поля component_tag должно быть идентично значению поля component_tag дескриптора stream_ identifier_descriptor, который может присутствовать в секции PSI используемого потока данных.

Каждый дескриптор data_broadcast_descriptor позволяет запускать протоколы более высокого уровня на основе языкового критерия с использованием списка имен объектов.

Карусель объектов DVB может использовать нескольких служб вещания данных. Службы вещания данных могут публиковать информацию о том, что они являются частью конкретной карусели объектов DVB путем включения дескриптора carousel_identifier_descriptor в первом цикле дескрипторов таблицы структуры программ (РМТ) MPEG-2 в соответствии с ГОСТ Р 53528—2009 (приложение М, пункт М.3.2).

Карусель объектов DVB для идентификации потоков, в которых транслируются объекты, может использовать дескриптор association_tag, или дескриптор stream_identifier_descriptor. В последнем случае предполагается, что поле component_tag дескриптора stream_identifier является младшим значащим байтом указанного значения association_tag, для которого в старшем байте установлено значение 0x00.

Объекты потоков в карусели объектов U-U могут быть связаны с элементарными потоками самой службы вещания данных, с элементарными потоками других служб DVB или с завершенными службами DVB. Если поток привязан к элементарным потокам других служб DVB или к службам DVB, то таблица отображения программ службы вещания данных должна включать в первом цикле дескрипторов дескриптор deferred_association_tags_descriptor. Дескриптор deferred_association_tags_descriptor описан в 9.3.4.

  • 9.3.3 Характеристики дескриптора data_broadcast_descriptor

Семантика полей в составе дескриптора data_broadcast_descriptor должна быть следующей: data_broadcast_id должно содержать значение 0x0007, указывающее карусель объектов DVB;

component_tag должно иметь то же значение, что и поле component_tag дескриптора stream_ identifier_descriptor (если присутствует в таблице PSI) потока, который используется для вещания карусели объектов;

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

selector_byte должно содержать структуру object_carousel_info, синтаксис которой определяется в соответствии с таблицей 26.

Таблица 26 — Синтаксис структуры object_carousel_info

Синтаксис

Количество бит

Мнемоника

object_carousel_info () {

carousel_type_id

2

bslbf

reserved

6

bslbf

transactionjd

32

uimsbf

time_out_value_DSI

32

uimsbf

ti me_out_va I ue_D 11

32

uimsbf

reserved

2

bslbf

leak_rate

for (i=0; i<N; i++) {

22

uimsbf

ISO_639_language_code

24

bslbf

object_name_length

for (i=0; i<N; i++) {

8

uimsbf

object_name_char

}

}

}

8

uimsbf

Семантика структуры object_carousel_info должна быть следующей:

carousel_type_id (двухбитовое поле) должно содержать значение 10, указывающее на двухуровневую карусель;

reserved (6-битовое поле) должно содержать значение 111111;

transaction_id (32-битовое поле) должно иметь то же значение, что и значение transactions сообщения DownloadServerlnitiate, которое содержит ссылку на объект шлюза службы. Значение OxFFFFFFFF указывает приемникам, что любое полученное сообщение DownloadServerlnitiate в соответствующем потоке является допустимым;

time_out_value_DSI (32-битовое поле), сообщает приемникам рекомендуемый период ожидания в миллисекундах с, который приемники должны использовать для ожидания получения сообщения DownloadServerlnitiate. Значение OxFFFFFFFF указывает приемникам, что рекомендуемое значение времени ожидания не пересылается;

time_out_value_DII (32-битовое поле), сообщает приемникам рекомендуемый период ожидания в миллисекундах, который приемники должны использовать для ожидания получения сообщения Downloadinfoindication. Значение OxFFFFFFFF сообщает приемникам, что рекомендуемое значение периода ожидания не пересылается;

reserved (2-битовое поле) должно содержать значение 11;

leak_rate указывает скорость вывода данных Rxn модели декодера карусели данных, которая применяется службой. Скорость вывода данных кодируется как 22-битовое положительное целое число. Значение leak_rate выражается в единицах по 50 байт/с;

ISO_639_language_code (24-битовое поле) содержит трехсимвольный языковой код ISO 639-2, который используется для выбора объекта, необходимого для запуска протоколов более высокого уровня;

object_name_length (8-битовое поле) определяет количество байтов, которые следуют за полем object_name_length для описания символов имени объекта;

object_name_char (8-битовое поле) определяет имя объекта, которое будет использоваться для запуска протоколов более высокого уровня.

  • 9.3.4 Характеристики дескриптора deferred_association_tags_descriptor ()

Синтаксис дескриптора deferred_association_tags_descriptor () в DVB-совместимых сетях — в соответствии с таблицей 27.

Таблица 27— Синтаксис дескриптора deferred_association_tags_descriptor

Синтаксис

Количество бит

Мнемоника

deferred_association_tags_descriptor () { descriptor_tag

descriptorjength

association_tags_loop_length

for (i=0; i<N; i++) {

association_tag

}

transport_stream_id

program_number

for (i=0; i<N; i++) { private_data_byte

}

}

8

8

8

16

16

16

8

uimsbf uimsbf uimsbf

uimsbf

uimsbf uimsbf

uimsbf

Семантика полей в составе deferred_association_tags_descriptor должна быть следующей: descriptor_tag (8-битовое поле) должно содержать десятичное значение «21»;

descriptor_length (8-битовое поле) должно содержать длину дескриптора в байтах;

association_tags_loop_length (8-битовое поле) должно содержать длину в байтах цикла тэгов ассоциации, который следует за этим полем;

association_tag (16-битовое поле) должно содержать тэг, который связан или с потоком, не являющимся частью этой службы вещания данных, или с другой службой DVB;

transport_stream_id (16-битовое поле) должно идентифицировать транспортный поток, в котором находится служба, связанная с включенными в список тэгами ассоциации;

program_number (16-битовое поле) должно содержать service_id службы, которая связана с включенными тэгами ассоциации;

private_data_byte должно содержать структуру deferred_service_location, синтаксис структуры deferred_service_location которой определен в таблице 28.

Таблица 28 — Синтаксис структуры deferred_service_location

Синтаксис

Количество бит

Мнемоника

deferred_service_location () { org_network_id

for (i=0; i<N, i++) { private_data_byte

}

}

16

8

uimsbf

uimsbf

Семантика структуры deferred_service_location должна быть следующей: org_network_id (16-битовое поле) должно содержать network_id системы доставки, из которой исходит служба.

Значение private_data_byte определяет пользователь.

  • 9.3.5 Характеристики типа потока

Присутствие карусели объектов в службе должно быть указано в таблице структуры программы (РМТ) этой службы установкой для типа потока, содержащего карусель данных, значение 0x0В или значения, определяемого пользователем.

  • 10 Высшие протоколы передачи асинхронных потоков данных

    • 10.1 Спецификация высших протоколов передачи данных

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

  • - в один пакет PES можно вставить несколько кадров;

  • - кадр может быть распределен по нескольким пакетам PES;

  • - биты заполнения должны использоваться для кадров, которые не выровнены по байтам. Эти биты должны быть расположены в конце кадра и установлены в «0».

  • 10.2 Характеристики информации о конкретной программе (PSI) и информации о службе (SI)

    10.2.1 Общие правила

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

Каждый дескриптор вещания должен быть связан с потоком через идентификатор component-tag. Значение поля component_tag должно быть идентично значению поля component_tag дескриптора stream_identifier_descriptor, которое может присутствовать в таблице PSI потока, который используется для передачи кадров.

  • 10.2.2 Характеристики дескриптора data_broadcast_descriptor

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

data_broadcast_id должно содержать значение 0x0009, указывающее на использование передачи высших протоколов через асинхронные потоки данных;

component_tag должно иметь то же значение, что и поле component_tag дескриптора stream_ identifier_descriptor, которое может присутствовать в секции информации о программе, используемого потока данных;

selector_length должно содержать общее количество selector_bytes;

selector_byte должно содержать структуру higher_protocol_asynchronous_data_info, синтаксис которой определен в таблице 29.

Таблица 29 — Синтаксис структуры higher_protocol_asynchronous_data_info

Синтаксис

Количество бит

Мнемоника

higher_protocol_asynchronous_data_info () { higher_protocol_id

4

uimsbf

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

Синтаксис

Количество бит

Мнемоника

reserved

for (i=0; i<N; i++) {

private_data_byte

}

}

4

8

bslbf

bslbf

Семантика структуры higher_protocol_asynchronous_data_info должна быть следующей: higher_protocol_id должно указывать протокол, который используется поверх асинхронной потоковой передачи данных. Кодирование этого поля должно соответствовать таблице 30.

Таблица 30 — Кодирование higher_protocol_id

Тэг

Высший протокол

0x00

Зарезервировано

0x01

По стандарту для дифференциальных глобальных навигационных спутниковых систем (Global Navigation Satellite Systems; GNSS)

0x02

По правилам передачи информации через потоки данных (Transport Protocol Experts Group; TPEG)

От 0x03 до 0x0F

Зарезервировано

Значение private_data_byte определяет пользователь.

  • 10.2.3 Тип потока

Присутствие многопротокольного потока данных в службе должно быть указано в разделе программы (РМТ) этой службы установкой для типа этого потока значения 0x06 или значения пользователя.

  • 11 Модель декодера

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

На рисунке 4 показана структура модели декодера службы данных для потока данных п, которая аналогична модели целевого декодера транспортной системы (T-STD).

i-й байт потока данных п

соответствии с

максимальной


скорости передачи данных


дескриптором сглаживающего буфера

ТЬП — транспортный буфер для потока данных п; Вп — главный буфер для потока данных n; Rxn — скорость, с которой данные удаляются из Tbn; Rn — скорость, с которой данные удаляются из Вп.

Рисунок 4 — Модель декодера службы данных

Полные пакеты транспортного потока (TS), содержащие данные из потока данных п, вводятся в транспортный буфер ТЬП, потока п.

Байты, поступающие в буфер ТЬП, выводятся из него со скоростью Rxn. Байты, которые являются частью пакета PES, секций или контента этих контейнеров, доставляются в главный буфер Вп. Остальные байты не используются и могут применяться для управления системой. Дублирующие пакеты TS в Вп не доставляются. Все байты, поступающие в буфер Вп, выводятся из него со скоростью Rn, указанной ниже.

Емкость транспортного буфера ТЬП составляет 512 байтов.

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

Служба может указывать значения для Rxn, Вп и Rn с помощью дескрипторов MPEG-2 maximum_ bit_rate_descriptor и smoothing_buffer_descriptor. Если они используются, дескрипторы должны быть включены в SDT или EIT, а также в РМТ службы.

maximum_bit_rate дескриптора maximiim_bit_rate должно содержать значение Rxn.

sb_size дескриптора smoothing _buffer_descriptor должно содержать значение Вп. sb_leak_rate должно содержать значение Rn.

Если дескриптор maximum_bit_rate_descriptor не включен в SI и PSI, но включен дескриптор smoothing_buf-fer_descriptor, то Rxn = 1,2Rn.

Если дескриптор smoothing_buffer_descriptor не включен в SI и PSI, а включен дескриптор maximum_bit_rate_descriptor, модель с двумя буферами становится моделью, содержащей только транспортный буфер ТЬП со скоростью вывода данных Rxn.

Если ни один из дескрипторов не включен в SI и PSI, описанная модель буфера неприменима. В этом случае способ доставки битов определяется службой.

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

Набор услуг Bouquet_ID

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

Шаблон регистрации идентификатора bouquetJD приведен в таблице А.1.

Для регистрации bouquetJD кандидаты должны предоставить информацию, помеченную как «обязательная» в таблице А.1.

Таблица А.1 — Шаблон регистрации bouquetJD

Поле регистрации

Обязательность заполнения

Описание

Имя BouquetJD

Обязательно

Имя BouquetJD (например, «АСМЕ Рау-TV, Inc.»)

Код страны BouquetJD

Обязательно

Описание кода страны

Оператор BouquetJD

Обязательно

Название организации, которая управляет набором услуг BouquetJD (например, «АСМЕ Рау-TV, Inc.»)

Юридический контакт оператора BouquetJD

Обязательно

Имя и адрес электронной почты уполномоченного законного лица, подписавшего BouquetJD

Технический контакт BouquetJD

Обязательно

Имя и адрес электронной почты контактного лица по техническим вопросам компании BouquetJD

Примечания к BouquetJD

Опционально

Примечания к заявке, например последняя редакция и какие изменения были внесены

УДК 621.397.132.129:006.354

ОКС 33.170


Ключевые слова: телевидение вещательное цифровое, DVB-IPTV, провайдер, транспортный поток

MPEG-2, вещание медиа, контент, карусель данных, карусель объектов, INT

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

Сдано в набор 28.10.2021. Подписано в печать 24.11.2021. Формат 60x84%. Гарнитура Ариал. Усл. печ. л. 4,18. Уч.-изд. л. 3,38.

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

Создано в единичном исполнении в ФГБУ «РСТ» , 117418 Москва, Нахимовский пр-т, д. 31, к. 2.