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

Обложка ГОСТ Р 59809-2021 Телевидение вещательное цифровое. Расширенные технические требования к передаче транспортных потоков служб DVB по сетям с IP-протоколами. Часть 5. Качество службы. Возобновляемость системы. Динамическое управление службой. Основные параметры
Обозначение
ГОСТ Р 59809-2021
Наименование
Телевидение вещательное цифровое. Расширенные технические требования к передаче транспортных потоков служб DVB по сетям с IP-протоколами. Часть 5. Качество службы. Возобновляемость системы. Динамическое управление службой. Основные параметры
Статус
Действует
Дата введения
2022.01.06
Дата отмены
-
Заменен на
-
Код ОКС
33.170

        ГОСТ Р 59809-2021


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


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


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


Часть 5


Качество службы. Возобновляемость системы. Динамическое управление службой. Основные параметры


Digital video broadcasting. Extended technical requirements for transmitting DVB service transport streams over networks with IP protocols. Part 5. Quality of service. The renewability of the system. Dynamic service management. Basic parameters

ОКС 33.170

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


Предисловие


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

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

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

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

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

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


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

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

- классификации типа данных;

- доставки сообщений возобновления систем защиты контента через IP-сети;

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

- служб загрузки SRM;

- функциональной архитектуры доставки SRM;

- служб анонсирования SRM;

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

3.1.3 клиент DNS (DNS client): Служба [программа (или модуль в программе)], предназначенная для получения IP-адреса удаленного компьютера при наличии его доменного адреса.

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

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

3.1.5 оконечное устройство домашней сети; HNED (Home Network End Device, HNED): Устройство, подключенное к IP-сети через интерфейс IPI-1, являющееся отправителем потока или приемником потока.

Примечание - HNED обеспечивает функции навигации и визуализацию контента DVB-IPTV.

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

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

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

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

3.1.10 провайдер службы контента; CSP (Content Service Provider, CSP): Объект, который приобретает, лицензирует контент у провайдеров контента и упаковывает контент в службу.

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

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

3.1.12 транспортный поток с полной SI (traffic flow with full service information): Транспортный поток со встроенной служебной информацией, за исключением таблицы сетевой информации NIT.

3.1.13 транспортный поток с дополнительной SI (traffic flow with additional service information): Транспортный поток с PSI MPEG (таблицы PAT и PMT).

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


CDS

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

CP

- защита контента (Content Protection);

CPCM

- управление защитой копирования контента (Content Protection Copy Management);

DNG

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

DNS

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

DSCP

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

DSM

- динамическое управление службой (Dynamic Service Management);

DSMM

- администратор динамического управления службой (Dynamic Service Management Manager);

DVB

- вещательное цифровое телевидение (Digital Video Broadcastitng);

DVB-IPTV

- вещательное цифровое телевидение по каналам с IP-протоколами;

DVBSTP

- транспортный протокол DVB SD&S (DVB SD&S Transport Protocol);

IEEE

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

FCC

- быстрая смена каналов (Fast Channel Change);

FDT

- таблица доставки файла (File Delivery Table);

FLUTE

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

FUS

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

GET

- метод GET протокола HTTP, используемый для запроса содержимого ресурса;

HNS

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

IGMP

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

IPI

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

IPTV

- IP-телевидение (Internet Protocol Television);

IPv4

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

IPv6

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

LMB

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

MAC

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

MD5

- контрольная сумма файла (Checksum of the file);

QoS

- качество услуг (Quality of Services);

RMS

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

SAP

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

SDP

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

SD&S

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

SRM

- сообщение обновлении системы* (System Renewability Message);


ToS

- тип услуги (Type of Service);

TSI

- идентификатор сеанса транспорта (Transport Session Identifier);

TV

- телевидение (Television);

TVA

- система TV Anytime (TV Anytime);

URI

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

URL

- универсальный указатель ресурсов (Uniform Resource Locator);

XML

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

multicast

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

unicast

- режим передачи (доставки, загрузки, источника передачи) служб, сеансов, потоков, каналов, протоколов, файлов одному получателю или адресу.


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


4.1 Классификация типа данных

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

Метод классификации основан на модели дифференцированных служб, в соответствии с которой IP-пакеты, проходящие через интерфейс IPI-1, должны быть маркированы в источнике исходящих данных в соответствии с подразделом 4.2.


4.2 Маркировка пакетов кодовых точек дифференцированных служб

Для маркировки дифференцированных служб в 8-битовых полях заголовка IPv4 Type of Service или заголовка IPv6 Traffic Class размещается 6 битов поля DS, с помощью которых осуществляется динамическое управление защитой дифференцированных служб (DSCP). Допускается для IPv4 размещать маркировку приоритета служб в 3-битовом поле DSCP.

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

Таблица 1 - Маркировки дифференцированных служб


Тип трафика

Значение DSCP IP

Приоритеты IP

Канал передачи речи (см. примечание 1 к таблице)

0b110000

0b110

Видеоканал в реальном времени (высокий приоритет) (см. примечание 2 к таблице)

0b100010

0b100

Видеоканал в реальном времени (низкий приоритет) (см. примечание 2 к таблице)

0b100100

0b100

Сигнализация, речь и видео

0b011010

0b011

Данные с негарантированной доставкой

0b000000

0b000

Примечания

