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

        ГОСТ Р 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 В настоящем стандарте применены следующие сокращения:

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 - Маркировки дифференцированных служб

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

Для 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

Эти интерфейсы являются частью интерфейса 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_System_ID должно быть выполнено в соответствии с таблицей 5.

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

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

Выделенные службы в режиме 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

Для сеансов 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 - Профили полей модели данных

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

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

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

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 в эксплуатацию.