ГОСТ Р 59808-2021. Национальный стандарт Российской Федерации. Телевидение вещательное цифровое. Технические требования к системе обновления программного обеспечения в системах цифрового телевизионного вещания

(утв. и введен в действие Приказом Росстандарта от 26.10.2021 № 1316-ст)

от 26 октября 2021 г. № 1316-ст

ОКС 33.170

1 июня 2022 года

Предисловие

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

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

4 Настоящий стандарт разработан с учетом основных нормативных положений документа Европейского института по стандартизации в области телекоммуникаций (ETSI) ETSI TS 102 006 V1.4.1 (2015-06) «Телевидение вещательное цифровое. Технические требования к системе обновления программного обеспечения в системах цифрового телевизионного вещания» [ETSI TS 102 006 V1.4.1 (2015-06) «Digital Video Broadcasting (DVB); Specification for System Software Update in DVB Systems», NEQ]

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

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

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

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

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

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

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

ГОСТ Р 52210 Телевидение вещательное цифровое. Термины и определения

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

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

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

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

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

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

3.1.1 изготовитель (приемника DVB): Организация, ответственная в первую очередь за обновление программного обеспечения приемника DVB, выпущенного в обращение.

3.1.2 система обновления программного обеспечения; СОПО: Обновление программного обеспечения приемника DVB через систему DVB.

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

• ПО — программное обеспечение;
• СОПО — система обновления ПО;
• bslbf — строка битов, первый бит слева (bit string, left bit first);
• BAT — таблица ассоциации букета программ (Bouquet Association Table);
• CA — условный доступ (Conditional Access);
• DDB — загрузка блока данных (DownloadDataBlock);
• DII — индикация информации о загрузке (DownloadInfoIndication);
• DSI — инициация сервера загрузки (DownloadServerInitiate);
• DSM-CC — система команд и управления для средств цифровой записи (Digital Storage Media Command and Control);
• DVB — цифровое вещательное телевидение (Digital Video Broadcasting);
• ETSI — Европейский институт по стандартизации в области телекоммуникаций (European Telecommunications Standards Institute);
• IEC — Международная электротехническая комиссия (International Electrotechnical Commission);
• IEEE — Институт инженеров электротехники и электроники (Institute of Electrical and Electronics Engineers);
• ISO — Международная организация по стандартизации (International Standards Organization);
• LRI — информация о разрешении местоположения (Location Resolution Information);
• mi — поле, содержащее дескрипторы с необходимой информацией, в том числе указатель на локацию сообщений DownloadDataBlock (ModuleInfoBytes);
• NIT — таблица сетевой информации (Network Information Table);
• OUI — уникальный идентификатор организации (Organization Unique Identifier);
• PMT — таблица карты программ (Program Map Table);
• PSI — информация о составе программы (Program Specific Information);
• rpchof — коэффициенты остаточного многочлена, самый старший коэффициент обрабатывается первым (remainder polynomial coefficients, highest order first);
• SI — информация об услугах (Service Information);
• TDT — таблица времени и даты (Time and Date Table);
• TOT — таблица смещения времени (Time Offset Table);
• TS — транспортный поток (Transport Stream);
• uimsbf — беззнаковое целое, старший значащий бит первый (unsigned integer most significant bit first);
• UNT — таблица уведомления об обновлении (Update Notification Table);
• URI — унифицированный идентификатор ресурса (Uniform Resource Identifier);
• XOR — исключающее «ИЛИ» (eXclusive OR).

4 Профили и типы служб системы обновления программного обеспечения

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

Настоящий стандарт определяет два профиля служб СОПО в зависимости от вида сигнализации о службе:

- простой профиль служб СОПО. Данный профиль основан на сигнализации в таблице сетевой информации (Network Information Table; NIT), в таблице ассоциации букета программ (Bouquet Association Table; BAT) и в таблице карты программ (Program Map Table; PMT) и не требует таблицы уведомления об обновлении (Update Notification Table; UNT);

• расширенный профиль служб СОПО на базе таблицы UNT.

Существует два профиля приемников:

• приемники, поддерживающие только простой профиль служб СОПО;
• приемники, поддерживающие расширенный профиль служб СОПО на базе таблицы UNT.

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

• оператор как минимум должен поддерживать простой профиль;
• приемник как минимум должен поддерживать простой профиль.

4.2 Передача данных

Настоящий стандарт определяет два различных формата передачи данных СОПО в вещательных потоках:

• проприетарный (собственный) формат;
• карусель стандартного обновления, распределенная между изготовителями приемников DVB.

5 Сетевая сигнализация

5.1 Общие правила функционирования

Дескриптор связей с типом связи 0x09 (служба СОПО) передает местоположение транспортного потока, несущего службу СОПО в сети или букете. Данный дескриптор должен переноситься в первом цикле NIT или в первом цикле специально идентифицированной BAT (далее — BAT СОПО).

BAT СОПО идентифицируется с помощью идентификатора bouquet_id, равного 0xFF00, и, если используется дескриптор country_availability_descriptor, применяется код страны 902 (т.е. все страны). Если BAT СОПО переносится в каком-либо транспортном потоке сети, она должна быть такой же, как и в любом другом транспортном потоке данной сети с BAT СОПО.

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

