ГОСТ Р 59803-2021 Телевидение вещательное цифровое. Расширенные технические требования к передаче транспортных потоков служб DVB по сетям с IP-протоколами. Часть 4. Служба загрузки контента в домашнее оконечное устройство. Основные параметры

        ГОСТ Р 59803-2021

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

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

Расширенные технические требования к передаче транспортных потоков служб DVB по сетям с IP-протоколами

Часть 4

Служба загрузки контента в домашнее оконечное устройство. Основные параметры

Digital video broadcasting. Extended technical requirements for transmitting DVB service transport streams over networks with IP protocols. Part 4. Service of the download content in the home the end device. Basic parameters

ОКС 33.170

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

Предисловие

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

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

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

4 Настоящий стандарт разработан с учетом основных нормативных положений документа Европейского института по стандартизации в области телекоммуникаций (ETSI) ETSI TS 102 034 V2.1.1 (2016-04)* "Телевидение вещательное цифровое. Передача транспортных потоков MPEG-2 основных служб DVB по основным сетям IP" (ETSI TS 102 034 V2.1.1 (2016-04) "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks", NEQ)

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

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

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

Настоящий стандарт предусматривает расширение набора спецификаций ГОСТ Р 54994, относящихся к передаче служб DVB в транспортных потоках MPEG-2, по двунаправленным IP-сетям добавлением поддержки:

- динамического управления службами, обеспечивающего эффективное использование пропускной способности сети;

- технологии IPv6.

Стандарт содержит детализированные определения процессов и параметров:

- анонсирования службы загрузки контента;

- форматов элементов контента и файлов службы загрузки контента;

- описания сеанса загрузки CDS;

- загрузки элементов контента CDS;

- управления устройством хранения HNED.

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

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

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

ГОСТ Р 53528 Телевидение вещательное цифровое. Требования к реализации протокола высокоскоростной передачи информации DSM-CC. Основные параметры

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

ГОСТ Р 55697 Телевидение вещательное цифровое. Сервисная информация. Общие технические требования

ГОСТ Р 55713 Телевидение вещательное цифровое. Кодирование для защиты от ошибок при передаче служб DVB по сетям с IP протоколами. Основные параметры

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

ГОСТ Р 56476-2015 Телевидение вещательное цифровое. Система TV-Anytime. Схемы метаданных. Основные параметры

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

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

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

3.1.1 дом (home): Расположение, в котором завершена сеть доступа (IPI-1), находится соединение с полным комплектом оборудования сети и которое является домашней платформой клиента.

Примечания

1 Термин "расположение" используется в логическом смысле.

2 Термины "дом" и "клиент" в контексте настоящего стандарта являются синонимами.

3.1.2 домен (domain): Автономная часть сети или распределенной системы.

3.1.3 интернет-протокол; IP (Internet protocol, IP): Межсетевой протокол пакетной передачи, который работает:

- с 32-битовыми адресами (версия IPv4) и с 128-битовыми адресами (версия IPv6), обеспечивает адресацию и маршрутизацию пакетов в сети;

- без установления соединения, не обеспечивает сохранение порядка следования пакетов, не гарантирует доставку пакетов.

3.1.4 клиент (customer): Лицо(а), заключившее(ие) договор для получения служб IPTV, предоставленных в сети доступа и ответственных за администрирование этой связи.

3.1.5 локатор (locator): Расположение (местоположение) одного или нескольких URI, в которых могут быть найдены агрегированные описания контента (каталог/метаданные).

3.1.6 описание сеанса загрузки (Download Session Description): Набор параметров, описывающих процесс загрузки элемента контента в сеансе загрузки с использованием CDS DVB-IPTV.

3.1.7 потоковый протокол реального времени; RTSP (Real Time Streaming Protocol, RTSP): Прикладной протокол, предназначенный для использования в системах, работающих с мультимедийными данными.

3.1.8 предложение провайдера служб (SP offering): Набор потоков или служб, предлагаемых провайдером служб для конечного пользователя.

3.1.9 провайдер службы; SP (Service Provider, SP): Объект, предоставляющий службу пользователю.

3.1.10 провайдер службы интернет; ISP (Internet Service Provider; ISP): Сторона, предлагающая пользователю службу доступа в Интернет.

3.1.11 служба DVB-IPTV: Одна или несколько программ, передаваемых по IP, под управлением провайдера службы.

Примечание - Программы могут быть доступны при передаче по расписанию (Live Media Broadcast), по требованию (Content on Demand Services) или для локального хранения - при работе службы загрузки контента (CDS).

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

4 Служба загрузки контента

4.1 Введение

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

В соответствии с ГОСТ Р 54994-2012 (подраздел 10.1) CDS DVB-IPTV должны поддерживать два режима обслуживания:

- режим загрузки push, при котором решение распределения элементов контента принимает SP, без запроса от пользователя;

- режим загрузки pull обеспечивает загрузку элементов контента по запросу пользователя.

Эти режимы обслуживания системы доставки CDS поддерживаются двумя режимами загрузки: multicast и unicast. Для режима загрузки multicast используется протокол однократной передачи файлов FLUTE в соответствии с ГОСТ Р 54994-2012 (подраздел 10.1), который может быть объединен с механизмами восстановления файлов (см. 4.6.2). Режим unicast основан на протоколе HTTP 1.1, который поддерживает загрузку файла с одного сервера и загрузку файла по частям с нескольких серверов. Процедура отчетности приема позволяет HNED сообщать об успешной загрузке контента.

4.2 Функциональная архитектура CDS

4.2.1 Введение

Функциональная архитектура CDS представлена на рисунке 1 эталонной структурой службы загрузки контента. Архитектура включает логические интерфейсы между HNED и другими функциональными компонентами сети CDS. Все интерфейсы CDS являются частью интерфейса IPI-1.

Состав функциональных компонентов CDS представлен в ГОСТ Р 54994-2012 (подраздел 10.2). Настоящий стандарт содержит определения этих функциональных компонентов и интерфейсов.

Стек протоколов, используемых в интерфейсе IPI-1 представлен на рисунке 2.

Рисунок 1 - Эталонная структура службы загрузки контента

Рисунок 2 - Стек протоколов CDS

4.3 Анонсирование службы загрузки контента при использовании BCG

4.3.1 Назначение службы анонсирования CDS

Служба анонсирования CDS предоставляет для HNED информацию согласно ГОСТ Р 54994-2012 (подраздел 10.3) об элементах контента, обеспечивающую возможность загрузки контента в HNED.

В состав данной информации входят:

- информация об элементах контента, предлагаемых сетью CDS;

- информация о функциях сети CDS для режимов push и pull;

- информация о метаданных элементов контента;

- информация о доступности загрузки и описание сеанса загрузки.

Информация анонсирования CDS для HNED предоставляется через интерфейс CDS-1.

Возможности использования ресурсов BCG и TVA для задач загрузки контента в CDS представлены в настоящем пункте.

При использовании URI для поиска расположения описания сеанса загрузки в 4.3.2 представлены детализированные характеристики процедур анонсирования CDS.

Характеристики процедур использования URI для поиска файлов в устройстве хранения HNED представлены в 4.3.3.

Для анонсирования в CDS отдельных элементов контента, при использовании фрагментов метаданных с расширениями, должен применяться BCG на базе TV-Anytime" (TVA).

Для анонсирования элементов контента, доступных в режиме pull загрузки, используется расширенная версия OnDemandProgramType, определенного в приложении А.

Для анонсирования элементов контента, доступных в режиме push загрузки, вводится новый тип PushDownloadType как часть ProgramLocationType, определенного в приложении Б.

Разрешение CRID должно выполняться в соответствии с ГОСТ Р 56476-2015 (раздел 5). Локатором CDS может быть локатор URI (приложение В) или расширенный декомпозированный по требованию двоичный локатор (приложение Г).

URI, специально используемые для CDS в локаторах и ProgramURL, определены в 4.3.2.

Элементы контента, доступные для pull загрузки, анонсируются через BCG так же, как это делается для потоковой передачи элементов контента CoD. Информация о самом элементе контента предоставляется метаданными описания контента согласно ГОСТ Р 56476-2015 (подраздел 6.3), а информация о фактическом сеансе загрузки предоставляется расширенным типом OnDemandProgram экземпляра описания метаданных, и/или локатором URI, или расширенным декомпозированным по требованию двоичным локатором, обеспеченным разрешением CRID.

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

Элементы контента, доступные для службы загрузки в режиме push, анонсируются через метаданные описания экземпляров BCG PushDownloadType (приложение Б); HNED, абонированные на службу загрузки push, самостоятельно загружают эти элементы контента. Экземпляры объекта PushDownloadType не должны анонсироваться пользователю. После успешной загрузки элемент контента может быть анонсирован через метаданные описания экземпляров OnDemandProgramType и/или локатором URI, или расширенным декомпозированным по требованию двоичным локатором, предоставленным разрешением контента, доступного для потребления пользователем с URI, указывающим на элемент контента в устройстве хранения HNED (см. 4.3.2). Метаданные OnDemandProgramType могут предоставляться обычными механизмами BCG или в составе загружаемого контента.

Описание сеанса загрузки контента определяется несколькими параметрами. Эти параметры, предоставляются специальным механизмом описания сеанса загрузки. Описание сеанса загрузки содержит необходимую информацию для загрузки элемента контента. HNED должно поддерживать описания сеансов загрузки в формате XML, допускается поддержка описания сеансов загрузки в формате SDP. Метаданные описания экземпляров BCG и локаторы предоставляют ссылки на описание сеанса загрузки URI, описанные в 4.3.2.

Транспортирование описаний сеансов загрузки может быть unicast или multicast. Методы транспорта описания сеанса загрузки CDS описаны в 4.5.5.

Запись SD&S BCG может предоставить информацию о доставке описания сеанса через multicast рассылку. Это позволяет HNED прослушивать анонсированную multicast доставку и кешировать описания сеанса загрузки. В случае, когда запрашивается конкретное описание сеанса загрузки из multicast доставки, HNED может получить к нему доступ из кеша, не ожидая отправления описания сеанса загрузки в multicast доставке.

4.3.2 Характеристики процедур анонсирования CDS при использовании URI для поиска расположения описания сеанса загрузки

Ссылка на описание сеанса загрузки CDS может быть предоставлена:

- элементом ProgramURL типа PushDownloadType или типом OnDemandProgramType согласно ГОСТ Р 56476-2015 (пункт 6.4.2);

- URI локатора URI или расширенным декомпозированным по требованию двоичным локатором согласно приложению Г.

Методы описания сеанса загрузки XML и SDP и механизмов unicast и multicast транспорта могут использовать четыре различные схемы URI:

- на основе XML при multicast и unicast передаче;

- на основе SDP при multicast и unicast передаче.

Локатор XML CDS multicast определяет расположение контента CDS по ссылке на описание сеанса загрузки через multicast рассылку на базе XML. Multicast доставка описаний сеансов на основе XML через DVBSTP определена ниже. Сегменты XML с описаниями сеансов загрузки передаются в группе multicast рассылки. Для получения доступа к определенному сегменту XML, содержащему по ссылке описание сеанса загрузки, предоставляются информация multicast группы [multicast адрес, порт и (опционально) адрес источника], идентификатор сегмента (SegmentID) и идентификатор (опционально) провайдера служб (ServiceProviderID).

