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

(утв. и введен в действие Приказом Росстандарта от 26.10.2021 № 1317-ст)

Утвержден и введен в действие

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

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

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

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

Настоящий стандарт предусматривает расширение набора спецификаций ГОСТ Р 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 Broadcasting);

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 на уровне MAC-сегмента сети Ethernet должен поддерживать спецификацию параметров и требований мостовой передачи виртуальных сетей IEEE 802.1Q согласно конкретным классам приоритета пользователя. Поле, соответствующее алгоритму прозрачного моста IEEE 802.1D, следует поддерживать в кадре Ethernet. В маркировке должно быть использовано DSCP сообразно подразделу 4.1.

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

Значения DSCP и маркировки кодов приоритета по алгоритму

Тип трафика	Значение DSCP IP	Коды приоритета по IEEE 802.1D
Канал передачи речи (см. примечание к таблице)	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 Общие положения

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

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

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

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

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

Таблица 3

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

Интерфейс	Функциональность
SRM-1	Анонсирование SRM SD&S
SRM-2	Unicast анонсирования выделенных SRM
SRM-3	Multicast анонсирования выделенных SRM
SRM-4	Unicast загрузки SRM
SRM-5	Multicast загрузки SRM

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

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

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

Поле регистрации	Описание
Описание системы 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 системы CFP

Системы защиты контента могут поддерживать различные SRM (например, отличающеся разными версиями протоколов и разными режимами соответствия). Для поддержки индивидуального анонсирования и загрузки SRM система CP может быть использована в сочетании с ее идентификатором 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

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

Имя элемента/атрибута	Описание элемента/атрибута	Условие применения
SRMDownload	Запись доставки SRM	Опциональное
SRMDownloadService (одна запись на службу)	Информация службы доставки SRM	Обязательное

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

Из-за ограничений SAP (1 Кбайт на одно сообщение SDP) сообщение SDP должно анонсировать только одну службу загрузки SRM. Каждая служба загрузки SRM должна быть анонсирована отдельным сообщением SDP в одном сеансе в режиме multicast-рассылки SAP. Номер версии записи (см. 5.6), предоставленный строкой o = сообщения 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 системы CP (опционально)], номер версии файла SRM, поддерживаемый службой, и номер версии сеанса FLUTE предоставляет SD&S или выделенное предложение анонсирования службы SRM.

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

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

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

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

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

Имя элемента/атрибута	Описание элемента/атрибута	Условие применения
FDT-Instance-Attributes	Общие атрибуты для всех файлов, описанных в элементе FDT instance
Expires	Время окончания срока действия экземпляра FDT	Обязательно
Complete	В случае присутствия и при установке «true» сигнализирует, что новые данные не будут предоставлены в будущих экземплярах FDT на этом сеансе	Опционально
Content-Type	Тип контента	Опционально
Content-Encoding	Кодирование контента	Опционально
FDT-Instance-Delivery-Attributes	Атрибуты, связанные с доставкой всех файлов, описанных в элементе FDT
FEC-OTI-FEC-Encoding-ID	Алгоритм идентификации FEC	Опционально
FEC-OTI-FEC-Instance-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	Идентификатор системы CP файла SRM	Обязательно
CP-System-SRM-ID	Идентификатор SRM системы CP файла SRM (системы CP поддерживают несколько типов файлов SRM)	Опционально
SRM-File-Version	Версия файла SRM для загрузки	Обязательно
Content-Delivery-Attributes	Атрибуты, связанные с доставкой файлов
TOI	Идентификатор транспортного объекта	Обязательно
Transfer-Length	Размер транспортного объекта, переносящего контент	Опционально
Bandwidth-Requirement	Совокупная скорость отправки пакетов во все каналы	Опционально
FEC-OTI-FEC-Encoding-ID	Идентификация алгоритма FEC	Опционально
FEC-OTI-FEC-Instance-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 выделенного идентификатора системы CP или комбинации идентификаторов системы CP и 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 для идентификаторов системы CP и SRM. Если номер версии сеанса FLUTE не указан, HNED должно регулярно проверять сеанс FLUTE с целью обнаружения обновлений.

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

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

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

Номер версии записи сообщает 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.1 Общие положения

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

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

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

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

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

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

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.