Если уникальный идентификатор организации (Organization Unique Identifier; OUI) перечислен в дескрипторе linkage_descriptor, то список OUI должен быть полным, поскольку он передает информацию обо всех обновлениях ПО, передаваемых о соответствующей услуге. Особый OUI со значением 0x00015A зарезервирован DVB. Данный OUI может использоваться для других целей, несмотря на СОПО, описанную в стандарте. В рамках настоящего стандарта OUI используется для обозначения того, что дескриптор data_broadcast_id_descriptor не сигнализирует о каком-либо конкретном OUI. В данном случае дальнейшая информация о выборе должна переноситься либо в карусели стандартных данных, либо в UNT, как указано в дескрипторе. Если DVB OUI используется, то только единственный OUI должен содержаться в цикле дескриптора data_broadcast_id. Может быть несколько дескрипторов в NIT или в BAT СОПО, чтобы можно было идентифицировать несколько служб СОПО. В случае временного отсутствия службы СОПО для приемников идентифицированной организации OUI не должен удаляться из данного дескриптора связей.

5.2 Дескриптор связей системы обновления программного обеспечения

5.2.1 Данные частного характера для типа связей 0x09

Синтаксис данных частного характера для типа связей 0x09 приведен в таблице 1.

Таблица 1

Синтаксис данных частного характера для типа связей 0x09

• OUI_data_length — поле длиной 8 бит, указывает длину в байтах цикла OUI;
• OUI — поле длиной 24 бита, содержит IEEE OUI организации, предоставляющей службу СОПО в транспортном потоке/службе. Согласно определению DVB OUI со значением 0x00015A указывает, что поток исходит от любого OUI;
• selector_length — поле длиной 8 бит, указывает общую длину в байтах последующего поля селектора;
• selector_byte — поле предоставляет дополнительную информацию для OUI, которая может использоваться приемником для поиска и идентификации службы СОПО, например, тип модели или диапазоны. Синтаксис и семантика поля селектора определяются организацией, владеющей OUI;
• private_data_byte — поле длиной 8 бит.

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

Дескриптор связей поиска службы системы обновления ПО определяет указатель на транспортный поток, несущий BAT СОПО или NIT с подробной информацией о сигнализации о службах СОПО. Тип связей для данного дескриптора должен быть 0x0A и может быть вставлен в BAT или NIT.

Он отличается от дескриптора связей типа 0x09 в том смысле, что этот дескриптор не содержит никаких специфических данных OUI и может быть использован приемником DVB для быстрого получения мультиплекса с BAT СОПО или NIT без необходимости сканирования всех мультиплексов. Таким образом, использование дескриптора связей типа 0x0A дополняет использование дескриптора связей типа 0x09 в NIT в BAT СОПО.

Поле table_type информирует, указывает ли данный дескриптор связи на NIT или BAT в целевом транспортном потоке.

Использование данного дескриптора является необязательным.

Синтаксис дескриптора связей поиска службы СОПО типа 0x0A приведен в таблице 2.

Таблица 2

Синтаксис дескриптора связей поиска службы СОПО типа 0x0A

Семантика дескриптора связей типа 0x0A:

• transport_stream_id — поле длиной 16 бит, которое идентифицирует транспортный поток (Transport Stream; TS), содержащий BAT СОПО или NIT;
• original_network_id — поле длиной 16 бит, дает метку, показывающую идентификатор сети network_id исходной системы доставки BAT СОПО или NIT;
• service_id — поле длиной 16 бит, которое не имеет значения и должно быть установлено в 0x0000;
• linkage_type — поле длиной 8 бит, указывает тип связей и должно быть установлено в 0x0A;
• table_type — поле длиной 8 бит, содержит флаг, указывающий либо на BAT СОПО, либо на NIT. Оно должно быть закодировано в соответствии с таблицей 3.

Кодирование поля table_type

6 Сигнализация информации о составе программы

6.1 Общие правила функционирования

PMT транспортного потока, несущего данные о СОПО, должна содержать дескриптор data_broadcast_id с идентификатором широковещательной передачи данных 0x000A для указания элементарного потока, используемого для службы СОПО.

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

- дескриптор предоставляет точку входа в проприетарный поток;

• дескриптор предоставляет точку входа в стандартную двухслойную карусель данных без дополнительной ссылки из таблицы;
• дескриптор предоставляет ссылку на UNT.

В данных случаях этот дескриптор должен присутствовать на «полустатической» основе, т.е. идентификация оператора СОПО не должна удаляться из PMT, если в настоящее время нет службы СОПО, но ожидается, что она появится в ближайшем будущем.

Дескриптор может содержать определенные OUI (плюс байты селектора) и в этом случае список OUI (плюс байты селектора) должен быть полным.

Специфический OUI со значением 0x00015A зарезервирован DVB. В рамках настоящего стандарта он используется для указания, что data_broadcast_id_descriptor не сигнализирует о каком-либо конкретном OUI. В данном случае дополнительная информация о выборе должна переноситься либо в карусели стандартных данных, либо в UNT, как указано в дескрипторе. Если используется OUI DVB, только этот единственный OUI должен содержаться в цикле дескриптора data_broadcast_id. Чтобы позволить нескольким службам СОПО быть идентифицированными, в NIT или BAT СОПО может быть несколько дескрипторов.

