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

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

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

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

Технические требования к системе обновления программного обеспечения в системах цифрового телевизионного вещания

[ETSI TS 102 006 V1.4.1 (2015-06), NEQ]

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

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

Предисловие

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

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

• 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 г. Nt 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (но состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в ин-формационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

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

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложение А (обязательное) Использование дескрипторов таблицы уведомления об обновлении UNT

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

ГОСТ Р 59808—2021

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

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

Технические требования к системе обновления программного обеспечения в системах цифрового телевизионного вещания

Digital video broadcasting. Specifications for system software update in DVB systems

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

• 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);

• - Dll — индикация информации о загрузке (Downloadlnfolndication);

• - 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 — Международная организация no стандартизации (International Standards Organization);

• - LRI — информация о разрешении местоположения (Location Resolution Information);

• - mi — поле, содержащее дескрипторы с необходимой информацией, в том числе указатель на локацию сообщений DownloadDataBlock (ModulelnfoBytes);

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

• - OU I — уникальный идентификатор организации (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; ВАТ) и в таблице карты программ (Program Map Table; РМТ) и не требует таблицы уведомления об обновлении (Update Notification Table; UNT);

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

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

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

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

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

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

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

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

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

• - проприетарный (собственный) формат:

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

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

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

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

ВАТ СОПО идентифицируется с помощью идентификатора bouquetjd, равного OxFFOO. и. если используется дескриптор country_availabitity_descnptor. применяется код страны 902 (т. е. все страны). Если ВАТ СОПО переносится в каком-либо транспортном потоке сети, она должна быть такой же. как и в любом другом транспортном потоке данной сети с ВАТ СОПО.

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

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

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

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

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

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

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

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

• - OUI_data_length — поле длиной 8 бит. указывает длину в байтах цикла OUI:

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

• * selectorjength — поле длиной 8 бит. указывает общую длину в байтах последующего поля се-лектора;

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

• - private_data_byte — поле длиной 8 бит.

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

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

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

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

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

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

Таблица 2 — Синтаксис дескриптора связей поиска службы СОЛО типа ОхОА

Семантика дескриптора сеяэей типа ОхОА:

• - transport_stream_ki—поле длиной 16 бит. которое идентифицирует транспортный поток (Transport Stream; TS). содержащий ВАТ СОЛО или NIT;

• - original_network_id — поле длиной 16 бит. дает метку, показывающую идентификатор сети networkjd исходной системы доставки ВАТ СОЛО или NIT;

• • service_wj — поле длиной 16 бит. которое не имеет значения и должно быть установлено в 0x0000;

• ■ lmkage_type — поле длиной 8 бит, указывает тип связей и должно быть установлено в ОхОА;

• ■ table_type — поле длиной 8 бит. содержит флаг, указывающий либо на ВАТ СОЛО, либо на NIT. Оно должно быть закодировано в соответствии с таблицей 3.

Таблица 3—Кодирование поля table_type

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

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

РМТ транспортного потока, несущего данные о СОЛО, должна содержать дескриптор data_ broadcastjd с идентификатором широковещательной передачи данных ОхОООАдля указания элемен* тарного потока, используемого для службы СОЛО.

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

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

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

• - дескриптор предоставляет ссылку на UNT.

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

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

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

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

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

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

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

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

• • setector_byte — байты селектора, передают структуру system_software_updatejnfo, синтаксис которой представлен в таблице 4.

Таблица 4 — Синтаксис структуры system.software.update.rifo

Семантика байтов id.setector для data_broadcast_id ОхОООА:

• • OUI_data_length — поле указывает общую длину в байтах цикла OUI;

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

• • update_type — 4-битовое поле, определяющее тип службы СОПО. Оно должно кодироваться в соответствии с таблицей 5.

Таблица 5 — Кодирование поля update_lype

• - 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-битовое поле. Последовательность полей setector_byte определяет поле селектора. Это поле предоставляет информацию, являющуюся дополнительной к OUI. которая может использоваться приемником для нахождения и идентификации службы СОПО. например, тип модели или диапазоны. Синтаксис и семантика поля селектора определяются организацией, идентифицированной через OUI.

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

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

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

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

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

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

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

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

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

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

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

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

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

«transactions — два младших значащих байта идентификатора транзакции DSI должны находиться в диапазоне от 0x0000 до 0x0001. Младший значащий бит актуального идентификатора транзакции изменяется каждый раз, когда происходит изменение базовой структуры карусели (т. е. когда группа добавляется. изменяется или удаляется). Два старших значащих байта (биты 31—16) содержат число, которое идентифицирует версию карусели и может использоваться для обнаружения изменения версии;

