ГОСТ Р 54997-2012 Система цифрового звукового радиовещания DRM. Цифровое звуковое радиовещание DAB. Требования транспортировки и бинарного кодирования для электронного справочника программ (EPG)

ГОСТ Р 54997-2012

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

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

Требования транспортировки и бинарного кодирования для электронного справочника программ (EPG)

Digital radio mondiale (DRM). Digital audio broadcasting (DAB). Transportation and binary encoding specification for electronic programme guide (EPG)

ОКС 33.170

ОКПО 657300

Дата введения 2013-04-01

Предисловие

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

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

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

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

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

4 Настоящий стандарт разработан с учетом основных нормативных положений Европейского института по стандартизации в области телекоммуникаций (ETSI) ЕТСИ "Цифровое вещание аудио; Всемирное цифровое радио. Требования транспортировки и бинарного кодирования для электронного справочника программ (EPG)* (ETSI TS 102 371 V1.2.1 (2006-02) Technical Specification. Digital Audio Broadcasting (DAB); Digital Radio Mondiale (DRM); Transportation and Binary Encoding Specification for Electronic Programme Guide (EPG)

________________

* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - .

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

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

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

Настоящий стандарт распространяется на параметры процессов кодирования, профилирования, передачи данных и сигнализации электронного справочника программ (Electronic Programme Guide; EPG) для систем цифрового звукового радиовещания (Digital Audio Broadcasting; DAB) и системы Всемирного цифрового радио (Digital Radio Mondiale; DRM).

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

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

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

ГОСТ Р 54462-2011 Система цифрового радиовещания DRM. Требования и параметры

МСЭ-Р Регламент радиосвязи (ITU-R Radio Regulations)

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

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

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

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

3.1.2 данные, связанные с программой (Programme Associated Data; PAD): Информация, которая связана с аудиоданными с точки зрения содержания и синхронизации. Поле PAD расположено в конце аудио кадра DAB.

3.1.3 заголовок МОТ (МОТ header): Этот объект МОТ содержит информацию о заголовке, которая описывает одно единственное тело МОТ.

3.1.4 идентификатор ансамбля (Ensemble Identifier; Eld): Уникальный 16-разрядный код, выделенный ансамблю и предназначенный для однозначной глобальной идентификации этого ансамбля.

3.1.5 канал описания службы (Service Description Channel; SDC): Канал мультиплексированного потока данных, который переносит информацию, необходимую для декодирования служб, включенных в мультиплекс.

3.1.6 объект МОТ (МОТ entity): Единственное тело МОТ или единственный каталог МОТ или единственный заголовок МОТ.

3.1.7 приложение пользователя (User application): Приложение данных, определенное в отдельном стандарте и загружаемое данными через DAB.

3.1.8 расширенная часть PAD (eXtended - Programme Associated Data; X-PAD): Расширенная часть данных, связанных с программой, которая переносится в конце аудио кадра DAB сразу перед CRC, ее длина является переменной.

3.1.9 служба, сервис, услуга (service): Составная часть службы (услуги).

3.1.10 тело МОТ (МОТ body): Тело МОТ переносит любой вид данных конечной длины. Информация о теле МОТ содержится в заголовке МОТ.

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

СА (Conditional Access) - условный доступ;

CDATA (string data) - данные строки;

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

CRID (Content Reference ID) - идентификатор ссылки контента;

CS (classification scheme) - схема классификации;

DAB (Digital Audio Broadcasting) - цифровое звуковое радиовещание;

Deflate - алгоритм сжатия без потерь, использующий комбинацию алгоритма LZ77 и алгоритма Хаффмана;

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

ЕСС (Extended Country Code) - расширенный код страны;

Eld (Ensemble Identifier) - идентификатор ансамбля;

EPG (Electronic Programme Guide) - электронный справочник программ;

FIG (Fast Information Group) - группа быстрой информации;

Gl (Group Information) - информация о группе;

GZIP (GNU Zip) - утилита (программа) компрессии и декомпрессии, использующая алгоритм DEFLATE;

ISO (International Organization for Standardization) - Международная организация по стандартизации;

LTO (Local Time Offset) - смещение местного времени;

MIME (Multipurpose Internet Mail Extensions) - многоцелевые расширения почты Интернет;

MJD (Modified Julian Date) - измененная юлианская дата;

MOT (Multimedia Object Transfer) - передача мультимедийного объекта;

Mux (multiplex) - мультиплекс;

N/A (not available) - нет данных;

PAD (Programme Associated Data) - данные, связанные с программой;

PI (Programme Information) - информация о программе;

PNum (Programme Number) - количество программ;

Rfa (Reserved for future addition) - зарезервировано для будущего дополнения;

Rfu (Reserved for future use) - зарезервировано для будущего использования;

SCIdS (Service Component Identifier within the Service) - идентификатор компонента службы в службе (в рамках службы);

SDC (Service Description Channel) - канал описания службы;

SI Service Information - информация о службе;

Sid (Service Identifier) - идентификатор службы;

UA (User application) - приложение пользователя;