Если для каждого OUI (плюс соответствующие байты селектора) используется отдельная карусель стандартного обновления, data_broadcast_id_descriptor в PMT должен содержать один OUI (плюс байты селектора) для каждого компонента. Это позволяет поставщику уникально идентифицировать потоки проприетарных (собственных) форматов и обеспечивает дополнительное удобство для приемника в процессе определения соответствующего элементарного потока в случае, если имеется только один применимый вариант.

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

6.2 Определение байта селектора дескриптора идентификатора широковещательной передачи данных для системы обновления программного обеспечения

Синтаксис и семантика полей СОПО:

• data_broadcast_id — для этого поля должно быть установлено значение 0x000A для указания службы СОПО;

- selector_byte — байты селектора, передают структуру system_software_update_info, синтаксис которой представлен в таблице 4.

Таблица 4

Синтаксис структуры system_software_update_info

Семантика байтов id_selector для data_broadcast_id 0x000A:

• OUI_data_length — поле указывает общую длину в байтах цикла OUI;
• OUI — 24-битовое поле, содержащее OUI IEEE организации, предоставляющей службу СОПО в транспортном потоке/службе. Согласно определению DVB OUI со значением 0x00015A указывает, что поток исходит от любого OUI;
• update_type — 4-битовое поле, определяющее тип службы СОПО. Оно должно кодироваться в соответствии с таблицей 5.

Таблица 5

• update_versioning_flag — если 0, то релевантная информация о версии не передается в поле версии. Если 1, то поле версии должно отражать изменения в компоненте службы СОПО;
• update_version — версия должна увеличиваться при каждом изменении обновления. Если для параметра update_versioning_flag установлено значение 1, а для параметра update_type установлено значение 0x2 или 0x3 (UNT), тогда поле update_version должно совпадать с полем version_number в заголовке секции UNT;

- selector_length — 8-битовое поле, задает общую длину в байтах следующего поля селектора;

• selector_byte — 8-битовое поле. Последовательность полей selector_byte определяет поле селектора. Это поле предоставляет информацию, являющуюся дополнительной к OUI, которая может использоваться приемником для нахождения и идентификации службы СОПО, например, тип модели или диапазоны. Синтаксис и семантика поля селектора определяются организацией, идентифицированной через OUI.

7 Требования к карусели стандартных данных для системы обновления программного обеспечения

7.1 Структура карусели стандартного обновления

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

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

Несколько СОПО от разных производителей передаются как группы в двухслойной карусели данных.

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

Сообщение DownloadServerInitiate описывает загрузки (группы) в поле GroupInfoByte (gi).

Поле GroupInfoByte также состоит из цикла дескрипторов, который может содержать разную информацию.

Дескриптор CompatibilityDescriptor сообщения DSI находится в поле GroupInfoIndication и позволяет, используя IEEE OUI, идентифицировать изготовителя.

Сообщение DSI используется несколькими производителями. Данные в отдельной группе, как правило, принадлежат одному производителю.

На рисунке 1 показано несколько обновлений в двухслойной карусели данных, используя общий элементарный поток. Рисунок 1 иллюстрирует протокол. Производитель А имеет одно активное обновление и одно неактивное (т.е. запланированное/объявленное) обновление (пустая группа). Производитель Б имеет одно активное обновление.

Примечание - Дескриптор data_broadcast_id_descriptor в PMT используется для извещения о наличии одного или нескольких СОПО, от одного или нескольких изготовителей.

Рисунок 1 — Несколько обновлений в двухслойной карусели данных, используя общий элементарный поток

7.1.2 Сообщение об инициации сервера загрузки (DSI)

• transactionId — два младших значащих байта идентификатора транзакции DSI должны находиться в диапазоне от 0x0000 до 0x0001. Младший значащий бит актуального идентификатора транзакции изменяется каждый раз, когда происходит изменение базовой структуры карусели (т.е. когда группа добавляется, изменяется или удаляется). Два старших значащих байта (биты 31 — 16) содержат число, которое идентифицирует версию карусели и может использоваться для обнаружения изменения версии;
• serverId — это поле должно содержать 20 байтов со значением 0xFF;
• compatibilityDescriptor() — эта структура должна содержать только поле CompatibilityDescriptorLength дескриптора CompatibilityDescriptor(), как определено в DSM-CC. Оно должно быть установлено в значение 0x0000.

Поле privateDataByte должно содержать структуру GroupInfoIndication, как определено ниже:

• privateDataLength — это поле определяет длину в байтах последующей структуры GroupInfoIndication;
• privateDataByte — эти поля должны передавать структуру GroupInfoIndication согласно таблице 6.

Таблица 6

Структура GroupInfoIndication

Дескриптор CompatibilityDescriptor в структуре GroupInfoIndication должен соответствовать таблице 7.

Таблица 7

в структуре GroupInfoIndication

Кодировка поля descriptorType

Семантика структуры GroupInfoIndication:

