allgosts.ru33.170 Теле- и радиовещание33 ТЕЛЕКОММУНИКАЦИИ. АУДИО- И ВИДЕОТЕХНИКА

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

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

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

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР 59800— 2021



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

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

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

Часть 1

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

[ETSI TS 102 034 V2.1.1 (2016-04), NEQ]

Издание официальное

Москва Российский институт стандартизации 2021

Предисловие

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

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

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

  • 4 Настоящий стандарт разработан с учетом основных нормативных положений документа Европейского института по стандартизации в области телекоммуникаций (ETSI) ETSI TS 102 034 V2.1.1 (2016-04) «Телевидение вещательное цифровое. Транспорт услуг DVB на основе MPEG-2 TS по 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 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

© Оформление. ФГБУ «РСТ», 2021

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

Содержание

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

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

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

  • 4 Структура системы DVB-IPTV. Архитектура системы DVB-IPTV

  • 4.1 Введение

  • 4.2 Домены в системе DVB-IPTV

  • 4.3 Домен домашней сети

  • 4.4 Стек протоколов DVB-IPTV

  • 5 Требования к процессу обнаружения служб DVB-IPTV

  • 5.1 Введение

  • 5.2 Метаданные служб

  • 5.3 Процесс выбора служб

  • 5.4 Механизмы передачи информации

  • 5.5 Кодирование сегментов

ГОСТ Р 59800—2021

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

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

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

Часть 1

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

Digital Video Broadcasting (DVB). Extended technical requirements for transmission transport flows of DVB services over networks with The IP protocols. Part 1. Detecting a service for transmission over networks with IP protocols

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

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

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

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

  • - технологии IPv6;

  • - регионализации служб DVB;

  • - службы обновления.

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

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

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

ГОСТ 7.67 Система стандартов по информации, библиотечному и издательскому делу. Коды названий стран

ГОСТ 7.75 Система стандартов по информации, библиотечному и издательскому делу. Коды наименований языков

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

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

ГОСТ Р 54995 Телевидение вещательное цифровое. Требования к кодированию аудио и видеосигналов для приложений вещания, основанных на транспортных потоках MPEG-2. Общие технические требования

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

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

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

Издание официальное

ГОСТ Р ИСО/МЭК 7498-1 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель

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

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

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

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

      • 3.1.2 дом (домашняя платформа) (home): Месторасположение, в котором завершена домашняя сеть и в котором находится соединение с полным комплектом оборудования сети.

Примечания

  • 1 Термин «месторасположение» используется в логическом смысле. Термины «дом» и «клиент» в контексте настоящего документа являются синонимами.

  • 2 Домашняя платформа клиента — это домен, в котором используются аудиовизуальные службы. Домашняя платформа клиента является завершением сети доступа, в которой выполнено соединение с комплектом оборудования клиента. Термины «дом», «клиент», «пользователь» являются синонимами в контексте настоящего стандарта.

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

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

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

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

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

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

  • 3.1.6 пользователь (user): Оконечная система.

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

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

  • 3.1.8 провайдер контента (content provider): Организация, которая владеет лицензией на контент или продает его, или имеет лицензию на предоставление исходных описательных метаданных.

  • 3.1.9 провайдер сети доставки (delivery network provider): Объект, соединяющий клиентов и провайдеров служб.

  • 3.1.10 провайдер службы; SP (service provider, SP): Организация, предоставляющая службы клиенту DVB-IPTV.

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

  • 3.1.12 служба DVB-IPTV (Digital Video Broadcasting Internet Protocol TeleVision service): Одна или несколько программ, передаваемых по IP, под управлением провайдера службы. Программы для прямого потребления могут быть доступны при передаче по расписанию по требованию или для локального хранения при работе службы загрузки контента (Content Download Service; CDS).

  • 3.1.13 транспортный поток (traffic flow): Транспортный поток со встроенной служебной информацией.

  • 3.1.14 шлюз сети доставки; DNG (Delivery Network Gateway, DNG): Устройство, которое соединяет домен домашней сети с сетью доступа. Это может быть устройство, соединяющее сети на первом уровне модели взаимодействия открытых систем (Open Systems Interconnection; OSI). DNG может функционировать в качестве моста или маршрутизатора, связывающего устройства канального уровня различных технологий. DNG может функционировать на четвертом и более высоких уровнях OSL

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

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

  • ТП — транспортный поток со встроенной служебной информацией;

  • AL-FEC — уровень приложения прямого исправления ошибок (Application Layer Forward Error Correction);

ASM — любой источник multicast-доставки (Any Source Multicast);

BGD — устройство шлюза вещания (Broadband Gateway Device);

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

CA — гражданский адрес (Civic Address);

CoD — контент по требованию (Content on Demand);

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

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

ной суммы. Предназначен для проверки целостности данных (Cyclic Redundancy Check);

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

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

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

DVB — телевидение вещательное цифровое (Digital Video Broadcasting);

DVB-HN — домашняя сеть телевидения вещательнго цифрового (DVB Home Network);

DVB-IPTV — телевидение вещательное цифровое по каналам с IP-протоколами (Digital Video Broadcasting Internet Protocol TeleVision);

DVBSTP — транспортный протокол (DVB SD&S);

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

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

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

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

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

GZIP — утилита компрессии и декомпрессии файлов, использующая алгоритм Deflate (GnuZIP);

HN — домашняя сеть (Home Network);

HTTP — протокол передачи гипертекста (HyperText Transfer Protocol);

IANA

— администрация адресного пространства Интернет (совет по регистрации доменов интернет) (Internet Assignet Numbers Authority);

IGMP

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

IPv4

IPv6

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

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

IPI

IPTV

ITU

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

  • — IP-телевидение (Internet Protocol TeleVision);

  • — Международный союз по телекоммуникациям (International Telecommunication Union);

ITU-T

— Международный союз по телекоммуникациям — сектор стандартизации электросвязи (International Telecommunications Union — Telecommunication Standardization Sector);

LMB

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

MBwTM

MLD

— вещание медиа в режиме Trick (Media Broadcast with Trick Modes);

— обнаружение multicast-слушателей (Multicast Listener Discovery);

MPEG

MPEG-2 -

  • — группа экспертов по движущимся изображениям (Moving Pictures Expert Group);

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

NTP

OSI

PAT

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

  • — модель взаимодействия открытых систем (Open Systems Interconnection);

  • — таблица взаимосвязи (ассоциации) программ (Program Association Table);

PMT

POST

— таблица структуры программы (Program Map Table);

— метод запроса, поддерживаемый HTTP;

PSI

RET

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

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

RMS

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

RR

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

RTP

SAP

  • — протокол передачи в реальном времени (Real Time Protocol);

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

SDP

SD&S

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

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

SI

SOAP

  • — служебная информация (Service Information);

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

SRM

SRV

SSRC

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

  • — отчет получателя DNS (SeRVice, specific DNS RR);

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

TCP

TV

— протокол управления передачей (Transmission Control Protocol);

— телевидение (Tele Vision);

UDP

URI

— протокол передачи дейтаграмм пользователя (User Datagram Protocol);

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

URL

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

XML

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

href — элемент протокола передачи гипертекста (HyperText Transfer Protocol, HTML), задающий адрес документа, на который указывает ссылка;

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

pull — режим получения информации по запросу;

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

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

unicast — режим передачи (доставки, загрузки, источника передачи) только одному получателю (адресу).

  • 4 Структура системы DVB-IPTV. Архитектура системы DVB-IPTV

    • 4.1 Введение

В настоящем стандарте рассматриваются процессы открытия (обнаружения) служб, выбора и доставки служб с последующим формированием списка служб с информацией, позволяющей пользователю выбрать необходимую службу: вещание медиа (Live Media Broadcast; LMB), вещание медиа в режиме Trick (Media Broadcast with Trick Modes; MBwTM), контент по требованию (Content on Demand; CoD) или CDS с последующей доставкой одной из этих служб через интерфейс оконечного устройства домашней сети IPI-1 на HNED.

При необходимости интерфейс оконечного устройства домашней сети IPI-1 может применяться для доставки контента и метаданных в домашнюю сеть телевидения вещательнго цифрового (DVB Home Network; DVB-HN) с целью управления и использования их устройствами, работающими в составе DVB-HN.

  • 4.2 Домены в системе DVB-IPTV

В ГОСТ Р 54994—2012 (раздел 4, рисунок 1) показаны четыре идентифицированных домена и связи между ними, необходимые для функционирования системы доставки служб DVB-IPTV оконечному домашнему устройству. Домены в системе DVB-IPTV показаны во взаимосвязи с моделью уровней OSI по ГОСТ Р ИСО/МЭК 7498-1.

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

К службам DVB-IPTV могут иметь отношение провайдеры служб различных типов, например провайдеры службы Интернет (Internet Service Provider; ISP) и провайдеры службы контента (Content Service Provider; CSP). CSP приобретает и лицензирует контент и метаданные от одного или нескольких провайдеров контента и упаковывает их в службу.

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

В домашней сети может функционировать несколько HNED, при этом каждое HNED может действовать как оконечная точка. Допускается совместное использование контента DVB-IPTV и метаданных в домашней сети (Home Network; HN) через устройства, находящиеся внутри этой сети. Такая локальная система совместного использования контента специфицирована DVB в сети DVB-HN (см. ГОСТ Р 54994).

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

  • 4.3 Домен домашней сети

    4.3.1 HNED, оконечная точка в сети доставки служб DVB

    В настоящем стандарте концепция домена домашней сети ограничивается физической домашней сетью, которая соединяет HNED с сетью доступа вещания через DNG сети доставки, в которой HNED является оконечной точкой в системе DVB-IPTV. Допускается подключение нескольких HNED к одному шлюзу сети доставки (Delivery Network Gateway, DNG). Детали функциональных возможностей DNG в настоящем стандарте не раскрываются.

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

Домен домашней сети, состоящий из DNG и HNED, позволяет пользователям домашней сети:

  • - одновременно подключаться к нескольким разнородным сетям доставки, но сама домашняя сеть может подключаться к сети доступа только через один DNG;

  • - выбирать провайдера служб DVB-IPTV, используя доступные возможности связи и метаданных. Провайдеры службы Интернет (ISP) и провайдеры службы контента (CSP) могут быть независимыми друг от друга;

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

  • - иметь доступ к контенту DVB из сети доставки DVB-IPTV, используя несколько оконечных HNED в доме.

  • 4.3.2 Обмен контентом в домашней сети DVB (DVB-HN)

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

Интерфейс IPI-1 DVB не зависит от интерфейса IPI-HN DVB. Оба интерфейса могут сосуществовать в одном физическом домашнем сетевом домене и на одном физическом интерфейсе устройства, подключенного к домашней сети. Физические устройства могут сочетать функцию HNED DVB и любую логическую функцию HN DVB.

  • 4.3.3 Потоки служб высокого уровня в сети DVB-IPTV

С основными службами IPI-1, указанными в настоящем стандарте, связаны следующие службы высокого уровня:

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

  • - подключение и потоковая передача службы LMB;

  • - выбор служб CoD и MBwTM, потоковой передачи и управления потоковой передачей служб CoD и MBwTM;

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

