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

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

ТЕЛЕВИДЕНИЕ ВЕЩАТЕЛЬНОЕ ЦИФРОВОЕ. ПЕРЕДАЧА СЛУЖБ DVB ПО СЕТЯМ С IP ПРОТОКОЛАМИ

Общие технические требования

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

Москва

Стандартинформ

2013

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации — ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения»

Сведения о стандарте

1    РАЗРАБОТАН Федеральным государственным унитарным предприятием «Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении» (ВНИИНМАШ) и Федеральным государственным унитарным предприятием «Ордена Трудового Красного Знамени Научно-исследовательский институт радио», Самарский филиал «Самарское отделение научно-исследовательского института радио» (филиал ФГУП «НИИР-СОНИИР»)

2    ВНЕСЕН Управлением технического регулирования и стандартизации Федерального агентства по техническому регулированию и метрологии

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

4    Настоящий стандарт разработан с учетом основных нормативных положений стандарта Европейского института по стандартизации в области телекоммуникаций (ЕТСИ) ETSITS 102 034 VI.4.1 (2009-08) «Телевидение вещательное цифровое. Техническая спецификация. Передача транспортного потока MPEG-2 базовых служб DVB через базовые сети IP» (ETSI TS 102 034 VI .4.1 (2009-08) «Technical Specification. Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks»)

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

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

©Стандартинформ,2013

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

SP (Service Provider) — провайдер службы;

SPI (Source Packet Information) — информация исходного пакета;

SR (Sender Report) — отчет отправителя;

SRBT (Sub-Report Block Type) — тип блока суботчета;

SSL (Secure Socket Layer) — уровень безопасности сокета;

SSM (Single Source Multicast) — одиночная исходная многоадресная передача;

SSM (Source Specific Multicast) — источник определенной (специфичной) многоадресной передачи; SSRC (Synchronization Source) — источник синхронизации;

STC (System Time Clock) — часы системного времени;

SVC (Switched Virtual Circuit) — коммутируемый виртуальный канал;

TCP (Transmission Control Protocol) — протокол управления передачей (из стека протоколов TCP/IP); TCP/IP — стек протоколов сетевого и транспортного уровня;

TDT (Time and Date Table) — таблица времени и даты;

TLS (Transaction Layer Security) — безопасность уровня транзакции;

ToS (Type of Service) — тип службы (сервиса);

ТОТ (Time Offset Table) — таблица смещения времени;

Trick— режим [мода] быстрого проигрывания мультимедиа;

TS (Transport Stream) — транспортный поток (цифрового вещательного телевидения); ТП;

T-STD (The Transport Stream System Target Decoder) — системный целевой декодер транспортного потока;

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

UCS (Universal Character Set) — универсальный набор символов;

UD (Unicast Download) — одноадресная загрузка;

UDP (User Datagram Protocol) — протокол пользовательских датаграмм;

Ul (User Interface) — интерфейс пользователя;

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

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

UTC (Universal Time Coordinated) — всемирное координированное время;

UTF-8 (Unicode Transformation Format) — формат преобразования Юникода, реализующий представление Юникода, совместимое с 8-битным кодированием текста;

WINS (Windows Internet Name Service) — служба сопоставления NetBIOS-имён компьютеров с IP-адресами узлов;

World Wide Web — глобальная распределенная система гипермедиа, размещенная в сети Интернет; XML (Extensible Markup Language) — расширяемый язык разметки;

«pull» — режим «получение информации [записи] по запросу»;

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

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

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

4.1.1    Модель системы передачи транспортных потоков служб DVB по сетям с IP протоколами (DVB-IP)

Система передачи транспортных потоков служб DVB по сетям с IP протоколами (DVB-IP) обеспечивает передачу служб DVB («вещание медиа» (Live Media Broadcast; LMB)), передачу «контента по запросу» (CoD)) на домашнюю платформу клиента. Модель уровней DVB-IP, представленная на рисунке 1, включает в себя следующие домены:

ГОСТ Р 54994-2012

-    провайдер контента;

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

-сеть доставки;

-домашняя платформа клиента.

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

Провайдер служб (Service Provider; SP) представляет собой объект, предоставляющий службу конечному пользователю на домашнюю платформу клиента. Провайдерами служб могут быть Интернет-провайдеры (Internet Service Providers; ISP) и провайдеры служб контента (Content Service Provider; CSP).

В контексте служб DVB провайдер служб получает контент (на основе соглашения) от провайдеров контента и преобразует его в службу.

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

Сеть доставки в общем случае прозрачна для трафика IP.

Рисунок 1 — Модель уровней DVB-IP

4.1.2 Эталонная модель домашней сети

Эталонная модель домашней сети представлена на рисунке 2.

В ее состав входят следующие элементы:

-    шлюз сети доставки (DNG), соединенный с одной или несколькими сетями доставки и с одним или несколькими сегментами домашней сети;

-    сегмент домашней сети (HNS). Совокупность HNS в составе эталонной модели домашней сети формирует домашнюю сеть, которая является отдельной «субсетью IP». HNS присваиваются имена, включающие наименование сетевой технологии (Ethernet или беспроводная LAN) и собственное имя HNS;

-    узел домашней сети (HNN) соединяет два или более HNS друг с другом и выполняет функции моста. Параметры HNN должны быть в соответствии с IEEE [3], [4] (ниже границы службы MAC). HNN должен поддерживать процедуры для обеспечения необходимого качества обслуживания (QoS) согласно IEEE [5] в соответствии с разделом 7 настоящего стандарта;

-    оконечное устройство домашней сети (HNED).

9

Рисунок 2 — Эталонная модель домашней сети

Взаимодействие между устройствами эталонной модели домашней сети описываются интерфейсами, которые показаны на рисунке 2. Наименования этих интерфейсов образуются из аббревиатуры IPI и порядкового номера от 1 до 4.

В настоящем стандарте рассматриваются требования к интерфейсу IPI-1. Требования к интерфейсам IPI-2, IPI-3, IPI-4 в этом стандарте не предъявляются.

Для передачи трафика при использовании IP протокола все интерфейсы IPI-1 должны соответствовать требованиям IETF [6], при использовании протокола ARP — требованиям IETF [7].

4.1.3 Диаграмма стека протоколов DVB-IPTV

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

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

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

Встроенное программное обеспечение (ПО) профиля DSM-CC для FUS RMS должно быть в соответствии с ETSI [8].

Информация, которой обмениваются при использовании протокола RTSP, может быть передана в формате SDP или XML.

Запись TLS / SSL означает, что могут использоваться TLS или SSL.

Запись HTTP / HTTPS означает, что могут использоваться HTTP или HTTPS.

