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

ГОСТ Р 53528-2009

Группа Э30

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

Телевидение вещательное цифровое

ТРЕБОВАНИЯ К РЕАЛИЗАЦИИ ПРОТОКОЛА ВЫСОКОСКОРОСТНОЙ ПЕРЕДАЧИ ИНФОРМАЦИИ DSM-CC

Основные параметры

Digital video broadcasting. Requirements for realization of protocol of DSM-CC information high-speed communication. Basic parameters

ОКС 33.170

ОКП 65 7400

Дата введения 2010-12-01

Предисловие

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

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

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

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

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

4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта ИСО/МЭК 13818-6:1998 "Общее кодирование движущихся изображений и связанной с ними аудиоинформации. Часть 6. Расширение для DSM-CC" (ISO/IEC 13818-6:1998 Information technology - Generic coding of moving pictures and associated audio Information - Part 6: Extension for DSM-CC)

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

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

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

Настоящий стандарт распространяется на протокол высокоскоростной передачи информации системы команд и управления для средств цифровой записи в цифровой запоминающей среде (Digital Storage Media - Command and Control) - DSM-CC в цифровом телевизионном вещании.

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

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

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

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

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

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

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

3.1.1 внутриподсистемный интерфейс (intra-subsystem interface): Интерфейс между двумя объектами, находящимися в одной подсистеме.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.15 менеджер сеансов и ресурсов; МСР (Session and Resource Manager; SRM): Субсистема протокола системы команд и управления для средств цифровой записи (Digital Storage Media - Command and Control (DSM-CC), обеспечивающая централизованное управление сеансами DSM-CC и ресурсами одной или более основной технологии сети.

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

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

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

3.1.19 парсинг (parsing): Синтаксический анализ.

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

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

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

3.1.23 приложение (application): Программное обеспечение, предоставляющее Клиенту возможность решения определенной задачи и реализуемое в среде Клиента.

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

3.1.25 профиль (profile): 1 Перечень основных характеристик объекта в табличной или графической форме. 2 Совокупность требований к конкретной системе, основанная на требованиях стандарта, но не повторяющая их, а ссылающаяся на них.

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

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

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

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

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

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

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

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

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

3.1.35 соединение (connection): Связь между двумя или более устройствами, процессами или сетями.

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

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

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

3.1.39 суффикс (suffix): Логический знак (символ, слово), обозначающий конец сообщения.

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

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

3.1.42 тело (body): Набор операторов внутри некоторой структуры, например: тело цикла, тело процедуры.

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

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

3.1.45 форвардинг (forwarding): Продвижение, пересылка (сообщения).

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

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

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

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

П-П (User-to-User, U-U) - Пользователь-Пользователь;

П-С (User-to-Network, U-N) - Пользователь-Сеть;

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

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

AAL (ATM Adaptation Layer) - уровень адаптации ATM;

AFI (Authority and Format identifier) - идентификатор полномочий и формата; поле в структуре формата адресного заголовка NSAP;

API (Application Portability Interface) - прикладной интерфейс, использующий информацию и программное обеспечение в разных сетевых средах;

API (Application Programming Interface) - прикладной программный интерфейс;

ATM (Asynchronous Transfer Mode) - асинхронный режим передачи;

B-channel (Bearer channel) - базовый информационный канал для передачи информации со скоростью 64 кбит/с в системе В-ISDN;

В-ISDN (Broadband ISDN) - широкополосная цифровая сеть с интеграцией услуг;

ВIOР (Broadcast Inter-ORB Protocol) - протокол взаимодействия брокеров (посредников) запросов к объектам вещания;

ССР (Channel Change Protocol) - протокол обмена каналов;

CFS (Continuous Feed Session) - сеанс непрерывной передачи;

CORBA (Common Object Request Broker Architecture) - открытый стандарт для взаимодействия (интероперабельности) приложений;

CRC (Cyclic Redundancy Check/Code) - проверка циклическим избыточным кодом;

DSM (Digital Storage Media) - цифровая запоминающая среда;

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

HFC (Hybrid Fiber Coax) - гибридная волоконно-оптическая коаксиальная система передачи;

IDL (Interface Definition Language) - язык определения интерфейса;

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

IOR (Inter-operable Object Reference) - ссылка на функциональную совместимость объектов;

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

ISDN (Integrated Services Digital Network) - цифровая сеть с интеграцией услуг;

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

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

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

IWU (Inter-Working Unit) - блок взаимодействия;

LLC (Logical Link Control) - управление логическим звеном данных;

MHEG (Multimedia/Hypermedia Experts Group) - группа экспертов по кодированию мультимедиа и гипермедиа;

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

N-ISDN (Narrowband ISDN) - узкополосная цифровая сеть с интеграцией услуг;

NPT (Normal Play Time) - время нормального воспроизведения;

NSAP (Network Service Access Point) - точка доступа сетевого сервиса;

ORB (Object Request Broker) - посредник (брокер) запросов объектов;

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

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

OUI (Organization Unique Identifier) - уникальный идентификатор организации, присваиваемый IEEE;

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

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

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

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

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

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

PSTN (Public Switched Telephone Network) - телефонная сеть общего пользования;

РVC (Permanent Virtual Circuit) - постоянный виртуальный канал;

RPC (Remote Procedure Call) - вызов удаленных процедур;

SDB (Switched Digital Broadcast) - коммутируемое цифровое вещание;

SDL (Specification and Description Language) - язык спецификаций и описаний, использующий графическое исполнение описания поведения системы. Применение SDL определено Рекомендацией ITU-T [1];

SDV (Switched Digital Video) - коммутируемое цифровое видео;

SII (Service Interoperability Interface) - интерфейс интероперабельного сервиса;

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

STC (System Time Clock) - системный таймер;

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

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

ТСР/IP - стек протоколов сетевого и транспортного уровней;

TDMA (Time Division Multiple Access) - многостанционный доступ с временным разделением каналов;

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

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

U-N (User-to-Network) - Пользователь-Сеть; П-С;

U-U (User-to-User) - Пользователь-Пользователь; П-П.

4 Основные параметры протокола высокоскоростной передачи информации DSM-CC

4.1 Определение протокола DSM-CC

4.1.1 Протокол DSM-CC является стеком протоколов. Он обеспечивает конфигурирование Клиента, управление приемом и загрузкой потоков видеоинформации.

Протокол DSM-CC обеспечивает поддержку просмотра, выбора и загрузки передаваемого контента, а также поддержку управления транспортными потоками. Характеристики протокола DSM-CC определены стандартом ISO/IEC [2].

Для получения доступа к услуге (сервису) Клиент устанавливает сеансовое соединение с Сервером, а по получении услуги (сервиса) прекращает его. Все ресурсы, участвующие в сеансе, должны быть помечены специальным сеансовым идентификатором и не могут быть использованы в другом соединении. Особенностью протокола DSM-CC является возможность для Клиента в течение сеанса устанавливать более одного соединения и получать информацию одновременно более чем от одного источника. Протокол позволяет устанавливать многоресурсные соединения, когда информация проходит через одну или несколько концевых точек разных сетей. При установке соединения Клиент конфигурирует себя для Сети путем обмена сообщениями с ней. Затем проводится загрузка информации от Сервера к Клиенту.

4.1.2 Стек протоколов DSM-CC определяет синтаксис и семантику следующего набора протоколов от Пользователя к Пользователю (П-П) и от Пользователя к Сети (П-С):

- Заголовок Сообщения DSM-CC П-С;

- сообщения Конфигурации П-С;

- сообщения Сеанса П-С и управления потоками для Сеансов и Ресурсов;

- сообщения Загрузки П-С;

- Обмен Каналов Коммутируемого Цифрового Вещания П-С;

- Транзитных сообщений П-С;

- передача сообщений П-С с использованием требований ISO/IEC [3];

- передача базовых IP-сообщений с использованием секций DSM-CC согласно ISO/IEC [3] (раздел 9);

- Вызов Удаленной Процедуры П-П;

- интерфейс Сеанса П-П;

- интерфейс Загрузки П-П;

- интерфейс Карусель Объектов П-П;

- интерфейс Локального Объекта П-П;

- Дескрипторы Потока П-П.

Стек протоколов DSM-CC является модульным. Допускается использование модулей стека как индивидуальное, так и совместное при условии предоставления требуемых параметров и функциональных возможностей.

4.1.3 Протоколы DSM-СС классифицированы по следующим функциональным категориям:

- Конфигурация П-С;

- Сообщения Сеанса Базовые П-С;

- Сообщения Сеанса Расширенные П-С;

- Загрузка Управляемым Потоком П-С;

- Загрузка Неуправляемым Потоком П-С;

- Загрузка Карусели Данных П-С;

- Транзитные сообщения П-С;

- Квитанция о приеме Транзитного сообщения П-С;

- Обмен Каналов Коммутируемого Цифрового Вещания П-С;

- Базовые Интерфейсы П-С;

- Расширенные Интерфейсы П-С.

4.1.4 При реализации протоколов DSM-CC П-С должна быть обеспечена поддержка всех групп протоколов, входящих в состав Сообщений Сеансов Базовых.

При реализации протоколов DSM-CC П-С Сообщений Сеансов Расширенных должен поддерживаться полный набор сообщений, входящих в состав Расширенных Сеансов.

4.1.4.1 Группа функциональных Сообщений Сеанса Базового П-С включает в себя совокупности сообщений:

- Настройки Сеанса;

- Разъединения Сеанса;

- Дополнительных Ресурсов;

- Исключенных Ресурсов;

- Установки Непрерывной Подачи Сеанса;

- Запросов Статуса (состояния);

- Повторного Сброса-Установки;

- порядка Выполнения Сеанса;

- Соединения Сеанса.

4.1.4.2 Группа функциональных Сообщений Сеанса Расширенного П-С включает в себя совокупности:

- группу Переноса Сеанса;

- группу Сеанса в Развитии.

4.1.5 Интерфейсы IDL П-П разделены на две категории:

- Интерфейсы Базовые;

- Интерфейсы Расширенные.

Каждая из этих категорий включает в себя интерфейсы Пользователя и Интерфейсы Общие.

Интерфейсы Пользователя предназначены для доставки приложений при передаче данных, прежде всего, от Сервера Клиенту.

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

Интерфейсы Общие расширяют функции интерфейса Пользователя.

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

Каждый интерфейс из категории Расширенного набора интерфейсов может быть реализован или как полный Расширенный Интерфейс Потребителя или как полный Расширенный Общий Интерфейс.

4.2 Основная функциональная модель протокола DSM-CC

Основная модель Сервер-Сеть-Клиент протокола DSM-CC показана на рисунке 1.

Рисунок 1 - Основная модель Сервер-Сеть-Клиент протокола DSM-CC

Основная модель Сервер-Сеть-Клиент протокола DSM-CC содержит подсистемы:

- Клиент;

- Менеджер сеансов и ресурса (МСР);

- Сервер.

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

Подсистема МСР обеспечивает функционирование протокола DSM-CC в пределах сети.

Стек протоколов DSM-CC состоит из наборов протоколов П-С и П-П (см. 4.1.2).

Стек протоколов DSM-CC не предъявляет требований к физическим параметрам каналов передачи данных или уровню вызова удаленных процедур (RPC). Требования стека протоколов DSM-CC к транспортному потоку MPEG-2 приведены в приложении А. Требования стека протоколов DSM-CC к транспортному уровню - в соответствии с приложением Б.

Стек протоколов DSM-CC поддерживает типы соединений:

- "точка - точка";

- "точка - много точек" (вещание).

Соединения типа "точка-точка" используются для передачи приложений П-П и для обмена сервисами.

Соединения типа "точка - много точек" используются для передачи одного потока множеству Клиентов.

4.3 Эталонная модель протокола DSM-CC

4.3.1 На эталонной модели протокола DSM-CC, представленной на рисунке 2, показаны уровни системы, объекты и субобъекты, входящие в систему, а также интерфейсы между ними.

Рисунок 2 - Эталонная модель протокола DSM-CC

На рисунке 2 пунктирные линии разделяют эталонную модель на четыре уровня:

- уровень приложений;

- уровень Пользователь-Пользователь (П-П);

- уровень Пользователь-Сеть (П-С);

- уровень менеджеров соединений (транспортный уровень).

Требования к уровню приложений и к уровню менеджеров соединений (транспортному уровню) настоящий стандарт не предъявляет.

4.3.2 В системе DSM-CC предусмотрены следующие типы объектов:

- объект Клиент Пользователь-Пользователь (П-П);

- объект Клиент Сеть-Пользователь (С-П);

- объект Сервер Пользователь-Пользователь (П-П);

- объект Сервер Пользователь-Сеть (П-С);

- объект МСР Пользователь-Сеть (П-С).

Подсистема в протоколе DSM-CC содержит в своем составе один или более объект.

4.3.3 В соответствии с эталонной моделью системы DSM-CC должны обеспечиваться три типа соединения, через которые в системе DSM-CC выполняется обмен сообщениями между объектами:

- от объекта Клиент П-П к объекту Сервер П-П;

- от объекта Клиент П-С к объекту МСР П-С;

- от объекта Сервер П-С к объекту МСР П-С.

При соединении обмен между объектами П-П должен быть выполнен в соответствии с протоколом DSM-CC П-П, а обмен между объектами П-С - в соответствии с протоколом DSM-CC П-С.

4.3.4 В системе DSM-CC используются логические интерфейсы (обозначены на рисунке 2 линиями со стрелками):

- междуобъектный: между равноправными по положению объектами в различных подсистемах;

- внутриобъектный: между субобъектами в пределах общего объекта;

- внутриподсистемный: между объектами в пределах общей подсистемы.

Междуобъектные и внутриподсистемные логические интерфейсы показаны в таблице 1.

Таблица 1 - Междуобъектные и внутриподсистемные логические интерфейсы

4.3.5 На рисунке 3 в общем виде показана взаимосвязь протоколов, использующих интерфейсы DSM-CC.

Рисунок 3 - Взаимосвязь протоколов, использующих интерфейсы DSM-CC

Верхняя часть рисунка 3 (Прикладной уровень) содержит приложения (например, приложения MHEG и приложения языка сценария), использование которых допускается протоколами DSM-CC.

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

Интерфейсом приложений является библиотека языка определения интерфейсов (IDL) DSM П-П или прикладной интерфейс API.

Библиотека П-П может использовать протоколы Менеджмента Сеанса П-С, Загрузки П-С и уровня Карусели Объектов для управления Сеансами и Ресурсами и для доставки объектов Данных и Потока.

В качестве протоколов транспортного уровня (в нижней части рисунка 3) допускается использование любых протоколов, удовлетворяющих требованиям ISO/IEC [2] (раздел 9), в том числе таких протоколов, как TCP/IP, UDP/IP или AAL. Требования к протоколам транспортного уровня настоящий стандарт не предъявляет.

4.3.6 В таблице 2 показаны интерфейсы используемых протоколов DSM-CC.

Таблица 2 - Интерфейсы используемых протоколов DSM-CC

4.3.7 Выполнение требования к взаимодействию обеспечивается тем, что протоколы сообщений: Конфигурация П-С, Сеанс П-С, Выбор каналов коммутируемого цифрового вещания (SDB CCP) П-С, Загрузка П-С - используют метод передачи, удовлетворяющий требованиям транспортного уровня.

Протокол Карусели Объектов П-П использует протокол Загрузки П-С в соответствии с требованием транспортного уровня.

Библиотека RPC П-П использует протокол Вызова удаленной процедуры и связанные с ним требования к транспортному уровню.

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

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

Метод описания синтаксиса использует синтаксис pseudo-C.

Сообщения Конфигурации П-С и Сеанса П-С передаются между Клиентом и Сетью (МСР) и между Сервером и Сетью (МСР).

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

- Запрос - сообщение, посланное от Пользователя (Клиент или Сервер) к Сети, чтобы начать сценарий;

- Подтверждение - сообщение, посланное от Сети к Пользователю (Клиент или Сервер) в ответ на Запрос;

- Признак - сообщение, посланное от Сети к Пользователю;

- Ответ - сообщение, посланное от Пользователя к Сети в ответ на сообщение признака.

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

Приведенные в настоящем стандарте сценарии являются типичными и не представляют всей полноты перечня сценариев.

4.3.10 Язык SDL определен в Рекомендации ITU-T [1]. Для преобразования спецификации DSM-CC в SDL используется версия SDL-88.

4.4 Основные параметры протокола DSM-CC

4.4.1 Все сообщения DSM-CC MPEG-2 должны начинаться с Заголовка Сообщения DSM-CC (за исключением интерфейсов DSM-CC П-П, которые используют механизм вызова удаленных процедур RPC). Формат Заголовка Сообщения протокола DSM-CC MPEG-2 должен быть, согласно ISO/IEC [2] (раздел 2), в соответствии с приложением В.

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

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

Настоящий стандарт включает в себя требования к следующим элементам Сообщений Конфигурации:

- Формат общего сообщения;

- Параметры конфигурации П-С;

- Сообщения конфигурации П-С;

- Типы данных полей сообщений П-С;

- Последовательность сообщений UNConfigRequest, инициированных Пользователем;

- Последовательность сообщений UNConfiglndication, инициированных сетью;

- Сообщения вещания UNConfiglndication;

- Последовательности конфигурации смешанной инициацилизации Пользователь/Сеть;

- Коды причины конфигурации П-С;

- Коды ответа конфигурации П-С.

Требования к параметрам элементов сообщений конфигурации П-С должны быть, согласно ISO/IEC [2] (раздел 3), в соответствии с приложением Г.

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

Эти сообщения являются частью стека протоколов и предназначены для работы с протоколами транспортного уровня (например, UDP/IP, TCP/IP, AALS).

Условия использования протоколов транспортного уровня должны быть, согласно ISO/IEC [2] (раздел 9), в соответствии с приложением Б.

Все сообщения сеанса П-С передаются между Пользователем (Клиент или Сервер) и Сетью.

Настоящий стандарт включает в себя требования к следующим элементам сообщений сеанса:

- Функциональные группы П-С;

- Применяемые структуры UserData в сообщениях сеанса;

- Типы полей данных сообщений сеанса П-С;

- Коды причины;

- Коды ответа;

- Типы статуса DSM-CC MPEG-2;

- Дескрипторы ресурса;

- Последовательность команд, инициированных Клиентом;

- Последовательность команд, инициированных Сервером;

- Последовательность команд, инициированных Сетью;

- Последовательность команд Сброса-Установки, инициированных Клиентом;

- Последовательность команд Сброса-Установки, инициированных Сервером;

- Последовательность команд Сброса-Установки, инициированных Сетью.

Требования к параметрам сообщений сеансов П-С и управления потоками для сеансов и ресурсов должны быть, согласно ISO/IEC [2] (раздел 4), в соответствии с приложением Д.

4.4.4 Интерфейсы П-П представляют собой набор компоновочных блоков, которые позволяют обеспечить предоставление широкого диапазона запросов Пользователей / Клиентов на мультимедийные услуги. В число предоставляемых мультимедийных услуг могут входить такие услуги как: видео по запросу, путеводитель по телевизионным программам, телемагазин, видеоконференция, новости по запросу, игры, телемедицина, дистанционное обучение.

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

Настоящий стандарт дает определение Среды Системы П-П, включая:

- Объекты Пользователя Аппаратурные;

- Объекты Логические;

- Интерфейсы Сервиса и Приложений;

- Классифицированный набор интерфейса библиотеки Клиента;

- Общие интерфейсы;

- Расширенные Интерфейсы.

Интерфейсы П-П должны быть, согласно ISO/IEC [2] (раздел 5), в соответствии с приложением Е.

Характеристики Среды Системы П-П - в соответствии с Е.1 (приложение Е).

4.4.5 Совместимость Пользователей в среде системы DSM-CC обеспечивается применением дескрипторов совместимости, которые сообщают Серверу информацию об имеющихся у Клиента аппаратных и программных средствах, а Клиенту - о загрузке информации. Используя эту информацию, Сервер принимает решение о загрузке данных Клиенту.

Допускается использование Сервером дескрипторов совместимости для информирования Клиентов о загрузке информации.

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

Требования к составу и параметрам дескрипторов совместимости Пользователей должны быть, согласно ISO/IEC [2] (раздел 6), в соответствии с приложением Ж.

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

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

- загрузка управляемым потоком. При этом сценарии Клиент управляет передачей данных через канал управления к Серверу загрузки (Download Server). Используются сообщения DownloadInfoRequest, DownloadInfoResponse, DownloadDataRequest, DownloadDataBlock;

- загрузка с помощью Карусели Данных. Этот сценарий реализует циклическую передачу данных Сервером загрузки. Клиенты будут получать передаваемые данные в зависимости от приложения. Сервер загрузки может обслужить несколько Клиентов одновременно. Используются сообщения DownloadInfoIndication, DownloadDataRequest, DownloadDataBlock;

- загрузка неуправляемым потоком. Сервер загрузки может использовать этот сценарий, чтобы загрузить данные нескольким Клиентам одновременно. Передача данных базируется на взаимных соглашениях о параметрах передачи. Используются сообщения DownloadInfoRequest, DownloadInfoResponse или DownloadInfoIndication, DownloadDataBlock.

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

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

Требования к параметрам сообщений загрузки П-С должны быть, согласно ISO/IEC [2] (раздел 7), в соответствии с приложением И.

4.4.7 Дескрипторы потока обеспечивают предоставление информации в системе DSM-CC о транспортных и программных потоках MPEG-2. Параметры транспортного потока приведены в приложении А. Значения тегов дескрипторов потока (descriptor_tag), обеспечивающих предоставление информации о транспортных и программных потоках MPEG-2 для системы DSM-CC, приведены в таблице 3.

Таблица 3 - Значения тегов дескрипторов потока (descriptor_tag), предоставляющих информацию о транспортных потоках MPEG-2 для системы DSM-CC

Детализированные данные о типах потоков приведены в ISO/IEC [3] (таблица 2-39).

Требования к параметрам следующих дескрипторов потока П-П:

- дескриптора начала отсчета;

- дескриптора конечной точки NPT;

- дескриптора режима потока;

- дескриптора событий потока -

должны быть, согласно ISO/IEC [2] (раздел 8), в соответствии с приложением К.

4.4.8 Требования к параметрам протоколов передачи сообщений DSM-CC П-С

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

- Сообщения конфигурации П-С;

- Сообщения сеанса П-С;

- Сообщения загрузки П-С;

- Сообщения протокола обмена переключаемых цифровых каналов вещания;

- Транзитные сообщения П-С.

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

В таблице 4 представлен минимальный уровень сервиса, который должен обеспечивать транспортный уровень.

Таблица 4 - Требования к транспортному протоколу П-С и загрузке

4.4.8.2 Интерфейс П-П должен включать в себя сообщения следующих категорий:

- Библиотека RPC П-П;

- Объекты сеанса;

- Объекты загрузки;

- Карусель Объектов П-П;

- Объекты локальных приложений;

- Дескрипторы потока.

Библиотека RPC П-П должна быть использована в механизме удаленного вызова процедуры (RPC). Требования к протоколам вызова удаленной процедуры настоящий стандарт не устанавливает.

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

Структуры сообщений Объекты загрузки и Карусель Объектов П-П допускается передавать в сообщениях загрузки в соответствии с требованиями категории сообщения загрузки.

Дескрипторы потока являются составной частью интерфейса П-П, обеспечивая необходимую дополнительную информацию о потоке MPEG-2 в соответствии с ISO/IEC [3] (таблица 2-39) с условиями в соответствии с приложением Б.

Требования к параметрам протокола передачи сообщений DSM-CC П-С при инкапсуляции в транспортных потоках MPEG-2 и в программном потоке MPEG-2 должны быть, согласно ISO/IEC [2] (раздел 9), в соответствии с приложением Б.

4.4.9 Протокол обмена каналов коммутируемого цифрового вещания П-С

Протокол обмена каналов (CCP) коммутируемого цифрового вещания (SDB) используется между Клиентом и модулем обеспечения межсетевого обмена (МСР) для предоставления Клиенту возможности дистанционного выбора каналов коммутируемого цифрового вещания.

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

4.4.9.1 Протокол SDВ CCP является частью стека протоколов DSM-CC. CCP сообщения предназначены для обслуживания различных транспортных протоколов (например, IP, ATM).

Условия применения протоколов более низких уровней должны быть, согласно ISO/IEC [2] (раздел 9), в соответствии с приложением Б.

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

4.4.9.2 SDB CCP сообщения используют механизм запроса/ответа.

Сообщения запроса выполняются, когда Клиент инициирует последовательность сообщений.

Сервер SDB отвечает на сообщение запроса с подтверждающим сообщением.

Сервер SDB передает Клиенту сообщения признака.

Клиент отвечает на сообщение признака сообщением ответа.

SDB CCP сообщения имеют общий формат и совместно используют тот же заголовок, что и другие сообщения П-С.

Синтаксис сообщений SDB CCP приведен в таблице 5.

Таблица 5 - Синтаксис сообщений SDB CCP

Требования к DSMCCMessageHeader должны быть, согласно ISO/IEC [2] (раздел 2), в соответствии с приложением В.

Сообщение MessagePayload состоит из дескрипторов ресурсов и полей данных.

Его структура определяется спецификой сообщения SDB CCP.

Протокол обмена каналов коммутируемого цифрового вещания (SDB CCP) П-С должен быть, согласно ISO/IEC [2] (раздел 10), в соответствии с приложением Л.

4.4.10 Карусель Объектов должна обеспечивать циклическую передачу Клиенту информации об объектах П-П (Файлы, Каталоги, Потоки), связанной непосредственно с передаваемыми программами или с мультимедийными данными.

4.4.10.1 Доступ Клиентов к совокупности объектов П-П (например, Каталогов, Файлов и Потоков) обеспечивает прикладной интерфейс мультисистемности API.

Допускается использование интерфейса API П-П для доступа к объектам в сети вещания. В этом случае Клиент должен обеспечить локальную функциональность режима П-П и доступ к сети вещания.

При передаче объектов П-П в Сеть Сервер вещания может предложить множеству Клиентов одновременный доступ к объектам.

Протокол Карусели Объектов П-П определяет правила передачи объектов П-П в сетях вещания и правила кодирования объектов П-П, чтобы предложить Клиентам доступ к этим объектам через интерфейс API П-П, определенный в соответствии с приложением Е.

Карусель Объектов П-П использует сценарий Карусели Данных протокола загрузки П-С. Сообщения загрузки П-С определены в соответствии с приложением И.

На рисунке 4 показано положение Карусели Объектов П-П в стеке протоколов.

Рисунок 4 - Положение протоколов Карусели Объектов П-П в стеке протоколов

4.4.10.2 Протокол Карусели Объектов П-П совместим с протоколом П-П приложения Е и со структурой Посредника (Брокера) запроса Объекта (ORB), определенного стандартом CORBA в ISO/IEC [2] (раздел 5).

Домен сервиса имеет шлюз сервиса, который предоставляет Клиентам граф имен услуг.

Для поддержки домена сервиса стандарт DSM-CC предназначает протокол Inter-ORB (BIOP).

Протокол BIOP является сетенезависимым и может быть применен в сети вещания любого типа.

Сетевая независимость протокола BIOP достигнута использованием концепции ответвлений (tар) сигналов в соответствии с ISO/IEC [2] (раздел 5).

Ответвления обеспечивают формирование ссылки на специфическое сетевое подключение использованием тега объединения.

Протокол BIOP состоит из трех частей:

1 Определение профиля тела BIOP.

2 Формат сообщений BIOP.

3 Определения транспорта BIOP.

4.4.10.3 Интерфейс API П-П базируется на интерфейсах П-П, которые могут использовать объекты П-П.

Карусель Объектов П-П поддерживает четыре объекта П-П. Это обеспечивает поддержку интерфейсов считывающего устройства, приведенных в таблице 6. Перечень объектов и интерфейсов, поддерживающих Карусель Объектов П-П, приведен в таблице 6.

Таблица 6 - Интерфейсы считывающего устройства. Перечень объектов и интерфейсов, поддерживающих Карусель Объектов П-П

Характеристики объектов П-П определены в приложении Е. Отличия семантики API П-П от семантики API П-П для интерактивных сетей приведены в ISO/IEC[2] (пункт 11.2.1).

Протокол Карусели Объектов П-П является открытым для расширения, для поддержки вещания общих объектов. В ISO/IEC [2] (приложение F) проиллюстрированы эти функциональные возможности для расширенных объектов потока, которые используют интерфейс событий.

Требования к параметрам Карусели Объектов П-П должны быть, согласно ISO/IEC [2] (раздел 11), в соответствии с приложением М.

4.4.11 Транзитные сообщения П-С используются для передачи сообщений между Пользователями.

Эти сообщения является частью стека протоколов и предназначены для обеспечения транспорта с использованием протоколов низкого уровня (например, UDP/IP, TCP/IP, AALS).

Условия применения протоколов более низких уровней должны быть, согласно ISO/IEC [2] (раздел 9), в соответствии с приложением Б.

Все транзитные сообщения П-С посылаются от Пользователя (или Клиента или Сервера) через Сеть, которая поставляет сообщение Пользователю (Клиенту или Серверу), указанному отправителем сообщения.

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

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

Все транзитные сообщения имеют формат общего сообщения.

Синтаксис транзитных сообщений П-С приведен в таблице 7.

Таблица 7 - Синтаксис транзитных сообщений П-С

Параметры заголовка dsmccMessageHeader определены, согласно ISO/IEC [2] (раздел 2), в соответствии с приложением В. Для сообщения транзита поле dsmccType должно быть установлено в 005.

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

Сообщения транзита П-С определены в соответствии с ISO/IEC [2] (пункт 12.2).

Требования к параметрам транзитных сообщений П-С:

- Сообщения транзита;

- Типы полей данных транзитных сообщений П-С;

- Сценарий сообщения транзита;

- Сценарий приема транзитного сообщения;

- Коды ответа транзита;

- Типы кодов транзита;

- Состояние механизма -

должны быть, согласно ISO/IEC [2] (раздел 12), в соответствии c приложением Н.

4.4.12 Соглашением между Клиентом и Сервером определяются требования к параметрам:

- дистанционного вызова процедур П-П;

- интерфейса сеанса связи П-П;

- интерфейса загрузки П-П;

- интерфейса локальных объектов П-П.

Приложение А
(справочное)

Требования стека протоколов DSM-CC к транспортному потоку MPEG-2

А.1 Элементарные группы данных кодированного транспортного потока описываются именем, длиной в битах и мнемоническим обозначением типа.

Мнемоническое обозначение типа группы данных и описание типа группы данных показано в таблице А.1.

Таблица А.1

А.2 Транспортный поток MPEG формируется на основе пакетированных элементарных потоков (ПЭП (PES)).

Структура основных полей пакета ПЭП (PES), соответствующая ISO/IEС [3], показана на рисунке А.1.

Рисунок А.1 - Структура основных полей пакета ПЭП (PES)

Пакет ПЭП (PES) состоит из заголовка пакета и блока полезной нагрузки.

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

- префикс кода начала пакета;

- идентификатор потока;

- длина ПЭП (PES)-пакета;

- необязательный заголовок пакета, имеет переменную длину:

- приоритет ПЭП (PES)-пакета;

- оригинал или копия;

- 7 флагов, в том числе:

- длина данных заголовка ПЭП (PES)-пакета (PES_header_data_length);

- необязательные поля должны быть в соответствии с ISO/IEC [3].

А.3 Пакеты транспортного потока MPEG имеют постоянную длину 188 байт. Они включают в себя заголовок длиной 4 байта и область полезных данных длиной 184 байта. Структура основных полей транспортного потока MPEG, в соответствии с ISO/IEC [3], показана на рисунке А.2.

Рисунок А.2 - Структура основных полей транспортного потока MPEG

Заголовок пакета транспортного потока MPEG последовательно включает в себя:

- синхробайт байт синхронизации, в нем всегда записано кодовое число 047;

- три флага заголовка по одному биту несут информацию:

- идентификатор типа пакета (PID), 13 битов, сообщает о принадлежности пакета конкретному потоку данных;

- указатель скремблирования, 2 бита, сообщает о наличии или отсутствии скремблирования;

- указатель наличия или отсутствия полей адаптации (adaptation_field_control), 2 бита. Значения полей adaptation_field_control показаны в таблице А.2.

Таблица А.2 - Значения полей adaptation_field_control

- счетчик непрерывности пакетов (continuity_counter), 4 бита, при приеме каждого следующего пакета с данным PID увеличивает свое значение на единицу и после 15-го пакета возвращается в состояние "0";

- поле адаптации или данные содержит:

- дополнительные поля:

Оставшуюся часть поля адаптации занимают служебные данные.

Приложение Б
(обязательное)

Требования к параметрам протокола передачи сообщений DSM-CC П-С при инкапсуляции в транспортных потоках MPEG-2 и в программном потоке MPEG-2

Б.1 Сборка сообщения DSM-CC из пакетов транспортного потока MPEG-2 выполняется при использовании частной секции (private-section), структуру которой определяет ISO/IEC [3].

При использовании транспортного потока MPEG-2 для передачи сообщений протокола DSM-CC формирование пакета этих сообщений должно быть выполнено в соответствии с настоящим приложением.

Структура секций DSMCC_section должна быть совместима с синтаксисом секций private_section так, чтобы обеспечивать использование совместимых декодеров MPEG-2.

Б.2 В тех случаях, когда сообщения DSM-CC П-С и загрузки инкапсулируются в транспортный поток MPEG-2, должен быть использован синтаксис DSMCC_section. Этот же синтаксис может быть использован и в случае передачи других полезных данных.

Структура DSMCC_section использует синтаксис частных секций (private_section) согласно ISO/IEC [3].

Специальная семантика применяет кодирование специфических полей в заголовке DSMCC секций (DSMCC_section).

Отображение DSMCC_section в пакете транспортного потока MPEG-2 и максимальная длина DSMCC_section определяются семантикой для рrivate_sections, установленных ISO/IEC [3].

В некоторых реализациях рекомендуется использовать циклическую проверку избыточности (CRC-32), доступную для применения в рrivate_sections. Поскольку некоторые системы не обеспечивают вычисление CRC-32, синтаксис DSMCC_section допускает альтернативу использования CRC-32.

В соответствии с ISO/IEC [3], если section_syntax_indicator установлен на "1", должно быть обеспечено эффективное использование CRC-32. Если section_syntax_indicator - "0", синтаксис раздела CRC-32 должен быть аналогичным случаю, когда section_syntax_indicator - "1", за исключением того, что поле CRC-32 заменено полем контрольной суммы.

Результирующий синтаксис остается соответствующим ISO/IEC [3], так как полезные данные, следующие за полем section_length, будут обработаны как частные данные.

Поскольку section_syntax_indicator может быть искажен ошибками, поле Private_sections должно быть дополнено величиной section_syntax_indicator.

Если section_syntax_indicator установлен на "0", то private_indicator должен быть проверен на равенство "1". Невыполнение этого условия означает, что секция поражена ошибкой.

Точно так же, если section_syntax_indicator установлен на "1", тогда частный индикатор должен быть установлен на "0".

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

Это требование гарантирует, что DSMCC_sections поддерживает требования к транспортному протоколу согласно ISO/IEC [2] (таблица 9-1).

Синтаксис и семантика, связанные с передачей private_sections (и, следовательно, DSMCC_sections), определены в ISO/IEC [3] (пункт 2.4.4).

При отсутствии ограничений одна или несколько DSM-CC-секций с той же самой table_id могут быть размещены в пакетах транспортного потока с тем же самым значением PID, поскольку другая private_section форматировала таблицы (например, в ISO/IEC [3] stream_type 005), если выполнен анализ table_id.

Формат секций DSM CC_sections приведен в таблице Б.1.

Таблица Б.1 - Формат секций DSMCC_sections

Б.2.1 Семантические определения полей в секции DSMCC_section представлены ниже.

Поле table_id в случае DSMCC_section должно идентифицировать тип данных в полезной нагрузке DSMCC_section.

Это поле определяет специфические правила кодирования полей table_id_extension, version_number, section_number и last_section_number.

Перечень назначений table_id для DSM-CC приведен в таблице Б.2.

Таблица Б.2 - Перечень назначений table_id для DSM-CC

Детализированное распределение величин table_id представлено в ISO/IEC [3] (таблица 2-26).

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

Пояснения к назначениям table_id DSM-CC приведены в ISO/IEC [2] (пункт 9.2.2).

Б.3 Настоящий стандарт определяет отдельные параметры типов потока так, чтобы простой парсинг ISO/IEC [3] таблицы PMT мог найти идентификаторы PID для каждого типа секции DSM-CC (которые, в свою очередь, допускают парсинг идентификаторов протокола).

Фильтрация может быть, кроме того, выполнена на поле table_id в пределах DSMCC_section.

В таблице Б.3 представлены назначения типов потока MPEG-2 для задач DSM-CC (stream_type).

Таблица Б.3 - Назначения типов потока MPEG-2 для задач DSM-CC

Детализированные определения величин MPEG-2 - в соответствии с ISO/IEC [3] (таблица 2-29).

Так как парсинг table_id является рекомендуемым процессом, ограничения на виды информации должны быть помещены в типы потока 00А - 00С следующим образом:

- только DSMCC_sections с table_id 03А должны содержаться в пакетах транспортного потока типа 00А;

- только DSMCC_sections с table_id 03В и 03С П-П должны содержаться в пакетах транспортного потока типа 00В;

- только DSMCC_sections с table_id 03D П-П должны содержаться в пакетах транспортного потока типа 00С;

- если парсинг table_id доступен, то секция stream_type должна быть 00D. В этом случае допускается использование отображения всех секций DSM-CC в пакетах транспортного потока с одним и тем же PID.

Б.4 Интерфейс интероперабельной службы П-П (SII) должен использовать механизм вызова удаленной процедуры (RPC). Протоколы RPC настоящим стандартом не установлены.

Если эти сообщения необходимо переносить в транспортных потоках MPEG-2, то они должны быть инкапсулированы согласно Logical Link Control (LLC) в соответствии с ISO/IEC [6] и SubNetwork Attachment Point (SNAP) в соответствии с ISO/IEC [7].

Этот механизм формирования пакета допускается использовать для других полезных нагрузок, чтобы обеспечить однородный метод передачи данных в транспортных потоках MPEG-2.

Структура LLC/SNAP позволяет использовать для инкапсуляции сетевые протоколы OSI уровня 3, включая, например, протокол маршрутизации в среде Интернет (IP).

Б.5 Сообщения П-С подразделяются на следующие категории:

- конфигурация П-С. Требования к сообщениям - в соответствии с приложением Г и ISO/IEC [2] (раздел 3);

- сообщения Сеанса П-С. Требования к сообщениям - согласно ISO/IEC [2] (раздел 4) и в соответствии с приложением Д;

- загрузка П-С. Требования к сообщениям - согласно ISO/IEC [2] (раздел 7) и в соответствии с приложением И;

- протокол обмена каналов коммутируемого цифрового вещания. Требования к сообщениям - согласно ISO/IEC [2] (раздел 10) и в соответствии с приложением Л;

- транзит П-С. Требования к сообщениям - согласно ISO/IEC [2] (раздел 12) и в соответствии с приложением Н.

Инкапсулированные в транспортный поток сообщения П-С должны передаваться непосредственно в полезной нагрузке секции DSM-CC (DSMCC_section).

Единственная (отдельная) DSM-CC секция (DSMCC_section) должна содержать данные не более чем одного сообщения П-С.

Когда сообщения DownloadDataBlock передаются в транспортном потоке MPEG-2, сообщения DownloadDataBlock с тем же самым идентификатором downloadId должны содержаться в пакетах транспортного потока с тем же значением идентификатора PID.

Б.6 Вызов удаленной процедуры (RPC) использует интероперабельный интерфейс (SII) сервиса П-П.

Интероперабельный интерфейс SII П-П, согласно ISO/IEC [2] (раздел 5), определен в соответствии с приложением Е.

Когда эти сообщения передаются в транспортном потоке MPEG-2, формирование пакета мультипротокольной инкапсуляции должно выполняться в соответствии с Б.4.

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

Например, если TCP/IP инкапсулированы в П-П сообщения RPC, тот же самый метод может также использоваться, чтобы поставить IP для других приложений пользователя.

В этом примере пакеты IP и для П-П вызова удаленной процедуры (RPC) и для целей пользователя могут передаваться в пакетах транспортного потока с одним и тем же идентификатором PID.

Б.7 В случаях, когда дескрипторы потока DSM-CC (например, дескрипторы Normal Play Time, StreamMode и StreamEvent) переносятся в транспортных потоках MPEG-2, они должны переноситься в DSMCC_descriptor_list() с DSM-CC секцией (DSMCC_section) в соответствии с ISO/IEC [2] (таблица 9.5).

Описания полей в списке дескрипторов DSM-CC DSMCC_descriptor_list(): stream-descriptor() - согласно ISO/IEC [2] (раздел 8) и в соответствии с приложением К.

Б.8 В тех случаях, когда дескрипторы потока DSM-CC передаются в программном потоке MPEG-2, их перенос должен выполняться в DSMCC_program_stream_descriptor_list(), как показано в таблице Б.4 (приложение Б), как пакета ПЭП в соответствии с [2].

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

Формат DSMCC_program_stream_descriptor_list приведен в таблице Б.4.

Таблица Б.4 - Формат DSMCC_program_stream_descriptor_list

Описания полей в списке DSM_CC_program_stream_Descriptor_list - в соответствии с ISO/IEC [2] (подпункт 9.3.1.1).

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

Приложение В
(обязательное)

Формат Заголовка Сообщения протокола DSM-CC MPEG-2

В.1 Формат заголовка сообщений DSM-CC приведен в таблице В.1.

Таблица В.1 - Формат заголовка сообщений DSM-CC MPEG -2

B.2 Поле protocolDiscriminator указывает принадлежность данного сообщения сообщению DSM-CC MPEG-2. Значение поля должно быть равно 011.

B.3 Поле dsmccType указывает тип DSM-CC MPEG-2 сообщения. Значения поля dsmccType приведены в таблице В.2.

Таблица В.2 - Значения поля dsmccType

B.4 Поле messageId указывает тип передаваемого сообщения. Значение поля установлено в пределах значений поля dsmccType.

B.5 Поле transactionId определяет целостность сеанса и используется для обработки ошибок. Предусматривается в сообщениях между Сервером и сетью или Клиентом и сетью. Поле содержит 30 битов (с 0 по 29) транзакции и 2 бита (30 и 31), характеризующих источник сообщений. Значения двух битов, характеризующих источник сообщений, приведены в таблице В.3.

Таблица В.3 - Значения двух битов, характеризующих источник сообщений в поле transactionId

B.6 Значение поля reserved должно быть установлено 0FF.

B.7 Поле adaptationLength должно содержать значение длины заголовка адаптации (adaptationHeader).

B.8 Поле messageLength должно содержать значение длины сообщения, начинающегося сразу после поля messageLength.

B.9 Заголовки адаптации используются для облегчения выполнения требований, определенных сетью. Использование заголовка адаптации необязательно. Общий формат заголовка адаптации dsmccAdaptationHeader определен в таблице В.4.

Таблица В.4 - Общий формат заголовка адаптации dsmccAdaptationHeader

В.9.1 Поле adaptationType используется для указания типа заголовка адаптации. Значения поля adaptationType приведены в таблице В.5.

Таблица В.5 - Значения поля adaptationType

В.9.2 Формат поля адаптации условного доступа dsmccСonditionalAccessAdaptationHeader (DSM-CC Conditional Access Adaptation Format) приведен в таблице В.6.

Таблица В.6 - Формат поля адаптации условного доступа dsmccСonditionalAccessAdaptationHeader

Описания полей reserved, caSystemId, conditionalAccessLength и conditionalAccessDataByte должны быть в соответствии с требованиями ISO/IEC [2] (пункт 2.1.1).

В.9.3 Формат адаптации идентификатора (ID) Пользователя (DSM-CC User ID Adaptation) приведен в таблице В.7.

Таблица В.7 - Формат адаптации идентификатора (ID) Пользователя

Описания полей reserved и userId должны быть в соответствии с требованиями ISO/IEC [2] (пункт 2.1.2).

Приложение Г
(обязательное)

Требования к параметрам элементов сообщений конфигурации Пользователь-Сеть

Г.1 Синтаксис общего сообщения конфигурации П-С должен быть в соответствии с таблицей Г.1.

Таблица Г.1 - Синтаксис общего сообщения конфигурации П-С

dsmccMessageHeader() определяется в соответствии с приложением В.

Поле MessagePayload включает в себя поля данных и определяется специфическим сообщением messageId в соответствии с ISO/IEC [2] (пункт 3.3).

Г.2 Сообщения конфигурации П-С подразделяют на три секции:

- специфические параметры конфигурации DSM-CC;

- сетевые специфические параметры конфигурации;

- параметры конфигурации, определяемые Пользователем.

Г.2.1 Специфические параметры конфигурации DSM-CC используются для определения параметров в соответствии с сообщениями П-С.

Формат секции dsmccConfigurationParameters П-С приведен в таблице Г.2.

Таблица Г.2 - Формат секции dsmccConfigurationParameters П-С

Описания полей messageTimer, sessionInProgressTimer, messageRetryCount, sessionIdAssignor, resourceIdAssignor, maximumForwardCount должны быть в соответствии с ISO/IEC [2] (пункт 2.1).

Г.2.2 Сетевые специфические параметры конфигурации networkConfigurationParameters характеризуют адреса (определенные OSI NSAP) точек доступа к сетевым службам.

Формат секции networkConfigurationParameters П-С приведен в таблице Г.3.

Таблица Г.3 - Формат секции networkConfigurationParameters П-С

Поле userId содержит OSI NSAP точку доступа к сетевым службам, которая будет использована с целью уникально идентифицировать Пользователя в Сети.

Поле primaryServerId содержит OSI NSAP точку доступа к сетевым службам, которая будет использована с целью уникально идентифицировать адрес первичного сервера в Сети.

Поле networkParameterLength определяет общее число байтов.

Поле networkParameterDataByte определяет параметры конфигурации. Параметры этого поля настоящим стадартом* не установлены.

________________

* Текст документа соответствует оригиналу. - .

Г.2.3 Параметры конфигурации, определяемые Пользователем, должны быть в соответствии с форматом секции конфигурации userDefinedConfigurationParameters, приведенным в таблице Г.4.

Таблица Г.4 - Формат секции конфигурации userDefinedConfigurationParameters П-С

Поле userDefinedParameterLength определяет общее число полей userDefinedParameterDataBytes.

Поле userDefinedParameterDataByte содержит информацию о конфигурации, которая настоящим стандартом не установлена.

Перечень и параметы сообщений конфигурации П-С приведены в таблице Г.5.

Таблица Г.5 - Перечень сообщений конфигурации П-С

Г.2.4 Сообщение UNConfigRequest передается от Пользователя к Сети в целях запроса параметров конфигурации для Пользователя.

Формат сообщения UNConfigRequest приведен в таблице Г.6.

Таблица Г.6 - Формат сообщения UNConfigRequest

Поле deviceId определено в таблице Г.10 (приложение Г). Поле содержит уникальный номер, который определяет Пользователя. Сеть использует это поле для конфигурации устройства Пользователя.

Структура дескриптора compatibilityDescriptor содержит параметры конфигурации для устройства Пользователя. Структура дескриптора compatibilityDescriptor должна быть согласно ISO/IEC [2] (раздел 6) и в соответствии с приложением Ж.

Г.2.5 Сообщение UNConfigConfirm передается от Сети к Пользователю в ответ на сообщение UNConfigRequest.

Формат сообщения UNConfigConfirm приведен в таблице Г.7.

Таблица Г.7 - Формат сообщения UNConfigConfirm

Поле deviceId определено в таблице Г.10 (приложение Г). Оно содержит уникальный номер, определяющий Пользователя. Значение поля установлено Сетью в ответ на сообщение UNConfigRequest.

Поле response указывает статус запроса конфигурации. Параметры поля response определены в таблице Г.12 (приложение Г).

Формат dsmccConfigurationParameters определен в Г.2.1 (приложение Г).

Формат networkConfigurationParameters определен в Г.2.2 (приложение Г).

Формат userDefinedConfigurationParameters содержит рекомендуемые параметры. Формат этих параметров определен в Г.2.3 (приложение Г).

Г.2.6 Сообщение UNConfigIndication передается от Сети на устройство Пользователя для его конфигурирования. Формат сообщения UNConfigIndication приведен в таблице Г.8.

Таблица Г.8 - Формат сообщения UNConfigIndication

Поле deviceId содержит уникальный номер, определяющий Пользователя. Сеть использует это поле для конфигурирования устройства Пользователя. Кодирование поля deviceId выполняется в соответствии с таблицей Г.10 (приложение Г).

Поле reason заполняется Сетью и содержит обозначение причины, по которой посылаются признаки конфигурации. Кодирование поля reason выполняется в соответствии с таблицей Г.11 (приложение Г).

Структура compatibilityDescriptor указывает устройства, к которым применяется сообщение UNConfigIndication, и должна соответствовать установленной ISO/IEC [2] (раздел 6).

Формат dsmccConfigurationParameters определен в Г.2.1 (приложение Г).

Формат networkConfigurationParameters определен в Г.2.2 (приложение Г).

Формат userDefinedConfigurationParameters определен в Г.2.3 (приложение Г).

Г.2.7 Сообщение UNConfigResponse пересылается от Пользователя к Сети в ответ на сообщение UNConfigIndication. Формат сообщения UNConfigResponse приведен в таблице Г.9.

Таблица Г.9 - Формат сообщения UNConfigResponse

Поле userId содержит точку присоединения к подсети (определенную OSI NSAP), которая назначена Пользователю в соответствии с сообщением UNConfigIndication. Если сообщение UNConfigResponse получено от Клиента, то значение поля userId такое же, как поля clientId. Если сообщение UNConfigResponse получено от Сервера, то значение поля userId такое же, как поля serverId.

Поле response содержит ответ Пользователя на сообщение UNConfigIndication. Коды для этого поля определены в таблице Г.12 (приложение Г).

Структура compatibilityDescriptor содержит текущую конфигурацию параметров для устройства Пользователя. Параметры определены в ISO/IEC [2] (раздел 6).

Г.3 Типы данных полей в сообщениях конфигурации П-С приведены в таблице Г.10.

Таблица Г.10 - Типы полей данных в сообщениях конфигурации П-С

Г.4 Описание сообщения UNConfigRequest, инициированного пользователем:

- для работы с Сетью устройство Пользователя должно знать свой адрес и адрес Сети. Для получения этих адресов и других параметров конфигурации устройство Пользователя посылает Сети сообщение UNConfigRequest;

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

Г.5 Описание сообщения UNContigIndication, инициированного пользователем:

- для конфигурирования устройства Пользователя Сеть посылает этому Пользователю сообщение UNContigIndication с указанием причины конфигурации;

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

Г.6 Описание сообщения вещания UNConfigIndication, инициированного Сетью, должно соответствовать ISO/IEC [2] (пункт 3.7).

Г.7 Описание последовательности конфигурации смешанной инициации (Пользователем и Сетью) должно соответствовать ISO/IEC [2] (пункт 3.8).

Г.8 Значения кодов причины (reason) в сообщениях конфигурации П-С приведены в таблице Г.11.

Таблица Г.11 - Значения кодов причины (reason) в сообщениях конфигурации П-С

Г.9 Значения кодов ответа (response) сообщения конфигурации П-С приведены в таблице Г.12.

Таблица Г.12 - Значения кодов ответа (response)

Приложение Д
(обязательное)

Требования к параметрам сообщений сеансов Пользователь-Сеть и управления сеансами и ресурсами

Д.1 В настоящем приложении определены параметры сообщений сеансов П-С и управления сеансами и ресурсами, допустимые для использования:

- формат этих сообщений;

- сценарии, описывающие процедуры использования этих сообщений;

- используемые дескрипторы ресурса, которые идентифицируют сетевые ресурсы, распределенные сеансу.

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

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

Таблица Д.1 - Синтаксис единого формата сообщения сеанса П-С

Формат заголовка dsmccMessageHeader определен в таблице В.1 (приложение В).

Поле MessagePayload включает в себя дескрипторы ресурса и полей данных. Его структура зависит от назначения конкретного сообщения.

Д.2 Сообщения сеанса Пользователь-Сеть

Д.2.1 Сообщения Сеанса П-С имеют идентификатор сообщения messageId, который указывает тип и направление передачи сообщения. Идентификатор messageId передается в составе dsmccMessageHeader, который определен в таблице В.1 (приложение В).

На рисунке Д.1 показано правило кодирования формата полей messageId, используемых в сообщениях сеанса связи П-С. Бит 0 - младший значащий бит, бит 15 - старший значащий бит.

Рисунок Д.1 - Правило кодирования формата полей messageId, используемых в сообщениях сеанса связи П-С

Д.2.1.1 Дискриминатор сообщения messageDiscriminator указывает направление передачи сообщений между Сетью и Клиентом или между Сетью и Сервером. Значения битов Дискриминатора сообщения messageDiscriminator приведены в таблице Д.2.

Таблица Д.2 - Значения битов Дискриминатора сообщения messageDiscriminator

Д.2.1.2 Двоичная последовательность Сценария сообщения messageScenario используется, чтобы указать ту последовательность сообщений, в которой данное сообщение находится. Значения двоичной последовательности сообщения сценария messageScenario приведены в таблице Д.3.

Таблица Д.3 - Значения двоичной последовательности битов Сценария сообщения messageScenario

Большинство перечисленных сообщений управления используют механизм подтверждения. В некоторых случаях сообщений сеанса П-С этот механизм не используется. Эти случаи следующие:

- сообщения выполнения сеанса;

- сообщения соединения сеанса;

- сообщения развития сеанса.

Сообщения запроса проводятся, когда Сервер или Клиент инициирует сообщение.

Сеть отвечает на сообщение запроса подтверждающим сообщением.

Сообщения, которые посылают Серверу или Клиенту от Сети, - сообщения указания.

Клиент и Сервер отвечают на сообщение указания сообщением Ответа.

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

Эти коды причины определены в ISO/IEC [2] (таблица 4-59).

Сообщения Ответа и Подтверждения могут содержать код ответа, который указывает ответ на сообщение Признака или Запрос. Коды ответа определены в ISO/IEC [2] (таблица 4-60).

Д.2.1.3 Биты Типа сообщения messageType указывают отправителя / получателя сообщения. Значения последовательности битов Типа сообщения messageType приведены в таблице Д.4.

Таблица Д.4 - Значения последовательности битов типа сообщений messageType

Д.2.1.4 Идентификаторы сообщения messageId, используемые в сообщениях сеанса П-С, определены в таблице Д.5.

Таблица Д.5 - Идентификаторы сообщения сеанса П-С messageId

Д.2.2 Функциональная группа представляет собой группу сообщений сеанса, в которой выполняется специфическая реализация.

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

Состав базовой и расширенной функциональных групп должен быть в соответствии с ISO/IEC [2] (подпункты 4.2.1.1, 4.2.1.2).

Д.2.3 Сообщения сеанса П-С, входящие в состав функциональной группы, передаются от Пользователя к МСР и с соответствующим сообщением должны быть посланы от МСР другому Пользователю. Эти сообщения могут содержать поле UserData. В зависимости от обстоятельств поля UserData будут передаваться на Сервер или Клиенту.

Формат структуры поля UserData, передаваемого в сообщениях сеанса П-С, определен в таблице Д.6.

Таблица Д.6 - Формат структуры поля UserData П-С, передаваемого в сообщениях сеанса П-С

Описания полей UserData П-С - в соответствии с ISO/IEC [2] (пункт 4.2.2).

Д.2.4 Сеанс представляет собой процесс связи между Сетью и одним или более Пользователем. По крайней мере, один из Пользователей действует в роли Сервера. Сетевые ресурсы предоставляются сеансу или Сервером, или Сетью (по запросу). Сообщения, которые используются для запроса ресурсов от Сети или для информирования Сети о ресурсах, которые предоставляются Сервером, содержат структуру данных Ресурсов.

Эта структура содержит оценку ресурса и список дескрипторов ресурса, которые определены в ISO/IEC [2] (пункт 4.7).

Формат Resources П-С DSM-CC представлен в таблице Д.7.

Таблица Д.7 - Формат Resources П-С DSM-CC

Описания полей Resources П-С - в соответствии с ISO/IEC [2] (пункт 4.2.3).

Д.2.5 В состав сообщения группы Настройки Сеанса входят сообщения:

- ClientSessionSetUpRequest;

- ClientSessionSetUpConfirm;

- ServerSessionSetUpIndication;

- ServerSessionSetUpResponse.

Форматы сообщений представлены в таблицах Д.8-Д.11 (приложение Д).

Описания полей в таблицах Д.8-Д.11 (приложение Д) в соответствии с ISO/IEC [2] (подпункты 4.2.4.1-4.2.4.4).

Д.2.5.1 Сообщение ClientSessionSetUpRequest передается от Клиента в Сеть для запроса установки сеанса с требуемым serverId. На это сообщение Сеть отвечает сообщением ClientSessionSetUpConfirm.

Формат сообщения ClientSessionSetUpRequest представлен в таблице Д.8.

Таблица Д.8 - Формат сообщения ClientSessionSetUpRequest П-С DSM-CC

Д.2.5.2 Сообщение ClientSessionSetUpConfirm передается от Сети к Клиенту в ответ на сообщение ClientSessionSetUpRequest.

Формат сообщения ClientSessionSetUpConfirm представлен в таблице Д.9.

Таблица Д.9 - Формат сообщения ClientSessionSetUpRequest П-С DSM-CC

Д.2.5.3 Сообщение ServerSessionSetUpIndication передается от Сети на Сервер, чтобы установить сеанс, который затребовал Клиент.

Формат сообщения представлен в таблице Д.10.

Таблица Д.10 - Формат сообщения ServerSessionSetUpIndication П-С DSM-CC

Д.2.5.4 Сообщение ServerSessionSetUpResponse передается от Сервера в Сеть в ответ на сообщение ServerSessionSetUpIndication.

Формат сообщения ServerSessionSetUpResponse представлен в таблице Д.11.

Таблица Д.11 - Формат сообщения ServerSessionSetUpResponse П-С DSM-CC

Д.2.6 В состав сообщения группы Разъединения Сеанса входят следующие сообщения:

- ClientSessionReleaseRequest;

- ClientSessionReleaseConfirm;

- ClientSessionReleaseIndication;

- ClientSessionReleaseResponse;

- ServerSessionReleaseRequest;

- ServerSessionReleaseConfirm;

- ServerSessionReleaseIndication;

- ServerSessionReleaseResponse.

Форматы сообщений представлены в таблицах Д.12-Д.18 (приложение Д).

Описания полей в таблицах Д.12-Д.18 (приложение Д) в соответствии с ISO/IEC[2] (подпункты 4.2.5.1-4.2.5.8).

Д.2.6.1 Сообщение ClientSessionReleaseRequest передается от Клиента в Сеть для запроса прекращения сеанса. На это сообщение Сеть последовательно прекращает сеанс между Сетью и Сервером и отвечает Клиенту сообщением ClientSessionReleaseConfirm.

Формат сообщения ClientSessionReleaseRequest представлен в таблице Д.12.

Таблица Д.12 - Формат сообщения ClientSessionReleaseRequest П-С DSM-CC

Д.2.6.2 Сообщение ClientSessionReleaseConfirm передается от Сети Клиенту в ответ на сообщение ClientSessionReleaseRequest.

Формат сообщения ClientSessionReleaseConfirm представлен в таблице Д.13.

Таблица Д.13 - Формат сообщения ClientSessionReleaseConfirm П-С DSM-CC

Д.2.6.3 Сообщение ClientSessionReleaseIndication передается от Сети Клиенту при инициации разъединения сеанса.

Формат сообщения представлен в таблице Д.14.

Таблица Д.14 - Формат сообщения ClientSessionReleaseIndication П-С DSM-CC

Д.2.6.4 Сообщение ClientSessionReleaseResponse передается от Клиента в Сеть в ответ на сообщение ClientSessionReleaseIndication (как ответ на запрос).

Формат сообщения ClientSessionReleaseResponse представлен в таблице Д.15.

Таблица Д.15 - Формат сообщения ClientSessionReleaseResponse П-С DSM-CC

Д.2.6.5 Сообщение ServerSessionReleaseRequest передается от Сервера к Сети для запроса прекращения сеанса. Сеть отвечает сообщением ServerSessionReleaseConfirm. Перед передачей сообщения ServerSessionReleaseConfirm Сеть должна разорвать сеанс между Сетью и Клиентом.

Формат сообщения ServerSessionReleaseRequest представлен в таблице Д.16.

Таблица Д.16 - Формат сообщения ServerSessionReleaseRequest П-С DSM-CC

Д.2.6.6 Сообщение ServerSessionReleaseConfirm передается от Сети на Сервер в ответ на сообщение ServerSessionReleaseRequest.

Формат сообщения представлен в таблице Д.17.

Таблица Д.17 - Формат сообщения ServerSessionReleaseConfirm П-С DSM-CC

Д.2.6.7 Сообщение ServerSessionReleaseIndication передается от Сети на Сервер, чтобы начать разрыв сеанса, который требовал Клиент.

Формат сообщения представлен в таблице Д.18.

Таблица Д.18 - Формат сообщения ServerSessionReleaseIndication П-С DSM-CC

Д.2.6.8 Сообщение ServerSessionReleaseResponse передается от Сервера в Сеть в ответ на сообщение ServerSessionReleaseIndication.

Формат сообщения ServerSessionReleaseResponse представлен в таблице Д.19.

Таблица Д.19 - Формат сообщения ServerSessionReleaseResponse П-С DSM-CC

Д.2.7 В состав сообщения группы Дополнительных Ресурсов входят следующие сообщения:

- ClientAddResourceIndication;

- ClientAddResourceResponse;

- ServerAddResourceRequest;

- ServerAddResourceConfirm.

Форматы сообщений представлены в таблицах Д.20-Д.23 (приложение Д).

Описания полей в таблицах Д.20-Д.23 (приложение Д) - в соответствии с ISO/IEC [2] (подпункты 4.2.6.1-4.2.6.4).

Д.2.7.1 Сообщение ClientAddResourceIndication передается от Сети Клиенту с целью указать, что по требованию Сервера к сеансу добавлены новые ресурсы.

Формат сообщения представлен в таблице Д.20.

Таблица Д.20 - Формат сообщения ClientAddResourceIndication П-С DSM-CC

Д.2.7.2 Сообщение ClientAddResourceResponse передается от Клиента в Сеть в ответ на сообщение ClientAddResourceIndication, чтобы указать ответ Клиента на запрос.

Формат сообщения ClientAddResourceResponse представлен в таблице Д.21.

Таблица Д.21 - Формат сообщения ClientAddResourceResponse П-С DSM-CC

Д.2.7.3 Сообщение ServerAddResourceRequest передается от Сервера в Сеть, чтобы запросить к сеансу дополнительные ресурсы. Сеть отвечает сообщением ServerAddResourceConfirm.

Формат сообщения ServerAddResourceRequest представлен в таблице Д.22.

Таблица Д.22 - Формат сообщения ServerAddResourceRequest П-С DSM-CC

Д.2.7.4 Сообщение ServerAddResourceConfirm передается с Сети на Сервер в ответ на сообщение ServerAddResourceRequest.

Формат сообщения ServerAddResourceConfirm представлен в таблице Д.23.

Таблица Д.23 - Формат сообщения ServerAddResourceConfirm П-С DSM-CC

Д.2.8 В состав сообщения группы Удаления Ресурсов входят следующие сообщения:

- ClientDeleteResourceIndication;

- ClientDeleteResourceResponse;

- ServerDeleteResourceRequest;

- ServerDeleteResourceConfirm.

Форматы сообщений представлены в таблицах Д.24-Д.27 (приложение Д).

Описания полей в таблицах Д.24-Д.27 (приложение Д) - в соответствии с ISO/IEC [2] (подпункты 4.2.7.1-4.2.7.4).

Д.2.8.1 Сообщение ClientDeleteResourceIndication передается от Сети Клиенту с целью указать, что ресурсы были удалены из сеанса по требованию Сервера.

Формат сообщения ClientDeleteResourceIndication представлен в таблице Д.24.

Таблица Д.24 - Формат сообщения ClientDeleteResourceIndication П-С DSM-CC

Д.2.8.2 Сообщение ClientDeleteResourceResponse передается от Клиента к Сети в ответ на сообщение ClientDeleteResourceIndication как ответ Клиента на запрос.

Формат сообщения ClientDeleteResourceResponse представлен в таблице Д.25.

Таблица Д.25 - Формат сообщения ClientDeleteResourceResponse П-С DSM-CC

Д.2.8.3 Сообщение ServerDeleteResourceRequest передается от Сервера к Сети c запросом удаления ресурсов из сеанса. Сеть отвечает сообщением ServerDeleteResourceConfirm.

Формат сообщения ServerDeleteResourceRequest представлен в таблице Д.26.

Таблица Д.26 - Формат сообщения ServerDeleteResourceRequest П-С DSM-CC

Д.2.8.4 Сообщение ServerDeleteResourceConfirm передается из Сети на Сервер в ответ на сообщение ServerDeleteResourceRequest.

Формат сообщения ServerDeleteResourceConfirm представлен в таблице Д.27.

Таблица Д.27 - Формат сообщения ServerDeleteResourceConfirm П-С DSM-CC

Д.2.9 В состав сообщения группы Непрерывной Подачи Сеансов входят следующие сообщения:

- ServerContinuousFeedSessionRequest;

- ServerContinuousFeedSessionConfirm.

Д.2.9.1 Сообщение ServerContinuousFeedSessionRequest передается от Сервера в Сеть с запросом установки сеанса непрерывной подачи.

Формат сообщения приведен в таблице Д.28.

Таблица Д.28 - Формат сообщения ServerContinuousFeedSessionRequest П-С DSM-CC

Описания полей в таблице Д.28 - в соответствии с ISO/IEC [2] (подпункт 4.2.8.1).

Д.2.9.2 Сообщение ServerContinuousFeedSessionConfirm передается от Сети на Сервер в ответ на сообщение ServerContinuousFeedSessionRequest.

Формат сообщения представлен в таблице Д.29.

Описания полей в таблице Д.29 - в соответствии с ISO/IEC [2] (подпункт 4.2.8.2).

Таблица Д.29 - Формат сообщения ServerContinuousFeedSessionConfirm П-С DSM-CC

Д.2.10 В состав сообщения группы Состояния входят следующие сообщения:

- ClientStatusRequest;

- ClientStatusConfirm;

- ClientStatusIndication;

- ClientStatusResponse;

- ServerStatusRequest;

- ServerStatusConfirm;

- ServerStatusIndication;

- ServerStatusResponse.

Форматы этих сообщений приведены в таблицах Д.30-Д.37 (приложение Д).

Описания полей в таблицах Д.30-Д.37 (приложение Д) - в соответствии с ISO/IEC [2] (подпункты 4.2.9.1-4.2.9.8).

Д.2.10.1 Сообщение ClientStatusRequest передается от Клиента в Сеть для запроса сообщения состояния.

Формат сообщения представлен в таблице Д.30.

Таблица Д.30 - Формат сообщения ClientStatusRequest П-С DSM-CC

Д.2.10.2 Сообщение ClientStatusConfirm передается от Сети Клиенту в ответ на сообщение ClientStatusRequest.

Формат сообщения ClientStatusConfirm представлен в таблице Д.31.

Таблица Д.31 - Формат сообщения ClientStatusConfirm П-С DSM-CC

Д.2.10.3 Сообщение ClientStatusIndication передается от Сети Клиенту для запроса сообщения состояния от Клиента.

Формат сообщения представлен в таблице Д.32.

Таблица Д.32 - Формат сообщения ClientStatusIndication П-С DSM-CC

Д.2.10.4 Сообщение ClientStatusResponse передается от Клиента к Сети в ответ на ClientStatusIndication сообщение, чтобы указать ответ Клиента на запрос.

Формат сообщения ClientStatusResponse представлен в таблице Д.33.

Таблица Д.33 - Формат сообщения ClientStatusResponse П-С DSM-CC

Д.2.10.5 Сообщение ServerStatusRequest передается от Сервера в Сеть для запроса сообщения состояния.

Формат сообщения ServerStatusRequest представлен в таблице Д.34.

Таблица Д.34 - Формат сообщения ServerStatusRequest П-С DSM-CC

Д.2.10.6 Сообщение ServerStatusConfirm передается от Сети на Сервер в ответ на сообщение ServerStatusRequest.

Формат сообщения ServerStatusConfirm представлен в таблице Д.35.

Таблица Д.35 - Формат сообщения ServerStatusConfirm П-С DSM-CC

Д.2.10.7 Сообщение ServerStatusIndication передается от Сети на Сервер для запроса сообщения состояния от Сервера.

Формат сообщения представлен в таблице Д.36.

Таблица Д.36 - Формат сообщения ServerStatusIndication П-С DSM-CC

Д.2.10.8 Сообщение ServerStatusResponse передается от Сервера в Сеть в ответ на сообщение ServerStatusIndication.

Формат сообщения ServerStatusResponse представлен в таблице Д.37.

Таблица Д.37 - Формат сообщения ServerStatusResponse П-С DSM-CC

Д.2.11 В состав сообщения группы повторного Сброса-Установки входят следующие сообщения:

- ClientResetRequest;

- ClientResetConfirm;

- ClientResetIndication;

- ClientResetResponse;

- ServerResetRequest;

- ServerResetConfirm;

- ServerSessionResetIndication;

- ServerResetResponse.

Форматы этих сообщений приведены в таблицах Д.38-Д.45 (приложение Д).

Описания полей в таблицах Д.38-Д.45 (приложение Д) - в соответствии с ISO/IEC [2] (подпункты 4.2.10.1-4.2.10.8).

Д.2.11.1 Сообщение ClientResetRequest передается от Клиента к Сети, чтобы начать повторную установку всех сеансов, активных для Клиента.

Формат сообщения представлен в таблице Д.38.

Таблица Д.38 - Формат сообщения ClientResetRequest П-С DSM-CC

Д.2.11.2 Сообщение ClientResetConfirm передается от Сети Клиенту в ответ на сообщение ClientResetRequest.

Формат сообщения ClientResetConfirm представлен в таблице Д.39.

Таблица Д.39 - Формат сообщения ClientResetConfirm П-С DSM-CC

Д.2.11.3 Сообщение ClientResetIndication передается от Сети Клиенту, чтобы начать установку в исходное состояние всех сеансов, активных для Клиента.

Формат сообщения представлен в таблице Д.40.

Таблица Д.40 - Формат сообщения ClientResetIndication П-С DSM-CC

Д.2.11.4 Сообщение ClientResetResponse передается от Клиента к Сети в ответ на сообщение ClientResetIndication.

Формат сообщения ClientResetResponse представлен в таблице Д.41.

Таблица Д.41 - Формат сообщения ClientResetResponse П-С DSM-CC

Д.2.11.5 Сообщение ServerResetRequest передается от Сервера к Сети, чтобы начать клиринг всех сеансов.

Формат сообщения ServerResetRequest представлен в таблице Д.42.

Таблица Д.42 - Синтаксис сообщения ServerResetRequest П-С DSM-CC

Д.2.11.6 Сообщение ServerResetConfirm передается от Сети на Сервер в ответ на сообщение ServerResetRequest.

Формат сообщения ServerResetConfirm представлен в таблице Д.43.

Таблица Д.43 - Формат сообщения ServerResetConfirm П-С DSM-CC

Д.2.11.7 Сообщение ServerSessionResetIndication передается от Сети на Сервер, чтобы начать клиринг всех сеансов.

Формат сообщения ServerSessionResetIndication представлен в таблице Д.44.

Таблица Д.44 - Формат сообщения ServerSessionResetIndication П-С DSM-CC

Д.2.11.8 Сообщение ServerResetResponse передается от Сервера к Сети в ответ на сообщение ServerResetIndication.

Формат сообщения ServerResetResponse представлен в таблице Д.45.

Таблица Д.45 - Формат сообщения ServerResetResponse П-С DSM-CC

Д.2.12 В состав сообщения группы Выполнения Сеанса входят следующие сообщения:

- ClientSessionProceedingIndication;

- ServerSessionProceedingIndication.

Д.2.12.1 Сообщение ClientSessionProceedingIndication передается от Сети Клиенту в ответ на сообщение ClientSessionSetUpRequest, чтобы сообщить Клиенту, что запрос обрабатывается.

Формат сообщения ClientSessionProceedingIndication представлен в таблице Д.46.

Таблица Д.46 - Формат сообщения ClientSessionProceedingIndication П-С DSM-CC

Описания полей в таблице Д.46 - в соответствии с ISO/IEC [2] (подпункт 4.2.11.1).

Д.2.12.2 Сообщение ServerSessionProceedingIndication передается от Сети на Сервер в ответ на ServerContinuousFeedSessionRequest, чтобы сообщить Серверу, что запрос обрабатывается. Сервер должен сбросить таймер tMsg к его начальному значению после получения этого сообщения.

Формат сообщения ServerSessionProceedingIndication представлен в таблице Д.47.

Таблица Д.47 - Формат сообщения ServerSessionProceedingIndication П-С DSM-CC

Описания полей в таблице Д.47 приведены в соответствии с ISO/IEC [2] (подпункт 4.2.11.2).

Д.2.13 В состав сообщения группы Соединения входят следующие сообщения:

- ClientConnectRequest;

- ServerConnectIndication.

Д.2.13.1 Сообщение ClientConnectRequest передается от Клиента к Сети, чтобы сообщить Сети, с которой Клиент связан сеансом, о готовности продолжить обмен сообщениями.

Формат сообщения ClientConnectRequest представлен в таблице Д.48.

Таблица Д.48 - Формат сообщения ClientConnectRequest П-С DSM-CC

Описания полей в таблице Д.48 приведены в соответствии с ISO/IEC [2] (подпункт 4.2.12.1).

Д.2.13.2 Сообщение ServerConnectIndication передается от Сети на Сервер, чтобы сообщить, что Клиент получил соединение с сеансом и готов продолжать передачу сообщений П-П режима. Сеть посылает это сообщение после получения сообщения ClientConnectRequest.

Формат сообщения ServerConnectIndication представлен в таблице Д.49.

Таблица Д.49 - Формат сообщения ServerConnectIndication П-С DSM-CC

Описания полей в таблице Д.49 приведены в соответствии с ISO/IEC [2] (подпункт 4.2.12.2).

Д.2.14 В состав сообщения группы Перемещения Сеанса входят следующие сообщения:

- ClientSessionTransferIndication;

- ClientSessionTransferResponse;

- ServerSessionTransferRequest;

- ServerSessionTransferConfirm;

- ServerSessionTransferIndication;

- ServerSessionTransferResponse.

Форматы этих сообщений приведены в таблицах Д.50-Д.55 (приложение Д).

Описания полей в таблицах Д.50-Д.55 (приложение Д) приведены в соответствии с ISO/IEC [2] (подпункты 4.2.13.1-4.2.13.6).

Д.2.14.1 Сообщение ClientSessionTransferIndication передается от Сети Клиенту о выполнении передачи.

Формат сообщения ClientSessionTransferIndication представлен в таблице Д.50.

Таблица Д.50 - Формат сообщения ClientSessionTransferIndication П-С DSM-CC

Д.2.14.2 Сообщение ClientSessionTransferResponse передается от Клиента к Сети в ответ на сообщение ClientSessionTransferIndication.

Формат сообщения ClientSessionTransferResponse представлен в таблице Д.51.

Таблица Д.51 - Формат сообщения ClientSessionTransferResponse П-С DSM-CC

Д.2.14.3 Сообщение ServerSessionTransferRequest передается от Сервера к Сети с запросом о передаче сеанса.

Формат сообщения ServerSessionTransferRequest представлен в таблице Д.52.

Таблица Д.52 - Формат сообщения ServerSessionTransferRequest П-С DSM-CC

Д.2.14.4 Сообщение ServerSessionTransferConfirm передается от Сети на Сервер в ответ на ServerSessionTransferRequest.

Формат сообщения ServerSessionTransferConfirm представлен в таблице Д.53.

Таблица Д.53 - Формат сообщения ServerSessionTransferConfirm П-С DSM-CC

Д.2.14.5 Сообщение ServerSessionTransferIndication передается от Сети на Сервер с целью указать, что эту передачу требуют на этот Сервер.

Формат сообщения представлен в таблице Д.54.

Таблица Д.54 - Формат сообщения ServerSessionTransferIndication П-С DSM-CC

Д.2.14.6 Сообщение ServerSessionTransferResponse передается от Сервера к Сети в ответ на ServerSessionTransferIndication.

Формат сообщения ServerSessionTransferResponse представлен в таблице Д.55.

Таблица Д.55 - Формат сообщения ServerSessionTransferResponse П-С DSM-CC

Д.2.15 В состав сообщений группы Развития Сеанса входят следующие сообщения:

- ClientSessionInProgress;

- ServerSessionInProgress.

Д.2.15.1 Сообщение ClientSessionInProgress передается от Клиента к Сети периодически, чтобы сообщить Сети о сеансах с активными Клиентами.

Формат сообщения представлен в таблице Д.56.

Таблица Д.56 - Формат сообщения ClientSessionInProgress П-С DSM-CC

Описания полей в таблице Д.56 приведены в соответствии с ISO/IEC [2] (подпункт 4.2.14.1).

Д.2.15.2 Сообщение ServerSessionInProgress передается от Сервера к Сети периодически, чтобы сообщить Сети о сеансах, активных на Сервере.

Формат сообщения представлен в таблице Д.57.

Таблица Д.57 - Формат сообщения ServerSessionInProgress П-С DSM-CC

Описания полей в таблице Д.57 приведены в соответствии с ISO/IEC [2] (подпункт 4.2.14.2).

Д.3 Характеристики Типов Поля Данных, используемых в Сообщении Сеанса П-С, представлены в таблице Д.58.

Таблица Д.58 - Характеристики Типов Поля Данных, используемых в Сообщении Сеанса П-С

Д.4 Значения Кодов Причины, используемые в соответствии с сообщениями сеанса П-С, представлены в таблице Д.59.

Таблица Д.59 - Коды Причины сообщения сеанса П-С

Д.5 Значения Кодов Ответа, используемые в соответствии с сообщениями сеанса П-С, представлены в таблице Д.60.

Таблица Д.60 - Коды Ответа сообщения сеанса П-С

Д.6 Поле Тип Статуса (statusType) используется для индикации типа статуса, который запрашивается или сообщается в ответ на запрос.

Возможные значения запрашиваемого или возвращаемого поля Тип Статуса представлены в таблице Д.61.

В этой таблице resourceId является комбинацией sessionId и resourceNum, которые уникально идентифицируют дескриптор ресурса в пределах сеанса.

Таблица Д.61 - Значения statusType MPEG-2 DSM-CC

Д.7 Дескрипторы ресурса содержат информацию, необходимую для Сети при распределении ресурса, контроле за распределенным ресурсом и освобождением ресурса (при его высвобождении).

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

Д.7.1 Общий формат Дескриптора Ресурса представлен в таблице Д.62.

Таблица Д.62 - Общий формат Дескриптора Ресурса

Д.7.1.1 Поле commonDescriptorHeader должно использоваться при каждом определении дескриптора ресурса. Формат поля commonDescriptorHeader представлен в таблице Д.63.

Таблица Д.63 - Формат поля commonDescriptorHeader

Д.7.1.1.1 Поле resourceRequestId установлено пользователем для сопоставления ресурса, указанного в сообщении запроса, с результатом в подтверждающем сообщении.

Д.7.1.1.2 Поле resourceDescriptorType определяет затребованный ресурс.

Значения поля resourceDescriptorTypes для различных типов дескрипторов ресурса DSM-CC приведены в таблице Д.64.

Таблица Д.64 - Значения поля resourceDescriptorTypes для различных типов дескрипторов ресурса DSM-CC

Д.7.1.1.3 Поле resourceNum включает в себя уникальный номер и источник назначения resourceNum (назначен Сетью, Клиентом или Сервером).

На рисунке Д.2 показан формат поля resourceNumber.

Рисунок Д.2 - Формат поля resourceNumber

Субполе resourceNumVaIue уникально идентифицирует ресурс в пределах сеанса.

Субполе resourceNumberAssignor указывает объект, назначивший ресурс (Клиент, Сервер или Сеть). Значения субполя resourceNumberAssignor приведены в таблице Д.65.

Таблица Д.65 - Значения субполя resourceNumberAssignor П-С DSM-CC