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

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

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

Текст ГОСТ Р 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 - Междуобъектные и внутриподсистемные логические интерфейсы

Одноуровневый
(Peer 1)

Одноуровневый (Peer 2)

Тип протокола DSM-CC

Междуобъектный интерфейс

Внутрипод-
системный интерфейс

Библиотека Клиента П-П

Шлюз сервиса Сервера

П-П

Да*

Нет

Библиотека Клиента П-П

Доступ объекта Сервера

П-П

Да

Нет

Шлюз сеанса Клиента

МСР

П-С

Да

Нет

Менеджер ресурса Клиента

МСР

П-С

Да

Нет

Менеджер сеанса Сервера

МСР

П-С

Да

Нет

Менеджер ресурса Сервера

МСР

П-С

Да

Нет

Конфигурация Клиента

МСР

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

Да

Нет

Конфигурация Сервера

МСР

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

Да

Нет

Поставщик DSM Серверов (например, транспортный поток MPEG-2)

Клиент Пользователя DSM

(MPEG)

Да*

Нет

Сервер загрузки

Клиент загрузки П-С

Загрузка

Да*

Нет

Сервер Карусели Объектов

Клиент Карусели Объектов

Карусель Объектов / загрузка

Да*

Нет

Сервер SDB

SDB Клиент

SDB CCP

Да*

Нет

Приложения Клиента

Библиотека Клиента П-П

П-П

Нет

Да

* Интерфейс на рисунке 2 не показан.

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

DSM-CC протоколы

Одноуровневый
(Peer 1)

Одноуровневый (Peer 2)

Формат сообщения
П-С

Используемый протокол: RPC или IDL

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

Клиент/Сервер

МСР

Да

Нет

Сеанс П-С

Клиент/Сервер

МСР

Да

Нет

Загрузка П-С

Клиент

Загрузка

Сервер

Да

Нет

SDB- CCP П-С

Клиент

SDB Сервер

Да

Нет

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

Клиент

Сервер

Да

Нет

RPC П-П

Клиент

RPC Сервер

Нет

RPC

Сеанс П-П

Приложения

Клиент

Библиотека

Клиент П-П

Нет

IDL

Загрузка П-П

Приложения

Клиент

Библиотека

Клиент П-П

Нет

IDL

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

Клиент

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

Карусель

Объектов

Да

Нет

Локальные объекты П-П

Приложения

Клиент

Библиотека

П-П

Нет

IDL

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

descriptor_tag

Транспортный поток (TS)

Программный поток (PS)

Тип секции DSM-CC

0-18

Не применимо

Не применимо

Определено Рекомендацией ITU-T [4] и ISO/IEC [2]

19

Применимо

Применимо

carousel_identifier_descriptor в соответствии с приложением М

20

Применимо

Применимо

association_tag_descriptor в соответствии с приложением М

21

Применимо

Применимо

deferred_association_tags_descriptor в соответствии с приложением М

22

Применимо

Применимо

Зарезервировано в соответствии с ISO/IEC [2]

23

Применимо

Применимо

Дескриптор ссылки NPT

24

Применимо

Применимо

Дескриптор NPT

25

Применимо

Применимо

Дескриптор тип потока (Stream Mode)

26

Применимо

Применимо

Дескриптор события потока (Stream Event)

27-63

Не применимо

Не применимо

Определено Рекомендацией ITU-T [4]

64-255

Не применимо

Не применимо

Частный пользователь.

Определено Рекомендацией ITU-T [4]

Детализированные данные о типах потоков приведены в 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

Синтаксис

SDBChannelChangeProtocolMessage() {

DSMCCMessageHeader()

MessagePayload()

}

Требования к 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 - Интерфейсы считывающего устройства. Перечень объектов и интерфейсов, поддерживающих Карусель Объектов П-П

Объекты Карусели

Поддерживаемые интерфейсы считывающего устройства

Директория DSM::Directory

Доступ, каталог

Файл DSM::File

База, доступ, файл

Поток DSM::Stream

База, доступ, поток

Шлюз Cервиса DSM::ServiceGatewav

Доступ, служба шлюза, каталог, сеанс

Характеристики объектов П-П определены в приложении Е. Отличия семантики 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 - Синтаксис транзитных сообщений П-С

Синтаксис

unPassThruMessage() {

dsmccMessageHeader()

MessagePayload()

}

Параметры заголовка 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

Мнемоника

Описание типа группы данных

bslbf

Строка битов, левый бит обрабатывается первый. Строки битов написаны в виде цепочек цифр 1 или 0, заключенных в одинарные кавычки, например, 10000001. Пробелы в пределах цепочек цифр проставлены для простоты чтения и не имеют другого значения

rpchof

Перечень коэффициентов полинома ненулевых степеней, начиная с коэффициента с самой высокой степенью

tcimsbf

Два целых числа дополнения, сначала записывается старший значащий бит

uimsbf

Целое число без знака, сначала записывается старший значащий бит

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

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


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

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

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

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

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

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

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

- управление скремблированием ПЭП (PES)-пакета: поле указывает режим скремблирования ПЭП-пакета. Первый бит поля управления несет сообщение - скремблирована "1" или нет "0" полезная нагрузка пакета. Второй бит поля управления несет сообщение о ключе, которым скремблируется полезная нагрузка пакета ("0" - пакет скремблирован четным ключом, "1" - пакет скремблирован нечетным ключом). Ключ определяется пользователем;

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

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

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

- флаги PTS_DTS (PTS_DTS_flags),

- флаг проверки PES-пакета (PES CRC),

- флаг расширения PES-пакета (PES_extension_flag);

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

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

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


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

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

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

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

- об ошибках передачи,

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

- приоритет передачи;

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

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

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

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

Значение бита

Описание

00

Зарезервировано для применений в будущем

01

Поле adaptation_field_control отсутствует. Передается только полезная нагрузка

10

Передается только поле adaptation_field_control. Полезная нагрузка не передается

11

Передается поле adaptation_field_control. Передается полезная нагрузка

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

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

- указатель длины поля, 1 байт,

- указатель непрерывности счета времени во временных метках, 1 бит; значение "1" указывает на изменение базы отсчета времени,

- указатель случайного доступа, 1 бит,

- указатель приоритета элементарного потока, 1 бит,

- пять флагов;

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

- поле PCR (PCR_fields), 42 бита,

- поле OPCR (ОРCR_fields), 42 бита,

- указатель числа пакетов до стыка, 8 битов, - указывает число пакетов с тем же PID в транспортном потоке, оставшихся до точки бесшовного входа в поток,

- длина поля данных, 8 битов,

- поле данных пользователя,

- длина расширения поля адаптации (данных), 8 битов.

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

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

Требования к параметрам протокола передачи сообщений 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

Синтаксис

Число битов

Мнемоника

DSMCC _section() {

table_id

8

uimsbf

section_syntax_indicator

1

bslbf

private_indicator

1

bslbf

reserved

2

bslbf

dsmcc_section_length

12

uimsbf

table_id_extension

16

uimsbf

reserved

2

bslbf

version_number

5

uimsbf

current_next_indicator

1

bslbf

section_number

8

uimsbf

last_section_number

if(table id == 03A) {

LLCSNAP()

}

else if(table_id == 03B) {

userNetworkMessage()

}

else if(table_id == 03C) {

downloadDataMessage()

}

else if(table_id == 03D) {

DSMCC_descriptor_list()

}

else if(table_id == 03E) {

for (i=0;i<dsmcc_section_length-9;i++) {

private_data_byte

}

}

if(section_syntax_indicator =='0') {

8

uimsbf

checksum

}

else {

32

uimsbf

CRC_32

}

32

rpchof

}

Примечание - Поле LLCSNAP - в соответствии с ISO/IEC [2] (пункт 9.2).

Б.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

Тип секции DSM-CC

000 - 037

Определено рекомендацией ITU-T [4], ISO/IEC [3]

038 - 039

Зарезервировано ISO/IEC [2]

0

DSM-CC секции, содержащие данные мультипротокольной инкапсуляции

0

DSM-CC секции, содержащие сообщения П-С, кроме сообщений загрузки данных

0

DSM-CC секции, содержащие сообщения загрузки данных

03D

DSM-CC секции, содержащие дескрипторы потока

0

DSM-CC секции, содержащие частные данные

03F

Зарезервировано ISO/IEC [2]

040 - 0FE

Частный пользователь

0FF

Запрещенный

Детализированное распределение величин 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

stream_type

Описание

000 - 009

Определен Рекомендацией ITU-T [4], ISO/IEC [3]

0

Мультипротокольная инкапсуляция

0

DSM-CC сообщения П-С

0

DSM-CC дескрипторы потока

00D

DSM-CC секции (любой тип, включая частные данные)

00Е - 0

Определен Рекомендацией ITU-T [4], ISO/IEC [3]

080 - 0FF

Частный пользователь

Детализированные определения величин 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

Синтаксис

Число битов

Мнемоника

DSMCC_program_stream_descriptor_list() {

packet_start_code_prefix

24

bslbf

stream_id

8

uimsbf

packet_length

for (i=0;i<N;i++) {

16

uimsbf

dsmcc_discriminator

stream_descriptor()

}

8

uimsbf

}

Описания полей в списке 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

Синтаксис

Число байтов

dsmccMessageHeader() {

protocolDiscriminator

1

dsmccType

1

messageId

2

transactionId

4

reserved

1

adaptationLength

1

messageLength

if(adaptationLength>0) {

dsmccAdaptationHeader()

}

2

}

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

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

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

Значение

Описание

000

Зарезервировано ISO/IEC [2]

001

Сообщение конфигурации

002

Сообщение о сеансе

003

Сообщение о загрузке

004

Сообщение протокола SDB П-С

005

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

006 - 07F

Зарезервировано ISO/IEC [2]

080 - 0FF

Тип сообщения определяется Пользователем

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

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

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

Значение двух битов, характеризующих источник сообщений

Описание

000

transactionId назначено Клиентом

001

transactionId назначено Сервером

002

transactionId назначено сетью

003

Зарезервировано ISO/IEC [2]

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

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

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

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

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

Синтаксис

Число байтов

dsmccAdaptationHeader() {

adaptationeType

for (i=0; i<(adaptationLength-1); i++) {

1

adaptationeDataByte

}

1

}

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

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

Тип адаптации

Описание

000

Зарезервировано ISO/IEC [2]

001

Формат адаптации условного доступа DSM-CC

002

Формат адаптации идентификатора (ID) Пользователя DSM-CC

002 - 07F

Зарезервировано ISO/IEC [2]

080 - 0FF

Тип адаптации определяет Пользователь

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

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

Синтаксис

Число байтов

dsmccConditionalAccess(){

reserved

1

caSystemId

2

conditionalAccessLength

for (i=0;i<conditionalAccessLength;i++) {

2

conditionalAccessDataByte

}

1

}

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

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

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

Синтаксис

Число байтов

dsmccUserId() {

reserved

1

userId

20

}

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

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

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

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

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

Синтаксис

unConfigurationMessage () {

dsmccMessageHeader()

MessagePayload

}

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

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

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

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

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

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

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

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

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

Синтаксис

Число байтов

dsmccConfigurationParameters() {

messageTimer

4

sessionInProgressTimer

4

messageRetryCount

1

sessionIdAssignor

1

resourceIdAssignor

1

maximumForwardCount

1

}

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

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

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

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

Синтаксис

Число байтов

networkConfigurationParameters() {

userId

20

primaryServerId

20

networkParameterLength

for (i=0;i<networkParameterLength;i++) {

2

networkParameterDataByte

}

1

}

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

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

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

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

________________

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

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

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

Синтаксис

Число байтов

userDefinedConfigurationParameters() {

userDefinedParameterLength

for (i=0;i<userDefinedParameterLength;i++) {

2

userDefinedParameterDataByte

}

1

}

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

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

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

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

Значение идентификатора сообщений загрузки messageId

Наименование сообщения

Описание

00000

Зарезервировано

Зарезервировано ISO/IEC [2]

00001

UNConfigRequest

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

от Пользователя к Сети

00002

UNConfigConfirm

Отклик на сообщение UNConfigRequest;

от Сети к Пользователю

00003

UNConfigIndication

Конфигурация устройства пользователя;

от Сети к Пользователю

00004

UNConfigResponse

Отклик на сообщение UNConfigIndication;

от Пользователя к Сети

00005 - 07FFFF

Зарезервировано

Зарезервировано ISO/IEC [2]

08000 - 0FFFF

Определяется пользователем

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

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

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

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

Синтаксис

Число байтов

UNConfigRequest() {

dsmccMessageHeader()

deviceId

6

reserved

compatibilityDescriptor()

2

}

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

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

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

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

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

Синтаксис

Число байтов

UNConfigConfirm() {

dsmccMessageHeader()

deviceId

6

response

dsmccConfigurationParameters()

networkConfigurationParameters()

userDefinedConfigurationParameters()

2

}

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

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

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

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

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

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

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

Синтаксис

Число байтов

UNConfigIndication() {

dsmccMessageHeader()

deviceId

6

reason

compatibilityDescriptor()

dsmccConfigurationParameters()

networkConfigurationParameters()

userDefinedConfigurationParameters()

2

}

Поле 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

Синтаксис

Число байтов

UNConfigResponse() {

dsmccMessageHeader()

userId

20

response

2

reserved

compatibilityDescriptor()

2

}

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

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

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

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

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

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

Длина, байты

Диапазон значений

Описание

deviceId

6

00000000000 - 0FFFFFFFFFFFF

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

Reason

2

00000 - 0FFFF

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

Response

2

00000 - 0FFFF

Указывает отклик на сообщение конфигурации. Коды, указанные в таблице Г.12 (приложение Г), определяют возможные значения этого поля

UserId

20

Определено OSI NSAP

Глобально уникальный OSI NSAP адрес, идентифицирующий Пользователя

Г.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) в сообщениях конфигурации П-С

Ответ (Response)

Значение

Описание

rsnNormal

00000

Указывает, что посылаемое сообщение является нормальным сообщением UNConfigIndication и пользователь должен послать ответ

RsnNoReply

00001

Указывает, что сообщение UNConfigIndication посылается незапрашиваемому пользователю или группе пользователей и от пользователей ответ не требуется

Reserved

00002 - 07FFF

Зарезервировано ISO/IEC [2]

User defined

08000 - 0FFFF

Коды определяются пользователем

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

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

Ответ (response)

Значение

Описание

rspOK

00000

Указывает, что сообщение обработано успешно

RspNotAvailable

00001

Указывает, что Сервер конфигурации П-С в Сети в это время недоступен

RspInvalid

00002

Указывает, что запрос конфигурации был отклонен Сервером конфигурации П-С в Сети

RspRejected

00003

Указывает, что пользователь отклонил сообщение UNConfigIndication

Reserved

00004 - 07FFF

Зарезервировано ISO/IEC [2]

User defined

08000 - 0FFFF