1 Канал передачи речи гарантирует отсутствие помех в службах DVB-IPTV.

2 Обычная маркировка для видео в реальном времени.

3 Маркировка позволяет CSP считать, что некоторые видеопакеты менее важны, чем другие.


4.3 Приоритет в локальных сетях Ethernet

Интерфейс IPI-1 HNS на уровне МАС-сегмента сети Ethernet должен поддерживать спецификацию параметров и требований мостовой передачи виртуальных сетей IEEE 802.1Q согласно конкретным классам приоритета пользователя. Поле, соответствующее алгоритму прозрачного моста IEEE 802.1D, следует поддерживать в кадре Ethernet. В маркировке должно быть использовано DSCP сообразно подразделу 4.1.

В таблице 2 представлены значения DSCP и маркировки кодов приоритета в соответствии с алгоритмом IEEE 802.1D.

Таблица 2 - Значения DSCP и маркировки кодов приоритета по алгоритму IEEE 802.1D


Тип трафика

Значение DSCP IP

Коды приоритета по IEEE 802.1 D

Канал передачи речи (см. примечание к таблице)

0b110000

0b110

Видеоканал (высокий приоритет)

0b100010

0b100

Видеоканал (низкий приоритет)

0b100100

0b100

Сигнализация видео

0b011010

0b011

Данные с негарантированной доставкой

0b000000

0b000

Примечание - Канал передачи речи гарантирует отсутствие помех в службах DVB-IPTV.


Для HNS на основе MAC Ethernet значения DSCP IP используют для отображения типа трафика в соответствующих кодах приоритета алгоритма сетевого моста IEEE 802.1D. Пакеты должны быть маркированы параметрами уровня 2 класса службы качества. Маркировку размещают в битах поля приоритета пользователя согласно алгоритму IEEE 802.1D, которое размещено в заголовке спецификации IEEE 802.1Q. Маркировка может быть отображена в битах приоритета IP/DSCP в байте типа службы обслуживания заголовка IPv4.

Заголовок спецификации IEEE 802.1Q добавляет дополнительные 4 байта данных в заголовке кадра Ethernet. 3-битовое поле приоритета по алгоритму IEEE 802.1D входит в одно из полей заголовка согласно спецификации IEEE 802.1Q. Любое коммутационное устройство, которое реализует спецификацию IEEE 802.1Q, может использовать поле приоритета пользователя для определения того класса планирования, к которому принадлежит пакет.

Поле приоритета IP (3-битовое) записывается в поле (3-битовое) приоритета пользователя.


5 Доставка сообщений возобновления систем защиты контента через сети IP


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

Защита контента системами СР обеспечена возобновлением (обновлением) тех частей системы в оборудовании пользователя, которые были скомпрометированы и не гарантировали предотвращения неприемлемого использования контента. Информация об обновлении передается в оборудование пользователя в форме сообщений об обновлении системы SRM, например доставляется в форме частей медиаконтентов DVB.

DVB для передачи SRM через вещательные сети используют транспортный поток MPEG-2. Ниже будут определены параметры доставки SRM для HNED непосредственно по IP-адресу при внеполосной доставке медиа.

Примечание - Служба доставки SRM не нормирует технологию обеспечения безопасности объявления и загрузки SRM. Служба доставки SRM не гарантирует доставку для HNED последнего правильного SRM.


5.2 Функциональная архитектура доставки SRM

На рисунке 1 показана функциональная архитектура доставки SRM.

Архитектура включает логические интерфейсы между функциональными компонентами сети SRM и клиентами доставки SRM на HNED. В таблице 3 представлена функциональность интерфейсов SRM.

Таблица 3 - Функциональность интерфейсов SRM


Интерфейс

Функциональность

SRM-1

Анонсирование SRM SD&S

SRM-2

Unicast анонсирования выделенных SRM

SRM-3

Multicast анонсирования выделенных SRM

SRM-4

Unicast загрузки SRM

SRM-5

Multicast загрузки SRM


Эти интерфейсы являются частью интерфейса IPI-1. Нормирование интерфейсов функциональных компонентов сети (в том числе управления и хранения SRM) и между системой доставки SRM в HNED не рассматривается в настоящем стандарте.

Хранилище SRM содержит SRM, которые доставляются в HNED через службы multicast- или unicast-загрузок. Подсистема управления SRM получает SRM от системных администраторов СР, помещает их в хранилище SRM и генерирует информацию об анонсировании SRM. Службы загрузки и анонсирования SRM и функциональность клиента доставки SRM определены в следующих подразделах. Параметры управления хранилищем SRM и управления SRM настоящим стандартом не определены.



Примечание - Все функции, показанные на рисунке 1, являются логическими. Стрелки указывают направление основного потока сообщений.


Рисунок 1 - Функциональная архитектура доставки SRM


5.3 Специальные идентификаторы SRM

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


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


5.3.2 Идентификатор системы СР


SRM выдаются для конкретной системы защиты контента. В системе доставки SRM использован идентификатор системы СР (CP_System_ID).

Для регистрирации CP_System_ID заявители должны предоставлять информацию, необходимую для регистрации CP_System_ID, в соответствии с таблицей 4.

Таблица 4 - Информация для регистрации системы CP_System_ID


Поле регистрации

Описание

Описание системы CP

Наименование системы защиты контента