После получения HNED адреса IP оконечное устройство функционирует в следующей последовательности:

  • - этап 0: HNED получает [при использовании службы удаленного управления и встроенных программ (Remote Management and Firmware; RMS) и службы обновления встроенного программного обеспечения (Firmware Update Service; FUS)] право на установку необходимой конфигурации;

  • - этап 1: HNED выполняет процесс обнаружения провайдера служб [например, через механизм обнаружения и выбор службы (Service Discovery and Selection; SD&S) или через DHCP] и подключается к точке входа механизма SD&S;

  • - этапы 2 и 3: HNED обнаруживает службы, подключаясь к серверу SD&S конкретного провайдера служб или получая информацию от сервера доставки контента (опционально).

После получения всех необходимых метаданных HNED может подключаться к следующим службам провайдера служб DVB-IPTV:

  • - к службе вещания LMB, при multicast-передаче и в последующем — к потоковой передаче;

  • - к серверу CoD (с использованием RTSP) с последующим использованием unicast-контента;

  • - к службе загрузки контента (unicast или multicast), с последующим использованием контента.

Примечание — Настоящий стандарт не описывает реализацию в системе DVB-IPTV всех служб, определенных в настоящем стандарте, или всех служб, поддерживаемых HNED с интерфейсом IPI-1.

  • 4.4 Стек протоколов DVB-IPTV

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

Верхний уровень стека содержит предложения служб и приложений. Уровень стека состоит из программ, информации о программах, multicast и/или unicast IP-адресах.

Уровень промежуточного ПО и функций включает в себя функции поддержки DVB.

На уровне IP-протоколов и протоколов транспорта идентифицируются необходимые протоколы и выполняется связывание этих протоколов с функциями указанных выше уровней.

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

HNED с интерфейсом IPI-1 соответствует требованиям к коммуникационным протоколам канального уровня, сетевого уровня IP и транспортного уровня. HTTP, протокол управления передачей (Transmission Control Protocol; TCP), протокол передачи дейтаграмм пользователя (User Datagram Protocol; UDP) доступны для HNED как сетевые и транспортные протоколы.

RTSP используется для доставки и управления службой CoD, а также для управления доставкой службы вещания LMB. Спецификация этого протокола представлена в ГОСТ Р 54994.

Потоки служебной аудио-, видеоинформации мультиплексируются в транспортный поток MPEG-2. Полученные пакеты мультиплекса MPEG-2 инкапсулируются непосредственно в UDP или в RTP/ UDP для потоковой доставки с маркировкой пакетов DSCP по ГОСТ Р 54994. RTCP используется для передачи клиентам статистики передачи. Протокол управления группами (пользователей) в сети Интернет (Internet Group Management Protocol; IGMP) и обнаружение multicast-слушателей (Multicast Listener Discovery; MLD) применяются для соединения с multicast-потоками и выхода из multicast-потоков в соответствии с ГОСТ Р 54994.

Протокол DHCP используется для настройки HNED на IP-адрес. Служба часов реального времени и служба часов точного сетевого времени реализуются с использованием простого сетевого протокола времени (Simple Network Time Protocol; SNTP) или сетевого протокола времени (Network Time Protocol; NTP).

На первом этапе процедуры загрузки используется файл-заглушка (FUSS), загружаемый по протоколу HTTP для unicast-передачи или полученный от службы multicast, DVBSTP. Этот механизм файла-заглушки заменяет метод агента идентификации.

Протокол HTTP используется для загрузки контента при unicast-доставке.

Протокол доставки файлов при однонаправленной передаче (File Delivery over Unidirectional Transport; FLUTE) используется для загрузки контента при multicast- доставке и unicast-передаче.

Сеансы загрузки контента описываются синтаксисом XML или SDP, а доставка контента осуществляется протоколами HTTP (unicast), SAP (multicast-передача для данных SDP) или DVBSTP (multicast-передача для данных XML).

Для передачи сообщения об обновлении системы (SRM) при unicast доставке используется протокол HTTP, при multicast доставке используется протокол FLUTE. Для доставки сообщения о восстановлении системы используются HTTP (при unicast-доставке) и протокол описания сеанса SAP (при multicast-доставке).

Повышение надежности доставки для RTP обеспечивается использованием уровня приложения прямого исправления ошибок (Application Layer Forward Error Correction; AL-FEC) или повторных передач (RETransmission; RET). Уменьшение времени отклика при переключении служб LMB обеспечивается за счет быстрой смены канала на уровне сервера.

  • 5 Требования к процессу обнаружения служб DVB-IPTV

    • 5.1 Введение

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

  • - текстовых идентификаторов службы;

  • - триплета числовых идентификаторов.

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

Настоящий стандарт нормирует механизмы обнаружения в реальном времени служб LMB, CoD и CDS. Служба вещания LMB может функционировать в двух режимах:

  • - служба вещания с SI DVB, встроенной в поток («ТП с полной SI»);

  • - служба вещания дополнительная SI («ТП с дополнительной SI»).

Для службы вещания «TS полная SI» провайдер служб должен формировать информацию, необходимую пользователю для поиска транспортных потоков по IP. Информацию об отдельных службах пользователь извлекает из транспортного потока использованием SI DVB согласно ГОСТ Р 55697.

В случае службы вещания «ТП с дополнительной SI» пользователь использует PSI транспортного потока MPEG (РАТ и РМТ).

Информацию о службах CoD и CDS и расписание программ для служб LMB предоставляет путеводитель по контенту вещания в соответствии с ГОСТ Р 54994.

Информация об обнаружении службы предоставляется и хранится в виде записей XML и схем XML.

  • 5.2 Метаданные служб

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

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

Синтаксис текстового идентификатора службы соответствует определениям, приведенным в ГОСТ Р 56170:

<service_name>, <service_provider_domain_name>,

где <service_name> — уникальное имя службы в домене провайдера служб;

<service_provider_domain_name> — имя домена в DNS сети Интернет, которым провайдер службы имеет право управлять.

Поле <service_name> является допустимым именем хоста, используемым в DNS сети Интернет.

Триплет числовых идентификаторов <original_network_id>, <transport_stream_id> и <service_id> применяется в соответствии с ГОСТ Р 55697 и позволяет различать службы, переносимые разными сетями.

  • 5.2.1 Этапы процесса обнаружения служб

Этапы процесса обнаружения службы показаны на рисунке 1.

Рисунок 1 — Этапы процесса обнаружения службы

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

Взаимодействие с провайдерами службы начинается с обнаружения точки (или точек) входа в службу (см. 5.2.2).

Обнаружение провайдеров служб DVB-IPTV осуществляется в процессе приобретения информации о провайдерах служб (см. 5.2.3). Провайдеры служб, указанные в 5.2.3, публикуют свои предложения в информацию об обнаружении служб (см. 5.2.4).

  • 5.2.2 Точки входа в процесс обнаружения службы

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

  • - группового адреса 224.0.23.14 (DvbServDisc), зарегистрированного в администрации адресного пространства Интернет (совете по регистрации доменов интернет) (Internet Assignet Numbers Authority; IANA);

  • - списка адресов точек входа SD&S в соответствии с расположением службы через DNS.

Имя службы образуется сочетанием dvbservdsc с именем используемого протокола (tcp или udp) и с именем домена services.dvb.org, поддерживаемого DVB для обнаружения службы. Поиск точки входа может выполняться по одному из адресов, _dvbservdsc._tcp.services.dvb.org или dvbservdsc._udp. services.dvb.org. Необходимым условием успешного поиска точки входа является поддержка HNED клиента DNS отчет получателя DNS (SeRVice; SRV). DVB для обнаружения службы поддерживает доменное имя services.dvb.org. Новые провайдеры служб для включения их в список DNS SRV должны регистрироваться в DVB. HTTP-серверы находятся методами протокола TCP, а адреса multicast-доставки находятся методом протокола UDP.

Подключение HNED к сети производится путем запроса собственного адреса через DHCP в зависимости от используемого IPv4 или IPv6. Адрес может быть предоставлен с именами доменов при использовании опций 15 DHCPv4 или 24 DHCPv6. Список адресов приобретается для точек входа SD&S через DNS в соответствии с расположением службы. Имя службы образуется сочетанием _dvbservdsc с именем используемого протокола (tcp или udp) и именем домена. Необходимым условием успешного поиска точки входа является поддержка HNED клиента DNS SRV.

Если номер порта не указан, то по умолчанию он должен быть установлен 3937 (_dvbservdsc).

Примечания

  • 1 Опция 15 DHCPv4 указывает имя домена, которое клиент должен использовать при разрешении имен хостов через систему доменных имен. Код этой опции — 15. Минимальная длина — 1 байт.

  • 2 Опция 24 DHCPv6 указывает имя домена, которое клиент должен использовать при разрешении имен хостов через систему доменных имен.

  • 3 Механизм DNS может использовать рекурсию, при которой сервер выполняет от имени клиента поиск нужной информации во всей системе DNS, при необходимости обращаясь к другим DNS-серверам.

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

  • - использованием доменных имен, возвращаемых опцией 15 DHCPv4 или опцией 24 DHCPv6 в сочетании с механизмом DNS. Если метод не выдает допустимые доменные имена или дает сообщение об ошибке, то HNED переходит к следующему этапу;

  • - присоединением HNED к групповому адресу, зарегистрированному IANA. Если действительные пакеты DVBSTP не получены в течение двух циклов доставки информации SD&S (максимальный период цикла 30 с), то HNED переходит к выполнению следующего этапа;

  • - если на предыдущем этапе точки входа не были найдены, пользователь должен вручную ввести или URL, или адрес IP, или (опционально) номер порта точки входа.

После получения точки входа HNED должен прекратить поиск новых точек.

  • 5 .2.3 Информация обнаружения провайдера служб

На первом этапе обнаружения службы выполняется обнаружение провайдеров служб DVB-IPTV и получение информации о расположении предложений этих провайдеров. Запись информации обнаружения провайдера служб может содержать агрегированную информацию обнаружения нескольких провайдеров служб. Обнаружение провайдера служб в случае multicast-доставки выполняется при значении «PayloadID», равном 0x01.

  • В таблице 1 приведено описание полей элемента обнаружения провайдера служб ServiceProviderDiscovery.

Таблица 1 — Описание полей элемента обнаружения провайдера служб ServiceProviderDiscovery

Имя

Описание

Указания применения

Service-Provider

Описание провайдеров служб, доступных в записи информации обнаружения провайдера служб ServiceProviderListType

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

Name

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

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

Description

Текстовое описание служб. Допускается несколько описаний на разных языках

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

Offering

Определяет доступные методы доставки и связанные с ними расположения для доставки в режимах «push» и «pull». Элемент Offering используется для передачи расположений, содержащих предложение. Отсутствие элемента Offering означает, что SP не предоставляет службы

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

Атрибут DomainName

Строка, переносящая атрибут domain name

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

Атрибут

Version

Строка транспортирования атрибутов, определяющая ограничения конкретных символов, детализирует номер версии записи Service Provider Discovery Record. Используется для multicast-доставки и идентификации обновления Service Provider Discovery Record

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

Атрибут LogoURI