Коды определяются пользователем



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

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

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

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

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

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

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

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

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

Синтаксис

UserNetworkSessionMessage() {

dsmccMessageHeader()

MessagePayload()

}

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

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

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

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

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


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

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

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

Значения битов

Поток сообщения

00

Зарезервировано ISO/IEC [2]

01

Клиент и Сеть

10

Сервер и Сеть

11

Зарезервировано ISO/IEC [2]

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

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

Значение

Описание

00 0000 0000

Зарезервировано ISO/IEC [2]

00 0000 0001

Подготовка сеанса в соответствии с ISO/IEC [2] (пункт 4.2.4)

00 0000 0010

Разъединение сеанса в соответствии с ISO/IEC [2] (пункт 4.2.5)

00 0000 0011

Дополнительные ресурсы в соответствии с ISO/IEC [2] (пункт 4.2.6)

00 0000 0100

Удаление ресурса (Delete Resource) в соответствии с ISO/IEC [2] (пункт 4.2.7)

00 0000 0101

Подготовка непрерывной передачи сеансов в соответствии с ISO/IEC [2] (пункт 4.2.8)

00 0000 0110

Состояния в соответствии с ISO/IEC [2] (пункт 4.2.9)

00 0000 0111

Повторный Сброс-Установка в соответствии с ISO/IEC [2] (пункт 4.2.10)

00 0000 1000

Выполнение Сеанса в соответствии с ISO/IEC [2] (пункт 4.2.11)

00 0000 1001

Соединение Сеанса в соответствии с ISO/IEC [2] (пункт 4.2.12)

00 0000 1010

Перенос Сеанса в соответствии с ISO/IEC [2] (пункт 4.2.13)

00 0000 1011

Развития Сеанса в соответствии с ISO/IEC [2] (пункт 4.2.14)

00 0000 1100 - 01 1111 1111

Зарезервировано ISO/IEC [2]

10 0000 0000 - 11 1111 1111

Определяется Пользователем

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

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

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

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

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

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

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

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

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

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

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

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

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

Значение

Описание

0000

Request Message. Означает, что сообщение передается от Пользователя к Сети с целью начать сценарий

0001

Confirm Message. Означает, что сообщение передается от Сети к Пользователю в ответ на сообщение Request Message

0010

Indication Message. Означает, что сообщение передается от Сети к Пользователю

0011

Response Message. Означает, что сообщение передается от Пользователя к Сети в ответ на сообщение Indication

0100 - 1111

Зарезервировано ISO/IEC [2].

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

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

Команды Клиента

messageId Клиента

messageId Сервера

Команды Сервера

Зарезервировано ISO/IEC [2]

00000-0400f

08000-0800f

Зарезервировано ISO/IEC [2]

ClientSessionSetUpRequest

04010

08010

Зарезервировано ISO/IEC [2]

ClientSessionSetUpConfirm

04011

08011

Зарезервировано ISO/IEC [2]

Зарезервировано ISO/IEC [2]

04012

08012

ServerSessionSetUpIndication

Зарезервировано ISO/IEC [2]

04013

08013

ServerSessionSetUpResponse

Зарезервировано ISO/IEC [2]

04014-0401f

08014-0801f

Зарезервировано ISO/IEC [2]

ClientSessionReleaseRequest

04020

08020

ServerSessionReleaseRequest

ClientSessionReleaseConfirm

04021

08021

ServerSessionReleaseConfirm

ClientSessionReleaseIndication

04022

08022

ServerSessionReleaseIndication

ClientSessionReleaseResponse

04023

08023

ServerSessionReleaseResponse

Зарезервировано ISO/IEC [2]

04024-0402f

08024-0802f

Зарезервировано ISO/IEC [2]

Зарезервировано ISO/IEC [2]

04030

08030

ServerAddResourceRequest

Зарезервировано ISO/IEC [2]

04031

08031

ServerAddResourceConfirm

ClientAddResourceIndication

04032

08032

Зарезервировано ISO/IEC [2]

ClientAddResourceResponse

04033

08033

Зарезервировано ISO/IEC [2]

Зарезервировано ISO/IEC [2]

04034-0403f

08034-0803f

Зарезервировано ISO/IEC [2]

Зарезервировано ISO/IEC [2]

04040

08040

ServerDeleteResourceRequest

Зарезервировано ISO/IEC [2]

04041

08041

ServerDeleteResourceConfirm

ClientDeleteResourceIndication

04042

08042

Зарезервировано ISO/IEC [2]

ClientDeleteResourceResponse

04043

08043

Зарезервировано ISO/IEC [2]

Зарезервировано ISO/IEC [2]

04044-0404f

08044-0804f

Зарезервировано ISO/IEC [2]

Зарезервировано ISO/IEC [2]

04050

08050

ServerContinuousFeedSession Request

Зарезервировано ISO/IEC [2]

04051

08051

ServerContinuousFeedSession Confirm

Зарезервировано ISO/IEC [2]

04052-0405f

08052-0805f

Зарезервировано ISO/IEC [2]

ClientStatusRequest

04060

08060

ServerStatusRequest

ClientStatusConfirm

04061

08061

ServerStatusConfirm

ClientStatusIndication

04062

08062

ServerStatusIndication

ClientStatusResponse

04063

08063

ServerStatusResponse

Зарезервировано ISO/IEC [2]

04064-0406f

08064-0806f

Зарезервировано ISO/IEC [2]

СlientResetRequest

04070

08070

ServerResetRequest

ClientResetConfirm

04071

08071

ServerResetConfirm

ClientResetIndication

04072

08072

ServerResetIndication

ClientResetResponse

04073

08073

ServerResetResponse

Зарезервировано ISO/IEC [2]

04074-0407f

08074-0807f

Зарезервировано ISO/IEC [2]

Зарезервировано ISO/IEC [2]

04080-04081

08080-08081

Зарезервировано ISO/IEC [2]

ClientSessionProceeding Indication

04082

08082

ServerSessionProceeding Indication

Зарезервировано ISO/IEC [2]

04083-0408f

08083-0808f

Зарезервировано ISO/IEC [2]

ClientConnectRequest

04090

08090

Зарезервировано ISO/IEC [2]

Зарезервировано ISO/IEC [2]

04091

08091

Зарезервировано ISO/IEC [2]

Зарезервировано ISO/IEC [2]

04092

08092

ServerConnectIndication

Зарезервировано ISO/IEC [2]

04093-0409f

08093-0809f

Зарезервировано ISO/IEC [2]

Зарезервировано ISO/IEC [2]

040a0

080a0

ServerSessionTransferRequest

Зарезервировано ISO/IEC [2]

040a1

080a1

ServerSessionTransferConfirm

ClientSessionTransferIndication

040a2

080a2

ServerSessionTransferIndication

ClientSessionTransferResponse

040a3

080a3

ServerSessionTransferResponse

Зарезервировано ISO/IEC [2]

040a4-040af

080a4-080af

Зарезервировано ISO/IEC [2]

ClientSessionInProgressRequest

040b0

080b0

ServerSessionInProgressRequest

Зарезервировано ISO/IEC [2]

040b1-040bf

080b1-080bf

Зарезервировано ISO/IEC [2]

Зарезервировано ISO/IEC [2]

040c0-05fff

080c0-09fff

Зарезервировано ISO/IEC [2]

Определяется пользователем

06000-07fff

0a000-0ffff

Определяется пользователем

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

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

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

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

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

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

Синтаксис

Число байтов

UserData() {

uuDataLength

for (i=0; i<uuDataLength; i++) {

2

uuDataByte

}

1

privateDataLength

for (i=0; i<privateDataLength; i++) {

2

privateDataByte

}

1

}

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

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

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

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

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

Синтаксис

Число байтов

Resources() {

resourceDescriptorCount

for (i=0;i<resourceDescriptorCount;i++) {

ResourceDescriptor()

}

2

}

Описания полей 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

Синтаксис

Число байтов

ClientSessionSetUpRequest() {

dsmccMessageHeader()

sessionId

10

reserved

2

clientId

20

serverId

UserData()

20

}

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

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

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

Синтаксис

Число байтов

ClientSessionSetUpConfirm() {

dsmccMessageHeader()

sessionId

10

response

2

serverId

Resources()

UserData()

20

}

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

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

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

Синтаксис

Число байтов

ServerSessionSetUpIndication() {

dsmccMessageHeader()

sessionId

10

reserved

2

clientId

20

serverId

20

forwardСount

for (i=0;i<forwardCount;i++) {

2

forwardServerId

}

UserData()

20

}

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

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

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

Синтаксис

Число байтов

ServerSessionSetUpResponse() {

dsmccMessageHeader()

sessionId

10

response

2

serverId

20

nextServerId

Resources()

UserData()

20

}

Д.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

Синтаксис

Число байтов

ClientSessionReleaseRequest() {

dsmccMessageHeader()

sessionId

10

reason

UserData()

2

}

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

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

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

Синтаксис

Число байтов

ClientSessionReleaseConfirm() {

dsmccMessageHeader()

sessionId

10

response

UserData()

2

}

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

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

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

Синтаксис

Число байтов

ClientSessionReleaseIndication() {

dsmccMessageHeader()

sessionId

10

reason

UserData()

2

}

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

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

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

Синтаксис

Число байтов

ClientSessionReleaseResponse() {

dsmccMessageHeader()

sessionId

10

response

UserData()

2

}

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

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

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

Синтаксис

Число байтов

ServerSessionReleaseRequest() {

dsmccMessageHeader()

sessionId

10

reason

UserData()

2

}

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

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

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

Синтаксис

Число байтов

ServerSessionReleaseConfirm() {

dsmccMessageHeader()

sessionId

10

response

UserData()

2

}

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

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

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

Синтаксис

Число байтов

ServerSessionReleaseIndication() {

dsmccMessageHeader()

sessionId

10

reason

UserData()

2

}

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

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

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

Синтаксис

Число байтов

ServerSessionReleaseResponse() {

dsmccMessageHeader()

sessionId

10

response

UserData()

2

}

Д.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

Синтаксис

Число байтов

ClientAddResourceIndication() {

dsmccMessageHeader()

sessionId

Resources()

UserData()

10

}

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

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

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

Синтаксис

Число байтов

ClientAddResourceResponse() {

dsmccMessageHeader()

sessionId

10

response

Resources()

UserData()

2

}

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

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

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

Синтаксис

Число байтов

ServerAddResourceRequest()

dsmccMessageHeader()

sessionId

Resources()

UserData()

10

}

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

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

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

Синтаксис

Число байтов

ServerAddResourceConfirm() {

dsmccMessageHeader()

sessionId

10

response

Resources()

UserData()

2

}

Д.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

Синтаксис

Число байтов

ClientDeleteResourceIndication() {

dsmccMessageHeader()

sessionId

10

reason

2

resourceCount

for (i=0;i<resourceCount;i++) {

2

resourceNum

}

UserData()

2

}

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

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

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

Синтаксис

Число байтов

ClientDeleteResourceResponse() {

dsmccMessageHeader()

sessionId

10

response

UserData()

2

}

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

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

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

Синтаксис

Число байтов

ServerDeleteResourceRequest() {

dsmccMessageHeader()

sessionId

10

reason

2

resourceCount

for (i=0;i<resourceCount;i++) {

2

resourceNum

}

UserData()

2

}

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

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

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

Синтаксис

Число байтов

ServerDeleteResourceConfirm() {

dsmccMessageHeader()

sessionId

10

Response

UserData()

2

}

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

- ServerContinuousFeedSessionRequest;

- ServerContinuousFeedSessionConfirm.

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

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

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

Синтаксис

Число байтов

ServerContinuousFeedSessionRequest() {

dsmccMessageHeader()

sessionId

10

reserved

2

serverId

Resources()

20

}

Описания полей в таблице Д.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

Синтаксис

Число байтов

ServerContinuousFeedSessionConfirm() {

dsmccMessageHeader()

sessionId

10

response

Resources()

2

}

Д.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

Синтаксис

Число байтов

ClientStatusRequest() {

dsmccMessageHeader()

reason

2

clientId

20

statusType

2

statusCount

for (i=0;i<statusCount;i++) {

2

statusByte

}

1

}

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

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

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

Синтаксис

Число байтов

ClientStatusConfirm() {

dsmccMessageHeader()

response

2

statusType

2

statusCount

for (i=0;i<statusCount;i++) {

2

statusByte

}

1

}

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

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

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

Синтаксис

Число байтов

ClientStatusIndication() {

dsmccMessageHeader()

reason

2

statusType

2

statusCount

for (i=0;i<statusCount;i++) {

2

statusByte

}

1

}

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

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

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

Синтаксис

Число байтов

ClientStatusResponse() {

dsmccMessageHeader()

response

2

statusType

2

statusCount

for (i=0;i<statusCount;i++) {

2

status Byte

}

1

}

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

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

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

Синтаксис

Число байтов

ServerStatusRequest() {

dsmccMessageHeader()

reason

2

serverId

20

statusType

2

statusCount

for (i=0;i<statusCount;i++) {

2

statusByte

}

1

}

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

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

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

Синтаксис

Число байтов

ServerStatusConfirm() {

dsmccMessageHeader()

response

2

statusType

2

statusCount

for (i=0;i<statusCount;i++) {

2

statusByte

}

1

}

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

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

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

Синтаксис

Число байтов

ServerStatusIndication() {

dsmccMessageHeader()

reason

2

statusType

2

statusCount

for (i=0;i<statusCount;i++) {

2

statusByte

}

1

}

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

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

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

Синтаксис

Число байтов

ServerStatusResponse() {

dsmccMessageHeader()

response

2

statusType

2

statusCount

for (i=0;i<statusCount;i++) {

2

statusByte

}

1

}

Д.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

Синтаксис

Число байтов

ClientResetRequest() {

dsmccMessageHeader()

clientId

20

reason

2

}

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

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

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

Синтаксис

Число байтов

ClientResetConfirm() {

dsmccMessageHeader()

clientId

20

Response

2

}

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

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

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

Синтаксис

Число байтов

ClientResetIndication() {

dsmccMessageHeader()

clientId

20

reason

2

}

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

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

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

Синтаксис

Число байтов

ClientResetResponse() {

dsmccMessageHeader()

clientId

20

response

2

}

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

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

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

Синтаксис

Число байтов

ServerResetRequest() {

dsmccMessageHeader()

serverId

20

reason

2

}

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

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

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

Синтаксис

Число байтов

ServerSessionResetConfirm() {

dsmccMessageHeader()

serverId

20

response

2

}

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

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

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

Синтаксис

Число байтов

ServerSessionResetIndication() {

dsmccMessageHeader()

serverId

20

reason

2

}

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

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

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

Синтаксис

Число байтов

ServerSessionResetResponse() {

dsmccMessageHeader()

serverId

20

response

2

}

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

- ClientSessionProceedingIndication;

- ServerSessionProceedingIndication.

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

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

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