• numberOfGroups — 16-битовое поле, указывающее количество групп, описанных в цикле, следующих за этим полем;
• groupId — 32-битовое поле, которое должно быть равно transactions сообщения DownloadInfoIndication, описывающее группу;
• groupSize — 32-битовое поле, которое должно указывать совокупный размер в байтах всех модулей в группе;
• groupCompatibility — структура GroupCompatibility, эквивалентная структуре CompatibilityDescriptor DSM-CC. CompatibilityDescriptor должен содержать дескриптор аппаратного обеспечения системы, содержащий OUI в структуре system_software_update_info дескриптора data_broadcast_id_descriptor в PMT. Если имеется несколько обновлений одного и того же производителя, то поля model и version в дескрипторе аппаратного обеспечения системы и дескриптор ПО системы могут использоваться приемником для выбора корректного потока. Применяются только дескрипторы типа 0x01 и 0x02 (дескриптор аппаратного и программного обеспечения системы);
• groupInfoLength — 16-битовое поле, указывающее длину в байтах цикла дескриптора;
• groupInfoByte — не определено в настоящем стандарте;
• privateDataLength — это поле определяет длину в байтах полей privateDataByte;
• privateDataByte — данные поля не используются.

7.1.3 Сообщение об индикации информации о загрузке

Семантика специализированных полей DII:

• transactionId — идентификатор транзакции, для сообщений DownloadInfoIndication (DII) должен находиться в диапазоне 0x0002 0xFFFF, чтобы отличать его от идентификатора транзакции сообщения DownloadServerInitiate (DSI). Идентификатор transactionId равен groupId (номер группы) в соответствующей структуре groupInfo в DSI;
• downloadId — эквивалентно transactionId.

Семантика структуры moduleInfo:

• moduleId — поле является идентификатором модуля.

В соответствии с процедурой, описанной в 7.1:

• биты с 15 по 8 имеют то же значение, что и младшие значащие биты groupId в соответствующей структуре groupInfo в DSI, ссылающегося на данную конкретную загрузку;
• биты с 7 по 0: являются moduleId конкретной загрузки, поддерживается 256 модулей.

Примечание - Максимальное количество модулей в данном случае ограничено 256, что является достаточным для СОПО;

• moduleVersion — версия описанного модуля.

В соответствии с процедурой, описанной в 7.1, это значение также содержится в младших значащих битах идентификатора транзакции в соответствующей структуре groupInfo в DSI, ссылающейся на данную конкретную загрузку.

7.1.4 Сообщение загрузки блока данных

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

Семантика полей сообщения DDB:

• moduleId — идентификатор модуля, к которому принадлежит текущий блок;
• moduleVersion — равно полю moduleVersion в структуре модуля DII, к которому принадлежит текущий блок;
• blockNumber — идентифицирует позицию блока в модуле. Блок под номером 0 должен быть первым блоком в модуле.

7.2 Дескрипторы карусели стандартных данных

7.2.1 Дескриптор типа модуля СОПО

Дескриптор типа модуля СОПО SSU_type_descriptor должен содержать тип модуля СОПО. Кодировка дескриптора SSU_type_descriptor приведена в таблице 9.

Кодировка дескриптора SSU_type_descriptor

Семантика SSU_type_descriptor:

• descriptor_tag — 8-битовое поле, идентифицирует дескриптор. Для дескриптора типа СОПО установлено значение 0x0A;
• descriptor_length — 8-битовое поле, указывает количество байтов дескриптора, следующих сразу же после этого поля;
• SSU_module_type — 8-битовое поле типа модуля СОПО. Типы модуля СОПО определены в таблице 10.

Таблица 10

7.3 Время доступности простых служб системы обновления программного обеспечения

Доступность загрузки в конфигурации с простым профилем должна составлять не менее 2 ч. Это позволяет приемникам отслеживать появление новой загрузки с интервалом около 1 ч. По согласованию между изготовителем приемника и оператором допускается применять другие правила.

8 Таблица уведомления об обновлении

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

UNT должна использоваться с дескриптором data_broadcast_id_descriptor (0x000A), где параметр update_type установлен в значение 0x2, 0x3 или 0x4.

UNT должна транслироваться в формате таблицы информации об услугах (Service Information; SI), длина секции ограничена длиной 4096 байт.

UNT разделяют на подтаблицы, индексированные с помощью action_type и уникального идентификатора организации OUI, администрируемого IEEE (IEEE OUI).

8.2 Информация о составе программы (PSI), информация об услугах (SI) и сигнализация о соответствующей таблице уведомления об обновлении (UNT)

PMT ссылается на UNT путем включения дескриптора data_broadcast_id_descriptor (data_broadcast_id = 0x000A) в цикл ES_info, где параметр update_type в структуре system_software_update_info установлен в значение 0x2, 0x3 или 0x4. Параметр OUI структуры system_software_update_info может быть либо установлен в зарезервированный DVB IEEE OUI, равный 0x00015A, указывающий, что выбор обновления возможен только путем анализа UNT (ссылка находится в текущем потоке в записи PMT), либо OUI должен содержать актуальный IEEE OUI, соответствующий индексу подтаблицы UNT (приложение А).

После выбора кандидата UNT должен выполняться поиск подтаблицы, соответствующей IEEE OUI. Если найдена необходимая подтаблица, выполняется последовательный поиск по секциям подтаблицы, в ходе которого сравниваются дескрипторы compatibilityDescriptor.

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

Успешный поиск выдает ссылку на соответствующую карусель данных через поле association_tag дескриптора SSU_location_descriptor. Поле association_tag используется в сочетании с дескриптором deferred association_tag_descriptor() в цикле дескриптора программы PMT или с дескриптором stream_identifier_descriptor() в цикле ES_info потока служебных компонентов PMT.

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

Пример служб СОПО со ссылкой на UNT приведен на рисунке 2. Пример служб СОПО с обновлением через Интернет приведен на рисунке 3.