ГОСТ Р 54994-2012

Промежуточное программное обеспечение (middleware) и функции

Управление службой качества Ethernet (QoS Management) Кодовые точки дифференцированных служб (DSCP) Соединение многоадресной службы Протокол управления группами (пользователей) в сети Интернет (IGMP) Управление доставкой Управляющий транспортный протокол реального времени (RTCP) Прямое исправление ошибок на уровне Базовый уровень Транспорт-ный прото- приложений (AL-FEC) Улучшенный уровень Аудио, аудио/видео, информация о службах, программно-зависимая информация (Audio, AV, SI, PSI) Транспортный поток MPEG-2 кол реального времени (RTP) Обновление встроенного ПО (многоадресная доставка) Система команд и управления для средств цифровой записи (DSM-CC) ю Доставка файла по однонаправленному £ 5 Загрузка контента (многоадресная доставка) транспорту (i-LU 1 ь) о з О. Ф Путеводитель по контенту вещания 5 5 Ct >s (многоадресная доставка) (BCG) Транспортный протокол обнаружения и выбора службы DVB (DVBSTP) О. i_ >s m о Q. с Обнаружение и выбор службы (многоадресная доставка) (SD&S)) н >s ф S о ф У ё Анонсирование загрузки контента X S СО S ю £ (многоадресный режим) Протокол анонсирования сеанса / о л § СО ■а 5 Служба обновления встроенного ПО; Протокол описания сеанса (SAP / SDP) 1 о < К S анонсирование службы Транспортный протокол обнаружения и выбора службы DVB (DVBSTP) m о СО I I Стаб службы обновления встроенного ПО (многоадресная доставка) § с с CL со ц со X О. Инициализация Протокол динамической конфигурации хоста (DHCP) § 1 3 S X ф об Система доменных имен (DNS) о. с о К Сетевой протокол времени/ Простой сетевой X 9 Аутентификация протокол времени (NTP / SNTP) 0 1 о. Безопасность уровня транзакции/ Безопасный уровень сокета (TLS / SSL) с Протоколы передачи гипертекстовых файлов О. £ Стаб службы обновления встроенного ПО (одноадресная доставка) (Ml 1 К / М 1 1 >s ф z Служба обновления встроенного ПО в одноадресном режиме со 9 О. ф Путеводитель по контенту вещания (одноадресная доставка) (BCG) Протокол передачи гипертекстовых файлов (HTTP) с к S X Обнаружение и выбор службы (одноадресная доставка) (SD&S)) ф 5 СО о. Загрузка контента (одноадресная доставка) с >. § Анонсирование загрузки контента (одноадресный режим) о о о. Служба соединения и управления потоком Потоковый протокол реального времени (RTSP) с

Рисунок 3 — Диаграмма стека протоколов служб DVB-IPTV

4.2 Сценарии использования HNED в сетях DVB-IPTV

Для всех возможных сценариев использования HNED предусматривается:

-    использование механизмов DHCP для присвоения HNED IP-адреса и других параметров;

-    передача трафика IP через DNG к HNED на сетевом уровне OSI.

11

ГОСТ Р 54994-2012

5 Требования к открытию службы

5.1    Определение службы. Вводная часть

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

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

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

-    «вещание медиа» (LMB);

-    «контент по требованию» (CoD);

-    «служба загрузки контента» (CDS).

Настоящий стандарт, кроме того, предусматривает две моды службы «вещания медиа» (LMB):

-    «транспортный поток, полная SI» («ТП полная SI»);

-    «транспортный поток, дополнительная SI» («ТП дополнительная SI»).

5.2    Механизм открытия службы

5.2.1    Открытие службы выполняется сцеплением (сочетанием) идентификатора провайдера службы и идентификатора службы.

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

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

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

-    сочетанием трех числовых идентификаторов: original_network_id, transport_stream_id и servicejd в соответствии с ETSI [9].

Синтаксис текстового идентификатора службы должен быть в соответствии с ETSI [10] (14.9).

5.2.2    Определены следующие типы информации, которые могут быть использованы в будущем:

-    SD&S информация, касающаяся провайдера службы;

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

-    запись открытия руководства по контенту вещания;

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

-    встроенное ПО информации анонсирования, обеспечивающее обновление или изменение встроенного ПО HNED.

Эти типы информации охватывают различные типы служб, которые может предлагать SP. Предложение SP может включать службу «вещания медиа» («ТП полная SI» или «ТП дополнительная SI») или “CoD”. SP может также предлагать ссылку на услуги, предоставляемые другим SP, или формировать пакет, в который группируется несколько служб с последующим представлением их как единственного объекта. Эти типы SD&S информации должны быть идентифицированы 8-битовым значением ID полезной нагрузки.

5.2.3    В таблице 1 представлены типы записей информации SD&S, которые могут использоваться для идентификации полезной нагрузки.

Таблица 1 — Типы записей информации SD&S, которые могут использоваться для идентификации полезной нагрузки

Значение идентификатора полезной нагрузки Типы информации SD&S 0x00 Зарезервирован 0x01 Информация для поиска провайдера служб 0x02 Информация для поиска вещания 0x03 Информация для поиска COD 0x04 Службы от других провайдеров служб 0x05 Информация для поиска пакета

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

Значение идентификатора полезной нагрузки Типы информации SD&S 0x06 Информация для поиска BCG / 0x07 Информация для поиска региона I 0x08 Запись файлов FUS Stub и SD&S RMS-FUS / 0x09 до ОхАО Зарезервированы / 0хА1 до OxAF Загрузка значений ID BCG, определенных в соответствии с ETSI [11] / 0хВ0 Зарезервированы / 0хВ1 Описание загрузки сеанса CDS XML I 0хВ2 Обновления анонсирования встроенного ПО FUS RMS / ОхВЗдо OxBF Зарезервированы 1 0хС1 Информация открытия (обнаружения) приложений / 0хС2 до OxEF Зарезервированы / OxFOflO OxFF Частный пользователь /

5.2.4 Записи SD&S полезной нагрузки должны быть сегментированы. Каждый сегмент должен быть сформированной и допустимой записью XML. ID сегмента должен иметь 16-битовое значение. Для определения текущей версии сегмента должно использоваться 8-битовое значение, которое должно увеличиваться с каждым изменением версии сегмента. Номер версии неизменяемого сегмента не должен изменяться. Записи, содержащие информацию для поиска SP (PayloadID 0x01), не должны сегментироваться в режиме «получения информации по запросу» («pull»). Во всех других случаях записи XML должны быть сегментированы. Запись может содержать единственный сегмент. Связь между сегментами, ID полезной нагрузки и записями представлена на рисунке 6. Детализированные правила разделения записей XML на сегменты должны быть в соответствии с ETSI [12] (приложение С, С.1.6).

