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

ГОСТ Р 54994-2012

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

ТЕЛЕВИДЕНИЕ ВЕЩАТЕЛЬНОЕ ЦИФРОВОЕ. ПЕРЕДАЧА СЛУЖБ DVB ПО СЕТЯМ С IP ПРОТОКОЛАМИ

Общие технические требования

Digital broadcast television. Transport of DVB services over networks with IP protocols. General technical requirements

ОКС 33.170

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

Предисловие

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

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

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

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

________________

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

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

6 ПЕРЕИЗДАНИЕ. Июнь 2020 г.

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

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

Настоящий стандарт распространяется на параметры интерфейса оконечного устройства домашней сети (Home Network End Device; HNED), который при работе в сетях с IP протоколами обеспечивает передачу на HNED транспортных потоков MPEG-2 служб DVB.

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

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

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

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

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

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

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

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

3.1.1 артефакт (artefact): Дефект изображения.

3.1.2 букет программ: Совокупность сервисов, предлагаемых абоненту как единый программный продукт.

3.1.3 вещатель (broadcaster [Service Provider]): Организация, которая собирает последовательность событий или программ для доставки.

3.1.4 декларация типа документа (Document Type Declaration; DTD): Составная часть XML-документа, содержащая имя типа документов, DTD или ссылку на DTD, которому соответствует данный документ.

3.1.5 документ DVB-HTML (DVB-HTML document): Полный (завершенный) модуль элементов или форматов контента одного семейства HTML, определенного в настоящем стандарте.

3.1.6 домашняя мультимедийная платформа (Multimedia Home Platform; МНР): Аппаратно-программный комплекс, обеспечивающий доступ пользователя к интерактивным и вещательным службам.

3.1.7 домашняя сеть: Домен домашней платформы клиента, являющийся потребителем аудио- и видео служб, в общем случае представляет собой сеть терминалов.

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

3.1.9 дескриптор (descriptor): Кодовое слово, служащее для описания типа передаваемых данных.

3.1.10 загрузка (download): Пересылка файлов по сети от пользователя или сервера пользователю или серверу.

3.1.11 идентификатор типа пакета (packet identifier; PID): Тринадцатибитовый указатель в заголовке транспортного пакета, определяющий принадлежность пакета тому или иному потоку данных.

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

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

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

3.1.13 интероперабельность (interoperability): Нейтральная платформа, обеспечивающая прием и представление приложений для поставщика, автора и вещателя (функциональная совместимость).

3.1.14 интерфейс: Семантическая и синтаксическая конструкция в коде программы, используемая для специфицирования услуг, предоставляемых классом или компонентом. Интерфейс определяет:

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

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

3.1.15 информация о службах (Service Information; SI): Совокупность таблиц, которые передаются в составе транспортных потоков MPEG-2, предназначенных для вещания. К основным таблицам информации о службах относятся таблицы, характеризующие параметры сети передачи, компоненты служб: таблица объединения букета программ (Bouquet Association Table; ВАТ), таблица информации о событиях (Event Information Table; EIT), таблица состояния событий (Running Status Table; RST), таблица описания служб (Service Description Table; SDT), таблица времени и даты (Time and Date Table; TDT), таблица смещения времени (Time Offset Table; TOT).

3.1.16 Карусель Данных (Data Carousel): Передача модулей данных с циклическим повторением.

3.1.17 Карусель Объектов (Object Carousel; ОС): Передача в транспортном потоке циклически повторяющихся объектов (Файлов, Каталогов, Потоков).

3.1.18 Клиент (Client): Потребитель услуг одного или более серверов.

3.1.19 коммутируемый виртуальный канал (Switched Virtual Circuit; SVC): Тип логического соединения, устанавливаемого по запросу пользователя только на время, необходимое для обмена информацией.

3.1.20 контекст (context): Состояние системы; окружение системы, среда выполнения программы; текущая ситуация.

3.1.21 контент (content): Содержание, мультимедийный продукт (например, телевизионная программа).

3.1.22 конфигурация (configuration): Совокупность аппаратных и программных средств и связей между ними.

3.1.23 конфигурирование: Установление конфигурации.

3.1.24 кэш (cache): Быстродействующая буферная память большой емкости, используемая для хранения копии областей оперативной памяти с наиболее частым доступом.

3.1.25 медиа (media): Информационные сообщения, передаваемые по каналам вещания (MPEG кадры звука, MPEG кадры изображения, JPEG кадры изображения, файлы текста, субтитров, загружаемых шрифтов, графическая информация).

3.1.26 междуобъектный интерфейс (inter-entity interface): Интерфейс между двумя объектами, находящимися в различных подсистемах.

3.1.27 многоцелевые расширения почты Интернет (Multipurpose Internet Mail Extensions; MIME): 1 Стандарт, описывающий передачу различных типов данных. 2 Спецификация для кодирования информации и форматирования сообщений.

3.1.28 навигатор (navigator): Резидентное приложение, обычно обеспечиваемое производителем, которое конечный пользователь может активировать в любое время. Навигатор может использоваться для выбора службы, приложения и инициирования взаимодействующих приложений.

3.1.29 нормальная форма Бэкуса-Наура; БНФ (Backus Normal Form; BNF): Нотация (метаязык) для записи синтаксиса языков программирования.

3.1.30 обнаружение и выбор службы (Service Discovery and Selection; SD&S): Наименование механизма обнаружения и выбора DVB базовых аудио/видео служб при использовании двунаправленных сетей IP.

3.1.31 обратный вызов (callback): Принцип регистрации вызова класса-обработчика события (слушателя) в среде класса-источника при выполнении приложения DVB-J. Обратный вызов позволяет функции обратного вызова исполнять код, который задается в аргументах при ее вызове.

3.1.32 объект (entity): Функциональный модуль в составе подсистемы (например, в состав подсистемы клиента входят объекты пользователь-сеть (П-С) и пользователь-пользователь (П-П)).

3.1.33 оконечное устройство домашней сети (Home Network End Device; HNED): Устройство, которое соединено с домашней сетью и которым начинается и завершается IP информационный поток [является отправителем потока или приемником потока].

3.1.34 ответвление (tap): Прикладной объект, связанный с более низким уровнем взаимодействия.

3.1.35 пакетированный элементарный поток; ПЭП (Packetized Elementary Stream; PES): Пакетированный элементарный поток, в котором данные разбиты на пакеты и снабжены заголовками.

3.1.36 персистентность (Persistence): Сохраняемость, живучесть.

3.1.37 пользователь (user): Оконечная система, которая может передавать или принимать информацию от других таких же оконечных систем с использованием сети и которая может функционировать как клиент, сервер или как клиент и сервер одновременно.

3.1.38 постоянный виртуальный канал (Permanent Virtual Circuit; PVC): Логическое соединение, устанавливаемое на сетевом уровне на определенный период времени.

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

3.1.40 приложение (application): 1 Программное обеспечение, предоставляющее клиенту возможность решения определенной задачи и реализуемое в среде клиента. 2 Функциональная реализация программного обеспечения, обслуживающего один или несколько взаимодействующих аппаратных объектов.

3.1.41 приложение DVB-HTML (DVB-HTML application): Совокупность документов, выбранных из семейства DVB-HTML элементов и форматов контента, определенных в спецификации. Границы множества документов определяются границами приложения.

3.1.42 примитив (primitive): Программный модуль, выполняющий одну элементарную операцию, или блоки данных, передаваемые между разными уровнями системы для вызова каких-либо процедур.

3.1.43 программный интерфейс приложения (Application Programming Interface; API): Набор определенных интерфейсов, посредством которых приложение общается с операционной системой (ОС) или с другими программами.

3.1.44 программный поток данных (Program Stream; PS): Поток данных, образованный путем мультиплексирования элементарных потоков видеоданных и звукоданных цифрового вещательного телевидения, имеющих одну общую тактовую частоту, и сформированный из программных пакетов вещательного телевидения переменной длины.

3.1.45 протокол управления группами (пользователей) в сети Интернет (Internet Group Management Protocol; IGMP): Протокол многоадресной рассылки, управляет передачей пакетов между пользователями и поддерживается протоколами IP в соответствии со стандартом IETF [2].

3.1.46 профиль (profile): Описание группы минимальных конфигураций, определяющих часть спецификации, обеспечивающей возможности домашней мультимедийной платформы (Multimedia Home Platform) или HNED и отображающей функции, которые характеризуют контекст опций службы.

3.1.47 ресурс (resource): Способность или качество системного объекта, которая может использоваться для создания вклада в реализацию службы (например, декодер стандарта MPEG, графическая система).

3.1.48 сеанс (session): Последовательность операций, при которой между пользователями сети устанавливается соединение, проводится обмен данными и завершается соединение.

3.1.49 сегмент домашней сети (Home Network Segment; HNS): Обеспечивает обмен данными на уровне канала между домашними оконечными сетевыми устройствами и/или присоединяющимися компонентами.

3.1.50 секция (section): Синтаксическая структура, используемая для отображения всей сервисной информации в пакетах транспортного потока.

3.1.51 семантика (semantics): Система правил, предназначенная для определения смысловых значений отдельных конструкций алгоритмического языка.

3.1.52 сервер (server): Программный объект, экспортирующий ресурс имеющихся данных и устанавливаемый на физическое устройство, подключенное к сети и предоставляющее услуги другим устройствам, работающим в этой сети.

3.1.53 сервис [служба, услуга] (service): 1 Последовательность программ, которая под управлением вещателя может быть в режиме вещания передана как часть расписания. 2 Логический объект в системе предоставляемых функций и интерфейсов, поддерживающий одно или множество приложений, отличие которого от других объектов заключается в доступе конечного пользователя к управлению шлюзом сервисов.

3.1.54 сеть (network): Совокупность элементов, поддерживающих связь, обеспечивающая соединение элементов, управление сеансом связи и/или управление подключением пользователя.

3.1.55 сеть DVB (DVB network): Набор мультиплексов транспортных потоков MPEG-2, переданных по единственной системе доставки (например, все цифровые каналы в конкретной кабельной системе).

3.1.56 синтаксис (syntax): Часть языка программирования, которая описывает структуру программ как наборов символов.

3.1.57 система DSM-CC (DSM-CC system): Вся область действия протокола DSM-CC, включая субсистемы и их интерфейсы.

3.1.58 состояния приложения DVB-HTML (DVB-HTML application states): Логические состояния, в которых может находиться агент DVB-HTML.

3.1.59 ссылка на программные часы (Program Clock Reference; PCR): Тридцатитрехбитовое число, оцениваемое в периодах частоты 90 кГц, вводимое на программном уровне индивидуально для каждой передаваемой телевизионной программы.

3.1.60 стаб (stub): Программный модуль, временно подменяющий реальную процедуру другой версией, предусматривающей возможность передачи параметров вызываемой процедуры через сеть в "прозрачном" режиме.

3.1.61 субсистема (subsystem): Единица логического "оборудования" в пределах DSM-CC системы (например, клиент, сервер или менеджер сеансов и ресурсов).

3.1.62 таблица информации приложений (Application Information Table; AIT): Таблица, обеспечивающая полную информацию о вещании данных и о необходимых операциях для активизации приложений.

3.1.63 таблица описания служб (Service Description Table; SDT): Таблица, описывающая службы, передаваемые в конкретном транспортном потоке.

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

3.1.65 тег объединения (association tag): Признак, идентифицирующий группы ресурсов или разделенные ресурсы, которые вместе составляют соединение пользователь-пользователь (П-П), при подключении к ресурсам являющийся уникальным в пределах сеанса.

3.1.66 транспорт [передача, транспортировка] (transport): Передача информации между различными объектами транспортного уровня, при котором гарантируется заданная степень надежности связи.

3.1.67 транзакция (transaction): Логическая единица работы, состоящая из запроса и получения результатов его обработки (короткое сообщение, передаваемое в диалоговом режиме между равноправными объектами прикладных уровней).

3.1.68 транспортный поток; ТП (transport stream; TS): Набор из нескольких программных потоков данных цифрового вещательного телевидения, сформированный из программных пакетов постоянной длины с коррекцией ошибок и независимым тактированием от своих источников синхронизации.

3.1.69 универсальный набор символов (Universal Character Set; UCS): Универсальный набор символов, который задает однозначное соответствие символов кодам - элементам кодового пространства, представляющим неотрицательные целые числа.

3.1.70 файл заглушки (Stub File): Файл функции заглушки.

3.1.71 хост (host): Узлы отправителя и получателя.

3.1.72 четность чередующихся битов [четность при чередовании битов] (Bit Interleaved Parity; BIP): Процедура проверки четности в кадрах с чередующимися битами.

3.1.73 шлюз сервиса (службы) (Service Gateway): Интерфейс, предоставляющий клиенту каталог услуг и возможность подключаться к домену сервиса (службы).

3.1.74 (Unicode): Стандарт кодирования символов, представляющих знаки письменных языков.

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

БНФ (Backus Normal Form, BNF) - нормальная форма Бэкуса-Наура;

МСР (Session and Resource Manager, SRM) - менеджер сеансов и ресурсов;

МСЭ (International Telecommunication Union, ITU) - Международный союз электросвязи;

МЭК (International Electrotechnical Commission/Committee, IEC) - Международная электротехническая комиссия;

ОС (Operating System, OS) - операционная система;

ПО - программное обеспечение;

ПЭП (Packetized Elementary Stream, PES) - пакетированный элементарный поток;

ТП (transport stream, TS) - транспортный поток (цифрового вещательного телевидения);

"ТП полная SI" - "транспортный поток, полная SI";

"ТП дополнительная SI" - "транспортный поток, дополнительная SI";

ЭВМ - электронно-вычислительная машина;

ФАПЧ (Phased Locked Loop, PLL) - фазовая автоподстройка частоты;

AIT (Application Information Table) - таблица информации приложений;

AL (Application Layer) - уровень приложений;

API (Application Programming Interface) - программный интерфейс приложения;

ARP (Address Resolution Protocol) - протокол преобразования [разрешения] адресов;

A/V (Audio/Video) - аудио/видео;

ВАТ (Bouquet Association Table) - таблица объединения букета программ;

BCG (Broadband Content Guide) - путеводитель по контенту вещания;

BiM (Binary MPEG format for XML) - бинарный формат MPEG для XML;

BIP (Bit Interleaved Parity) - четность чередующихся битов [код битового чередуемого паритета, четность чередующихся битов, чередующаяся четность битов];

BNF (Backus Normal Form) - нормальная форма Бэкуса-Наура; БНФ;

BYE - указатель завершения соединения;

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

СС (CSRC Count) - количество идентификаторов CSRC;

CDP (Content Delivery Protocols) - протоколы доставки контента;

CDS (Content Download Service) - "служба загрузки контента";

CelllD (Cell identifier) - идентификатор ячейки (соты);

CMD (Carousel Multicast Download) - загрузка в режиме многоадресной карусели;

CNAME (canonical name) - каноническое имя;

CoD (Content on Demand) - "контент по требованию (запросу)";

СРСМ (Content Protection and Copy Management) - защита контента и управление копированием;

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

CSP (Content Service Provider) - провайдер службы контента;

CSRC (Contributing Source) - объединяемые потоки (информации); объединяемые источники (информации);