• - servers — это поле должно содержать 20 байтов со значением OxFF:

• - compatibilityDescriptor() — эта структура должна содержать только поле CompatibilityDescriptor-Length дескриптора CompatibilityDescriptor(). как определено в DSM-CC. Оно должно быть установлено в значение 0x0000.

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

• - privateDataLength — это поле определяет длину в байтах последующей структуры Grouplnfolndication;

• - privateDataByte — эти поля должны передавать структуру Grouplnfolndication согласно таблице 6.

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

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

Таблица 6 — Структура Grouplnfotndication

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

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

Таблица 7 — Дескриптор CompatibilityOescriptor в структуре Grouplnfolndication

Таблица 8—Кодировка поляdescriptorType

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

• • numberOfGroups — 1 S-битовое поле, указывающее количество групп, описанных в цикле, следу* ющих за этим полем;

• • groupld — 32-битовое поле, которое должно быть равно transactions сообщения Downloadinfoindication, описывающее группу;

• - groupSize — 32-битовое поле, которое должно указывать совокупный размер в байтах всех модулей в группе:

• - groupCompatibility — структура GroupCompatibility. эквивалентная структуре CompatibitityDescnp-tor DSM-CC. CompatibilityDescfiptor должен содержать дескриптор аппаратного обеспечения системы, содержащий OUI в структуре system_software_update_info дескриптора data_broadcast_id_descriptor в РМТ, Если имеется несколько обновлений одного и того же производителя, то поля model и version в дескрипторе аппаратного обеспечения системы и дескриптор ПО системы могут использоваться приемником для выбора корректного потока. Применяются только дескрипторы типа 0x01 и 0x02 (дескриптор аппаратного и программного обеспечения системы);

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

• - groupInfoByte — не определено в настоящем стандарте;

• - privateDataLength — это поле определяет длину в байтах полей privateDataByte;

• - privateDataByte — данные поля не используются.

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

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

• - transactions — идентификатор транзакции, для сообщений Downioadlnfolndication (Dll) должен находиться в диапазоне 0x0002 OxFFFF. чтобы отличать его от идентификатора транзакции сообщения DownloadServerlnitiate (DSI). Идентификатор transactions равен groupld (номер группы) в соответствующей структуре grouplnfo в DSI;

• - downloads — эквивалентно transactions.

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

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

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

• - биты с 15 по 8 имеют то же значение, что и младшие значащие биты groupld в соответствующей структуре grouplnfo в DSI. ссылающегося на данную конкретную загрузку;

• - биты с 7 по 0: являются modules конкретной загрузки, поддерживается 256 модулей.

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

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

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

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

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

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

• - modules — идентификатор модуля, к которому принадлежит текущий блок;

• - moduleversion — равно полю moduleversion в структуре модуля DII, к которому принадлежит текущий блок;

• - blockNumber — идентифицирует позицию блока в модуле. Блок под номером 0 должен быть первым блоком в модуле.

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

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

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

Таблица 9 — Кодировка дескриптора SSU_type_descriptor

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

Семантика SSU_type_descriptor:

• - descriptorjag — 8-битовое поле, идентифицирует дескриптор. Для дескриптора типа СОПО установлено значение ОхОА:

• - descriptorjengtti — 8-битовое поле, указывает количество байтов дескриптора, следующих сразу же после этого поля;

• * SSU_module_type — 8-битовое поле типа модуля СОПО. Типы модуля СОПО определены в таблице 10.

Таблица 10 — Типы модулей СОПОSSU_modute_type

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

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

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

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

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

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

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

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

РМТ ссылается на UNT путем включения дескриптора data_broadcastjd_descriptor (data_ broadcastjd = ОхОООА) в цикл ESjnfo. где параметр update_type в структуре system_software_update_ info установлен в значение 0x2, 0x3 или 0x4. Параметр OUI структуры system_software_update_info может быть либо установлен в зарезервированный DVB IEEE OUI. равный 0х00015А, указывающий, что выбор обновления возможен только путем анализа UNT (ссылка находится в текущем потоке в записи РМТ). либо OUI должен содержать актуальный IEEE OUI. соответствующий индексу подтаблицы UNT (приложение А).

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

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

Успешный поиск выдает ссылку на соответствующую карусель данных через поле associationjag дескриптора SSU_location_descriptor. Поле associationjag используется в сочетании с дескриптором deferred association_tag_descriptor() в цикле дескриптора программы РМТ или с дескриптором stream. identifierjJescriptorO в цикле ESJnfo потока служебных компонентов РМТ.

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

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