&

ID полезной нагрузки

Рисунок 6 — Связь между сегментами,

ID полезной нагрузки и записями

5.2.5    Продолжительность передачи всех сегментов, составляющих полный комплект информации SD&S для провайдера, не должна превышать 30 с (максимальное время цикла).

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

Процедуры открытия службы иллюстрируются на рисунке 7.

ГОСТ Р 54994-2012

Рисунок 7 — Процедуры открытия службы

Перечень этапов процедуры открытия службы включает в себя:

-    поиск точки входа открытия службы;

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

-    сбор информации для поиска службы DVB-IP для каждого провайдера службы.

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

а)    группового адреса, зарегистрированного в IANA 224.0.23.14 (DvbServDisc);

б)    списка SD&S адресов точек входа от сервера DNS согласно месту предоставления служб в соответствии с IETF [13].

Точки входа SD&S могут быть также получены при соединении оконечного устройства домашней сети с сетью, для запроса ее собственного адреса (например, в случае DHCP), через опцию 15 DHCP.

Процесс поиска SD&S точки входа HNED рекомендуется выполнять в обратном порядке, начиная с пункта б). В случае, когда один из шагов обеспечивает получение, по крайней мере, одной точки входа, рекомендуется прекратить поиск новых точек. В том случае, если ни один из шагов поиска не обеспечил получение точки входа, поиск точки входа должен выполняться вручную. Детализированное описание процедур определения точек входа представлено в ETSI [12] (5.2.4).

5.2.8    На первом этапе процесса открытия службы выполняется открытие провайдера служб. При этом обеспечивается как открытие провайдеров, предлагающих в сети службы DVB-IPTV, так и сбор информации о расположении предложений различных провайдеров. Информация для поиска SP может быть передана в режиме многоадресной передачи информации («push») или получена по запросу («pull»). Сервер должен поддерживать один из двух режимов. Рекомендуется поддержка сервером двух режимов. Оба режима должны поддерживаться клиентом (пользователем). Допускается агрегатировать записи для открытия SP с целью минимизации количества записей.

Запись открытия провайдера служб должна переноситься в записи, содержащие атрибуты и элементы, представленные в ETSI [12] (таблица 2). Эти записи реализуют и информацию для поиска провайдера служб, и компоненты модели данных провайдера служб, представленные в приложении А.

5.2.9    Сбор информации для поиска службы DVB-IPTV выполняется использованием записи предложения DVB-IPTV служб и иллюстрируется моделью потоков данных поиска информации о службах в приложении А.

Запись предложения DVB-IP служб должна содержать поля в соответствии с таблицей 2, сопровождаемые полями фактических предложений провайдеров служб.

Таблица 2 — Запись предложения DVB-IPTV служб

Имя элемента / атрибута Описание элемента / атрибута Условия применения @DomainName Доменное имя DNS, зарегистрированного провайдера служб. Однозначно определяет провайдера служб Обязательное @Version Версия предложения записи DVB-IPTV; номер версии будет увеличиваться каждый раз при изменении предложения записи DVB-IPTV (Примечание) Примечание — Номер версии записи предложения DVB-IPTV обязателен в режиме «получения записи по запросу» («pull») и является дополнительным (опциональным), когда запись выполнена в режиме многоадресной передачи («push»).

15

5.2.10    Запись открытия служб формируется для следующих служб:

-    «вещания медиа» (моды «ТП полная SI» или «ТП дополнительная SI»);

-    «контент по требованию» (CoD);

-    предоставленных другими провайдерами служб (служба «от другого провайдера служб»);

-    предоставленных провайдером служб пакета («пакет служб»), включающего в себя несколько служб, с последующим представлением этого пакета в качестве одной службы.

Модель открытия служб представлена в приложении А.

5.2.10.1    Запись открытия «вещания медиа» для моды «ТП полная SI» (тип XML Broadcastoffering) формируется из записей предложения DVB-IPTV служб. Эти записи предоставляют необходимую информацию для нахождения доступных служб «вещания медиа». Информация об индивидуальных службах получена из транспортного потока использованием информации, содержащейся в DVB-SI. Запись открытия «вещания медиа» должна включать атрибуты, представленные в таблице 2, и должна содержать поля, представленные в ETSI [12] (таблица 4). Процедура выполнения записи открытия «вещания медиа» для моды «ТП полная SI» иллюстрируется моделью потоков данных поиска информации о службах в приложении А.

5.2.10.2    Формирование записи открытия «вещания медиа» для моды «ТП дополнительная SI» из записей предложения DVB-IP выполняется аналогично изложенному в 5.2.6. Эта запись должна включать атрибуты, представленные в таблице 2, и должна содержать поля, представленные в ETSI [12] (таблица 5). Процедура выполнения записи открытия «вещания медиа» для моды «ТП дополнительная SI» иллюстрируется моделью потоков данных поиска информации о службах в приложении А.

5.2.10.3    Запись открытия службы «контент по требованию» должна включать атрибуты, представленные в таблице 2, и должна содержать поля, представленные в ETSI [12] (таблица 6). Процедура выполнения записи открытия службы «контент по требованию» иллюстрируется моделью потоков данных поиска информации о службах в приложении А.

5.2.10.4    Запись службы «от другого провайдера служб» должна включать все атрибуты, представленные в таблице 2, и должна содержать поля, представленные в ETSI [12] (таблица 7). Процедура выполнения записи открытия службы «от другого провайдера служб» иллюстрируется моделью потоков данных поиска информации о службах в приложении А.

5.2.10.5    Запись открытия «пакета служб» обеспечивает возможность комплектования набора служб для поставки в отдельном пакете. Запись открытия «пакета служб» содержит информацию для поиска пакета, включая идентификатор службы и описание расположения. Запись открытия «пакета служб» должна включать все атрибуты, представленные в таблице 2, и должна содержать поля, представленные в ETSI [12] (таблица 8). Процедура выполнения записи открытия службы «пакет служб» иллюстрируется на модели потоков данных поиска информации о службах в приложении А.

5.2.10.6    Запись руководства вещания контента обеспечивает возможность обнаружения расположения документов, содержащих перечисления доступного контента, например, в предложениях вещания через CoD или CDS. Обнаружение провайдера происходит использованием предложения услуги в соответствии с ETSI [11]. Запись руководства вещания контента выполняется в соответствии с ETSI [12] (5.2.6.6).