Атрибут, содержащий универсальный локатор (определитель местонахождения) ресурсов (Uniform Resource Locator; URI) расположения логотипа провайдера служб

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

  • 5.2.4 Информация обнаружения служб DVB-IPTV

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

Базовые типы XML представлены в 5.2.8.

Сложные типы XML-групп атрибутов представлены в 5.2.9.

Комплексные типы XML-групп элементов представлены в 5.2.10.

Основные типы XML, используемые для обнаружения служб и их описания, представлены в 5.2.11.

Запись предложений DVB-IPTV должна содержать поля, определенные в таблице 1, и поля, относящиеся к конкретному предложению провайдера служб. Предложение провайдера служб может включать:

  • - службы LMB (ТП с полной или дополнительной SI);

  • - CoD [через запись обнаружения устройства шлюза вещания (Broadband Gateway Device; BGD)];

  • - службы по ссылке, предоставляемые другими SP;

  • - службы, сгруппированные провайдером служб в пакеты.

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

Тип OfferingBase является основным при формировании всех предложений и относится к сложным типам XML и предоставляет необходимый атрибут типа домена. В таблице 2 представлено описание полей типа OfferingBase.

Таблица 2 — Описание полей типа OfferingBase

Имя

Описание

Указания применения

DomainName

Доменное имя DNS в сети Интернет, зарегистрированное провайдером служб. Это имя уникально идентифицирует провайдера службы. Значение этого поля используется по умолчанию для конкретных полей в записи в соответствии с их семантикой

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

Version

Версия записи предложения DVB-IPTV и номер версии предоставляются при изменении записи предложения DVB-IPTV

Обязательное, если запись предоставляется по запросу (режим pull).

Опциональное, если запись multicast (режим push)

Если провайдер служб предлагает несколько служб вещания, используется элемент Broadcastoffering. Предоставляемые службы сгруппированы в списках служб (ServiceLists), которые представлены экземпляром сложного типа IPServiceList и являются списком служб IP.

Элемент Broadcastoffering используется в двух формах:

  • - ТП с полной SI, когда полная информация о службах DVB, определенная в ГОСТ Р 55697, предоставляется в транспортном(ых) потоке(ах) в расположениях, указанных в записи;

  • - ТП с дополнительной SI содержит в этой записи элемент SI (опциональный), передаваемый в транспортном потоке.

В таблице 3 представлена семантика полей служб IP.

Таблица 3 — Семантика полей служб IP

Имя

Определения семантики полей служб IP

Указания применения

ServiceList

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

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

SingleService

Содержит детализированные параметры и расположение единственной службы IP, предлагаемой провайдером служб

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

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

ServicesDescription

Содержит идентификатор записи BCG для элемента обнаружения BCG, который содержит справочные данные для предложений, сгруппированных в ServiceList, с которым связан этот элемент. Этот тип описан в таблице 18, пункт 6

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

ServiceLocation

Содержит расположение служб, включает в себя информацию об исправлениях ошибок в прямом направлении или службах ретрансляции. Это расположение может быть представлено в multicast-форме или форме RTSP. Этот тип описан в таблице 18, пункт 33

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

Textual Identifier

Текстовый идентификатор службы. Если имя домена отсутствует, то оно извлекается из контекста атрибута DomainName Broadcastoffering (унаследованным от OfferingBase). Этот тип описан в таблице 18, пункт 45

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

DVBTriplet

Триплет службы DVB. Этот тип описан в таблице 18, пункт 8

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

MaxBitrate

Определяет максимальную скорость (кбит/с) потока, переносящего службу, не учитывая потоки FEC и потоки других уровней*

Опциональное. Динамическое управление службой (Dynamic Service Management; DSM).

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

службой DSM

SI

Информация о двух формах службы IP (ТП с полной SI и ТП с дополнительной SI) которые отличаются присутствием этого элемента. Этот тип описан в таблице 18, пункт 34

Опциональное — для службы ТП полная SI. Обязательное — для службы «ТП дополнительная SI»

AudioAttributes

Каждый экземпляр этого элемента указывает способ кодирования звука. Если этот элемент отсутствует, то используется значение по умолчанию MPEG-1 или MPEG-2, уровень 2, с обратной совместимостью, моно или стерео, способ может быть установлен по ГОСТ Р 54995. Формат этого типа определен по ГОСТ Р 56476. Значения, содержащиеся в атрибуте href элемента Coding, должны определяться классификацией, указанной в файле AudioCS

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

Окончание таблицы 3

Имя

Определения семантики полей служб IP

Указания применения

VideoAttributes

Каждый экземпляр этого элемента указывает способ кодирования видео, которое может быть использовано. Если этот элемент отсутствует, используется значение по умолчанию кодированного видео MPEG-2, работающего на МР @ ML с частотой кадров 25 Гц. Это значение определено в ГОСТ Р 54995. Формат этого типа определен в ГОСТ Р 56476. Значения, которые переносятся в атрибуте href элемента Coding, должны определяться классификацией, указанной в файле VideoCodecCS.xml

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

ServiceAvailabilty

Определяет географические регионы, в которых эта служба доступна или недоступна. Этот элемент обеспечивает поддержку регионирования. Он позволяет каждой службе иметь список регионов, с которыми связана служба. По умолчанию все службы доступны во всех регионах. Может использоваться несколько элементов ServiceAvailability, соответствующих нескольким кодам CountryCode. Этот элемент описан в таблице 18, пункт 32

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

Usage

Элемент применяется для определения формы использования этой службы (например, студийное TV, SD, HD, PiP и т. д.). В некоторых случаях возможно указать все варианты, которые можно найти в этой службе IP (IPService). Этот элемент сообщает, что один и тот же контент представляет и другие службы IP и что они будут отображаться как субслужбы IP внутри этой службы IP

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

LinkedService

Содержит субслужбы IP

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

URILinkage

Поддерживает функциональность URILinkage, определенную по ГОСТ Р 55697, которая включает в себя поддержку функций сопровождающих экранов (companion screen)

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

ciAncillaryData

Содержит вспомогательные данные, используемые в идентификаторах (опционально), которые поддерживают функциональность сопровождающих экранов (companion screen)

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

* Другие уровни могут переноситься по одному и тому же адресу групповой доставки.

В таблице 21 приведена запись предложения контента по требованию CoDOffering. Значение PayloadID при multicast-рассылке равно 0x03. Запись CoD содержит необходимую информацию обнаружения серверов CoD и расположения каталога контента. Информация об отдельном контенте не предоставляется. В записи CoD представлена информация о расположении CoD и о расположении описания обнаружения CoD.

Примечание — Для оборудования предыдущих поколений следует использовать BCGOffering, описанный в 5.2.11. Эта запись сохраняется исключительно для обеспечения обратной совместимости.

Доставка с multicast-адресацией CoDOffering применяется для обеспечения обратной совместимости с устаревшими HNED. Для современного оборудования следует использовать запись путеводителя по контенту вещания BCGOffering.

В таблице 4 представлена семантика полей предложения CoDOffering.

Таблица 4 —Семантика полей CoDOffering

Имя

Описание

Указания применения

Catalogue

Описание каталога, в котором может находиться информация о группе элементов контента

Должно присутствовать не менее одной службы

Name

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

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

Description

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

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

Locator (дочерний элемент каталога)

Содержит не менее одного URI для агрегированных описаний контента (каталог/метаданные)

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

Id (атрибут каталога)

Идентификатор провайдера и сервера CoD, этот Id назначается провайдером служб

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

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

При multicast-передаче предложений служб по ссылке значение PayloadID должно быть равно 0x04 (таблица 21).

Определения полей служб по ссылке представлены в таблице 5.

Таблица 5 — Определения полей служб по ссылке

Имя

Определение

Указания применения

ReferencedService-Provider

Группа служб от провайдера Б служб по ссылке, на которые ссылается провайдер А. Тип ReferencedServiceProviderType определен в таблице 18, пункт 24

Должно присутствовать не менее одной службы

@Name [атрибут службы (Service) с элементом ReferencedServicePro-vider]

Имя службы по ссылке. Уникальное имя хоста службы в домене, на который ссылается провайдер А, для каждой службы от провайдера Б. Элемент Service используется в соответствии с 5.2.8

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

При multicast-доставке пакетов служб по предложению PackagedServices провайдер служб группирует службы в пакет, предлагаемый пользователю.

Одна служба может входить в состав разных пакетов служб.

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

Дополнительная информация о службах может быть предоставлена опционально в поле PackageDescription.

Таблица 6 —Определения полей служб PackagedServices

Имя

Определение

Указания применения

PackageName

Текстовое имя пакета служб на одном или нескольких языках. Каждому языковому коду должно присваиваться не более одного имени. Многоязычный тип описан в таблице 18, пункт 17

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

Service

Одна или несколько служб, входящих в пакет служб. Тип описан в таблице 18, пункт 21

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

CountryAvailability

Список стран и/или групп стран, в которых пакет доступен или не доступен. Тип CountryAvailability описан в таблице 18, пункт 5

Устаревшее

PackageDescription

Ссылка на идентификатор записи BCG, которая предоставляет описание контента, доступного в пакете служб. Тип PackageDescription описан в таблице 18, пункт 6

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

PackageReference

Идентификатор пакетов, включенных в текущий пакет служб. Идентификатор переносится как атрибут элемента PackageReference

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

PackageAvailability

Элемент обеспечивает поддержку регионирования. Он позволяет каждому пакету иметь список ориентированных на него регионов. По умолчанию пакет доступен всем регионам. Для каждого CountryCode должно существовать не более одного элемента PackageAvailability. Тип PackageAvailability описан в таблице18, пункт 32

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

URILinkage

Это поле поддерживает функциональность

URILinkage в соответствии с ГОСТ Р 55697, включая поддержку функций сопутствующего экрана. Этот тип раскрывается в таблице 18, пункт 47а

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

ciAncillaryData

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

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

Id (атрибут)

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

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

Visible (атрибут)

Логический индикатор (в сочетании с элементом PackageAvailability) указывает, должен ли данный пакет представляться пользователю при прямом использовании этого пакета. Когда ссылка на пакет указана, атрибут Visible пакета, на который указывает ссылка, должен игнорироваться и используется атрибут Visible ссылающегося пакета. Значение по умолчанию должно быть «true»

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

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

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

При multicast-передаче пакетов служб значение PayloadID должно быть равно 0x05 (таблица 21).

Определения полей служб PackagedServices представлены в таблице 6.

Запись предложения путеводителя по контенту вещания BCGOffering обеспечивает возможность обнаружения расположений BCG, содержащих листинг контента, доступного в реальном времени, при использовании служб CoD или CDS. Провайдер, обнаруженный в этой записи, предлагает службы в соответствии с ГОСТ Р 54994—2012 (подраздел 10.3). При multicast-передаче значение PayloadID должно быть равно 0x6 (таблица 21).

Определения семантики полей BCGOffering представлены в таблице 7.

Таблица 7 — Определения семантики полей BCGOffering

Имя

Определения семантики полей BCGOffering

Указания применения

Name

Имя руководства по контенту вещания, которое представляется пользователю. Формат этого типа определен в таблице 18, пункт 17

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

Description

Текстовое описание путеводителя по контенту вещания

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

TransportMode

Расположение путеводителя по контенту вещания. Формат этого типа определен в таблице 18, пункт 46

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