<*> OUI со значением 0x00015A приведен в качестве примера. Могут использоваться иные OUI или списки OUI.

<*> OUI со значением 0x00015A приведен в качестве примера. Могут использоваться иные OUI или списки OUI.

Рисунок 3 — Пример служб СОПО с обновлением через Интернет

8.3 Описание таблицы уведомления об обновлении (UNT)

UNT описывает доступность и местоположение СОПО (приложение А). Может существовать одна или несколько UNT, охватывающих все СОПО сети. UNT ссылается через дескриптор data_broadcast_id_descriptor (data_broadcast_id = 0x000A) в цикле ES_info таблицы PMT, где поле update_type в структуре system_software_update_info устанавливается в 0x2 или 0x3 (с указанием ссылки на UNT). Параметр OUI структуры system_software_update_info может быть либо установлен в зарезервированный DVB IEEE OUI, равный 0x00015A, указывающий, что выбор обновления возможен только путем анализа UNT, либо OUI должен содержать актуальный IEEE OUI, соответствующий индексу подтаблицы UNT.

Чтобы помочь приемным устройствам с ограниченными возможностями блока фильтрации в процессе обнаружения соответствующей подтаблицы UNT, подтаблица OUI в UNT хэшируется с использованием простой функции, исключающей «ИЛИ» (eXclusive OR; XOR), и включается в поле table_id_extension как часть.

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

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

Цикл платформы связывает цикл operational_descriptor_loop() с циклом target_descriptor_loop(), что позволяет использовать несколько назначенных или неназначенных СОПО, которые должны быть связаны с данной платформой.

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

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

8.4 Синтаксис и семантика таблицы уведомления об обновлении (UNT)

8.4.1 Синтаксис таблицы уведомления об обновлении (UNT)

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

Таблица 11

Синтаксис UNT

8.4.2 Семантика полей таблицы уведомления об обновлении (UNT)

8.4.2.1 Поля преамбулы

• table_id — для таблицы UNT уникально определен 0x4B;
• action_type — идентифицирует действие, которое необходимо выполнить. Кодировка поля action_type должна быть в соответствии с таблицей 12;

Таблица 12

Кодировка поля action_type

• OUI_hash — формируется путем операции XOR всех трех байтов OUI вместе для формирования одного байтового значения:

OUI_hash = OUI [23..16] XOR OUI [15..8] XOR OUI [7..0];

• section_number — 8-битовое поле, содержащее номер секции. Значение section_number первой секции в подтаблице должно быть равно 0x00. Номер секции должен увеличиваться на 1 с каждой дополнительной секцией с теми же table_id, action_type и OUI;

• processing_order — указывает последовательность действий. Если для загрузки ПО требуется более одного действия, то это поле используют для указания порядка выполнения этих действий. Кодировка поля processing_order должна быть в соответствии с таблицей 13;

Кодировка processing_order

• platform_loop_length — 16-битовое поле указывает объединенную длину последующих циклов target_descriptor_loop () и operational_descriptor_loop ().

8.4.2.2 Дескриптор common_descriptor_loop()

Синтаксис дескриптора common_descriptor_loop() приведен в таблице 14.

Синтаксис дескриптора common_descriptor_loop()

8.4.2.3 Дескриптор compatibilityDescriptor()

Дескриптор compatibilityDescriptor() назван дескриптором для унификации, но по сути является структурой compatibilityDescriptor().

Синтаксис структуры compatibilityDescriptor() приведен в таблице 15.

Синтаксис структуры compatibilityDescriptor()

Кодировка поля descriptorType

8.4.2.4 Дескриптор target_descriptor_loop()

Синтаксис дескриптора target_descriptor_loop() приведен в таблице 17.

Синтаксис дескриптора target_descriptor_loop()

8.4.2.5 Дескриптор operational_descriptor_loop()

Синтаксис дескриптора operational_descriptor_loop() приведен в таблице 18.

8.5 Дескрипторы таблицы уведомления об обновлении (UNT) системы обновления программного обеспечения

8.5.1 Идентификация и размещение дескрипторов

Дескрипторы UNT СОПО перечислены в таблице 19.

8.5.2 Кодирование дескрипторов

8.5.2.1 Дескриптор target_smartcard_descriptor

Синтаксис дескриптора target_smartcard_descriptor приведен в таблице 20.

Синтаксис дескриптора target_smartcard_descriptor

super_CA_system_id — идентификатор DVB CA.

Номера смарт-карт передаются в поле private_data.

8.5.2.2 Дескриптор target_MAC_address_descriptor

Синтаксис дескриптора target_MAC_address_descriptor приведен в таблице 21.

Таблица 21

8.5.2.3 Дескриптор target_IP_address_descriptor

Синтаксис дескриптора target_IP_address_descriptor приведен в таблице 22.

Синтаксис дескриптора target_IP_address_descriptor

8.5.2.4 Дескриптор target_IPv6_address_descriptor

Синтаксис дескриптора target_IPv6_address_descriptor приведен в таблице 23.

Синтаксис дескриптора target_IPv6_address_descriptor

8.5.2.5 Дескриптор target_serial_number_descriptor

Синтаксис дескриптора target_serial_number_descriptor приведен в таблице 24.

Синтаксис дескриптора target_serial_number_descriptor