5.2.11    Открытие идентификатора соты, в которой расположено домашнее оконечное сетевое устройство, выполняется одновременным использованием кода страны и идентификатора соты. Этот идентификатор используется в элементе PackageAvailability в ETSI [12] (таблица 8) и элементе ServiceAvailability в ETSI [12] (таблицы 4 и 5), что позволяет указать, какой пакет и какие службы могут быть получены домашним оконечным сетевым устройством.

HNED получает данные о своем расположении от сервера DHCP использованием опции GEOCONF CIVIC, код 99 в соответствии с IETF [14], ETSI [12] (8.1.1.11). HNED может получить ID сотыми следующими способами:

-запросом на сервер URI в режиме «pull», в соответствии с ETSI [12] (5.2.6.7.1).

-через запись открытия районирования — в режиме «push», в соответствии с ETSI [12] (5.2.6.7.1).

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

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

Детализированные процедуры открытия ID сот должны быть в соответствии с ETSI [12] (5.2.6.7).

5.2.12    Информация о службах FUS и RMS, доступных HNED, может быть получена применением процедур SD&S (опционально) при использовании данных (точек входа) о расположении этих служб.

ГОСТ P 54994—2012

В случае FUS необходимое расположение точек входа служб FUS и RMS определяется:

-    при многоадресной передаче - в режиме «push»;

-    при одноадресной передаче при соединении со службами анонсирования — в режиме «pull».

В обоих случаях HNED использует канал QRC для запроса FUS.

В случае RMS для HNED требуется только канал управления, являющийся одноадресной службой.

Детализированные процедуры выполнения записи информации о сервисах FUS и RMS должны быть в соответствии с ETSI [12] (5.2.6.8).

5.3 Выбор службы

5.3.1    Доступ отдельного HNED к потоковой передаче базовой службы обеспечивается использованием:

-    протокола IGMP;

-    протокола RTSR

Службы «вещания медиа» при многоадресной передаче IP передаются непрерывным потоком. Их передача не должна инициироваться каждым домашним сетевым оконечным устройством. Отдельные HNED могут присоединиться к службам «вещания медиа», формируя запросы о присоединении к многоадресным службам, выпуская соответствующие сообщения IGMP. Элемент «Service Location» в записях открытия службы содержит всю информацию, необходимую для формирования соответствующего сообщения IGMP Однако, HNED не получает возможности управления потоком (например, типа «пауза» или «ускоренная перемотка»).

Опционально: Провайдеры служб могут требовать непосредственного участия HNED в этапах набора и разъединения со службами «вещания медиа» (возможными причинами таких требований могут быть: необходимость учета поставляемых услуг, необходимость обслуживания условного доступа и т. д.). В таких случаях должен использоваться протокол сеанса RTSP согласно IETF [15]. Элемент «Service Location» в записи открытия службы сигнализирует об использовании протокола RTSP и дает информацию, необходимую для запуска соответствующего метода RTSP.

Параметры для сообщения IGMP будут получены от RTSP методом SETUP.

5.3.2    Служба «вещания медиа с режимом Trick» (MBwTM) аналогична службе «вещания медиа», но использует режим одноадресной передачи IP, обеспечивающий возможность управления потоком.

5.3.3    Службы «контент по требованию» и «вещание медиа с режимом Trick» используют одноадресную передачу IP, они предназначены для конкретного пользователя и должны инициироваться конкретным HNED. Для получения доступа к таким службам должен использоваться протокол RTSP. Раздел 6 настоящего стандарта определяет параметры используемых методов RTSP.

5.3.4    Выбор параметров службы для CDS рассмотрен в разделе 10 настоящего стандарта.

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

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

-    многоадресной передачи;

-одноадресной передачи.

Для доставки записей XML при многоадресной передаче используется транспортный протокол DVBSTP механизма DVB SD&S. Параметры протокола DVBSTP определены в 5.4.2 настоящего стандарта.

При одноадресной передаче информации SD&S должен использоваться протокол HTTP в соответствии с IETF [16].

5.4.2    В тех случаях, когда информация для доставки информации SD&S с целью поиска службы передается с использованием многоадресного пакета протокола UDP, должен применяться транспортный протокол DVBSTP.

Протокол DVBSTP используется также для многоадресной доставки данных руководства по контенту вещания согласно ETSI [11], для многоадресной доставки сообщений анонсирования встроенных программных обеспечений (ПО) ETSI [17] и для многоадресной доставки описаний сеанса загрузки XML CDS, как определено в разделе ETSI [12] (10.4.2). Схема URI DVBSTP представлена в приложении Б.

5.4.3    Синтаксис многоадресного протокола доставки DVBSTP представлен на рисунке 8.

17

ГОСТ Р 54994-2012

Содержание

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

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

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

4    Основные параметры системы передачи транспортных потоков служб DVB по сетям с IP протоколами ............................................... 8

4.1    Архитектура системы передачи транспортных потоков служб DVB по сетям с IP протоколами .    8

4.2    Сценарии использования HNED в сетях DVB-IPTV....................... 11

5    Требования к открытию службы.................................. 13

5.1    Определение службы. Вводная часть............................. 13

5.2    Механизм открытия службы.................................. 13

5.3    Выбор службы......................................... 17

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

5.5    Кодирование.......................................... 21

6    Протокол RTSP.......................................... 21

6.1    Использование протокола RTSP для служб DVB........................ 21

6.2    Профили протокола RTSP................................... 22

6.3    Методы RTSP......................................... 23

6.4    Состояния кодов в ответах на запросы............................. 25

6.5    Использование RTSP при многоадресной передаче...................... 25

7    Передача транспортного потока MPEG-2 для служб в реальном времени............. 25

7.1    Общие положения....................................... 25

7.2    Инкапсуляция транспортного потока MPEG-2.......................... 25

7.3    Требования к сети IP...................................... 28

7.4    Инициирование службы и управление службами........................ 29

7.5    Качество службы....................................... 29

8    Распределение IP адресов и сетевые службы времени...................... 29

8.1    Адресация IP и маршрутизация................................ 29

8.2    Сетевые сервисы времени................................... 30

9    Системные заглушки загрузки файла (FUSS) для активирования обновления системного программного обеспечения HNED...................................... 31

9.1    Общие положения....................................... 31

9.2    Получение файла заглушки.................................. 31

9.3    Формат файла заглушки.................................... 31

10    «Служба загрузки (пересылки) контента» (CDS).......................... 31

10.1    «Служба загрузки    контента».    Вводная часть......................... 31

10.2    Функциональная архитектура CDS.............................. 32

10.3    Анонсирование службы загрузки контента при использовании BCG.............. 35

10.4    Форматы CDS элементов контента и файлов......................... 36