Logo

URI для логотипа BCG

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

Type

Тип BCG, определяемый как tva: ControlledTermType. Значения типа BCG определены в расширяемой Classificationscheme

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

TargetProvider

Доменное имя провайдера, контент которого описывается данным BCG. Доменное имя должно совпадать с именем домена, представленным в ServiceList

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

BCGProviderName

Имя провайдера BCG. Это поле должно быть идентично текстовой строке атрибута Publisher элемента TVAMain в метаданных BCG. Формат этого типа определен в таблице 18, пункт 17

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

CDSDownloadSession-

DescriptonLocation

Расположение службы multicast-доставки, содержащей информацию описания сеанса в загружаемом файле CDS. Формат этого типа определен в таблице 18, пункт 2

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

@ld

Определяет провайдера/сервер контента вещания. Этот идентификатор назначается провайдером служб

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

©Version

Версия этой записи. Изменение этого значения указывает на изменение одной из записей BCG

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

HNED географически расположено в регионе, который определяют провайдер служб и идентификатор соты. Идентификатор соты является уникальным идентификатором HNED внутри страны. Расположение HNED может быть определено по коду страны и идентификатору соты. Идентификатор соты используется в элементе ServiceAvailability таблицы Зив элементе PackageAvailability таблицы 6. Эти элементы указывают пакет служб и службы, которые может получать HNED.

HNED получает данные о своем расположении от сервера DHCP через опцию 99 протокола DHCP.

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

  • - отправляя информацию о расположении на сервер URI, извлеченную из предложения региони-рования (Regionalization Offering) режим pull (см. 5.4.3);

  • - сопоставлением информации о расположении с данными таблицы 8. Результирующим идентификатором является идентификатор соты, который в сочетании с кодом страны сопоставляется с информацией в элементах PackageAvailability и ServiceAvailability. Это сопоставление позволяет определить пакет и службы, которые могут быть получены HNED в его регионе. В отличие от остальной информации обнаружения и выбора службы форматы информации регионирования, полученного HNED, отличаются в режимах push или pull. Расположения push и pull, которые анонсируются в предложениях по регионированию, идентичны расположениям других предложений SD&S. Предложение регионирования в записи обнаружения провайдера служб должно предоставлять адрес IP расположения push или pull и/или обоих. Если предусмотрены расположения режимов push и pull, то HNED сначала использует расположение режима pull и только в случае отказа переходит к расположению режима push.

Для уменьшения объема данных запись о регионе рекомендуется компрессировать (см. таблицу 20). Не рекомендуется переносить все типы почтовых адресов (CAtype) в запись региона. HNED должно минимизировать время обработки и прекращать поиск, если CAtype не соответствует значению, предоставленному сервером DHCP.

HNED прекращает синтаксический анализ структуры XML при обнаружении не соответствующих друг другу пар тип/значение. Совпадение всех пар тип/значение и достижение конца дерева элементов гражданского адреса означают, что идентификатор соты (CelllD) получен.

При предоставлении данных DHCP GEOCONF_CIVIC на нескольких языках (CAtype=0), достаточно иметь совпадение на одном из языков для получения идентификатора соты.

При multicast-доставке значение PayloadID (таблица 21) равно 0x07.

Семантика поля предложений о регионе представлена в таблице 8.

Таблица 8 —Семантика поля предложений о регионе

Имя

Определения семантики полей

Указания применения

Cell

Единица регионирования, которая содержит иерархический список гражданских адресов, к которому относится регион (гражданские адреса, доступные через DHCP)

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

В данном разделе приведено описание процессов получения идентификатора региона через HTTP (режим pull). Для получения идентификатора соты при работе в режиме pull HNED отправляет сообщение POST в URI, извлеченный из предложения по регионализации (Regionalization Offering). Тело метода должно содержать код страны и информацию о гражданском адресе, полученную через опцию 99 DHCP. Сервер отвечает POST устройству с идентификатором соты, определяющим расположение HNED.

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

'POST ' path request ' НТТР/1.1' CRLF

'Host: ' host CRLF

CRLF

message_body,

где request = ‘CelllD’ — идентификатор соты;

path = абсолютный путь URI, указанный в атрибуте Location элемента pull элемента Regionization Offering (типа OfferingListType, см. таблицу 18, пункт 19), с добавлением /;

host = расположение сети (полномочное) URL, указанного в атрибуте «Location элемента pull элемента «Regionization Offering» (типа OfferingListType) (см. таблицу 18, пункт 19);

message_body = элемент записи запроса соты, включая код страны и всю информацию о гражданском адресе, полученную через опцию 99 DHCP.

В поле CountryCode устанавливается значение, полученное из опции 99 DHCP.

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

Если в данных DHCP GEOCONF_CIVIC присутствует набор параметров для нескольких языков (CAtype=0), HNED должно предоставить каждому набору параметров идентификаторы соты на всех языках.

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

Предложение о службах удаленного управления, встроенных программах и обновления ПО RMSFUSDiscoveryType могут быть идентифицированы сочетаниями нескольких служб. При multicast-доставке значение PayloadID для DVBSTP должно быть 0x8 (таблица 21). В таблице 9 представлены определения семантики полей служб по ссылкам.

Таблица 9 — Определения семантики полей служб по ссылкам

Имя

Определение семантики

Указания применения

FUSProvider

Текстовое имя провайдера FUS, от которого могут быть получены обновления. Допустимы ссылки на несколько FUS. Ссылки выполняются с использованием FUSType (см. таблицу 18, пункт 12)

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

RMSProvider

Текстовое имя провайдера RMS, управляющего HNED. Допустимы ссылки на несколько FUS. Ссылки выполняются с использованием RMSType (см. таблицу 18, пункт 28)

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

DSMProvider

Информация обнаружения службы динамического управления службой. Обеспечивает не более одного провайдера DSM. Выполняется с помощью DSMMType (см. таблицу 18, пункт 6а)

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

В записи предложения SRM (SRM Offering Record) содержится информация для доставки в HNED сообщений возобновляемости (обновления) системы.

В записи предложения SRM используется значение идентификатора полезной нагрузки, равное 0x09 (таблица 21), и используется базовая запись предложения (Offering Record). Доменное имя является доменным именем провайдера службы доставки SRM.

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

Примечание — В случае unicast-доставки объявлений системы SRM по HTTP должен быть предоставлен идентификатор системы СР или комбинация идентификатора системы СР и идентификатора SRM СР.

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

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

Номер версии файла SRM предоставляется для служб загрузки unicast-служб SRM вместе:

  • - с ID системы защиты контента;

  • - ID SRM системы защиты контента (опционально).

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

Номер версии файла SRM увеличивается при загрузке обновленного файла SRM через HTTP.

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

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

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

Элемент SRM Offering используется в тех случаях, когда провайдер службы предлагает доставку SRM по сетям IP. Он предоставляет список объявлений и службы загрузки SRM для конкретных идентификаторов системы СР. Определения полей SRM Offering представлены в таблице 10.

Таблица 10 — Определения полей SRM Offering

Имя

Определения полей SRM Offering

Указания применения

SRM Announcementservice

Подробности о всех службах объявлений (Announcement) SRM. Предоставляется один экземпляр на службу. Формат описан в таблице 18, пункт 37

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

SRMDownloadService

Подробная информация о предоставляемой службе загрузки SRM. Предоставляется один экземпляр на службу. Формат описан в таблице 18, пункт 40

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

Структура записи описания анонсирования CoDAnnounceDescribe должна присутствовать только в документах, используемых как часть методов RTSP RNPNNUNCE и DESCRIBE.

Определения полей структуры CoDAnnounceDescribe представлены в таблице 11.

Таблица 11 —Определения полей CoDAnnounceDescribe

Имя

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

Указания применения

ContentDescription

Описание элемента с использованием формата TV-Anytime по ГОСТ Р 56476

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

FECInfo

Подробная информация о FEC, доступная для этого элемента контента. Подробности определены в таблице 18, пункт 9

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

RETInfo

Сведения о RET для этого элемента контента доступны. Подробности определены в таблице 18, пункт 26

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

ServerBasedEnhance-mentServicelnfo

Подробная информация о службе расширения для этого элемента контента доступна на сервере. Подробности определены в таблице 18, пункт 31

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

RTPControlURL

URL RTSP используется для управления этим элементом контента

Обязательное, если для RTSP используется отдельный URL управления

Streaming

Этот атрибут должен указывать формат потоковой передачи согласно определению по 5.2.8

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

  • 5.2.5 Модель данных

В приложении А ГОСТ Р 54994—2012 показано графическое представление модели обнаружения службы DVB-IPTV.

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

В таблице 12 представлен список предложений в модели данных DVB IPTV.

Таблица 12 — Список предложений в модели данных DVB IPTV

Предложение

Описание

Информация об обнаружении вещания

Информация об обнаружении вещания предоставляется в двух формах:

  • - в режиме ТП полная SI информация об обнаружении вещания может быть указана значением Stream для атрибута PrimarySISource и S для IPService;

  • - режим ТП дополнительная SI используется при недоступности полной SI

Информация об обнаружении CoD

Информация об обнаружении CoD содержит все необходимые данные для обнаружения CoD в сети серверов CoD*

Службы от других провайдеров служб

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

Окончание таблицы 12

Предложение

Описание

Информация об обнаружении пакетов

Информация об обнаружении пакетов используется провайдерами служб, которые группируют несколько служб и представляют их в виде единого объекта. Информация о пакете не позволяет обнаруживать новые службы. Информация об обнаружении пакета ссылается на службы, которые должны быть обнаружены с помощью двух других компонентов в модели Broadcast и CoD Discovery Information

Информация об обнаружении провайдера служб

Информация об обнаружении провайдера служб содержит описание провайдеров служб, предоставляющих предложения служб

Предложение BCG

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

Предложение RMS

Предложение RMS предоставляет средства для работы как служб удаленного управления, так и служб обновления встроенного ПО

Предложение регионирования

Предложение регионирования предоставляет данные, необходимые для работы служб регионирования

Предложение SRM

Предложение SRM содержит данные для доставки сообщений об обновлении системы

* Применение информации об обнаружении CoD не рекомендуется, следует использовать информацию об обнаружении BCG.

Все точки входа обнаружения, кроме ServiceproviderDiscovery, используют расширенные версии dvb:Offeringbase, каждая из которых также расширена дополнительными атрибутами.

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

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

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

  • 5.2.6 Пространство имен метаданных служб

Корень пространства имен для определений метаданных, представленных в настоящем стандарте, должен быть urn:dvb:metadata:iptv:sdns.

Настоящий стандарт использует обновленное пространство имен TV-Anytime urn:tva:metadata:2011 и пространство имен базовых схем XML.

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

Ниже приводится текстовая версия заголовка схемы пространства имен:

<xsd:schema targetNamespace=urn:dvb:metadata:iptv:sdns:2014-l xmlns:tva=urn:tva:metadata:2 011

xmlns:dvbl2=urn:dvb:metadata:iptv:sdns:2 012-1

xmlns:dvbl4=urn:dvb:metadata:iptv:sdns:2014-1

xmlns:dvb=urn:dvb:metadata:iptv:sdns:2008-l