* OUI со значением Ох00015А приведен в качестве примера. Могут использоваться иные OUi или списки OUI.

Рисунок 2 — Пример служб СОПО со ссылкой на UNT

* OUI со значением 0х00О15А приведен в качестве примера. Могут использоваться иные OUI или списки OUI.

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

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

UNT описывает доступность и местоположение СОПО (приложение А). Может существовать одна или несколько UNT, охватывающих все СОПО сети. UNT ссылается через дескриптор data_broadcast_ id_descnptor (data_broadcast_id = ОхОООА) в цикле ESJnfo таблицы РМТ. где поле update_type в структуре system_software_update Jnfo устанавливается в 0x2 или 0x3 (с указанием ссылки на UNT). Параметр OUI структуры systetn_software_updatejnfo может быть либо установлен в зарезервированный DVB IEEE OUI. равный 0х0О015А. указывающий, что выбор обновления возможен только путем анализа UNT. либо OUI должен содержать актуальный IEEE OUI. соответствующий индексу подтаблицы UNT.

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

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

Секция подтаблицы далее подразделяется на пять иерархических циклов. Первый цикл, common. descriptorJoopO, содержит список дескрипторов, которые, если они не переопределены в цикле operational-descriptor_toop(), применяются ко всем СОЛО в данной секции подтаблицы.

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

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

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

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

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

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

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

Таблица 11—Синтаксис UNT

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

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

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

Семантика полей преамбулы:

• • tablejd — для таблицы UNT уникально определен 0x4В;

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

Таблица 12 — Кодировка поля action.lype

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

OUl.hash = OUI {23.. 16] XOR OUI [15..8] XOR OUI [7..0];

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

• • OUI — поле IEEE OUI. выбранное для формирования индекса подтаблицы;

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

Таблица 13 — Кодировка processing_order

• • platformjoopjength — 16-битовое поле указывает объединенную длину последующих циклов target_descriptorjoop () и operational-descriptor Joop ().

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

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

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

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

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

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

Таблица 15 — Синтаксис структуры compatibilityDescriptor()

Таблица 16 — Кодировка поля descriptorType

• 8.4.2.4 Дескриптор target_descriptorJoopO

Синтаксис дескриптора target-descriptorJoopO приведен е таблице 17.

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

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

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

Таблица 18 — Синтаксис дескриптора operaltonal_descriptor_loop()

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

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

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

Таблица 19 — Дескрипторы UNTСОЛО

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

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

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

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

Таблица 20 — Синтаксис дескриптора larget.smartcard.descriplor

super_CA_system_jd — идентификатор DVB СА.

Номера смарт-карт передаются в none private.data.

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

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

Таблица 21 —Синтаксис дескриптора larget.MAC.address.descriptor

• 8.5.2.3 Дескриптор targetJP_address_descriptor

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

Таблица 22 — Сжтаксис дескриптора target_IP_address_descriplor

• 8.5.2.4 Дескриптор target_IPv6_addfess_descriplor

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

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

• 8.5.2.5 Дескриптор targel_seriaLnumber_descriptor

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

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

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

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

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

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

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

Семантика дескриптора update.descriptor:

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

Таблица 26 — Кодировка поля update_flag

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

Таблица 27 — Кодировка поля update_method

Пример использования updatejnethod и update_flag приведен в таблице 28.

Таблица 28 — Пример использования update.method и update_flag

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

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

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

Синтаксис дескриптора SSUJocation.descriptor приведен в таблице 29.

Таблица 29 — Синтаксис дескриптора SSU_locat»on_descriptor

Семантика дескриптора SSU_locat)on_descriptof:

• • data_broadcast_id — указывает транспортный механизм. Значение ОхОООА соответствует стандартной двухуровневой карусели данных СОЛО;

• - association.tag — 16-битовое поле, указывает на связь между соответствующим обновлением и потоками службы данных, что может быть реализовано с использованием либо дескриптора deferred-association-tag descriptor, либо дескриптора stream.identifier-descriptor. В последнем случае предполагается. что поле component-tag дескриптора stream_identifier_descripto< является младшим значащим байтом ссылочного значения association_tag.

• 8.5.2.8 Дескриптор SSU_subgroup_associat>on_descriptor

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