10.5    Описание сеанса загрузки службы загрузки контента..................... 36

10.6    Загрузка элементов контента службы загрузки контента.................... 37

10.7    Управление хранением HNED службы загрузки контента................... 37

11    Качество службы......................................... 38

11.1    Общие положения...................................... 38

11.2    Маркировка пакетов DSCP.................................. 38

11.3    Приоритет Ethernet...................................... 38

Приложение А (справочное) Модель данных SD&S......................... 39

Приложение Б (обязательное) Информация, связанная со службой загрузки контента (CDS).....    40

Приложение В (обязательное)    Решения    повторной передачи RTP.................. 42

Библиография............................................ 48

0 12 3 0123456 7 890123456 7 890 1 234 567 8901 Ver Resrv Enc С Total_Segment_Size Payload ID Segment ID Segment_Version Section_Number | Last Section number Compr p HDR_LEN (Conditional) Service Provider ID (Optional) Private Header Data Payload (Optional) CRC (Optional) CRC (Cont)

Рисунок 8 — Синтаксис многоадресного протокола доставки DVBSTP

5.4.3.1 Семантика многоадресного протокола доставки DVBSTP:

-    Ver (Protocol Version): поле «Версия протокола», 2 бита. Поле «Версия протокола» должно иметь значение «00»;

-    Resrv (Reserved): поле «Резерв», 3 бита. Поле «Резерв» должно иметь значение «ООО»;

-    Enc (Encryption): поле «Шифрование», 2 бита. Поле «Шифрование» должно использоваться для сигнализации о присутствии процедуры шифрования полезной нагрузки. Значение «00» указывает, что полезная нагрузка не зашифрована. Синтаксис, семантика, поведение и другие значения не определены;

-С (CRCflag): поле «ФлагCRC», 1 бит. Значение поля «ФлагСРС» «1», указывает на присутствие 32-разрядного CRC в конце пакета. Этот флаг может быть установлен в заключительном пакете сегмента, когда section_number соответствует last_section_number;

-    Total segment size: поле «Полный размер сегмента», 24 бита. Поле определяет размер сегмента в байтах. Для некомпрессированных данных (поле Compression «000»), это поле определяет совокупный размер всех полезных нагрузок всех секций, включенных в сегмент (без заголовков и полей CRC, если они присутствуют). Для компрессированных данных, например BiM, это поле определяет совокупный размер всех полезных нагрузок всех секций согласно 5.4.3.2.1 настоящего стандарта, включенных в сегмент (без заголовков и полей CRC, если они присутствуют),—это поле называется «переданный размер» («transmitted size»). Для компрессированных данных, которые должны быть распакованы перед использованием (например, zlib), это поле определяет размер сегмента, однажды распакованного указанным алгоритмом (отмечают, что это, возможно, не тот же самый размер, какой имел исходный XML), — это поле называется «декомпрессированный размер» («decompressed size»). Определение значения компрессированного поля должно указывать, какой должна быть интерпретация полного размера сегмента;

-    Payload ID: поле «ID полезной нагрузки», 8 битов. Поле идентифицирует тип данных, перенесенных в пределах полезной нагрузки. Значения типов данных приведены в таблице 1;

-Segment ID: поле «ID сегмента», 16 битов. Поле идентифицирует сегмент данных для объявленного типа полезной нагрузки (РТ). В случае многократных записей информации для открытия вещания каждой записи будет присвоен уникальный ID;

-    Segment_Version: поле «Версия сегмента», 8 битов. Поле определяет текущую версию сегмента, находящегося в процессе переноса. Поле включает ID полезной нагрузки вместе с ID сегмента. Максимальный размер поля составляет 256, и после заполнения поля подсчет начинается сначала. Версия сегмента должна изменяться только в начале сегмента. Однако, для обработки функции потери пакетов приемник должен проверять изменение версии сегмента в любой точке сегмента;

-    Section_Number: поле «Количество секций», 12 битов. Поле идентифицирует количество секций в сегменте. Номер первой секции в сегменте должен быть 0;

-    Last Section number: поле «Номер последней секции», 12 битов. Поле «Номер последней секции» определяет номер последней секции (с самым высоким номером в Поле количество секций) в сегменте;

-    Compr (Compression): поле «Компрессия», 3 бита. Поле «Компрессия» указывает на схему компрессии полезной нагрузки (если компрессия применяется). Все сегменты данного ID полезной нагрузки должны совместно использовать одно и тоже значение компрессии. Значения компрессии представлены в ETSI [12] (таблица 12). Компрессия GZIP доступна только с ID полезной нагрузки 0x08 для использования с RMS/FUS или с ГО полезной нагрузки 0x07 с информационной записью районирования;

ГОСТ Р 54994-2012

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

ТЕЛЕВИДЕНИЕ ВЕЩАТЕЛЬНОЕ ЦИФРОВОЕ. ПЕРЕДАЧА СЛУЖБ DVB ПО СЕТЯМ

С IP ПРОТОКОЛАМИ

Общие технические требования

Digital broadcast television. Transport of DVB services over networks with IP protocols. General technical requirements

Дата введения — 2013—04—01

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

Настоящий стандарт распространяется на параметры интерфейса оконечного устройства домашней сети (Home Network End Device; HNED), который при работе в сетях с IP протоколами обеспечивает передачу на HNED транспортных потоков MPEG-2 служб DVB.

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

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

ГОСТ Р 52210-2004 Телевидение вещательное цифровое. Термины и определения

ГОСТ Р 52591-2006 Система передачи данных пользователя в цифровом телевизионном формате. Основные положения

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

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

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

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

3.1.1    артефакт (artefact): Дефект изображения.

3.1.2    букет программ: Совокупность сервисов, предлагаемых абоненту как единый программный продукт.

3.1.3    вещатель (broadcaster [Service Provider]): Организация, которая собирает последовательность событий или программ для доставки.

3.1.4    декларация типа документа (Document Type Declaration; DTD): Составная часть XML-доку-мента, содержащая имя типа документов, DTD или ссылку на DTD, которому соответствует данный документ.

3.1.5    документ DVB-HTML (DVB-HTML document): Полный (завершенный) модуль элементов или форматов контента одного семейства HTML, определенного в настоящем стандарте.

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

3.1.6    домашняя мультимедийная платформа (Multimedia Home Platform; МНР): Аппаратно-программный комплекс, обеспечивающий доступ пользователя к интерактивным и вещательным службам.

3.1.7    домашняя сеть: Домен домашней платформы клиента, являющийся потребителем аудио- и видео служб, в общем случае представляет собой сеть терминалов.

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