DHCP (Dynamic Host Configuration Protocol) - протокол динамической конфигурации хоста (узла);

DNG (Delivery Network Gateway) - шлюз сети доставки;

DNS (Domain Name System) - система доменных имен;

DNS (Domain Name Server) - сервер доменных имен;

DSCP (Differentiated Services CodePoint) - кодовые точки дифференцированных (различных) служб;

DSM (Digital Storage Media) - цифровая запоминающая среда;

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

DTD (Document Type Declaration) - декларация типа документа;

DVB (Digital Video Broadcasting) - цифровое телевизионное вещание;

DVB-HTML application - приложение DVB-HTML;

DVB-HTML document - документ DVB-HTML;

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

DVB-IPTV - цифровое телевизионное вещание по каналам с IP протоколами;

DVB-J - платформа Java, являющаяся частью спецификации МНР;

DVB network - сеть DVB;

DVBSTP (DVB SD&S Transport Protocol) - транспортный протокол обнаружения и выбора службы DVB;

EIT (Event Information Table) - таблица информации о событиях;

FB (Feed Back) - обратная передача;

FEC (Forward Error Correction) - прямое исправление ошибок;

FF (Feed Forward) - прямая передача;

FLUTE (File Delivery over Unidirectional Transport) - доставка файла при однонаправленной передаче;

EPG (Electronic Program Guide) - электронный путеводитель (гид) по программам;

FUS (Firmware Update Service) - служба обновления встроенного программного обеспечения;

FUSS (File Upload System Stub) - системные заглушки загрузки файла;

GSM (Global System for Mobile communications) - глобальная система подвижной связи;

HNED (Home Network End Device) - оконечное устройство домашней сети;

HNN (Home Network Node) - узел домашней сети;

HNS (Home Network Segment) - сегмент домашней сети;

HTML (Hyper Text Mark-up Language) - язык разметки гипертекста;

HTML-3.2 - номер версии языка HTML;

HTTP (Hyper Text Transfer Protocol) - протокол передачи гипертекстовых файлов;

HTTPS (Hyper Text Transfer Protocol Secure) - протокол передачи гипертекстовых файлов с защитой;

IANA (Internet Assigned Numbers Authority) - Администрация адресного пространства Интернет (Совет по регистрации доменов Интернет);

ID (IDentifier) - идентификатор;

IEC (International Electrotechnical Commission/Committee) - Международная электротехническая комиссия; МЭК;

IEEE (Institute of Electrical and Electronics Engineers) - Институт инженеров по электротехнике и радиоэлектронике;

IETF (Internet Engineering Task Force) - техническая комиссия Интернет, разрабатывающая документы RFC;

IGMP (Internet Group Management Protocol) - протокол управления группами (пользователей) в сети Интернет;

INT (IP/MAC Notification Table) - таблица нотификации [извещений] IP протокола;

IP (Internet Protocol) - Интернет протокол;

IPv4 (Internet Protocol version 4) - Интернет протокол, версия 4;

IP протокол (Internet protocol) - семейство протоколов, входящих в стек протоколов TCP/IP;

IPCP (Internet Protocol Control Protocol) - протокол управления Интернет протоколом;

IPDC (Internet Protocol DataCasting) - Интернет протокол широковещательной рассылки данных;

IPI (Internet Protocol Infrastructure) - инфраструктура протокола IP;

ISBN (International Standard Book Number) - Международный стандартный номер книги;

ISN (Initial Sequence Number) - начальный номер последовательности;

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

ISP (Internet Service Providers) - провайдер служб сети Интернет (Интернет-провайдеры);

ITU (International Telecommunications Union) - Международный союз электросвязи; МСЭ;

ITU-T (International Telecommunications Union - Telecommunication Standardization Sector) - Сектор стандартизации электросвязи МСЭ;

JFIF (JPEG File Interchange Format) - формат обмена файлами JPEG;

JPEG (Joint Picture Expert Group) - группа экспертов по кодированию фотографических изображений (стандарт сжатия фотографических (неподвижных) изображений);

LAN (Local-area Network) - локальная сеть;

LMB (Live Media Broadcast) - "вещание медиа";

LMDS (Local Multi-point Distribution Systems) - система местного многоточечного распределения;

MAC (Media Access Control) - управление доступом к среде;

MBwTM (Media Broadcast with Trick Modes) - вещание медиа с модой Trick;

МС (MultiCast [Multicast, multicast]) - многоадресная (например, передача);

МНР (Multimedia Home Platform) - аппаратно-программный комплекс - домашняя мультимедийная платформа;

middleware - промежуточное программное обеспечение;

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

MPEG (Motion Pictures Expert Group) - группа экспертов по движущимся изображениям [группа стандартов сжатия аудио- и видеоинформации];

MPEG-2 - стандарт цифрового сжатия аудио- и видеоинформации;

MTS (MPEG-2 Transport Stream) - транспортный поток MPEG-2;

MTU (Maximum Transmission Unit) - максимальный модуль передачи;

NACK (negative acknowledgment) - отсутствие подтверждения приема (отрицательная квитанция);

NetBIOS (Network Basic Input/Output System) - протокол для работы в локальных сетях на персональных ЭВМ;

NetBIOS/WINS (NetBIOS/Windows Internet Naming Service) - служба сопоставления NetBIOS-имен компьютеров с IP-адресами узлов;

NTP (Network Time Protocol) - сетевой протокол времени;

ОС (Object Carousel) - Карусель Объектов;

OS (Operating System) - операционная система; ОС;

OSI (Open Systems Interconnection) - взаимодействие открытых систем;

PCR (Program Clock Reference) - ссылка на программные часы;

PES (Packetized Elementary Stream) - пакетированный элементарный поток; ПЭП;

PID (Packet Identifier) - идентификатор типа пакета;

PLL (Phased Locked Loop) - фазовая автоподстройка частоты; ФАПЧ;

РМТ (Program Map Table) - таблица состава программы;

PS (Program Stream) - программный поток данных;

PSI (Program Specific Information) - программно-зависимая информация;

РТ (Payload Туре) - тип полезной нагрузки;

PVR (Digital Video Recorder) - цифровой видеорекордер;

QoS (Quality of Service) - качество службы;

QRC (Query-Response Channel) - канал ответа на запрос;

RET (RETransmission) - повторная передача;

RFC (Request for Comments) - предложения для обсуждения, серия нормативных документов, стандартизирующих протоколы Интернет;

RMS (Remote Management and Firmware) - служба удаленного управления и встроенных программ;

RPC (Remote Procedure Call) - вызов удаленных процедур;

RR (Receiver Report) - отчет получателя;

RSI (Receiver Summary Information) - сводная информация приемника;

RST (Running Status Table) - таблица состояния событий;

RTCP (Real-time Transport Control Protocol) - протокол контроля транспортировки информации в реальном времени;

RTP (Real-time Transport Protocol) - транспортный протокол реального времени;

RTSP (Real Time Streaming Protocol) - потоковый протокол реального времени;

RTT (round trip time) - время от отправления запроса до получения ответа;

SAP (Session Announcement Protocol) - протокол анонсирования сеанса;

SDES (Source DEScription) - описание источника;

SDP (Session Description Protocol) - протокол описания сеанса;

SD&S (Service Discovery and Selection) - обнаружение и выбор службы;

SDT (Service Description Table) - таблица описания служб;

SETUP - подготовка к работе;

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

SMD (Scheduled Multicast Download) - запланированная многоадресная загрузка;

SRM (Session and Resource Manager) - менеджер сеансов и ресурсов; МСР;

SNTP (Simple Network Time Protocol) - простой сетевой протокол времени;

SOAP (Simple Object Access Protocol) - простой протокол доступа к объекту;

SP (Service Provider) - провайдер службы;

SPI (Source Packet Information) - информация исходного пакета;

SR (Sender Report) - отчет отправителя;

SRBT (Sub-Report Block Type) - тип блока суботчета;

SSL (Secure Socket Layer) - уровень безопасности сокета;

SSM (Single Source Multicast) - одиночная исходная многоадресная передача;

SSM (Source Specific Multicast) - источник определенной (специфичной) многоадресной передачи;

SSRC (Synchronization Source) - источник синхронизации;

STC (System Time Clock) - часы системного времени;

SVC (Switched Virtual Circuit) - коммутируемый виртуальный канал;

TCP (Transmission Control Protocol) - протокол управления передачей (из стека протоколов TCP/IP);

TCP/IP - стек протоколов сетевого и транспортного уровня;

TDT (Time and Date Table) - таблица времени и даты;

TLS (Transaction Layer Security) - безопасность уровня транзакции;

ToS (Type of Service) - тип службы (сервиса);

ТОТ (Time Offset Table) - таблица смещения времени;

Trick - режим [мода] быстрого проигрывания мультимедиа;

TS (Transport Stream) - транспортный поток (цифрового вещательного телевидения); ТП;

T-STD (The Transport Stream System Target Decoder) - системный целевой декодер транспортного потока;

TVA (TV Anytime) - собирательный термин, относящийся к нормализованным процедурам поиска, селекции контента служб вещания и on-line сервиса (интерактивные услуги) для персональных систем хранения;

UCS (Universal Character Set) - универсальный набор символов;

UD (Unicast Download) - одноадресная загрузка;

UDP (User Datagram Protocol) - протокол пользовательских датаграмм;

Ul (User Interface) - интерфейс пользователя;

URI (Uniform Resource Identifier) -унифицированный идентификатор ресурса;

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

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

UTF-8 (Unicode Transformation Format) - формат преобразования Юникода, реализующий представление Юникода, совместимое с 8-битным кодированием текста;

WINS (Windows Internet Name Service) - служба сопоставления NetBIOS-имен компьютеров с IP-адресами узлов;

World Wide Web - глобальная распределенная система гипермедиа, размещенная в сети Интернет;

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

"pull" - режим "получение информации [записи] по запросу";

"push" - режим многоадресной (multicast) передачи информации.

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

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

4.1.1 Модель системы передачи транспортных потоков служб DVB по сетям с IP протоколами (DVB-IP)

Система передачи транспортных потоков служб DVB по сетям с IP протоколами (DVB-IP) обеспечивает передачу служб DVB ("вещание медиа" (Live Media Broadcast; LMB)), передачу "контента по запросу" (CoD)) на домашнюю платформу клиента. Модель уровней DVB-IP, представленная на рисунке 1, включает в себя следующие домены:

- провайдер контента;

- провайдер служб;

- сеть доставки;

- домашняя платформа клиента.

Рисунок 1 - Модель уровней DVB-IP

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

Провайдер служб (Service Provider; SP) представляет собой объект, предоставляющий службу конечному пользователю на домашнюю платформу клиента. Провайдерами служб могут быть Интернет-провайдеры (Internet Service Providers; ISP) и провайдеры служб контента (Content Service Provider; CSP).

В контексте служб DVB провайдер служб получает контент (на основе соглашения) от провайдеров контента и преобразует его в службу.

Сеть доставки соединяет объекты клиентов и провайдеров служб.

Сеть доставки в общем случае прозрачна для трафика IP

4.1.2 Эталонная модель домашней сети

Эталонная модель домашней сети представлена на рисунке 2.

В ее состав входят следующие элементы:

- шлюз сети доставки (DNG), соединенный с одной или несколькими сетями доставки и с одним или несколькими сегментами домашней сети;

Рисунок 2 - Эталонная модель домашней сети

- сегмент домашней сети (HNS). Совокупность HNS в составе эталонной модели домашней сети формирует домашнюю сеть, которая является отдельной "субсетью IP". HNS присваиваются имена, включающие наименование сетевой технологии (Ethernet или беспроводная LAN) и собственное имя HNS;

- узел домашней сети (HNN) соединяет два или более HNS друг с другом и выполняет функции моста. Параметры HNN должны быть в соответствии с IEEE [3], [4] (ниже границы службы MAC). HNN должен поддерживать процедуры для обеспечения необходимого качества обслуживания (QoS) согласно IEEE [5] в соответствии с разделом 7 настоящего стандарта;

- оконечное устройство домашней сети (HNED).

Взаимодействие между устройствами эталонной модели домашней сети описываются интерфейсами, которые показаны на рисунке 2. Наименования этих интерфейсов образуются из аббревиатуры IPI и порядкового номера от 1 до 4.

В настоящем стандарте рассматриваются требования к интерфейсу IPI-1. Требования к интерфейсам IPI-2, IPI-3, IPI-4 в этом стандарте не предъявляются.

Для передачи трафика при использовании IP протокола все интерфейсы IPI-1 должны соответствовать требованиям IETF [6], при использовании протокола ARP - требованиям IETF [7].

4.1.3 Диаграмма стека протоколов DVB-IPTV

На рисунке 3 представлена логическая диаграмма стека протоколов высокого уровня интерфейса IPI-1, обеспечивающих предоставление служб DVB по IP сетям. Организация этого стека протоколов основана на иерархической структуре.

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

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

Встроенное программное обеспечение (ПО) профиля DSM-CC для FUS RMS должно быть в соответствии с ETSI [8].

Информация, которой обмениваются при использовании протокола RTSP, может быть передана в формате SDP или XML.

Рисунок 3 - Диаграмма стека протоколов служб DVB-IPTV

Запись TLS/SSL означает, что могут использоваться TLS или SSL.

Запись HTTP/HTTPS означает, что могут использоваться HTTP или HTTPS.

4.2 Сценарии использования HNED в сетях DVB-IPTV

Для всех возможных сценариев использования HNED предусматривается:

- использование механизмов DHCP для присвоения HNED IP-адреса и других параметров;

- передача трафика IP через DNG к HNED на сетевом уровне OSI.

Представленные варианты сценариев позволяют показать основные возможности передачи транспортных потоков служб DVB по сетям с IP протоколами:

- одиночная домашняя сеть;

- множество домашних сетей (сложная домашняя сеть).

Одиночная домашняя сеть показана на рисунке 4. В этом случае дом имеет единственный шлюз DNG и единственную домашнюю сеть. Взаимодействие различных устройств в домашней сети и обмен этих устройств с провайдерами служб выполняется через DNG.

Множество домашних сетей показано на рисунке 5. В этом случае дом имеет несколько шлюзов DNG, каждый DNG имеет свою частную (отдельную) домашнюю сеть.

Рисунок 4 - Одиночная домашняя сеть

Рисунок 5 - Множество домашних сетей (сложная домашняя сеть)

5 Требования к открытию службы

5.1 Определение службы. Вводная часть

Процедура открытия службы при использовании двунаправленной IP сети использует механизмы SD&S, которые, кроме того, применяются для выбора службы и для поставки информации для поиска службы.

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

Настоящий стандарт определяет параметры следующих основных видов служб:

- "вещание медиа" (LMB);

- "контент по требованию" (CoD);

- "служба загрузки контента" (CDS).

Настоящий стандарт, кроме того, предусматривает две моды службы "вещания медиа" (LMB):

- "транспортный поток, полная SI" ("ТП полная SI");

- "транспортный поток, дополнительная SI" ("ТП дополнительная SI").

5.2 Механизм открытия службы

5.2.1 Открытие службы выполняется сцеплением (сочетанием) идентификатора провайдера службы и идентификатора службы.

Провайдер службы должен быть уникально и глобально идентифицирован именем домена в системе доменных имен (DNS).