URL (Uniform Resource Location) - унифицированный локатор (определитель местонахождения) ресурса;

UTC (Co-ordinated Universal Time) - всемирное координированное время;

XML (eXtensible Markup Language) - расширяемый язык разметки;

X-PAD (eXtended - Programme Associated Data) - расширенная часть PAD.

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

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

Раздел содержит описание двоичного кодирования совокупности tag-length-value. В этом случае каждый элемент или атрибут закодированы при использовании уникального значения тега, значения длины (указание на длину данных содержится в пределах этого элемента или атрибута) и фактического значения данных. Это позволяет приемникам пропускать ненужные или неидентифицированные элементы. На рисунке 1 показана схема кодирования совокупности tag-length-value.

Рисунок 1 - Схема кодирования совокупности tag-length-value

В этих двоичных структурах закодированы элементы XML в соответствии с 4.3 настоящего стандарта. Атрибуты кодированы аналогичным образом в соответствии с 4.5 настоящего стандарта. В этих двоичных структурах иерархическая природа XML EPG обычно сохранена. Различным типам общих данных присваиваются эффективные двоичные кодировки в соответствии с 4.8 настоящего стандарта. Пример кодирования двоичного файла объекта XML приведен в приложении А.

4.2 Требования к синтаксису

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

Таблица 1 - Мнемоника типа данных для спецификации синтаксиса

4.3 Двоичные объекты

Структура двоичного объекта, определенная настоящим стандартом, приведена в таблице 2. Каждый двоичный объект переносит единственный элемент высокого уровня в пределах единственного объекта МОТ.

Таблица 2 - Структура двоичного объекта

top_level_element() - элемент высокого уровня, определенный в 4.4.2 настоящего стандарта.

4.4 Элементы

4.4.1 Кодирование элемента

Все элементы кодируются в соответствии с таблицей 3.

Таблица 3 - Структура элемента. Кодирование элемента

element_tag: Это поле идентифицирует элемент. Если в будущем возникнут потребности в новых элементах, то для них будут использоваться новые значения тега. Возможные значения определены в соответствии с приложением Б. Элементы с тегами, которые не определены, зарезервированы для использования в будущем. Приемники не должны обрабатывать эти теги и связанный с ними контент.

element_length: Это поле указывает на количество байтов данных, содержащихся в этом элементе. Диапазон значений этого поля от 0x00 до 0xFD (от 0 до 253). Если поле element_length принимает значения 0xFE или 0xFF, то длину элемента определяет дополнительное поле extended_element_length.

extended_element_length: Это поле указывает на количество байтов данных, содержащихся в этом элементе.

element_data_byte: Эти байты содержат атрибуты элемента, данные CDATA и дочерние элементы. Они кодируются в следующем порядке:

- атрибуты;

- дочерние элементы;

- контент СDATA.

4.4.2 Элементы высокого уровня

Настоящий стандарт определяет требования к двум элементам высокого уровня: epg и servicelnformation. Элемент высокого уровня переносится в границах двоичного объекта (согласно 4.3 настоящего стандарта), он должен быть единственным элементом в этом объекте (кроме вложенных в него дочерних элементов).

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

Таблица 4 - Теги элементов высокого уровня

Так же как и соответствующие элементы, определенные спецификацией EPG XML, элементы высокого уровня опционально могут содержать строковую маркерную таблицу (согласно 4.10 настоящего стандарта) и "по умолчанию" идентификатор contentID (согласно 4.11 настоящего стандарта). Эти элементы должны быть первыми в элементе высокого уровня после атрибутов.

Элемент высокого уровня должен кодироваться таким же образом, как и нормальный элемент (согласно 4.4 настоящего стандарта) за исключением того, что element_data_bytes должен быть закодирован в следующем порядке:

- атрибуты;

- строковая маркерная таблица (если есть);

- значение contentID "по умолчанию" (если есть);

- дочерние элементы;

- контент CDATA.

4.5 Атрибуты

4.5.1 Кодирование атрибута

Кодирование атрибутов выполняется в соответствии с данными, представленными в таблице 5.

Таблица 5 - Структура атрибута. Кодирование атрибута

attribute_tag: Это поле однозначно определяет атрибут в родительском элементе. Возможные значения определены в соответствии с приложением В. Атрибуты с тегами, которые не определены здесь, зарезервированы для будущего использования и не должны обрабатываться приемниками.

attribute_length: Это поле указывает на количество байтов данных, содержащихся в этом атрибуте. Диапазон значений от 0x00 до 0xFD (от 0 до 253). Если в поле записано значение 0xFE или 0xFF, тогда длину атрибута определит дополнительное поле extended_attribute_length.

extended_attribute_length: Это поле указывает на количество байтов данных, содержавшихся в этом атрибуте.

attribute_data_byte: Эти байты содержат строки (согласно 4.6.1 настоящего стандарта), или перечисленное значение данных (согласно 4.7 настоящего стандарта), или тип общих данных (согласно 4.8 настоящего стандарта).

Примечание - Любые ссылки объекта должны быть расширены.