Customer { CustomerID TotalAvailableBitrate ServiceTypePriority ContentTypePriority HNED { HNED_ID HNEDpriority Session { SessionID ServiceBitrates { Bitrate Usages { Usage } } ServiceID{ DomainName ServiceName } EquivalentService { ServiceBitrates { Bitrate Usages { Usage } } EquivalentServiceID{ DomainName ServiceName } EquivalentServiceLocation } } } }

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

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

Профили полей модели данных

Поле	Профиль поля	Условие применения
CustomerID	В сочетании с 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, уникальный в границах идентификатора CustomerID. Эта уникальная строка идентификации позволяет 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	Обязательное
ServiceID	Уникальная ссылка для элемента контента текущей службы идентична TextualIdentifier, который используется в SD&S, содержащей имена домена и службы	Обязательное
ServiceID. DomainName	Уникальное доменное имя DNS, зарегистрированное SP, предоставляющего текущую службу, как указано в элементе IPService службы	Обязательное
ServiceID. 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-ServiceID	Ссылка является уникальной для элемента контента эквивалентной службы и идентичной той, которая используется в SD&S, содержащей имена домена и службы	Обязательное
EquivalentService DomainName	Уникальное доменное имя DNS, зарегистрированное SP, обеспечивающее эквивалентную службу, как предусмотрено в элементе TextualIdentifier и в элементе IPService SD&S для службы	Обязательное
EquivalentService ServiceName	Уникальное имя хоста для эквивалентной службы в домене SP, как указано в элементе TextualIdentifier и в элементе 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 на предложение службы
RequestedServiceID	Идентификатор службы (имена доменов и служб), которые будут заимствованы из элемента IPService SD&S для этой службы	1 на запрос службы
RequestedServiceID. DomainName	Уникальное имя домена DNS, зарегистрированное SP, предоставляющее службу, как предусмотрено в элементе TextualIdentifier элемента IPService SD&S для службы	1 на запрос службы
RequestedServiceID. ServiceName	Уникальное имя хоста для службы в домене SP, как указано в элементе TextualIdentifier элемента IPService SD&S для службы	1 на запрос службы
ProposedServiceID	Идентификатор службы (имена доменов и служб), которые будут заимствованы из элемента IPService SD&S для службы	1 на предложение службы
ProposedServiceID. DomainName	Уникальное имя домена DNS, зарегистрированное SP, предоставляющее службу, как предусмотрено в элементе TextualIdentifier элемента IPService SD&S для службы	1 на запрос службы
ProposedServiceID. ServiceName	Уникальное имя хоста для службы в домене SP, как указано в элементе TextualIdentifier элемента IPService SD&S для службы.	1 на запрос службы
Примечание — Применение дополнительных полей поддержки является обязательным.

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

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

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

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

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

Тип сообщения	Направление передачи	Цель сообщения	Комментарий
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 (комбинацией идентификаторов CustomerID и 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 (CustomerID, HNED_ID, NegotiationID) prefixed by «$» Element pre-fxed by «&» Message terminated by «;;»

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

http://'SourceAddress:[<port]'?'{'CustomerId='<string>}{'HNED_ID='}

{'$NegotiationSessionID='}{'&''='}{'&''='}{'&''='} {'&''='}{'&''='}';;'

Где:

SourceAddress = address

port = associated port number (optional)

MessageType = DSM message identifier, e.g. dsm101

CustomerID 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-name as defined in clause 13.7 or as used during a DSM negotiation

= Value or as used during a DSM negotiation

';;' = Message terminator

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

'http://SourceAddress:[port]?MessageTtype=DSM001$NegotiationSessionID=ASDF1234

[$HNEDPriority='2];;

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

'http://SourceAddress:[port]?MessageType=DSM306$CustomerID=5678ad $HNED_ID=qwerty1

$NegotiationID=123098 &TotalDSMBitrate=3500500;;

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

'http://SourceAddress:[port]?MessageType=DSM002CustomerID=5678adHNED_ID=qwerty1$NegotiationI

D=123098?DSM101CustomerID=5678adHNED_ID=qwerty1HNEDPriority=2ServiceTypePriority=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;

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

---