Каждая служба может быть идентифицирована двумя способами:

- текстовым идентификатором, образуемым сцеплением имени службы (назначаемым провайдером служб) и глобально уникального доменного имени DNS провайдера службы;

- сочетанием трех числовых идентификаторов: original_network_id, transport_stream_id и service_id в соответствии с ETSI [9].

Синтаксис текстового идентификатора службы должен быть в соответствии с ETSI [10] (14.9).

5.2.2 Определены следующие типы информации, которые могут быть использованы в будущем:

- SD&S информация, касающаяся провайдера службы;

- четыре типа SD&S информации, касающейся предложения службы провайдера службы;

- запись открытия руководства по контенту вещания;

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

- встроенное ПО информации анонсирования, обеспечивающее обновление или изменение встроенного ПО HNED.

Эти типы информации охватывают различные типы служб, которые может предлагать SP. Предложение SP может включать службу "вещания медиа" ("ТП полная SI" или "ТП дополнительная SI") или “CoD”. SP может также предлагать ссылку на услуги, предоставляемые другим SP, или формировать пакет, в который группируется несколько служб с последующим представлением их как единственного объекта. Эти типы SD&S информации должны быть идентифицированы 8-битовым значением ID полезной нагрузки.

5.2.3 В таблице 1 представлены типы записей информации SD&S, которые могут использоваться для идентификации полезной нагрузки.

Таблица 1 - Типы записей информации SD&S, которые могут использоваться для идентификации полезной нагрузки

5.2.4 Записи SD&S полезной нагрузки должны быть сегментированы. Каждый сегмент должен быть сформированной и допустимой записью XML. ID сегмента должен иметь 16-битовое значение. Для определения текущей версии сегмента должно использоваться 8-битовое значение, которое должно увеличиваться с каждым изменением версии сегмента. Номер версии неизменяемого сегмента не должен изменяться. Записи, содержащие информацию для поиска SP (PayloadlD 0x01), не должны сегментироваться в режиме "получения информации по запросу" ("pull"). Во всех других случаях записи ХМL должны быть сегментированы. Запись может содержать единственный сегмент. Связь между сегментами, ID полезной нагрузки и записями представлена на рисунке 6. Детализированные правила разделения записей XML на сегменты должны быть в соответствии с ETSI [12] (приложение С, С.1.6).

Рисунок 6 - Связь между сегментами, ID полезной нагрузки и записями

5.2.5 Продолжительность передачи всех сегментов, составляющих полный комплект информации SD&S для провайдера, не должна превышать 30 с (максимальное время цикла).

5.2.6 Процедура открытия службы включает в себя открытие провайдеров служб, предлагающих услуги DVB-IPTV по сети IP, и открытие доступных служб каждого провайдера служб. Модель потоков данных поиска информации о службах приведена в приложении А.

Процедуры открытия службы иллюстрируются на рисунке 7.

Перечень этапов процедуры открытия службы включает в себя:

- поиск точки входа открытия службы;

Рисунок 7 - Процедуры открытия службы

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

- сбор информации для поиска службы DVB-IP для каждого провайдера службы.

5.2.7 Начальная загрузка процесса открытия службы выполняется определением точки входа информации SD&S для открытия. Точки входа SD&S могут быть получены при использовании:

а) группового адреса, зарегистрированного в IANA 224.0.23.14 (DvbServDisc);

б) списка SD&S адресов точек входа от сервера DNS согласно месту предоставления служб в соответствии с IETF [13].

Точки входа SD&S могут быть также получены при соединении оконечного устройства домашней сети с сетью для запроса ее собственного адреса (например, в случае DHCP), через опцию 15 DHCP.

Процесс поиска SD&S точки входа HNED рекомендуется выполнять в обратном порядке, начиная с пункта б). В случае, когда один из шагов обеспечивает получение, по крайней мере, одной точки входа, рекомендуется прекратить поиск новых точек. В том случае, если ни один из шагов поиска не обеспечил получение точки входа, поиск точки входа должен выполняться вручную. Детализированное описание процедур определения точек входа представлено в ETSI [12] (5.2.4).

5.2.8 На первом этапе процесса открытия службы выполняется открытие провайдера служб. При этом обеспечивается как открытие провайдеров, предлагающих в сети службы DVB-IPTV, так и сбор информации о расположении предложений различных провайдеров. Информация для поиска SP может быть передана в режиме многоадресной передачи информации ("push") или получена по запросу ("pull"). Сервер должен поддерживать один из двух режимов. Рекомендуется поддержка сервером двух режимов. Оба режима должны поддерживаться клиентом (пользователем). Допускается агрегатировать записи для открытия SP с целью минимизации количества записей.

Запись открытия провайдера служб должна переноситься в записи, содержащие атрибуты и элементы, представленные в ETSI [12] (таблица 2). Эти записи реализуют и информацию для поиска провайдера служб, и компоненты модели данных провайдера служб, представленные в приложении А.

5.2.9 Сбор информации для поиска службы DVB-IPTV выполняется использованием записи предложения DVB-IPTV служб и иллюстрируется моделью потоков данных поиска информации о службах в приложении А.

Запись предложения DVB-IP служб должна содержать поля в соответствии с таблицей 2, сопровождаемые полями фактических предложений провайдеров служб.

Таблица 2 - Запись предложения DVB-IPTV служб

5.2.10 Запись открытия служб формируется для следующих служб:

- "вещания медиа" (моды "ТП полная SI" или "ТП дополнительная SI");

- "контент по требованию" (CoD);

- предоставленных другими провайдерами служб (служба "от другого провайдера служб");

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

Модель открытия служб представлена в приложении А.

5.2.10.1 Запись открытия "вещания медиа" для моды "ТП полная SI" (тип XML BroadcastOffering) формируется из записей предложения DVB-IPTV служб. Эти записи предоставляют необходимую информацию для нахождения доступных служб "вещания медиа". Информация об индивидуальных службах получена из транспортного потока использованием информации, содержащейся в DVB-SI. Запись открытия "вещания медиа" должна включать атрибуты, представленные в таблице 2, и должна содержать поля, представленные в ETSI [12] (таблица 4). Процедура выполнения записи открытия "вещания медиа" для моды "ТП полная SI" иллюстрируется моделью потоков данных поиска информации о службах в приложении А.

5.2.10.2 Формирование записи открытия "вещания медиа" для моды "ТП дополнительная SI" из записей предложения DVB-IP выполняется аналогично изложенному в 5.2.6. Эта запись должна включать атрибуты, представленные в таблице 2, и должна содержать поля, представленные в ETSI [12] (таблица 5). Процедура выполнения записи открытия "вещания медиа" для моды "ТП дополнительная SI" иллюстрируется моделью потоков данных поиска информации о службах в приложении А.

5.2.10.3 Запись открытия службы "контент по требованию" должна включать атрибуты, представленные в таблице 2, и должна содержать поля, представленные в ETSI [12] (таблица 6). Процедура выполнения записи открытия службы "контент по требованию" иллюстрируется моделью потоков данных поиска информации о службах в приложении А.

5.2.10.4 Запись службы "от другого провайдера служб" должна включать все атрибуты, представленные в таблице 2, и должна содержать поля, представленные в ETSI [12] (таблица 7). Процедура выполнения записи открытия службы "от другого провайдера служб" иллюстрируется моделью потоков данных поиска информации о службах в приложении А.

5.2.10.5 Запись открытия "пакета служб" обеспечивает возможность комплектования набора служб для поставки в отдельном пакете. Запись открытия "пакета служб" содержит информацию для поиска пакета, включая идентификатор службы и описание расположения. Запись открытия "пакета служб" должна включать все атрибуты, представленные в таблице 2, и должна содержать поля, представленные в ETSI [12] (таблица 8). Процедура выполнения записи открытия службы "пакет служб" иллюстрируется на модели потоков данных поиска информации о службах в приложении А.

5.2.10.6 Запись руководства вещания контента обеспечивает возможность обнаружения расположения документов, содержащих перечисления доступного контента, например, в предложениях вещания через CoD или CDS. Обнаружение провайдера происходит использованием предложения услуги в соответствии с ETSI [11]. Запись руководства вещания контента выполняется в соответствии с ETSI [12] (5.2.6.6).

5.2.11 Открытие идентификатора соты, в которой расположено домашнее оконечное сетевое устройство, выполняется одновременным использованием кода страны и идентификатора соты. Этот идентификатор используется в элементе PackageAvailability в ETSI [12] (таблица 8) и элементе ServiceAvailability в ETSI [12] (таблицы 4 и 5), что позволяет указать, какой пакет и какие службы могут быть получены домашним оконечным сетевым устройством.

HNED получает данные о своем расположении от сервера DHCP использованием опции GEOCONF_CIVIC, код 99 в соответствии с IETF [14], ETSI [12] (8.1.1.11). HNED может получить ID соты следующими способами:

- запросом на сервер URI в режиме "pull", в соответствии с ETSI [12] (5.2.6.7.1).

- через запись открытия районирования - в режиме "push", в соответствии с ETSI [12] (5.2.6.7.1).

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

Процедура выполнения записи открытия ID сот иллюстрируется на модели потоков данных поиска информации о службах в приложении А.

Детализированные процедуры открытия ID сот должны быть в соответствии с ETSI [12] (5.2.6.7).

5.2.12 Информация о службах FUS и RMS, доступных HNED, может быть получена применением процедур SD&S (опционально) при использовании данных (точек входа) о расположении этих служб.

В случае FUS необходимое расположение точек входа служб FUS и RMS определяется:

- при многоадресной передаче - в режиме "push";

- при одноадресной передаче при соединении со службами анонсирования - в режиме "pull".

В обоих случаях HNED использует канал QRC для запроса FUS.

В случае RMS для HNED требуется только канал управления, являющийся одноадресной службой.

Детализированные процедуры выполнения записи информации о сервисах FUS и RMS должны быть в соответствии с ETSI [12] (5.2.6.8).

5.3 Выбор службы

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

- протокола IGMP;

- протокола RTSP.

Службы "вещания медиа" при многоадресной передаче IP передаются непрерывным потоком. Их передача не должна инициироваться каждым домашним сетевым оконечным устройством. Отдельные HNED могут присоединиться к службам "вещания медиа", формируя запросы о присоединении к многоадресным службам, выпуская соответствующие сообщения IGMP. Элемент "Service Location" в записях открытия службы содержит всю информацию, необходимую для формирования соответствующего сообщения IGMP. Однако HNED не получает возможности управления потоком (например, типа "пауза" или "ускоренная перемотка").

Опционально: Провайдеры служб могут требовать непосредственного участия HNED в этапах набора и разъединения со службами "вещания медиа" (возможными причинами таких требований могут быть: необходимость учета поставляемых услуг, необходимость обслуживания условного доступа и т.д.). В таких случаях должен использоваться протокол сеанса RTSP согласно IETF [15]. Элемент "Service Location" в записи открытия службы сигнализирует об использовании протокола RTSP и дает информацию, необходимую для запуска соответствующего метода RTSP.

Параметры для сообщения IGMP будут получены от RTSP методом SETUP.

5.3.2 Служба "вещания медиа с режимом Trick" (MBwTM) аналогична службе "вещания медиа", но использует режим одноадресной передачи IP, обеспечивающий возможность управления потоком.

5.3.3 Службы "контент по требованию" и "вещание медиа с режимом Trick" используют одноадресную передачу IP, они предназначены для конкретного пользователя и должны инициироваться конкретным HNED. Для получения доступа к таким службам должен использоваться протокол RTSP. Раздел 6 настоящего стандарта определяет параметры используемых методов RTSP.

5.3.4 Выбор параметров службы для CDS рассмотрен в разделе 10 настоящего стандарта.

5.4 Механизм передачи информации для поиска провайдера служб и открытия службы

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

- многоадресной передачи;

- одноадресной передачи.

Для доставки записей XML при многоадресной передаче используется транспортный протокол DVBSTP механизма DVB SD&S. Параметры протокола DVBSTP определены в 5.4.2 настоящего стандарта.

При одноадресной передаче информации SD&S должен использоваться протокол HTTP в соответствии с IETF [16].

5.4.2 В тех случаях, когда информация для доставки информации SD&S с целью поиска службы передается с использованием многоадресного пакета протокола UDP, должен применяться транспортный протокол DVBSTP.

Протокол DVBSTP используется также для многоадресной доставки данных руководства по контенту вещания согласно ETSI [11], для многоадресной доставки сообщений анонсирования встроенных программных обеспечений (ПО) ETSI [17] и для многоадресной доставки описаний сеанса загрузки XML CDS, как определено в разделе ETSI [12] (10.4.2). Схема URI DVBSTP представлена в приложении Б.

5.4.3 Синтаксис многоадресного протокола доставки DVBSTP представлен на рисунке 8.

Рисунок 8 - Синтаксис многоадресного протокола доставки DVBSTP

5.4.3.1 Семантика многоадресного протокола доставки DVBSTP:

- Ver (Protocol Version): поле "Версия протокола", 2 бита. Поле "Версия протокола" должно иметь значение "00";

- Resrv (Reserved): поле "Резерв", 3 бита. Поле "Резерв" должно иметь значение "000";

- Enc (Encryption): поле "Шифрование", 2 бита. Поле "Шифрование" должно использоваться для сигнализации о присутствии процедуры шифрования полезной нагрузки. Значение "00" указывает, что полезная нагрузка не зашифрована. Синтаксис, семантика, поведение и другие значения не определены;

- С (CRC flag): поле "Флаг CRC", 1 бит. Значение поля "Флаг CRC" "1", указывает на присутствие 32-разрядного CRC в конце пакета. Этот флаг может быть установлен в заключительном пакете сегмента, когда section_number соответствует last_section_number;

- Total_segment_size: поле "Полный размер сегмента", 24 бита. Поле определяет размер сегмента в байтах. Для некомпрессированных данных (поле Compression "000"), это поле определяет совокупный размер всех полезных нагрузок всех секций, включенных в сегмент (без заголовков и полей CRC, если они присутствуют). Для компрессированных данных, например BiM, это поле определяет совокупный размер всех полезных нагрузок всех секций согласно 5.4.3.2.1 настоящего стандарта, включенных в сегмент (без заголовков и полей CRC, если они присутствуют), - это поле называется "переданный размер" ("transmitted size"). Для компрессированных данных, которые должны быть распакованы перед использованием (например, zlib), это поле определяет размер сегмента, однажды распакованного указанным алгоритмом (отмечают, что это, возможно, не тот же самый размер, какой имел исходный XML), - это поле называется "декомпрессированный размер" ("decompressed size"). Определение значения компрессированного поля должно указывать, какой должна быть интерпретация полного размера сегмента;

- Payload ID: поле "ID полезной нагрузки", 8 битов. Поле идентифицирует тип данных, перенесенных в пределах полезной нагрузки. Значения типов данных приведены в таблице 1;

- Segment ID: поле "ID сегмента", 16 битов. Поле идентифицирует сегмент данных для объявленного типа полезной нагрузки (РТ). В случае многократных записей информации для открытия вещания каждой записи будет присвоен уникальный ID;