4.5.2 Атрибуты "по умолчанию".

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

4.6 CDATA и строки

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

Все CDATA или текстовые строки, кроме текстовых атрибутов, должны быть закодированы в соответствии с таблицей 6.

Таблица 6 - Структура элемента CDATA

cdata_tag: В поле всегда должно быть записано 0x01.

cdata_length: Это поле указывает на количество байтов данных, содержащихся в этой строке. Диапазон этих значений от 0x00 до 0xFD (от 0 до 253). Если в поле записано значение 0xFE или 0xFF, тогда дополнительное поле extended_cdata_length определит атрибут длины.

extended_cdata_length: Поле указывает на количество байтов данных, содержащихся в этой строке.

cdata_data_byte: Поле содержит символы для элемента CDATA.

Примечания:

1 Атрибуты с текстовыми значениями не должны быть закодированы в этом формате и вместо этого закодированы как атрибут (согласно 4.5 настоящего стандарта) с attribute_data_bytes.

2 Любые ссылки объекта должны быть расширены.

4.6.2 Наборы символов

Все строки CDATA и другие строки должны использовать кодирование UTF-8 в соответствии с ISO/IEC [1]. Символы от 0хЕ000 до 0xF8FF не должны включаться в закодированные строки двоичных файлов.

4.7 Перечисленные значения данных

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

4.8 Типы общих данных

4.8.1 Введение

Типы общих данных определены спецификацией EPG в соответствии с ETSI [2]. В этом подразделе определены типы общих данных, предназначенные для использования, идентификации и специфического кодирования.

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

Все элементы, определенные как timePointType, закодированы в соответствии с рисунками 2 и 3.

Рисунок 2 - Кодирование даты и времени (флаг LТО==1)

Рисунок 3 - Кодирование даты и времени (флаг LTO==0)

Rfa: Это 1-разрядное поле должно быть зарезервировано для будущих дополнений и до их определения должно быть установлено на 0.

Примечание - Приемники этот бит должны игнорировать.

Дата: Это 17-разрядное двоичное число без знака должно определить текущую дату согласно MJD в соответствии со стратегией кодирования ETSI [3]. Это число ежедневно постепенно увеличивается в 0000 UTC в диапазоне значений от 0 до 999. Например, значению MJD 50000 соответствует 10 октября 1995 года.

Rfa: Это 1-разрядное поле должно быть зарезервировано для будущих дополнений и до их определения должно быть установлено на 0.

Примечание - Приемники должны игнорировать этот бит.

Флаг LTO: Значение этого 1-разрядного поля указывает на представление поля LTO:

- 0: LTO не представлено, время определяется как UTC;

- 1: LTO представлено, местное время определяется как UTC плюс LTO.

Флаг UTC: Значение этого 1-разрядного поля указывает, какую форму использует UTC:

- 0: Краткая форма UTC;

- 1: Подробная форма UTC.

UTC: В зависимости от состояния флага UTC доступны две формы, определенные следующим образом:

- краткая форма: это 11-разрядное поле содержит два субполя, кодированные как двоичные числа без знака. Первое субполе - 5-разрядное (часовое), определяет часы. Второе субполе - 6-разрядное (минутное), определяет минуты;

- подробная форма: в дополнение к часовым и минутным субполям, определенным в краткой форме, это 27-разрядное поле должно содержать одно 6-разрядное субполе, которое должно быть закодировано как двоичное число без знака. Это поле должно определять секунды. Следующие 10 битов должны быть зарезервированы для будущих дополнений, и до их определения биты должны быть установлены на 0.

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

- 0: Положительное смещение;

- 1: Отрицательное смещение.

Заключительные 5 битов определяют смещение в получасах в диапазоне от минус 12 часов до плюс 12 часов.

Например, у программы вещания в 05:00 в Великобритании в течение летнего времени был бы UTC 04:00 и LTO плюс 1 час.

4.8.3 Продолжительность

Все атрибуты, определенные как durationType, закодированы как 16-разрядное целое число без знака, представляющее продолжительность интервалов времени в секундах от 0 до 65535 (только для интервалов продолжительностью более 18 часов).

4.8.4 Идентификаторы ссылок контента CRID

Все атрибуты, определенные как CRIDType, закодированы как строковый атрибут (согласно 4.5 настоящего стандарта).

4.8.5 Короткие идентификаторы ссылок контента

Все атрибуты, определенные как shortCRIDType, закодированы как 24-разрядное целое число без знака.

4.8.6 Жанры

Все элементы, которые определены как genreТуре, должны быть закодированы следующим образом. Кодируется только атрибут href (схема классификации (CS) и уровни) вместе с типом атрибута (опционально). Имя и элементы определения не кодируются. Атрибут href элемента жанра должен быть закодирован в соответствии с рисунком 4.

Рисунок 4 - Кодирование атрибута элемента жанра href

Rfu: Это 4-разрядное поле должно быть зарезервировано для будущего использования. Четыре бита этого поля должны быть обнулены.

CS: Это 4-разрядное поле должно указывать применяемую схему классификации (CS), например, 1 из "1.2.3.4", следующим образом:

- 0: CS не определен. Жанры с этим CS должны быть проигнорированы.

- 1: CS намерения;

- 2: CS формата;

- 3: CS контента;

-4: CS целевой аудитории;

- 5: CS происхождения (производства);

- 6: CS предупреждения контента (Content alert);

- 7: CS типа медиа;

- 8: CS атмосферы (окружающей среды, обстановки);

- 9-15: схемы классификации не определены. Жанры с этими CS должны быть проигнорированы.

Семантика полей Уровень 1, Уровень 2, Уровень 3 должна быть в соответствии с ETSI [4] (4.7.5).

4.8.7 contentID

4.8.7.1 Для случая EPG DAB все элементы, определенные как contentlDType, кодируются в соответствии с рисунками 5, 6, 7.

Рисунок 5 - Кодирование contentID для DAB

Рисунок 6 - Пример кодирования contentID (флаг Ens == 1 и флаг Х-PAD == 0)

Рисунок 7 - Пример кодирования contentID (флаг Ens == 0 и флаг Х-PAD == 0)

Rfa: Это 1-разрядное поле должно быть зарезервировано для будущих дополнений. При кодировании в настоящее время этот бит должен быть обнулен.

Примечание - Приемники этот бит должны игнорировать.

Флаг Ens: Этот 1-разрядный флаг должен указать о наличии или отсутствии ЕССи Eld в contentID следующим образом:

- 0: ЕСС и Eld не присутствуют. Служба, на которую ссылаются в contentID, передана в том же самом ансамбле как эта служба EPG;

- 1: ЕСС и Eld присутствуют.

Флаг X-PAD: Этот 1-разрядный флаг указывает, переносят или не переносят адресуемый компонент в канале X-PAD следующим образом:

- 0: адресуемый компонент в канале X-PAD не переносят, расширение X-PAD не присутствует;

- 1: адресуемый компонент переносят в канале X-PAD, расширение X-PAD присутствует.

Флаг Sld: Этот 1-разрядный флаг указывает, как закодировано поле Sld следующим образом:

- 0: Sld закодирован как 16-разрядный идентификатор службы (аудио служба);

- 1: Sld закодирован как 32-разрядный идентификатор службы (информационная служба).

SCIdS: Это 4-разрядное поле определяет ID компонента службы в рамках службы (SCIdS).

ЕСС: Это 8-разрядное поле (опционально) определяет код ЕСС ансамбля, на котором выполняется служба вещания. Поле ЕСС присутствует, если флаг Ens установлен в 1.

Eld: Это опциональное 16-разрядное поле определяет идентификатор ансамбля (Eld), на котором выполняется служба вещания. Поле Eld присутствует, если флаг Ens установлен в 1.

Sld: Это 16-разрядное или 32-разрядное поле (разрядность определяется в соответствии с флагом SId) определяет идентификатор службы.

Расширение X-PAD: Это поле данных расширения X-PAD (опционально) присутствует, если флаг X-PAD установлен в 1.

Rfu: Это 3-разрядное поле должно быть зарезервировано для будущего использования поля типов приложений (X-PAD Арр Туре) (обозначенного флагом XPAD). Три бита этого поля должны быть обнулены.

Примечание - Приемники должны проверить наличие в этих битах нулей, для того чтобы определить статус поля X-PAD Арр Туре. Если какой-либо из битов поля Rfu не установлен в нуль, тогда приемники не должны декодировать флаг Х-PAD Арр Туре.

Типы приложений X-PAD: Это 5-разрядное поле (обозначенное как флаг ХРАD) определяет первый X-PAD Арр Туре (используемое только для приложений данных X-PAD).

4.8.7.2 Для случая EPG DRM все элементы, определенные как contentlDType, закодированы в соответствии с рисунком 8.

Рисунок 8 - Кодирование contentiD для DRM

Sld: Это 24-разрядное поле определяет идентификатор службы.

4.8.8 Идентификаторы ансамбля ensemblelD

4.8.8.1 Для случая EPG DAB все элементы, определенные как ensemblelDType, закодированы в соответствии с рисунком 9.

Рисунок 9 - Кодирование ensemblelD для DAB

ЕСС: Это 8-разрядное поле определяет расширенный код страны (ЕСС) ансамбля.

Eld: Это 16-разрядное поле определяет идентификатор ансамбля (Eld).

4.8.8.2 Для случая EPG DRM все элементы, определенные как ensemblelDType, закодированы в соответствии с рисунком 10.

Рисунок 10 - Кодирование ensemblelD для DRM

Sld: Это 24-разрядное поле определяет идентификатор службы.

4.8.9 triggerType/Pnum

Детализированные параметры кодирования элементов поля triggerType (4 байта) должны быть в соответствии с ETSI [2].

4.8.10 URL

Все элементы, определенные как urIType, должны быть закодированы как строки (согласно 4.6 настоящего стандарта).

4.8.11 Тип MIME

Все элементы, определенные как mimeType, должны быть закодированы как строки (согласно 4.6 настоящего стандарта).