Дополнительно должен быть указан идентификатор сеанса загрузки (Download-Session) в URI описания сеанса загрузки.

HNED должно извлекать конкретное описание сеанса загрузки, на которое ссылается идентификатор Download-Session поставляемого сегмента. Идентификатор Download-Session-ID определяет каждую запись описания сеанса, как определено в 4.5.3.

Для DVBSTP используется URI DVB-MCAST для ссылки на multicast доставку описания сеанса XML. В ID следует указывать поле dvbstpPayloadID и устанавливать значение b1.

Для CDS и элементов контента, определенных локатором multicast рассылки XML CDS, следует использовать следующий формат:

’dvb-mcast: //’[src-host ’@’] mcast-addr [’:’ port] ’?payload = sap’#? dvb-cds-session-id = ’Download-Session-ID].

В следующем примере показан URI, ссылающийся на описание сеанса загрузки на основе XML, доставленного по DVBSTP:

dvb-mcast://[email protected]:1000?payload=sap#?sdp-session-id=12

При использовании локатора XML CDS unicast контент CDS может быть расположен по ссылке на описание сеанса загрузки на базе XML, переданное через unicast рассылку. Unicast доставка описаний сеансов на основе XML с использованием HTTP определена ниже. Описание сеанса загрузки предоставляется в сегменте XML из приложения хоста. URI описания сеанса должен предоставлять хост, порт (опционально), приложение (/dvb/cds/session_description) и идентификатор конкретного сегмента XML.

URI HTTP используется для ссылки на описание сеанса загрузки на базе XML. Если сегмент содержит несколько записей описания сеанса, то дополнительно необходимо предоставлять SessionID. HNED должно извлекать конкретное описание сеанса загрузки, определенное идентификатором Download-Session-ID из доставленного сегмента. Идентификатор Download-Session-ID является частью каждой записи описания сеанса, как определено в 4.5.3.

Для CDS и элементов контента, найденных с помощью unicast локатора CDS XML, используется следующий формат:

’http://’ host [’:’ port] ’/’ path ’/’filename [’#?sdp-session-id=’ Download-Session-ID]

Download-Session-ID = String

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

http://announcements.provider1.org:80/session_announcements/session 14.sdp

Контент CDS может быть расположен по ссылке на описание сеанса загрузки на базе SDP по multicast рассылке. Multicast рассылка описаний сеансов на базе SDP определена ниже. Описания сеансов постоянно отправляются в группу multicast рассылки. Информация о multicast группе [multicast адрес, порт, адрес (опционально) источника] и идентификатор загрузки сеанса (Download-Session-ID) должны быть указаны в URI описания сеанса загрузки для того, чтобы получить доступ к конкретному описанию сеанса SDP. Идентификатор Download-Session-ID является частью каждой записи описания сеанса.

Для CDS и элементов контента, обнаруженных локатором multicast SDP CDS, должен использоваться URI DVB-MCAST для SAP. В поле payload (полезная нагрузка) должно быть установлено sap:

’dvb-mcast://’ [src-host ’@’] mcast-addr [’:’ port] ’?payload=sap’ ’#?sdp-session-id=’ Download-Session-ID

В следующем примере показан URI, ссылающийся на описание сеанса загрузки на основе SDP для multicast доставки:

dvb-mcast://[email protected]:1000?payload=sap#?sdp-session-id=12.

При использовании локатора SDP CDS unicast контент CDS может быть расположен по ссылке на описание сеанса загрузки на базе SDP, доставленное unicast. Фактическая unicast доставка описаний сеанса загрузки на основе SDP определена ниже. Описание сеанса предоставляется в виде файла. Хост, путь к файлу и имя файла должны быть определены для доступа к файлу. Расширение по умолчанию должно быть sdp, допускается использовать другие расширения.

URI HTTP используется для ссылки на файл SDP. Файл SDP содержит единственное описание сеанса. HNED должно принимать только описание сеанса загрузки в поставляемом файле (если идентификаторы Download-Session-ID в ссылке и в записи описания сеанса совпадают). Если они не совпадают, описание сеанса загрузки следует игнорировать.

Для CDS и элементов контента, определенных с помощью unicast локатора CDS SDP, используется следующий формат:

’http://’ host [’:’ port] ’/’ path ’/’ filename [’#?sdp-session-id=’ Download-Session-ID] Download-Session-ID = String

В следующем примере показан URI, ссылающийся на описание сеанса загрузки на основе SDP для unicast доставки:

http://announcements.provider1.org:80/session_announcements/session14.sdp

4.3.3 Характеристики процедур использованиия URI для поиска файлов в устройстве хранения HNED

После успешной загрузки элемента контента HNED может получить доступ к файлам элемента контента в устройстве хранения HNED. Для ссылки на файл в устройстве хранения HNED, по метаданным BCG (например, ProgramURL OnDemandProgramType) и локаторам (например, URI локатора, URI расширенного декомпозированного по требованию двоичного локатора), должна использоваться схема локального URI DVB CDS:

’dvb-cds-local://’File-Reference

File-Reference = absolute path

<absolute-path> как определено в 4.5.2.

Ссылку на файл (File-Reference), которая идентифицирует конкретный файл в устройстве хранения HNED, следует выполнять аналогично ссылке на файл, представленной в описании сеанса загрузки или FDT FLUTE для этого конкретного файла. Сеть CDS должна гарантировать однозначность File-Reference.

Тип контента файла доступен по процедуре загрузки, или из описания сеанса загрузки (File-Content-Type), или из FDT FLUTE, или из сеанса HTTP.

В случае push загрузки метаданные, которые анонсируют загруженный элемент контента пользователю после загрузки, должны использовать локальный URI CDS DVB.

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

4.4 Форматы элементов контента и файлов cлужбы загрузки контента

4.4.1 Введение

Перечень поддерживаемых форматов файлов и связанных с ними типов медиаслужб загрузки контента, а также ссылок на требования к параметрам форматов файлов и типам медиа приведены в ГОСТ Р 54994-2012 (подраздел 10.4).

Детализация условий применения перечисленных элементов форматов контента приведена в 4.4.2, 4.4.3.

4.4.2 Форматы и типы файлов

HNED должно поддерживать прием и возможность использования файлов контента в формате транспортного потока MPEG-2. Файл транспортного потока MPEG-2 состоит из связанных пакетов транспортного потока по 188 байтов.

Должны поддерживаться следующие типы медиа MIME:

- video/mp2t (для видео и комбинированного видео- и аудиоконтента);

- audio/mp2t (только для контента аудио).

HNED должно поддерживать форматы файлов метаданных BCG. Файл XML должен содержать элемент типа tva ProgramInformationType, описывающий связанный контент. Файл XML может быть доставлен в виде некомпрессированного или BiM компрессированного файла текстовой схемы XML. В случае использования BiM компрессии параметр Content-Encoding в заголовке FDT FLUTE и HTTP должен быть установлен в x-bim.

После загрузки элемента контента HNED должно интерпретировать загруженные файлы метаданных BCG как часть обработки BCG.

Тип медиа MIME должен быть application/xml.

CDS может поддерживать файлы в формате файла DVB.

Должны поддерживаться следующие типы медиа MIME:

- video/vnd.dvb.file (для видео и комбинированного видео- и аудиоконтента);

- audio/vnd.dvb.file (для аудиоконтента).

Файлы, соответствующие спецификации формата файла DVB, должны содержать описательные метаданные типа uri.

4.4.3 Форматы элементов контента

Все файлы элемента контента должны быть анонсированы в одном описании сеанса загрузки и загружены в один сеанс загрузки. HNED должно отслеживать эту связь между элементом контента и файлами. Описание сеанса загрузки может анонсировать формат элемента контента в атрибуте Content-Item-Format.

Должны поддерживаться следующие форматы элементов контента:

- Content-Item-Format=0: описание сеанса загрузки любой коллекции файлов. HNED должно интерпретировать Content-Type первого файла в описании сеанса загрузки для использования элемента контента;

- Content-Item-Format=1: описание сеанса загрузки одного транспортного потока MPEG-2 с типом контента должно соответствовать 4.4.2;

- Content-Item-Format=2: Описание сеанса загрузки транспортного потока MPEG-2 должно соответствовать формату в соответствии с 4.4.2 и связанным с ним метаданным BCG. HNED должно интерпретировать метаданные BCG перед выполнением доступа к транспортному потоку MPEG-2;

- Content-Item-Format=3: Описание сеанса загрузки файла в формате файла DVB должно соответствовать 4.4.2.

Если формат контента не определен, должен быть принят формат Content-Item-Format=0.

Примечания

1 При использовании форматов элементов контента Content-Item-Format=0 не допускается перенос служб CDS в других форматах.

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

4.5 Описание сеанса загрузки службы загрузки контента

4.5.1 Введение

В процессе загрузки HNED приобретает каждый элемент контента. Описание сеанса загрузки определяет параметры сеанса, предоставляет информацию о запуске сеанса загрузки и присоединении к сеансу загрузки элементов контента. Загрузка элементов контента происходит при загрузке одного или нескольких файлов.

Приобретение отдельных файлов элемента контента осуществляется по уникальной ссылке каждого файла. Методы поиска по ссылке расположения файлов в описаниях сеансов загрузки CDS приведены в 4.5.2. Параметры сеанса загрузки и его семантика приведены в 4.5.3. Типы сеансов загрузки с назначенными параметрами описаны в 4.5.4. В соответствии с ГОСТ Р 54994-2012 (подраздел 10.5) HNED должно поддерживать следующие типы сеансов загрузки:

- cеанс запланированной multicast загрузки (SMD);

- cеанс multicast загрузки в режиме карусели (CMD);

- сеанс unicast загрузки (UD).

HNED должно поддерживать загрузку описания сеансов, используя синтаксис XML. Допускается поддержка устройством HNED синтаксиса SDP. Оба варианта описания сеансов загрузки поддерживают одинаковые наборы параметров. Синтаксис XML для параметров сеанса загрузки определен в ГОСТ Р 54994-2012 (подраздел 10.5). Синтаксис SDP для сеанса загрузки параметров приведен в ГОСТ Р 54994-2012 (Б.2, приложение Б). Параметры передачи описаний сеансов загрузки определены в 4.5.5.

4.5.2 Поиск по ссылке расположения файлов для загрузки

В описании сеанса загрузки элементов контента предоставляется информация о всех файлах, которые необходимо загрузить для определенного элемента контента. Файлы в элементе контента могут загружаться из разных расположений. Поэтому сеанс загрузки описания для unicast загрузки может содержать альтернативные источники в исходном описании сеанса или в описании переадресации загрузки файла (см. 4.6.3). В случае multicast загрузки файлы должны быть идентифицированы в соответствии с таблицей доставки файлов (FDT), а процедуры восстановления файлов должны выполняться при использовании информации о расположении данных восстановления (см. 4.6.2).