Синтаксис

Число байтов

ClientSessionProceedingIndication() {

dsmccMessageHeader()

sessionId

10

reason

2

}

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

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

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

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

Синтаксис

Число байтов

ServerSessionProceedingIndication() {

dsmccMessageHeader()

sessionId

10

reason

2

}

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

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

- ClientConnectRequest;

- ServerConnectIndication.

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

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

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

Синтаксис

Число байтов

ClientConnectRequest() {

dsmccMessageHeader()

sessionId

UserData()

10

}

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

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

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

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

Синтаксис

Число байтов

ServerConnectIndication() {

dsmccMessageHeader()

sessionId

UserData()

10

}

Описания полей в таблице Д.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

Синтаксис

Число байтов

ClientSessionTransferIndication() {

dsmccMessageHeader()

sessionId

10

reserved

2

clientId

20

oldServerId

20

newServerId

Resources()

UserData()

20

}

Д.2.14.2 Сообщение ClientSessionTransferResponse передается от Клиента к Сети в ответ на сообщение ClientSessionTransferIndication.

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

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

Синтаксис

Число байтов

ClientSessionTransferResponse() {

dsmccMessageHeader()

sessionId

10

response

UserData()

2

}

Д.2.14.3 Сообщение ServerSessionTransferRequest передается от Сервера к Сети с запросом о передаче сеанса.

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

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

Синтаксис

Число байтов

ServerSessionTransferRequest() {

dsmccMessageHeader()

sessionId

10

reserved

2

destServerId

20

baseServerId

UserData()

20

}

Д.2.14.4 Сообщение ServerSessionTransferConfirm передается от Сети на Сервер в ответ на ServerSessionTransferRequest.

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

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

Синтаксис

Число байтов

ServerSessionTransferConfirm() {

dsmccMessageHeader()

sessionId

10

response

UserData()

2

}

Д.2.14.5 Сообщение ServerSessionTransferIndication передается от Сети на Сервер с целью указать, что эту передачу требуют на этот Сервер.

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

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

Синтаксис

Число байтов

ServerSessionTransferIndication() {

dsmccMessageHeader()

sessionId

10

reserved

2

clientId

20

srcServerId

20

baseServerId

Resources0

UserData()

20

}

Д.2.14.6 Сообщение ServerSessionTransferResponse передается от Сервера к Сети в ответ на ServerSessionTransferIndication.

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

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

Синтаксис

Число байтов

ServerSessionTransferResponse() {

dsmccMessageHeader()

sessionId

10

response

Resources()

UserData()

2

}

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

- ClientSessionInProgress;

- ServerSessionInProgress.

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

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

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

Синтаксис

Число байтов

ClientSessionInProgress() {

dsmccMessageHeader()

sessionCount

for (i=0;i<sessionCount;i++) {

2

sessionId

}

10

}

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

Д.2.15.2 Сообщение ServerSessionInProgress передается от Сервера к Сети периодически, чтобы сообщить Сети о сеансах, активных на Сервере.

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

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

Синтаксис

Число байтов

ServerSessionInProgress() {

dsmccMessageHeader()

sessionCount

for (i=0;i<sessionCount;i++) {

2

sessionId

}

10

}

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

Д.3 Характеристики Типов Поля Данных, используемых в Сообщении Сеанса П-С, представлены в таблице Д.58.

Таблица Д.58 - Характеристики Типов Поля Данных, используемых в Сообщении Сеанса П-С

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

Длина, байты

Область значений

Описание

BaseServerId

20

Специфицировано OSI NSAP

Глобально уникальный OSI NSAP адрес, идентифицирующий Сервер. Этот адрес должен быть специфичным

ClientId

20

Специфицировано OSI NSAP

Глобально уникальный OSI NSAP адрес, идентифицирующий Клиента. Этот адрес должен быть специфичным

DestServerId

20

Специфицировано OSI NSAP

Глобально уникальный OSI NSAP адрес, идентифицирующий Сервер. Этот адрес должен быть специфичным

DeviceId

6

0000000000000 - 03FFFFFFFFFFF

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

Для Сетей, использующих поле ATM B-HLI, второй старший значащий бит deviceId установлен на "1", чтобы указать, что последние три октета содержат deviceNum

ForwardCount

2

00000 - 0FFFF

Определяет номер для forwardServerId's, которые включены в сообщение

ForwardServerId

20

Специфицировано OSI NSAP

Глобально уникальный OSI NSAP адрес, идентифицирующий Сервер. Этот адрес должен быть специфичным

NewServerId

20

Специфицировано OSI NSAP

Глобально уникальный OSI NSAP адрес, идентифицирующий Сервер. Этот адрес должен быть специфичным

NextServerId

20

Специфицировано OSI NSAP

Глобально уникальный OSI NSAP адрес, идентифицирующий Сервер. Этот адрес должен быть специфичным

OldServerId

20

Специфицировано OSI NSAP

Глобально уникальный OSI NSAP адрес, идентифицирующий Сервер. Этот адрес должен быть специфичным

PrivateDataByte

privateDataCount

000 - 0FF

Частные данные, к которым в соответствии с [2] настоящим стандартом требования не предъявляются

PrivateDataCount

2

00000 - 0FFFF

Указывает номер для privateDataBytes, которые включены в сообщение

Reason

2

Перечисляемый

Определяет причину отказа

ResourceCount

2

00000 - 0FFFF

Содержит число дескрипторов ресурса, которые в сообщении следуют за полем resourceCount

ResourceNum

2

00000 - 0FFFF

Указывает специфичный дескриптор ресурса в пределах resource number assignor

Response

2

Перечисляемый

Указывает отклик на требуемое действие

SdbId

6

0000000 - 0ffffff

Сетевой уникальный идентификатор. Идентифицирует службу SDB. К процедуре назначения sdbId's оператором Сети в соответствии с [2] настоящий стандарт требования не предъявляет

ServerId

20

Специфицировано OSI NSAP

Глобально уникальный OSI NSAP адрес, идентифицирущий Сервер. ServerId должен быть специфичным

SessionCount

2

00000 - 0FFFF

Указывает номер для sessionId's, включенных в сообщение

SessionId

10

Композиция

Поле sessionId должно состоять из уникальных 6 байтов deviceId (байты 4-9) и 4-байтового номера сеанса (байты 0-3). SessionId может быть назначен или Пользователем, который инициирует запрос сеанса, или Сетью

SessionNum

4

000000000 - 0FFFFFFFF

Номер, который уникально идентифицирует сеанс на устройстве, которое назначает sessionId

StatusByte

statusCount

Переменная

Данные состояния, которые зависят от поля statusType

StatusCount

2

00000 - 0FFFF

Указывает число записей состояния, возвращающихся в отклике состояния

StatusType

2

Композиция

Указывает тип состояния, которое запрашивается или возвращается в транзакции состояния

UserId

20

Специфицировано OSI NSAP

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

UuDataByte

uuDataCount

000 - 0FF

Данные, требования к которым определены в части П-П

UuDataCount

2

00000 - 0FFFF

Указывает номер uuDataBytes, включенных в сообщение

Д.4 Значения Кодов Причины, используемые в соответствии с сообщениями сеанса П-С, представлены в таблице Д.59.

Таблица Д.59 - Коды Причины сообщения сеанса П-С

Причина

Значение

Описание

RsnOK

00000

Указывает, что последовательность команды - нормальный процесс

RsnNormal

00001

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

RsnClProcError

00002

Указывает, что состояние возникло из-за ошибки процедуры, обнаруженной у Клиента

RsnNeProcError

00003

Указывает, что состояние возникло из-за ошибки процедуры, обнаруженной в Сети

RsnSeProcError

00004

Указывает, что состояние возникло из-за ошибки процедуры, обнаруженной на Сервере

RsnClFormatError

00005

Указывает, что состояние возникло из-за недопустимого формата (например, пропущен параметр), обнаруженного у Клиента

RsnNeFormatError

00006

Указывает, что состояние возникло из-за недопустимого формата (например, пропущен параметр), обнаруженного в Сети

RsnSeFormatError

00007

Указывает, что состояние возникло из-за недопустимого формата (например, пропущен параметр), обнаруженного на Сервере

RsnNeConfigCnf

00008

Указывает, что это последовательность подтвержденной конфигурации (т.е. Клиент должен ответить)

RsnSeTranRefuse

00009

Указывает, что в передаче Сеанса отказал Сервер

RsnSeForwardOvl

0000A

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

RsnSeForwardMnt

0000B

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

RsnSeForwardUncond

0000C

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

RsnSeRejResource

0000D

Указывает, что Сервер отклонил назначенные ресурсы

RsnNeBroadcast

0000E

Указывает, что сообщение является сообщением вещания и не требует ответа

RsnSeServiceTransfer

0000F

Сервер указывает, что Клиент должен установить сеанс к другому serverId, основанному на контексте, обеспеченном в PrivateData()

RsnClNoSession

00010

Клиент указывает, что sessionId, приведенный в сообщении, неактивен

RsnSeNoSession

00011

Сервер указывает, что sessionId, приведенный в сообщении, неактивен

RsnNeNoSession

00012

Сеть указывает, что sessionId, приведенный в сообщении, неактивен

RsnRetrans

00013

Указывает, что сообщение ретранслируется

RsnNoTransaction

00014

Указывает, что сообщение было получено без transactionId

RsnClNoResource

00015

Указывает, что запрошенный ресурс не поддерживается

RsnClRejResource

00016

Указывает, что Клиент отклонил назначенные ресурсы

RsnNeRejResource

00017

Указывает, что Сеть отклонила ресурсы, назначенные Сервером

RsnNeTimerExpired

00018

Указывает, что сообщение посылается после окончания работы таймера

RsnClSessionRelease

00019

Указывает, что Клиент инициировал прекращение сеанса

RsnSeSessionRelease

0001A

Указывает, что Сервер инициировал прекращение сеанса

RsnNeSessionRelease

0001B

Указывает, что Сеть инициировала прекращение сеанса

Reserved

0001C - 07FFF

Зарезервировано ISO/IEC [2]

User Defined

08000 - 0FFFF

Коды причин определяются Пользователем

Д.5 Значения Кодов Ответа, используемые в соответствии с сообщениями сеанса П-С, представлены в таблице Д.60.

Таблица Д.60 - Коды Ответа сообщения сеанса П-С

Ответ

Значение

Описание

RspOK

00000

Указывает, что запрашиваемая команда завершена без ошибок

RspClNoSession

00001

Указывает, что Клиент отклонил запрос, поскольку запрашиваемый sessionId недопустим

RspNeNoCalls

00002

Указывает, что Сеть не способна принять новые сеансы

RspNeInvalidClient

00003

Указывает, что Сеть отклонила запрос из-за недопустимого clientId

RspNeInvalidServer

00004

Указывает, что Сеть отклонила запрос из-за недопустимого serverId

RspNeNoSession

00005

Указывает, что Сеть отклонила запрос, поскольку запрашиваемый sessionId недопустим

RspSeNoCalls

00006

Указывает, что Сервер не способен принять новые сеансы

RspSeInvalidClient

00007

Указывает, что Сервер отклонил запрос из-за недопустимого clientId

RspSeNoService

00008

Указывает, что Сервер отклонил запрос, так как запрашиваемый сервис не может быть обеспечен

RspSeNoCFS

00009

Указывает, что Сервер отклонил запрос, поскольку запрашиваемый сеанс непрерывной подачи не был обнаружен

RspClNoResponse

0000A

Указывает, что Сеть, установленная перед Клиентом, отвечала на сообщение Indication

RspSeNoResponse

0000B

Указывает, что Сеть, установленная перед Сервером, отвечала на сообщение Indication

Reserved

0000C - 0000F

Зарезервировано ISO/IEC [2]

RspSeNoSession

00010

Указывает, что Сервер отклонил запрос, так как запрашиваемый sessionId недопустим

RspNeResourceContinue

00011

Указывает, что запрос ресурса закончен без ошибок, но указанный ресурс был назначен Сетью дополнительно

RspNeResourceFailed

00012

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

RspNeResourceOK

00013

Указывает, что запрашиваемая команда завершена без ошибок

RspResourceNegotiate

00014

Указывает, что Сеть была способна завершить запрос, но задала дополнительные значения поля negotiable

RspClSessProceed

00015

Указывает, что Сеть ждет ответа от Сервера

RspClUnkRequestID

00016

Указывает, что Клиент принял сообщение, которое содержало неизвестный resourceRequestId

RspClNoResource

00017

Указывает, что Клиент отклонил установку сеанса, так как был не способен использовать назначенные ресурсы

RspClNoCalls

00018

Указывает, что Клиент отклонил установку сеанса, потому что не принял запрос

RspNeNoResource

00019

Указывает, что Сеть не способна назначить ресурсы на один или более сеанс

Reserved

0001A - 0001F

Зарезервировано ISO/IEC [2]

RspSeNoResource

00020

Указывает, что Сервер не способен завершить установку сеанса, поскольку требуемые ресурсы недоступны

RspSeRejResource

00021

Указывает, что Сервер отклонил назначенные ресурсы

RspClProcError

00022

Указывает, что состояние возникло из-за ошибки процедуры, обнаруженной у Клиента

RspNeProcError

00023

Указывает, что состояние возникло из-за ошибки процедуры, обнаруженной в Сети

RspSeProcError

00024

Указывает, что состояние возникло из-за ошибки процедуры, обнаруженной на Сервере

RspNeFormatError

00026

Указывает, что состояние возникло из-за недопустимого формата (например, пропущен параметр), обнаруженного в Сети

RspSeFormatError

00027

Указывает, что состояние возникло из-за недопустимого формата (например, отсутствует параметр), обнаруженного на Сервере

RspSeForwardOvl

00028

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

RspSeForwardMnt

00029

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

RspClRejResource

0002A

Указывает, что Клиент отклонил ресурс, назначенный для сеанса

Reserved

0002B - 0002F

Зарезервировано ISO/IEC [2]

RspSeForwardUncond

00030

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

RspNeTransferFailed

00031

Указывает, что передача сеанса в Сети не удалась

RspClTransferReject

00032

Указывает, что передача сеанса была отклонена Клиентом

RspSeTransferReject

00033

Указывает, что передача сеанса была отклонена Сервером

RspSeTransferResource

00034

Указывает, что Сервер отклонил сеанс из-за недостаточного ресурса

RspResourceCompleted

00035

Указывает, что Сервер принял ресурсы, назначенные Сетью

RspForward

00036

Указывает, что Сервер запрашивает переадресованный сеанс

RspNeForwardFailed

00037

Указывает, что Сеть не способна обработать переадресованный сеанс

RspClForwarded

00038

Указывает, что сеанс был переправлен указанному clientId

Reserved

00039 - 00040

Зарезервировано ISO/IEC [2]

RspSeTransferNoRes

00041

Передача Серверу была отклонена из-за того, что не могла получить достаточно ресурсов