4.9 Смешанные поля

4.9.1 Все атрибуты, определенные как xml:lang, должны быть закодированы как атрибут строки (согласно 4.5 настоящего стандарта).

4.9.2 Поле index, используемое в <memberOf> , кодируется как 16-разрядное целое число без знака.

4.9.3 Поле version, используемое в <programme>, <programmeEvent>, <serviceinformation>, <ensemble>, <service>, <programmeGroups>, <programmeGroup> and <schedule>, кодируется как 16-разрядное целое число без знака.

4.9.4 Поле "скорость передачи" (bitrate), используемое в <service> и <programme>, кодируется как 16-разрядное целое число без знака, которое при умножении на 0,1 дает скорость передачи, близкую к ожидаемой средней скорости передачи в кбит/с.

4.9.5 Поле кГц, используемое в <frequency>, кодируется как 24-разрядное целое число без знака, определяющее частоту в кГц.

4.9.6 Поле numOfltems используется в <programmeGroup>. Кодируется как 16-разрядное целое число без знака.

4.9.7 Поле "ширина и высота" (width and height) используется в <multimedia>. Кодируется как 16-разрядное целое число без знака.

4.10 Маркерный табличный элемент

4.10.1 Маркерный табличный элемент не определен спецификацией XML. Часто повторяющиеся строки в символьных данных EPG ("маркеры") могут быть закодированы при использовании таблицы маркеров. Таблица может содержать не более 16 маркеров. Эта таблица определяет теги (их байты могут быть идентифицированы в символьном потоке данных) и эквивалентные им строки. Когда декодер находит тег маркера в символьном потоке, он должен заменить тег эквивалентной строкой. В том случае, если маркерный табличный элемент встречается в двух верхних уровнях элементов (ерg и servicelnformation), он должен встречаться перед любыми другими элементами. Этот элемент применяется ко всем символьным данным в пределах родительского элемента высокого уровня (т.е. ерg или servicelnformation) и всех дочерних элементах родительского элемента. Этот элемент должен быть закодирован, как определено в 4.4 настоящего стандарта, со следующими условиями:

- element_tag: Значение всегда должно быть 0x04;

- element_data_byte: Эти байты содержат последовательность одного или более маркеров (согласно 4.10.2 настоящего стандарта).

4.10.2 Маркеры

Записи в маркерной таблице должны быть закодированы как уникальный тег и связанная с ним строка. Маркеры строк не должны включать ссылки на другие маркеры. Структура маркера должна быть в соответствии с таблицей 7.

Таблица 7 - Структура маркера

token_tag: Этот байт идентифицирует маркер. Есть 16 возможных значений тега (непечатаемые символы): 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0х0В, 0х0С, 0х0Е, 0x0F, 0x10, 0x11, 0x12, 0x13.

Примечание - За исключением значений 0x00 (нуль), 0x09 (вкладка), 0х0А (перевод строки) и 0x0D (возврат каретки). Каждый тег может встречаться в таблице маркеров не более одного раза.

token_length: Это поле указывает на количество байтов данных в маркерной строке. Диапазон допустимых значений от 0x00 до 0xFF (от 0 до 255).

token_data_byte: Маркерная строка.

4.11 Значения contentID по "умолчанию"

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

Правила и параметры кодирования элемента contentID "по умолчанию" должны быть в соответствии с ETSI [4] (4.10).

5 Профилирование

5.1 Профили

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

5.1.1 Базовый профиль

Таргет-приемники для профиля Базовый могут быть простыми и встроенными. Эти приемники обычно имеют доступную память для кода декодера EPG и для хранения данных в размере 25 кбайт. С целью максимизации доступной пропускной способности вещания и емкости хранения используется простой двоичный механизм кодирования в соответствии с разделом 4 настоящего стандарта.

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

5.1.2 Профиль Усовершенствованный

Любые атрибуты или элементы спецификации EPG XML, находящиеся вне профиля Базовый, передаются в рамках профиля Усовершенствованный. Кроме того, этот профиль предусматривает применение GZIP (алгоритм DEFLATE) для сжатия закодированных двоичных данных (опционально).

5.2 Фрагментация данных профиля в объекты

Данные EPG фрагментированы в объекты, базирующиеся на типе данных и профиле. EPG может описать службы в тех случаях, когда EPG не передается как служба EPG в том же самом ансамбле/канале. Примеры фрагментации данных приведены в ETSI [4] (приложение В).

Необходимо отметить:

- данные профиля Усовершенствованный нужно переносить как объекты профиля Усовершенствованный в канале информации профиля Базовый;

- данные профилей Базовый и Усовершенствованный для конкретной службы должны содержаться в единственной карусели. Соответствующий декодер должен объединить наборы информации от различных профилей для того, чтобы сформировать совместимый EPG. Следовательно, служба EPG профиля Усовершенствованный должна также быть связана со службой профиля Базовый. Декодеры служб профиля Усовершенствованный должны быть способны декодировать службы профиля Базовый. Для получения дополнительной информации о схеме объединения данных профилей необходимо руководствоваться 5.3 настоящего стандарта.