- Segment_Version: поле "Версия сегмента", 8 битов. Поле определяет текущую версию сегмента, находящегося в процессе переноса. Поле включает ID полезной нагрузки вместе с ID сегмента. Максимальный размер поля составляет 256, и после заполнения поля подсчет начинается сначала. Версия сегмента должна изменяться только в начале сегмента. Однако для обработки функции потери пакетов приемник должен проверять изменение версии сегмента в любой точке сегмента;

- Section_Number: поле "Количество секций", 12 битов. Поле идентифицирует количество секций в сегменте. Номер первой секции в сегменте должен быть 0;

- Last Section number: поле "Номер последней секции", 12 битов. Поле "Номер последней секции" определяет номер последней секции (с самым высоким номером в Поле количество секций) в сегменте;

- Compr (Compression): поле "Компрессия", 3 бита. Поле "Компрессия" указывает на схему компрессии полезной нагрузки (если компрессия применяется). Все сегменты данного ID полезной нагрузки должны совместно использовать одно и то же значение компрессии. Значения компрессии представлены в ETSI [12] (таблица 12). Компрессия GZIP доступна только с ID полезной нагрузки 0x08 для использования с RMS/FUS или с ID полезной нагрузки 0x07 с информационной записью районирования;

- P (ProviderlD Flag): поле "Флаг providerlD", 1 бит. Значение поля "1" означает присутствие в заголовке поля ServiceProviderlD;

- HDR_LEN (Private Header Length): поле "Длина частного заголовка", 4 бита. Поле показывает количество слов по 32 бита. Поле используется для сигнализации о присутствии данных частного заголовка. При отсутствии дополнительных данных заголовка у этого поля должно быть значение "0000". Поле ID провайдера не рассматривается как часть частного заголовка и не учитывается полем Private Header Length;

- ServiceProvider ID: поле "ID провайдера служб", 32 бита. Поле используется для идентификации провайдера служб. Это число должно быть адресом IPv4, в соответствии с детализацией в 5.4.3.2 настоящего стандарта. Провайдер служб обязан гарантировать, что этот адрес сохраняется соответствующими органами и его уникальное значение используется в пределах контекста. Поле предназначено только для использования HNED, а не для сетевой фильтрации. Использование поля обязательно, если провайдер знает, что другие провайдеры не могут использовать этот же самый multicast адрес;

- Private Header Data: поле "Частные данные заголовка", опциональное. Это поле частных данных. Значение, синтаксис, семантика и правила использования этих данных настоящим стандартом не определяются;

- Payload: поле "Полезная нагрузка". Размер пакета поля может быть определен из размера полученного пакета минус размер заголовка (включая опциональное поле ProviderlD (если оно существует) и любые опциональные частные существующие данные заголовка) и CRC (если оно существует). Полезная нагрузка может содержать нулевые байты;

- CRC: поле "CRC", опциональное, 32 бита. В поле CRC должен использоваться стандартный CRC в соответствии с ISO/IEC [18] (приложение A). CRC должен быть применен к данным полезной нагрузки всех секций, включенных в сегмент. Граница этого поля не должна выравниваться до 32 битов.

5.4.3.2 Уточнения параметров секций и полей

5.4.3.2.1 Допускается разделение сегментов протокола UDP на секции. Каждая секция должна точно соответствовать одной дейтаграмме UDP. Каждая дейтаграмма UDP должна точно соответствовать одной секции. Для сборки всего сегмента HNED должен собирать полезную нагрузку всех секций. Упорядочивание секций выполняется с использованием номеров секций. После сборки сегмента может выполняться проверка CRC. На рисунке 9 показана взаимосвязь между записями, сегментами и секциями.

Рисунок 9 - Взаимосвязь между секциями, сегментами и записями

5.4.3.2.2 Объем данных, который может инкапсулироваться в каждом пакете UDP (и, следовательно, в секции), ограничен максимальным размером дейтаграммы IP (65535 байтов для IPv4) минус размер заголовка UDP. С целью устранения возможной сетевой фрагментации рекомендуется устанавливать максимальный размер дейтаграммы (секции) таким, что бы он не превышал размера максимального модуля передачи (MTU), равного 1452 байта. При использовании дополнительных IP, UDP или многоадресных версий протокола это значение должно быть соответствующим образом уменьшено.

Если размер секции установлен таким, что фрагментация происходит, любые конечные устройства, которые не поддерживают фрагментацию, не смогут получить полезную нагрузку SD&S. Поэтому рекомендуется системным провайдерам в заголовке IP устанавливать сообщение DF ("Не фрагментируйте"). При получении такого сообщения (если длина секции превысит установленный MTU сети) маршрутизаторы возвратят сообщение ICMP "необходима фрагментация, но установлен флаг ее запрета (DF)". При получении таких сообщений системный провайдер может скорректировать размер полезной нагрузки.

В соответствии со стандартом IETF [19] все хосты (узлы отправителя и получателя) должны обеспечивать прием дейтаграмм размером 576 байтов.

5.4.3.2.3 Использование поля ProviderlD позволяет HNED фильтровать пакеты, не распаковывая их. Рекомендуется использовать поле ProviderlD только с записями открытия провайдера служб, когда PayloadID - 0x01, так как процесс открытия гарантирует получение только многоадресных адресов.

5.4.3.2.4 Значение частоты повторения всех сегментов SD&S записи для провайдера служб не должно приводить к превышению максимального времени цикла 30 с, определенного в 5.2.5 настоящего стандарта.

5.4.4 Протокол для одноадресной поставки информации SD&S

При поставке информации SD&S в режиме "pull" для передачи данных между HNED и серверами SD&S должен использоваться протокол HTTP в соответствии с IETF [16]. При запросе домашним сетевым оконечным устройством информации SD&S, HNED должен использовать следующий формат:

' GET /dvb/sdns ' request ' HTTP/1.1' CRLF

' Host: ' host CRLF,

где request=sp_discovery_request/service_discovery_request.

<request> используется для идентификации конкретного типа запроса. Предусмотрены два типа запроса:

- sp_discovery_request для запроса информации для поиска провайдера служб;

- service_discovery_request для запроса информации для поиска предложения службы провайдера служб.

Для запроса sp_discovery_request <хост> имеет IP-адрес сервера SD&S, полученного в соответствии с 5.2.7 настоящего стандарта.

Для запроса service_discovery_request <хост> имеет адрес, определенный в поле "Location of the SP Discovery Record" в соответствии с 5.2.8.

Запрос может содержать другие поля заголовка, соответствующие IETF [16].

Детализированное описание применения протокола для одноадресной поставки информации SD&S должно быть в соответствии с ETSI [12] (5.4.2).

5.4.4.1 По запросу открытия провайдера служб sp_discovery_request на HNED должна возвратиться запись открытия провайдера служб в соответствии с 5.2.8 настоящего стандарта (для одного или всех провайдеров служб, работающих на сеть). Один из параметров запроса может принять значение ALL для запроса информации для поиска всех провайдеров служб или доменного имени определенного провайдера служб с целью последующего запроса информации для поиска провайдера. В режиме "pull" записи, содержащие информацию для поиска провайдера служб (т.е. ID полезной нагрузки 0x01), не должны сегментироваться.

Форматы записей открытия должны быть в соответствии с ETSI [12] (5.4.2.1).

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

5.4.4.2 По запросу открытия службы service_discovery_request на HNED должна возвратиться запись открытия службы, как определено в 5.2.9 настоящего стандарта, содержащая описание службы, предлагаемой конкретным провайдером служб. В состав запроса входят три обязательных параметра:

- доменное имя провайдера служб;

- тип предлагаемой службы (ID полезной нагрузки);

- ID сегмента.

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

Детализированная процедура обмена сообщениями между HNED и сервером по запросу HNED открытия службы service_discovery_request должна быть в соответствии с ETSI [12] (5.4.2.2).

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

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

В случае, когда список сегментов дан в записи открытия провайдера (обязательный в режиме "pull" и опциональный в режиме "push") HNED должно обнаруживать дополнение или удаление сегментов с учетом перечня ID, допустимых для провайдера сегментов.

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

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

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

5.5.1 Допускается кодирование сегментов SD&S в формате BiM согласно ISO/IEC [20]. Однако сетевой провайдер должен обеспечивать доступность для HNED, не имеющих реализации BiM, получение незакодированных сегментов SD&S в режиме "pull" или "push" или обоих режимах.

5.5.2 Требования к параметрам формата BiM при кодировании сегментов SD&S и к параметрам кодека BiM должны быть в соответствии с ETSI [12] (5.5.2).

6 Протокол RTSP

6.1 Использование протокола RTSP для служб DVB

6.1.1 В этом подразделе определяются возможности использования для HNED потокового протокола реального времени (RTSP) при воспроизведении служб DVB. Возможности использования HNED для записи служб DVB не нормируются.

RTSP является протоколом уровня приложения для управления доставкой данных в реальном времени. Предусматривается использование протокола RTSP для двух случаев:

- для служб "вещания медиа";

- для служб "видео по требованию".

6.1.2 В соответствии с разделом 5 настоящего стандарта доступ HNED к необходимой информации запрашиваемой службы обеспечивается средствами протокола RTSP. В зависимости от количества потоков, образующих службу, в записях SD&S могут использоваться множественные URL RTSP в следующих случаях:

- если URL управления присутствует для потоков FEC, то агрегатный URL /BroadcastDiscovery/ServiceList/SingleService/ServiceLocation/RTSPURL применяется для всей службы за исключением потока повторной передачи. В тех случаях, когда служба образована единственным потоком, этот URL используется для всех сообщений RTSP: SETUP (запрос установки транспортного механизма для медиа-контента), PLAY (запрос начала вещания контента), TEARDOWN (остановка потока и освобождение ресурсов). В любом случае, при необходимости извлечения описания, этот URL должен использоваться для передачи сообщения DESCRIBE (запрос описания контента);

- URL управления используются в тех случаях, когда служба образуется несколькими потоками. URL используются для передачи сообщений SETUP для каждого потока в отдельности. URL могут использоваться при необходимости для управления каждым потоком в отдельности, формированием сообщений PLAY, PAUSE (запрос временной остановки вещания). Используются следующие URL управления:

- RTSPURL@RTSPControlURL - для управления основным потоком аудио-видео;

- FECBaseLayer@RTSPControlURL - для управления потоком базового уровня FEC;

- FECEnhancementLayer@RTSPControlURL - для управления потока улучшенного уровня FEC;

- UnicastRET@RTSPControlURL - для сообщений управления RTSP (SETUP) при одноадресной передаче потока RET.

В тех случаях, когда служба использует повторную передачу (поток RET) или AL-FEC, при установке сеанса может возникнуть необходимость получения дополнительной информации описания сеанса в соответствии с 6.3.2 настоящего стандарта.

6.1.3 Транспорт сеанса. Оконечные устройства домашней сети, совместимые с DVB, с целью обмена сообщениями RTSP с сервером RTSP должны использовать постоянное (персистентное) соединение TCP. Использование персистентного соединения TCP обеспечивает надежный транспорт данных между сервером RTSP и HNED, который находится позади межсетевого экрана (МЭ). Персистентные соединения TCP согласно IETF [16] применяются, как правило, для того, чтобы исключить использование отдельного транспортного соединения для каждой транзакции запроса/ответа. Применение персистентных соединений полезно в тех случаях, когда, например, сервер намеревается передать к HNED асинхронные сообщения ANNOUNCE RTSP (методы RTSP для одноадресного режима доставки представлены в таблице 3). Мультимедийные потоки, инкапсулированные (как описано в разделе 7 настоящего стандарта) и управляемые сервером RTSP, могут быть переданы в режимах одноадресной или многоадресной передачи. В многоадресном режиме Trick такие операции, как "пауза", "ускоренная перемотка" и подобные им операции, не могут быть выполнены.

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

В возможных случаях сервер RTSP может асинхронно отправить HNED информацию о службе при использовании метода ANNOUNC (анонсирования) (таблица 3). Альтернативно HNED может передать серверу запрос (при использовании метода DESCRIBE (таблица 3)), проверки, обновления информации о службе. Этот прием может применяться, например, в случае использования кратковременного соединения между HNED и сервером RTSP.

Детализированные условия формирования информации о службах при использовании для служб LMB, CoD и MBwTM должны быть в соответствии с ETSI [12] (6.1.3).

6.1.5 Настоящий стандарт использует меры безопасности, предусмотренные в протоколах RTSP и HTTP. Дополнительные параметры безопасности и аутентификации для DVB-IPTV в настоящем стандарте не устанавливаются.

6.2 Профили протокола RTSP

6.2.1 Настоящий стандарт предусматривает применение следующих трех профилей протокола RTSP:

- "вещание медиа" (LMB);

- "вещание медиа с модой Trick" (MBwTM);

- "контент по требованию" (CoD).

Каждый профиль RTSP содержит подмножество методов и заголовков, определенных протоколом RTSP.

6.2.2 Профиль RTSP "вещание медиа" является эквивалентом традиционного телевизионного вещания и радиовещания. Потоки медиа доставляются пользователям в многоадресном режиме.

6.2.3 Профиль RTSP "вещание медиа с модой Trick" является эквивалентом традиционного телевизионного вещания и радиовещания с поддержкой таких операций режимом Trick, как "пауза", "ускоренная перемотка" и других подобных им операций. Поэтому потоки медиа профиля RTSP "вещание медиа с режимом Trick" доставляются только в одноадресном режиме.

6.2.4 Профиль RTSP "контент по требованию" в дополнение к возможностям профиля RTSP "вещание медиа с режимом Trick" обеспечивает возможность инициировать операции "старт" (и "остановка") доставки, представляемые как независимые события. Это означает, что этот профиль поддерживает "паузу", "ускоренную перемотку" и подобные им операции, а также возможность получить доступ к медиа на время по выбору пользователей. Поэтому потоки медиа профиля RTSP "контент по требованию" доставляются только в одноадресном режиме передачи.

6.3 Методы RTSP

6.3.1 В таблице 3 представлены методы протокола RTSP, которые поддерживают интерфейс IPI-1 для одноадресного режима доставки для профилей RTSP MBwTM и CoD.

Таблица 3 - Методы RTSP для одноадресного режима доставки

6.3.2 Использование методов RTSP

6.3.2.1 Метод ANNOUNCE может использоваться для асинхронного обновления в HNED информации о службе. Например, для того, чтобы обновить имя службы "вещание медиа", клиент RTSP DVB обязан поддерживать прием описаний в формате XML. Для профилей вещания ("вещание медиа" и "вещание медиа с модой Trick") метод ANNOUNCE должен содержать структуру комплекса XML BroadcastOffering в соответствии с ETSI [12] (приложение С, С.1.4.2) и описанной в 5.2.10 настоящего стандарта. Тип MIME в заголовке Content-Type согласно ETSI [12] (таблица 16) должен быть text/xml, заголовок Content-Encoding и XML должны кодироваться, используя UTF-8.

В таблице 4 представлена информация для методов протокола RTSP ANNOUNCE и DESCRIBE.

Таблица 4 - Информация для методов протокола RTSP ANNOUNCE и DESCRIBE

Опционально: Клиент RTSP DVB, поддерживающий повторную передачу в соответствии с приложением В, должен понимать описания сеанса в формате SDP согласно IETF [23]. Описание типа MIME протокола SDP application/sdp и описание SDP должны использовать формат UTF-8. HNED может включать application/sdp в Accept Header для того, чтобы явно указать на поддержку SDP. Ниже описаны методы RTSP.