RspNeNotOwner

00042

Акцию на сеанс требовал Пользователь, который не был владельцем этого сеанса

Reserved

00043 - 07FFF

Зарезервировано ISO/IEC [2]

User Defined

08000 - 0FFFF

Коды отклика определяются Пользователем

Д.6 Поле Тип Статуса (statusType) используется для индикации типа статуса, который запрашивается или сообщается в ответ на запрос.

Возможные значения запрашиваемого или возвращаемого поля Тип Статуса представлены в таблице Д.61.

В этой таблице resourceId является комбинацией sessionId и resourceNum, которые уникально идентифицируют дескриптор ресурса в пределах сеанса.

Таблица Д.61 - Значения statusType MPEG-2 DSM-CC

statusType

Описание

Требуемые поля для состояния Пользователя Request / Indication

Требуемые поля для состояния Пользователя Response / Confirm

00000

Зарезервировано ISO/IEC [1]

Не применяется

Не применяется

00001

Идентифицирует список сеанса. Это состояние указывает активные сеансы

Ни одно

sessionCount for (sessionCount)

{

sessionId

}

00002

Идентифицирует состояние сеанса. Указывает текущее состояние сеанса

sessionId

sessionId

response

userId

resourceCount for (resourceCount)

{

ResourceDescriptor()

}

00003

Идентифицирует Конфигурацию.

Указывает текущую конфигурацию

Ни одно

В соответствии с ISO/IEC [2] (раздел 6)

00004

Запрашивает дескриптор ресурса. Это сообщение состояния возвращает дескрипторы ресурса для требуемого resourceIDs

resourceIdCount for (resourceIdCount)

{

resourceId

}

resourceIdCount for (resourceIdCount)

{

sessionId, ResourceDescriptor()

}

00005

Запрашивает состояние ресурса. Это состояние возвращает состояние требуемого resourceIDs

resourceIdCount for (resourceIdCount)

{

resourceId

}

resourceIdCount for (resourceIdCount)

{

sessionId, resourceNum, resourcestatus

}

00006 - 07FFF

Зарезервировано ISO/IEC [2]

He применяется

He применяется

08000 - 0FFFF

statusType определяет Пользователь

Клиент

Клиент

Д.7 Дескрипторы ресурса содержат информацию, необходимую для Сети при распределении ресурса, контроле за распределенным ресурсом и освобождением ресурса (при его высвобождении).

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

Д.7.1 Общий формат Дескриптора Ресурса представлен в таблице Д.62.

Таблица Д.62 - Общий формат Дескриптора Ресурса

Синтаксис

Число байтов

dsmccResourceDescriptor {

He нормируется

commonDescriptorHeader()

He нормируется

resourceDescriptorDataFields()

He нормируется

}

Д.7.1.1 Поле commonDescriptorHeader должно использоваться при каждом определении дескриптора ресурса. Формат поля commonDescriptorHeader представлен в таблице Д.63.

Таблица Д.63 - Формат поля commonDescriptorHeader

Синтаксис

Число байтов

commonDescriptorHeader() {

resourceRequestId

2

resourceDescriptorType

2

resourceNum

2

associationTag

2

resourceFlags

1

resourceStatus

1

resourceDescriptorDataFieldsLength

2

resourceDataFieldCount

if(resourceDescriptorType == 0ffff) {

2

typeOwnerId

3

typeOwnerValue

3

}

}

Д.7.1.1.1 Поле resourceRequestId установлено пользователем для сопоставления ресурса, указанного в сообщении запроса, с результатом в подтверждающем сообщении.

Д.7.1.1.2 Поле resourceDescriptorType определяет затребованный ресурс.

Значения поля resourceDescriptorTypes для различных типов дескрипторов ресурса DSM-CC приведены в таблице Д.64.

Таблица Д.64 - Значения поля resourceDescriptorTypes для различных типов дескрипторов ресурса DSM-CC

Тип дескрипторов ресурса DSM-CC

Значение поля resource DescriptorTypes

Описание

Reserved

00000

Зарезервировано ISO/IEC [2]

ContinuousFeedSession

00001

Описывает ресурсы, уже распределенные в сеансе непрерывной подачи

AtmConnection

00002

Описывает ресурс соединения ATM PVC или предварительно выделенных SVC

MpegProgram

00003

Обеспечивает метод внеполосной доставки информации PMT системы MPEG-2

PhysicalChannel

00004

Указывает использование специфичного транспортного потока (например, каналы HFC)

TSUpstreamBandwidth

00005

Описывает полную пропускную способность восходящего потока, бит/с, необходимую для доставки данных сеанса от Клиента на Сервер

TSDownstreamBandwidth

00006

Описывает пропускную способность нисходящего потока, бит/с, необходимую для доставки данных сеанса от Сервера Клиенту

AtmSvcConnection

00007

Обеспечивает параметры SETUP ATM SVC. Используется, когда Сеть или Клиент ответствен за инициирование вызова

ConnectionNotify

00008

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

IP

00009

Запрашивается Сервером с целью указать, что обмен данными между Сервером и Клиентом будет происходить по протоколу IP

ClientTDMAAssignment

0000a

Посылается от Сети Клиенту, чтобы назначить слоты в канале TDMA восходящего потока сеанса

PSTNSetup

0000b

Предоставляет возможность Пользователю DSM-CC установить вызов PSTN

NISDNSetup

0000c

Предоставляет возможность Пользователю DSM-CC установить вызов N-ISDN

NISDNConnection

0000d

Описывает соединение N-ISDN и метки канала В, используемого в этом соединении

Q.922Connections

0000e

Позволяет одному или более каналу передачи данных быть мультиплексированными в одно соединение в соответствии с Рекомендацией ITU-T [5]

HeadEndList

0000f

Указывает список головных станций, которые должны быть связаны с Сеансом Непрерывной Подачи

AtmVcConnection

00010

Указывает VPI / VCI виртуального соединения ATM

SdbContinuousFeed

00011

Позволяет Серверу управления SDB идентифицировать загружаемые программы Серверу SDB и получить broadcastProgramId's

SdbAssociations

00012

Позволяет Серверу управления SDB установить теги объединения для управления SDB и каналами программ SDB и позволяет Сети идентифицировать ресурсы соединения для управления SDB и каналами программ SDB Клиента

SdbEntitlement

00013

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

Reserved

00014 - 07ffd

Зарезервировано ISO/IEC [2]

SharedResource

07ffe

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

SharedRequestId

07fff

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

UserDefined

08000 - 0fffe

Дескрипторы ресурса в этом диапазоне значений определяются Пользователем

TypeOwner

0ffff

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

Д.7.1.1.3 Поле resourceNum включает в себя уникальный номер и источник назначения resourceNum (назначен Сетью, Клиентом или Сервером).

На рисунке Д.2 показан формат поля resourceNumber.


Рисунок Д.2 - Формат поля resourceNumber

Субполе resourceNumVaIue уникально идентифицирует ресурс в пределах сеанса.

Субполе resourceNumberAssignor указывает объект, назначивший ресурс (Клиент, Сервер или Сеть). Значения субполя resourceNumberAssignor приведены в таблице Д.65.

Таблица Д.65 - Значения субполя resourceNumberAssignor П-С DSM-CC

Объект, назначивший ресурс

Значение субполя

Описание

Зарезервировано

00

Зарезервировано ISO/IEC [2]

Клиент

01

Resource number, назначенный Клиентом. Эта опция в настоящее время не предусмотрена ISO/IEC [2]

Сервер

10

Resource number, назначенный Сервером

Сеть

11

Resource number, назначенный Сетью

Д.7.1.1.4 Формат поля associationTag показан на рисунке Д.3.


Рисунок Д.3 - Формат поля associationTag

Субполе associationTagValue уникально идентифицирует тег объединения в пределах сеанса.

Субполе associationTagAssignor указывает объект, назначивший ресурс (Клиент, Сервер или Сеть). Значения субполя associationTagAssignor приведены в таблице Д.66.

Таблица Д.66 - Значения субполя associationTagAssignor П-С DSM-CC

Объект, назначивший ресурс

Значение

Описание

Зарезервировано

00

Зарезервировано ISO/IEC [2]

Клиент

01

Тег объединения, назначенный Клиентом. Эта опция в настоящее время не предусмотрена ISO/IEC [1]

Сервер

10

Тег объединения, назначенный Сервером

Сеть

11

Тег объединения, назначенный Сетью

Д.7.1.1.5 Поле resourceFlags содержит субполя:

- флага, определяющего объект, ответственный за распределение ресурса (resourceAllocator);

- согласования характеристик (атрибутов) ресурса (resourceAttribute);

- согласование вида предоставляемого ресурса (resourceView).

Формат поля resourceFlags показан на рисунке Д.4.


Рисунок Д.4 - Формат поля resourceFlags

Флаг resourceAllocator, устанавливаемый Сервером, указывает тот объект в сети, который ответствен за распределение ресурса и управление ресурсом. Возможные значения субполя resourceAllocator приведены в таблице Д.67.

Таблица Д.67 - Значения субполя resourceAllocator П-С DSM-CC

resourceAllocator

Значение субполя

Описание

Не установлено

00

Используется, когда создатель дескриптора ресурса не знает распределителя ресурса

Клиент

01

Ресурс, распределенный Клиентом

Сервер

10

Ресурс, распределенный Сервером

Сеть

11

Ресурс, распределенный Сетью

Субполе resourceAttribute определяет условия, при которых Сервер, Сеть или Клиент согласует характеристики (атрибуты) ресурса. Значения субполя resourceAttribute приведены в таблице Д.68.

Таблица Д.68 - Значения субполя resourceAttribute П-С DSM-CC

resourceAttribute

Значение субполя

Описание

Обязательный

Не согласовывается

0000

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

Обязательный

Согласовывается

0001

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

Необязательный

Не согласовывается

0010

Указывает, что Сеть должна удовлетворить требуемое значение точно или назначение ресурса не будет выполнено (не затрагивает состояние последовательности команды Resource Request)

Необязательный

Согласовывается

0011