Спецификатор системы CP

Наименование организации, предоставляющей CPS

Правовой контакт с системой CP

Имя и адрес электронной почты уполномоченного лица, подписавшего спецификатор системы CP

Технический контакт с системой CP

Имя и адрес электронной почты технического контакта спецификатора системы CP


Распределение значений CP_System_ID должно быть выполнено в соответствии с таблицей 5.

Таблица 5 - Распределения значений CP_System_ID


CP_System_ID

Спецификатор CP_System_ID

От 0x0000 до 0x00FF

Зарезервировано для регистрации в системах, определенных DVB

0x0000

Лицензия на контент CPCM DVB

0x0001

Вспомогательные данные CPCM DVB

0x0002

Список отмены CPCM DVB

От 0x0100 до 0xFFFF

Зарезервировано для регистрации через офис проекта DVB


5.3.3 Идентификатор SRM системы CP


Системы защиты контента могут поддерживать различные SRM (например, отличающиеся разными версиями протоколов и разными режимами соответствия). Для поддержки индивидуального анонсирования и загрузки SRM система СР может быть использована в сочетании с ее идентификатором SRM. Идентификатор SRM системы CP должен быть двоичной строкой (шестнадцатиричная кодировка) с максимальной длиной 256 байт. Соответствие идентификатора SRM определено конкретной системой CP. SRM с одинаковыми идентификаторами системы CP должны иметь уникальные идентификаторы SRM, чтобы система доставки SRM могла различать их простым сравнением (одинаковые/неодинаковые).


5.4 Службы анонсирования SRM

5.4.1 Общие правила


Службы анонсирования SRM предоставляют анонсы для служб загрузки SRM или предоставляют указатели на другие службы анонсирования SRM.

В анонсах приведены:

- список идентификаторов системы CP;

- список (опционально) идентификаторов SRM системы CP (см. 5.3), которые поддерживаются службами загрузки SRM или службами анонсирования SRM и информацией о получении доступа к этим службам.

Анонсы SRM могут включать в себя различные типы версий (версия службы анонсирования, версия для записей, версия сеанса FLUTE, версия файла SRM).


5.4.2 Анонсирование SRM SD&S


Точкой входа для служб анонсирования и загрузки SRM является SD&S. Анонсы SRM SD&S предоставляют по заявке на размещение SRM. Запись предложений SRM может напрямую объявлять службы загрузки SRM либо указывать выделенные службы анонсирования SRM.


5.4.3 Выделенные службы анонсирования SRM (интерфейс SRM-1)


Выделенная служба анонсирования SRM предоставляет список служб загрузки SRM для идентификаторов системы CP и SRM.

Выделенные службы анонсирования SRM доставляют рассылки в режиме unicast через HTTP или в режиме multicast с использованием SAP.

Примечание - Для одного идентификатора системы CP или комбинации идентификаторов системы CP и SRM может анонсироваться более одной службы загрузки. Поведение HNED при выборе конкретной службы загрузки в этом случае определено спецификой его реализации.

Выделенные в режиме unicast объявления SRM распределяют с использованием HTTP. Служба предоставляет доставку кодированных XML-файлов SRM записей предложений, использующих схему предложения службы загрузки SRM SD&S. В таблице 6 даны описания элементов записи доставки SRM (SRM Download Record).

Таблица 6 - Описания элементов записи доставки SRM


Имя элемента/атрибута

Описание элемента/атрибута

Условие применения

SRMDownload

Запись доставки SRM

Опциональное

SRMDownloadService (одна запись на службу)

Информация службы доставки SRM

Обязательное


Выделенные службы в режиме unicast анонсирования SRM представлены в SD&S (в виде предложения этой службы). Предложением службы анонсирования SRM является:

- URL анонсирования списка идентификаторов системы CP;

- идентификатор (опционально) SRM системы CP;

- версия используемой службы анонсирования (см. 5.6).

Выделенные анонсы в режиме multicast рассылки SRM распространяются с использованием SAP (интерфейс SRM-3). Служба предоставляет кодированные SDP-записи для загрузки SRM с информацией, определенной в таблице 5.

Из-за ограничений SAP (1 Кбайт на одно сообщение SDP) сообщение SDP должно анонсировать только одну службу загрузки SRM. Каждая служба загрузки SRM должна быть анонсирована отдельным сообщением SDP в одном сеансе в режиме multicast-рассылки SAP Номер версии записи (см. 5.6), предоставленный строкой о = сообщения SDP, используется для указания новой версии сообщения SDP для конкретной службы загрузки SRM.

Выделенные службы в режиме multicast-рассылки SRM анонсируются в SD&S (предложением службы анонсирования SRM), предоставляя в режиме multicast адрес SAP, порт, адрес источника (опционально для источника multicast), список идентификаторов системы CP, SRM системы CP (опционально). Эти данные обрабатываются в режиме multicast службой анонсирования с учетом (опционально) номера версии службы анонсирования (см. 6.6).

HNED должно присоединиться в режиме multicast к сеансу рассылки SAP для доступа к информации об объявлении SRM, распространяемого в этом сеансе.


5.5 Службы загрузки SRM

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


Службы загрузки SRM доставляют SRM для конкретных идентификаторов систем CP в HNED. Служба загрузки прозрачна для контента SRM.