6.3.2.2 При методе DESCRIBE клиент RTSP DVB должен поддерживать прием описаний в формате XML аналогично методу ANNOUNCE, описанному в 6.3.2.1 настоящего стандарта. Тип MIME для XML-описаний должен text/xml, формат XML описания должен быть UTF-8. HNED должен всегда включать text/xml при использовании заголовка Accept.

Клиент RTSP DVB, поддерживающий повторную передачу в соответствии с приложением В настоящего стандарта, должен понимать описания сеанса в формате SDP IETF [23]. Тип MIME описаний SDP application/sdp и само описание SDP используют UTF-8. Допускается включение HNED application/sdp в Accept Header, чтобы указать на явную поддержку протокола SDP.

6.3.2.3 Метод GET_PARAMETER (запрос указанных параметров у сервера). Тип MIME в заголовке Content-Type или ответе Content-Type при использовании метода GET_PARAMETER должен быть text/parameters; контент в заголовке Content-Encoding должен быть выполнен в формате UTF-8. Синтаксис и минимальный набор параметров GET_PARAMETER, которые должны поддерживаться интерфейсом IPI-1, должны быть в соответствии с ETSI [12] (6.3.1.3).

6.3.2.4 Метод SETUP (запрос установки транспортного механизма для медиа-контента). HNED не должен передавать запрос SETUP для того потока или мультимедийного сеанса, для которого будет предаваться запрос TEARDOWN.

6.3.3 Заголовки полей RTSP

6.3.3.1 Рекомендуемый перечень полей заголовков RTSP, генерируемых HNED, должен быть в соответствии с ETSI [12] (таблица 16).

Рекомендуемый перечень полей заголовков RTSP, анализируемых и понимаемых HNED, должен быть в соответствии с ETSI [12] (таблица 17).

При прямой инкапсуляции UDP (без применения RTP) параметры "transport-protocol/profile/lower-transport" транспортного заголовка RTSP "Transport" должны принимать значения:

- MP2T/H2221/UDP;

- RAW/RAW/UDP.

6.4 Состояния кодов в ответах на запросы

Состояния кодов в ответах на запросы протокола RTSP, которые HNED должны интерпретировать, должны быть в соответствии с ETSI [12] (таблица 18).

6.5 Использование RTSP при многоадресной передаче

Допускается использование протокола RTSP для присоединения HNED к многоадресному вещанию медиа. Детализированные условия присоединения и возможности присоединения HNED к многоадресному вещанию медиа при использовании протокола RTSP должны быть в соответствии с ETSI [12] (6.5).

7 Передача транспортного потока MPEG-2 для служб в реальном времени

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

Раздел касается поставки служб DVB "вещание медиа" и "CoD" по сетям IP, описанным в разделе 4 настоящего стандарта. В разделе рассматриваются вопросы, касающиеся инкапсуляции транспортного потока, требований к сети IP, инициирования служб и управления службами. Передача ТП MPEG-2 для службы загрузки контента (CDS) (нереального времени) рассмотрена в разделе 10 настоящего стандарта.

7.2 Инкапсуляция транспортного потока MPEG-2

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

Должна обеспечиваться инкапсуляция однопрограммного транспортного потока или многопрограммного транспортного потока MPEG-2, соответствующих требованиям ETSI [24]. Транспортные потоки, содержащие множество ссылок PCR, должны быть потоками с постоянной скоростью передачи. Транспортные потоки, содержащие единственную ссылку PCR, могут иметь как постоянную, так и переменную скорость передачи.

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

Все транспортные потоки, совместимые с ETSI [24], должны инкапсулироваться в протоколы:

- RTP (транспортный протокол реального времени), соответствующий требованиям IETF [25] в соединении с IETF [26];

- UDP (протокол пользовательских дейтаграмм) согласно Рекомендации ITU-T 10 [27].

7.2.2 Инкапсуляция ТП в транспортный протокол реального времени (RTP)

Пакет протокола RTP включает в свой состав заголовок, расширение заголовка переменной длины (необязательное) и поле данных.

Протокол RTP всегда использует четный номер порта UDP.

Каждый пакет IP в соответствии с IETF [19] включает в себя стандартный заголовок IP, заголовок UDP, заголовок RTP и целое число n пакетов транспортного потока MPEG-2 по 188 байтов.

Минимальный формат пакета IP (IPv4) показан на рисунке 10.

Рисунок 10 - Минимальный формат пакета IP (IPv4)

Формат заголовка протокола RTP представлен на рисунке 11.

Рисунок 11 - Формат заголовка протокола RTP

7.2.2.1 Семантика протокола RTP:

- V (RTP Version (2)): поле "Версия", 2 бита. Содержит номер версии протокола RTP (оконечное оборудование поддерживает действующую версию 2 протокола RTP);

- Р (Padding): поле "Признак дополнения пакета незначащими байтами", 1 бит. В поле устанавливается "1", если длина пакета выровнена с помощью незначащих байтов;

- X (Extended Header): поле "Флаг наличия дополнительного заголовка", 1 бит. Поле устанавливается в "1" при наличии дополнительного заголовка. Дополнительный заголовок служит для передачи специальной информации пользователя;

- CSRC count: поле "Количество идентификаторов CSRC", 4 бита. Поле указывает количество объединяемых потоков RTP;

- М (Marker): поле "Маркер", 1 бит. Значение поля зависит от типа полезной нагрузки и используется, например, для указания границ потока данных. В случае видео он указывает на конец кадра. В случае аудио он указывает на начало кадра аудио после периода молчания;

- Payload Туре (РТ): поле "Тип данных поля полезной нагрузки", 7 битов. Поле идентифицирует вид информации, передаваемой в пакете RTP (аудио, видео), и формат данных, включая сжатие и шифрование. В поле РТ должно быть установлено МР2Т (33), в соответствии с IETF [28] (раздел 7);

- Sequence Number: поле "Значение порядка следования пакетов", 16 битов. Начальное значение поля определяется случайным образом. Значение поля увеличивается на единицу при передаче очередного пакета данных RTP. При достижении значения FFFFh поле обнуляется. Поле используется для восстановления исходной последовательности пакетов, удаления копий пакетов и определения потерянных пакетов;

- Timestamp: поле "Счетчик времени (метка времени)", 32 бита. Поле указывает момент отсчета первого байта в пакете данных RTP и представляет собой число, отсчитываемое в периодах частоты 90 кГц, которое может быть привязано к PCR одной из программ. Требования к точности этих часов не соответствуют точности системных часов MPEG-2, определенных в ISO/IEC [18];

- Synchronization Source (SSRC): поле "Идентификатор источника синхронизации", 32 бита. Идентифицирует потоки RTP, принадлежащие одному вызову. Этот идентификатор должен выбираться случайным образом, обеспечивающем отсутствие одинаковых идентификаторов для двух источников синхронизации на интервале одного сеанса RTP. Пример алгоритма формирования случайного идентификатора представлен в стандарте IETF [25] (приложение 6). В том случае, если источник синхронизации изменяет свой исходный транспортный адрес, он должен также выбрать новый идентификатор SSRC;

- Contributing Source (CSRC): поле "Список идентификаторов CSRC" (длина поля переменная, включает от 0 до 15 субполей (элементов), по 32 бита. Поле "Список идентификаторов CSRC" содержит перечень источников потоков RTP. Идентификаторы CSRC вставлены миксером, используя идентификаторы SSRC тех источников, которые участвовали в создании данного пакета RTP. Поля CSRC являются опциональными. Они должны игнорироваться оконечным устройством.

7.2.2.2 Управляющий протокол RTCP используется совместно с протоколом RTP для периодической передачи пакетов управления. Протокол RTCP выполняет четыре основные функции:

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

- поддерживает устойчивый идентификатор источника данных RTP на транспортном уровне, используя каноническое имя CNAME;

- позволяет масштабировать число участников обмена протоколом RTP регулированием частоты передачи пакетов в зависимости от числа участников;

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

Для передачи информации управления предусмотрены следующие типы пакетов RTCP:

- SR - отчет отправителя, содержит статистическую информацию о передаче и приеме участников, которые являются активными отправителями;

- RR - отчет получателя, содержит статистическую информацию о приеме от участников, которые не являются активными отправителями;

- SDES - элементы описания источника, включая CNAME;

- BYE - указатель завершения соединения.

В контексте задач передачи транспортных потоков служб DVB по сетям с IP протоколами использование пакетов SR и RR является обязательным.

В том случае, когда HNED должно декодировать разные транспортные потоки одновременно (например, "картинка в картинке"), должна обеспечиваться синхронизация этих транспортных потоков, учитывая, что некоторые потоки синхронизированы от независимых часов с произвольными значениями времени. С этой целью в отчете отправителя передаются метки времени RTP и метки времени NTP. Метки времени RTP определяются источником часов RTP. Метки времени NTP определяются временем по сетевому протоколу времени (NTP) согласно IETF [29]. Эти метки в отчете отправителя позволяют HNED вычислять необходимое смещение времени транспортных потоков, чтобы обеспечить их синхронизацию.

7.2.3 Инкапсуляция ТП непосредственно (прямая инкапсуляция) в пакеты прямого пользовательского протокола дейтаграммы (UDP)

В том случае, если сети IP могут обеспечить малые значения потерь пакетов, малые значения дрожания пакетов и отсутствие изменений порядка следования пакетов, транспортный поток может инкапсулироваться непосредственно в пакеты протокола UDP в соответствии с Рекомендацией ITU-T [27]. Формат пакета IP (IPv4) UDP показан на рисунке 12.

Рисунок 12 - Формат пакета IP (IPv4) UDP

Каждый пакет IP включает в себя заголовок IP, заголовок UDP и целое число пакетов n по 188 байтов транспортного потока MPEG 2. Количества пакетов транспортного потока, содержащихся в каждом пакете UDP, определяется полем длины в заголовке UDP.

Пакеты нескольких транспортных потоков, которые могут инкапсулироваться в каждом пакете IP, ограничены максимальным размером дейтаграммы MTU (65535 байтов для IPv4). Не должно допускаться превышение MTU сети. Превышение MTU сети приведет к фрагментации IP, которая значительно увеличивает эффективную частоту потерь сети. Это обусловлено тем, что при потере одного фрагмента остающиеся фрагменты должны быть отброшены приемником. Это создает дополнительную загрузку маршрутизаторов, выполняющих фрагментацию и в конце системы повторно собирающих фрагменты. Для любой сети, использующей технологию Ethernet с MTU 1492 байта (кадр в соответствии IEEE [30] с LLC) или 1500 байтов (кадр в соответствии IEEE 802.3 [30], [31] без LLC), количество пакетов MPEG на IP пакет должно быть не более семи (из условия обеспечения максимальной длины пакета не более 1356 байтов). Рекомендуется использовать в пакете IP меньше семи пакетов MPEG, чтобы не превышать MTU. Протокол IP согласно IETF [19] требует, чтобы хосты обеспечивали обработку дейтаграмм не менее 576 байтов.

7.2.4 Обнаружение и использование инкапсуляции в протокол RTP и прямой инкапсуляции в протокол UDP

Сигнализацию об использовании протокола RTP или UDP выполняет служба SD&S (5.2.10 настоящего стандарта) при многоадресной передаче и протокол RTSP (6.3.3 настоящего стандарта) при одноадресной потоковой передаче. Кроме того, обнаружить использование RTP или прямого UDP инкапсуляции можно поиском значения 0x47 в первом байте после заголовка UDP. В случае прямой инкапсуляции UDP это - первый байт 188-байтового пакета ТП MPEG-2, который всегда имеет значение 0x47 (байт синхронизации заголовка транспортного потока). В случае инкапсуляции RTP это - первый байт заголовка RTP, значение которого всегда отличается от 0x47. Таким образом, в случае, если у первого байта есть значение 0x47 - используется прямая инкапсуляция UDP, если у первого байта есть какое-либо другое значение, тогда используется инкапсуляция RTP.

7.2.5 Встроенная информация о службе (SI)

Для транспортных потоков "ТП дополнительная SI" все таблицы MPEG-2 в соответствии ISO/IEC [18] и ETSI [9], кроме требуемых ETSI [24], являются опциональными.

Транспортные потоки "ТП полная SI" должны соответствовать требованиям ETSI [9], [32] и должны содержать все необходимые DVB SI за исключением таблицы информации о сети NIT.

7.3 Требования к сети IP

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

7.3.1.1 Джиттер пакетов должен определяться как изменение задержки при передаче пакета от источника потока до HNED. Пиковое значение джиттера J (от пика до пика) не должно превышать 40 мс. При этом подразумевается, что величина отклонения сетевой задержки d находится в интервале значений J/2+J/2.

Это означает, что HNED должно устойчиво функционировать при значениях 20 мс в соответствии с ISO/IEC [33].

7.3.1.2 Использование устройством HNED прямого пользовательского протокола дейтаграммы (UDP) допускается в том случае, если сеть не вносит изменения в порядок следования пакетов.

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

7.3.2.1 Необходимое качество приема пакетов устанавливается исходя из допустимости появления не более одного артефакта в час. Такое качество приема обеспечивается при коэффициенте ошибок пакетов не более 110 для транспортного потока со скоростью 4 Мбит/с с семью транспортными пакетами на пакет IP.

При использовании AL-FEC или RET в соответствии с ETSI [12] (приложение Е) и приложением В настоящего стандарта допустимый коэффициент ошибок пакетов может быть значительно увеличен.

7.3.2.2 При многоадресной передаче максимальные значения интервалов "Времени присоединения" (JOIN time) к многоадресным группам" и "Времени выхода" (LEAVE time) из многоадресных групп не должны превышать 500 мс.

"Время присоединения" определяется как интервал времени между передачей запроса протокола IGMP от оконечного устройства на присоединение к многоадресной передаче и приемом первого пакета транспортного потока оконечным устройством.

"Время выхода" определяется как интервал времени между передачей запроса протокола IGMP от оконечного устройства на выход из многоадресной передачи и получением соответствующего пакета потока, связанного с передачей этого запроса.

7.4 Инициирование службы и управление службами

7.4.1 Настоящий стандарт нормирует правила и параметры доставки служб DVB для одного из двух вариантов доставки (поставки):

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

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

7.4.2 Многоадресное распределение потоков выполняется для оконечных устройств, сигнализирующих об ожидании получения потока. Эта сигнализация обеспечивается использованием управления по протоколу IGMP. Интерфейс IPI-1 должен поддерживать версию 3 протокола IGMP в соответствии с IETF [34].

Для получения службы HNED должно выполнить "групповое присоединение" согласно IGMPv3. "Групповое присоединение" должно содержать список допустимых исходных адресов, представляемых механизмом "Открытия Службы".

Для завершения приема службы HNED должно выполнить "групповой выход" в соответствии с IGMPv3.

7.4.3 Одноадресные службы должны инициироваться и управляться использованием профиля DVB протокола потоковой передачи реального времени (RTSP) в соответствии с разделом 6 настоящего стандарта.

7.5 Качество службы

Для обеспечения необходимого качества службы транспортным потокам MPEG-2 должны быть присвоены "типы трафика" передачи видео в реальном времени в соответствии с разделом 11 настоящего стандарта.

8 Распределение IP адресов и сетевые службы времени

8.1 Адресация IP и маршрутизация

8.1.1 HNED присваивается один адрес IP на интерфейс от сервера DHCP. Сервер DHCP может предоставить дополнительную информацию, которая детализирована в 8.1.4.

Для HNED должна применяться только динамическая адресация в том случае, когда она назначается автоматически при подключении устройства к сети и используется в течение ограниченного промежутка времени. Адрес IP, маска подсети, адреса сервера DNS, шлюза по умолчанию, шлюз и, в случае необходимости, сервер WINS/NetBIOS должны выделяться для HNED динамически через DHCP.

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

8.1.2 Протокол динамической конфигурации хоста (узла) (DHCP) определен несколькими стандартами RFC, основными из которых являются IETF [35], [36]. Протокол состоит из нескольких сообщений, имеющих фиксированный формат, который должен быть в соответствии с ETSI [12] (рисунок 14). Часть сообщения содержит опции переменного размера, которые позволяют сообщению кроме IP-адреса переносить дополнительную информацию.

В настоящем стандарте спецификация клиента DHCP в HNED подразделяется на сообщения и опции.

8.1.3 Клиент DHCP должен поддерживать все сообщения в соответствии с IETF [35], [36]. DHCP требует уникального идентификатора клиента, который является MAC адресом Ethernet в соответствии с IETF [35], [36].

8.1.4 Пространство кодов опций DHCP (от 1 до 254) разделено на две части. Специфичные для сайта коды опции (128-254) предназначены для "Личного использования" и зависят от реализации. Коды общедоступного использования (от 0 до 127, 255) определены диапазоном значений, установленных IETF [36], и детализированы в ETSI [12] (таблица 20).

8.1.4.1 Опция максимального размера сообщения DHCP (Max DHCP Message Size) должна применяться в тех случаях, когда размер сообщения DHCP превышает 378 байтов.

8.1.4.2 Протокол NetBIOS с транспортными протоколами TCP/IP устанавливается при необходимости установления связи HNED с сервером NetBIOS/WINS.

8.1.4.3 Опция класса пользователя DHCP для многопользовательских классов должна быть реализована в среде клиента DHCP. Предоставление опций для многопользовательских классов выполняется добавлением дополнительных имен классов удаленной системой управления. Идентификаторы (указатели имен) классов должны быть в соответствии с таблицей 5.

Таблица 5 - Указатели класса

8.1.4.4 Требования к реализации в HNED опции DHCP Relay Agent не предъявляются.

8.1.5 В том случае, если удаленный сервер DHCP по каким-либо причинам недоступен HNED, то домашняя сеть должна быть в состоянии связаться с DHCP, используя метод в соответствии с IETF [37].

8.1.6 Сценарии, рассматриваемые в настоящем стандарте, не предусматривают предоставление домашней сети многократных (multiple) серверов DHCP через внутренний или внешний DNG.

8.1.7 Выделение сервера DNS по умолчанию должно произойти через DHCP Шлюз по умолчанию должен быть определен DHCP.

8.1.8 Настоящий стандарт не предусматривает реализацию в HNED любого аспекта режима универсального Plug and Play. Допускается опция такого режима.

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

8.1.10 Адрес сервера повторной передачи протокола RTP предоставляется опцией сервера DHCP. Будущие расширения DVB должны быть структурированы как "Vendor-Identifying Vendor Specific Information Options" в соответствии с ETSI [12] (8.1.1.10).

8.1.11 Параметр расположения для CelllD формируется с использованием опции 99 DHCP GEOCONF_CIVIC в соответствии с IETF [14]. Эта опция позволяет серверу DHCP предоставлять информацию о стране и о почтовом адресе HNED, основанной на адресе клиента (chaddr) HNED, переданном на сервер DHCP. HNED должно использовать эту опцию, а сервер DHCP должен предоставить соответствующие гражданские элементы адреса для CelllD. Формат GEOCONF_CIVIC и правила использования адреса должны быть в соответствии с ETSI [12] (8.1.1.11).

8.2 Сетевые сервисы времени

8.2.1 Для оконечного устройства домашней сети должны быть предоставлены сетевые службы для часов реального времени и опционально - для транспортного потока:

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

- сетевые службы времени для транспортного потока с погрешностью отсчета 50 мс.

Обе службы могут существовать одновременно.

8.2.2 В HNED должны быть реализованы часы реального времени с погрешностью отсчета не более 100 мс в соответствии с IETF [38], с помощью простого сетевого протокола времени (SNTP) версия 4 (для IPv4). Адреса серверов SNTP должны поступать от сервера времени (Time Server Option) DHCP опция (4).

8.2.3 Точные службы времени для транспортного потока реализуются как опция сетевого протокола времени (версия 3) в соответствии с IETF [29] при обеспечении погрешности отсчета в диапазоне значений от 1 мс до 50 мс.

IP-адреса серверов времени должны поступать от DHCP сервера времени, опция (42). Сетевой Протокол Времени (NTP) должен использоваться в первую очередь, и в случае отказа сети NTP должен обеспечиваться переход на протокол SNTP. Нулевая сетевая опция (42) DHCP сервера времени означает, что сервер сетевого протокола времени не доступен и должен использоваться протокол SNTP.

9 Системные заглушки загрузки файла (FUSS) для активирования обновления системного программного обеспечения HNED

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

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

Процедура обновления встроенного ПО HNED включает в себя четыре этапа:

- получение файла заглушки при одноадресной или многоадресной передаче. Имя файла в случае одноадресной передачи должно быть "dvb-ipi-fus-stub.dvb";

- исследование файла заглушки с целью поиска возможных объектов ПО для обновления;

- загрузка обновления (опционально);

- выполнение провайдером мер безопасности и замена существующего ПО (опционально).

9.2 Получение файла заглушки

9.2.1 При запуске HNED должны быть определены URL или IP-адрес файла заглушки методами и в последовательности в соответствии с ETSI [12] (9.1: 1), 2), 3), 4).