Указывает, что Сеть может удовлетворить договорный диапазон значений точно или назначение ресурса не будет выполнено (не затрагивает состояние последовательности команды Resource Request). Если диапазон значений обеспечен, то может быть задано любое значение ресурса (условие don't care)

Зарезервировано

0100 - 1111

Зарезервировано ISO/IEC [2]

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

Отказ назначения ресурса как обязательного согласованного (Сеть не может предложить ресурс в пределах требуемого диапазона ресурсов) приведет к отказу от процедуры распределения ресурса.

Отказ от назначения ресурса как необязательного несогласованного не останавливает МРС от обработки других запросов ресурса в пределах того же самого AddResourceRequest сообщения.

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

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

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

Флаги resourceView определяют объект, представляющий дескриптор ресурса. Значения субполя resourceView и объекты, представляющие виды (планы) ресурса, приведены в таблице Д.69.

Таблица Д.69 - Значения субполя resourceView DSM-CC

План

Значение субполя

Описание

Зарезервировано

00

Зарезервировано ISO/IEC [2]

ClientView

01

Перечень ресурсов Клиента

ServerView

10

Перечень ресурсов Сервера

Зарезервировано

11

Зарезервировано ISO/IEC [2]

Перечень планов ресурса Клиента представлен ниже:

- ClientSessionSetUpConfirm;

- ClientAddResourceIndication;

- ClientAddResourceResponse;

- ClientDeleteResourceIndication;

- ClientStatusRequest;

- ClientStatusConfirm;

- ClientStatusIndication;

- ClientStatusResponse.

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

- ServerAddResourceRequest;

- ServerAddResourceConfirm;

- ServerDeleteResourceRequest;

- ServerStatusRequest;

- ServerStatusConfirm;

- ServerStatusIndication;

- ServerStatusResponse.

Д.7.1.1.6 Поле resourceStatus может иметь значения, приведенные в таблице Д.70.

Таблица Д.70 - Значения поля resourceStatus П-С DSM-CC

resourceStatus

Значение

Описание

Зарезервировано

000

Зарезервировано ISO/IEC [2]

Requested

001

Указывает, что ресурс затребован

InProgress

002

Указывает, что происходит распределение ресурса

AlternateAssigned

003

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

Assigned

004

Указывает, что было назначено точное значение ресурса

Failed

005

Указывает, что Сеть была не способна выделить ресурс, чтобы удовлетворить условия resourceAttribute

Unprocessed

006

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

Invalid

007

Указывает, что требуемый ресурс недопустим или неизвестен

Released

008

Указывает, что ресурс был выделен

Reserved

009 - 07F

Зарезервировано ISO/IEC [2]

User Defined

080 - 0FF

Частные данные

Д.7.1.1.7 Поле resourceDescriptorDataFieldsLength определяет полную длину секции resourceDescriptorDataFields, следующей за заголовком commonDescriptorHeader.

Значение поля resourceDescriptorDataFieldsLength зависит от специфического типа дескриптора resourceDescriptor и фактических данных дескриптора ресурса.

Д.7.1.1.8 Поле resourceDataFieldCount указывает общее число полей данных в дескрипторе ресурса.

Д.7.1.1.9 Поля typeOwnerId и typeOwnerVaIue определены, если только значение поля resourceDescriptorType установлено в 0ffff (см. Д.7.1.1.2).

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

Поле typeOwnerValue, как и поле resourceDescriptorType (см. Д.7.1.1.2) определяется владельцем typeOwnerId (OUI).

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

Атрибуты полей данных специфического дескриптора ресурсов resourceDescriptorType определены на рисунке Д.5.

Синтаксис

Кодирование

Переменная

Число байтов


Рисунок Д.5 - Атрибуты полей данных специфического дескриптора ресурсов resourceDescriptorType

Синтаксис определяет имя поля данных.

Кодирование определяет значение поля:

- единственное значение (s),

- определяется списком значений (I),

- определятся диапазоном значений (r).

Переменная (Variable) определяет:

- поле данных использует формат dsmccResourceDescriptorValue [значение "Да" (Yes)];

- поле данных использует простую строку байтов [значение "Нет" (No)].

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

Д.7.1.2 Формат поля resourceDescriptorDataFields представлен в таблице Д.71.

Таблица Д.71 - Формат поля resourceDescriptorDataFields П-С DSM-CC

Синтаксис

Число байтов

resourceDescriptorDataFields() {

for (i=0;i<resourceDataFieldCount;i++) {

if(Variable =='Yes') {

dsmccResourceDescriptorValue()

} else {

for (i=0;i<resourceLength;i++) {

resourceDataValueByte

1

}

}

}

}

Описания полей resourceDescriptorDataFields и resourceDataFieldCount приведены в ISO/IEC [2] (пункт 4.7.1).

Д.7.2 В тех случаях, когда поле данных дескриптора ресурса является переменным (см. рисунок Д.5), это поле должно кодироваться как формат dsmccResourceDescriptorValue() в соответствии с таблицей Д.72.

Если поле данных дескриптора ресурса не определено как переменное, то значение дескриптора ресурса не должно использовать формат dsmccResourceDescriptorValue ().

Таблица Д.72 - Формат поля dsmccResourceDescriptorValue()

Синтаксис

Число байтов

dsmccResourceDescriptorValue() {

resourceValueType

if (resourceValueType = singleValue) {

2

resourceValue()

}

else if (resourceValueType = listValue) {

resourceListCount

for (i=0;i<resourceListCount;i++) {

resourceValue()

}

2

}

else if (resourceValueType = rangeValue) {

mostDesiredRangeValue()

leastDesiredRangeValue()



}

}

Поле resourceValueType указывает формат затребованного значения. Это поле соответствует определению кодирования (см. рисунок Д.5).

Значения поля resourceValueType приведены в таблице Д.73.

Таблица Д.73 - Типы значений ресурсов DSM-CC (DSM-CC Resource Value Types)

resourceValueType

Кодирование

Значение

Описание

Reserved

00000

Зарезервировано ISO/IEC [2]

singleValue

s

00001

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

listValue

I

00002

Указывает, что требуемое значение содержит список возможных значений, которые примет инициатор запроса. В этом случае поле значения ресурса (resource value) будет содержать поле resourceValueCount и элементы resourceValueCount. Список значений должен быть упорядочен. Список должен начинаться элементом с наиболее предпочтительным значением и заканчиваться элементом с наименее предпочтительным значением

rangeValue

r

00003

Указывает, что требуемое значение содержит диапазон значений, которые примет инициатор запроса. В этом случае поле значения ресурса (resource value) будет содержать два элемента. Значение первого элемента должно быть наиболее предпочительным значением из диапазона допустимых значений. Значение второго элемента должно быть наименее предпочтительным из диапазона допустимых значений

Reserved

00004 - 07fff

Зарезервировано ISO/IEC [2]

User Defined

08000 - 0ffff

Типы значения ресурса в этом диапазоне определяются Пользователем

Описания полей, указанных в таблицах Д.72, Д.73, приведены в ISO/IEC [2] (пункт 4.7.2).

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

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

"Горизонтальная" ассоциация дескрипторов ресурса обеспечивает связь планов ресурсов одного Пользователя с появляющимися планами ресурсов другого Пользователя.

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

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

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

Сообщения тегов объединения ресурсов П-С перечислены ниже:

- ClientSessionSetUpConfirm;

- ClientAddResourceIndication;

- ClientAddResourceResponse;

- ClientDeleteResourceIndication;

- ClientStatusRequest;

- ClientStatusConfirm;

- ClientStatusIndication;

- ClientStatusResponse;

- ServerAddResourceRequest;

- ServerAddResourceConfirm;

- ServerDeleteResourceRequest;

- ServerStatusRequest;

- ServerStatusConfirm;

- ServerStatusIndication;

- ServerStatusResponse.

Д.7.4 В тех случаях, когда два или более ресурса идентифицируются одним дескриптором ресурса (например, в результате мультиплексирования транспортных потоков MPEG-2), эти ресурсы являются общедоступными.

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

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

Д.7.5 Дескрипторы ресурсов, перечисленные в Д.7.1.1.2, определены настоящим стандартом как дополнительные.

Это означает, что настоящий стандарт позволяет не применять ни один из перечисленных дескрипторов.

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

Детализация назначения дескрипторов, описания полей представлены в соответствии с ISO/IEC [2] (подпункты 4.7.5.1-4.7.5.21).

Форматы дескрипторов, перечисленных в Д.7.1.1.2, определены в соответствии с ISO/IEC [2] (таблицы 4-74 - 4-96).

Д.8 Последовательности команд, инициированных клиентом:

- последовательность команд установки сеанса;

- последовательности команд разъединения сеанса;

- последовательности команд статуса запроса.

Допускаются сеансы двух типов между Клиентом и Сервером.

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

Второй тип: Сервер может уведомить Клиентов, что сеанс непрерывной подачи был установлен:

- в транзитных сообщениях, согласно ISO/IEC [2] (раздел 12), в соответствии с приложением Н;

- в сообщениях режима П-П, согласно ISO/IEC [2] (раздел 5), в соответствии с приложением Е, - методом Карусели Данных, определенным в приложении И в соответствии с ISO/IEC [2] (раздел 7), или другими средствами, не предусмотренными настоящим стандартом согласно ISO/IEC [2].

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

Д.8.1 Сценарий последовательности сообщений при установке сеанса Клиента показан на рисунке Д.6.


Рисунок Д.6 - Сценарий последовательности сообщений при установке сеанса Клиента

Детализированное описание этапов передачи сообщений при установке сеанса Клиента - в соответствии с ISO/IEC [2] (подпункты 4.8.1.1-4.8.1.8).

Д.8.2 Сценарий последовательности выполнения команды разъединения сеанса, инициированного Клиентом, представлен на рисунке Д.7.


Рисунок Д.7 - Сценарий последовательности выполнения команды разъединения сеанса, инициированного Клиентом

Детализированное описание этапов передачи команд разъединения сеанса, инициированного Клиентом, - в соответствии с ISO/IEC [2] (подпункты 4.8.2.1-4.8.2.3).

Д.8.3 Последовательность команд состояния (статуса), инициированная Клиентом, должна быть в соответствии с ISO/IEC [2] (пункт 4.8.3).

Д.9 Последовательности команд, инициированных Сервером:

- последовательность команд настройки непрерывного сеанса подачи (Server Continuous Feed Session (CFS) Set-Up Command Sequence) - в соответствии с ISO/IEC [2] (пункт 4.9.1);

- последовательность команд дополнительных ресурсов сеанса - в соответствии с ISO/IEC [2] (пункт 4.9.2);

- последовательность команд удаления ресурса сеанса - в соответствии с ISO/IEC [2] (пункт 4.9.3);

- последовательность команд выполнения сеанса CFS - в соответствии с ISO/IEC [2] (пункт 4.9.4);

- последовательность команд разъединения сеанса - в соответствии с ISO/IEC [2] (пункт 4.9.5).

Д.9.1 Последовательность команд состояния (статуса) Сервера должна соответствовать установленной ISO/IEC [2] (пункт 4.9.6).

Д.9.2 Последовательность команд форвардинга сеанса Сервера должна соответствовать установленной ISO/IEC [2] (пункт 4.9.7).

Д.9.3 Последовательность команд переноса сеанса Сервера должна соответствовать установленной ISO/IEC [2] (пункт 4.9.8).

Д.9.4 Разъединение перемещенного сеанса должно быть выполнено в случаях и с последовательностью команд, указанных в ISO/IEC [2] (пункт 4.9.9).

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

- последовательность команд разъединения сеанса;

- последовательность команд прекращения подачи сеанса;

- последовательность команд запроса статуса Клиента;

- последовательность команд запроса статуса Сервера.

Выполнение перечисленных последовательностей команд должно быть в соответствии ISO/IEC [2] (пункты 4.10.1-4.10.4).

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

Эта процедура позволяет начать сброс одного или более сеанса одновременно.

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

Включение userId в сообщение сброса указывает, что все сеансы, связанные данным Пользователем, должны быть сброшены.

Причина сброса должна быть обозначена полем данных причины. Ниже перечислены допустимые случаи сброса:

- аномальная сигнализация, обнаруженная системой сигнализации DSM-CC, например из-за разрегулированности процедур состояния сеанса;

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

- запуск и рестарт Клиента, Сервера или МРС системой сигнализации DSM-CC с целью определить причину сбоя процесса запуска (допускается использовать только в экстраординарных ситуациях).

Выполнение команд процедуры сброса должно быть в соответствии с ISO/IEC [2] (пункт 4.11).

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

Интерфейсы Пользователь-Пользователь

Е.1 Среда Системы П-П определяется как Сеть Пользователей с изменяющимися характеристиками производительности.

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

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

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

- аппаратурные средства серверов;

- аппаратурные средства Клиентов;

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

В состав логических объектов Пользователей системы П-П входят следующие объекты:

- Выполнение Объекта Сервиса;

- Клиент, который определяется так же, как Приложение Клиента;

- Приложение;

- Ссылка Объекта;

- Стаб Библиотеки на стороне Клиента;

- Стаб Библиотеки на стороне Сервера;

- Шлюз Сервиса на стороне Сервера;

- Локальный Объект на стороне Клиента.

Структурная схема, иллюстрирующая среду системы П-П, представлена на рисунке Е.1.


Рисунок Е.1 - Структурная схема, иллюстрирующая среду системы П-П

Уточненное определение Среды Системы П-П - в соответствии с ISO/IEC [2] (пункты 5.2.1-5.2.6).

Е.2 Требования к Языку Определения Интерфейса (IDL) - в соответствии с ISO/IEC [2] (пункты 5.3.1-5.3.6).

Требования к Общим Определениям, в том числе к общим типам и константам, - в соответствии с ISO/IEC [2] (пункты 5.4.1-5.4.6).

Требования к Интерфейсам Мультисистемных Приложений, включая базовую и расширенную части, должны соответствовать установленным в ISO/IEC [2] (пункты 5.5.1-5.5.3).

Требования к интерфейсам интероперабельных сервисов (SII), включая базовую и расширенную части, и правила кодирования, необходимые для взаимодействия через сеть между Клиентом и объектами Сервиса, должны соответствовать установленным в ISO/IEC [2] (пункты 5.6.1-5.6.6).

Характеристики Процессов Загрузки Приложений, включающие в себя объединенные в рабочей модели системы: Прикладные Мультисистемные Интерфейсы, Протокол Сеанса П-С, Протокол Загрузки и Сервис интероперабельных интерфейсов - в соответствии с ISO/IEC [2] (пункты 5.7.1-5.7.4).

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

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

Ж.1 Формат дескрипторов совместимости представлен в таблице Ж.1.

Таблица Ж.1 - Формат дескрипторов совместимости compatibilityDescriptor

Синтаксис

Число байтов

compatibilityDescriptor() {

compatibilityDescriptorLength

2

descriptorCount

for (i=0; I < descriptorCount; i++) {

2

descriptorType

1

descriptorLength

1

specifierType

1

specifierData

3

model

2

version

2

subDescriptorCount

for (j = 0; j < subDescriptorCount; j++) {

subDescriptor()

}

1

}

}

subDescriptor() {

subDescriptorType

1

subDescriptorLength

for (k=0; k<subDescriptorLength; k++) {

1

}

additionalInformation

1

}

Ж.1.1 Поле compatibilityDescriptorLength определяет полную длину дескрипторов.

Ж.1.2 Поле descriptorCount указывает число дескрипторов, следующих за полем descriptorCount.

Ж.1.3 Поле descriptorType позволяет идентифицировать тип аппаратных средств или программного обеспечения, на который ссылается этот дескриптор. Значения поля типа дескриптора descriptorType указаны в таблице Ж.2.

Таблица Ж.2 - Значение поля типа дескриптора descriptorType (descriptorType field values)

Кодовое значение descriptorType

Описание

000

Дескриптор вставки

001

Дескриптор аппаратного обеспечения системы

002

Дескриптор программного обеспечения системы

003 - 03F

Зарезервировано ISO/IEC [2]

040 - 0FF

Определяется Пользователем

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

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

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

Ж.1.4 Поле descriptorLength указывает полную длину дескриптора без учета полей descriptorType и descriptorLength.

Ж.1.5 Спецификатор состоит из полей specifierType и specifierData.

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

Ж.1.5.1 Поле specifierType используется для определения поля формата specifierData. Значения поля типа спецификатора specifierType указаны в таблице Ж.3.

Таблица Ж.3 - Значение поля типа спецификатора specifierType

Кодовое значение поля specifierType

Описание спецификатора

000

Зарезервировано ISO/IEC [2]

001

IEEE OUI

002 - 07F

Зарезервировано ISO/IEC [2]

080 - 0FF

Определяется Пользователем

При использовании уникального идентификатора (OUI) специфицированного типа (specifierType) Организации IEEE поле specifierData должно включать в себя трехбайтовое значение IEEE OUI в соответствии с IEEE [8].

Формат поля specifierData представлен в таблице Ж.4.

Таблица Ж.4 - Формат поля specifierData при использовании IEEE OUI

Синтаксис

Число байтов

specifierData() {

org

}

3

Ж.1.5.2 Поле specifierData уникально идентифицирует организацию. Значение этого поля зависит от значения поля specifierType.

Ж.1.6 Семантика поля model определена организацией, идентифицированной спецификатором. Использование этого поля позволяет различить модели, определенные организацией. Обозначение l's указывает, что этот дескриптор обращается ко всем моделям.

Ж.1.7 Семантика поля version определена организацией, идентифицированной спецификатором. Использование этого поля позволяет различить версии модели, определенные организацией. Обозначение l's указывает, что этот дескриптор обращается ко всем версиям.

Ж.1.8 Поле subDescriptorCount указывает число субдескрипторов в дескрипторе. Субдескриптор содержит дополнительные дескрипторы, семантика которых определена организацией, идентифицированной спецификатором.

Ж.1.9 Поле SubDescriptorType определяет тип субдескриптора. Семантика этого поля определена организацией, идентифицированной спецификатором.

Ж.1.10 Поле SubDescriptorLength определяет полную длину всех полей additionalInformation, включенных в субдескриптор.

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

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

И.1 Сообщения загрузки П-С разделены на две категории: сообщения управления загрузки и сообщения загрузки данных.

И.1.1 Сообщения управления загрузки - типичные сообщения запроса-ответа, подобные другим сообщениям П-С.

К сообщениям управления загрузки относятся сообщения:

- DownloadInfoRequest,

- DownloadInfoResponse,

- DownloadInfoIndication,

- DownloadCancel,

- DownloadServerInitiate.

Использование заголовка сообщения управления загрузкой определено в приложении В.

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

И.2 Синтаксис сообщения управления загрузкой приведен в таблице И.1.

Таблица И.1 - Синтаксис сообщения управления загрузкой

Синтаксис

downloadControlMessage() {

dsmccMessageHeader()

controlMessagePayload()

}

dsmccMessageHeader используется в соответствии с приложением В.

controlMessagePayload используется в соответствии с ISO/IEC [2] (пункт 7.3).

И.3 Синтаксис сообщения загрузки данных является специфичным. Формат сообщения загрузки данных приведен в таблице И.2.

Таблица И.2 - Синтаксис сообщения загрузки данных

Синтаксис

downloadDataMessage() {

dsmccDownloadDataHeader()

dataMessagePayload()

}

dsmccDownloadDataHeader используется в соответствии с И.3.1 согласно ISO/IEC [2] (подпункт 7.2.2.1).

dataMessagePayload используется в соответствии с ISO/IEC [2] (пункт 7.3).

И.3.1 Сообщения загрузки данных начинаются с заголовка dsmccDownloadDataHeader.

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

Формат заголовка dsmccDownloadDataHeader приведен в таблице И.3.

Таблица И.3 - Формат заголовка dsmccDownloadDataHeader

Синтаксис

Число байтов

dsmccDownloadDataHeader() {

protocolDiscriminator

1

dsmccType

1

messageId

2

downloadId

4

reserved

1

adaptationLength

1

messageLength

for (adaptationLength>0) {

dsmccAdaptationHeader()

}

2

}

Поля protocolDiscriminator, dsmccType, messageId, downloadId, reserved, adaptationLength, messageLength и dsmccAdaptationHeader определены в соответствии с ISO/IEC [2] (подпункт 7.2.2.1).

И.3.2 Значения идентификатора сообщений загрузки messageId для сообщений загрузки данных приведены в таблице И.4. Значения идентификатора сообщений загрузки messageId применимы для всех сценариев загрузки, если не заявлено иначе.

Таблица И.4 - Значения идентификатора сообщений загрузки messageId для сообщений загрузки данных

Наименование сообщения загрузки данных

Значение идентификатора сообщений загрузки messageId

Описание

DownloadInfoRequest

01001

Клиент запрашивает параметры загрузки

DownloadInfoResponse, DownloadInfoIndication

01002

Сервер загрузки поставляет параметры загрузки

DownloadDataBlock

01003

Сервер загрузки посылает один блок данных загрузки

DownloadDataRequest

01004

Клиент подтверждает прием блоков данных

DownloadCancel

01005

Клиент или Сервер загрузки прерывают загрузку

DownloadServerInitiate

01006

Сервер загрузки просит Клиента инициировать загрузку

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

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

Сообщение DownloadInfoRequest должно быть использовано в режиме управляемого потока данных. Допускается использование этого сообщения в сценарии загрузки неуправляемого потока данных.

Сообщение DownloadInfoRequest не используется в сценарии Карусели Данных.

Формат сообщения DownloadInfoRequest приведен в таблице И.5.

Таблица И.5 - Формат сообщения DownloadInfoRequest

Синтаксис

Число байтов

DownloadInfoRequest() {

dsmccMessageHeader()

bufferSize

4

maximumBlockSize

compatibilityDescriptor()

2

privateDataLength

for (i=0;i<privateDataLength;i++) {

2

privateDataByte

}

1

}

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

Сервер загрузки выбирает размеры окна, которое должно быть не больше числа блоков, указанного в поле bufferSize (windowSize <= bufferSize / blockSize). Величина bufferSize должна быть не менее указанной в поле maximumBlockSize (bufferSize >= maximumBlockSize).

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

Дескриптор compatibilityDescriptor структурируют в соответствии с приложением Ж.

Поле рrivateDataLength определяет длину в байтах полей privateDataByte.

Данные поля privateDataByte, передаваемые от Клиента к Серверу загрузки, инвариантны (независимы) от передаваемой информации.

И.3.2.2 Сообщение DownloadInfoResponse должно быть использовано как ответ на сообщение Download InfoRequest.

Сообщение DownloadInfoIndication используется в случаях применения сценария Карусели Данных и сценария неуправляемого потока, когда сообщение DownloadInfoRequest не передается.

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

Форматы сообщений DownloadInfoResponse и DownIoadInfoIndication приведены в таблице И.6.

Таблица И.6 - Форматы сообщений DownloadInfoResponse и DownIoadInfoIndication

Синтаксис

Число байтов

DownloadInfoResponse(), DownIoadInfoIndication() {

dsmccMessageHeader()

downloadId

4

blockSize

2

windowSize

1

ackPeriod

1

tCDownloadWindow

4

tCDownloadScenario

4

compatibilityDescriptor()

numberOfModules

2

for (i=0;i< numberOfModules;i++) {

moduleId

2

moduleSize

4

moduleVersion

1

moduIeInfoLength

1

for (i=0;i< moduleInfoLength;i++) {

moduIeInfoByte

1

}

}

privateDataLength

2

for (i=0;i< privateDataLength;i++) {

privateDataByte

1

}

}

При передаче сообщений DownloadInfoIndication к Серверу загрузки поле transactionId в dsmccMessageHeader должно быть использовано как механизм управления версиями.

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

При изменениии поля сообщения DownloadInfoIndication увеличивается модуль поля transactionId.

Пояснения к форматам сообщений DownloadInfoResponse и DownIoadInfoIndication приведены в ISO/IEC [2] (пункт 7.3.2).

И.3.2.3 Сообщение DownloadDataBlock передается от Сервера Загрузки Клиенту.

Сообщение DownloadDataBlock используется во всех сценариях загрузки. Формат сообщения DownloadDataBlock представлен в таблице И.7.

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

Синтаксис

Число байтов

DownloadDataBlock() {

dsmccDownloadDataHeader()

moduleId

2

moduleVersion

1

reserved

1

blockNumber

for (i=0;i<N;i++) {

2

blockDataByte

}

1

}

Пояснения к формату сообщения DownloadDataBlock приведены в ISO/IEC [2] (пункт 7.3.3).

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

Сообщение DownloadDataRequest не используется в случае сценария неуправляемого потока или сценария Карусели Данных. Формат сообщения DownloadDataRequest представлен в таблице И.8.

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

Синтаксис

Число байтов

DownloadDataRequest() {

dsmccDownloadDataHeader()

moduleId

2

blockNumber

2

downloadReason

1

}

Пояснения к формату сообщения DownloadDataRequest приведены в ISO/IEC [2] (пункт 7.3.4). Коды поля downloadReason определены в ISO/IEC [2] (пункт 7.3.4, таблица 7-9).

И.3.2.5 Сообщение DownloadCancel передается или Клиентом, или Сервером загрузки для прерывания сценария загрузки. Передача этого сообщения подразумевает завершение полного сценария загрузки.

Сообщение DownloadCancel может быть использовано во всех сценариях загрузки.

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

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

Синтаксис

Число байтов

DownloadCancel() {

dsmccMessageHeader()

downloadId

4

moduleId

2

blockNumber

2

downloadCancelReason

1

reserved

1

privateDataLength

for (i=0;i<privateDataLength;i++) {

2

privateDataByte

}

1

}

Пояснения к формату сообщения DownloadCancel приведены в ISO/IEC [2] (пункт 7.3.5). Формат сообщения downloadCancelReason приведен в ISO/IEC [2] (пункт 7.3.5, таблица 7-11).

И.3.2.6 Сообщение DownloadServerInitiate передается от Сервера Загрузки Клиенту. В сценарии загрузки управляемого потока посылка сообщения DownloadInfoRequest - это запрос Клиенту о начале загрузки.

Сообщение DownloadServerInitiate может быть использовано в сценарии загрузки неуправляемым потоком и сценарии Карусели Данных для сообщения Клиенту о связи с сообщением DownloadInfoIndication.

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

Таблица И.10 - Формат сообщения DownloadServerInitiate

Синтаксис

Число байтов

DownloadServerInitiate() {

dsmccMessageHeader()

serverId

compatibilityDescriptor()

20

privateDataLength

for (i=0;i<privateDataLength;i++) {

2

privateDataByte

}

1

}

Пояснения к формату сообщения DownloadServerInitiate приведены в ISO/IEC [2] (пункт 7.3.6).

И.3.3 Последовательность обмена сообщениями для сценария загрузки управляемым потоком должна быть в соответствии с ISO/IEC [2] (пункты 7.4.1-7.4.6).

И.3.4 Последовательность обмена сообщениями для сценария загрузки Карусели Данных должна быть в соответствии с ISO/IEC [2] (пункты 7.5.1-7.5.5).

И.3.5 Последовательность обмена сообщениями для сценария загрузки неуправляемым потоком должна быть в соответствии с ISO/IEC [2] (пункты 7.6.1-7.6.3).

И.3.6 Механизм определения протоколов для сценария загрузки управляемым потоком (Protocol State Machines for flow-controlled download scenario) должен быть в соответствии с ISO/IEC [2] (пункт 7.7).

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

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

К.1 Дескриптор начала отсчета NPT обеспечивает определение NPT совокупности элементарных потоков, синхронизированных по времени. Время нормального воспроизведения (NPT) определяет непрерывную продолжительность события по шкале времени. Событие определяется ISO/IEC [3] как совокупность элементарных потоков с общей временной базой, связанных временем начала старта и временем окончания.

К.1.1 Формат дескриптора начала отсчета NPT представлен в таблице К.1.

Таблица К.1 - Формат дескриптора начала отсчета NPT

Синтаксис

Число байтов

Мнемоника

NPTReferenceDescriptor() {

descriptorTag

8

uimsbf

descriptorLength

8

uimsbf

postDiscontinuityIndicator

1

bsblf

contentld

7

uimsbf

reserved

7

bsblf

STC-Reference

33

uimsbf

reserved

31

bsblf

NPT-Reference

33

tcimsbf

scaleNumerator

16

tcimsbf

scaleDenominator

16

tcimsbf

}

Пояснения к формату дескриптора начала отсчета NPT приведены в ISO/IEC [2] (пункт 8.1.1).

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

Восстановленное значение NPT может быть использовано Клиентом для определения точки перехода в программе или как основание показа Пользователю.

Правила реконструкции NPT приведены в ISO/IEC [2] (пункт 8.1.2).

К.1.3 Единицей NPT является период частоты синхронизации системы (CFS), разделенный на 300. Выражение единицы NPT в секундах и микросекундах и обратное преобразование значения NPT из секунд и микросекунд должны быть выполнены в соответствии с ISO/IEC [2] [пункт 8.1.3, уравнения (8-5) - (8-7)].

К.1.4 Неопределенность при восстановлении NPT возникает в тех случаях, когда приемник не имеет информации, необходимой для правильного восстановления NPT. Для сокращения периодов неопределенности NPT период передачи в транспортном потоке дескрипторов начала отсчета NPT должен быть не более 1 с.

К.1.5 Дескриптор конечной точки NPT содержит информацию, разрешающую Клиенту поддержать NPT для определенного события. Формат дескриптора конечной точки NPT представлен в таблице К.2.

Таблица К.2 - Формат дескриптора конечной точки NPT

Синтаксис

Число байтов

Мнемоника

NPTEndpointDescriptor() {

descriptorTag

8

uimsbf

descriptor Length

8

uimsbf

reserved

15

bsblf

startNPT

33

uimsbf

reserved

31

bsblf

stopNPT

33

uimsbf

}

Поле descriptorTag устанавливается равным 24.

Описания полей descriptorLength, startNPT, stopNPT должны быть в соответствии с ISO/IEC [2] (пункт 8.1.5).

К.2 Дескриптор типа потока содержит информацию о состоянии потока, что позволяет Клиентам синхронизировать свои действия с изменениями параметров потока.

Формат дескриптора типа потока представлен в таблице К.3.

Таблица К.3 - Формат дескриптора типа потока

Синтаксис

Число байтов

Мнемоника

StreamModeDescriptor() {

descriptorTag

8

uimsbf

descriptorLength

8

uimsbf

streamMode

8

uimsbf

reserved

8

bsblf

}

Пояснения к формату дескриптора типа потока приведены в ISO/IEC [2] (пункт 8.3).

К.3 Дескриптор событий потока содержит информацию, позволяющую передачу прикладных специфичных событий, синхронных с транспортным потоком, согласно ISO/IEC [2] (раздел 5), в соответствии с приложением Е.

Определение события в этом контексте не соответствует событию, касающемуся NPT.

Формат дескрипторов событий потока приведен в таблице К.4.

Таблица К.4 - Формат дескрипторов события потока

Синтаксис

Число байтов

Мнемоника

StreamEventDescriptor () {

descriptorTag

8

uimsbf

descriptorLength

8

uimsbf

eventId

16

uimsbf

reserved

31

bsblf

eventNPT

for (i=0;i<N;i++) {

33

uimsbf

privateDataByte

}

8

uimsbf

}

Пояснения к полям формата дескриптора событий потока приведены в ISO/IEC [2] (пункт 8.4).

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

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

Л.1 Каждое сообщение протокола выбора каналов цифрового вещания идентифицировано определенным messageId, который указывает класс и направление сообщения. Перечень сообщений конфигурации SDB CCP приведен в таблице Л.1.

Таблица Л.1 - Перечень сообщений конфигурации SDB CCP

messageId

Наименование сообщения

Описание

00000

Зарезервировано

00001

SDBProgramSelectRequest

От пользователя к Серверу SDB. Запрос вещательной программы

00002

SDBProgramSelectConfirm

От Сервера SDB к Пользователю. Отклик на сообщение SDBProgramSelectRequest

00003

SDBProgramSelectIndication

От Сервера SDB к Пользователю. Сообщение о новой вещательной программе

00004

SDBProgramSelectResponse

От Пользователя к Серверу SDB. Отклик на сообщение SDBProgramSelectIndication

00005 - 07FFF

Зарезервировано

Зарезервировано ISO/IEC [2]

08000 - 0FFFF

Определяется пользователем

Сообщение SDB, определенное Пользователем

Л.1.1 Передача частных данных поддерживается в сообщениях SDB CCP.

В таблице Л.2 представлен формат сообщений PrivateData (), передаваемых в сообщениях SDB.

Таблица Л.2 - Формат частных данных DSM-CC SDB

Синтаксис

Число байтов

PrivateData() {

privateDataLength

for (i=0;i<privateDataLength;i++) {

2

privateDataByte

}

1

}

Поле privateDataLength указывает общее число privateDataBytes.

Поле privateDataByte содержит частные данные. Формат и применение этих данных настоящим стандартом не определяются.

Л.1.2 В сообщениях SDBProgramSelect поле идентификатора вещательной программы используется для опознавания отдельной вещательной программы. Значения поля broadcastProgramId определены в таблице Л.3.

Таблица Л.3 - Значения поля идентификатора вещательной программы

broadcastProgramId

Наименование вещательной программы

Описание

000000000

Нет программы

Вещательная программа не была идентифицирована

000000001 - 07FFFFFFF

Номера вещательных программ

Уникальный идентификатор отдельной вещательной программы

080000000 - 0FFFFFFFF

Определяется пользователем

Определение пользователем специального назначения broadcastProgramId

Л.1.3 Все сообщения SDB CCP содержат поле sessionId. В случае если сеанс П-С был установлен в динамическом режиме с использованием набора заданных значений Сеанса П-С, это поле должно кодироваться с использованием тех же самых значений в соответствии с договоренностью, достигнутой во время SessionSetup.

Если сеанс был установлен в статическом режиме посредством инициализации (provisioning), то кодирование этого поля должно быть взаимно согласовано между Клиентом и Сервером.

Л.1.3.1 Сообщение SDBProgramSelectRequest посылают от Клиента Серверу SDB для запроса установки выбранной программы вещания.

SDB Сервер должен ответить Клиенту сообщением SDBProgramSelectConfirm.

Формат сообщения SDBProgramSelectRequest приведен в таблице Л.4.

Таблица Л.4 - Формат сообщения SDBProgramSelectRequest

Синтаксис

Число байтов

SDBProgramSelectRequest() {

sessionId

10

reserved

2

broadcastProgramId

4

PrivateData()

}

Поле sessionId используется для идентификации сеанса всюду во время его существования.

Поле reserved зарезервировано ISO/IEC [2], устанавливается в 0FFFF.

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

Структура PrivateData определена в таблице Л.2. Содержание этого поля настоящий стандарт не устанавливает.

Л.1.3.2 Сообщение SDBProgramSelectConfirm посылают от Сервера SDB Клиенту в ответ на сообщение SDBProgramSelectRequest.

Формат сообщения SDBProgramSelectConfirm приведен в таблице Л.5.

Таблица Л.5 - Формат сообщения SDBProgramSelectConfirm

Синтаксис

Число байтов

SDBProgramSelectConfirm() {

sessionId

10

response

2

broadcastProgramId

PrivateData()

4

}

Поле sessionId используется для идентификации сеанса во время его существования.

Поле response должно быть установлено Сервером SDB в соответствии со значением, которое было указано в ответе Сервера SDB на сообщение SDBProgramSelectRequest. Допустимые значения для кодирования этого поля приведены в таблице Л.9 Кодов Ответа SDB DSM-CC.

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

Структура поля PrivateData определена в таблице Л.2. Содержание этого поля настоящий стандарт не устанавливает.

Л.1.3.3 Сообщение SDBProgramSelectIndication посылают от Сервера SDB Клиенту с целью указать, что новая программа вещания доставляется.

Клиент должен ответить сообщением SDBProgramSelectResponse.

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

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

Синтаксис

Число байтов

SDBProgramSelectIndication() {

sessionId

10

reason

2

broadcastProgramId

PrivateData()

4

}

Поле sessionId используется для идентификации сеанса во время его существования.

Поле reason должно быть установлено Сервером SDB в соответствии со значением, которое указывает причину выбора Сервером SDB. Допустимые значения для кодирования этого поля приведены таблице Л.8 Кодов Причины SDB DSM-CC.

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

Структура поля PrivateData определена в таблице Л.2. Содержание этого поля настоящий стандарт не устанавливает.

Л.1.3.4 Сообщение SDBProgramSelectResponse посылают от Клиента Серверу SDB в ответ на сообщение SDBProgramSelectIndication. Формат сообщения SDBProgramSelectResponse приведен в таблице Л.7.

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

Синтаксис

Число байтов

SDBProgramSelectResponse() {

sessionId

10

response

2

PrivateData()

}

Поле sessionId используется для идентификации сеанса во время его существования.

В поле response Клиентом должно быть установлено значение, которое указано в ответе Клиента в сообщении SDBProgramSelectRequest. Допустимые значения для кодирования этого поля приведены в таблице Л.9 Кодов Ответа SDB DSM-CC.

Структура поля PrivateData определена в таблице Л.2. Содержание этого поля настоящий стандарт не устанавливает.

Л.2 Последовательность Команд Выбора Программы, инициированной Клиентом, иллюстрируется сценарием, показанным на рисунке Л.1.


Рисунок Л.1 - Сценарий Последовательности Команд Выбора Программы, инициированной Клиентом

Детализированное описание шагов выпонения сценария представлено в ISO/IEC [2] (пункт 10.3.1).

Л.3 Последовательность Команд Выбора Программы, инициированного Сервером SDB, иллюстрируется cценарием, показанным на рисунке Л.2.


Рисунок Л.2 - Сценарий Последовательности Команд Выбора Программы, инициированного Сервером SDB

Детализированное описание этапов выполнения сценария представлено в ISO/IEC [2] (пункт 10.3.2).

Л.4 Список и значения Кодов Причины, используемых в протоколе обмена каналов SDB, приведены в таблице Л.8.

Таблица Л.8 - Список и значения Кодов Причины SDB DSM-CC

Reason Code

Значение

Описание

rspOk

00000

Указывает, что вещательная программа была начата как нормальное действие [например, плати и смотри]

rsnNormal

00001

Указывает, что вещательная программа была прекращена из-за освобождения сеанса

rsnSeEntitlementFailure

00002

Указывает, что вещательная программа была прекращена из-за отказа в праве

reserved

00003 - 07FFF

Зарезервировано ISO/IEC [2]

prtvate use

08000 - 0FFFF

Для частного использования

Л.5 Список и значения Кодов Ответа, используемых в протоколе выбора каналов SDB, приведены в таблице Л.9.

Таблица Л.9 - Список и значения Кодов Ответа SDB DSM-CC

Response Code

Значение

Описание

rspOk

00000

Указывает положительное подтверждение

rspFormatError

00001

Указывает, что применен недопустимый формат (например, пропущен параметр)

rspNoSession

00002

Указывает, что или Клиент, или Сервер отклоняет команду SDBProgramSelect, поскольку данный сеанс не установлен

rspNoNetworkResource

00003

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

rspNoServerResource

00004

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

rspEntitlementFailure

00005

Указывает, что вещательную программу невозможно доcтавить Клиенту из-за отсутствия его права на это

rspBcProgramOutOfService

00006

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

rspRedirect

00007

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

Reserved

00008 - 07FFF

Зарезервировано ISO/IEC [2]

prtvate use

08000 - 0FFFF

Для частного использования

Л.6 Каждый сеанс Сервиса SDB требует определенного Состояния Механизма (State Machine) Клиента и Сервера SDB.

Л.6.1 Состояния Механизма на стороне Клиента для SDB определены в таблице Л.10.

Таблица Л.10 - Состояния Механизма на стороне Клиента для SDB

Состояния Механизма на стороне Клиента для SDB

Описание

Cidle

Сеанс сервиса SDB не установлен

CprogramInactive

Сеанс сервиса SDB установлен, но программа вещания не ожидается

CprogramActive

Сеанс сервиса SDB установлен. Программа вещания ожидается

CprogramRequest

Клиент затребовал программу вещания и ждет подтверждения от Сервера SDB

Возможные Состояния событий для стороны Клиента должны соответствовать установленным в ISO/IEC [2] (рисунок 10-3).

События на стороне Клиента для Состояний Механизма сервиса SDB подразделяются на "внутренние" и "внешние". Пояснения к Событиям должны быть в соответствии с ISO/IEC [2] (пункт 10.5.1).

Л.6.2 Состояния Механизма на стороне Сервера SDB определены в таблице Л.11.

Таблица Л.11 - Состояния Механизма на стороне Сервера SDB

Состояния Механизма на стороне Сервера SDB

Описание

Sidle

Сеанс сервиса SDB не установлен

SprogramInactive

Сеанс сервиса SDB установлен, но программа вещания не обеспечивается

SprogramActive

Сеанс сервиса SDB установлен, но программа вещания ожидается

SprogramIndication

Сервер SDB просил Клиента переключиться на новую программу вещания и ждет подтверждения от Клиента

Возможные Состояния событий для стороны Сервера должны соответствовать установленным в ISO/IEC [2] (рисунок 10-4).

События на стороне Сервера для Состояний Механизма сервиса SDB подразделяются на "внутренние" и "внешние". Пояснения к Событиям должны быть в соответствии с ISO/IEC [2] (пункт 10.5.1).

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

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

М.1 Домен сервиса и шлюз Сервиса

М.1.1 Каждая реализация Карусели Объектов П-П представляет домен сервиса.

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

Адрес NSAP Карусели является идентификатором, совместимым с NSAP, согласно Рекомендации ITU-T [9], serverIds, с сообщениями сеанса П-С, описанными в приложении Д, и с интерфейсами П-П, описанными в приложении Е.

Протокол Карусели Объектов П-П определяет синтаксис этого идентификатора. Идентификатор включает в себя:

- поле идентификатора полномочий администрации и формата (АFI), 1 байт;

- поле Type, l байт;

- поле carouselId, 4 байта;

- поле спецификатора (specifier), 4 байта;

- поле частных данных (privateData), 10 байтов.

Формат адреса NSAP Карусели должен быть в соответствии с рисунком М.1.

AFI

1 байт

Type

1 байт

carouselld

4 байта

specifier

4 байта

privateData

10 байтов


Рисунок М.1 - Формат адреса NSAP Карусели

Описания полей адреса NSAP Карусели AFI, Type, carouselId, specifier, privateData должны быть в соответствии с ISO/IEC [2] (пункт 11.2.2).

М.1.2 Протокол BIOP использует интероперабельные ссылки объекта (IOR), формат которых определен CORBA.

Интероперабельные ссылки объекта IOR, который постоянно находится в Карусели Объектов П-П, содержат обязательные компоненты LiteComponents BIOP::ObjectLocation и DSM::ConnBinder. Компонент LiteComponents - в соответствии с ISO/IEC [2] (раздел 5).

М.1.3 Сообщения протокола BIOP транспортируются в модулях Карусели Данных. Допускается передача многократных сообщений в составе одного модуля. Модули Карусели Данных фрагментируются в блоки. Эти блоки транспортируются в сообщениях DownloadDataBlock. Формат сообщения DownloadDataBlock должен быть в соответствии с И.7 (приложение И). Схема инкапсуляции и фрагментации сообщений протокола BIOP в модули показана на рисунке М.2.


Рисунок М.2 - Схема инкапсуляции и фрагментации сообщений протокола BIOP в модули

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

Параметры модулей включают в себя обозначения:

- размера и версии модуля;

- прикладного размера блока;

- величин блокировки времени (time-out).

Кроме того, сообщение DownloadInfoIndication () содержит информацию об ответвлении.

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

М.1.5 Сетенезависимость протокола BIOP обеспечивается применением понятия Tap в соответствии с определением в ISO/IEC [2] (раздел 5).

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

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

-TapUse BIOP-DELIVERY-PARA-USE;

-BIOP-OBJECT-USE;

-BIOP-PROGRAM-USE, BIOP-ES-USE;

- STR-STATUS-AND-EVENT-USE; STR-EVENT-USE;

- STR-STATUS-USE;

- NPT-USE;

- DOWNLOAD-CTRL-DOWN-USE, DOWNLOAD-DATA-DOWN-USE.

TapUse определены в ISO/IEC [2] (раздел 5).

М.2 Протокол вещания внутри ORB

М.2.1 Протокол BIOP использует формат Inter-operable Object Reference (IOR), определенный CORBA в соответствии с ISO/IEC [2].

Ссылка IOR содержит тела профиля, в которые инкапсулирована вся информация, необходимая для идентификации объекта.

Отдельное тело профиля содержит необходимое количество информации для управления объектом при использовании протокола BIOP.

Синтаксис ссылки IOR, согласно ISO/IEC [2] (раздел 5), - в соответствии с приложением Е.

Параметры компонента местоположение объекта и компонента ConnBinder должны быть в соответствии с ISO/IEC [2] (подпункт 11.3.1.1).

М.2.2 Протокол BIOP в сообщениях передает объектам П-П каталоги, файлы, потоки и ServiceGateway.

Сообщения BIOP получены из сообщения общего формата объекта. Протокол ВI0Р определяет следующие сообщения:

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

- сообщение файла, используемое для передачи объекту П-П типа файла;

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

- сообщение ServiceGateway, используемое для передачи объекту П-П типа ServiceGateway.

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

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

Синтаксис и семантика общего формата сообщения объекта определены в таблице М.1.

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

Синтаксис и семантика

module BIOP {

typedef unsigned long ServiceID;

struct ServiceContext {

ServiceID

сontext_id;

sequence<octet,65535>

сontext_data;

};

struct MessageHeader

{

char

magic;

Version

biop_version;

boolean

byte_order;

octet

message_type;

unsigned long

message_size;

};

Struct MessageSubHeader {

sequence<octet,255>

objectKey;

sequence<octet>

objectKind;

sequence<octet,65535>

objectInfo;

sequence<ServiceContext,255>

serviceContextList;

};

//

struct GenericObjectMessage {

MessageHeader

messageHeader;

MessageSubHeader

messageSubHeader;

sequence<octet>

messageBody;

};

};

Пояснения к полям таблицы приведены в ISO/IEC [2] (подпункт 11.3.2.1).

М.2.2.2 Сообщение каталога протокола BIOP является реализацией формата сообщения объекта со следующими изменениями:

- поле objectKind содержит строку "DSM::Directory" или "dir";

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

- поле messageBody содержит структуру тела сообщения каталога (BIOP::DirectoryMessageBody).

Синтаксис и семантика ::DirectoryMessageBody протокола BIOP приведены в таблице М.2.

Таблица М.2 - Синтаксис и семантика ::DirectoryMessageBody протокола BIOP

Синтаксис и семантика

Module BIOP {

typedef string<255> Istring;

struct NameComponent {

Istring id;

Istring kind;

};

//

typedef sequence<NameComponent,255> Name;

typedef octet BindingType;

const BindingType nobject = 1;

const BindingType ncontext = 2;

const BindingType composite = 3;

//

struct Binding {

Name

bindingName;

octet

bindingType;

IOP::IOR

objectRef;

sequence<octet,65535>

objectInfo;

};

typedef sequence<Binding,65535> DirectoryMessageBody};

};