Поиск по ссылке файлов CDS выполняется при использовании схемы URI. Настоящий стандарт устанавливает следующие объекты, необходимые для поиска по ссылке файлов CDS:

- общий URI <URI>;

- компонент синтаксиса схемы <scheme>;

- компонент синтаксиса полномочий <authority>;

- компонент синтаксиса запроса <query>;

- компонент синтаксиса фрагмента <fragment>;

- абсолютный URI <absolute-URI>;

- относительная ссылка <relative-ref>;

- абсолютный путь <path-absolute>.

Примечание - Синтаксис абсолютного пути <path-absolute> является особым случаем синтаксиса относительной ссылки <relative-ref>.

URI базы данных сервера HTTP <http-server-base-URI> является <absolute-URI> с фиксированной схемой "http://" и только с компонентом <authority> (хост, порт). URI не должен содержать компоненты абсолютного пути, запроса или фрагмента синтаксиса.

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

- расположение файла указывается целевым URI, который имеет синтаксис абсолютного URI <absolute-URI>. Компонент синтаксиса фрагмента не должен использоваться. Целевой URI, ссылающийся на расположение файла, не должен использовать компонент синтаксиса запроса;

- HNED может создавать целевой URI, используя разрешение по ссылке. Для создания целевого URI с помощью ссылки разрешения HNED требует:

- базовый URI синтаксиса <http-server-base-URI>;

- относительную ссылку синтаксиса <path-absolute>.

4.5.3 Параметры описания сеанса загрузки

Описание сеансов загрузки содержит параметры, определяющие формат элемента контента. В данном пункте определены общие параметры, параметры unicast загрузки и параметры multicast загрузки, а также методы получения элемента контента. Описана семантика параметров.

Общие параметры сеанса загрузки допускается применять к любому сеансу загрузки.

Service-Provider-Domain: домен SP является доменным именем DNS в Интернете, зарегистрированным SP, которое идентифицирует SP. В описании сеанса загрузки параметр Service-Provider-Domain должен упоминаться только один раз.

Download-Session-ID: идентификатор сеанса загрузки является числовой строкой и идентифицирует конкретное описание сеанса. В описании сеанса загрузки параметр Download-Session-ID должен применяться только один раз.

Download-Session-Version: версия сеанса загрузки определяет версию конкретного описания сеанса. Это целочисленное значение от 0 до 255, которое увеличивается на 1 для каждой новой версии описания сеанса. При переполнении счетчика версий после значения 255 отсчет возобновляется с 0. В описании сеанса загрузки параметр Download-Session-Version должен применяться только один раз.

Content-Item-Format: формат элемента контента. Если формат элемента контента отсутствует, должно быть принято значение Content-Item-Format=0. Подробности о форматах контента представлены в 4.4.3.

Тип сеанса загрузки Download-Session-Mode определяет один из трех режимов сеанса загрузки: SMD, CMD или UD в соответствии с 4.5.4. В описании сеанса загрузки параметр режима Download-Session-Mode должен применяться только один раз.

Download-Session-Time-Information предоставляет информацию при активизированном сеансе загрузки CDS. Допускается присоединение HNED к этому сеансу. В случае unicast и multicast загрузок в режиме карусели должно устанавливаться начальное и конечное время активного окна. В случае абонированной multicast загрузки необходимо определить только время начала сеанса.

Информация об успешном приеме объявленных элементов контента должна передаваться серверам отчета приема в сети CDS. Для выполнения этого требования HNED должно использовать параметры отчета приема.

Для каждого сервера отчета приема должен предоставляться:

- Receive-Reporting-Server-URI: URI HTTP сервера отчетов приема;

- если сеть CDS содержит более одного сервера, то HNED должно произвольно выбирать один из предоставленных серверов. В случае отсутствия параметра отчета для этого сеанса загрузки отчет приема не поддерживается.

Если предоставляется более одного сервера отчетов приема, могут быть предоставлены следующие параметры отчетов приема:

- Reception-Reporting-Mode: определяет уровень детализации, предоставляемый отчетами о приеме;

- Receiving-Reporting-Mode=0: отчет об элементе контента;

- Receive-Reporting-Mode=1: отчеты об элементе контента и файле;

- Receive-Reporting-Mode=2: отчеты об элементе контента, файле и фрагменте.

В отсутствие параметра Reception-Reporting-Mode HNED должно устанавливать Reception-Reporting-Mode=0. При multicast загрузке уровень детализации Reception-Reporting-Mode=2 не используется.

Reception-Reporting-Offset-Time: параметр определяет время смещения отправления отчета о приеме (см. 4.6.5). Это целочисленное значение, выраженное в секундах. В отсутствие параметра HNED должно принимать Reception-Reporting-Offset-Time=0.

Reception-Reporting-Random-Time-Period: параметр определяет величину произвольного интервала времени отправления отчета о приеме (см.4.6.5). Это целочисленное значение, выраженное в секундах. В отсутствие параметра HNED должно принимать Reception-Reporting-Random-Time-Period=0.

Параметры, относящиеся к сеансам unicast загрузки:

File-Reference: ссылка на файл. Синтаксис этой ссылки должен соответствовать синтаксису <path-absolute>;

File-Content-Type: определен в 4.4.2 с ссылкой на зарегистрированный тип MIME;

File-Length: длина файла для поля заголовка объекта Content-Length.

File-Digest: Base64 из 128-битового MD5 дайджеста файла для поля заголовка объекта Content-MD5 (см. приложение Д).

В случае загрузки файла в отдельных фрагментах необходимо загружать Chunk-Length: длина фрагмента файла. Файл делится на фрагменты постоянной длины (последний фрагмент может быть укорочен).

Для каждого фрагмента (фрагменты нумеруются от 1 до n в порядке их составления) необходимо загружать Chunk-Digest: Base64 из 128-битового MD5 дайджеста фрагмента для поля заголовка объекта Content-MD5 (см. приложение Д).

Для каждого сервера, доступного для скачивания файла, необходимо загружать Server-Base-URI: базовый URI расположения файла. Синтаксис ссылки Server-Base-URI должен соответствовать синтаксису <http-server-base-URI> (см. 4.5.2).

В случае загрузки файла в виде отдельных фрагментов необходимо загружать Available-Chunk-List: список всех фрагментов файла, доступных на этом сервере (фрагменты нумеруются от 1 до n в порядке их составления). Если список не предоставлен, то на сервере должен быть доступен весь файл.

Грамматика параметра Available-Chunks-List должна использовать условные обозначения, представленные ниже:

chunks-list = 1#single-chunk-num | chunk-range-spec

single-chunk-num = 1*DIGIT

chunk-range-spec = first-chunk-num "-" last-chunk-num

first-chunk-num = 1*DIGIT

last-chunk-num = 1*DIGIT

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

К сеансам multicast загрузок относятся нижеприведенные параметры.

Для каждого загружаемого файла File-Reference приводится ссылка на загружаемый файл. Синтаксис этой ссылки должен соответствовать синтаксису <path-absolute>. В отсутствие параметра HNED загружает все файлы, переносимые сеансом FLUTE. Если формат элемента имеет значение Content-Item-Format=0 и содержит более одного файла, это поле является обязательным.

Для присоединения к сеансу multicast загрузки FLUTE используются следующие параметры:

- IP-Source-Address: IP-адрес источника multicast группы сеанса FLUTE. Сеанс загрузки multicast файла должен иметь один IP-адрес источника;

- Transport-Session-Identifier: идентификатор транспортного сеанса (TSI). TSI вместе с IPSource-Address однозначно идентифицирует сеанс FLUTE для заданного адреса IP источника во время активного сеанса, а также до и после сеанса. Допускается одно вхождение этого параметра в описание сеанса FLUTE. Значение TSI должно быть целочисленным;

- FEC-Encoding-ID описывает схему FEC. Поддерживаются две схемы:

- FEC-Encoding-ID=0: компактная схема FEC без кода;

- FEC-Encoding-ID=1: схема FEC Raptor.

Если идентификатор FEC-Encoding-ID не указан, то функция HNED должна принимать FEC-Encoding-ID=0.

Примечание - Информация о передаче объекта FEC (Object Transmission Information, OTI) должна быть доставлена с использованием заголовка расширения ALC/LCT EXT_FTI или FDT.

Атрибут Number-Of-Channels указывает количество FLUTE/LCT каналов сеанса FLUTE.

Параметр атрибута Number-Of-Channels сообщает приемнику, что отправитель для передачи данных использует несколько каналов в сеансе FLUTE и сообщает количество каналов, используемых отправителем. В отсутствие этого параметра HNED должно считать, что для сеанса multicast загрузки используется один канал FLUTE.

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

- IP-Multicast-Address, IP multicast адрес для каждого канала FLUTE;

- IP-Multicast-Port-Number, номер порта для каждого канала FLUTE;

- Max-Bandwidth, максимальная пропускная способность каждого канала FLUTE. При отсутствии этого параметра максимальный предел пропускной способности не устанавливается.

Порядок перечисления каналов FLUTE в описании сеанса загрузки соответствует очередности, с которой HNED должно присоединяться к каналам и покидать каналы.

Для участия в опросе завершения в запланированном сеансе multicast загрузки HNED должно использовать следующие параметры:

- Completion-Poll-Response-Server-Address, IP-адрес, по которому HNED отправит ответы на опрос завершения;

- Completion-Poll-Response-Server-Port-Number, номер порта для ответов на опрос завершения.

При отсутствии этих параметров опрос завершения не применяется для этого сеанса загрузки.

Если поддерживается механизм восстановления файлов для multicast загрузки, то HNED должно использовать следующие параметры, связанные с механизмом восстановления файлов:

- для каждого сервера восстановления файлов Recovery-Server-Base-URI;

- базовый URI сервера восстановления файлов unicast. Синтаксис этой ссылки должен соответствовать синтаксису <http-server-base-URI> (см. 4.5.2).

Для Recovery-Server-Base-URI могут быть предоставлены следующие параметры:

- Recovery-Mode описывает процедуры восстановления файла, которые должны применяться;

- Recovery-Mode=0, процедура восстановления файла CDS;

- Recovery-Mode=1, процедура восстановления файла, подобная IPDC (в отсутствие параметра Recovery-Mode HNED должен принимать Recovery-Mode=0);

- Recovery-Offset-Time, параметр определяет время смещения восстановления файла (см. 4.6.2). Это целочисленное значение, выраженное в секундах. При отсутствии этого параметра HNED должно принимать Recovery-Offset-Time=0;

- Recovery-Random-Time-Period, параметр определяет время восстановления резервной копии файла числом без знака в секундах. В отсутствие этого параметра HNED должно принимать значение Recovery-Random-Time-Period=0.

4.5.4 Режимы сеанса загрузки

CDS работает в следующих режимах сеансов:

- запланированной multicast загрузки (SMD);

- multicast загрузки в режиме карусели (CMD);

- unicast загрузки (UD) от одиночного сервера (SS);

- unicast загрузки (UD) от нескольких серверов (MS).

Описание сеансов загрузки использует параметры из списка параметров сеанса загрузки в 4.5.3. В таблице 1 представлены параметры сеанса загрузки:

- символ M обозначает обязательные параметры, которые должны быть включены сетью CDS в описание сеанса загрузки;

- символ O обозначает опциональные параметры;

- символ N относится к случаю, когда параметр не должен быть включен для этого режима сеанса загрузки. В таблице 1 указан тип каждого параметра.

Таблица 1 - Параметры сеансов загрузки

4.5.5 Транспорт описаний сеансов загрузки

Описания сеанса загрузки на основе XML и SDP предоставляются для HNED при использовании unicast или multicast передачи через интерфейс CDS-1.

Для multicast транспорта описаний сеансов XML протокол DVBSTP используется со следующими профилями CDS:

- в поле идентификатора полезной нагрузки должно быть установлено 0xB1;

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

Передача фрагментов XML CDS в группе multicast выполняется в режиме карусели.

Если сегмент содержит более одной записи описания сеанса, то опциональный идентификатор Download-Session-ID фрагмента в ссылке URI идентифицирует конкретную запись описания сеанса.

Если для распространения информации описания сеанса загрузки используется multicast рассылка, записи XML допускается сегментировать.

Каждый сегмент должен содержать целое число элементов сеанса загрузки, сегмент не должен содержать часть элемента сеанса загрузки. Каждый сегмент должен быть действительным и хорошо сформированным.

Группу multicast передачи могут использовать несколько провайдеров служб. В этом случае опциональное поле ServiceProviderID заголовка DVBSTP используется для идентификации SP.

Параметры unicast передачи описаний сеансов XML идентичны параметрам unicast передачи SD&S. Протокол HTTP должен использоваться для связи между серверами HNED и сервером описания сеансов CDS. Запрос описания сеанса должен выполняться для доставки конкретной записи описания сеанса.

Примечание - Если возвращенный сегмент содержит более одной записи описания сеанса, идентификатор фрагмента идентификатора загрузки сеанса (Download-Session-ID) идентифицирует (опционально) конкретную запись описания сеанса. Пользуясь Download-Session-ID, HNED извлекает конкретную запись описания сеанса.

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

HNED может кешировать сегменты. В случае запроса описания сеанса загрузки из того же сегмента, HNED может предоставить версию кешированного сегмента, указанного в запросе к записи XML. Ответ на запрос возвращает запись обнаружения службы для указанного сегмента только в том случае, если доступна более новая версия. Если версия сегмента не изменилась, то сервер должен ответить кодом состояния 204, указывая, что запрос был успешно обработан, но что объект для возврата отсутствует.

Если версия сегмента не указана, ответ на запрос возвращает фактическую версию указанного сегмента. Если запись не найдена, сервер должен вернуть код состояния 404, означающий, что запись не обнаружена.

Запрос описания сеанса загрузки должен соответствовать следующему формату:

’GET /dvb/cds/session_description’ ’?Segment=’ SegmentItem ’HTTP/1.1’ CRLF ’Host: ’ host [’:’ port] CRLF.

Параметр SegmentItem содержит опциональное поле для номера версии.

SegmentItem = SegmentId 0*1(’&Version=’VersionNumber) SegmentId = 4*4 HEXDIG; any hex number from 0x0000 to 0xffff VersionNumber = OCTET; any hex number from 0x00 to 0xff.

Примечание - Идентификатор полезной нагрузки, определенный для запроса обнаружения службы, не предоставляется, так как тип запроса /dvb/cds/session_description уже указывает, что запрашивается информация описания сеанса.

В multicast передаче описаний сеансов загрузки на базе SDP используется протокол SAP со следующим специфическим для CDS профилем:

- тип полезной нагрузки - application/sdp;

- полезную нагрузку допускается компрессировать с помощью Zlib;

- аутентификация не поддерживается.

Описание сеансов SDP передается по multicast каналу в режиме карусели. Если канал multicast передачи был анонсирован HNED ранее в записи BCG, то HNED может постоянно прослушивать multicast канал и кешировать последние версии описаний сеансов. HNED может в этом случае получить доступ к соответствующему описанию сеанса из кеша без необходимости ожидания передачи сегмента в multicast канале.

HNED запрашивает файл SDP от сервера описания сеанса CDS. Файл должен содержать одно описание сеанса SDP. Тип контента для файла SDP должен быть application/sdp. Файл поставляется некомпрессированным.

4.6 Загрузка элементов контента CDS

4.6.1 Введение

Загрузка элементов контента выполняется CDS для их распределения одному или нескольким HNED в режиме реального времени.

Элемент контента состоит из файлов. Файлы могут содержать видео, аудио, комбинированные видео и аудио и связанные с ними файлы метаданных, как определено в ГОСТ Р 54994-2012 (подраздел 10.6). CDS поддерживает загрузку всех файлов, связанных с элементом контента, являющихся частью одного сеанса загрузки. В рамках сеанса CDS файлы доставляются через unicast или multicast загрузки. Сеанс CDS анонсируется unicast или мulticast загрузкой. Однако при восстановлении unicast файла или переадресации сеанса unicast для мulticast загрузки сеанса режим загрузки может измениться во время сеанса.

В соответствии с ГОСТ Р 54994-2012 (подраздел 10.6) HNED должно поддерживать следующие обязательные функции:

- загрузки мulticast контента (4.6.2);

- загрузки unicast контента (4.6.3);

- процедуры отчетов приема (4.6.5).

В соответствии с 4.5 до начала загрузки элемента контента HNED должно получить доступ к описанию сеанса загрузки.

HNED завершает загрузку элемента контента только при полной загрузке всех файлов элемента доступного контента.

В режимах загрузки сеанса (Download-Session-Mode) SMD или CMD, CDS и HNED должны следовать процедурам загрузки multicast контента, приведенным в 4.6.2.

В режиме unicast загрузки сеанса (Download-Session-Mode) CDS и HNED должны применять процедуры загрузки unicast контента, описанные в 4.6.3.

В 4.6.4 приведены рекомендации по параллельной загрузке элементов контента с одного или нескольких серверов.

Если описание сеанса загрузки содержит один "Reception-Reporting-Server-URI", то CDS и HNED должны применять процедуры отчета приема, как указано в 4.6.5.

4.6.2 Загрузка контента в Multicast режимах

Мulticast режимы обеспечивают загрузку элементов контента нескольким HNED с использованием IP. Доступность элементов контента при multicast загрузке рекламы анонсируется в описании сеанса загрузки.

Multicast загрузка выполняется в сеансах. Сеанс загрузки является экземпляром CDS, содержащим адреса потоков IP. Время начала и окончания сеанса содержится в параметре Download-Session-Time-Information.

Описание сеанса загрузки предусматривает загрузку только одного элемента контента. Сеанс мulticast загрузки может включать файлы нескольких элементов контента. В этом случае описание сеанса загрузки определенного элемента контента устанавливает состав загружаемых файлов этого элемента контента. При отсутствии такого описания должны быть загружены все файлы из элемента контента.

Параметр Download-Session-Mode при multicast запланированной загрузке описывает сеансы SMD и CMD (в режиме карусели).

В режиме SMD сеть устанавливает начало сеанса. HNED могут принимать участие в сеансе в назначенное время. Сеть CDS в режиме SMD должна выполнять опрос завершения сеанса.

В случае CMD HNED могут присоединяться к сеансу и выходить из сеанса в любое время. Сеть CDS не должна выполнять опрос завершения сеанса в режиме CMD.

Распределение файлов сервер multicast сети CDS выполняет при использовании протокола FLUTE. Информация об использовании FLUTE в CDS указана в данном разделе. HNED присоединяется во время сеанса к одной или нескольким группам multicast передачи IP. Для multicast канала используется протокол IGMPv3 (для протокола IPv4) или протокол MLD версии 2 (для протокола IPv6). Процедуры объединения IP multicast групп указаны в данном разделе.

Для сеансов режима SMD провайдер служб должен продолжать сеанс до тех пор, пока все приемники, присоединившиеся к группе, не получат загружаемые элементы контента. Как указано в данном разделе, длительность сеанса определяется по результатам опроса завершения.

HNED в CDS должно присоединяться к сеансу multicast рассылки в предусмотренное время. Если к сеансу SMD HNED присоединилось после назначенного времени, а система CDS завершает сеанс, HNED не должно отвечать на запросы о завершении функций сети CDS.

Если HNED не завершило загрузку элемента контента во время активного сеанса multicast рассылки, CDS должен предоставить ему механизмы восстановления файлов. Эти механизмы описаны в данном разделе.

Протокол передачи файлов при однонаправленной передаче FLUTE должен использоваться CDS для multicast доставки. В дополнение к базовому протоколу FLUTE при multicast доставке CDS включает элементы, расширяющие FLUTE. В настоящем стандарте термин файл используется для всех объектов, переносимых FLUTE (за исключением экземпляров FDT).

FLUTE реализуется поверх экземпляра протокола асинхронного многоуровневого кодирования (Asynchronous Layered Coding, ALC). ALC объединяет структурный блок многоуровневого транспорта (Layered Coding Transport, LCT), блок блокировки перегрузок (Congestion Controlled, СС) и блок исправления прямых ошибок (Forward Error Correction, FEC) для обеспечения асинхронной доставки контента неограниченному количеству приемников от единственного отправителя. На рисунке 3 показана структура стека протокола FLUTE.

FLUTE переносится через UDP/IP и не зависит от версии IP и используемых базовых канальных уровней.

ALC использует блок LCT для обеспечения "внутриполосного" управления сеансом. Блок LCT содержит специфицированные и субспецифицированные поля, которые наследуются и специфицируются ALC. Блок FEC позволяет выбрать соответствующий код FEC для использования в ALC, включая код FEC без защитного кодирования.

Рисунок 3 - Структура стека протокола FLUTE

ALC переносит двоичные объекты с конечной или с неопределенной длиной. FLUTE является полностью определенным протоколом для транспорта файлов (любых дискретных двоичных объектов) и использует объекты специального назначения - экземпляры таблицы FDT. Целью использования экземпляров таблицы FDT является индексирование файлов и их основных параметров приема в сеансе FLUTE.

HNED и сеть CDS должны использовать все обязательные части спецификации FLUTE, а также функции ALC, которые следуют из FLUTE.

Сегментация файлов позволяет применять:

- алгоритм блокирования, который вычисляет исходные блоки от исходных файлов;

- алгоритм кодирования символа, который вычисляет символы кодирования от исходных блоков.

О применяемых алгоритмах кодирования символов сообщается в параметре сеанса загрузки FEC-Encoding-ID:

- поддерживается компактная схема FEC без кода (FEC-Encoding-ID=0, Null-FEC);

- поддерживается схема FCR Raptor (FEC-Encoding-ID=1), состоящая из двух частей:

- компоновка и прием исходного блока и исходного пакета;

- восстановление компоновки, прием пакетов, кодирование и декодирование Raptor FEC.

HNED должно поддерживать компоновку исходного блока, прием исходного блока и исходного пакета для схемы FCR Raptor. HNED должно поддерживать ID полезной нагрузки FEC, информацию об объекте передачи FEC и об источнике пакетов.

Передача файлов (или отдельных кодированнных символов файла) по нескольким каналам FLUTE для сеанса FLUTE должна поддерживаться HNED и сетью CDS.

