ГОСТ Р 57870.4-2017. Национальный стандарт Российской Федерации. Телевидение вещательное цифровое. Вспомогательные дисплеи и потоки. Часть 4. Протоколы. Обнаружение

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

Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 31 октября 2017 г. № 1584-ст

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

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

ВСПОМОГАТЕЛЬНЫЕ ДИСПЛЕИ И ПОТОКИ

ЧАСТЬ 4

ПРОТОКОЛЫ. ОБНАРУЖЕНИЕ

Digital video broadcasting (DVB). Companion screens and streams. Part 4. Protocols. Discovery

(ETSI TS 103 286-2 V1.1.1 (2015-05), NEQ) (ETSI TS 103 286-3 V1.1.1 (2015-05), NEQ)

ГОСТ Р 57870.4-2017

ОКС 33.170

ОКП 657400

Дата введения 1 августа 2018 года

Предисловие

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

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

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

4 Настоящий стандарт разработан с учетом основных нормативных положений разделов 6 — 12 стандартов Европейского института по стандартизации в области телекоммуникаций (ETSI) ЕТСИ ТС 103 286-2 V1.1.1 (2015-05) «Телевидение вещательное цифровое. Вспомогательные дисплеи и потоки. Часть 2. Идентификация контента и синхронизация медиаданных» (ETSI TS 103 286-2 V1.1.1 (2015-05) «Digital Video Broadcasting (DVB) — Companion Screens and Streams — Part 2: Content Identification and Media Synchronization», NEQ) и ЕТСИ ТС 103 286-3 V1.1.1 (2015-05) «Телевидение вещательное цифровое. Вспомогательные дисплеи и потоки. Часть 3. Обнаружение» (ETSI TS 103 286-3 V1.1.1 (2015-05) «Digital Video Broadcasting (DVB) — Companion Screens and Streams — Part 3: Discovery», NEQ)

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

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

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

Настоящий стандарт является четвертой частью в группе стандартов, определяющих правила использования новых дополнительных медийных услуг на вспомогательных дисплеях (смартфоны, планшеты и т.п.), дополняющих основной контент, отображаемый на телевизионном устройстве (ТВ-устройство).

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

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

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

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

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

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

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

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

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

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

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

3.1.2 вспомогательный дисплей, вспомогательное устройство: Устройство с IP-подключением, такое как мобильный телефон, планшет, ноутбук.

3.1.3 контент по расписанию: Аудио-, видео- или любой другой тип потоковых или файловых медиаданных или контент, сгенерированный приложением, презентация которого привязана к временной шкале.

3.1.4 материал: Уникальный фрагмент или сегмент финального редакционного контента. Может включать (но не ограничиваясь ими): разовые ТВ-программы, серии из телесериалов, рекламу, трейлеры и пр.

3.1.5 метка времени: Пара из двух значений, каждое из которых представляет значение времени на временной шкале, при этом оба эти значения соответствуют одному и тому же моменту времени.

3.1.6 переключающее событие: Уведомление о временной точке в трансляции.

3.1.7 приложение вспомогательного дисплея (Companion Screen Application; CSA): Приложение, выполняемое на вспомогательном устройстве и обеспечивающее доступ к услугам, дополняющим основной контент, который пользователь просматривает на ТВ-устройстве.

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

3.1.9 телевизионное устройство (ТВ-устройство): Телевизионное устройство или устройство типа сет-топ-бокс, подключенное к домашней сети, принимающее и воспроизводящее DVB-трансляцию, IP-ТВ услугу или иной контент по расписанию.

3.1.10 тег (tag): Язык разметки или дескриптор.

3.1.11 WebSocket: Протокол дуплексной связи поверх TCP-соединения, обеспечивающий обмен сообщениями между браузером и веб-сервером в режиме реального времени.

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

ТВ — телевидение, телевизионный;

ТВ-устройство — телевизионное устройство;

ASCII — американский стандарт кодировки символов (American standard code for information interchange);

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