serial_data_byte — информация предназначена для целевых устройств на основе установленного идентификатора производства. Дальнейшее определение по семантике этой информации не подразумевается.

8.5.2.6 Дескриптор update_descriptor

Таблица 25

Синтаксис дескриптора update_descriptor

Семантика дескриптора update_descriptor:

• update_flag — это поле указывает, должно ли обновление выполняться автоматически. Кодировка поля update_flag приведена в таблице 26;

Таблица 26

Кодировка поля update_flag

• update_method — это поле определяет поведение приемника в процессе обновления. Поле носит рекомендательный характер. Кодировка поля update_method приведена в таблице 27.

• update_priority — четыре возможных значения от 0 до 3, определяющих приоритет, связанный с СОПО, где 0 является самым высоким приоритетом, 3 — самым низким приоритетом.

8.5.2.7 Дескриптор SSU_location_descriptor

Таблица 29

Семантика дескриптора SSU_location_descriptor:

• data_broadcast_id — указывает транспортный механизм. Значение 0x000A соответствует стандартной двухуровневой карусели данных СОПО;
• association_tag — 16-битовое поле, указывает на связь между соответствующим обновлением и потоками службы данных, что может быть реализовано с использованием либо дескриптора deferred_association_tag descriptor, либо дескриптора stream_identifier_descriptor. В последнем случае предполагается, что поле component_tag дескриптора stream_identifier_descriptor является младшим значащим байтом ссылочного значения association_tag.

8.5.2.8 Дескриптор SSU_subgroup_association_descriptor

Синтаксис дескриптора SSU_subgroup_association_descriptor приведен в таблице 30.

Таблица 30

subgroup_tag — 16 младших значащих битов этого поля должны содержать то же значение, что находится в поле GroupInfoBytes дескриптора subgroup_association_descriptor структуры GroupInfoIndication сообщения DSI. Это уникальное значение, определяющее полномочия держателя OUI и передаваемое в 24 старших значащих битах поля OUI. Связь между данным OUI и любым другим OUI системой не подразумевается.

8.5.2.9 Дескриптор scheduling_descriptor

Таблица 31

Синтаксис дескриптора scheduling_descriptor

Семантика дескриптора scheduling_descriptor:

• start_date_time и end_date_time — эти 40-битные поля указывают дату и время начала и окончания запланированного времени кампании обновления ПО. Фактическая доступность СОПО может быть дополнительно уточнена полями периодичности и смежными полями. Дата и время кодируются в формате DVB, указанном в поле UTC_time таблицы времени и даты (Time and Date Table; TDT) и таблицы смещения времени (Time Offset Table; TOT);
• final_availability — информативное поле, указывает срок действия расписания текущего обновления. Если установлено значение 1, то после завершения текущего расписания обновление будет недоступно. Если установлено значение 0 (по умолчанию), возможно, будущие расписания будут содержать это обновление;
• periodicity_flag — СОПО может быть доступна только периодически во время кампании обновления. Значение 1 в данном 1-битовом поле указывает, что расписание соответствует СОПО, которая доступна периодически между указанными датой и временем начала и окончания кампании обновления ПО;
• period_unit, duration_unit и expected_cycle_time_unit — эти поля указывают единицы времени, которые будут использоваться при интерпретации полей period, duration и estimated_cycle_time. Кодировка единиц времени приведена в таблице 32.

Таблица 32

• period — 8-битовое поле, определяет период повторения доступности СОПО, выраженный в единицах времени, определенных в поле period_unit. Первый период всегда начинается с запланированного времени start_date_time и периодически повторяется до запланированного end_date_time;
• duration — 8-битовое поле, определяет длительность времени, в течение которого СОПО доступна в начале каждого периода. Длительность выражается в единицах, определенных в поле duration_unit;
• estimated_cycle_time — расчетное время повторения необходимых данных для обновления ПО, выраженное в единицах, определенных полем estimated_cycle_time_unit. Значение поля, равное 0, означает, что это поле не используется.

8.5.2.10 Дескриптор telephone_descriptor (не обязательный)

Таблица 33

Семантика дескриптора telephone_descriptor:

• foreign_availability — 1-битовый флаг, если установлено значение «1», это означает, что указанный номер можно вызвать из-за пределов страны, указанной в country_prefix. Если установлено значение «0», это означает, что номер может быть вызван только из страны, указанной в country_prefix;
• connection_type — 5-битовое поле, которое указывает типы соединений. Например, с помощью данного поля приемник может быть проинформирован, что если после инициирования соединения соединение не происходит в течение 1 минуты, то попытка соединения должна быть прервана;
• country_prefix_length — 2-битовое поле, указывает количество 8-битовых буквенно-цифровых символов в префиксе страны;
• international_area_code_length — 3-битовое поле, указывает количество 8-битовых буквенно-цифровых символов в международном коде;
• operator_code_length — 2-битовое поле, указывает количество 8-битовых буквенно-цифровых символов в коде оператора;
• national_area_code_length — 3-битовое поле, указывает количество 8-битовых буквенно-цифровых символов в междугородном коде;
• core_number_length — 4-битовое поле, указывает количество 8-битовых буквенно-цифровых символов в базовом номере;
• country_prefix_char — 8-битовое поле, содержит один буквенно-цифровой символ префикса страны;
• international_area_code_char — 8-битовое поле, содержит один буквенно-цифровой символ международного кода;
• operator_code_char — 8-битовое поле, содержит один буквенно-цифровой символ кода оператора;
• national_area_code_char — 8-битовое поле, содержит один буквенно-цифровой символ междугородного кода;
• core_number_char — 8-битовое поле, содержит один буквенно-цифровой символ базового номера.