5.5.2 Служба загрузки unicast SRM HTTP (интерфейс SRM-4)


В режиме unicast службы для загрузки файла SRM для конкретного идентификатора системы CP используют HTTP.

SD&S или выделенное предложение анонсирования службы SRM предоставляют URI файла SRM вместе с идентификаторами системы CP и SRM системы CP (опционально), для которых действительны файл SRM и версия файла SRM (см. 5.6.1).

Кодирование контента файлов SRM не обеспечивает. Сервер HTTP может использовать перенаправление на другое расположение сервера или запрашивать задержанный запрос (повторить попытку) с целью предотвращения перегрузки.


5.5.3 Служба загрузки SRM в режиме multicast протокола FLUTE (интерфейс SRM-5)


В режиме multicast для служб загрузки SRM используют протокол FLUTE.

Информацию о сеансе FLUTE [в режиме multicast адрес, порт, TSI, адрес источника (опционально), список идентификаторов системы CP и SRM системы СР (опционально)], номер версии файла SRM, поддерживаемый службой, и номер версии сеанса FLUTE предоставляет SD&S или выделенное предложение анонсирования службы SRM.

Доставка файлов SRM может быть осуществлена в сеансе FLUTE. Сегмент FLUTE SRM работает как динамическая карусель. Это позволяет HNED для получения файла SRM присоединяться к сеансу в любое время. Файлы SRM могут обновляться, а файлы SRM для новых идентификаторов системы CP добавляться во время сеанса.

FDT FLUTE предоставляет:

- идентификатор системы CP;

- идентификатор SRM системы CP;

- номер версии файла SRM для каждого файла SRM.

HNED могут присоединяться к сеансу FLUTE и проверять FDT для идентификатора системы CP, для которых скачивают файлы SRM. Номер версии файла SRM должен увеличиваться при каждом изменении файла SRM для конкретного идентификатора системы CP (см. 5.6.1). Изменение номера версии файла SRM приведет к изменению номера экземпляра FDT Модифицированные версии файлов SRM должны отправляться с другим идентификатором транспортного объекта (TOI).

Структура расширенной таблицы доставки файлов SRM для протокола FLUTE (FDT) и описание элементов записи доставки SRM представлены в таблице 7.

Таблица 7 - Структура расширенной таблицы доставки файлов SRM для FLUTE (FDT). Описания элементов записи доставки SRM


Имя элемента/атрибута

Описание элемента/атрибута

Условие применения

FDT-lnstance-Attributes

Общие атрибуты для всех файлов, описанных в элементе FDT instance

Expires

Время окончания срока действия экземпляра FDT

Обязательно

Complete

В случае присутствия и при установке "true" сигнализирует, что новые данные не будут предоставлены в будущих экземплярах FDT на этом сеансе

Опционально

Content-Type

Тип контента

Опционально

Content-Encoding

Кодирование контента

Опционально

FDT-lnstance-Delivery-Attributes

Атрибуты, связанные с доставкой всех файлов, описанных в элементе FDT

FEC-OTI-FEC-Encoding-ID

Алгоритм идентификации FEC

Опционально

FEC-OTI-FEC-lnstance-ID

Экземпляр FEC в зависимости от идентификации алгоритма FEC

Опционально

FEC-OTI-Maximum-Source-Block-Length

Максимальное количество символов источника для каждого блока источника

Опционально

FEC-OTI-Encoding-Symbol-Length

Длина символа кодирования, выраженная в байтах

Опционально

Атрибуты файла (один на файл)

-

Content-Type

Тип контента медиа MIME

Опционально

Content-Encoding

Компрессирование

Опционально

Content-Location

Расположение файла

Обязательно

Content-Length

Размер контента

Обязательно

Content-MD5

Выходные данные процесса хеширования контента (MD5)

Опционально

CP-System-ID

Идентификатор системы СР файла SRM

Обязательно

CP-System-SRM-ID

Идентификатор SRM системы СР файла SRM (системы СР поддерживают несколько типов файлов SRM)

Опционально

SRM-File-Version

Версия файла SRM для загрузки

Обязательно

Content-Delivery-Attributes

Атрибуты, связанные с доставкой файлов

TOI

Идентификатор транспортного объекта

Обязательно

Transfer-Length

Размер транспортного объекта, переносящего контент

Опционально

Bandwidth-Requirement

Совокупная скорость отправки пакетов во все каналы

Опционально

FEC-OTI-FEC-Encoding-ID

Идентификация алгоритма FEC

Опционально

FEC-OTI-FEC-lnstance-ID

FEC в зависимости от идентификации алгоритма FEC

Опционально

FEC-OTI-Maximum-Source-Block-Length

Максимальное количество символов источника на блок источника

Опционально

FEC-OTI-Encoding-Symbol-Length

Длина символа кодирования, выраженная в байтах

Опционально


Для сеансов FLUTE SRM поддерживается использование только одного канала в режиме multicast.

Для сеансов FLUTE SRM должна поддерживаться компактная схема FEC без кода (FEC Encoding ID 0). Другие схемы кодирования символов для сеансов FLUTE SRM не поддерживаются. Ошибка, возникающая при загрузке файла SRM, может быть восстановлена при повторе файла в карусели. Кодировка контента файлов SRM не поддерживается.


5.6 Версии файла SRM

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


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