5.2.1 Информация о службе

Информация о службе профиля Базовый для всех служб единственного ансамбля/канала, описанная этой службой EPG, должна содержаться в одном объекте.

Дополнительная информация о службе должна переноситься в дополнительных объектах информации о службе профиля Усовершенствованный и может быть дополнительно сжата с GZIP.

5.2.2 Информация о программе (PI)

Информация о программе в профиле Базовый должна представляться одним объектом для единственной службы на интервале одних суток. Общее количество объектов информации о программе профиля Базовый должно быть равно количеству описанных служб, умноженных на количество суток, которые поддерживаются EPG.

Одни сутки определяются как время, в течение которого все программы передают одну или более служб (которые тарифицируются), и которые начинаются в интервале времени между 0:00:00 (местного времени) и 23:59:59 (местного времени) конкретной даты.

Все программы в пределах объекта PI профиля Базовый должны быть рассортированы хронологически, начиная от времени старта.

Примечание - Программа содержит множество факторов времени. Эти индивидуальные факторы времени должны быть хронологически рассортированы. Индивидуальная программа должна быть рассортирована в рамках базовых объектов информации о программе по его первому фактору времени - времени старта.

Информация с расширенными подробностями о программе (переносится в профиле Усовершенствованный) выполняется группированием ансамблем/каналом за время продолжительности службы или за сутки. Приемники должны быть способны к поддержке всех методов группирования данных PI профиля Усовершенствованный.

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

5.2.3 Информация о группе (GI)

Информация о группе для всех служб профиля Базовый о единственном ансамбле/канале, описанная этим EPG, должна содержаться в одном объекте.

Если служба EPG содержит данные о двух и более ансамблях/каналах, то на каждый ансамбль/канал должен создаваться объект информации GI профиля Базовый.

Дополнительная информация GI для какой-либо из служб должна переноситься в дополнительных объектах GI профиля Усовершенствованный и может быть дополнительно компрессирована с применением GZIP.

5.3 Схема объединения данных профиля

Данные профилей Базовый и Усовершенствованный получены из основного XML-файла, который соответствует схемам EPG, определенным в ETSI [2]. Эти файлы являются хорошо согласованными XML-документами, которые закодированы отдельно при использовании двоичного формата кодирования, упомянутого в разделе 4 настоящего стандарта.

Формат XML профиля Базовый должен соответствовать форме основного XML-документа (файла), но с включенными элементами и атрибутами профиля Базовый. Каждый элемент должен иметь вложение и порядок, соответствующие основному документу.

Данные профиля Усовершенствованный должны соответствовать форме исходного XML со следующими перемещенными данными:

- атрибуты и элементы, которые включены в профиль Базовый;

- text/CDATA, которые включены в профиль Базовый;

- элементы, которые стали пустыми в результате этих перемещений.

Детализированные правила применения данных профилей Базовый и Усовершенствованный должны быть в соответствии с ETSI [4] (5.3).

5.4 Атрибуты, необходимые для объединения файлов

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

- атрибуты объединенной информации о службе в соответствии с таблицей 8.

Таблица 8 - Атрибуты объединенной информации о службе

- атрибуты объединенной информации о программе в соответствии с таблицей 9.

Таблица 9 - Атрибуты объединенной информации о программе

- атрибуты объединенной информации о группе должны быть в соответствии с таблицей 10.

Таблица 10 - Атрибуты информации о группе

Приемник не должен пытаться объединять данные, если ID и версии данных в профилях Базовый и Усовершенствованный не совпадают. В этом случае должны использоваться только данные профиля Базовый.

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

6.1 Транспортный механизм

В качестве метода передачи данных EPG используется МОТ в режиме каталога (ETSI [5]). Отображение данных EPG на объекты МОТ описано в 5.2 настоящего стандарта.

Каталог МОТ не должен компрессироваться, информация о заголовке в пределах каталога МОТ должна сортироваться в порядке возрастания ContentName, сообщенного параметром расширения каталога МОТ SortedHeaderlnformation в соответствии с детализацией спецификации МОТ (ETSI [5]).

6.2 Максимальный размер объекта

Размер каждого объекта МОТ профиля Базовый не должен превышать 16 кбайт (16384 байт) и размер каталога МОТ не должен превышать 8 кбайт (8192 байт). Размер каждого из объектов профиля Усовершенствованный не ограничен.

Если размер объекта каталога МОТ превысит 8 кбайт, то индивидуальные службы должны пересылаться в альтернативную карусель с размером объекта каталога не более максимального. Если размер любого объекта EPG профиля Базовый превышает 16 кбайт (16384 байт), то уровень детализации в пределах объекта должен быть сокращен до размера объекта, не превышающего максимальное значение.

Данные профилей Базовый и Усовершенствованный для определенной службы должны содержаться в пределах единственной карусели.

6.3 Максимальная пропускная способность канала

Для любых каруселей, содержащих объекты EPG, скорость передачи данных для МОТ, транспортируемой или в пакетном режиме, или в формате PAD, не должна превышать 64 кбит/с. Для режима передачи пакета полная скорость подканала, включая EPG, ограничена величиной 128 кбит/с.