3.1.9    дескриптор (descriptor): Кодовое слово, служащее для описания типа передаваемых данных.

3.1.10    загрузка (download): Пересылка файлов по сети от пользователя или сервера пользователю или серверу.

3.1.11    идентификатор типа пакета (packet identifier; PID): Тринадцатибитовый указатель в заголовке транспортного пакета, определяющий принадлежность пакета тому или иному потоку данных.

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

-    работает с 32-битовыми адресами, обеспечивает адресацию и маршрутизацию пакетов в сети;

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

3.1.13    интероперабельность (interoperability): Нейтральная платформа, обеспечивающая прием и представление приложений для поставщика, автора и вещателя (функциональная совместимость).

3.1.14    интерфейс: Семантическая и синтаксическая конструкция в коде программы, используемая для специфицирования услуг, предоставляемых классом или компонентом. Интерфейс определяет:

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

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

3.1.15    информация о службах (Service Information; SI): Совокупность таблиц, которые передаются в составе транспортных потоков MPEG-2, предназначенных для вещания. К основным таблицам информации о службах относятся таблицы, характеризующие параметры сети передачи, компоненты служб: таблица объединения букета программ (Bouquet Association Table; ВАТ), таблица информации о событиях (Event Information Table; EIT), таблица состояния событий (Running Status Table; RST), таблица описания служб (Service Description Table; SDT), таблица времени и даты (Time and Date Table; TDT), таблица смещения времени (Time Offset Table; TOT).

3.1.16    Карусель Данных (Data Carousel): Передача модулей данных с циклическим повторением.

3.1.17    Карусель Объектов (Object Carousel; ОС): Передача в транспортном потоке циклически повторяющихся объектов (Файлов, Каталогов, Потоков).

3.1.18    Клиент (Client): Потребитель услуг одного или более серверов.

3.1.19    коммутируемый виртуальный канал (Switched Virtual Circuit; SVC): Тип логического соединения, устанавливаемого по запросу пользователя только на время, необходимое для обмена информацией.

3.1.20    контекст (context): Состояние системы; окружение системы, среда выполнения программы; текущая ситуация.

3.1.21    контент (content): Содержание, мультимедийный продукт (например, телевизионная программа).

3.1.22    конфигурация (configuration): Совокупность аппаратных и программных средств и связей между

ними.

3.1.23    конфигурирование: Установление конфигурации.

3.1.24    кэш (cache): Быстродействующая буферная память большой емкости, используемая для хранения копии областей оперативной памяти с наиболее частым доступом.

3.1.25    медиа (media): Информационные сообщения, передаваемые по каналам вещания (MPEG кадры звука, MPEG кадры изображения, JPEG кадры изображения, файлы текста, субтитров, загружаемых шрифтов, графическая информация).

3.1.26    междуобъектный интерфейс (inter-entity interface): Интерфейс между двумя объектами, находящимися в различных подсистемах.

3.1.27    многоцелевые расширения почты Интернет (Multipurpose Internet Mail Extensions; MIME): 1 Стандарт, описывающий передачу различных типов данных. 2 Спецификация для кодирования информации и форматирования сообщений.

ГОСТ Р 54994-2012

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

3.1.29    нормальная форма Бэкуса-Наура; БНФ (Backus Normal Form; BNF): Нотация (метаязык) для записи синтаксиса языков программирования.

3.1.30    обнаружение и выбор службы (Service Discovery and Selection; SD&S): Наименование механизма обнаружения и выбора DVB базовых аудио/видео служб при использовании двунаправленных сетей IP.

3.1.31    обратный вызов (callback): Принцип регистрации вызова класса-обработчика события (слушателя) в среде класса-источника при выполнении приложения DVB-J. Обратный вызов позволяет функции обратного вызова исполнять код, который задается в аргументах при ее вызове.

3.1.32    объект (entity): Функциональный модуль в составе подсистемы (например, в состав подсистемы клиента входят объекты пользователь-сеть (П-С) и пользователь-пользователь (П-П)).

3.1.33    оконечное устройство домашней сети (Home Network End Device; HNED): Устройство, которое соединено с домашней сетью и которым начинается и завершается IP информационный поток [является отправителем потока или приемником потока].

3.1.34    ответвление (tap): Прикладной объект, связанный с более низким уровнем взаимодействия.

3.1.35    пакетированный элементарный поток; ПЭП (Packetized Elementary Stream; PES): Пакетированный элементарный поток, в котором данные разбиты на пакеты и снабжены заголовками.

3.1.36    персистентность (Persistence): Сохраняемость, живучесть.

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

3.1.38    постоянный виртуальный канал (Permanent Virtual Circuit; PVC): Логическое соединение, устанавливаемое на сетевом уровне на определенный период времени.

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

3.1.40    приложение (application): 1 Программное обеспечение, предоставляющее клиенту возможность решения определенной задачи и реализуемое в среде клиента. 2 Функциональная реализация программного обеспечения, обслуживающего один или несколько взаимодействующих аппаратных объектов.

3.1.41    приложение DVB-HTML (DVB-HTML application): Совокупность документов, выбранных из семейства DVB-HTML элементов и форматов контента, определенных в спецификации. Границы множества документов определяются границами приложения.

3.1.42    примитив (primitive): Программный модуль, выполняющий одну элементарную операцию, или блоки данных, передаваемые между разными уровнями системы для вызова каких-либо процедур.

3.1.43    программный интерфейс приложения (Application Programming Interface; API): Набор определенных интерфейсов, посредством которых приложение общается с операционной системой (ОС) или с другими программами.

3.1.44    программный поток данных (Program Stream; PS): Поток данных, образованный путем мультиплексирования элементарных потоков видеоданных и звукоданных цифрового вещательного телевидения, имеющих одну общую тактовую частоту, и сформированный из программных пакетов вещательного телевидения переменной длины.

3.1.45    протокол управления группами (пользователей) в сети Интернет (Internet Group Management Protocol; IGMP): Протокол многоадресной рассылки, управляет передачей пакетов между пользователями и поддерживается протоколами IP в соответствии со стандартом IETF [2].

3.1.46    профиль (profile): Описание группы минимальных конфигураций, определяющих часть спецификации, обеспечивающей возможности домашней мультимедийной платформы (Multimedia Home Platform) или HNED и отображающей функции, которые характеризуют контекст опций службы.

3.1.47    ресурс (resource): Способность или качество системного объекта, которая может использоваться для создания вклада в реализацию службы (например, декодер стандарта MPEG, графическая система).

3.1.48    сеанс (session): Последовательность операций, при которой между пользователями сети устанавливается соединение, проводится обмен данными и завершается соединение.