BOSH — двунаправленные потоки (данных) через синхронный HTTP (Bidirectional-streams Over Synchronous HTTP);

CORS — совместное использование ресурсов между разными источниками (Cross Origin Resource Sharing);

CII — идентификация контента и иной информации (Content Identification and other Information);

CIS — сервер информации о корреляции (Correlation Information Server);

CSA — приложение вспомогательного дисплея (Companion Screen Application);

CSS — вспомогательные дисплеи и потоки (Companion Screens and Streams);

DA — обнаружение и взаимодействие (Discovery and Association);

DCP — протокол управления устройством (Device Control Protocol);

DDD — документ описания устройства (Device Description Document);

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

ETSI — Европейский институт по стандартизации в области телекоммуникаций (European Telecommunications Standards Institute);

GENA — архитектура уведомлений общих событий (General Event Notification Architecture);

GZIP — утилита сжатия и декомпрессии файлов (GNU Zip);

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

HTTPS — протокол передачи гипертекста с поддержкой шифрования (HyperText Transfer Protocol Secure);

IP — межсетевой протокол (Internet Protocol);

JSON — текстовый формат обмена данными, основанный на языке JavaScript (JavaScript Object Notation);

LP — прокси-соединение (Link Proxy);

MI — информация о материале (Material Information);

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

MPEG — экспертная группа по движущемуся изображению; стандарт сжатия видео- и аудиоданных (Moving Picture Experts Group);

MRS — услуга [служба] разрешения материала (Material Resolution Service);

MSAS — сервер приложения синхронизации медиаданных (Media Synchronization Application Server);

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

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

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

PTS — временная отметка предоставления пакета (Presentation Time Stamp);

REST — передача состояния представления (REpresentational State Transfer);

SC — клиент синхронизации (Synchronization Client);

SCP — протокол управления сеансом (Session Control Protocol);

SCPD — описание протокола управления услугой (Service Control Protocol Description);

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

STB — сет-топ-бокс (Set Top Box);

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

TE — переключающее событие (Trigger Event);

TEMI — внешняя медиа-информация с привязкой ко времени (Timed External Media Information);

TLS — синхронизация временной шкалы (TimeLine Synchronization)

TS — транспортный поток (Transport Stream);

TSAP — данные частного характера в поле адаптации транспортного потока (TS Adaptation Private (data));

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

UPnPTM — набор сетевых протоколов, публикуемых форумом UPnP (Universal Plug and Play);

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

URL — универсальный указатель ресурса (Universal Resource Locator);

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

XMPP — расширяемый протокол обмена сообщениями и информацией о присутствии (eXtensible Messaging and Presence Protocol);

WC — системные часы (Wall Clock).

4 Идентификация контента и иной информации

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

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

4.2 Протокол

ТВ-устройство должно обеспечить подключение к оконечному узлу службы CII нескольким CSA одновременно.

Когда CSA пытается подключиться к оконечному узлу службы CII, ТВ-устройство может отклонить запрос, если обслуживание оконечных узлов в настоящее время не доступно или превышено число одновременных подключений, которое ТВ-устройство способно поддерживать в данное время.

Когда CSA успешно подключается к оконечному узлу службы CII, ТВ-устройство должно направить сообщение идентификации контента и иной информации (CII).

Когда ТВ-устройство обнаруживает изменение одного или нескольких свойств, включенных в сообщение идентификации контента и иной информации, ТВ-устройство должно направить всем подключенным CSA сообщение, содержащее обновленную идентификацию контента и иной информации. Это сообщение должно включать свойства, которые изменились. Свойства, которые не изменились, могут быть опущены.

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

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

4.3 Транспорт протокола

ТВ-устройство должно реализовать оконечный узел службы CSS-CII, которая реализует серверную часть протокола WebSocket версии 13. Оконечные узлы службы, предоставляемые ТВ-устройством, в сообщении CII являются WebSocket URL сервера WebSocket. WebSocket URL определяет хост, порт, безопасность и имя ресурса оконечного узла службы.