Таблица 30 — Синтаксис дескриптора SSU_subgnoup_associat>on_descrip(or

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

• 8.5.2.9 Дескриптор scheduling.descriptor

Синтаксис дескриптора scheduling.desaiptor приведен в таблице 31.

Таблица 31 —Синтаксис дескриптора scheduling.descriptor

Семантика дескриптора scheduling.descriptor:

• - start_date_time и end_date .time — эти 40-битные поля указывают дату и время начала и окончания запланированного времени кампании обновления ПО. Фактическая доступность СОЛО может быть дополнительно уточнена полями периодичности и смежными полями. Дата и время кодируются в формате DVB. указанном в поле UTC.time таблицы времени и даты (Time and Date Table; TDT) и таблицы смещения времени (Time Offset Table; ТОТ);

• - final_availabil ity — информативное поле, указывает срок действия расписания текущего обновления. Если установлено значение 1. то после завершения текущего расписания обновление будет недоступно. Если установлено значение 0 (по умолчанию), возможно, будущие расписания будут содержать это обновление;

• - periodicrty.flag — СОЛО может быть доступна только периодически во время камлании обновления. Значение 1 в данном 1-битовом поле указывает, что расписание соответствует СОЛО, которая доступна периодически между указанными датой и временем начала и окончания кампании обновления ПО;

• - period.unit. duration.unit и expected.cycle.time.unit — эти поля указывают единицы времени, которые будут использоваться при интерпретации полей period, duration и estimated.cycle.time. Кодировка единиц времени приведена в таблице 32.

Таблица 32 — Кодировка единиц времени

• - period — 8-битовое поле, определяет период повторения доступности СОПО. выраженный в единицах времени, определенных в поле period.unil. Первый период всегда начинается с запланированного времени start_date_time и периодически повторяется до запланированного end.date.time;

• - duration — 8-битовое поле, определяет длительность времени, в течение которого СОПО доступна в начале каждого периода. Длительность выражается в единицах, определенных в поле duration.unit;

• • estimated_cycle_time — расчетное время повторения необходимых данных для обновления ПО. выраженное в единицах, определенных полем estimated_cycle_time_unit. Значение поля, равное 0. означает, что это поле не используется.

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

Синтаксис дескриптора telephone-descriptor приведен в таблице 33.

Таблица 33 — Синтаксис дескриптора telephone-descriptor

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

Семантика дескриптора telephone-descriptor.

• • foreign.availability — 1-битовый флаг, если установлено значение «1». это означает, что указанный номер можно вызвать из-за пределов страны, указанной в country.prefix. Если установлено значение «0». это означает, что номер может быть вызван только из страны, указанной в country .prefix;

• - connection.type — 5-битовое поле, которое указывает типы соединений. Например, с помощью данного поля приемник может быть проинформирован, что если после инициирования соединения соединение не происходит в течение 1 минуты, то попытка соединения должна быть прервана:

• « country_prefix_length — 2-битовое поле, указывает количество 8-битовых буквенно-цифровых символов в префиксе страны;

• - intemational.area.code.length — 3-битовое поле, указывает количество 8-битовых буквенноцифровых символов в международном коде;

• - operator.code.length — 2-битовое поле, указывает количество 8-битоеых буквенно-цифровых символов в коде оператора;

• - national.area.code.fength — 3-битовое поле, указывает количество 8-битовых буквенно-цифро-вых символов в междугородном коде;

• - core.numberjength — 4-битовое поле, указывает количество 8-битовых буквенно-цифровых символов в базовом номере;

• - country_pfefix_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

Синтаксис дескриптора SSU.event.name.descriptor приведен в таблице 34.

Таблица 34 — Синтаксис дескриптора SSU.event.name.descriptor

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

• * ISO.639Janguage.code — 24-битовое поле, содержит три символа кода языка (см. [2]). на ко-тором идут следующие текстовые поля. Могут использоваться как [2] (код В), так и [2] (код Т). Каждый символ кодируется в 8 бит и вставляется по порядку в 24-битовое поле (см.{3]).

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

• ■ namejength — 8-битовое поле, содержит длину следующей строки имени;

• • name.char — строка символов, предоставляет имя события СОПО;

• ■ textJe ng th — 8-битовое поле, указывает длину следующего поля text.char;

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

• 8.5.2.12 Дескриптор message_descriptof

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

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

Семантика дескриптора message.descriptor:

• - descnptor_number — 4-битовое поле, дает номер дескриптора. Он используется для связывания информации с тем же кодом ISO.639_language.code. которую не допускается размещать в одном дескрипторе. Номер дескриптора первого дескриптора message_descriptor связанного набора дескрипторов message ^descriptor должен быть равен нулю. Номер дескриптора должен увеличиваться на единицу с каждым дополнительным дескриптором message_descriptor с тем же кодом ISO_639_language_ code в том же цикле;

• - Iast_descriptor_number — 4-битовое поле, указывает номер последнего дескриптора message, descriptor (то есть дескриптора с наивысшим значением descriptor.number) в связанном наборе дескрипторов;

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

Пример — Французский язык имеет 3-символьный код *1ге». который кодируется как *0110 0110 0111 0010 0110 0101»;

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

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

Синтаксис дескриптора private.data.specifier.descriptor приведен в таблице 36.

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

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

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

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

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

Семантика дескриптора enhanced_mes$age_descriptor:

• - descriptor.number — 4-битовое поле, устанавливает номер дескриптора. Он используется для связывания информации с общей комбинацией полей ISO_639_language_code и messagejndex, которая может быть разделена на несколько дескрипторов enhanced_message_descriptor. Номер дескриптора первого дескриптора message.descriptor связанного набора дескрипторов message-descriptor должен быть равен нулю. Номер дескриптора должен увеличиваться на единицу с каждым дополнительным дескриптором enhanced_message_descriptor;

• - Iast_descriptor_number — 4-битовое поле, указывает номер последнего дескриптора enhanced. message-descriptor (то есть дескриптора с наивысшим значением descriptor.number) в связанном наборе дескрипторов:

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

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

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

• 8.5.2.15 Дескриптор ssu.uri.descriptor

Синтаксис дескриптора ssu.uri.descnptor приведен в таблице 38.

Таблица 38 — Синтаксис дескриптора ssu.uri.descnptor

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

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

- max_ho4doff_time — 8-битовое поле, указывающее максимальное количество времени до прекращения попыток подключения. Приемник должен подождать случайное число секунд перед подключением к интернет-серверу. Случайная задержка должна лежать в пределах числа от 0 до 60. умноженного на значение данного поля. Значение, равное 0, означает, что подключения могут устанавливаться немедленно, если время, прошедшее после последнего подключения к серверу, превышает время, указанное в поле minjx>ll<ng_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_intefval равен 24. приемник должен ожидать минимум 24 ч между попытками подключения.

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

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

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

Рисунок 4 — Соотношение max_holdoff_time и min_pol1ing_interval

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

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

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

    • 8.6.1.1 Дескриптор subgroup_associat>on_descriptor

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

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

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

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

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

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

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

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

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

• - оператор должен иметь возможность принимать данные UNT. предоставленные производителем приемника, с максимальным размером секции 4096 байт;

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

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

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

• - минимальные рекомендуемые параметры повторения UNT определяются как:

• - 10 с по кабельным и спутниковым сетям;

• - 60 с в наземных сетях;

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

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

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

• - простой профиль СОПО. определенный в 4.1. должен поддерживаться;

• - все варианты поиска подходящей UNT через NIT/BAT и сканирование РМТ должны поддерживаться;

• • все требования настоящего стандарта должны быть применимы к сканированию/интерпретации UNT;

• - приемники должны проверять act>on_type и выполнять только те действия, которые они поддерживают. Приемники допжны игнорировать неподдерживаемые actionsjypes;

• - приемники должны поддерживать значение processing_order. равное OxFF. Поддержка других значений processing.order является необязательной;

• • приемники должны поддерживать дескриптор compatibilityDescriptor() согласно 8.4.2.3;

• ■ приемники должны иметь возможность анализировать и отрабатывать следующие дескрипторы:

• - scheduling_descriptor;

• - SSU_tocation_descfiptor;

• - SSU_subgroup_association_descriptor;

• - pnvate_data_specifiec_descriptor;

• . обработка дескрипторов в цикле назначения должна соответствовать 8.4.2.4.

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

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

Использование дескрипторов таблицы уведомления об обновлении (UNT)

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

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

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

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

• - в дескрипторе SSUJocation_descriptor; или

• • дескрипторе ssu_uri_descriptoc или

• - дескрипторе phone_descriptor.

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

УДК 621.397.132.129:006.354

Ключевые слова: приемник, программное обеспечение, обновление, нотификация, дескриптор. UNT, DVB

Редактор Е.В. Якубова Технический редактор И.Е. Черепкова Корректор ЕЛ- Дульнева Компьютерная верстка Е.О. Асташина

Сдано в набор 28.10.202! Подписано в печать 22.>1.2021. Формат 80*84И. Гарнитура Ариал. Усп. печ. л. 4.18. Уч.-иад. л. 3.78.

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

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

www.90slinfo.ru info@gostnfo.ru