xmlns:mpeg7=urn:tva:mpeg7:20 08

xmlns:xsd=http://www.w3.org/2001/XMLSchema» elementFormDefault=«unqualified attributeFormDefault=unqualified>

<xsd:annotation>

<xsd:documentation>schema to validate the record of the description of the DVB-IP

offering of a service Provider

Это версия схемы фазы 1.6.1.

</xsd: documentation

</xsd:annotation>

<xsd:import namespace=urn:tva:metadata:2011 schemaLocation=./tva_metadata_3-l_ vl71.xsd/>

<xsd:import namespace=urn:dvb:metadata:iptv:sdns:2008-1 schemaLocation=./sdns_ vl.4rl3.xsd/>

<xsd:import namespace=urn:dvb:metadata:iptv:sdns:2012-l schemaLocation=./sdns_ vl.5r25b.xsd/>

<xsd:import namespace=urn:tva:mpeg7:2008 schemaLocation=./tva_mpeg7_2008.xsd/>

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

urn:dvb:metadata:iptv:sdns:2014-1, элементы и атрибуты, затронутые обновлением, будут предварительно установлены с помощью dvb14.

  • 5.2.7 Обратная совместимость

Определения метаданных, введенные в предыдущих версиях стандарта, использовали разные обозначения версии формы yearversion, например 2008-1. Эти определения верны, если для определения того же элемента в том же корневом пространстве имен не было предоставлено обозначение более поздней версии.

  • 5.2.8 Базовые типы XML

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

Примечания

  • 1 Данные о некоторых известных типах представляют простую спецификацию XML и являются информативными.

  • 2 Символ @, предшествующий имени атрибута или элемента, указывает, что объект является атрибутом элемента, к которому он присоединен.

  • В таблице 13 представлены определения базовых типов XML.

Таблица 13 — Определения базовых типов XML

Имя

Определения

BroadcastSystemType

Определяет систему доставки вещания. Этот тип может принимать любое из следующих значений: ANALOG (студийное ТВ), ID_DVB_C, ID_DVB_S, ID_ DVB_T, ID_DVB_C2, ID_DVB_S2, ID_DVB_T2, ID_ISDB_C, ID_ ISDB _S, ID_ ISDB _T, ID_ATSC_T

CPSystemIDType

Идентификатор системы СР. Значения CA_System_ID должны быть выделены поставщиками систем САдля идентификации систем гражданского адреса (Civic Address; СА) в области приложений по ГОСТ Р 55697 установкой этих значений в поле CA_system_id

CPSystemSRMID

Значения CPSystemSRMID должны быть выделены поставщиками систем условного доступа для идентификации систем СА в области приложений по ГОСТ Р 55697 установкой этих значений в поле CA_system_id

DomainType

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

EnhancementServiceType

Содержит список предложений служб расширения базовых серверов для LMB. Нормированы только службы RET и FCC

Genre

Описывает жанр контента, который кодируется числом в диапазоне значений от Одо 15, какописано в поле content_nibble_level_1 дескриптора content_descriptor, в соответствии с ГОСТ Р 55679

Hexadecimal3bit

3-битовое число, представленное как одна шестнадцатеричная цифра, перед которой не установлен Ох

Hexadecimal4bit

4-битовое число, представленное как одна шестнадцатеричная цифра, перед которой не установлен Ох

Hexadecimal8bit

8-битовое число, представленное как две шестнадцатеричные цифры, перед которыми не установлен Ох

Окончание таблицы 13

Имя

Определения

Hexadecimall 6bit

16-битовое число, представленное как четыре шестнадцатеричные цифры, перед которыми не установлен Ох

Hexadecimal32bit

32-битовое число, представленное как 8 шестнадцатеричных цифр, перед которыми не установлен Ох

Integer6bit

6-битовое десятичное число в диапазоне от 0 до 63, без базового идентификатора номера

IPorDomainType

Тип блока, который может содержать адрес IP (см. IPType) или имя домена (см. DomainType)

IPType

Адрес IPv4 в форме a.b.c.d (десятичный) или адрес IPv6, разделенный двоеточием (шестнадцатеричный)

ISO-3166-List

Список 3-символьных кодов стран, разделенных запятой в соответствии с ГОСТ 7.67. Коды в списке должны быть разделены запятыми

ISO 639-2

Трехбуквенный код языка в соответствии с ГОСТ 7.75

OrigNetld

Идентификатор original_network_id нормирует управление числовым пространством значений Original_Network_ID, которые должны передаваться вещателям, сетевым операторам и производителям контента для однозначной идентификации сетей. Значение original_network_id должно быть в десятичной форме

PrimarySISource

Тип указывает источник информации SI:

  • - если в XML, то тип принимает значение XML;

  • - если в потоке, то тип принимает значение Stream

PullURL

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

RTSP

Используется, если требуется URL протокола RTSP

Service

Содержит имя службы, как указано в 5.2 настоящего стандарта. Рекомендуется обеспечивать соответствие имени службы правилам для имен DNS в сети Интернет

ServicelD

Servicejd должен соответствовать ГОСТ Р 55697

ServiceType

Шестнадцатеричное 8-битовое значение (см. Hexadecimal8bit), кодирующее type службы. Значения и определения установлены ГОСТ Р 55697

StreamingType

Этот тип указывает: используется RTP (со значением rtp) или UDP (со значением udp)

TransportProtocolType

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

TSId

Transport_stream_id должно быть в соответствии с ГОСТ Р 55697. Это значение должно быть десятичным

Usage

Указывает на использование IPService. Этот элемент является строкой и может содержать: ANALOG (студийное TV), SD, HD, PiP, FCC, 3D или DSMService. Этот элемент используется для указания существования других IP-служб для одного и того же контента и что они будут отображаться как субслужбы IP в рамках этого IPService. Значение DSMService является обязательным для служб, которые являются частью группы DSM, когда DSM включен в HNED

Version

Число, соответствующее версии таблицы или записи. Это значение будет увеличиваться с изменениями в таблице или записи по модулю 256. Это значение должно быть в шестнадцатеричном формате

Примечание — Регулярное выражение RegEx применяется в качестве шаблона для сопоставления адреса IPv6 в определении IPType в настоящей таблице с параметрами 128-битовой структуры.

  • 5.2.9 Сложные типы XML-групп атрибутов

Группа атрибутов BasicMulticastAddressAttributesType выполняет перенос базового адреса групповой доставки (без информации о каналах служб с FEC или RET).

В таблице 14 представлены определения полей группы атрибутов BasicMulticastAddressAttributes Туре.

Таблица 14 — Определения полей группы атрибутов BasicMulticastAddressAttributesType Fields

Имя

Определение

Указания применения

Source

Может быть предоставлен один адрес IP источника TS. Если этот атрибут отсутствует, multicast-доставка должна выполняться от любого источника multicast-доставки

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

Address

Адрес multicast-группы

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

Port

Порт, через который может быть осуществлен доступ к службе

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

Группа CommonCastRETType является набором атрибутов для типов: unicast RET/FCC и multicast RET.

В таблице 15 представлены определения пакетов атрибутов CommonCastRETType.

Таблица 15 — Определения пакетов атрибутов CommonCastRETType

Имя

Определение

Указания применения

ssrc

Пакеты SSRC для RTP в сеансе повторной передачи. Это значение должно соответствовать значению SSRC первичной multicast-доставки, за исключением multicast-доставки RET, при использовании мультиплексирования источника синхронизации (Synchronization Source; SSRC)

Опционально

RTPPayloadNumber

Количество пакетов типа динамической полезной нагрузки RTP в сеансе повторной передачи

Опционально

rtcp-mux

Этот атрибут сигнализирует о мультиплексировании пакетов повторной передачи RTCP и RTP на одном и том же порте назначения. Если атрибут отсутствует, то пакеты RTCP переносятся в порт, который сигнализируется атрибутом estinationPort

Опционально

Destination Port

Определяет порт назначения UDP:

  • -для multicast RET, порт назначения UDP multicast-пакетов RET RTP;

  • - для unicast — RET/FCC, порт назначения UDP unicast-пакетов повторной передачи RTP. Если порт не представлен, то номер порта соответствует исходному порту пакетов RTCP, выпущенных отчетами HNED для RTCP в исходном сеансе

Обязательно для multicast RET.

Опционально для unicast RET

rtx-time

Допустимый интервал времени (в миллисекундах) повторной передачи информация пакета RTP. Этот атрибут определяется только для службы RET; для FCC значение должно быть проигнорировано

Обязательно

Группа атрибутов FECAttributeGroupType предоставляет информацию FEC, используемую в уровнях улучшения. Определения полей FECAttributeGroupType представлены в таблице 16.

Таблица 16 — Определения полей FECAttributeGroupType

Имя

Определение

Указания применения

FECMaxBIockSize

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

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

FECMaxBIockTime

Максимальная продолжительность передачи любого блока FEC в миллисекундах

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

FECOTI

Информация о передаче объекта FEC для

кода Raptor. Если элемент «FECEnancementLayer» включен, он должен быть использован

Обязательное, при использовании

AttributeGroup для уровня улучшения FEC

Тип MulticastAddressAttribute передает набор параметров, поддерживающих multicast-службы. Он поддерживает адресацию одиночного источника multicast-доставки (SSM), если указан атрибут Source. При отсуствии атрибута Source он поддерживает любые адреса источника multicast-доставки. Он также содержит информацию, необходимую для поддержки и настройки поддержки FEC. Определения полей типа MulticastAddressAttribute представлены в таблице 17.

Таблица 17 — Определения полей типа MulticastAddressAttribute

Имя

Определение

Указания применения

BasicMulticast-AddressAttributesType (включая attributeGroup)

Базовое значение группового адреса является импликацией «attributeGroup»

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

Streaming (потоковая передача)

Указывает на применение RTP или UDP. Если параметр не указан, предполагается применение RTP. Этот тип определен в 5.2.10 (таблица 13)

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

FECAttributeGroupType (включая attributeGroup)

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

Обязательное, если используется уровень улучшения FEC

  • 5.2.10 Сложные типы XML-групп элементов

В таблице 18 представлено описание сложных типов XML-групп элементов.

Таблица 18 — Описание сложных типов XML-групп элементов

Наименования типов

Назначение типов

1 Announcementsupport

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

1а ciAncillaryData

Используется для переноса эквивалента дескриптора вспомогательных данных ci_ancillary_data. Назначение дескриптора — поддержка функциональности сопутствующего экрана

2 CDSDownloadSessionDescrip-tionLocationType

Используется для переноса multicast-адреса сеанса службы загрузки контента (CDS) и для индикации способа переноса:

  • - в формате протокола анонсирования сеанса (при использовании элемента SAP);

  • - в формате XML SD&S (при использовании элемента DVBSTP)

3 Cell

Используется для группирования гражданских адресов и предоставления идентификатора регионализации, к которому эти адреса относятся. Детализация задач регионализации представлена в 5.2.4

Продолжение таблицы 18

Наименования типов

Назначение типов

4 CivicAddress

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

5 CountryAvailabilty

Представляет XML-дескриптор доступности страны.

Поле «Countries» в составе типа CountryAvailabilty содержит список стран и является обязательным к применению.