Все сообщения, отправленные CSA и ТВ-устройством, должны быть в формате кадра данных WebSocket с полезной нагрузкой в текстовом формате.

Если оконечный узел службы CII в данный момент не доступен, ТВ-устройство должно отклонить запрос на соединение ответом с кодом ответа HTTP 403 «Запрещено».

Если ТВ-устройство достигло предела числа одновременных подключений к оконечному узлу службы CII, которое оно может обработать, то ТВ-устройство должно отклонить запрос на соединение, возвращая код ответа HTTP 503 «Сервис не доступен».

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

ТВ-устройство может проверить заголовок «Origin», если он присутствует в заголовке HTTP запроса от CSA по протоколу WebSocket для установления соединения. На основе значения заголовка «Origin» ТВ-устройство может решить отказать в установлении соединения и ответить с кодом ответа 403 «Forbidden».

ТВ-устройство может возвращать HTTP коды ответа 400 и 500 (включая код 403 «Forbidden» и 503 «Service Unavailable») и по другим причинам, которые не рассматриваются в настоящем стандарте.

CSA должно отключаться при закрытии соединения в соответствии с процедурой протокола WebSocket.

Если ТВ-устройство разрывает соединение, то оно должно делать это в соответствии с процедурой протокола WebSocket. При этом ТВ-устройство должно сообщить соответствующий код состояния в кадре закрытия, чтобы указать причину закрытия соединения.

ТВ-устройство и CSA должны корректно обрабатывать неожиданное закрытие соединения в случае, если WebSocket кадра закрытия не отправлен, или не принят, или если базовое соединение с TCP соединителем разорвано, например из-за тайм-аута.

5 Служба разрешения материала

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

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

5.2 Протокол разрешения материала

Для взаимодействия с MRS должен использоваться протокол REST API через HTTP 1.1 или HTTPS (в частности, HTTP 1.1 через TLS).

URL MRS должен указывать, какой протокол следует использовать.

В нормальном режиме кодом ответа HTTP должен быть код состояния «200 OK». Другие коды состояния также могут быть возвращены, и они должны быть обработаны соответствующим образом. Следует отметить, что успешные коды (2xx), коды перенаправления (3xx) и коды не-модификации (304) могут быть возвращены и должны поддерживаться.

Могут быть возвращены коды ошибок клиента (4xx) и коды ошибок сервера (5xx). Поведение сервера в этих случаях не определено, но рекомендуется, чтобы оно было таким же, как если бы идентификатор контента не был получен от ТВ-устройства.

5.3 Запрос протокола разрешения материала

5.3.1 Общие требования протокола разрешения материала

CSA должно выдавать запросы GET к URL MRS_REST_API согласно 5.2.

CSA должно включать поле «Accept: application/json» в заголовок запроса.

CSA должно поддерживать GZIP и IDENTITY (для не упакованных в архив GZIP в формате JSON) кодирования ответов и включать поле «Accept-Encoding» в заголовок запроса, а также параметры GZIP и IDENTITY.

CSA должно поддерживать метки объекта ETags для запроса.

CSA должно включать заголовок «Referer» в запрос, который должен быть установлен для идентификации CSA.

CSA должно включать в запрос заголовок «Origin».

5.3.2 URL протокола разрешения материала

URL, формирующий запрос MRS HTTP REST, должен быть построен путем конкатенации трех частей в следующем порядке:

• mrsUrl, возвращаемый ТВ-устройством;
• фиксированная строка «/v1.1/MRS»;
• один параметр протокола разрешения материала согласно 5.3.3.

Формат запроса MRS HTTP REST приведен в таблице 1.

Таблица 1

Формат запроса MRS HTTP REST

5.3.3 Параметр протокола разрешения материала

Параметром name для идентификатора контента должна быть строка «ContentID», а параметром value должен быть идентификатор контента.