Пояснения к полям таблицы М.2 приведены в ISO/IEC [2] (подпункт 11.3.2.2).

М.2.2.3 Сообщение файла протокола BIOP является реализацией общего формата сообщения объекта со следующими изменениями:

- поле objectKind содержит строку "DSM::File" или "fil";

- атрибуты доступа (Access attributes) и атрибут контента файла (DSM::File::Content attribute) не инкапсулированы в поле objectInfo сообщения файла или директории; атрибут размера контента файла (DSM::File::ContentSize attribute) вставлен в начало поля objectInfo сообщения файла или директории;

- поле messageBody содержит структуру тела сообщения файла (BIOP::FileMessageBody).

Синтаксис и семантика ::FileMessageBody протокола BIOP приведены в таблице М.3.

Таблица М.3 - Синтаксис и семантика BIOP::FileMessageBody протокола BIOP

Синтаксис и семантика

module BIOP {



};

typedef

sequence <octet>

FileMessageBody;

Пояснения к FileMessageBody приведены в ISO/IEC [2] (подпункт 11.3.2.3).

М.2.2.4 Сообщение потока BIOP является реализацией общего формата сообщения объекта со следующими изменениями:

- поле objectKind содержит строку "DSM::Stream" или "str";

- атрибуты доступа не инкапсулированы в поле objectInfo сообщения файла или директории; атрибут информации потока (DSM::Stream::Info-T attribute) вставлен в начало поля objectInfo сообщения файла;

