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

        ГОСТ Р 59808-2021

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

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

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

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

ОКС 33.170

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

Предисловие

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

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 26 октября 2021 г. N 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 г. N 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 В настоящем стандарте применены следующие сокращения:

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 СОПО).

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

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

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

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

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

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

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

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

- OUI_data_length - поле длиной 8 бит, указывает длину в байтах цикла OUI;

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

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

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

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

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

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

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

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

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

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

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

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

- transport_stream_id - поле длиной 16 бит, которое идентифицирует транспортный поток (Transport Stream; TS), содержащий BAT СОПО или NIT;

- original_network_id - поле длиной 16 бит, дает метку, показывающую идентификатор сети network_id исходной системы доставки BAT СОПО или NIT;

- service_id - поле длиной 16 бит, которое не имеет значения и должно быть установлено в 0x0000;

- Iinkage_type - поле длиной 8 бит, указывает тип связей и должно быть установлено в 0х0A;

- table_type - поле длиной 8 бит, содержит флаг, указывающий либо на BAT СОПО, либо на NIT. Оно должно быть закодировано в соответствии с таблицей 3.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 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 со значением 0x00015А указывает, что поток исходит от любого OUI;

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

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

- 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.

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

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

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

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

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

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

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

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

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

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

- serverld - это поле должно содержать 20 байтов со значением 0xFF;

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

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

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

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

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

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

Таблица 6 - Структура Grouplnfolndication

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- transactionld - идентификатор транзакции, для сообщений Downloadlnfolndication (DII) должен находиться в диапазоне 0x0002 0xFFFF, чтобы отличать его от идентификатора транзакции сообщения DownloadServerlnitiate (DSI). Идентификатор transaction равен groupld (номер группы) в соответствующей структуре grouplnfo в DSI;

- downloadld - эквивалентно transactionId.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Семантика SSU_type_descriptor:

- descriptor_tag - 8-битовое поле, идентифицирует дескриптор. Для дескриптора типа СОПО установлено значение 0х0A;

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

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

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

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

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

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

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

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

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

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

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

РМТ ссылается на UNT путем включения дескриптора data_broadcast_id_descriptor (data_ broadcast_id = 0х000A) в цикл ES_info, где параметр update_type в структуре system_software_update_info установлен в значение 0x2, 0x3 или 0x4. Параметр OUI структуры system_software_update_info может быть либо установлен в зарезервированный DVB IEEE OUI, равный 0x00015А, указывающий, что выбор обновления возможен только путем анализа UNT (ссылка находится в текущем потоке в записи РМТ), либо OUI должен содержать актуальный IEEE OUI, соответствующий индексу подтаблицы UNT (приложение А).

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

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

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

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

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

_______________

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

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

_______________

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

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

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

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

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

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

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

Второй цикл обеспечивает механизм, с помощью которого несколько приемников могут быть адресованы к одной секции подтаблицы. Первым элементом данного цикла является дескриптор 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 уникально определен 0x4В;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 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 - Синтаксис дескриптора target_MAC_address_descriptor

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 28 - Пример использования update_method и update_flag

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

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

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

Таблица 29 - Синтаксис дескриптора SSU_location_descriptor

Семантика дескриптора 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 - Синтаксис дескриптора SSU_subgroup_association_descriptor

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

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

Синтаксис дескриптора scheduling_descriptor приведен в таблице 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_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 (не обязательный)

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

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

Семантика дескриптора 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

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

Таблица 34 - Синтаксис дескриптора SSU_event_name_descriptor

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

- ISO_639_language_code - 24-битовое поле, содержит три символа кода языка (см. [2]), на котором идут следующие текстовые поля. Могут использоваться как [2] (код В), так и [2] (код Т). Каждый символ кодируется в 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

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

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

Семантика дескриптора 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] (код) В, так и [2] (код Т). Каждый символ кодируется в 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 - Синтаксис дескриптора private_data_specifier_descriptor

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

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

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

Семантика дескриптора 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] (код) В, так и [2] (код Т). Каждый символ кодируется в 8 бит и вставляется по порядку в 24-битовое поле (см. [3]).

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

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

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

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

Таблица 38 - Синтаксис дескриптора ssu_uri_descriptor

Семантика дескриптора 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 до 15300 с (т.е. задержка до 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.

Рисунок 4 - Соотношение max_holdoff_time и min_polling_interval

- 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_association_descriptor

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

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

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

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

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

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/ВАТ и сканирование РМТ должны поддерживаться;

- все требования настоящего стандарта должны быть применимы к сканированию/интерпретации 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)

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

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