- в предложениях в режимах unicast служб загрузки HTTP файла SRM (запись предложения SRM SD&S или запись загрузки SRM);

- FDT FLUTE для каждого файла SRM, поставляемого в режиме multicast службой рассылки FLUTE.

Номер версии файла SRM может быть использован в предложениях службы загрузки для аналогичных служб FLUTE в режиме unicast.

Номер версии файла SRM специфичен для файла SRM выделенного идентификатора системы СР или комбинации идентификаторов системы СР и SRM. Номер версии файла SRM должен увеличиваться (по модулю 256) при каждом обновлении файла SRM.

Номера версий файла SRM в FDT FLUTE и в предложении службы загрузки для аналогичных служб загрузки файлов SRM HTTP в режиме unicast должны совпадать.


5.6.2 Номер версии сеанса FLUTE


Номер версии сеанса FLUTE предоставляется в предложениях служб загрузки в режиме multicast-рассылки FLUTE. Номер версии сеанса FLUTE должен увеличиваться (по модулю 256) каждый раз, когда новые или обновленные файлы SRM становятся доступными через конкретный сеанс загрузки FLUTE.

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


5.6.3 Номер версии записи


Каждая запись предложения SRM SD&S и запись загрузки SRM имеет номер версии записи. Номер версии записи должен увеличиваться (по модулю 256) каждый раз при изменении записи, т.е. появится или новая запись, или обновленное либо удаленное объявление SRM, или предложение служб.

Версия записи предоставляется атрибутом версии в типе OfferingBase SD&S, который используется в записи предложения SDM Offering Record SD&S, в записи загрузки SRM и атрибутом версии сеанса в строке SDP о =.

Номер версии записи сообщает HNED об изменении записи по сравнению с предыдущей принятой версией.


5.6.4 Номер версии службы анонсирования


Каждое предложение службы анонсирования SRM в предложении SRM SD&S может иметь версию службы анонсирования. Выделенная служба анонсирования SRM предоставляет несколько записей загрузки SRM. Номер версии службы анонсирования должен увеличиваться (по модулю 256) каждый раз, когда записи загрузки SRM обновляются, добавляются или удаляются из выделенной службы анонсирования SRM.

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


5.6.5 Номер версии сегмента


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


6 Динамическое управление службой


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

Динамическое управление службой позволяет HNED (пользователям) принимать оптимальные решения при выборе служб из группы эквивалентных служб DVB. Группа эквивалентных служб DVB может включать службы SD, HD, 3D и несколько версий скорости передачи служб.

Функциональность динамического управления службой в настоящем разделе определяет:

- модель данных;

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

- транспорт сообщений, основанный на одноранговой модели (не "клиент-сервер");

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

Адрес диспетчера DSM должен предоставляться в элементе RMSFUSDiscovery SD&S от провайдера служб, поддерживающего DSM. Только один диспетчер DSM доступен для любого предложения служб одного провайдера служб и поэтому будет предоставляться только один адрес диспетчера DSM.

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

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


6.2 Функциональная архитектура DSM

Функциональная архитектура DSM включает в себя:

а) область, находящуюся вне границ спецификации DVB и включающую:

1) головную станцию, содержащую серверы контента IPTV,

2) сеть доставки,

3) диспетчера DSM;

б) область, находящуюся в границах спецификации DVB и включающую:

1) шлюз сети доставки DNG,

2) интерфейс IPI-1,

3) HNED.

HNED DVB реализует функциональность IPTV DVB и содержит блок, выполняющий функции клиента DSM.


6.3 Операционные допущения

Структура модели данных и обмена сообщениями основана на ряде предположений о службах, поддерживаемых головной станцией. К этим службам относятся:

- оборудование DVB, подключенное к сети IP-доставки в доме, управляется головной станцией. Головная станция имеет информацию в реальном времени о статусе всех обслуживаемых ею HNED и всех служб, предоставляемых этим HNED;

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

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

- дом, который может содержать несколько HNED, подключенных к SP через один DNG;

- HNED, которые не могут напрямую связываться друг с другом внутри дома (домашняя сеть типа DVB HN/DLNA);

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

- все настройки, которые будут храниться на сервере, откуда они могут быть запрошены или изменены (если это согласовано с SP), так как HNED не будет поддерживать любую модель данных;

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

- расположение диспетчера DSM, не определяемое в настоящем стандарте;

- единая точка хранения данных DSM, обеспечивающая в диспетчере DSM согласованность состояния HNED и исключающая необходимость частой синхронизации;

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

- метаданные (SD&S, BCG и т.д.), предоставленные любому HNED, которые могут описывать и раскрывать наиболее подходящие экземпляры;

- метаданные SD&S для служб, поддерживающих DSM, которые должны указывать предполагаемое использование службы в расширении поля IPService.


6.4 Схема процесса DSM

На рисунке 2 представлена блок-схема базового процесса DSM: в левой части рисунка 2 показан процесс загрузки HNED; асинхронный обмен сообщениями, необходимый для поддержания синхронизации DSMM-HNED, - в центре блок-схемы; элементы, находящиеся с правой стороны рисунка, иллюстрируют процесс принятия решения, связанный с инициированными HNED действиями.



Рисунок 2 - Блок-схема базового процесса динамического управления службой (DSM)


6.5 Модель данных информации диспетчера DSM