Количество каналов FLUTE сообщается в параметре Number-of-Channels.

HNED должно поддерживать в одном сеансе FLUTE прием не менее 16 каналов FLUTE.

При поддержке компактной схемы FEC без кода FEC-Encoding-ID=0 должен использоваться алгоритм для вычисления исходной структуры блока, описанный в спецификации FLUTE.

При поддержке схемы FEC Raptor (FEC-Encoding-ID=1) (см. ГОСТ Р 55713) должен использоваться алгоритм построения блока источника.

Для управления перегрузкой допускается использовать адаптацию multicast передачи, описанную в данном разделе.

Файлы для передачи могут кодироваться при использовании алгоритма GZip.

Терминалы должны поддерживать декодирование контента файлов FLUTE, кодированных по алгоритму GZip. Для файлов с кодировкой GZip атрибуту элемента файла FDT Content-Encoding присваивается значение gzip.

Сигнализация параметров с базовыми заголовками ALC/FLUTE должна быть расширена следующими специализациями:

- в FLUTE длина идентификатора управления перегрузкой (Congestion Control Information, CCI) должна быть 32 бита, для заголовка LCT устанавливается значение флага C=0;

- поле идентификатора сеанса передачи (Transmission Session Identifier, TSI) должно иметь длину 16 или 32 бита (в зависимости от значений флагов Н и S, установленных в заголовке LCT) при значении длины TOI 32 бита;

- поле идентификатора транспортного объекта (Transport Object Identifier, TOI) должно иметь длину 16 или 32 бита (в зависимости от значений флагов Н и О, установленных в заголовке LCT);

- для экземпляров FDT должен использоваться только идентификаторв TOI.

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

- флаг А закрытия сеанса - указывает об окончании сеанса;

- флаг В закрытия объекта - указывает об окончании жизни объекта.

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

- длина заголовка LCT (HDR_LEN) должна быть установлена в единицах 32-битовых слов;

- для компактной схемы FEC без кода (FEC-Encoding-ID=0) идентификатор полезной нагрузки должен содержать 16-битовый номер исходного блока (Source Block Number, SBN) и следующий за ним 16-битовый идентификатор символа кодирования (Encoding Symbol ID, ESI).

При сигнализации параметров с заголовками расширения поля FLUTE с заголовками расширения EXT_FDT, EXT_CENC должны использоваться следующим образом:

- EXT_FTI должен быть включен в каждый пакет FLUTE, содержащий символы, принадлежащие любому экземпляру FDT;

- контент экземпляров FDT не должен кодироваться, если не используется EXT_CENC.

FLUTE используется при следующих условиях:

- EXT_FDT должен находиться в каждом пакете FLUTE, переносящем символы, принадлежащие любому экземпляру FDT;

- пакеты FLUTE, содержащие символы файлов, не должны содержать EXT_FDT.

Условия использования EXT_FTI (опционально) для пакетов, содержащих символы файлов, должны соответствовать FLUTE для сигнализации передачи информации об объекте FEC, связанной со схемой кодирования FEC без кода (FEC-Encoding-ID=0).

При использовании кода Raptor (FEC-Encoding-ID=1) следует использовать формат EXT_FTI.

Для сигнализации параметров используется схема экземпляра FDT FLUTE, определенная в данном разделе. Некоторые элементы данных могут быть включены в экземпляр FDT (FDT-Instance) или в файлы. Значения элементов данных в элементе файла переопределяют их в элементе FDT-Instance.

На уровне экземпляра FDT и всех файлов сеанса FLUTE применяются следующие правила:

- Content-Location (URI файла).

Примечание - Применяют absolute path syntax <path - absolute>, как установлено в 4.5.2. Информация о сервере не должна включаться;

- TOI;

- срок действия (данные окончания срока действия для экземпляра FDT).

Следует включать следующие элементы экземпляра FDT:

- Content-Length (длина исходного файла в байтах);

- Content-Type (тип контента MIME). Этот атрибут должен размещаться либо в элементе FDT или в элементе файла, либо в обоих.

Включение перечисленных элементов данных экземпляра FDT является опциональным и зависит от схемы FEC:

- FEC-OTI-Maximum-Source-Block-Length;

- FEC-OTI-Encoding-Symbol-Length;

- FEC-OTI-Max-Number-of-Encoding-Symbols;

- FEC-OTI-Scheme-Specific-Info.

Элементы данных экземпляра FDT (опционально) могут включаться для FLUTE в CDS:

- Complete (сигнализация о том, что экземпляр FDT предоставляет полный, не изменяемый набор следующих параметров файла для сеанса FLUTE);

- FEC-OTI-FEC-Encoding-ID (значение по умолчанию - FEC Encoding ID 0);

- FEC-OTI-FEC-Instance-ID;

- Content_Encoding;

- Transfer_length;

- Content-MD5 (контрольная сумма файла).

В таблице 2 представлена структура доставки FDT.

Адаптация cкорости multicast передачи поддерживается загрузкой сеанса FLUTE несколькими каналами FLUTE. Все каналы передаются через разные группы multicast передачи.

Для адаптации multicast передачи multicast загрузка сети CDS должна использовать несколько каналов FLUTE в сочетании со схемой FEC Raptor. Количество каналов FLUTE рекламируется в описании сеанса загрузки в параметре Number-Of-Channels.

Таблица 2 - Структура доставки FDT

Каждый канал FLUTE транспортируется через выделенную multicast группу, идентифицированную уникальным IP multicast адресом. В дополнение к поддержке адаптации multicast скорости сеть CDS должна сигнализировать параметр Max-Bandwidth для каждого канала. Сеть CDS не должна допускать превышения максимальной пропускной способности, анонсируемой параметром Max-Bandwidth для каждой multicast группы.

Распределение исходных пакетов, а также пакетов FEC по разным группам multicast рассылки может выполняться сетью CDS. Эта функция настоящим стандартом не нормируется.

В случае, если FEC Raptor поддерживается всеми функциями HNED, сеть CDS должна обеспечивать равномерное распределение пакетов FLUTE/UDP в multicast группах в соответствии со скоростью передачи данных для каждой группы.

Выделение пропускной способности для групп multicast передачи может выполняться в различных режимах сетью CDS. Эта функция настоящим стандартом не нормируется.

При получении описания сеанса загрузки в конкретном сеансе HNED имеет доступ к группам multicast рассылки, которые определены параметром Number-of-Channels. Для доступа к группам multicast рассылки должны использоваться следующие параметры:

- идентификатор multicast группы, адрес IP источника (IP-Source-Address), IP multicast адрес (IP-Multicast-Address) и IР-multicast номер порта (IP-Multicast-Port-Number);

- максимальная пропускная способность (Max-Bandwidth);

- порядковый номер multicast группы присваивается в соответствии с описанием сеанса загрузки.

HNED входят в сеанс, присоединяяcь к группам multicast передачи. Присоединение HNED к группам multicast передачи должно выполняться так, чтобы результирующая скорость передачи не превышала скорости, доступной HNED. HNED определяет текущую доступную скорость передачи, измеряя скорость входящих данных абонированных групп multicast передачи. Если она меньше значения скорости, анонсированной при подписке на multicast группы, измеренная скорость считается соответствующей доступной скоростью передачи (на этот момент времени).

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

- абонированная скорость передачи CDS равна сумме скоростей передачи абонированных multicast групп, как указано в параметре загрузки Max-Bandwidth;

- наблюдаемая скорость передачи CDS соответствует общей наблюдаемой скорости передачи входящих данных CDS в произвольный момент времени. Интервал времени, на котором измеряется наблюдаемая скорость передачи, и точный алгоритм измерения определяются реализацией. Продолжительность времени измерения должна быть меньше периода изменения состава multicast группы и должна быть более одной десятой этого времени.

HNED должно постоянно корректировать количество членов в multicast группе, обеспечивая соответствие наблюдаемой пропускной способности CDS значению абонированной пропускной способности CDS. Абонированная CDS пропускная способность ограничена скоростью передачи анонсированных групп multicast передачи. HNED не должно корректировать количество членов в multicast группе CDS более одного раза за каждые 30 с.

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

Файлы, которые HNED загружает из FLUTE, приведены в описании сеанса загрузки (параметры File-Reference). Если параметр File-Reference отсутствует, то должны загружаться все файлы FLUTE.

Идентификация файлов FLUTE выполняется в URI по Content-Location в FDT Flute по параметрам File-Reference.

Для идентификации файлов FLUTE HNED сравнивает параметры File-Reference с URI Content-Location в FDT Flute.

Если в устройстве хранения уже существует файл <path-absolute> с длиной контента и дайджестом MD5 (такими же, как и у файла в FDT FLUTE), то файл не должен загружаться. В случае неидентичности файлов файл в устройстве хранения HNED должен быть удален и должна быть загружена новая версия файла.

При запросе описания сеанса загрузки после успешной загрузки всех файлов элемента контента HNED должно отправить отчет приема.

Сеть CDS должна использовать механизм опроса завершения для определения времени окончания сеанса multicast загрузки на сервере multicast файлов.

HNED, получив распространяемые файлы полностью, должно покинуть абонированные группы multicast рассылки и выйти из этого сеанса загрузки.

Приемники завершают прием в разное время из-за различной скорости передачи и разных уровней потерь пакетов. Для проверки завершения приема функция загрузки multicast информации CDS периодически отправляет сообщение Completion Poll (опрос завершения) в сеансе FLUTE. Сообщение Completion Poll содержит 32-битовое поле POLL_MASK, при получении которого HNED передает псевдослучайное 32-битовое число в поле POLL_MASK_X. В качестве такого числа допускается использовать четыре младших значащих байта MAC-адреса HNED.

Для защиты сервера от перегрузки этими сообщениями HNED, при получении поля POLL_MASK в сообщении Completion Poll, определяет необходимость формирования ответа. С получением запроса Completion Poll HNED вычисляет логическое И "своего" внутреннего значения POLL_MASK_X и значения POLL_MASK, предоставляемого сервером. Если результат вычисления равен нулю, HNED отвечает на сообщение Completion Poll, отправив сообщение ответа.

В запросе Completion Poll используется простой базовый протокол UDP. Протокол содержит:

- номер сообщения запроса, к которому относится сообщение;

- адрес источника и TSI сеанса FLUTE;

- маску опроса HNED;

- оценку времени, необходимого HNED для получения файла или файлов.

Запрос Completion Poll выполняется как расширение заголовка LCT. Расширение заголовка Poll LCT должно быть включено в нормальный пакет FLUTE, связанный с транспортным объектом с применением обычных правил для настроек заголовка LCT.

Формат расширенного заголовка LCT запроса завершения опроса приведен на рисунке 4.

Рисунок 4 - Формат расширенного заголовка LCT запроса Completion Poll

Header Extension Type (HET), 8 бит, поле идентифицирует тип расширения заголовка запроса Completion Poll. В поле должно быть установлено значение, равное 65.

Header Extension Length (HEL), 8 бит, поле содержит длину расширенного заголовка в единицах 32-битовых слов.

Version, 4 бита, версия протокола. В этой версии протокола в поле должен быть установлен 0.

