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

        ГОСТ Р 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

ОКС 33.170

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

Предисловие

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

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 26 октября 2021 г. N 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 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

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 может функционировать на четвертом и более высоких уровнях OSI.

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

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

Возможности предложений служб 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 (PAT и РМТ).

Информацию о службах 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 сети Интернет.

Триплет числовых идентификаторов , и применяется в соответствии с ГОСТ Р 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HNED географически расположено в регионе, который определяют провайдер служб и идентификатор соты. Идентификатор соты является уникальным идентификатором HNED внутри страны. Расположение HNED может быть определено по коду страны и идентификатору соты. Идентификатор соты используется в элементе ServiceAvailability таблицы 3 и в элементе 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 - Семантика поля предложений о регионе

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

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

’POST ’ path request ’ HTTP/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 - Определения семантики полей служб по ссылкам

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

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

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

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

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

Примечание - Если система CP использует идентификаторы SRM системы CP и в объявлении предоставляется только идентификатор системы CP, для получения информации об идентификаторах SRM системы CP 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

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

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

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

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

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

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

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

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

Все точки входа обнаружения, кроме 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-1

xmlns:tva=urn:tva:metadata:2011

xmlns:dvb12=urn:dvb:metadata:iptv:sdns:2012-1

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

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

xmlns:mpeg7=urn:tva:mpeg7:2008

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

<xsd:annotation>

<xsd:documentation>chema 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-1_v171.xsd/>

<xsd:import namespace=urn:dvb:metadata:iptv:sdns:2008-1 schemaLocation=./sdns_v1.4r13.xsd/>

<xsd:import namespace=urn:dvb:metadata:iptv:sdns:2012-1 schemaLocation=./sdns_v1.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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

- 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 ’ HTTP/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 ’ HTTP/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;

Segmentltem=Segmentld 0*1(‘&Version=’VersionNumber;

Segmentltem - это Segmentld с опциональным полем для номера версии;

VersionNumber=2 HEXDIG; любой шестнадцатеричный номер от 00 до ff.

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

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

’POST ’ path request ’ HTTP/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, идентифицирующие полезную нагрузку

Значения идентификаторов полезной нагрузки используются в протоколе 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.