Поле Available в составе типа CountryAvailabilty содержит логическое значение true или false для списка стран. По умолчанию устанавливается значение true

6 DescriptionLocationBCG

Расширение к типу tva: TVAIDType, определенному ГОСТ Р 56476, которое добавляет атрибут (опционально), сигнализирующий о предпочтительности расположения описания службы. В каждой соответствующей области должно быть не более одного экземпляра предпочтительного значения true

6а DSMMType

Передает информацию о менеджере DSM (DSMM) и методах, доступных для подключения к нему.

Многоязычное имя DSMM, может иметь несколько DSMMName для одного DSMM. Создан с использованием MultilingualType, как указано в пункте 17 настоящей таблицы

7 DVBSTPTransportModeType

Содержит детали адресов и сегментов для информации, передаваемой по протоколу DVBSTP.

Поле DVBSTPTransportModeType определяет сегмент и полезные нагрузки, которые переносятся по указанному адресу для указанной информации. Тип PayloadList определен в пункте 22 настоящей таблицы.

Поле MulticastAddressAttributes в составе DVBSTPTransportModeType определяет адрес multicast-доставки, в котором присутствует информация, передаваемая протоколом. Эта группа атрибутов определена в 5.2.9

8 DVBTriplet

Идентификатор службы в классической системе DVB. Поле OrigNetld определяет идентификатор сети исходной системы доставки. Формат этого атрибута определен в 5.2.8. Поле TSId определяет транспортный поток. Формат этого атрибута определен в 5.2.8.

Поле Serviceld идентифицирует службу из любой другой службы в транспортном потоке. Идентификатор службы совпадает с номером программы в соответствующей РМТ.

Формат этого атрибута определен в 5.2.8.

Поле TSIdWildcard (опционально) позволяет игнорировать атрибут TSId в пользу этого шаблона, сопоставляя все значения TSId

9 FECInfoType

Сообщает о присутствии и использовании FEC, передает параметры, необходимые для использования FEC, со связанной с ним службой.

Поле FECBaseLayer в составе FECInfoType содержит информацию о базовом уровне FEC, используя тип, определенный в пункте 10 настоящей таблицы.

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

10 FECLayerAddressType

Атрибут Port является опциональным, если он используется совместно с CoDAnnounceDescribe и URL с применением RTSP.

Если на базовом уровне параметр PayloadTypeNumber не имеет значение 96, a Transportprotocol отсутствует, тип FECLayerAddressType используется в контексте BaseLayer, a PayloadTypeNumber должен иметь значение 96.

Если тип FECLayerAddressType используется в контексте EnhancementLayer, то Transportprotocol по умолчанию должен иметь значение UDP/FEC. (Если Transportprotocol в EnhancementLayer отсутствует, то предполагается значение Transportprotocol UDP/FEC)

Продолжение таблицы 18

Наименования типов

Назначение типов

11 FUSAnnouncementType

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

Поля в составе FUSAnnouncementType представляют:

  • - FUSAnnouncementDescription — текстовый дескриптор объявления;

  • - MulticastAnnouncementAddress — адрес группового объявления, созданный с помощью RMSFUSMulticastAddressType, определенный в пункте 27 настоящей таблицы;

  • - FUSUnicastAnnouncement — адрес объявления URI, к которому должны быть сделаны запросы для unicast-объявлений;

  • - QRCLocation — URI, с которым должны быть выполнены соединения канала запроса/ответа

12 FUSType

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

  • - многоязычное имя FUS, может быть применено к одному FUS;

  • - числовой идентификатор FUS в десятичной форме для экземпляра FUS;

  • - текстовое описание обновления ПО (опционально);

  • - предоставление экземпляров FUSAnnouncement инициируется использованием FUSAnnouncementType, определенных в пункте 11 настоящей таблицы;

  • - URI для загрузки URI провайдера FUS (опционально)

13 HTTPTransportModeType

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

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

  • - определяет расположение, в котором может быть найдено руководство. Формат этого типа определяется в 5.2.8;

  • - указывает на допустимость запроса руководства при использовании протокола SOAP, а не протокола DVBSTP, описанного в 5.4.2. По умолчанию значение этого атрибута — false (опционально)

14 McastType

Используется для хранения группового адреса и (опционально) для сигнализации об использовании AL-FEC или RET/FCC. При наличии таких данных McastType содержит информацию, необходимую для этих дополнительных компонентов. McastType поддерживает multicast через MulticastAddressAttributes доставку SSM, если указан атрибут Source. Если атрибут Source не указан, то поддерживаются любые источники multicast-доставки (Any Source Multicast; ASM).

Поля CNAME и SSRC позволяют передавать значения, используемые службой, и могут быть (опционально) использованы для поддержки HNED для идентификации корректных потоков и выделения уникальных номеров

15 MosaicDescription

Элемент описания мозаики идентифицирует элементарные ячейки службы «мозаика», группирует различные элементарные ячейки для формирования логических ячеек и устанавливает связь между содержимым всей логической ячейки и соответствующей информацией о службе или о пакете. Реализация дескриптора Mosaic и определения всех полей отражены в ГОСТ Р 55697. Поле AudioLink позволяет привязывать тег и язык к каждой логической ячейке мозаики. Это позволяет связывать различные аудиопотоки с каждой логической ячейкой

16 MulticastRETType

Предоставляет основные атрибуты multicastRET и включает в себя тип CommonCastRET для предоставления дополнительных данных, определенных в 5.2.9

17 MultilingualType

Содержит строку базового XML-типа с ассоциированным языком. Строка базового XML-типа содержит значение строки с языком, указанным в атрибуте Language двухсимвольным кодом языка

Продолжение таблицы 18

Наименования типов

Назначение типов

18 OfferingBase

Является основой для формирования всех предложений служб. Предоставляет требуемый атрибут типа домена и поле версии (опционально), необходимое при использовании протокола HTTP. Содержит поле DomainName — имя домена DNS, зарегистрированное провайдером служб, которое однозначно идентифицирует провайдера служб. Это поле является значением по умолчанию для определенных полей в записи в соответствии с их семантикой.

Поле Version содержит значение версии записи предложения DVB-IPTV. Номер версии должен увеличиваться при каждом изменении записи DVB-IPTV

19 Offering ListType

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

20 PackageAvailabilityCountry-CodeType

Предоставляет список стран, в которых служба или пакет служб доступны (или недоступны). Используется в сочетании со строкой, в которой перечислены Cell, которые определяют регионализацию страны.

Содержит расширение базового типа строки схемы ХМ, в которой определена страна, для которой определяется доступность служб DVB-IPTV. Этот элемент должен иметь двухсимвольный формат

21 PackagedServiceType

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

  • - Textual I ID — текстовую ссылку службы, определенную в пункте 45;

  • - DVBTriplet — триплет DVB (опциональный), эквивалентный идентификатору службы TextuallD, определен в пункте 8 настоящей таблицы;

  • - DescriptionLocation — расположение описания службы BCG, определенного в пункте 6 настоящей таблицы;

  • - LogicalChannelNumber— номер логического канала службы

22 PayloadList

Содержит список ID полезной нагрузки и (опционально) SegmentID (5.4.4). Используется типами DVBSTP и HTTP для указания доступности по указанному адресу полезных нагрузок и сегментов.

Поле Payloadld (опционально) содержит список сегментов, их идентификаторов и версий, которые составляют полезную нагрузку по ссылке. Несколько экземпляров этого элемента составляют полный список полезной нагрузки. Поле Id — идентификатор полезной нагрузки. Значения Id представлены в 5.4.4.

Поле Segment содержит список сегментов (опционально), которые переносятся, используя значения, определенные типом в пункте 23 настоящей таблицы

23 PayloadListSegmentType

Используется для переноса сведений о сегменте, который доступен, вместе с целевым пакетом, к которому относится сегмент

24 ReferencedServiceProvider-Type

Используется для перечисления служб от провайдера Б, которые текущий провайдер А включает в свой контекст

25 Replacementservice

XML-предоставление функциональности замещающей службы linkage_ descriptor. Служба, указанная триплетом DVB или текстовым идентификатором, может использоваться при завершении службы в результате сбоя. Тип Replacementservice идентифицирует замену службы, которая может автоматически выбираться HNED, когда качество процесса декодирования службы становится недопустимо низким

26 RETInfoType

Этот тип используется для сигнализации наличия службы повторной передачи RET unicast-передачи RTP и multicast-служб RTP повторной передачи и передает параметры, необходимые для использования службы RET

Продолжение таблицы 18

Наименования типов

Назначение типов

27 RMSFUSMulticastAddress-Туре

Содержит комбинацию, используемую для определения параметров multicast-доставки для службы объявлений FUS

28 RMSType

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

29 RTCPReportingType

Используется в сочетании с механизмами службы FCC/RET и представляет параметры отчетности RTCP. Они являются общими для реализаций служб multicast RET и unicast RET/FCC

30 RTSPURLType

Используется для предоставления дополнительного URL управления RTSP для поддержки служб AL-FEC и/или RET

31 ServerBasedEnhancement-ServicelnfoType

Используется для оповещения о присутствии службы расширения и передает параметры, необходимые для использования этой службы. Возможными службами являются RET и FCC

32 ServiceAvailabilityType

Обеспечивает поддержку регионирования. Позволяет каждой службе иметь список Cell, с которыми связана служба. Все отдельные службы по умолчанию доступны во всех регионах. Более подробная информация об использовании и инициализации значений ServiceAvailability приведена в 5.2.11.

Для каждого CountryCode должно быть определено не более одного элемента ServiceAvailability

33 ServiceLocation

Описывает расположение источника вещания или источника IP. В случае источника IP, расположение должно быть либо адресом multicast-доставки, либо сервером RTSP. Должен присутствовать один из IPMulticastAddress (пункт 14), или RTSPURL (пункт 30), или Broadcast

34 SI

Описывает служебную информацию, передаваемую в транспортном потоке

35 SRMAnnouncementMode-Type

Используется для передачи сведений о доставке объявлений службам SRM через SAP или HTTP. Более подробная информация об использовании этой информации приведена в 5.2.4

36 SRMAnnouncementMode-SAPType

Используется для переноса и определения адресов протокола объявления сеанса (SAP), которые могут содержать подробности службы объявления SRM

37 SRMAnnouncementService-Type

Предоставляет информацию службе объявлений SRM, содержит элементы:

  • - SRMID — создает список идентификаторов SRM;

  • - SRMAnnouncementMode — содержит информацию о правилах доступа к службе объявления SRM;

  • - AnnouncementServiceVersion — содержит версию службы объявления SRM

38 SRMDownloadServiceFLU-TEType

Переносит информацию о загрузке файлов SRM в FLUTE.

Список идентификаторов SRM и номеров версий SRM-файлов, поддерживаемых службой загрузки FLUTE

39 SRMDownloadServiceHTTP-Type

Переносит информацию о загрузке файлов SRM в HTTP. Содержит элементы: - SRMIDVer — содержит SRM ID и версию файла SRM, поддерживаемые службой загрузки HTTP;

- Location — URI файла для unicast-загрузки HTTP

40 SRMDownloadServiceType

Содержит сведения о службе загрузки SRM, которая должна использовать или FLUTE или HTTP