- поле messageBody содержит структуру тела сообщения потока (BIOP::StreamMessageBody).

Синтаксис и семантика протокола BIOP::StreamMessageBody представлены в таблице М.4.

Таблица М.4 - Синтаксис и семантика::StreamMessageBody протокола BIOP

Синтаксис и семантика

module BIOP {

struct StreamMessageBody {



};

sequence <Tap,255>

stream;

};

Пояснения к полям таблицы М.4 - в соответствии с ISO/IEC [2] (подпункт 11.3.2.4).

М.2.2.5 Сообщение шлюза сервиса BIOP является реализацией общего формата объекта.

Следующие правила определяют эту реализацию:

- поле objectKind содержит строку "DSM::ServiceGateway" или "srg";

- атрибуты доступа (Access attributes) не инкапсулированы в поле objectInfo сообщения службы шлюза;

- поле messageBody содержит структуру тела сообщения директории (BIOP::DirectoryMessageBody).

М.2.3 Определения транспорта

М.2.3.1 Сообщения BIOP транспортируются в модулях Карусели Данных DSM-CC. Модули могут передать многократные нефрагментированные сообщения BIOP. Начало сообщения BIOP должно совпадать с началом модуля. Модули Карусели Данных фрагментированы в блоки. Эти блоки транспортируются в сообщениях DownloadDataBlock (). Семантика и ограничения, наложенные на транспорт блоков в сообщениях DownloadDataBlock (), должны быть в соответствии с ISO/IEC [2] (подпункт 11.3.3.1).