6.5.1 Модель данных DSM


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

Структура модели данных представлена на рисунке 3.

Поддержка службы DSM является опциональной. В активированном состоянии службы DSM диспетчер DSM должен поддерживать все поля в составе службы, a HNED - все элементы модели данных. В таблице 8 представлены профили полей модели данных.



Рисунок 3 - Структура модели данных

Таблица 8 - Профили полей модели данных

Поле

Профиль поля

Условие применения

CustomerlD

В сочетании с HNED_ID поле описывает конфигурацию HNED в доме. При каждом подключении к сети доставки только один идентификатор клиента должен поддерживаться в домене SP

Обязательное (опциональное для DSM001)

TotalAvailable-Bitrate

Указывает общую доступную пропускную способность DNG для служб DVB. DNG подключен к домену SP и к HNED

Обязательное

Service

TypePriority

Поле определяет для HNED приоритет выбранных типов служб. Поддерживаемые типы доставки (DeliveryType): LMB, CoD.

Приоритет полей LMB и CoD определен числами:

1 = высокий приоритет, 2 = низкий приоритет.

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

Опциональное

ContentType-Priority

Приоритет полей SD, HD и 3D определен числами: 1, 2 и 3, 1 имеет высший приоритет, 3 имеет самый низкий приоритет. Если для любого или всех типов значения приоритета не заданы, то неквалифицированные типы внутри этой группы будут иметь равный приоритет со значением 3.

Если значение типа не задано, то этот тип в группе будет иметь приоритет 3.

Значение приоритета может быть установлено HNED (локально) или диспетчером DSM в зависимости от политики для HNED в доме

Опциональное

HNED_ID

Единый идентификатор для каждого HNED в доме выделяет DSMM. Каждое HNED должен иметь только один HNED_ID, уникальный в границах идентификатора CustomerlD.

Эта уникальная строка идентификации позволяет DSMM синхронизировать переговоры при обслуживании нескольких HNED. HNED_ID сохраняется до выключения HNED

Обязательное

HNEDpriority

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

- значение приоритета 1 дает HNED максимальный вес в системе, в любой момент только одно HNED должен иметь приоритет 1, приоритет HNED2 и 3 будет устанавливаться при необходимости отказа от скорости передачи, соответствующей приоритету HNED1;

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

Опциональное

SessionID

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

ServiceBitrates

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

Обязательное

Bitrate

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

Обязательное

Usages

Список способов применения текущей службы. Одна служба может иметь более одного использования, например. FCC и PiP используют один и тот же поток. Доступными способами применения являются: студийное видео, SD, HD, 3D, FCC, PiP, DSMService

Обязательное

ServicelD

Уникальная ссылка для элемента контента текущей службы идентична Textual Identifier, который используется в SD&S, содержащей имена домена и службы

Обязательное

ServicelD.

DomainName

Уникальное доменное имя DNS, зарегистрированное SP, предоставляющего текущую службу, как указано в элементе IPService службы

Обязательное

ServicelD.

ServiceName

Уникальное имя хоста для текущей службы в домене SP в соответствии с предусмотренным в элементе IPService SD&S для службы

Обязательное

EquivalentService

Эквивалентные (альтернативные службы) являются редакционно одинаковыми сточки зрения контента, но отличаются условиями кодирования или доставки. Ссылка на эквивалентную службу является уникальной для службы и идентичной той, которая используется в SD&S. Эквивалентные службы могут быть идентифицированы по элементу Service элемента Package

Обязательное

EquivalentService

ServiceBitrates

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

Обязательное

EquivalentService

Bitrate

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

Обязательное

EquivalentService

Usages

Список вариантов использования эквивалентной службы. Один поток может применяться несколько раз, например: FCC и PiP используют один и тот же поток. Доступными являются: студийное видео, SD, HD, 3D, FCC, PiP, DSMService

Обязательное

Equivalent-ServicelD

Ссылка является уникальной для элемента контента эквивалентной службы и идентичной той, которая используется в SD&S, содержащей имена домена и службы

Обязательное

EquivalentService

DomainName

Уникальное доменное имя DNS, зарегистрированное SP, обеспечивающее эквивалентную службу, как предусмотрено в элементе TextualIdentifier и в элементе IPService SD&S для службы

Обязательное

EquivalentService

ServiceName

Уникальное имя хоста для эквивалентной службы в домене SP, как указано в элементе Textualldentifier и в элементе IPService SD&S для службы

Обязательное

EquivalentServiceLocation

URL подключения, по которому можно найти эквивалентную службу. Используется тип dvb14: ServiceLocation, эквивалентную ServiceLocation, как указано в элементе IPService SD&S

Опциональное


Совместно с полями модели данных, определенных в профилях полей таблицы 8, для поддержки последовательности сообщений DSM используют дополнительные поля. Эти поля сохраняются только на интервале жизни последовательности сообщений DSM. Определения дополнительных полей поддержки последовательности сообщений DSM приведены в таблице 9.

Таблица 9 - Определения дополнительных полей поддержки последовательности сообщений DSM


Имя поля

Определение поля

Количество экземпляров

NegotiationSessionID

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

1 на последовательность событий DSM

ProposedSessionID