Параметр value должен быть представлен в виде строки ASCII-символов. Значение параметра должно соответствовать кодировке URI. В частности, если какие-либо символы параметра value попадают в зарезервированный набор символов (независимо от контекста), они должны быть закодированы с помощью символа «%» и двух последующих шестнадцатеричных цифр в верхнем регистре. Символы, попадающие в незарезервированный набор символов, не должны быть закодированы.

5.3.4 Ответ протокола разрешения материала

HTTP-заголовки ответа MRS должны включать в себя заголовок «Expires».

HTTP-заголовки ответа MRS должны также включать в себя заголовки CORS, как определено в таблице 2.

Таблица 2

Заголовки CORS

Тело ответа MRS представляет собой JSON-документ, состоящий из объекта ответа MRS, описываемого корневым объектом схемы JSON. Пример шаблона для объекта JSON:

5.4 Протоколы обновления сервера разрешения материала

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

Информация материала (MI) или ее части, возвращаемые MRS, могут измениться во время просмотра контента и поэтому могут потребовать обновления.

Если массив updateMaterial присутствует и заполнен, то это означает, что обновления могут происходить, но не обязательно для материалов, определенных в свойствах материалов. Если массив updateTimelineSync присутствует и заполнен, это означает, что обновления могут происходить, но не обязательно для информации временной шкалы синхронизации, определенной в свойстве syncTimelineInformation.

Свойства updateMaterial и updatedTimelineSync являются массивами размещений, из которых могут быть получены или извлечены обновления. Размещение кодируется как URL и частично идентифицирует используемый протокол обновления. Для каждого размещения также передается MIME-тип, который завершает идентификацию протокола обновления. Данные массивы могут также содержать размещение MIME-типов для других механизмов, которые не определены в настоящем стандарте.

CSA осуществляет механизм длительного опроса, определенный в 5.4.4. CSA должно реализовывать механизм веб-сокета, определенный в 5.4.5, и механизм событий передачи сервера, определенный в 5.4.6. CSA может реализовать механизм BOSH/XMPP, определенный в 5.4.7.

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

Порядок элементов в массиве указывает на порядок размещений, где самый высокий индекс указывает на наиболее предпочтительный вариант. CSA должно использовать элементы массива в порядке убывания, начиная с самого старшего элемента. CSA может игнорировать любой элемент массива, чей URL и mimeTYPE оно не распознает или не поддерживает. Если CSA не удается установить соединение, используя данный элемент массива, то CSA должно продолжать попытки, используя остальные элементы в порядке убывания. После того как CSA устанавливает успешное соединение, оно должно продолжать его использовать для обновления, за исключением случаев:

• возникновения состояния ошибки;
• если получен новый массив обновления, не содержащий используемое в настоящее время размещение обновления.

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

5.4.2 Синтаксис JSON для обновления элемента массива

Объекты, входящие в состав массива updateMaterial и массива updateTimelineSync, должны соответствовать следующему шаблону:

5.4.3 JSON ответ с обновлением

Объект JSON, возвращаемый протоколами обновления, передает изменения в материал или в информацию временной шкалы синхронизации. Объект JSON должен соответствовать 5.3.4, но все его свойства, кроме свойства «type», являются опциональными. Он должен иметь дополнительные свойства, которые определены в настоящем пункте. Свойство «type» должно иметь значение «update».

Объект JSON должен иметь дополнительные свойства в соответствии со следующим шаблоном:

5.4.4 Длительный опрос

Длительный опрос является обычным запросом, посылаемым на определенный URL, когда ответ соответствует 5.3.4, а объект JSON в ответе соответствует семантике, определенной в 5.4.3, в зависимости от обстоятельств.

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

Когда соединение закрывается неожиданно или в результате завершения получения обновления, новый запрос выдается не ранее, чем указано в наименьшем из значений в свойстве repollInterval объекта JSON в ответах, или в обновлениях (считая с начала последнего запроса), или в заголовке «Expires» последнего успешного HTTP ответа.

Объект mimeTYPE должен иметь формат application/json для массива updateMaterial или формат application/json-patch для массива updateTimelineSync. Компонент протокола URL должен быть «http» или «https».

