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

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

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

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

Технические требования 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

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

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

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

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

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

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

Семантика полей в составе 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

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

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

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

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-битовое поле должно указывать количество байтов МАС-адреса, которые служба использует для различения приемников в соответствии с таблицей 7;

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

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

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

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

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

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

Ниже представлена семантика полей в составе дескриптора сцепления типа 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 — Синтаксис дескриптора сцепления типа ОхОС

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

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

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

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

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

Значение поля 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

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

Семантика секции полей 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

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

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

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

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

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

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

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

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

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

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

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

Дескрипторы диапазона значений от 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.

Рисунок 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 — содержит количество групп, описанных в цикле, следующем за этим полем; 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 — Характеристики идентификации и локации дескриптора

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

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

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

• 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

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

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

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

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

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 Rx_n модели декодера карусели данных, которая применяется сервисной службой. Скорость leak Rx_n кодируется как 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.

Рисунок 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-битовое поле) идентифицирует транспортный поток, в котором транслируется карусель;

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 (двухбитовое поле) должно содержать значение 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 указывает скорость вывода данных Rx_n модели декодера карусели данных, которая применяется службой. Скорость вывода данных кодируется как 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 (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 (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

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

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

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

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

• 10.2.3 Тип потока

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Набор услуг Bouquet_ID

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

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

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

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

УДК 621.397.132.129:006.354

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

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

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

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

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

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