9.2.2 Процедуры получения файла заглушки при многоадресной передаче средствами протокола DVBSTP на HNED должны выполняться в соответствии с ETSI [12] (9.1.1).

9.2.3 Процедуры получения файла заглушки при одноадресной передаче средствами протоколов HTTP или HTTPS должны выполняться в соответствии с ETSI [12] (9.1.2).

9.2.4 Предотвращение перегрузки серверов FUS, возникающей, например, из-за отказов электропитания HNED в начале загрузки данных, должно выполняться в соответствии с ETSI [12] (9.1.2.1).

9.3 Формат файла заглушки

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

Содержанием файла заглушки является подмножество метаданных, определенных в соответствии с ETSI [17] (приложение В).

Файлы заглушки могут передаваться в компактной, кодированной в соответствии с ETSI [12] (таблица 23) форме или детализированной форме, использующей полные имена, включенные в квадратные скобки "[ ]". Все файлы имеют заголовок [_DVB-STUB-HEADER-v1.0]. Примеры представления файлов в полной и компактной формах представлены в ETSI [12] (9.2). При передаче URI могут использоваться два способа:

- только при одноадресной передаче;

- при многоадресной и одноадресной передаче в соответствии с ETSI [12] (9.2).

10 "Служба загрузки (пересылки) контента" (CDS)

10.1 "Служба загрузки контента". Вводная часть

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

"Служба загрузки контента" может работать в двух режимах:

- загрузка в режиме "push";

- загрузка в режиме "pull".

Загрузка элементов контента в режиме "push" выполняется по инициативе провайдера служб без запроса пользователя.

Загрузка элементов контента в режиме "pull" выполняется при запросе пользователя.

Режимы загрузки элементов контента "push" и "pull" поддерживаются при многоадресной загрузке и одноадресной загрузке соответственно.

Многоадресный режим загрузки выполняется по протоколу доставки файла при однонаправленной передаче (FLUTE) IETF [39].

Одноадресный режим загрузки использует протокол HTTP, версия 1.1, в соответствии с IETF [16]. При этом поддерживается загрузка файла как от единственного сервера, так и по частям от нескольких серверов.

"Служба загрузки контента" прозрачна для любых систем защиты контента и допускает реализацию систем защиты контента, которые основываются на спецификации DVB СРСМ в соответствии с ETSI [40].

При необходимости установления одноадресных соединений между HNED в режиме CDS и функцией сети CDS или для получения описаний сеанса, или для загрузки файла рекомендуется использовать методы, описанные в спецификации RMS/FUS согласно ETSI [17] (5.4).

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

10.2.1 Структура функций CDS представлена на рисунке 13. Она включает в себя совокупность функций сети CDS, логические интерфейсы между HNED и функциональными компонентами сети CDS. Интерфейсы CDS: CDS-1, CDS-2, CDS-3, CDS-4, CDS-5, CDS-6, CDS-7, CDS-8, показанные на рисунке 13, являются частью интерфейса IPI-1. Все функции, идентифицированные на рисунке 13, являются логическими.

Компоненты службы загрузки контента:

- CDS HNED: устройство пользователя, которое обеспечивает легкий, быстрый и безопасный доступ к службам IPTV. HNED, поддерживающие службы CDS, должны обеспечивать выполнение функций HNED CDS, определенных настоящим стандартом, и должны обеспечивать хранение контента, выделенного CDS;

- анонсирование CDS: функция анонсирования CDS рекламирует доступность элементов контента в режимах загрузки "push" и "pull" и сообщает соответствующие параметры сеанса загрузки. Детализированные параметры службы анонсирования CDS представлены в 10.3 настоящего стандарта;

- многоадресные функции загрузки: обеспечивают одновременное и достоверное распределение элементов контента группе приемников. Детализированные параметры многоадресных функций загрузки представлены в ETSI [12] (10.6.2). Многоадресные функции загрузки включают в свой состав компоненты:

- многоадресная загрузка: многоадресный компонент загрузки загружает элементы контента на HNED. Многоадресный компонент загрузки основан на протоколе FLUTE. Детализированные параметры протокола FLUTE представлены в ETSI [12] (10.6.2.2);

- опрос завершения: этот компонент используется функцией сети CDS для определения момента завершения приема контента всеми HNED многоадресной группы, для остановки многоадресной загрузки. Детализированные параметры компонента опроса завершения представлены в ETSI [12] (10.6.2.5);

- восстановление файла: компонент восстановления файла запускает процесс восстановления неполных файлов после завершения многоадресного сеанса загрузки. Детализированные параметры компонента восстановления файла должны быть в соответствии с ETSI [12] (10.6.2.6);

- одноадресная функция загрузки: функция одноадресного режима загрузки обеспечивает достоверное распределение элементов контента к индивидуальным приемникам. Детализированные параметры одноадресных функций загрузки представлены в ETSI [12] (10.6.3). Одноадресная функция загрузки включает в свой состав компоненты:

- одноадресная загрузка: компонент одноадресной загрузки, который распределяет элементы контента индивидуальным HNED по их запросам. Этот режим загрузки основан на протоколе HTTP в соответствии IETF [16]. Детализированные параметры компонента одноадресной загрузки представлены в ETSI [12] (10.6.3);

- управление перенаправлением: этот компонент обеспечивает перенаправление одноадресных запросов загрузки к альтернативным источникам загрузки, таким как одиночный альтернативный сервер, многоадресный сеанс, на которых доступен затребованный контент, или совокупность многократных серверов, каждый из которых может обеспечивать доставку одной из частей требуемого контента. Кроме того, этот компонент формирует для HNED рекомендации о целесообразном времени выполнения запросов перенаправления, например немедленно или в более позднее время. Детализированные параметры компонента управления перенаправлением представлены в ETSI [12] (10.6.3.4);

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

- создание отчетов приема: после успешной загрузки блоков файла, файлов или элементов контента HNED может сообщить функции создания отчетов приема об окончании загрузки. Эта функция обеспечивает возможность для сети CDS сбора статистических данных о процессе загрузки контента и может использоваться для контроля или для динамической адаптации стратегии загрузки. Детализированные параметры функции создания отчетов приема представлены в ETSI [12] (10.6.5);

- управление локальным хранением: эта функция позволяет сети CDS управлять хранением контента на HNED. Детализированные параметры управления хранением представлены в ETSI [12] (10.7) и в 10.7 настоящего стандарта;

- управление CDS: этот компонент управляет всеми другими функциями CDS. Параметры этого компонента в настоящем стандарте не рассматриваются;

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

10.2.2 CDS определяет восемь интерфейсов между функциями сети CDS и функцией CDS HNED. Все эти интерфейсы являются частью IPI-1 интерфейса. Краткие описания функций, выполняемых интерфейсами CDS: CDS-1, CDS-2, CDS-3, CDS-4, CDS-5, CDS-6, CDS-7, CDS-8, протоколов, поддерживающих эти функции, и ссылки на детализированные описания представлены в таблице 6.

Таблица 6 - Краткие описания функций, выполняемых интерфейсами CDS, и протоколов, поддерживающих эти функции

10.2.3 Стек протоколов, используемых в интерфейсе IPI-1 для поддержки службы загрузки контента, показан на рисунке 14. На верхнем уровне стека расположены приложения (элементы контента и анонсы службы). На нижних уровнях показаны общие уровни: уровень IP, обслуживающий сетевой транспортный уровень, физический уровень и уровень канала передачи данных.

Рисунок 14 - Стек протоколов, используемых в интерфейсе IPI-1 для поддержки службы загрузки контента

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

10.3.1 Функции анонсирования службы загрузки контента предоставляют HNED информацию об элементах контента, которые являются в свою очередь функцией сети CDS для режимов "push" и "pull". Эта информация включает в себя метаданные элементов контента, данные о доступности загрузки и информации об описании сеанса загрузки.

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

10.3.2 Использование SD&S, BCG и TVA для задач CDS. Путеводитель по контенту вещания (BCG) в соответствии со стандартом ETSI [11] должен использоваться для анонсирования CDS и анонсирования отдельных элементов контента CDS. Анонсирование элементов контента для загрузки фрагментов метаданных должно выполняться в соответствии с ETSI [11] (раздел 6).

Расширенная версия OnDemandProgramType определена в Б.1.1 приложения Б для объявления об элементах контента, доступных в режиме службы загрузки получения по запросу "pull".

Новый PushDownloadType определен в Б.1.2 приложения Б для объявления об элементах контента, доступных в режиме службы загрузки "push". PushDownloadType является частью ProgramLocationType. ProgramLocationType определен в Б.1.3 приложения Б. Идентификация CRID должна выполняться в соответствии с ETSI [11] (раздел 5). Детализированные характеристики процедур использования руководства BCG для задач анонсирования CDS должны быть в соответствии с ETSI [12] (10.3.2).

10.3.3 Загрузка сеанса службы CDS должна обеспечиваться в соответствии с ETSI [12] (10.3.2):

10.3.3.1 Расположение контента CDS может быть определено ссылкой на доставленное в режиме многоадресной передачи описание сеанса, основанного на XML загрузке. Параметры многоадресной доставки описаний сеанса, использующих язык XML, определены в ETSI [12] (10.5.5.1).

10.3.3.2 Параметры одноадресной доставки описаний сеанса, использующих язык ХМL определены в ETSI [12] (10.5.5.2).