41 SRMIDType

Переносит систему защиты контента (СР) и опционально, ID SRM системы СР для системы SRM (5.2.8)

42 SRMIDVerMType

Обеспечивает систему СР (опционально) идентификатором SRM системы СР и версией файла SRM для FLUTE (или multicast-доставки). Расширяет тип SRMIDType в пункте 41 настоящего стандарта

Окончание таблицы 18

Наименования типов

Назначение типов

43 SRMIDVerUType

Обеспечивает систему СР версией файла SRM с номером версии и (опционально) ID SRM системы СР для SRM, используемого для протокола HTTP (unicast) доставки

44 TargetPackageType

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

Приемники, выполненные в соответствии с более ранними версиям стандарта, будут игнорировать элемент TargetPackage.

Тип TargetPackage включает в себя атрибут PackagelDRef и опционально элемент PackageType.

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

Элемент PackageType содержит текстовое описание пакета, которое может использоваться приложением пользователя

45 Textualldentifier

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

46 TransportModeType

Указывает на расположение информации BCG и механизма переноса информации BCG, а также значений «Payloadld» и Segmentld соответствующей информации. Должно присутствовать одно из полей DVBSTP или HTTP. Поля DVBSTP или HTTP могут присутствовать многократно, если информация доступна в нескольких расположениях

47 UnicastRETType

Предоставляет базовые атрибуты unicast RET и сервера службы FCC, содержит тип CommonCastRET для предоставления данных (опционально)

47a URILinkage

Используется для переноса эквивалента дескриптора URIJinkage

48 PackageTextualIdentifier

Используется для идентификации службы в текстовом режиме. Расширяет тип Textualldentifier. Тип предназначен только для использования в контексте PackageService

  • 5.2.11 Основные типы XML

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

  • - запись путеводителя по контенту вещания: BCGOffering;

  • - запись обнаружения вещательной передачи по предложению вещания: Broadcastoffering;

  • - запись предложения контента по требованию: CoDOffering;

  • - пакеты служб: PackagedServices;

  • - предложение служб по ссылке: ReferencedServices;

  • - предложение служб удаленного управления и встроенных программ: RMSFUSDiscoveryType;

  • - обнаружение провайдера служб: ServiceProviderListType;

  • - информация обнаружения служб по предложению: PackagedServices;

  • - информация обнаружения регионов;

  • - запись предложения SRM;

  • - запись анонсирования CoD.

Все типы, описанные в этом пункте, расширяют тип OfferingBase, определенный в 5.2.4. Пространство имен схемы XML определено в 5.2.6.

  • 5.3 Процесс выбора служб

Доступ к службам каждым HNED обеспечивается:

  • - использованием протокола RTSP;

  • - присоединением к multicast-передаче.

Службы LMB предоставляются при multicast-передаче IP. Службы LMB передаются непрерывно и не должны инициироваться каждым HNED. HNED могут присоединяться к службам и выходить из них, выдавая запросы через IPv4 или IPv6. Элемент расположения служб (Service Location) в записях обнаружения служб предоставляет всю информацию, необходимую для выдачи соответствующего сообщения. Не допускается управление потоком для выполнения команд типа «пауза» или «перемотка вперед».

Для служб LMB провайдеры служб могут требовать от HNED (опционально) выполнения всех этапов настройки и выхода из службы (возможными причинами этих действий могут быть необходимость учета поставляемых служб и обслуживания процессов условного доступа и т. д.). В таких системах используется протокол RTSP по ГОСТ Р 54994—2012 (раздел 6). Элемент Service Location в записи обнаружения службы сигнализирует об использовании RTSP и предоставляет всю информацию, необходимую для выдачи соответствующего метода RTSP. Параметры, необходимые для multicast-сообщения, будут получены с помощью метода SETUP от RTSP.

Процесс вещания служб с использованием режима Trick (MBwTM) аналогичен процессу вещания служб LMB, но выполняется при unicast-передаче IP, обеспечивающей возможность управления потоком.

Службы CoD и MBwTM поставляются при unicast-доставке IP. Они предназначены для конкретного пользователя и должны быть явно инициированы HNED. Для доступа к таким службам должен использоваться RTSP. Выбор применяемых методов RTSP представлен в ГОСТ Р 54994—2012 (раздел 6).

Процесс выбора служб для CDS должен выполняться в соответствии с ГОСТ Р 54994—2012 (раздел 10).

  • 5.4 Механизмы передачи информации

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

    Передача информации обнаружения провайдеров служб и служб в соответствии с ГОСТ Р 54994— 2012 (раздел 5) выполняется при использовании двух механизмов:

  • - multicast-передачи;

  • - unicast-передачи.

Информация обнаружения служб может быть multicast (режим push) или unicast, полученной по запросу (режим pull). Оба режима должны поддерживаться и сервером и клиентом.

В multicast-режиме передачи для доставки записей XML должен использоваться транспортный протокол DVBSTP.

В unicast-режиме передачи информации SD&S должен использоваться протокол HTTP.

Эти два механизма передачи должны быть взаимозаменяемыми на всех этапах и иметь одинаковое содержание. Исключением является формат о регионализации, который отличается для режимов push или pull (информационные данные регионализации, передаваемые в этих режимах, не являются взаимозаменяемыми).

  • 5.4.2 Протокол multicast-передачи информации SD&S

При передаче информации обнаружения службы с использованием multicast-пакета UDP используется протокол DVBSTP. Все значения, определенные ниже, должны передаваться в порядке байтов нормального адреса IP начиная со старшего байта. Протокол DVBSTP используется для multicast-доставки данных BCG, для multicast-доставки сообщений об обновлении встроенного ПО и для multicast-доставки описаний сеансов загрузки CDS XML.

Схема URI для DVBSTP должна соответствовать Б.5 приложения Б ГОСТ Р 54994—2012.

Не рекомендуется устанавливать атрибут версии корневого элемента ServiceDiscovery, описанного в 5.2.11, когда XML доставляется в режиме push. В этом случае значение отсутствующего атрибута Version эквивалентно версии поля заголовка сегмента DVBSTP.

Синтаксис датаграммы протокола multicast-доставки SD&S IPv4 должен соответствовать ГОСТ Р 54994—2012 (пункт 5.4.2).

Синтаксис датаграммы протокола multicast доставки SD&S IPv6 должен соответствовать рисунку 2.

0 12 3

01234567890123456789012345678901

|Ver|Resrv|Епс|С| Total_Segment_Size I

| Payload ID | Segment ID ISegment_Version|

4--4--4—4--4--4—4--4-- + -4--4—4--4--4--4--4--4—4--4—4--4—4—4--4—4-- + -4--4--4—4--4--4--4-

| Section_Number | Last Section Number |Compr|P|HDR_LEN|

4—4--4—4-- + -4—4--4--4—4-- + -4—4--4—4--4—4—+ -4—4--4—4—4—I—4-—F-4—4--4—4-—F-4—4-

| (Conditional) IPv6 ServiceProviderlD (hex digits 0-7) |

| (hex digits 8-15)

| (hex digits 16-23)|

| (hex digits 24-31)|

+ -4--4-- + - + - + -4-- + - + -4-- + - + -4-- + -4-- + - + -4-- + -4-- + - + - + - + -4-- + - + -4--4--4-- + - + -4-

: (Optional) Private Header Data

4--4--4--4--4--4--4--4--4—4--4—4--4--4--4--4—4--4--4--4--4—4--4--4--4--4—4--4--4--4--4--4--4-

I

: payload

| 4--4—+ -4-- + -4--4—+ -4-

| I(Optional) CRC |

4--4--4-- + - + - + -4-- + - + -4-- + - + - + - + -4-- + - + -4-- + -4-- + - + - + - + -4-- + - + -4-- + -4-- + - + -4-

| (Optional) CRC (Cont)

4--4--4--4--4-- + -4--4--4--4--4-- + -4--4--4-- + - + -4-- + -4-- + - + -4-- + -4-

Рисунок 2 — Синтаксис датаграммы протокола multicast-доставки SD&S IPv6

Семантика multicast DVBSTP должна соответствовать ГОСТ Р 54994—2012 (подпункт 5.4.3.1), за исключением семантики следующих полей:

  • - Ver (Protocol Version), поле 2 бита. Поле Ver должно принимать значение, указанное в таблице 19, соответствующее версии протокола IP;

Таблица 19 —Версия протокола IP

Значение версии

Наименование структуры пакета

00

Структура пакета IPv4

01

Структура пакета IPv6

От 10 до 11

Не определена

  • - Compression (Compr), поле 3 бита обозначает применяемую схему компрессирования полезной нагрузки. Все сегменты, относящиеся к данному идентификатору полезной нагрузки, должны иметь одинаковую схему компрессирования. Типы схем компрессирования приведены в таблице 20. Схема компрессирования GZIP доступна с идентификатором полезной нагрузки 0x08 для использования с RMS/FUS или с записью информации регионализации для идентификатора полезной нагрузки 0x07;

Таблица 20 —Типы схем компрессирования

Обозначение схемы компрессирования

Тип схемы компрессирования

Значение общего размера сегмента

000

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

Размер передаваемого сегмента

001

BiM

Размер передаваемого сегмента

010

GZIP

Размер передаваемого сегмента

От 011 до 101

Зарезервировано

Не определено

Окончание таблицы 20

Обозначение схемы компрессирования

Тип схемы компрессирования

Значение общего размера сегмента

110

Для применения схем ITU-T

Передаваемый размер

111

Частный пользователь

Определяет пользователь

  • - ServiceProvider ID, поле 32 бита. Семантика этого поля зависит от того, использует ли сеть IPv4 или IPv6, как указано в поле версии. Для IPv4 это 32-разрядное число, представляющее адрес IPv4, который используется для идентификации провайдера служб. Это число должно быть адресом IPv4. Остальная часть поля должна игнорироваться.

Для IPv6 это 128-разрядное число (переносимое в виде четырех 32-битовых слов), представляющее адрес IPv6, который используется для идентификации провайдера служб. Должны быть указаны все цифры адреса IPv6, включая начальные нули.

SP несет ответственность за поддержку этого адреса соответствующими полномочиями и за поддержку уникальности значения в пределах области, в которой он используется. «ServiceProviderlD» используется только для HNED.

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

Профилирование применяется к службам как для IPv4, так и для IPv6. Тем не менее следует применять различные методы, если в поле ServiceProviderlD не указывается соответствующий уникальный адрес IP.

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

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

В ГОСТ Р 54994—2012 (подраздел 5.4) показаны взаимосвязи между секциями, сегментами и записями.

Размер секции должен соответствовать ГОСТ Р 54994—2012 (подпункт 5.4.3.2.2).

Поле ServiceProviderlD позволяет HNED фильтровать пакеты без проверки или декомпрессии. Поле ServiceProviderlD рекомендуется использовать только с записями обнаружения провайдера служб, когда PayloadID равен 0x01, поскольку после этого процесс обнаружения позволит получать только multicast-адреса.

При использовании поля ServiceProviderlD параметры фильтрации пакетов должны соответствовать ГОСТ Р 54994—2012 (подпункт 5.4.3.2.3).