М.2.3.2 Параметры доставки модуля в сети вещания должны передаваться в сообщении DownloadInfoIndication ().

В одном сообщении DownloadInfoIndication () допускается передача параметров доставки многократных модулей той же самой Карусели Объекта П-П.

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

М.2.3.3 Шлюз сервиса ссылок IOR обеспечивает вещание с использованием сообщения DownloadServerInitiate ().

Семантика поля сообщения DownloadServerInitiate () должна быть в соответствии с ISO/IEC [2] (подпункт 11.3.3.3).

М.3 Дескрипторы MPEG-2

М.3.1 При использовании Карусели Объектов П-П в сетях вещания с транспортными потоками MPEG-2 не обеспечивается поддержка сеанса П-С ассоциации DSM-CC. В этом случае необходимо использовать дополнительно три дескриптора Карусели Объектов П-П, определенных в таблице 3 настоящего стандарта descriptor_tag стандарта MPEG-2. В таблице 3 определены назначения дескрипторов descriptor_tag DSM-CC, типы потоков и типы секций DSM-CC.

М.3.2 Дескриптор идентификатора Карусели carousel_identifier_descriptor() способствует формированию ассоциации между программой MPEG-2 и Каруселью Объектов П-П. Дескриптор carousel_identifier_descriptor() размещается в пределах таблицы состава программы PMT MPEG-2.

Синтаксис и семантика дескриптора идентификатора Карусели carousel-identifier-descriptor0* описаны в таблице М.5.

________________

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

Таблица М.5 - Синтаксис и семантика дескриптора идентификатора Карусели carousel-identifier-descriptor()

Синтаксис

Число битов

Мнемоника

carousel_identifier_descriptor() {

descriptor_tag

8

uimsbf

descriptor_length

8

uimsbf

carousel_id

for (n=0;n<N;n++){

32

uimsbf

private_data_byte

}

8

uimsbf

}

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

М.3.3 Дескриптор тега объединения облегчает ассоциацию между тегом объединения и PSI элементарного потока MPEG-2. В случае Карусели П-П применение дескипртора тега ассоциации позволяет идентифицировать потоки, в которых транспортируются данные загрузки (например, ServiceGateway). Синтаксис и семантика дескриптора тега ассоциации association_tag_descriptor описаны в таблице М.6.

Таблица М.6 - Синтаксис и семантика дескриптора тега объединения association_tag_descriptor

Синтаксис

Число битов

Мнемоника

association_tag_descriptor() {

descriptor_tag

8

uimsbf

descriptor_length

8

uimsbf

association_tag

16

uimsbf

use

16

uimsbf

selector_byte_length

for (n=0;n<N1;n++) {

8

uimsbf

selector_byte

}

for (n=0;n<N2;n++) {

8

uimsbf

private_data_byte

}

8

uimsbf

}

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

М.3.4 Карусель Объектов П-П может использовать многократные элементарные потоки (отсюда многократные идентификаторы PID), программы и транспортные потоки для вещания объектов и ассоциированной информации управления.

Дескриптор задержанных тегов объединения deferred_assocation_tags_descriptor() содержит все теги объединения, используемые в пределах Карусели Объектов П-П.

Дескриптор задержанных тегов объединения deferred_association_tags_descriptor() содержит ссылку на программу MPEG-2, которая имеет идентификатор PID, связанный с тегом объединения.

Многократный deferred_assocation_tags_descriptor()'s, при необходимости, может быть вставлен в PMT.

Синтаксис и семантика дескриптора задержанных тегов объединения deferred_association_tags_descriptor() описаны в таблице М.7.

Таблица М.7 - Синтаксис и семантика дескриптора задержанных тегов объединения deferred_association_tags_descriptor

Синтаксис

Число битов

Мнемоника

deferred_association_tags_descriptor() {

descriptor_tag

8

uimsbf

descriptor_length

8

uimsbf

association_tags_loop_length

for (n=0;n<N1;n++){

8

uimsbf

association_tag

}

16

uimsbf

transport_stream_id

16

uimsbf

program_number

for (n=0;n<N2;n++){

16

uimsbf

private_data_byte

}

8

uimsbf

}

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

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

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

Н.1 Перечень транзитных (Pass-Thru) сообщений приведен в таблице Н.1.

Таблица Н.1 - Перечень транзитных (Pass-Thru) сообщений

messageId

Наименование сообщения

Описание

00000

Зарезервировано

Зарезервировано ISO/IEC [2]

00001

PassThruRequest

От Пользователя к Сети.

Запрос на передачу транзитных данных (PassThruData).

Отклик от Сети на это сообщение отсутствует

00002

PassThruIndication

От Сети к Пользователю.

Передача Пользователю транзитных данных (PassThruData) от другого Пользователя.

Отклик от Получателя этого сообщения отсутствует

00003

PassThruReceiptRequest

От Пользователя к Сети.

Запрос на передачу Сетью транзитных данных (PassThruData) другому Пользователю. Ответ Получателя будет послан после приема данных

00004

PassThruReceiptConfirm

От Пользователя к Сети.

Отклик на сообщение PassThruReceiptRequest

00005

PassThruReceiptIndication

От Сети к Пользователю.

Передача Пользователю транзитных данных (PassThruData) от другого Пользователя. Ответ получателя будет послан после приема данных

00006

PassThruReceiptResponse

От Пользователя к Сети.

Отклик на сообщение PassThruReceiptIndication

00007 - 07FFF

Зарезервировано

Зарезервировано ISO/IEC [2]

08000 - 0FFFF

Определяется пользователем

Определяет Пользователь транзита П-С

Формат PassThruData транзитных сообщений приведен в таблице Н.2.

Таблица Н.2 - Формат PassThruData транзитных сообщений

Синтаксис

Число байтов

PassThruData() {

passThruDataLength

2

for (i=0; i<passThruDataLength; i++) {

passThruDataByte

1

}

}

Поле PassThruDataLength определяет общее число passThruDataBytes.

Поле PassThruDataByte содержет частные данные, не устанавливаемые настоящим стандартом.

Н.1.1 Транзитное сообщение PassThruRequest передается от Пользователя к Сети для запроса о доставке сообщения необходимому Пользователю.

Формат сообщения PassThruRequest представлен в таблице Н.3.

Таблица Н.3 - Формат сообщения PassThruRequest

Синтаксис

Число байтов

PassThruRequest() {

dsmccMessageHeader()

userId

20

passThruType

PassThruData()

2

}

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

Поле passThruType указывает тип передаваемого PassThruData. Это поле установлено передающим Пользователем.

Структура PassThruData() содержит частные данные, не устанавливаемые настоящим стандартом.

Н.1.2 Сообщение PassThruIndication посылают от Сети к Пользователю, чтобы освободить сообщение от обозначенного Пользователя.

Формат сообщения PassThruIndication приведен в таблице Н.4.

Таблица Н.4 - Формат сообщения PassThruIndication

Синтаксис

Число байтов

PassThruIndication() {

dsmccMessageHeader()

userId

20

passThruType

PassThruData()

2

}

Поле userId обозначает передающего Пользователя. Поле устанавливается сетью.

Поле passThruType указывает тип passThruType. Это поле определяется передающим Пользователем.

Структура PassThruData() частных данных определяется передающим Пользователем, настоящим стандартом не устанавливается.

Н.1.3 Сообщение PassThruReceiptRequest передается от Пользователя в Сеть с индикацией Пользователя и с запросом на прием сообщения от пользователя.

Формат сообщения PassThruReceiptRequest приведен в таблице Н.5.

Таблица Н.5 - Формат сообщения PassThruReceiptRequest

Синтаксис

Число байтов

PassThruReceiptRequest() {

dsmccMessageHeader()

sourceUserId

20

destinationUserId

20

passThruType

PassThruData()

2

}

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

Структура PassThruData() частных данных определяется передающим Пользователем, настоящим стандартом не устанавливается.

Н.1.4 Сообщение PassThruReceiptConfirm посылается от Сети передающему Пользователю в ответ на сообщение PassThruReceiptRequest.

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

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

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

Синтаксис

Число байтов

PassThruReceiptConfirm() {

dsmccMessageHeader()

response

2

PassThruData()

}

Н.1.5 Сообщение PassThruReceiptIndication передается от Сети принимающему Пользователю.

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

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

Синтаксис

Число байтов

PassThruReceiptIndication() {

dsmccMessageHeader()

userId

20

passThruType

PassThruData()

2

}

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

Н.1.6 Сообщение PassThruReceiptResponse передается от принимающего Пользователя к Сети.

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

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

Синтаксис

Число байтов

PassThruReceiptResponse() {

dsmccMessageHeader()

response

PassThruData()

2

}

Пояснения к синтаксису поля response - в соответствии с ISO/IEC [2] (подпункт 12.2.2.6).

13.2 Параметры полей данных, используемых в транзитных сообщениях (Pass-Thru) сеанса П-С, определены в таблице Н.9.

Таблица Н.9 - Параметры полей данных, используемых в транзитных сообщениях (Pass-Thru) сеанса П-С

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

Длина, байты

Диапазон

Описание

passThruType

2

00000 - 0FFFF

Это поле используется, чтобы указать тип PassThruData(). Возможные значения этого поля определены в ISO/IEC [2] (таблица 12-12)

response

2

00000 - 0FFFF

Это поле указывает ответ на сообщение PassThruReceipt. Этот ответ передают назад запрашиваемому Пользователю. Возможные значения для этого поля определены в ISO/IEC [2] (таблица 12-11)

userId

20

Определено OSI NSAP

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

Н.3 Пользователи могут связаться между собой, используя команды Pass-Thru в сообщениях полезной нагрузки, передаваемых через Сеть.

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

В этих сценариях отправитель сообщения считает себя Пользователем передачи, а Получатель сообщения будет считать себя Пользователем приема.

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

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

Сценарий сообщения транзита (Pass-Thru) показан на рисунке Н.1.


Рисунок Н.1 - Сценарий для транзитных сообщений

Пояснения к сценарию передачи сообщения PassThruRequest передающим Пользователем - в соответствии с ISO/IEC [2] (подпункт 12.4.1.1).

Н.4 Сценарий приема транзитного (Pass-Thru) сообщения показан на рисунке Н.2.


Рисунок Н.2 - Сценарий для транзитных (Pass-Thru) сообщений Receipt

Сообщения PassThruReceipt позволяют Пользователю послать сообщение другому Пользователю и запросить ответ Получателя сообщения.

Команды Pass-Thru Receipt передают полезную нагрузу сообщения через Сеть.

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

Инициатором сообщения PassThruReceipt является Пользователь передачи, а Получатель сообщения является Пользователем приема.

Пояснения к сценарию передачи сообщения PassThruReceiptRequest передающим Пользователем - в соответствии с ISO/IEC [2] (подпункт 12.4.1.1).

Н.5 Коды ответа, которые определены для использования в транзитных сообщениях П-С, представлены в таблице Н.10.

Таблица Н.10 - Коды ответа, определенные для использования в транзитных сообщениях П-С

Ответ

Значение

Описание

rspOK

00000

Может использоваться Пользователем приема с целью указать, что сообщение было принято

rspNoUser

00001

Указывает, что Сеть была не способна доставить сообщение PassThruReceipt, потому что данный userId был недопустим

rspNoReceipt

00002

Указывает, что Пользователь приема транзитного сообщения не отвечал на сообщение passThruReceiptIndication в период времени tMsg

reserved

00003 - 07FFF

Зарезервировано ISO/IEC [2]

User defined

08000 - 0FFFF

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

Н.6 Коды транзитных сообщений представлены в таблице Н.11.

Таблица Н.11 - Коды транзитных сообщений

Значение

Описание

00000

Зарезервировано ISO/IEC [2]

00001 - 00015

Зарезервировано Рекомендацией ITU-T [10]

00016 - 07FFF

Зарезервировано ISO/IEC [2]

08000 - 0FFFF

Определяется Пользователем. Не устанавливается настоящим стандартом

Н.7 Состояние механизма (State Machine) должно быть в соответствии с ISO/IEC [2] (приложение А).

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

[1]

ITU-T Recommendation Z.100 (11/2007)

SERIES Z: Languages and general software aspects for telecommunication systems.

Formal description techniques (FDT) - Specification and Description Language (SDL)

[2]

ISO/IEC 13818-6 (09/1998)

Information technology - Generic coding of moving pictures and associated audio Information - Part 6: Extension for DSM-CC

[3]

ISO/IEC 13818-1 (12/2000)

Information technology - Generic coding of moving pictures and associated audio information: Systems

[4]

ITU-T Recommendation H.222.0 (05/06)

Information technology - Generic coding of moving pictures and associated audio information: Systems

[5]

ITU-T Recommendation Q.922 (1992)

Digital subcriber signaling system No. 1 (DSS 1). Data link layer. ISDN data link layer specification for frame mode bearer services

[6]

ISO/IEC 8802-2 (06/98)

Information technology. Telecommunications and information exchange between systems. Local and metropolitan area networks. Specific requirements. Part 2: Logical link control

[7]

ISO/IEC 8802-1a

Information Technology. Telecommunications and information exchange between systems. Local and metropolitan area networks. Specific requirements. Part 1: Overview of Local Area Network Standards. SubNetwork Attachment Point (SNAP) specifications

[8]

IEEE 802-1990

Local and Metropolitan Area Networks: Overview and Architecture

[9]

ITU-T Recommendation E.164 (05/97)

Series E: Overall network operation, telephone service, service operation and human factors. Operation, numbering, routing and mobile services - International operation - Numbering plan of the international telephone service. The international public telecommunication numbering plan

[10]

ITU-T Recommendation T.120 (01/2007)

Series T: Terminals for telematic services.

Data protocols for multimedia conferencing

Электронный текст документа

и сверен по:

, 2010

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