10.3.3.3 Расположение контента CDS может быть определено ссылкой на доставленное при многоадресной передаче описание сеанса на основе загрузки протокола SDP. Параметры формирования ссылки должны быть в соответствии с ETSI [12] (10.3.2.3, 10.5.5.3).

10.3.3.4 Расположение контента CDS может быть определено ссылкой на доставленное при одноадресной передаче описание сеанса на основе загрузки протокола SDP. Параметры формирования ссылки должны быть в соответствии с ETSI [12] (10.3.2.4, 10.5.5.4).

10.3.4 После успешной загрузки элементов контента HNED может получить доступ к файлам хранения этих элементов HNED CDS использованием унифицированного идентификатора ресурса (URI). Доступ к файлам элемента контента хранения службы CDS устройством HNED должен выполняться в соответствии с ETSI [12] (10.3.3).

10.4 Форматы CDS элементов контента и файлов

10.4.1 Основной задачей загрузки CDS является обеспечение загрузки элементов контента, которые состоят из одного или более аудио и видеофайлов и связанных с ними метаданных. "Служба загрузки контента" различает форматы элемента контента и форматы файла.

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

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

10.4.3 Форматы элементов контента. Единственный элемент контента может включать как единственный файл, так и несколько файлов. Все файлы элемента контента должны быть объявлены и загружены в единственном описании сеанса загрузки. HNED должен отслеживать эту связь между элементом контента и файлами. Описание сеанса загрузки может анонсировать элемент формата контента в атрибуте Content-Item-Format. Должны поддерживаться следующие форматы элемента контента:

- Content-Item-Format=0;

- Content-ltem-Format=1;

- Content-ltem-Format=2;

- Content-ltem-Format=3.

Детализация условий применения перечисленных элементов форматов контента должна быть в соответствии с ETSI [12] (10.4.3).

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

Загрузка элементов контента выполняется загрузкой одного или нескольких индивидуальных файлов. Сбор индивидуальных файлов элемента контента требует применения конструкции уникальной ссылки для каждого файла. Методы ссылки на расположение файла в описаниях сеанса загрузки CDS представлены в стандарте ETSI [12] (10.5.2).

Параметры сеанса загрузки и их семантика представлены в стандарте ETSI [12] (10.5.3). Различные типы сеансов загрузки с параметрами сеанса загрузки представлены в стандарте ETSI [12] (10.5.4). Функция HNED службы загрузки контента должна обеспечивать поддержку следующих типов сеанса загрузки:

- сеанс запланированной многоадресной загрузки (Scheduled Multicast Download, SMD);

- сеанс многоадресной загрузки карусели (Carousel Multicast Download; CMD);

- сеанс одноадресной загрузки (Unicast Download; UD).

Допускаются две моды поддержки сеанса одноадресной загрузки (UD):

- одноадресная загрузка (UD) сеанса с одиночным сервером (Single Server; SS) загрузки;

- одноадресная загрузка (UD) сеанса с множеством серверов (Multiple Server; MS) загрузки.

Функция HNED службы загрузки контента должна поддерживать синтаксис языка XML. Допускается поддержка функцией HNED службы загрузки контента синтаксиса протокола SDP. Синтаксис XML для параметров сеанса загрузки определен в ETSI [12] (приложение С, 2.3). Синтаксис SDP для параметров сеанса загрузки определен в ETSI [12] (приложение G, раздел 2). Параметры транспорта описаний сеанса загрузки в режимах:

- многоадресный транспорт описаний сеанса загрузки, использующих язык XML;

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

- многоадресный транспорт описаний сеанса загрузки на основе протокола SDP;

- одноадресный транспорт описаний сеанса загрузки на основе протокола SDP определены в ETSI [12] (10.5.5).

10.6 Загрузка элементов контента службы загрузки контента

10.6.1 CDS поддерживает загрузку всех файлов, связанных с элементом контента, как части единственного сеанса загрузки.

В пределах сеанса CDS файлы поставляются при одноадресной передаче или при многоадресной передаче.

Функция HNED "службы загрузки контента" должна поддерживать:

- загрузку всех обязательных функций многоадресного контента в соответствии с ETSI [12] (10.6.2);

- загрузку всех обязательных функций одноадресного контента в соответствии с ETSI [12] (10.6.3);

- загрузку всех обязательных функций процедур отчетности приема в соответствии с ETSI [12] (10.6.5).

В режимах сеанса загрузки SMD или CMD и сеть CDS и HNED с функцией CDS должны применять многоадресную процедуру загрузки контента в соответствии с ETSI [12] (10.6.2).

В режиме одноадресного сеанса загрузки UD сеть CDS и функции CDS HNED должны применять одноадресную процедуру загрузки контента в соответствии с ETSI [12] (10.6.3).

Режим сеанса параллельной загрузки элементов контента от одного или множества серверов выполняется в соответствии с ETSI [12] (10.6.4).

Если описание сеанса загрузки содержит, по крайней мере, один Reception-Reporting-Server-URI, то сеть CDS и CDS функция HNED должны применить процедуры отчетности приема в соответствии с ETSI [12] (10.6.5).

10.6.2 HNED может выполнить параллельную загрузку множества элементов контента CDS в параллельных сеансах загрузки в соответствии со стандартом ETSI [12] (10.6.4).

10.6.3 Создание отчетов приема Reception-Reporting-Server-URI в описании сеанса загрузки выполняется в соответствии с ETSI [12] (10.6.5).

10.6.4 Нумерация версии контента выполняется в соответствии с ETSI [12] (10.6.6).

10.6.5 Приоритетные настройки. Одноадресная передача CDS и многоадресные сеансы загрузки данных должны использовать тип трафика "с максимальным усилием" при негарантированном режиме обслуживания - при выделении свободных сетевых ресурсов в соответствии с разделом 11 настоящего стандарта.

10.7 Управление хранением HNED службы загрузки контента

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

Параметры управления хранением HNED службы загрузки контента представлены в ETSI [12] (10.7).

11 Качество службы

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

В сети CDS обеспечение необходимого качества службы (QoS) для конечного пользователя обеспечивается:

- классификацией типов данных, содержащихся в каждой дейтаграмме:

- установлением приоритетов трафика данных, основанных на классификации типов данных, содержащихся в каждой дейтаграмме.

Метод классификации соответствует модели дифференцированных служб, описанной в IETF [42].

11.2 Маркировка пакетов DSCP

DSCP различных служб маркируются полем "тип службы" (Type of Service, ToS), 8 битов, в заголовке IP, описанном в IETF [43]. Сети, совместимые с IETF [43], используют 6 битов поля типа службы ToS. Поле ToS описывает кодовую точку службы числовым значением, используемым в пределах сети, для управления политикой организации очередей. Сети, не совместимые с IETF [43], для определения приоритета используют поле ToS, 3 бита.

В сетях IP, предназначенных для переноса служб DVB, должны использоваться маркировки кодовой точки DSCP, детализированные в таблице 8.

Таблица 8 - Маркировки кодовой точки DSCP

11.3 Приоритет Ethernet

Интерфейсы IPI-1, IPI-2 и IPI-3 на уровне MAC Ethernet базового домашнего сетевого сегмента HNS должны поддерживать параметры стандарта IEEE [4] с классификацией приоритетов, определенной пользователем.

Поле IEEE [43] должно соответствовать требованиям IEEE [4] к кадру Ethernet.

Маркировка должна использовать кодовые точки DSCP в соответствии с изложенным в ETSI [12] (11.1).

Величины DSCP и маркировка, соответствующая Ethernet IEEE [44], представлены в таблице 9.

Таблица 9 - Величины DSCP и маркировка, соответствующая Ethernet IEEE [44]

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

Модель данных SD&S

На рисунке А.1 показано графическое изображение модели открытия службы DVB-IPTV.

Рисунок А.1 - Модель данных для поиска информации о службах DVB-IPTV

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

Информация, связанная со службой загрузки контента (CDS)

Б.1 Расширения CDS, связанные с другими спецификациями

Б.1.1 Функция анонсирования CDS обусловливает необходимость расширения BCG и расширения состава процедур TVA.

В настоящем приложении собраны расширения спецификации, совместимые с CDS.

Б.1.2 Использование OnDemandProgramType и расширения OnDemandProgramType для службы загрузки в режиме "pull" должны быть в соответствии с ETSI [12] (приложение G, G.1.1).

Б.1.3 Использование PushDownloadType для загрузки службы CDS в режиме "push" должно быть в соответствии с ETSI [12] (приложение G, G.1.2).

Б.1.4 Локатор ProgramLocationTable должен быть в соответствии с ETSI [21] (6.7.1) для использования PushDownloadType в качестве локатора программы в соответствии с ETSI [12] (приложение G, G.1.3).

Б.1.5 Расширенный расчлененный двоичный локатор "по требованию" предназначен для обеспечения необходимых параметров для службы загрузки в режиме "pull". Параметры и синтаксис расширенного расчлененного двоичного локатора должны быть в соответствии с ETSI [12] (приложение G, G.1.4).

Б.1.6 ProgramURL и идентификаторы URI локатора файлов CDS, хранящихся в HNED, должны использоваться в соответствии с ETSI [12] (приложение G, G.1.5).

Б.2 Синтаксис SDP

Б.2.1 Базовые параметры синтаксиса протокола SDP определены стандартом IETF [23]. Служба CDS для конкретных целей использует стандартные параметры SDP, определенные в IETF [23], и устанавливает новые специфичные параметры. Синтаксис протокола SDP описаний параметров сеанса CDS, определенных в 10.5 настоящего стандарта, должен быть в соответствии с ETSI [12] (приложение G, G.2).

Б.2.2 Структура сообщения SDP должна быть в соответствии с ETSI [12] (приложение G, G.2.1).

Б.2.3 Общие параметры. В 10.5 настоящего стандарта определены общие параметры, которые должны поддерживаться для любого типа сеанса загрузки CDS. Соответствие этих параметров стандартным параметрам SDP должно быть в соответствии с ETSI [12] (приложение G, G.2.2).

Б.3 Параметры загрузки одноадресной передачи

Б.3.1 В этом подразделе определены параметры SDP, используемые для описания одноадресного сеанса загрузки контента. Представлен синтаксис SDP для одноадресной передачи конкретных параметров сеанса загрузки CDS, определенной в соответствии с 10.5 настоящего стандарта.

Б.3.2 Ссылки на файл должны выполняться в соответствии с ETSI [12] (приложение G, G.2.4.1).

Б.3.3 Синтаксис длины файла должен определяться в соответствии с ETSI [12] (приложение G, G.2.4.2).

Б.3.4 Синтаксис классификации файла должен быть в соответствии с ETSI [12] (приложение G, G.2.4.3).

Б.3.5 Общая длина блоков файла определена синтаксисом в соответствии с ETSI [12] (приложение G, G.2.4.4).

Б.3.6 Классификация блоков MD5 и их количества (позиция в пределах файла, считаемого от 1 до n) определена синтаксисом в соответствии с ETSI [12] (приложение G, G.2.4.5).

Б.3.7 URI базового сервера и тип файла контента определяется в соответствии с ETSI [12] (приложение G, G.2.4.6).

Б.3.8 Список доступных блоков файла определен синтаксисом в соответствии с ETSI [12] (приложение G, G.2.4.7).

Б.3.9 Параметры платформы группирования, обеспечивающей определение расположения альтернативного сервера или совокупности серверов файла, который должен быть загружен, должны быть в соответствии с IETF [45]. Общие правила формирования платформы группирования должны быть в соответствии с ETSI [12] (приложение G, G.2.4.8).

Б.3.10 Структура сообщения SDP для одноадресной загрузки сеанса должна быть в соответствии с ETSI [12] (приложение G, 2.4.9).

Б.4 Параметры загрузки многоадресной передачи

Подраздел определяет параметры SDP, используемые для описания многоадресного сеанса загрузки контента. Аналогичная структура SDP используется для запланированной и многоадресной загрузки карусели. FLUTE, используемая для многоадресной загрузки, и SDP параметры FLUTE, определенные в соответствии с ETSI [46] (6.1.3), используются для описания конкретной информации FLUTE.

Перечень параметров SDP, используемых для описания многоадресного сеанса загрузки контента, и ссылки на нормативные документы, специфицирующие эти параметры, представлены в таблице Б.1.

Таблица Б.1 - Перечень параметров SDP, описывающих многоадресный сеанс загрузки контента

Б.5 Схема идентификатора URI DVB-multicast

Схема URI DVB-multicast предназначена для идентификации ресурсов, передаваемых через многоадресный канал IP. Она позволяет определить местоположение многоадресного канала, переносящего ресурс, и определить информацию об уровне приложения транспортного протокола, который будет использоваться для переноса данных по многоадресному каналу IP. Параметры базовой схемы DVB-multicast URI должны быть в соответствии с ETSI [12] (приложение G, G.3.1). Параметры схемы DVB-multicast URI для протокола DVBSTP должны быть в соответствии с ETSI [12] (приложение G, G.3.2). Параметры схемы DVB-multicast URI для протокола SAP должны быть в соответствии с ETSI [12] (приложение G, G.3.3).

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

Решения повторной передачи RTP

B.1 Введение

Это приложение определяет опцию, обеспечивающую для HNED непосредственную обратную связь (FB) для переприема недостающих пакетов при использовании протокола RTCP и сервера RET. Этот механизм может использоваться для одноадресной передачи служб CoD и MBwTM и многоадресной передачи LMB.

Этот механизм может использоваться вместо решения AL-FEC или в комбинации с решением AL-FEC для защиты потоков RTP от потери пакетов.

B.2 Архитектура повторной передачи (RET)

В.2.1 RET для служб CoD / MBwTM

Архитектура процесса повторной передачи для одноадресной передачи CoD и вещания медиа с режимом Trick (CoD/MBwTM) показана на рисунке В.1.

FB (Feed Back) - обратная передача;

UC (Unicast) - одноадресная доставка.

Рисунок В.1 - Архитектура и сигнализация RET для служб CoD/MBwTM

Эта архитектура содержит два компонента:

- HNED, включающая клиента RTP для медиа и клиента RTP RET;

- стриммер CoD/MBwTM с функциями сервера RTP медиа и сервера RTP RET;

Процесс восстановления повторной передачи включает в себя три этапа:

- этап 1: поток данных CoD/MBwTM в одноадресном режиме от сервера RTP медиа передан протоколом RTP. В процессе передачи произошла потеря пакета RTP;

- этап 2: после обнаружения потери пакета RTP в HNED клиент RTP RET в HNED отправляет сообщение FB RTCP RET на сервер RTP RET;

- этап 3: сервер RTP RET отвечает на сообщение FB RTCP, ретранслируя требуемый пакет (называемый RET пакетом) протоколом RTP RET клиенту RTP RET.

Процесс повторной передачи для случая потоков с множеством SSRC в потоке данных CoD/MBwTM должен выполняться в соответствии с ETSI [12] (приложение F, F.3.1).

В.2.2 RET для службы "вещания медиа" (LMB)

Восстановление потерянных пакетов для служб LMB может выполняться для случаев одноадресной передачи и многоадресной передачи.

На рисунках B.2 и B.3 показаны элементы и коммуникационные потоки, образующие архитектуру RET для службы вещания медиа (LMB). Вариант восстановления потерянных пакетов для служб LMB при одноадресной передаче показан на рисунке В.2 Вариант восстановления потерянных пакетов для служб LMB при многоадресной передаче показан на рисунке B.3.