6.4 Параметры МОТ

6.4.1 Использование параметров МОТ

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

Параметры МОТ, которые должны быть применены к индивидуальным объектам МОТ, переносятся с информацией в заголовке МОТ, каждая запись в каталоге входит в каталог МОТ. Сводка параметров МОТ для индивидуальных объектов, которые применяются для спецификации EPG, дана в таблице 11 и определена подробно ниже в следующих подразделах.

Функция МОТ кэширования опциональна и для провайдера UA и для приемника (ETSI [5]).

Если используются параметры МОТ ProfileSubset, CAInfo, ContentName и/или UniqueBodyVersion, то эти параметры должны быть рассортированы в этом порядке и помещены в начале списка параметров МОТ в заголовке МОТ.

Примечание - В пределах контекста, определенного спецификой профиля, могут быть заданы другие параметры. Однако параметры, обработка которых не предусмотрена приемником данного профиля, будут проигнорированы.

Перечень параметров МОТ, используемых для идентификации контента индивидуальных одиночных объектов, представлен в таблице 11.

Таблица 11 - Перечень параметров МОТ, используемых для идентификации контента индивидуальных одиночных объектов

6.4.2 Ядро заголовка МОТ

Параметр ContentType указывает на основную категорию контента тел МОТ. Параметр ContentSubType указывает на точный тип контента тел МОТ в зависимости от значения поля в соответствии с ETSI [5].

Параметры ContentType/ContentSubType идентифицируют типы данных в зависимости от того, являются ли данные расписанием EPG, службой или информацией группы. Величины разрешенных значений для ContentType и ContentSubType для конкретных данных EPG перечислены в таблице 12. ContentType всех конкретных данных приложения EPG имеет значение "7".

Таблица 12 - Величины разрешенных значений для ContentType и ContentSubType для конкретных данных EPG

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

6.4.3 Параметр ProfileSubset