POLL_SEQUENCE, 12 бит, содержит порядковый номер запроса Completion Poll.

POLL_MASK, 32 бита, значение, выбранное сетью CDS для поддержки фильтрации ответов опроса.

Ответ на запрос Completion Poll отправляется через UDP по адресу, указанному в параметре Completion-Poll-Response-Server-Address, на порт Completion-Poll-Response-Server-Port-Number. Формат ответа на запрос Completion Poll приведен на рисунке 5.

Рисунок 5 - Формат ответа на запрос Completion Poll

Version, поле "Версия", 4 бита. В этой версии протокола должно быть установлено значение "0".

S (Transport Session Identifier flag), поле флага идентификатора сеанса транспорта 1 бит, определяется с учетом поля флага Н в количестве 32-битовых слов. Поле TSI имеет длину 32хS+16хH, т.е. длина поля может быть равна 0, 16, 32 или 48 бит.

H (Half-word flag), поле флаг полуслов, 1 бит, определяет длину поля TSI, кратного 32 битам +16хH бит.

Reserved, поле "Зарезервировано", 10 бит, в этой версии протокола должно быть установлено значение 0. Приемник должен игнорировать это поле.

POLL_SEQUENCE, 12 бит, значение этого поля должно быть установлено в поле POLL_SEQUENCE в запросе Completion Poll, которое вызвало этот ответ.

SOURCE_ADDRESS, 32 бита, этот параметр должен быть установлен в адрес источника IPv4 сеанса FLUTE, как указано в описании сеанса загрузки.

TSI (Transport Session Identifier) (0, 32, 64 бита) является идентификатором сеанса транспорта, длина поля зависит от значений флагов S и H:

- 0 бит, если S=H=0;

- 32 бита, если S=1 и H=0 или S=H=0;

- 64 бита, если S=H=1.

POLL_MASK_X, 32 бита, значение этого поля должно быть записано в поле POLL_MASK_X, используемом клиентом при обработке запроса Completion Poll.

Predicted remaining duration (прогнозируемое остающееся время), 32 бита, поле содержит прогноз оценки времени в секундах, необходимого приемнику для завершения приема файла. Если оценка не может быть сделана, то в поле устанавливается 0. Технология оценки прогноза времени настоящим стандартом не нормируется.

В режиме сеанса SMD (Download-Session-Mode=SMD) сеть CDS, для контроля завершения приема, должна выполнить опрос завершения.

Сеть CDS должна инициировать результаты опроса завершения, предоставляя ответы сервера на опросы завершения (Completion-Poll-Response-Server-Address и Completion-Poll-Response-Server-Port-Number) в описании сеанса загрузки.

Процедура обработки запроса Completion-Poll, инициируемая сетью CDS, содержит сообщение Completion Poll Request (запрос опроса завершения), передаваемое на HNED в пакетах multicast передачи базового канала FLUTE. Для нескольких групп multicast рассылки запрос опроса завершения должен быть включен только в базовый канал FLUTE.

Сеть CDS в поле POLL_SEQUENCE устанавливает значение, равное количеству выполненных процедур Completion-Pol на интервале сеанса. Для первой процедуры запроса на завершение опроса в поле POLL_SEQUENCE должно быть установлено значение 0. Это значение должно увеличиваться на единицу для каждого нового завершения процедуры запроса Completion-Poll.

Сеть CDS должна устанавливать в поле POLL_MASK значение, учитывающее количество активных приемников и количество целевых ответов. Настоящий стандарт не устанавливает правил формирования этого значения.

В начальной стадии сеть CDS должна устанавливать значение POLL_MASK, обеспечивающее необходимую многократность передачи запроса Completion-Poll. Процесс запроса Completion-Poll повторяется до получения ответа от всех HNED, после чего сеанс заканчивается. Настоящий стандарт не устанавливает правил определения необходимой многократности передачи запроса Completion-Poll.

Запрос на Completion-Poll должен быть включен в пакеты Nrepeat в каждой группе multicast передачи. Значения POLL_SEQUENCE и POLL_MASK должны быть одинаковыми в каждом сообщении. Рекомендуемое значение Nrepeat - 20.

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

Если поля не отличаются, сеть CDS должна вычислить логическое И принятого значения POLL_MASK_X и POLL_MASK последнего отправленного сообщения запроса на опрос завершения. Если полученный результат отличается от нуля, сервер должен отменить полученное сообщение.

Сеть CDS использует поле "Прогнозируемое остающееся время" для определения оставшейся продолжительности сеанса. Нормирование правил использования поля "Прогнозируемое остающееся время" выходит за рамки настоящего стандарта.

HNED определяет окончание процесса доставки файлов в соответствии с нормами, предусмотренными в 4.6.2.

Если HNED получило все файлы, определяемые описанием сеанса загрузки, это означает, что сеанс загрузки HNED завершен и оно должно выйти из анонсированной multicast группы и HNED больше не будет получать сообщения запроса опроса завершения.

Если информация сервера ответа на Completion-Poll (Completion-Poll-Response-Server-Address и Completion-Poll-Response-Server-Port-Number) предоставляется в режиме сеанса запланированной загрузки (Download-Session-Mode=SMD) и HNED участвует в этом сеансе загрузки, то устройство HNED должно ожидать получения сообщений запроса Completion-Poll в первой присоединенной multicast группе.

При получении сообщения запроса Completion-Poll HNED проверяет полученное значение POLL_ MASK. Каждый HNED в поле POLL_MASK_X содержит псевдослучайное 32-битовое число. HNED вычисляет логический И принятого POLL_MASK и собственного POLL_MASK_X. Если вычисленное значение не равно нулю, запрос опроса завершения должен быть отброшен.

Если вычисленное значение логического И равно нулю, HNED должно создать сообщение ответа на опрос завершения и отправить его по адресу, указанному в параметре Completion-Poll-Response-Server-Address описания сеанса загрузки и на порт назначения UDP, указанный в параметре Completion-Poll-Response-Server-Port-Number описания сеанса загрузки.

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

HNED, совместимое с этой версией протокола, должно игнорировать поле Version запроса на опрос завершения и игнорировать любые дополнительные данные после поля POLL_MASK.

Процедура восстановления файлов выполняется при неполном завершении сеанса multicast рассылки.

Неполное завершение сеанса multicast рассылки может происходить по нескольким причинам, в том числе:

- HNED было принудительно отключено от сеанса рассылки;

- HNED присоединилось к запланированному сеансу позже назначенного времени начала сеанса.

Сеть CDS сообщает HNED о процедуре восстановления файла для этого сеанса, предоставляя базовый URI (см. 4.5.2) одного или нескольких серверов восстановления в описании сеанса загрузки (параметр Recovery-Server-Base-URI).

Флаг режима восстановления (Recovery-mode) в описании сеанса загрузки сообщает HNED о типах применяемых процедур восстановления файлов:

- процедура восстановления файла типа IPDC;

- конкретная процедура восстановления файла CDS.

HNED должно инициировать процедуру восстановления файла только в том случае, если версия контента элемента не изменилась.

При выполнении процедуры восстановления файла типа IPDC HNED выполняет следующие операции:

- идентифицирует отсутствующие данные из необходимого для доставки файла;

- ожидает время, разрешенное для передачи запроса сообщения на возврат файла;

- отправляет запросы на недостающие части файла.

В этом случае:

- сеть CDS отвечает на сообщение данными о восстановлении;

- переадресация файла (опционально) может быть выполнена на другой сервер восстановления или сервер сеанса multicast рассылки.

В случае переадресации на сервер восстановления unicast рассылки возвращаемый URI должен содержать URI базового сервера в синтаксисе <http-server-base-URI>.

В случае переадресации на multicast службу, возвращаемый URI должен указывать на описание сеанса multicast загрузки, как определено в 4.5, то есть возвращаемый URI может быть любым URI, как определено в 4.3.2. Поддерживаются описания сеанса как unicast, так и multicast передачи. После этого HNED должно следовать процедурам загрузки контента multicast передачи для присоединения к сеансу и загрузке отсутствующих данных.

Процедура восстановления конкретного файла CDS повторяет этапы восстановления файлов IPDC и дополнительно использует unicast процедуры восстановления файла, указанные в 4.6.3. В этом случае HNED применяет следующую процедуру восстановления:

- идентифицирует отсутствующие данные, необходимые для доставки файла в соответствии с 4.6.2;

- применяя разрешение ссылки, генерирует запрос URI в абсолютном синтаксисе URI <absolute-URI>, созданном из Recovery-Server-Base-URI в синтаксисе <http-server-base-URI> выбранного случайным образом сервера восстановления и File-Reference в синтаксисе <path-absolute> файла с отсутствующими данными;

- ожидает время, разрешенное для передачи запроса на возврат файла, как определено в 4.6.2;

- отправляет запросы HTTP на недостающие части файла, используя запрос URI. Заголовок запроса HTTP идентифицирует отсутствующие и запрошенные данные.

Сеть CDS отвечает на запрос и возвращает данные или инициирует переадресацию, как определено в 4.6.3. Ответ сети CDS может быть направлением на переадресацию.

После доставки файла HNED определяет необходимость его восстановления. Стек протоколов FLUTE предоставляет приемнику достаточную информацию для определения исходного блока и структуры символов кодирования для каждого файла и соответствующего экземпляра.

В случае восстановления файла в виде IPDC (Recovery-mode=1) применяются следующие процедуры.

Описание сеанса и протокола FLUTE предоставляют приемнику достаточную информацию для определения структуры источника и кодирующей структуры символов для каждого файла. Из этой информации приемник определяет набор символов, достаточный для завершения приема файла. Приемник запрашивает определенный набор символов с сервера восстановления. В случае использования схемы FEC Raptor приемник может запросить символы кодирования, достаточные для восстановления файла.

В случае использования схемы FEC raptor приемник должен:

- или идентифицировать минимальный набор символов кодирования, которые необходимо запросить в сочетании с уже принятыми символами, и разрешить декодеру Raptor FEC восстанавливать файл;

- или идентифицировать ряд новых символов восстановления, достаточных для восстановления файла.

При восстановлении файла на CDS (Recovery-mode=0) HNED должно инвертировать блокировку источника, как указано в 4.6.2, для сопоставления принятых символов кодировки с файлом, полученным частично. По результатам этого сопоставления приемник определяет области недостающих байтов, необходимых для завершения приема и восстановления файла, и запрашивает их для процедуры восстановления.

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

После окончания сеанса multicast рассылки HNED должно проверять наличие контента в сеансе сравнением файлов, полученных FLUTE, с файлами, анонсированными в службе рекламы (например, описание сеанса загрузки или FDT FLUTE). Если некоторые части доставленного контента отсутствуют, то HNED запрашивает необходимые данные для восстановления всего контента.

Для защиты от "взрывной" перегрузки обратной связи каждый запрос сообщения на сервер режима unicast загрузки задерживается. Параметры времени смещения и временного периода задержки передачи запроса сообщения предоставляются анонсом сеанса (Recovery-Offset-Time and Recovery-Random-Time).

4.6.3 Загрузка контента в unicast режиме