Если провайдер не может получить уникальный адрес IPv4 для передачи пакетов UDP может использоваться идентификатор original_network_id. Он отображается в нижней части специального диапазона адресов IPv4 значением 0.0.0.0/16.

В случае отсутствия у провайдера адреса IPv6 для передачи пакетов UDP в поле ServiceProviderlD должен устанавливаться действительный адрес IPv6. Если адрес не предоставлен или предоставленный адрес не может считаться действительным, секция DVBSTP должна игнорироваться.

Длительность передачи полного цикла передачи всех сегментов записей SD&S должна соответствовать ГОСТ Р 54994—2012 (подпункт 5.4.3.2.4).

  • 5.4.3 Unicast-передача информации SD&S

HTTP должен использоваться для всех соединений между HNED и серверами SD&S для доставки информации SD&S в режиме pull. Режим pull может использоваться для передачи запросов:

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

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

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

HTTP должен возвращать ответы на запросы, соответствующие записям XML, определенных в 5.2.6 в незашифрованном виде. HNED должно оценить сообщение, возвращаемое с сервера SD&S для того, чтобы убедиться, что он имеет статус успешного обмена 200. Если статус успешного обмена 200 не возвращается, запрос должен повториться в соответствии с механизмом предотвращения переполнения. После получения статуса обмена 200 соединение TCP закрывается.

Клиент и сервер HTTP должны согласовывать необходимую компрессию поддержкой заголовка Accept-Encoding. Кроме того, клиенты и серверы, переносящие данные SD&S в кодировке BiM, передают контент с заголовком, соответствующим Content-Encoding, и не должны изменять Content-Type. Меткой кодирования контента, определяющей кодирование BiM, должен быть x-bim. В случае кодирования в формате BiM клиент должен приобрести DVB-TVA-init до приобретения сегментов SD&S.

Запрос обнаружения службы должен возвращать запись обнаружения провайдера службы в соответствии с 5.2.3. Запрос имеет один параметр, который может принимать значение:

  • - ALL — для запроса информации обнаружения всех провайдеров служб, известных запрашиваемому серверу;

  • - имя домена конкретного провайдера служб — для запроса информации обнаружения указанного провайдера служб.

При использовании режима pull записи, содержащие информацию обнаружения провайдера служб (идентификатор полезной нагрузки 0x01), не должны быть сегментированы. Запись обнаружения провайдера служб может существовать в двух формах:

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

  • - в виде набора записей XML, по одной на каждого провайдера служб.

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

'GET ' path request ' НТТР/1.1' CRLF

'Host: ' host CRLF

CRLF

где request = ‘sp_discovery?id=’ALL’/ SPId;

path = /dvb/sdns/;

Host = имя домена или адрес IP точки входа SD&S, полученные по спецификации в соответствии с 5.2.2;

SPId = domainName Имя провайдера служб.

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

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

  • - идентификатор сегмента;

  • - версия сегмента. По этой версии сервер определит текущую версию сегмента, которую имеет HNED.

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

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

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

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

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

'GET ' path request ' НТТР/1.1' CRLF

'Host: ' host CRLF

CRLF

где request = ‘service_discovery?id=’SPId’&Payload=’Payloadld’&Segment

=’Segmentltem;

Path = абсолютный путь URI, предоставленный в атрибуте расположения элемента pull элемента Offering (тип OfferingListType, таблица 18, пункт 19), с дополнительным /;

Host = расположение сети (полномочное), предоставленное URL в атрибуте Location элемента pull элемента Offering (типа OfferingListType, таблица 18, пункт 19);

SPId = domainName Имя провайдера служб;

Payloadld = 2 HEXDIG; любое шестнадцатеричное число от 00 до ff;

Segmentld = 4 HEXDIG; Любое шестнадцатеричное число от 0000 до ffff;

Segmentitem = Segmentld 0*1(‘&Version=’VersionNumber;

Segmentitem — это Segmentld с опциональным полем для номера версии;

VersionNumber = 2 HEXDIG; любой шестнадцатеричный номер от 00 до ff.

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

В 5.2.4 настоящего стандарта описан механизм регионализации. Для получения идентификатора соты в режиме pull HNED отправляет сообщение POST в URI, извлеченное из Regionalization Offering (предложение по регионализации). Тело метода должно включать в себя код страны и всю информацию о гражданском адресе, полученную через опцию 99 DHCP. Сервер отвечает POST с идентификатором соты, определяющим расположение. Запрос идентификатора соты должен использовать следующий формат: 'POST ' path request ' НТТР/1.1' CRLF

'host: ' host CRLF

CRLF

message_body,

где Request = ‘CelllD’ — идентификатор соты;

Path = абсолютный путь URI, указанный в атрибуте Location элемента pull элемента Regionization Offering (типа OfferingListType, см. таблицу 18, пункт 19, с дополнительным /;

Host = расположение сети (полномочное), предоставленное URL, в атрибуте Location элемента pull элемента Regionization Offering (типа OfferingListType, см. таблицу 18, пункт 19);

message_body = элемент записи запроса соты, включая код страны и всю информацию о гражданском адресе, полученную через опцию 99 DHCP.

В поле «CountryCode» устанавливается значение, полученное из опции 99 DHCP.

Элементы СА рекомендуется перечислять в том же порядке, что и в сообщении DHCP.

Если в данных DHCP GEOCONF_CIVIC присутствует набор параметров для нескольких языков (CAtype=0), HNED должно предоставить идентификаторы регионов на всех языках.

Тело ответа от HTTP-сервера должно быть предложением регионализации (см. 5.2.11), содержащим один элемент Cell с результирующим идентификатором соты, который SP представил значениями CAtype в запросе. HNED должно игнорировать в ответе код страны и элементы СА.

  • 5.4.4 Сигнализация об изменениях в предложении провайдера или в информации для поиска провайдера

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

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

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

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

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

  • 5.4.5 Фрагментация записей SD&S

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

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

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

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

  • - запись открытия регионализации для локальных служб;

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

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

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

Таблица 21 —Типы записей информации SD&S, идентифицирующие полезную нагрузку

Значение идентификатора полезной нагрузки

Типы информации SD&S

0x00

Зарезервирован

0x01

Информация SD&S обнаружения провайдера служб

0x02

Информация SD&S обнаружения вещания

0x03

Информация SD&S обнаружения CoD

0x04

Службы SD&S от других провайдеров служб

0x05

Информация SD&S поиска пакета служб

0x06

Информация SD&S для поиска BCG

0x07

Информация SD&S для поиска региона

0x08

Запись файлов заглушки FUS и SD&S RMS-FUS

0x09

Информация об анонсировании SRM

ОхОА до ОхАО

Зарезервированы

0хА1 до OxAF

Значения ID полезной нагрузки BCG

0хВ0

Зарезервированы

0хВ1

Описание загрузки сеанса CDS XML

0хВ2

Обновления анонсирования встроенного ПО FUS RMS

ОхВЗ до OxBF

Зарезервированы

0хС1

Информация обнаружения приложений

0хС2 до OxEF

Зарезервированы

0xF0 до OxFF

Частный пользователь

Значения идентификаторов полезной нагрузки используются в протоколе DVBSTP или в протоколе HTTP, определенных в 5.4.1,5.4.2.

При фрагментации записей SD&S HNED должно поддерживать управление записями SD&S как совокупностью фрагментов. Сегменты определяются для одного типа информации SD&S, именуемого идентификатором полезной нагрузки. Каждому сегменту назначается идентификатор сегмента для объявленного типа данных SD&S (полезной нагрузки). Идентификатор сегмента должен быть 16-бито-вым. Сегмент должен быть хорошо сформированной и действительной записью XML.

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

Записи, содержащие информацию обнаружения провайдера служб (PayloadID 0x01), не должны сегментироваться при использовании режима pull. Во всех остальных случаях записи XML должны быть сегментированы. Запись начинается от одного сегмента.

В ГОСТ Р 54994—2012 (подраздел 5.4) показаны взаимосвязи между сегментами, идентификатором полезной нагрузки и записями.

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

  • 5.4.6 Записи XML и идентификатор полезной нагрузки

Записи XML должны быть выполнены таким образом, чтобы каждая запись содержала элементы только одного из основных типов XML по 5.2.11.

Поле Payloadld заголовка multicast-протокола должно отражать тип записи, содержащегося в передаваемых multicast-пакетах. Любая запись XML должна содержать корневой элемент ServiceDiscovery, который содержит произвольное число элементов только одного типа (например, BroadcastDiscovery). Любая запись XML должна содержать корневой элемент ServiceDiscovery, который содержит произвольное количество элементов только одного из следующих типов:

  • - BroadcastDiscovery;

  • - CoDDiscovery;

  • - ServiceFromOtherSP;

  • - ServiceProviderDiscover;

  • - BCGDiscovery;

  • - RegionalizationDiscovery;

  • - RMSFUSDiscovery;

  • - SRMDiscovery.

  • 5.4.7 Сегментация записей XML

Записи, содержащие информацию обнаружения провайдера служб (ID полезной нагрузки = 0x01) в режиме pull не должны сегментироваться.

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

Запись может состоять из одного сегмента.

Каждый сегмент должен содержать полный корневой элемент ServiceDiscovery, состоящий из целого числа дочерних элементов (например, BroadcastDiscovery), как определено в 5.2.11. Сегмент не должен содержать часть дочернего элемента. Сегмент не должен содержать более одного типа дочернего элемента.

Каждый сегмент должен быть действительным и правильно сформированным.

Каждый сегмент должен иметь уникальный идентификатор в области действия провайдера служб и идентификатор полезной нагрузки. Для общего группового адреса провайдер служб должен сигнализироваться полем ServiceProviderlD в заголовке DVBSTP (см. 5.4.1). Для multicast-адреса, передаваемого только одним провайдером служб, эта информация выводится из multicast-адреса. При использовании HTTP информация о провайдере служб включается в запрос (см. 5.4.2). Каждый сегмент может содержать элементы обнаружения вещания или элементы обнаружения пакетов только для одного пакета. Если сегмент создан для конкретного пакета, информация о пакете должна указываться атрибутом PackagelDRef элемента TargetPackage (см. таблицу 18, пункт 44).

  • 5.5 Кодирование сегментов

Сегменты SD&S могут быть закодированы с помощью BiM по ГОСТ Р 54994—2012 (подраздел 5.5). Провайдер сети должен сделать доступными некодированные сегменты SD&S, либо в режиме pull, либо в режиме push, либо в обоих режимах. В случае доставки одного кодированного и одного не-кодированного multicast-потока HNED может различать потоки в соответствии с флагом «compression» заголовка DVBSTP.

Примечание — Если SP поставляет BCG, то ожидается, что HNED поддерживает кодирование BiM.

УДК 621.397.132.129:006.354

ОКС 33.170


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

Редактор Н.В. Таланова Технический редактор В.Н. Прусакова Корректор Л. С. Лысенко Компьютерная верстка ГД. Мухиной

Сдано в набор 28.10.2021. Подписано в печать 29.11.2021. Формат 60*84%. Гарнитура Ариал. Усл. печ. л. 4,65. Уч.-изд. л. 4,20.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Создано в единичном исполнении в ФГБУ «РСТ» , 117418 Москва, Нахимовский пр-т, д. 31, к. 2.