3

3.1.49    сегмент домашней сети (Home Network Segment; HNS): Обеспечивает обмен данными на уровне канала между домашними оконечными сетевыми устройствами и / или присоединяющимися компонентами.

3.1.50    секция (section): Синтаксическая структура, используемая для отображения всей сервисной информации в пакетах транспортного потока.

3.1.51    семантика (semantics): Система правил, предназначенная для определения смысловых значений отдельных конструкций алгоритмического языка.

3.1.52    сервер (server): Программный объект, экспортирующий ресурс имеющихся данных и устанавливаемый на физическое устройство, подключенное к сети, и предоставляющее услуги другим устройствам, работающим в этой сети.

3.1.53    сервис [служба, услуга] (service): 1 Последовательность программ, которая под управлением вещателя может быть в режиме вещания передана как часть расписания. 2 Логический объект в системе предоставляемых функций и интерфейсов, поддерживающий одно или множество приложений, отличие которого от других объектов заключается в доступе конечного пользователя к управлению шлюзом сервисов.

3.1.54    сеть (network): Совокупность элементов, поддерживающих связь, обеспечивающая соединение элементов, управление сеансом связи и/или управление подключением пользователя.

3.1.55    сеть DVB (DVB network): Набор мультиплексов транспортных потоков MPEG-2, переданных по единственной системе доставки (например, все цифровые каналы в конкретной кабельной системе).

3.1.56    синтаксис (syntax): Часть языка программирования, которая описывает структуру программ как наборов символов.

3.1.57    система DSM-CC (DSM-CC system): Вся область действия протокола DSM-CC, включая субсистемы и их интерфейсы.

3.1.58    состояния приложения DVB-HTML (DVB-HTML application states): Логические состояния, в которых может находиться агент DVB-HTML.

3.1.59    ссылка на программные часы (Program Clock Reference; PCR): Тридцати-трехбитовое число, оцениваемое в периодах частоты 90 кГц, вводимое на программном уровне индивидуально для каждой передаваемой телевизионной программы.

3.1.60    стаб (stub): Программный модуль, временно подменяющий реальную процедуру другой версией, предусматривающей возможность передачи параметров вызываемой процедуры через сеть в «прозрачном» режиме.

3.1.61    субсистема (subsystem): Единица логического «оборудования» в пределах DSM-CC системы (например, клиент, сервер или менеджер сеансов и ресурсов).

3.1.62    таблица информации приложений (Application Information Table; AIT): Таблица, обеспечивающая полную информацию о вещании данных и о необходимых операциях для активизации приложений.

3.1.63    таблица описания служб (Service Description Table; SDT): Таблица, описывающая службы, передаваемые в конкретном транспортном потоке.

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

3.1.65    тег объединения (association tag): Признак, идентифицирующий группы ресурсов или разделенные ресурсы, которые вместе составляют соединение пользователь-пользователь (П-П), при подключении к ресурсам являющийся уникальным в пределах сеанса.

3.1.66    транспорт [передача, транспортировка] (transport): Передача информации между различными объектами транспортного уровня, при котором гарантируется заданная степень надежности связи.

3.1.67    транзакция (transaction): Логическая единица работы, состоящая из запроса и получения результатов его обработки (короткое сообщение, передаваемое в диалоговом режиме между равноправными объектами прикладных уровней).

3.1.68    транспортный поток; ТП (transport stream; TS): Набор из нескольких программных потоков данных цифрового вещательного телевидения, сформированный из программных пакетов постоянной длины с коррекцией ошибок и независимым тактированием от своих источников синхронизации.

3.1.69    универсальный набор символов (Universal Character Set; UCS): Универсальный набор символов, который задает однозначное соответствие символов кодам — элементам кодового пространства, представляющим неотрицательные целые числа.

3.1.70    файл заглушки (Stub File): Файл функции заглушки.

3.1.71    хост (host): Узлы отправителя и получателя.

4

ГОСТ P 54994—2012

3.1.72    четность чередующихся битов [четность при чередовании битов] (Bit Interleaved Parity; BIP): Процедура проверки четности в кадрах с чередующимися битами.

3.1.73    шлюз сервиса (службы) (Service Gateway): Интерфейс, предоставляющий клиенту каталог услуг и возможность подключаться к домену сервиса (службы).

3.1.74    Юникод (Unicode): Стандарт кодирования символов, представляющих знаки письменных языков.

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

БНФ (Backus Normal Form, BNF) — нормальная форма Бэкуса—Наура;

МСР (Session and Resource Manager, SRM) — менеджер сеансов и ресурсов;

МСЭ (International Telecommunication Union, ITU) — Международный союз электросвязи;

МЭК (International Electrotechnical Commission / Committee, IEC) — Международная электротехническая комиссия;

ОС (Operating System, OS) — операционная система;

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

ПЭП (Packetized Elementary Stream, PES) — пакетированный элементарный поток;

ТП (transport stream, TS) — транспортный поток (цифрового вещательного телевидения);

«ТП полная SI» — «транспортный поток, полная SI»;

«ТП дополнительная SI» — «транспортный поток, дополнительная SI»;

ЭВМ — электронно-вычислительная машина;

ФАПЧ (Phased Locked Loop, PLL) — фазовая автоподстройка частоты;

AIT (Application Information Table) — таблица информации приложений;

AL (Application Layer) — уровень приложений;

API (Application Programming Interface) — программный интерфейс приложения;

ARP (Address Resolution Protocol) — протокол преобразования [разрешения] адресов;

АЛ/ (AudioA/ideo) — аудио/видео;

ВАТ (Bouquet Association Table) — таблица объединения букета программ;

BCG (Broadband Content Guide) — путеводитель по контенту вещания;

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

BIP (Bit Interleaved Parity) — четность чередующихся битов [код битового чередуемого паритета, четность чередующихся битов, чередующаяся четность битов];

BNF (Backus Normal Form) — нормальная форма Бэкуса—Наура; БНФ;

BYE — указатель завершения соединения;

СА (Conditional Access) — условный доступ;

СС (CSRC Count) — количество идентификаторов CSRC;

CDP (Content Delivery Protocols) — протоколы доставки контента;

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

CelllD (Cell identifier) — идентификатор ячейки (соты);

CMD (Carousel Multicast Download) — загрузка в режиме многоадресной карусели;

CNAME (canonical name) — каноническое имя;

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

СРСМ (Content Protection and Copy Management) — защита контента и управление копированием; CRID (Content Reference Identifier) — идентификатор ссылок контента;

CSP (Content Service Provider) — провайдер службы контента;