Для загрузки контента в unicast режиме в отдельных HNED используются unicast IP на основе HTTP. Доступность элементов контента в режиме загрузки unicast рекламы анонсируется в описаниях сеансов загрузки в соответствии с 4.5.

Unicast загрузка контента может выполняться в сеансах загрузки. Сеанс загрузки является экземпляром CDS, имеющим время начала и время окончания. В сеансе также загружаются URI для файлов, соответствующих элементу контента между временем начала и окончания. Время начала и окончания сеанса загрузки определяется в параметре Download-Session-Time-Information.

Параметр сеанса загрузки Download-Session-Mode=UD используется сетью CDS для индикации unicast загрузки.

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

При unicast загрузке от единственного сервера допускается переадресация на альтернативную загрузку от другого единственного сервера, или от нескольких серверов, или на сеанс загрузки multicast передачи.

В случае, если параметры загружаемого файла (File-Reference, дайджест MD5 и длина контента) совпадают с аналогичными параметрами файла, уже находящегося в устройстве хранения, файл не должен загружаться. Если параметры не совпадают, файл в устройстве хранения HNED будет удален и будет загружена его новая версия.

Загрузка файла от единственного сервера должна выполняться, если не указана информация о фрагменте файла при отсутствии параметров длины файла и длины фрагмента или не указано расположение сервера (параметр Server-Base-URI).

HNED создает запрос URI на разрешение по ссылке с базовым URI Server-Base-URI произвольно выбранному серверу из списка анонсированных серверов для файла и взаимосвязанной ссылки File-Reference и инициирует передачу файла HTTP, используя запрос URI. Если в описании сеанса загрузки присутствует File-Content-Type, заголовок Accept должен быть включен в запрос с указанным Content-Type.

Сеть CDS (сервер HTTP) может ответить:

- запрошенным файлом;

- запросом переадресации;

- кодом статуса 503 (недоступная служба) и заголовком ответа Retry-After (повторить позже), который указывает HNED на необходимость повторения первоначального запроса файла через интервал времени произвольной продолжительности или после даты и времени, предоставленных в заголовке Retry-After;

- кодом состояния 410, который указывает, что сеанс загрузки заканчивается.

Если сеть CDS (сервер HTTP) не отвечает указанным выше сообщениям, а передает код состояния 500 (внутренняя ошибка сервера), то HNED выбирает другой сервер из списка серверов и запускает новую загрузку файла. HNED должно продолжать эту процедуру до тех пор, пока запрос не будет успешным или не будут опробованы все объявленные серверы.

В случае, если серверы отчета приема будут определены в описании сеанса загрузки, HNED должно выполнять отчет приема, определенный в 4.6.5, после успешной загрузки файла и/или всех файлов элемента контента.

Загрузка от нескольких серверов должна выполняться, если для определенного файла предоставляется информация о фрагменте файла (параметры длины файла и длины строки) и несколько расположений сервера (параметры Server-Base-URI). HNED произвольным образом распределяет загрузку отдельных фрагментов файла по серверам, расположения которых предоставлены для данного файла с учетом доступности фрагментов на отдельных серверах (параметр Available-Chunk-List). HNED должно обеспечить загрузку всех фрагментов файла.

Примечание - Нормирование метода распространения запросов по расположению сервера выходит за рамки настоящего стандарта.

Для каждого выбранного сервера HNED должно генерировать запрос URI, используя разрешение по ссылке с базовым URI Server-Base-URI и взаимосвязанной ссылкой File-Reference.

Для каждого фрагмента, который должен быть загружен с сервера, HNED вычисляет диапазон байтов c учетом постоянной длины блока (параметр File-Chunk-Length) и позиции фрагментов.

Запрос одиночного сервера на unicast загрузку может быть перенаправлен:

- на альтернативную загрузку от единственного сервера;

- загрузку файла от нескольких серверов;

- multicast загрузку.

Сеть CDS предоставляет ответ HNED о режиме переадресации протоколом HTTP, устанавливая код статуса переадресации 3xx в исходный запрос на предоставление этого режима.

Для переадресации альтернативного файла с единственным сервером сеть CDS должна отвечать на запрос загрузки файла с кодом состояния 302 (найдено). Новый базовый URI с синтаксисом <http-server-base-URI> для альтернативного сервера предоставлен полем расположения ответа. Сеть CDS может дать ответ с заголовком "Retry-After" ("повторить позже"), который предписывает HNED выполнение переадресации с некоторой задержкой во времени или после времени, указанного в этом заголовке.

HNED инициирует загрузку файла единственного сервера после задержки, или времени, определенного заголовком Retry-After, или немедленно, если этот заголовок не указан. Новый базовый URI, предоставленный переадресацией, должен использоваться в качестве новой базы данных Server-Base-URI.

Для переадресации загрузки файла на совокупность серверов сеть CDS должна отвечать на запрос загрузки файла кодом состояния 300 (множественный выбор). Ответ содержит описание для загрузки файла с несколькими серверами. Сеть CDS может предоставить заголовок ответа Retry-After, предполагая, что это время относится к аннотации сеанса загрузки в описании сеанса загрузки.

В описании загрузки от нескольких серверов используются семантика и синтаксис, определенные для сеанса одноадресной загрузки. HNED должно поддерживать синтаксис XML и может поддерживать синтаксис SDP. Синтаксис указывается соответствующим типом Content-Type в ответе.

Примечание - Описанный метод переадресации используется для переадресации multicast загрузки. Из параметра Download-Session-Mode HNED будет знать тип используемой переадресации. Значение UD указывает переадресацию одноадресной передачи. Значение SMD или CMD указывает на переадресацию multicast загрузки.

HNED использует исходный File-Reference файла для идентификации соответствующей информации в описании сеанса загрузки.

Примечание - Описание сеанса загрузки может содержать информацию для нескольких файлов, например, если описание сеанса загрузки для всего элемента контента используется повторно. Каждый файл уникально идентифицируется параметром File-Reference.

HNED должно инициировать загрузку нескольких серверов после задержки или после времени, определяемого заголовком Retry-After, или немедленно, если этот заголовок не указан.

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

Для переадресации multicast загрузки сеть CDS пересылает код состояния 300 (множественный выбор). Ответ должен содержать описание для multicast загрузки. Заголовок ответа Retry-After не должен использоваться. Информация о времени сеанса загрузки multicast передачи приведена в описании сеанса.

В описании для multicast загрузки используются семантика и синтаксис, определенные в 4.5 для сеанса multicast загрузки. HNED должно поддерживать синтаксис XML и может поддерживать синтаксис SDP. Синтаксис описывается соответствующим типом MIME в ответе.

Информация о переадресации, предоставленная в теле объекта в ответе "300" (множественный выбор), использует информацию описания сеанса загрузки (см. 4.5) в формате XML или в формате SDP. Эта информация должна интерпретироваться следующим образом:

- параметры Service-Provider-Domain должны соответствовать параметрам Service-Provider-Domain в исходящем запросе. Если это условие не выполняется, то информация о переадресации игнорируется;

- параметры Download-Session-Version в запросе и в ответе могут отличаться;

- информация, содержащаяся в параметрах Content-Item-Format в запросе и в ответе, должна быть идентичной;

- для переадресации должен использоваться режим загрузки сеанса (Download-Session-Mode);

- должен предоставляться параметр Download-Session-Time-Information. В случае unicast загрузки ("UD") необходимо учитывать информацию переадресации HTTP Retry-After. В случае, если время, рассчитанное на основе информации Retry-After, находится за пределами объявленного времени сеанса загрузки, HNED должно выполнить переадресацию в самое раннее время в объявленном окне времени сеанса загрузки. В случае multicast загрузки (CMD или SMD) HNED должно выполнить переадресацию в ближайшее время, которое соответствует объявленной информации о времени сеанса загрузки;

- в случае предоставления информации отчета о приеме (Reception-Reporting-Server-URI, Reception-Reporting-Mode, Reception-Reporting-Offset-Time, Reception-Reporting-Random-Time-Period) информация должна быть идентична информации в оригинальном запросе;

- для переадресованной загрузки файла должны быть предоставлены unicast или multicast информации. Параметр File-Reference для перенаправленного файла должен соответствовать параметру File-Reference исходного описания сеанса загрузки. HNED должно использовать исходный параметр File-Reference для определения параметров файла в информации о переадресации. В случае переадресации на multicast загрузку HNED должно использовать исходный параметр File-Reference для идентификации файла в FDT сеанса FLUTE. Пользуясь информацией о перенаправлении, HNED должно обновлять начальное описание сеанса загрузки.

4.6.4 Параллельные сеансы загрузки

HNED может выполнять параллельную загрузку нескольких элементов контента в параллельных сеансах загрузки. Эта возможность определяется временем доступности элементов контента, запрашиваемых элементов контента пользователем в режиме загрузки pull и анонсированных элементов контента с помощью SP в режиме загрузки push. Сеансы загрузки элементов параллельного контента могут иметь разные режимы сеанса загрузки.

В случае параллельных multicast загрузок нескольких элементов контента HNED должно адаптировать multicast скорости передачи и использовать заявленную скорость передачи.

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

В случае загрузки файла с несколькими серверами HNED может выполнять параллельную загрузку файлов. Сведения о параллельных загрузках фрагментов папок файлов настоящим стандартом не нормируются.

4.6.5 Отчет о приеме

Сеть CDS должна указывать на необходимость использования отчетов приема, предоставляя Reception-Reporting-Server-URI в описании сеанса загрузки.

Параметр Reception-Reporting-Mode детализиpует отчет в следующих вариантах:

- отчет по элементам контента (Reception-Reporting-Mode=0);

- отчет по элементам контента и файлам (Reception-Reporting-Mode=1);

- отчет по элементам контента, файлам и фрагментам (Reception-Reporting-Mode=2).

Если параметр Reception-Reporting-Mode не указан, следует выполнять отчет об элементах контента (Reception-Reporting-Mode=0). Если для элемента контента запрашивается отчет о фрагменте, он должен использоваться только для загрузки файлов нескольких серверов. Для файлов, загружаемых с одного сервера, должен использоваться Reception-Reporting-Mode=1 (отчет приема по файлам).

HNED должно определять наличие элементов, для которых запрашивается отчет (например, элемент контента, файла, фрагмента), как указано в спецификациях загрузки, и отправлять отчеты о приеме на сервер отчетов. Сервер отчетов о приеме выбирается произвольным образом из списка серверов, предоставленных в описании сеанса загрузки (параметр Reception-Reporting-Server-URI).

При перегрузке канала обратной связи HNED с сервером в случае multicast загрузки каждое сообщение запроса к серверу отчетов приема задерживается. Параметры Reception-Reporting-Offset-Time и Reception-Reporting-Random-Time-Period предоставляются в описании сеанса загрузки.

Примечание - Параметры Reception-Reporting-Offset-Time и Reception-Reporting-Random-Time-Period, используемые для подтверждения доставки в режиме multicast загрузки, могут иметь значения, отличающиеся от значений, используемых для восстановления файлов.

Механизм задержки сообщений запроса отчетов приема в режиме unicast загрузки не используется. В этом случае HNED должно инициировать процесс отчета приема сразу после проверки завершения загрузки.