Идентификатор сеанса IP, который создается для идентификации службы для предлагаемого изменения. Если это изменение принято, идентификатор ProposedSessionID становится идентификатором SessionID для службы, которая должна быть сохранена в DSMM

1 на предложение службы

RequestedServicelD

Идентификатор службы (имена доменов и служб), которые будут заимствованы из элемента IPService SD&S для этой службы

1 на запрос службы

RequestedServicelD.

DomainName

Уникальное имя домена DNS, зарегистрированное SP, предоставляющее службу, как предусмотрено в элементе Textualldentifier элемента IPService SD&S для службы

1 на запрос службы

RequestedServicelD.

ServiceName

Уникальное имя хоста для службы в домене SP, как указано в элементе Textualldentifier элемента IPService SD&S для службы

1 на запрос службы

ProposedServicelD

Идентификатор службы (имена доменов и служб), которые будут заимствованы из элемента IPService SD&S для службы

1 на предложение службы

ProposedServicelD.

DomainName

Уникальное имя домена DNS, зарегистрированное SP, предоставляющее службу, как предусмотрено в элементе Textualldentifier элемента IPService SD&S для службы

1 на запрос службы

ProposedServicelD.

ServiceName

Уникальное имя хоста для службы в домене SP, как указано в элементе Textualldentifier элемента IPService SD&S для службы.

1 на запрос службы

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


6.5.2 Эквивалентные службы


К эквивалентным службам относятся службы с одинаковым редакционным контентом. Совокупности эквивалентных служб могут принадлежать единой службе пакетов, что позволяет связывать их вместе. Используя идентифицирующие их TextuallD, диспетчеры DSM могут идентифицировать тип IPService (IP, вещание и т.д.).


6.6 Обеспечение эффективности службы DSM

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

Эффективность службы DSM обеспечивается оценкой жизнеспособности соединения служб, которая предоставляется HNED в расширении DSM для SD&S и выполняется с учетом ограничения доступа к сети. Ограничения доступа к сети определены максимальной скоростью передачи, необходимой для выбранной службы. Эта оценка жизнеспособности поддерживается повторным профилированием элемента MaxBitrate элемента IPService как обязательного для служб, поддерживающих DSM.

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

Таблица 10 - Набор сообщений DSM


Тип сообщения

Направление передачи

Цель сообщения

Комментарий

DSM001 - DSM004

-

Сообщения для идентификации и установки приоритета, передаваемые во время загрузки

-

DSM001

От HNED к DSMM

Идентификатор запроса по HNED при загрузке

HNED запрашивает идентификатор от диспетчера DSM. Это сообщение интерпретируется DSMM как метод анонсирования переключения HNED в активное состояние из состояния Off

DSM002

От DSMM к HNED

Назначение идентификатора

Идентификация HNED до повторной загрузки

DSM003

От HNED к DSMM

Передача предварительно назначенных параметров HNED к DSMM при загрузке

Комментарий отсутствует

DSM004

От DSMM к HNED

Подтверждение приема HNED параметров от DSMM

Комментарий отсутствует

DSM101

-

Асинхронная доставка служб и обновления состояния HNED от DSMM

Комментарий отсутствует

DSM101

От DSMM к HNED

Синхронизация настроек состояния всех HNED. Доступная скорость передачи

Отправляется после идентификации HNED. Предназначено для всех HNED при изменении доступной скорости передачи для дома

DSM201 -DSM206

-

Сообщения, связанные с выбором службы

Используется, если для доставки запроса HNED 2 существует некорректная скорость передачи

DSM201

От HNED к DSMM

Запрос на изменение соединения

Сообщение от HNED к DSMM на установление нового соединения или на изменение соединения при сохранении скорости передачи

DSM202

От DSMM к HNED

Изменить запрос от HNED DSM201

Отправлено к HNED с предложением DSMM о изменениях с указанием содержания предложения

DSM203

От HNED к DSMM

Изменить принять/ отклонить

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

- 0 - принятие изменения;

- 1 - отмена изменения

DSM204

От DSMM к HNED

Изменение подтверждено/ отменено

Отправлено в HNED, где изменение завершено или отменено:

- 0 - изменение подтверждено;

- 1 - изменение отменено

DSM205

От HNED к DSMM

Уведомление об изменении службы

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

DSM206

От HNED к DSMM

Изменение службы завершено

Отправлено диспетчеру DSM для синхронизации состояния DSM о завершении изменения службы, в котором DSMM не участвовал, при отсутствии необходимости в сеансе DSM для подключения к службе

DSM301 -DSM308

-

Сообщения данных

Используются пары параметр - значение

DSM301

От HNED к DSMM

Значение запроса

Используется HNED для запроса настроек любого поля в сохраненной структуре данных в DSMM. Аргумент будет запрашиваемым полем. Допускается запрашивать несколько полей, разделенных пробелом. По запросу QueryValue без аргумента должны возвращаться все значения, хранящиеся для этого HNED

DSM302

От DSMM к HNED

Возвращаемое значение

Диспетчер DSM должен возвращать значения запрошенных полей

DSM303

От HNED к DSMM

Установление значения

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

DSM304

От DSMM к HNED

Установление параметра

Сообщение от DSMM для каждого запроса об изменении значения поля, подтверждающее установку нового значения параметра

DSM305

От DSMM к HNED

Значение запроса

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

DSM306

От HNED к DSMM