В тех случаях, когда карусель содержит больше объектов, чем необходимо для одного профиля, декодером МОТ может быть применена дополнительная обработка, если он "знает", с каким профилем данный объект используется. Параметр ProfileSubset идентифицирует профиль, для которого объект релевантен (соответствует запрашиваемому). Определены возможные значения ProfileSubset для ID профилей, представленных в ETSI [4] (таблица 13). Детализированные правила применения параметра ProfileSubset должны быть в соответствии со спецификацией МОТ (ETSI [5] и ETSI [4] (6.4.2).

6.4.4 Параметр ContentName

Этот обязательный параметр МОТ однозначно определяет объект в рамках карусели МОТ и в рамках службы EPG. Параметр ContentName используется в соответствии со спецификацией МОТ (EN [5]).

6.4.5 Параметр CompressionType

Параметр CompressionType используется в соответствии со спецификацией МОТ (ETSI [5]).

Объекты, содержащие данные профиля Базовый, не должны компрессироваться.

Объекты, содержащие информацию профиля Усовершенствованный, могут включать необработанный текст. Вследствие этого к закодированным объектам двоичного файла может быть применено компрессирование GZIP. Эти данные будут использоваться только приемниками профиля Усовершенствованный, у которых должна быть возможность распаковывать эти данные. Максимальный размер окна, поддерживаемый декодером EPG для GZIP, должен быть не более 32 кбайт.

6.4.6 Параметр CAInfo

Этот параметр используется, если условный доступ на уровне МОТ применен к данным МОТ. Параметр CAInfo используется в соответствии со спецификацией МОТ (ETSI [5]). В случае присутствия этого параметра приемник, не совместимый с СА, должен игнорировать этот объект МОТ.

6.4.7 Параметр ScopeStart

Параметр ScopeStart должен применяться для индикации тарифицированной даты вещания, времени старта вещания первой программы (местное время), которые соответствуют данным, находящимся в объекте информации о программе (PI) EPG.

Этот параметр используется только для объектов информации о программе EPG, он не должен использоваться для объектов информации о службе или для объектов информации о группе.

Для объектов информации о программе параметр ScopeStart является обязательным. Он должен кодироваться в соответствии с 4.8.2 настоящего стандарта со следующим ограничением: должна использоваться только краткая форма UTC (LTO допускается опционально). Время старта должно округляться в меньшую сторону до ближайшей минуты.

6.4.8 Параметр ScopeEnd

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

Параметр ScopeEnd не должен использоваться для объектов информации о службе или для объектов информации о группе.

Для объектов информации о программе этот параметр является обязательным. Он должен кодироваться в соответствии с 4.8.2 настоящего стандарта со следующим ограничением: должна использоваться только краткая форма UTC с опциональным LTO. Время окончания должно быть округлено в меньшую сторону до ближайшей минуты. Детализированные правила применения параметра ScopeEnd должны быть в соответствии с ETSI [4] (6.4.7).

6.4.9 Параметр ScopelD

Этот параметр указывает на ensemblelD ансамбля/канала, для которого объект содержит данные (кодированные в соответствии с 4.8.8 настоящего стандарта).

Правила применения параметра ScopeEnd должны быть в соответствии с ETSI [4] (6.4.8).

6.5 Транспортировка других объектов

Карусель МОТ может содержать дополнительные объекты, которые должны транспортироваться в рамках МОТ в соответствии с ETSI [5] и при использовании сигнализации, детализированной в рамках этого же стандарта.

Эти дополнительные объекты могут транспортироваться в той же самой карусели МОТ, как и данные профиля Базовый при условии, что размер каталога МОТ не будет превышать максимального размера, разрешенного для данных профиля Базовый (согласно 6.2 настоящего стандарта). В том случае, если каталог МОТ превышает разрешенный размер, эти дополнительные объекты должны транспортироваться в дополнительной карусели. Специфичные параметры EPG (ScopeStart, ScopeEnd и ScopelD) для этих объектов не должны использоваться.

7 Сигнализация

7.1 DAB

7.1.1 Сигнализация типа приложения при использовании приложения EPG в канале данных DAB должна выполняться при помощи FIG0/13, значение UserApplicationType должно быть "EPG" в соответствии с ETSI [6]. Данные профилируются в объекты EPG профилей Базовый и Усовершенствованный в соответствии с разделом 5 настоящего стандарта. Поле данных приложения EPG представляет собой последовательность ProfilelD.

Если количество идентификаторов ProfilelD больше одного, то список должен быть рассортирован в порядке возрастания, начиная от самой низкой величины ProfilelD. Список значений идентификаторов ProfilelDs представлен в ETSI [4] (таблица 13). Значения ProfilelD от 0x03 до 0xFF зарезервированы для использования в будущем и не должны обрабатываться приемниками.

7.1.2 Сигнализация времени вещания предоставлением данных о времени вещания в FIG 0/10 и смещения местного времени в FIG 0/9 является обязательным требованием приложения пользователя. Детализированные требования к этим параметрам должны быть в соответствии с ETSI [3].

7.1.3 Сигнализация о количестве программ в FIG 0/16 необходима для использования атрибута программы "trigger" в рамках спецификации EPG DAB. Детализированная информация об этих параметрах должна быть в соответствии с ETSI [3].

7.2 DRM

7.2.1 Сигнализация объекта данных типа 5 (приложение данных)

Использование приложения EPG в канале DRM должно быть обозначено применением объекта данных типа 5 (в соответствии с ETSI [7]) со значением домена приложения "DAB" (в соответствии с ETSI [8]) и с UserApplicationType, принимающим значение "EPG" (в соответствии с ETSI [6]).

Параметры сигнализация данных профиля должны быть в соответствии с описанием для DAB согласно 7.1.1 настоящего стандарта.

7.2.2 Сигнализация времени вещания

Корректное предоставление справочного времени вещания в пределах объекта данных SDC типа 8 является обязательным требованием приложения пользователя. Детализация параметров сигнализации должна быть в соответствии с ETSI [7].

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

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

В таблице А.1 показаны байты двоичного кодирования объекта.

Таблица А.1 - Пример двоичного кодирования

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

Теги элемента

Все теги элемента, кроме элементов верхнего уровня и других специальных элементов, находятся в диапазоне значений от 0x10 до 0х7Е. Все теги атрибута находятся в диапазоне значений от 0x80 до 0xFF. Тег 0x7F зарезервирован и никогда не будет использоваться.

В таблице Б.1 представлен перечень тегов элементов.

Таблица Б.1 - Теги элементов

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

Теги атрибута

Правила кодирования атрибутов определены в 4.5 настоящего стандарта. В таблицах В.1, В.2 и В.3 представлены дополнительные правила кодирования тегов атрибутов epgSchedule, epgSI, epgDataTypes соответственно.

Таблица В.1 - Теги атрибута epgSchedule

Таблица В.2 - Теги атрибута epgSI

Таблица В.3 - Теги атрибутов epgDataTypes

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

Перечисленные типы

В таблице Г.1 представлены значения перечисленного типа. Атрибут "по умолчанию", показанный курсивом в таблице Г.1, всегда имеет значение 0x01 и не должен кодироваться.

Таблица Г.1 - Значения перечисленного типа

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

Профилирование таблиц

Д.1 Элементы и атрибуты, передаваемые в профиле Базовый

В таблицах Д.1-Д.3 представлены элементы и атрибуты, формирующие профиль Базовый.

Таблица Д.1 - Информация о службе (SI) профиля Базовый

Таблица Д.2 - Информация о программе (PI) профиля Базовый

Таблица Д.3 - Информация о группе (GI) профиля Базовый

Д.2 Элементы и атрибуты, передаваемые в профиле Усовершенствованный

Профиль Усовершенствованный может включать любые элементы и атрибуты, предусмотренные спецификацией EPG XML.

Вещатель для конкретной службы EPG может перемещать элементы и атрибуты профиля Базовый в элементы и атрибуты профиля Усовершенствованный.

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

Электронный текст документа

и сверен по:

, 2013