CSRC (Contributing Source) — объединяемые потоки (информации); объединяемые источники (информации);

DHCP (Dynamic Host Configuration Protocol) — протокол динамической конфигурации хоста (узла); DNG (Delivery Network Gateway) — шлюз сети доставки;

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

DNS (Domain Name Server) — сервер доменных имен;

DSCP (Differentiated Services CodePoint) — кодовые точки дифференцированных (различных) служб; DSM (Digital Storage Media) — цифровая запоминающая среда;

DSM-CC (Digital Storage Media — Command and Control) — система команд и управления для средств цифровой записи;

DTD (Document Type Declaration)—декларация типа документа;

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

DVB-HTML application — приложение DVB-HTML;

5

DVB-HTML document — документ DVB-HTML;

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

DVB-IPTV — цифровое телевизионное вещание по каналам с IP протоколами;

DVB-J — платформа Java, являющаяся частью спецификации МНР;

DVB network — сеть DVB;

DVBSTP (DVB SD&S Transport Protocol) — транспортный протокол обнаружения и выбора службы

DVB;

EIT (Event Information Table) — таблица информации о событиях;

FB (Feed Back) — обратная передача;

FEC (Forward Error Correction) — прямое исправление ошибок;

FF (Feed Forward) — прямая передача;

FLUTE (File Delivery over Unidirectional Transport)—доставка файла при однонаправленной передаче; EPG (Electronic Program Guide) — электронный путеводитель (гид) по программам;

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

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

GSM (Global System for Mobile communications) — глобальная система подвижной связи;

HNED (Home Network End Device) — оконечное устройство домашней сети;

HNN (Home Network Node) — узел домашней сети;

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

HTML (Hyper Text Mark-up Language) — язык разметки гипертекста;

HTML-3.2 — номер версии языка HTML;

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

HTTPS (Hyper Text Transfer Protocol Secure) — протокол передачи гипертекстовых файлов с защитой; IANA (Internet Assigned Numbers Authority) — Администрация адресного пространства Интернет (Совет по регистрации доменов Интернет);

ID (IDentifier) — идентификатор;

IEC (International Electrotechnical Commission / Committee) — Международная электротехническая комиссия; МЭК;

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

IETF (Internet Engineering Task Force) — техническая комиссия Интернет, разрабатывающая документы RFC;

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

INT (IP/MAC Notification Table) — таблица нотификации [извещений] IP протокола;

IP (Internet Protocol) — Интернет протокол;

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

IP протокол (Internet protocol) — семейство протоколов, входящих в стек протоколов TCP/IP;

IPCP (Internet Protocol Control Protocol) — протокол управления Интернет протоколом;

IPDC (Internet Protocol DataCasting) — Интернет протокол широковещательной рассылки данных;

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

ISBN (International Standard Book Number) — Международный стандартный номер книги;

ISN (Initial Sequence Number) — начальный номер последовательности;

ISO (International Standards Organizations) — Международная организация по стандартизации;

ISP (Internet Service Providers) — провайдер служб сети Интернет (Интернет-провайдеры);

ITU (International Telecommunications Union) — Международный союз электросвязи; МСЭ;

ITU-T (International Telecommunications Union — Telecommunication Standardization Sector) — Сектор стандартизации электросвязи МСЭ;

JFIF (JPEG File Interchange Format) — формат обмена файлами JPEG;

JPEG (Joint Picture Expert Group) — группа экспертов по кодированию фотографических изображений (стандарт сжатия фотографических (неподвижных) изображений);

LAN (Local-area Network)—локальная сеть;

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

LMDS (Local Multi-point Distribution Systems) — система местного многоточечного распределения; MAC (Media Access Control) — управление доступом к среде;

6

ГОСТ P 54994—2012

MBwTM (Media Broadcast with Trick Modes) — вещание медиа с модой Trick;

МС (Multicast [Multicast, multicast]) — многоадресная (например, передача);

МНР (Multimedia Home Platform) — аппаратно-программный комплекс—домашняя мультимедийная платформа;

middleware — промежуточное программное обеспечение;

MIME (Multipurpose Internet Mail Extensions) — многоцелевые расширения почты Интернет;

MPEG (Motion Pictures Expert Group) — группа экспертов по движущимся изображениям [группа стандартов сжатия аудио- и видеоинформации];

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

MTS (MPEG-2 Transport Stream) — транспортный поток MPEG-2;

MTU (Maximum Transmission Unit) — максимальный модуль передачи;

NACK (negative acknowledgment) — отсутствие подтверждения приема (отрицательная квитанция); NetBIOS (Network Basic Input/Output System) — протокол для работы в локальных сетях на персональных ЭВМ;

NetBIOS/WINS (NetBIOS/Windows Internet Naming Service) — служба сопоставления NetBIOS-имен компьютеров с IP-адресами узлов;

NTP (NetworkTime Protocol) — сетевой протокол времени;

ОС (Object Carousel) — Карусель Объектов;

OS (Operating System) — операционная система; ОС;

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

PCR (Program Clock Reference) — ссылка на программные часы;

PES (Packetized Elementary Stream) — пакетированный элементарный поток; ПЭП;

PID (Packet Identifier) — идентификатор типа пакета;

PLL (Phased Locked Loop) — фазовая автоподстройка частоты; ФАПЧ;

РМТ (Program Map Table) — таблица состава программы;

PS (Program Stream) — программный поток данных;

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

РТ (Payload Туре) — тип полезной нагрузки;

PVR (Digital Video Recorder) — цифровой видеорекордер;

QoS (Quality of Service) — качество службы;

QRC (Query-Response Channel) — канал ответа на запрос;

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

RFC (Request for Comments) — предложения для обсуждения, серия нормативных документов, стандартизирующих протоколы Интернет;

RMS (Remote Management and Firmware) — служба удаленного управления и встроенных программ; RPC (Remote Procedure Call) — вызов удаленных процедур;

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

RSI (Receiver Summary Information) — сводная информация приемника;

RST (Running Status Table) — таблица состояния событий;

RTCP (Real-time Transport Control Protocol) — протокол контроля транспортировки информации в реальном времени;

RTP (Real-time Transport Protocol) — транспортный протокол реального времени;

RTSP (Real Time Streaming Protocol) — потоковый протокол реального времени;

RTT (round trip time) — время от отправления запроса до получения ответа;

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

SDES (Source DEScription) — описание источника;

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

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

SDT (Service Description Table) — таблица описания служб;

SETUP — подготовка к работе;

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

SMD (Scheduled Multicast Download) — запланированная многоадресная загрузка;

SRM (Session and Resource Manager) — менеджер сеансов и ресурсов; МСР;

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

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

7