Возвращаемое значение

HNED должен возвращать значения запрошенных полей

DSM307

От DSMM к HNED

Установленное значение

Позволяет DSMM устанавливать значения параметров в любом конкретном HNED

DSM308

От HNED к DSMM

Завершенная транзакция

Указывает на то, что транзакция завершена


6.7 Параметры структуры сообщений и передачи сообщений

6.7.1 Структура сообщений


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

- все субэлементы должны быть сгруппированы совместно с их родительскими элементами;

- совокупность сообщений DSM от диспетчера DSM к HNED и от HNED к диспетчеру DSM может быть объединена в одну строку полезной нагрузки HTTP (HTTPS). Ответ от диспетчера DSM на запрос DSM001 от HNED может включать в себя последовательность сообщений типов DSM002 и DSM101, а также DSM004, если диспетчер DSM устанавливает приоритет HNED. При передаче нескольких сообщений DSM все элементы каждого сообщения DSM должны быть перечислены совместно.


6.7.2 Передача сообщений


Обмен сообщениями осуществляется между одним HNED (комбинацией идентификаторов CustomerlD и HNED_ID) и диспетчером DSM. Сообщения должны передаваться через HTTP или HTTPS. Во всех обменах сообщениями должен быть использован метод HTTP GET. Для доставки сообщений DSM применена одноранговая модель, поэтому ответ HTTP не используется для переноса сообщения ответа DSM. Сообщение ответа DSM переносится при использовании другого сообщения HTTP GET.

Сообщения HTTP должны содержать сообщения DSM, определенные в 6.6 и 6.7 и в соответствии с условиями, определенными в 6.7.


6.7.3 Схема сообщений HTTP


Элементы сообщения должны иметь префикс с использованием зарезервированных символов следующим образом:

Message type prefixed by "?"

Message elements prefixed (hierarchically) as:

Main identifiers (CustomerlD, HNED_ID, NegotiationID) prefixed by "$"

Element pre-fxed by "&"

Message terminated by ";;"

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

http://’SourceAddress:[<port]’?’<MessageType>{’$Customerld=’<string>}

{’$HNED_ID=’<string>} {’$NegotiationSessionlD=’<value>}

{’&’<Element> ’=’<value>}{’&’<Element> ’=’<value>}{’&’<Child-element >’=’<value>}

{’&’<Child-element >’=’<value>}{’&’<Element>’=’<value>}’;;’

Где:

SourceAddress = address

port = associated port number (optional)

MessageType = DSM message identifier, e.g. dsm101

CustomerlD as is not required for all messages

HNED_ID is not required for all messages

NegotiationSessionID = NegotiationID is not required for all messages and may not be present

<Element> = Element-name as defined in clause 13.7 or as used during a DSM negotiation

<value> = Value or as used during a DSM negotiation

’;;’ = Message terminator

Например, сообщение DSM001 может иметь следующий вид:

’http://SourceAddress:[port]?MessageTtype=DSM001$NegotiationSessionlD=ASDF1234

[$HNEDPriority=’2];;

Сообщение DSM306, возвращающее значение параметра, следующего за запросом, может быть:

’http://SourceAddress:[port]?MessageType=DSM306$CustomerlD=5678ad

$HNED_ID=qwerty1 $NegoiationlD=123098 &TotalDSMBitrate=3500500;;

Композитное сообщение, содержащее DSM 002 и DSM101, может быть:

’http://SourceAddress:[port]?MessageType=DSM002$CustomerlD=5678ad$HNED_

ID=qwerty1 $Negoiationl

D=123098?DSM101$CustomerlD=5678ad$HNED_ID=qwerty1$HNEDPriority=2$ServiceTypePriority=1$C

ontentModePriority=2$TotalAvailableBitrate=400050050;;


6.8 Процесс установки идентификатора HNED

Процесс установки идентификатора HNED (HNED_ID) выполняется для каждого HNED, размещенного в доме, исходя из того, что только один диспетчер DSM может предлагать службы.

Процесс установки HNED_ID происходит в нижеприведенной последовательности и при следующих условиях:

а) HNED выполняет стандартный процесс загрузки IP-адресов для подключения к службе провайдера служб SD&S;

б) HNED получает запись RMSFUSDiscovery из записи SD&S;

в) элемент DSMProvider элемента RMSFUSDiscovery SD&S от провайдера служб, поддерживающего DSM, должен содержать адрес диспетчера DSM;

г) обмен HNED_ID выполняется в одном из вариантов:

1) если HNED_ID предварительно не назначен, HNED запрашивает информацию HNED_ID от диспетчера DSM, используя сообщение DSM001. Диспетчер DSM возвращает информацию HNED_ID по запросу с помощью сообщения DSM002,

2) если HNED_ID предварительно назначен, HNED передает информацию о HNED_ID диспетчеру DSM сообщением DSM003. Прием этого HNED_ID будет подтвержден диспетчером DSM сообщением DSM004;

д) диспетчер DSM отправляет в HNED сообщение синхронизации состояния DSM101;

е) пользователь выполняет ввод HNED в эксплуатацию.


УДК 621.397.132.129: 006.354

ОКС 33.170


Ключевые слова: DVB-IPTV, провайдер, DVBSTP, MPEG-2, LMB, CoD, CDS, метаданные, DNS, домен, точка входа