8.5.2.11 Дескриптор SSU_event_name_descriptor

Таблица 34

Семантика дескриптора SSU_event_name_descriptor:

• ISO_639_language_code — 24-битовое поле, содержит три символа кода языка (см. [2]), на котором идут следующие текстовые поля. Могут использоваться как [2] (код B), так и [2] (код T). Каждый символ кодируется в 8 бит и вставляется по порядку в 24-битовое поле (см. [3]).

Пример - Французский язык имеет 3-символьный код «fre», который кодируется как «0110 0110 0111 0010 0110 0101»;

• name_length — 8-битовое поле, содержит длину следующей строки имени;
• name_char — строка символов, предоставляет имя события СОПО;
• text_length — 8-битовое поле, указывает длину следующего поля text_char;
• text_char — 8-битовое поле. Текстовое сообщение формируется из набора таких полей.

8.5.2.12 Дескриптор message_descriptor

Таблица 35

Семантика дескриптора message_descriptor:

• descriptor_number — 4-битовое поле, дает номер дескриптора. Он используется для связывания информации с тем же кодом ISO_639_language_code, которую не допускается размещать в одном дескрипторе. Номер дескриптора первого дескриптора message_descriptor связанного набора дескрипторов message_descriptor должен быть равен нулю. Номер дескриптора должен увеличиваться на единицу с каждым дополнительным дескриптором message_descriptor с тем же кодом ISO_639_language_code в том же цикле;
• last_descriptor_number — 4-битовое поле, указывает номер последнего дескриптора message_descriptor (то есть дескриптора с наивысшим значением descriptor_number) в связанном наборе дескрипторов;
• ISO_639_language_code — 24-битовое поле, содержит три символа кода языка (см. [2]), на котором идут следующие текстовые поля. Могут использоваться как [2] (код) B, так и [2] (код T). Каждый символ кодируется в 8 бит и вставляется по порядку в 24-битовое поле (см. [3]);

Пример - Французский язык имеет 3-символьный код «fre», который кодируется как «0110 0110 0111 0010 0110 0101»;

• text_char — 8-битовое поле. Текстовое сообщение формируется из набора таких полей.

8.5.2.13 Дескриптор private_data_specifier_descriptor (не обязательный)

Синтаксис дескриптора private_data_specifier_descriptor приведен в таблице 36.

Таблица 36

8.5.2.14 Дескриптор enhanced_message_descriptor

Таблица 37

Семантика дескриптора enhanced_message_descriptor:

• descriptor_number — 4-битовое поле, устанавливает номер дескриптора. Он используется для связывания информации с общей комбинацией полей ISO_639_language_code и message_index, которая может быть разделена на несколько дескрипторов enhanced_message_descriptor. Номер дескриптора первого дескриптора message_descriptor связанного набора дескрипторов message_descriptor должен быть равен нулю. Номер дескриптора должен увеличиваться на единицу с каждым дополнительным дескриптором enhanced_message_descriptor;
• last_descriptor_number — 4-битовое поле, указывает номер последнего дескриптора enhanced_message_descriptor (то есть дескриптора с наивысшим значением descriptor_number) в связанном наборе дескрипторов;
• ISO_639_language_code — 24-битовое поле, содержит три символа кода языка (см. [2]), на котором идут следующие текстовые поля. Могут использоваться как [2] (код) B, так и [2] (код T). Каждый символ кодируется в 8 бит и вставляется по порядку в 24-битовое поле (см. [3]).

Пример - Французский язык имеет 3-символьный код «fre», который кодируется как «0110 0110 0111 0010 0110 0101»;

• text_char — 8-битовое поле. Текстовое сообщение формируется из набора таких полей.

8.5.2.15 Дескриптор ssu_uri_descriptor

Таблица 38

Семантика дескриптора ssu_uri_descriptor:

• max_holdoff_time — 8-битовое поле, указывающее максимальное количество времени до прекращения попыток подключения. Приемник должен подождать случайное число секунд перед подключением к интернет-серверу. Случайная задержка должна лежать в пределах числа от 0 до 60, умноженного на значение данного поля. Значение, равное 0, означает, что подключения могут устанавливаться немедленно, если время, прошедшее после последнего подключения к серверу, превышает время, указанное в поле min_polling_interval.

Примеры

1 Если max_holdoff_time равно 5, случайная задержка лежит в пределах от 0 до 300 с.

2 Если max_holdoff_time равно 255, случайная задержка лежит в пределах от 0 до 15 300 с (т.е. задержка до 4 ч и 15 мин);

• min_polling_interval — 8-битовое поле, указывает минимальный интервал в часах между запросами приемника на соединение с интернет-сервером. Значение ноль означает, что минимальный интервал не используется, приемник должен выбирать значение, установленное у него по умолчанию.

Примеры

1 Если min_polling_interval равен 24, приемник должен ожидать минимум 24 ч между попытками подключения.

2 Если min_polling_interval равен 255 (максимальное значение), приемник должен ожидать минимум 10 дней и 15 ч между попытками подключения.