5.4.5 Протокол WebSocket

Объект mimeTYPE должен иметь формат application/json для массива updateTimelineSync. Компонент протокола URL должен быть «ws» или «wss». Данный URL должен ссылаться на серверную часть протокола WebSocket версии 13.

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

CSA не должно направлять никаких данных на сервер через WebSocket.

Сервер может посылать ответы с обновлениями в соответствии с 5.4.3.

5.4.6 Протокол событий передачи сервера

Объект mimeTYPE должен иметь формат «ext/event-stream». Компонент протокола URL должен быть «http» или «https».

Тип события, которое фиксируется строкой «event:» потока событий, должен быть установлен в «MIupdate» (т.е. строка «event: MIupdate» должна предшествовать данным события) для обновлений материала или в «TSupdate» (т.е. строка «event:TSupdate» должна предшествовать данным события) для обновления синхронизации временной шкалы.

Данные должны быть посланы как поле данных с именем (т.е. строка «data:» должна предшествовать данным события).

Данные события должны быть объектом JSON для событий «MIupdate» и объектом JSON Patch для событий «TSupdate». Для того чтобы обеспечить правильную передачу, кодировка объекта JSON не должна включать в себя символы конца строки.

5.4.7 BOSH/XMPP протокол

Объект mimeTYPE должен иметь формат «ext/event-stream». Компонент протокола URL явно не определен, но обычно должен быть «http» или «https».

Свойство protocolSpecificData должно присутствовать и содержать XML-строфу в формате base64, которая должна быть отправлена от клиента к серверу, чтобы подписаться на обновления.

Возвращенный элемент тела сообщения должен содержать объект JSON для обновления информации материала или объект JSON для обновления syncTimelineInformation.

Представление JSON в теле элемента должно быть закодировано в формате base64, чтобы избежать риска повреждения XML-документа.

6 Системные часы

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

Для компенсации задержек в сети связи между ТВ-устройством и CSA в процедуре синхронизации временной шкалы с привязкой к системным часам производится обмен временными метками, обеспечивая тем самым синхронизацию ТВ-устройства и CSA. Синхронизация системных часов обеспечивает соответствие показаний системных часов ТВ-устройства и CSA.

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

Элементарная функция ТВ-устройства WC сервера должна реализовывать системные часы и поддерживать службу синхронизации системных часов.

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

6.2 Обзор протокола

6.2.1 Введение в протокол

Протокол должен передавать следующую информацию:

• значение времени, используемое для оценки смещения между системными часами WC сервера и системными часами WC клиента;
• точность измерения, представляющую максимальную величину точности, обеспечиваемую в процессе считывания WC сервером значения из системных часов;
• максимальную погрешность частоты, представляющую максимальную величину, на которую частота системных часов WC сервера может отклоняться от номинального значения с течением времени.

6.2.2 Значения времени и оценка смещения системных часов

WC клиент записывает значение времени T1 в момент, когда сообщение с запросом подготовлено и направлено на WC сервер, и значение времени T4 в момент, когда принимает сообщение с ответом. Аналогично WC сервер должен записывать значения T2 и T3 своих собственных системных часов в момент, когда ответное сообщение подготовлено и отправлено. Процесс синхронизации системных часов показан на рисунке 1.

T1 — исходное значение времени; T2 — значение времени приема; T3 — значение времени передачи; T4 — значение времени ответа

Рисунок 1 — Процесс синхронизации системных часов

Если предположить, что сообщение с запросом и ответное сообщение занимают равное количество времени для передачи между WC клиентом и WC сервера, для WC клиента возможно оценить смещение offset (\theta) между часами WC клиента и часами WC сервера:

\theta = ((T3 + T2) - (T4 + T1))2 . (1)

Также для WC клиента возможно оценить общее время, потраченное на сообщения запроса и ответа, известное как время запроса туда-обратно round_trip_time (\delta) :

\delta = (T4 - T1) - (T3 - T2) . (2)