HNED отправляет отчет приема, используя запрос HTTP 1.1 POST, переносящий сообщение об отчете приема в формате XML.

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

Таблица 3 - Параметры сообщения отчета приема

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

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

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

Тип сообщения об отправке сообщений XML MIME должен быть установлен в application/xml.

Отчеты для нескольких элементов одного типа (например, несколько фрагментов в сообщении отчета приема канала, несколько файлов в сообщении о приеме файлов) могут быть объединены в одно сообщение.

Несколько сообщений разных типов могут быть объединены в один запрос HTTP с использованием составного MIME (multipart/mixed).

Идентификатор клиента (Client-ID) обеспечивает уникальную идентификацию HNED, когда отправляет сообщение отчета о приеме. Конкретное значение идентификатора клиента и правила его предоставления на HNED настоящий стандарт не определяет. Если не указано иное, HNED должно использовать в качестве идентификатора клиента свой MAC-адрес.

Примечание - Адрес IP HNED не является уникальной идентификацией, поскольку HNED может использовать частный адрес IP в случае, если он находится в домашней сети с трансляцией сетевых адресов.

Сервер отчетов приема должен ответить HTTP с кодом состояния 200 (OK), чтобы сигнализировать об успешном приеме и обработке отчетов приема. HNED в случае ответа с кодом состояния ошибки или в случае отсутствия ответа должно повторно отправить сообщение отчета приема на альтернативный сервер.

Элемент контента, анонсированный для загрузки, может содержать ошибки, которые помешают корректному проигрыванию элемента контента. Обновленная версия такого элемента контента, не содержащая ошибок, получает номер версии контента. Номер версии контента записывается в метаданных описания экземпляра BCG и в двоичном локаторе.

В случае изменения любого файла элемента контента сеть CDS должна установить новый сеанс загрузки для элемента контента и объявить новый сеанс загрузки в BCG с новым номером версии контента (используя тот же CRID). Новый сеанс загрузки multicast рассылки должен использовать другой TSI.

В случае, если изменение происходит во время сеанса загрузки старой версии контента, сеть CDS должна остановить этот сеанс загрузки. Для сеансов unicast загрузки серверы должны отвечать при коде состояния HTTP 410 Gone (завершение) при любом запросе на загрузку. Для сеансов multicast загрузки сеть CDS должна прекратить доставку FLUTE сеанса. HNED при получении обновленного объявления BCG с новым номером версии контента прекращает участие в этом сеансе загрузки устаревшей версии и удаляет уже загруженные данные. Если для unicast загрузки HNED получает код состояния HTTP 410 Gone для запроса загрузки файла, он дополнительно проверяет наличие обновленного номера версии контента. Для multicast загрузки HNED должно проверить обновленный номер версии контента до того, как он начнет восстановление файла (если загрузка файла не закончена). HNED присоединяется к новому сеансу загрузки при анонсировании загрузки обновленного элемента контента. Если HNED успешно загрузило элемент контента и прекратило свое участие в сеансе загрузки, то при получении анонса PushDownloadType BCG с новой версией контента HNED должно загрузить обновленный элемент контента. Для pull загрузки анонсов (через OnDemandProgramType или декомпозированный по требованию двоичный локатор, см. приложение Г) HNED должно проверить новую версию контента до воспроизведения элемента контента. Если новая версия контента доступна, она должна быть загружена до начала воспроизведения.

Файлы версии устаревшего контента должны быть удалены и заменены обновленной версией контента. Файлы, которые не изменились, должны храниться в старой версии и не загружаться повторно.

Сеансы unicast рассылки и multicast рассылки CDS должны использовать тип трафика Best effort data.

4.7 Управление устройством хранения HNED

Если HNED поддерживает CDS, оно должен выделить достаточный объем памяти в выделенном устройстве хранения для CDS.

Примечание - Для хранения TS MPEG-2 при скорости передачи 4 Мбит/с необходим объем памяти устройства хранения не менее 1,8 Гбит за каждый час.

Перед приобретением нового элемента контента HNED должно проверить наличие достаточного объема памяти устройства хранения HNED. Если объем памяти недостаточен, HNED не должно инициировать сеанс загрузки элемента контента.

Сеть CDS управляет устройством хранения HNED, отслеживая получение отчетов приема о контенте элементов отдельных HNED. Детализация использования отчетов приема для управления устройством хранения выходит за рамки настоящего стандарта.

Связанный атрибут ExpiryTime в загруженном элементе контента, указанный в OnDemandProgramType, PushDownloadType BCG или в "декомпозированном по требованию двоичном локаторе", определяет время окончания срока действия элемента контента и время его удаления из устройства хранения HNED.

При наступлении ExpiryTime HNED должно автоматически удалять все файлы из устройства хранения HNED, связанные с элементом контента.

Загрузка новых элементов контента не должна блокироваться элементами контента в устройстве хранения HNED с истекшим ExpiryTime.

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

Приложение А

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

Тип PushDownloadType для загрузки CDS

Новый тип PushDownloadType инициирует загрузку и хранение указанного элемента контента в устройстве хранения HNED. С учетом любых критериев фильтрации, которые могут применяться в HNED. HNED должно автономно присоединяться к анонсированному сеансу загрузки и загружать элемент контента, в устройстве которого анонсируется PushAction для хранения. Метаданные, относящиеся к этому элементу контента, могут предоставляться вместе с данными контента как часть загрузки (см. 4.4). В таблице А.1 представлено описание элементов/атрибутов PushDownloadType.

Таблица А.1 - Описание элементов/атрибутов PushDownloadType

PushDownloadType является частью метаданных описания экземпляра на основе типа ProgramLocationType. Расширение типа ProgramLocationType приведено в приложении Б.

Ниже представлена схема XML PushDownloadType:

<annotation>

<documentation xml:lang="en">New PushDownloadType for TM-IPI CDS</documentation>

</annotation>

<complexType name="PushDownloadType">

<complexContent mixed="false">

<extension base="tva:ProgramLocationType">

<sequence>

<element minOccurs="0" name="PublishedDuration" type="duration" />

<element minOccurs="0" name="StartOfAvailability" type="dateTime" />

<element minOccurs="0" name="EndOfAvailability" type="dateTime" />

<element minOccurs="0" maxOccurs="1" name="ContentVersion" type="unsignedByte" />

<element minOccurs="0" maxOccurs="1" name="ExpiryTime" type="dateTime" />

</sequence>

<attributeGroup ref="tva:fragmentIdentification" />

<attribute name="metadataOriginIDRef" type="tva:TVAIDRefType" use="optional" />

<attribute ref="xml:lang" use="optional" />

<attribute name="serviceIDRef" type="tva:TVAIDRefType" use="optional" />

</extension>

</complexContent>

Приложение Б

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

Расширенный тип ProgramLocation

Тип ProgramLocationType расширяется для включения PushDownloadType в качестве допустимого расположения программы.

Расширение PushDownloadProgram. PushDownloadProgram включает в себя анонсы загрузки CDS в режиме "push" в таблице расположений программы BCG. Атрибут имеет тип PushDownloadType.

Приложение В

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

Декомпозированный по требованию двоичный локатор

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

Расширенный по требованию двоичный локатор определяет следующие основные параметры:

- availability_start_date, первая дата, начиная с которой становится доступным контент по запросу, указанный этим локатором. Это поле использует универсальное координированное время (UTC) в качестве ссылки на время. Оно должно быть закодировано количеством дней с начала года. Значение 0 указывает на 1 января того же года;

- availability_end_date, первая дата, начиная с которой контент, указанный этим локатором, больше не доступен. Это поле использует UTC в качестве ссылки на время. Оно должно быть закодировано количеством дней с начала года. Значение 0 указывает на 1 января того же года;

- availability_start_time, время, в течение которого контент по запросу, на который указывает этот локатор, становится доступным. В этом поле используется UTC в качестве ссылки на время. Поле кодируется количеством интервалов начиная с полуночи с периодом 2 с;

- availability_end_time, время, начиная с которого контент по запросу, на который указывает этот локатор, становится недоступным. В этом поле используется UTC как ссылка на время. Поле кодируется количеством интервалов начиная с полуночи с периодом 2 с.

Приложение Г

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

Расширенный декомпозированный по требованию двоичный локатор

Расширенный декомпозированный по требованию двоичный локатор применяется для предоставления необходимых параметров для служб загрузки "pull". Синтаксис расширенного декомпозированного по требованию двоичного локатора представляет собой расширенный набор декомпозированного по требованию двоичного локатора для включения режимов служб CDS.

Расширенный декомпозированный по требованию двоичный локатор определяет следующие основные параметры:

- delivery_mode=0, режим потоковой передачи. Потоковая доставка контента по требованию;

- delivery_mode=1, режим загрузки. Загрузка контента по требованию. Если параметр delivery_mode равен 0, семантика полей должна быть идентична семантике, указанной в приложении В. В полях content_version, early_playout, expiry_date и expiry_time должен быть установлен 0, эти поля должны игнорироваться приемником.

Если параметр delivery_mode равен 1, параметры загрузки контента по требованию определяются следующими параметрами:

- availability_start_date, первая дата, по которой контент по запросу, на который указывает этот локатор, становится доступным для загрузки. Используется синтаксис, определенный в приложении В;

- availability_end_date, первая дата, начиная с которой контент, на который указывает этот локатор, не доступен для загрузки. Используется синтаксис, определенный в приложении В;

- availability_start_time, время, в течение которого контент по запросу, на который указывает этот локатор, становится доступным для загрузки. Используется синтаксис, определенный в приложении В;

- availability_end_time, время, когда контент по запросу, на который указывает этот локатор, становится недоступным для загрузки. Используется синтаксис, определенный в приложении В;

- content_version, версия загружаемого контента. Номер версии отсчитывается от 0 до 255, при переполнении счетчика свыше 255 счет начинается с 0.

Приложение Д

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

Контент MD5

MD5 (Message Digest 5) - 128-битовый алгоритм хеширования. Предназначен для создания сообщения произвольной длины для последующей проверки их подлинности. MD5 является частью метода HEAD cообщения HTTP.

Поле заголовка объекта Content-MD5 представляет собой дайджест MD5 тела объекта для сквозной проверки целостности сообщения (message integrity check, MIC) тела объекта.

Content-MD5 = Content-MD5:

md5-digest md5-digest = <base64 из 128-битового MD5-дайджест согласно RFC 1864>

Поле заголовка Content-MD5 может формироваться сервером-источником или клиентом для проверки целостности тела объекта. Поле заголовка Content-MD5 могут формировать только серверы-источники или клиенты. Поле заголовка не должны формировать прокси-серверы и шлюзы. Любой приемник тела объекта, включая шлюзы и прокси-серверы, может проверить соответствие значения дайджеста в этом поле заголовка значению принятого тела объекта.

Дайджест MD5 вычисляется при использовании контента тела объекта с учетом примененного кодирования контента при условии некодированной передачи тела сообщения. Если сообщение получено при кодированной передаче тела, кодирование должно быть удалено перед началом проверки значения Content-MD5 принятого объекта.

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