3 Если min_polling_interval равен 24 и max_holdoff_time равно 240, приемник будет ожидать до 4 ч перед первым подключением к серверу. Если приемник не сможет загрузить обновление с первой попытки, он должен будет ожидать от 24 до 28 ч до повторной попытки подключения к серверу.

Соотношение max_holdoff_time и min_polling_interval показано на рисунке 4.

• uri_char — 8-битовое поле. Строка унифицированного идентификатора ресурса (Uniform Resource Identifier; URI) формируется из набора таких полей.

8.6 Дескрипторы карусели данных системы обновления программного обеспечения

8.6.1 Кодирование дескрипторов

8.6.1.1 Дескриптор subgroup_association_descriptor

Синтаксис дескриптора subgroup_association_descriptor приведен в таблице 39.

Таблица 39

subgroup_tag — 16 младших значащих битов этого поля должны содержать то же самое значение, что содержится в дескрипторе SSU_subgroup_association_descriptor таблицы UNT. Это уникальное значение, определяющее полномочия держателя OUI и передаваемое в 24 старших значащих битах поля OUI. Связь между данным OUI и любым другим OUI в системе не подразумевается.

8.6.1.2 Дескриптор совместимости

Когда UNT имеет важное значение для загрузки, дескриптор совместимости аппаратного обеспечения, используемый в структуре groupInfo карусели данных СОПО, необходимо заменить. OUI заменяемого дескриптора совместимости аппаратного обеспечения должен быть установлен в зарезервированное СОПО DVB значение, равное 0x00015A, поля модели и версии зарезервированы и каждое из них должно содержать значение 0xFFFF. Оригинальный дескриптор совместимости аппаратного обеспечения, включая любые поддескрипторы (если присутствуют), должен быть скопирован в поддескриптор этого замещающего дескриптора совместимости аппаратного обеспечения.

Приемник с расширенным профилем служб СОПО на базе таблицы UNT, проверяющий совместимость по структуре groupInfo, обнаруживший значение СОПО DVB OUI, равное 0x00015A, должен найти оригинальный дескриптор совместимости аппаратного обеспечения в цикле поддескриптора, но не должен предпринимать никаких действий без предварительной сверки с соответствующей таблицей UNT.

Запрещено использовать дескриптор совместимости СОПО DVB в цикле дескриптора совместимости структуры groupInfo иначе, чем описано ранее.

8.7 Требования к взаимодействию операторов

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

• оператор должен иметь возможность принимать данные UNT, предоставленные производителем приемника, с максимальным размером секции 4096 байт;
• оператор должен иметь возможность изменять все необходимые поля данных UNT, предоставленные изготовителем, чтобы сформировать актуальную таблицу UNT;
• если обновление ПО доступно через широковещательную рассылку, то оператор должен поддерживать карусель стандартных данных СОПО как формат для передачи актуальной службы СОПО. Кроме этого, могут поддерживаться другие форматы;

- если обновление ПО доступно через широковещательную рассылку, то оператор должен иметь возможность поддерживать дескриптор scheduling_descriptor. Предполагаемое время предварительного объявления может составлять одну неделю. Расписание обновления ПО может состоять из нескольких дескрипторов scheduling_descriptors. Поддержка оператором дескриптора scheduling_descriptor может быть реализована путем разрешения производителю приемника предоставлять scheduling_descriptor как часть UNT данных (после согласования с оператором актуального расписания);

• минимальные рекомендуемые параметры повторения UNT определяются как:
• 10 с по кабельным и спутниковым сетям;
• 60 с в наземных сетях;
• если обновление ПО доступно через широковещательную рассылку, то DSI и каждый DII должны повторяться каждые 5 с.

8.8 Требования к взаимодействию приемников

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

• простой профиль СОПО, определенный в 4.1, должен поддерживаться;
• все варианты поиска подходящей UNT через NIT/BAT и сканирование PMT должны поддерживаться;
• все требования настоящего стандарта должны быть применимы к сканированию/интерпретации UNT;
• приемники должны проверять action_type и выполнять только те действия, которые они поддерживают. Приемники должны игнорировать неподдерживаемые actions_types;
• приемники должны поддерживать значение processing_order, равное 0xFF. Поддержка других значений processing_order является необязательной;
• приемники должны поддерживать дескриптор compatibilityDescriptor() согласно 8.4.2.3;
• приемники должны иметь возможность анализировать и отрабатывать следующие дескрипторы: - scheduling_descriptor; - SSU_location_descriptor; - SSU_subgroup_association_descriptor; - private_data_specifier_descriptor;
• обработка дескрипторов в цикле назначения должна соответствовать 8.4.2.4.

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

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

В каждой подтаблице UNT должен быть как минимум один дескриптор compatibilityDescriptor (дескриптор совместимости).

Цикл назначения (target_descriptor_loop) может быть пустой. Если он пуст, то все устройства, соответствующие информации OUI и дескрипторам compatibilityDescriptor, являются адресуемыми.

Каждое обновление, указанное одним дескриптором совместимости, должно быть локализовано с помощью информации о разрешении местоположения (Location Resolution Information; LRI).

Для СОПО LRI может быть представлена:

• в дескрипторе SSU_location_descriptor; или
• дескрипторе ssu_uri_descriptor; или
• дескрипторе phone_descriptor.

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

БИБЛИОГРАФИЯ