Границы неопределенности оценки смещения (известные как дисперсии) больше или равны плюс или минус половине времени запроса туда-обратно.

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

6.2.3 Точность измерения

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

Если принять наименьшее регулярное приращение системных часов за № тактов при номинальной скорости M тактов в секунду, то показания системных часов в любой момент времени ограничены точностью в пределах N/M секунд.

Если процесс снятия показаний занимает p секунд, то точность измерения measurement precision (mp) рассчитывается по формуле

mp = p + N/M. (3)

6.2.4 Максимальная ошибка частоты

По ряду причин WC могут изменять частоту с течением времени (отклонение от номинальной частоты).

Ошибка частоты измеряется в миллионных частях (ppm). Ошибка частоты № ppm означает, что период времени T секунд может быть неточным на +/- T·N/1 000 000 секунд.

Опорный генератор устройства характеризуется максимальной ожидаемой погрешностью частоты F ppm для установленных условий эксплуатации устройства.

Система, где используется процесс управления синхронизацией (например, клиент NTP), может намеренно смещать тактовую частоту. Максимальное смещение частоты, которое может быть достигнуто с помощью такого процесса, равно +/- L ppm и также должно учитываться при определении максимальной погрешности частоты.

Если процесс управления синхронизацией (например, в клиенте NTP) предназначен для компенсации частотной погрешности опорного генератора, то можно предположить, что эффект смещения частоты благодаря процессу управления синхронизацией позволит снизить ошибку частоты. Тогда максимальная ошибка частоты (ppm) будет определена по формуле

ppm = max(F, L). (4)

6.3 Синтаксис сообщений синхронизации системных часов

Синтаксис сообщений синхронизации системных часов приведен в таблице 2.

Таблица 2

Синтаксис сообщений синхронизации системных часов

Поле message_type определяет тип сообщения и принимает одно из значений, указанных в таблице 3.

Таблица 3

Значения поля message_type

6.4 Транспорт протокола системных часов

Сообщение синхронизации WC должно быть передано в качестве полезной нагрузки одиночного UDP пакета.

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

Оконечный узел службы синхронизации системных часов должен представляться в виде URL формата «udp://:«, где и  являются IP-адресом и номером порта, на котором WC сервер представляет оконечный узел службы.

7 Синхронизация временной шкалы

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

Синхронизация временной шкалы представляет собой процесс, с помощью которого элементарная функция CSA SC и элементарная функция MSAS ТВ-устройства обмениваются информацией о метках времени через интерфейс TLS для того, чтобы координировать синхронизацию процесса презентации контента по расписанию.

7.2 Протокол

MSAS должен обеспечить нескольким CSA возможность сохранять открытые сеансы с оконечными узлами служб TLS одновременно. MSAS должен обеспечить CSA возможность иметь несколько открытых сеансов с одним оконечным узлом службы TLS.

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

7.3 Транспорт протокола

Элементарная функция MSAS ТВ-устройства должна содержать оконечный узел службы TLS. Данная функция реализуется серверной частью протокола WebSocket версии 13. Оконечным узлом службы, предоставляемым функцией MSAS, в сообщении CII является WebSocket URL сервера WebSocket.

8 Переключающие события

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

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

8.2 Протокол

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

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

8.3 Транспорт протокола

ТВ-устройство, которое предоставляет оконечный узел службы TE, должно реализовывать серверную часть протокола WebSocket версии 13. Оконечным узлом службы TE, предоставляемым ТВ-устройством, является WebSocket URL.

9 Временные шкалы в полях адаптации транспортного потока

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

В данном разделе определены два процесса передачи временной шкалы в заголовке адаптации пакетов транспортного потока:

• процесс, при котором временные шкалы несут байты данных частного характера в полях адаптации транспортного потока (TSAP) (см. 9.2);
• процесс, опубликованный MPEG в апреле 2014 года в качестве информационной технологии (см. 9.3).

9.2 Временная шкала данных частного характера в поле адаптации транспортного потока (TSAP)

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

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

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