При одноадресной передаче восстановление потерянных пакетов (рисунок В.2) происходит так же, как и в случае служб CoD/MBwTM: клиент RTP медиа (в составе HNED) обнаруживает потерю пакета, передает на сервер LMB RET сообщение FB RTCP (этап 2), в ответ происходит одноадресная передача пакета RTP RET. SSRC, используемый сервером LMB RET, может отличаться от SSRC исходного многоадресного сеанса RTP.

В этой архитектуре может быть предусмотрено несколько серверов LMB RET, которые обрабатывают одноадресные потоки сообщений RTCP FB от клиентов RET. Каждый из таких серверов LMB RET является адресатом потоков RTCP от субмножества устройств HNED.

FB (Feed Back) - обратная передача;

UC (Unicast) - одноадресная доставка;

МС (Multicast) - многоадресная доставка

Рисунок В.2 - Элементы и коммуникационные потоки, образующие архитектуру RET для службы вещания медиа (LMB): восстановление потерянных пакетов для служб LMB при одноадресной передаче

При многоадресной передаче служб LMB от головных станций восстановление потерянных пакетов происходит при одноадресной передаче сообщений обратной связи FB RTCP. Потерянные пакеты могут быть восстановлены в потоке от серверов LMB RET с помощью клиента повторной передачи (входит в состав этого сервера) при использовании механизма повторной передачи для восстановления потерянного пакета (рисунок В.З).

FF (Feed Forward) - прямая передача;

FB (Feed Back) - обратная передача;

MC (Multicast) - многоадресная доставка

Рисунок B.3 - Элементы и коммуникационные потоки, образующие архитектуру RET для службы вещания медиа (LMB): восстановление потерянных пакетов для служб LMB при многоадресной передаче

На рисунке B.3 показаны элементы и коммуникационные потоки, образующие архитектуру RET, для службы вещания медиа (LMB) при восстановлении потерянных пакетов для служб LMB для случая многоадресной передачи с использованием многоадресного метода восстановления служб LMB, когда потеря пакета происходит в потоке от сервера LMB RET к совокупности HNED (этап 1 на рисунке B.3).

Сервер LMB RET не нуждается в сообщении FB RTCP от устройств HNED, так как потерю пакета он обнаруживает сам (с помощью клиента LMB медиа в своем составе). Сервер LMB RET, обнаружив потерю пакета, передает на закрепленные за ним устройства HNED запрос с предложением не передавать сообщение FB через канал RTCP. Передача этого запроса выполняется сообщением RTCP FF при многоадресной передаче (этап 2 на рисунке В.З), что позволяет предотвращать "штормы NACK". По запросу RTCP FB, передаваемому от клиента RET, находящемуся в составе сервера LMB RET, к серверу RET в составе головной станции (этап III), RET сервер в составе головной станции передает на сервер LMB RET потерянный пакет протоколом RTP RET (этап III). Этот механизм предполагает, что клиенты RET при обнаружении потери пакета формирование запроса RET выполняют посредством рандомизации времени ожидания (IETF [47]) или применением более усовершенствованного механизма в соответствии с приложением B, B.6.3. В связи с тем, что SSRC, используемые сервером LMB RET, могут отличаться от SSRC исходного сеанса многоадресной передачи, допускаются отклонения правил при мультиплексировании сеанса сервером LMB RET от рекомендаций, определенных в IETF [48]. Детализация правил формирования сообщений LMB RET должна быть в соответствии с ETSI [12] (приложение F, F.3.2).

B.3 Сигнализация RTCP для HNED, поддерживающих повторную передачу RET

B.3.1 Общие положения

Отчеты RTCP устройств HNED для RET, включая службы LMB, всегда передаются к серверу LMB RET, который является целью RTCP в одноадресном режиме. Сервер LMB RET никогда не должен возвращать отчеты к устройствам HNED, кроме тех случаев, когда сервер LMB RET передает сообщение FF RTCP (приложение B, B.4.2). Ниже описываются параметры отчетов RTCP, которые могут быть переданы устройствам HNED и должны поддерживаться устройствами HNED.

B.3.2 Сообщение RTCP FB

Для запроса повторной передачи HNED использует протокол RTCP. Формат универсального сообщения FB транспортного уровня NACK, как определено в IETF [47], используется для запросов повторной передачи пакетов, как показано на рисунке B.4.

Рисунок В.4 - Формат пакета сообщения FB RTCP

Семантика основных полей пакета сообщения FB RTCP:

- поле "FMT" (Feedback Message Type), 5 битов. Идентифицирует тип сообщения FB и интерпретируется в соответствии с типом (транспортный уровень, полезная нагрузка - определенная или полезная нагрузка обратной связи прикладного уровня). Значения для каждого из трех типов обратной связи определены в соответствующих разделах IETF [47]. В случае передачи сообщения типа RTCP FB в поле должна быть установлена "1";

- поле "РТ" (Payload Туре): 8 битов. Идентифицирует тип полезной нагрузки. В случае "RTPFB" в поле устанавливается величина 205;

- поле "Feedback Control Information" (FCI): n*32 бита. Содержит информацию управления обратной связи. Поле FCI в сообщении FB RTCP может содержать одну и более универсальных квитанций NACK. Сообщения RTCP от HNED всегда передаются в сети одноадресно, в том числе и для службы LMB. Транспортный адрес для обмена сообщениями RTCP (IP-адрес назначения и порт назначения UDP) получен HNED методами конфигурации, представленными в приложении В, В.5.

В поле "SSRC отправителя пакетов" в сообщении FB RTCP использовано значение SSRC HNED в исходном сеансе RTP для служб LMB.

Поле "SSRC источника медиа" содержит SSRC головного узла, используемого для службы LMB, и для которого сообщение FB RTCP сообщает о потере пакетов.

Формат универсальной квитанции NACK в поле FCI в сообщении FB RTCP показан на рисунке B.5.

Рисунок B.5 - Формат универсальной квитанции NACK в поле FCI в сообщении FB RTCP

Семантика универсальной квитанции NACK:

- поле "PID", 16 битов. Поле указывает порядковый номер первого потерянного пакета;

- поле "BLP" (bitmask of following lost packets), 16 битов. Поле "битовая маска (поразрядная маска) следующих потерянных пакетов" учитывает создание отчетов о потерях любого из 16 пакетов RTP сразу после пакета RTP, индицированного идентификатором PID (полное определение - в соответствии с IETF [47]). Это позволяет в отдельной универсальной квитанции NACK сообщать о 17 (последовательных) потерях пакетов.

Детализированные данные о сообщении RTCP FB должны быть в соответствии с ETSI [12] (приложение F, F.4.1).

B.3.3 Пакеты RR, SDES и BYE протокола RTCP

HNED, поддерживающее RET, должно обеспечивать обработку следующих пакетов протокола RTCP: описание SDES RTCP, отчеты приемника (RR) и BYE. Форматы этих протоколов определены в IETF [25]. Правила применения этих пакетов должны быть в соответствии с ETSI [12] (приложение F, F.4.2.1-F.4.2.3).

B.3.4 Типы обмена сообщениями RTCP

HNED для исходного сеанса RTP должен поддерживать и составные, и несоставные пакеты FB RTCP. Составной пакет RTCP должен содержать пакеты SDES, RR и сообщения FB (IETF [47]), в то время как несоставной (сокращенного размера) пакет RTCP содержит только сообщения FB RTCP. Детализированные типы обмена сообщениями должны быть в соответствии с ETSI [12] (приложение F, F.4.3).

B.4 Сигнализация протокола RTCP к HNED, поддерживающим RET

Ниже описаны пакеты RTCP, которые должны поддерживаться HNED, поддерживающими RET.

B.4.1 Пакеты RTCP SDES и SR

HNED должен обеспечивать прием отчета отправителя RTCP (SR) и пакетов RTCP SDES в исходном многоадресном RTP сеансе от RTP многоадресного источника.

Допускается передача сервером LMB/CoD RET пакетов RTCP SR и RTCP SDES в одноадресном сеансе RTP RET. Допускается передача сервером LMB RET пакетов RTCP SR и RTCP SDES в многоадресном сеансе RTP RET.

B.4.2 Сообщение прямой передачи (FF) протокола RTCP (только для службы LMB)

Сообщения FF RTCP передаются в нисходящем потоке сервера LMB RET.

Детализированные описания типов сообщений FF должны быть в соответствии с ETSI [12] (приложение F, F.5.3).

В.4.3 Пакеты RSI RTCP (только для службы LMB)

Форматы и семантика пакетов сводной информации приемника (RSI) протокола RTCP должны быть в соответствии с ETSI [12] (приложение F.3).

B.5 Формат повторной передачи SSRC и транспортные адреса сеанса повторной передачи RTP

B.5.1 Формат повторной передачи

HNED должен поддерживать пакеты повторной передачи (RET) с форматом заголовка полезной нагрузки RET в соответствии с IETF [48]. Детализированное описание формата повторной передачи должно быть в соответствии с ETSI [12] (приложение F, F.6.1).

B.5.2 Рекомендации относительно повторной передачи адресов и идентификаторов SSRC

B.5.2.1 Одноадресные службы (CoD и MBwTM)

IP-адреса и номера портов пакетов исходного RTP и ретранслируемых пакетов RTP рекомендуется устанавливать идентичными, приведенными к единственному (отдельному) сеансу RTP. Идентификаторы SSRC пакетов повторной передачи RTP должны отличаться от идентификаторов SSRC RTP исходных пакетов, если используются одни и те же транспортные параметры для обязательного формата RET (в соответствии с IETF [48]). Это позволяет HNED находить среди пакетов RET SSRC исходных пакетов.

Примечание - "идентичная копия" ("identical сору") формата RET не допускает использования указанных различий при использовании одинаковых транспортных параметров.

B.5.2.2 Служба LMB

При одноадресной передаче идентификатор SSRC пакета повторной передачи RTP может отличаться от идентификатора SSRC RTP многоадресных исходных пакетов. Эти отличия могут использоваться для решения задач мониторинга сети. Детализированные рекомендации относительно повторной передачи адресов и идентификаторов SSRC для службы LMB должны быть в соответствии с ETSI [12] (приложение F, F.6.2.2).

B.6 Характеристики запроса повторной передачи HNED, поддерживающим RET

HNED, поддерживающее RET, буферизует входящие пакеты RTP и задерживает их на время, необходимое для обнаружения потери пакетов, формирования запроса повторной передачи (RET) и восстановления пакетов.

Задержка буферизации имеет постоянное значение, которое базируется на параметрах синхронизации RET, описанных в этом приложении отдельно для служб CoD/MBwTM и LMB.

В.6.1 Параметры синхронизации повторной передачи (RET) служб CoD/MBwTM (запрос)

Средствами протокола RTSP сигнализируются следующие параметры синхронизации RET для служб CoD/MBwTM:

- rtx-time - определяет интервал времени, в течение которого пакет доступен для повторных передач в соответствии IETF [48]. Это значение интервала времени является максимальной допустимой задержкой буферизации в случае RET; параметр rtx-time позволяет определить количество попыток повторной передачи, которые HNED может выполнить, принимая во внимание значение параметра dvb-t-ret;

- dvb-t-ret - определяет интервал времени, в течение которого приемник должен ожидать пакета восстановления на запрос повторной передачи прежде, чем выпустить другой запрос повторной передачи на тот же самый пакет (или пакеты). Этот период времени является начальной точкой отправления запроса повторной передачи. Этот параметр опционален, но HNED должен быть в состоянии его поддерживать, если параметр сигнализируется. Если параметр не сообщен, то HNED должен выбрать соответствующую задержку на интервал времени, с которым повторялись дефектные передачи. Это время задержки может быть определено оценкой времени, которое протекает между временем обратной передачи (FB) сообщения RTCP на отдельную потерю пакета от HNED на сервер RET и времени приема требуемого пакета RET в HNED, с возможностью динамической адаптации этого параметра в соответствии с IETF [48] (6.3).

Представляется допустимым следующее соотношение между значениями параметров синхронизации:

"rtx- time">"dvb-t-ret">среднее значение RTT.

Величина задержки буферизации HNED должна быть выбрана между:

- минимальным значением, равным dvb-t-ret;

- максимальным значением, равным rtx-time.

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

- trr-int: В соответствии с IETF [47] параметр trr-int определяет минимальный интервал в миллисекундах между двумя нормальными полными составными пакетами RTCP для сеанса RTP. Если параметр trr-int не определен, то по умолчанию устанавливается значение "0". Полные составные пакеты RTCP включают отчеты приемника (RR). Пакеты RTCP, содержащие только сообщения FB, не подвергаются ограничениям, вносимым параметром trr-int;

- rtcp-bandwidth: Параметр XML rtcp-bandwidth указывает максимальное значение пропускной способности, которая может быть использована HNED для создания отчетов RTCP. Значение по умолчанию составляет 5% исходной пропускной способности потока. Если используется протокол SDP, то этот параметр может быть установлен использованием выражения "b=RR: <значение пропускной способности>" модификатора пропускной способности в соответствии с IETF [49].

В.6.2 Временные параметры RET службы LMB

Временные параметры RET для служб LMB, поддерживающих RET в соответствии с условиями SD&S, включают параметры, определенные в приложении B, B.6.2. Детализированные параметры времени RET для служб LMB, поддерживающих RET, должны быть в соответствии с ETSI [12] (приложение Е, Е.7.2).

B.7 Метод конфигурации и параметры конфигурации

Методы конфигурации и параметры конфигурации клиента служб LMB и CoD, поддерживающих повторную передачу, должны быть в соответствии с ETSI [12] (приложение F, F.8).

B.8 Установки приоритетов QoS

Пакеты повторной передачи RTP имеют приоритет соответствующих исходных пакетов RTP, передающих видео (кодовые точки (DSCP) которых имеют значения 0b100010 или 0b100100).

Для всех пакетов RTCP, передающихся от оконечного устройства домашней сети, установка приоритета сигнализируется значением DSCP 0b011010.

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

B.9 Объединенные службы AL-FEC и RET

Службы AL-FEC и RET выполняют защиту пакетов от потерь. Эти службы специфицированы независимо друг от друга. Системный провайдер может использовать оба механизма этих служб для восстановления потерянных пакетов для службы LMB и служб CoD/LMBwTM. Однако, следует учитывать, что механизм RET в соответствии с настоящим стандартом применяется только к исходным потокам данных RTP.

B.10 Отображение специфичных для DVB RET атрибутов и параметров в протоколе описания сеанса (SDP)

Правила применения атрибутов dvb-t-ret, dvb-disable-rtcp-rr, dvb-t-wait-min, dvb-t-wait-max, dvb-ssrc-bitmask, dvb-ssrcupstream-client, dvb-rsi-mc-ret и dvb-enable-bye должны быть в соответствии с [ ] (приложение B.10).

Примеры описаний SDP для RET, поддерживающего службу CoD, для RET, поддерживающего сеанс RTP LMB, включая атрибуты и параметры DVB RET, определенные в настоящем приложении, даны в рекомендациях стандарта TS [50].

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

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

и сверен по:

, 2020