9.2.2 Селектор временной шкалы для временной шкалы TSAP

Формат селектора временной шкалы для поля tsap_timeline должен соответствовать следующему шаблону:

tsap-timeline-selector = «urn:dvb:css:timeline:tsap:» component-tag «:» timeline-id

9.2.3 Соотношение с PTS

Информация временной шкалы кодируется с использованием tsap_timeline в соответствии с моментом презентации медиаданных, указанным PTS, расположенной в первом заголовке PES, который начинается в полезной нагрузке, передаваемой в текущем или последующем пакете транспортного потока с таким же PID. В заголовке PES должно содержаться значение PTS.

9.2.4 Синтаксис

Синтаксис поля tsap_timeline должен соответствовать таблице 4.

Таблица 4

Синтаксис поля tsap_timeline

9.2.5 Интерпретация данных временной шкалы

ТВ-устройство должно декодировать данные временной шкалы с timeline_type, равным 1.

Значение такта временной шкалы и скорость тактов должны быть определены из последних полученных данных временной шкалы, согласно которой timeline_id соответствует значению, указанному в timelineSelector, и которая переносится в байтах данных частного характера поля адаптации adaptation_field для пакетов TS, определенных тегом компонент, указанным в timelineSelector.

Поле UnitsPerTick временной шкалы должно быть равно 1, поле unitsPerSecond временной шкалы должно быть равно значению поля tick_rate.

9.3 Внешняя медиа-информация с привязкой ко времени (TEMI)

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

Дескрипторы полей адаптации для синхронизированной внешней медиа-информации (TEMI) определяют процесс для передачи временной шкалы в поле адаптации пакета транспортного потока, который в свою очередь содержит поток PES с PTS, объявленной в заголовке PES. Данный пункт определяет селектор временной шкалы и требования, которым ТВ-устройство должно соответствовать, если оно поддерживает использование временной шкалы TEMI.

9.3.2 Селектор временной шкалы для временной шкалы MPEG TEMI

Формат селектора временной шкалы MPEG TEMI должен соответствовать следующему шаблону:

temi-timeline-selector = «urn:dvb:css:timeline:temi:» component-tag «:» timeline-id

9.3.3 Интерпретация дескриптора temi_timeline_descriptor

Если поле has_timestamp дескриптора temi_timeline_descriptor равно 1 или 2, то величина такта временной шкалы берется из поля media_timestamp, а тактовая скорость определяется из поля timescale.

Поле unitsPerTick временной шкалы должно быть равно 1, поле unitsPerSecond временной шкалы должно быть равно значению поля tick_rate.

Если поле has_timestamp не равно 1 или 2, то тактовая скорость временной шкалы и значение такта не определены.

ТВ-устройство может игнорировать значение полей has_ntp, has_ptp и has_timecode.

Если поле paused равно 1, то тактовая скорость не изменяется, но ТВ-устройство должно рассчитывать метки времени, как будто презентация приостановлена.

10 Управление соединением и сеансом воспроизведения

ТВ-устройство и CSA, задействованные в синхронизированном воспроизведении, обычно используют интерфейс WC совместно с интерфейсами CII, TLS или TE. При определенных обстоятельствах они могут также использовать все четыре интерфейса параллельно. В таблице 5 приведена комбинация активных состояний соединений сети CSS.

Таблица 5

Комбинации активных состояний соединений сети CSS

11 Обнаружение

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

11.1.1 Введение

Протокол Universal Plug and Play (UPnPTM) является принятым протоколом для поиска и идентификации UPnPTM устройств в сети. UPnPTM используется для передачи информации, чтобы позволить CSA обнаружить и ассоциироваться с ТВ-устройством, как показано на рисунке 2, и таким образом установить связь.

Рисунок 2 — Соединение CSA и ТВ-устройства в домашней сети

11.1.2 Архитектура UPnPTM устройства

UPnPTM реализует модель клиент — сервер. В терминологии UPnPTM клиенты называются контрольными точками, а серверы — UPnPTM устройствами. Функциональность UPnPTM устройств и контрольных точек абстрагируется от транспортного механизма. Функциональность приводится в протоколах управления устройствами (DCP), которые определяют набор действий (RPC методы) и событий. Транспортный механизм описан в архитектуре UPnPTM устройства (UDA). Компоненты, которые составляют UDA, показаны на рисунке 3. UDA описывает:

• как контрольные точки могут обнаружить UPnPTM устройства в сети без предварительного знания IP-адреса устройства с помощью простого протокола обнаружения устройства (SSDP), который реализуется через UDP;
• какие возможности обнаруженных UPnPTM устройств реализованы посредством загрузки документа описания XML-устройства и документа описания XML-протокола управления службами с помощью HTTP;
• как контрольные точки взаимодействуют с открытой функциональностью, вызывая действия с использованием запросов SOAP через HTTP;
• как контрольные точки получают события, используя GENA через TCP.

Рисунок 3 — Схема стека UPnPTM

В DCP описаны специфические функции каждого домена. DCP определяются как службы UPnPTM в UPnPTM устройстве.

11.1.3 Управление приложением UPnPTM

Служба DCP управления приложением UPnPTM используется для установления связи между CSA и ТВ-устройством. ТВ-устройство включает UPnPTM устройство, которое в свою очередь включает службу управления приложением, CSA реализует контрольную точку управления приложением. Этот процесс показан на рисунке 4.

Рисунок 4 — Типовая реализация контрольных точек управления приложением во вспомогательном устройстве и службы управления приложением UPnPTM в ТВ-устройстве

11.1.4 Отображение интерфейса CSS-CII при управлении приложением

CSA действует как контрольная точка управления приложением. Это позволяет CSA обнаружить ТВ-устройство, которое включает UPnPTM устройство, реализующее службу управления приложением DCP. Этот процесс показан на рисунке 5.

Рисунок 5 — CSA и ТВ-устройство, реализующее управление приложением UPnPTM и связи приложения CII

11.1.5 Поведение CSA

Определение WebSocket адреса CII от CSA к ТВ-устройству достигается за счет последовательности команд, приведенных на рисунке 6:

1. обнаружение ТВ-устройства в домашней сети путем выдачи M-Search;

2. выбор ТВ-устройства с помощью фильтрации ответов M-Search;

3. загрузка DDD выбранного ТВ-устройства;

4. выполнение действий для:

а) определения существования или отсутствия приложения с matchingProtocolName путем вызова действия GetAppIDList ();

б) получения информации о приложении, которое содержит адрес WebSocket и runningState, путем вызова действия GetAppInfoByIDs();

5. установление WebSocket соединения CSS-CII.

Рисунок 6 — Последовательность команд между CSA и ТВ-устройством для установления WebSocket соединения CII

11.2 Требования к UPnPTM устройству для ТВ-устройства

ТВ-устройство должно реализовать UPnPTM устройство, которое в свою очередь реализует службу управления приложениями DCP.

Реализованное UPnPTM устройство должно соответствовать архитектуре UPnPTM устройств или последней версии UDA.

Интерфейс CII должен быть представлен в качестве приложения в службе управления приложением.

Приложение должно предоставлять элемент в XML-документе описания приложения, где:

• matchingProtocolName должен быть определен как «CSS-CII.TVDevice.CSS.DVB.org_v1»;
• протокол должен быть определен как «WebSocket»;
• значение атрибута требования протокола должно быть определено как «1»;
• connectionAddress должен быть действительным адресом WebSocket;
• connectionAddress должен указывать на оконечный узел WebSocket и должен передавать протокол CII.

Приложение всегда должно иметь значение runningState, равное «Running».

Приложение не должно быть остановлено, когда вызывается действие StopApp(). Эта функция должна возвращать код ошибки 710.

XML-документ, описывающий применение в качестве результата вызова действия GetAppInfoByIDs(), должен всегда включать свойства:

• runningStatus;
• apptoAppInfo.