ГОСТ Р 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 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 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 определены, согласно 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 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] |
03А | DSM-CC секции, содержащие данные мультипротокольной инкапсуляции |
03В | DSM-CC секции, содержащие сообщения П-С, кроме сообщений загрузки данных |
03С | DSM-CC секции, содержащие сообщения загрузки данных |
03D | DSM-CC секции, содержащие дескрипторы потока |
03Е | 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] |
00А | Мультипротокольная инкапсуляция |
00В | DSM-CC сообщения П-С |
00С | DSM-CC дескрипторы потока |
00D | DSM-CC секции (любой тип, включая частные данные) |
00Е - 07Е | Определен Рекомендацией 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 | 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 | 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 включает в себя поля данных и определяется специфическим сообщением 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 | 2 | |
networkParameterDataByte | 1 | |
} | ||
Поле userId содержит OSI NSAP точку доступа к сетевым службам, которая будет использована с целью уникально идентифицировать Пользователя в Сети.
Поле primaryServerId содержит OSI NSAP точку доступа к сетевым службам, которая будет использована с целью уникально идентифицировать адрес первичного сервера в Сети.
Поле networkParameterLength определяет общее число байтов.
Поле networkParameterDataByte определяет параметры конфигурации. Параметры этого поля настоящим стадартом* не установлены.
________________
* Текст документа соответствует оригиналу. - .
Г.2.3 Параметры конфигурации, определяемые Пользователем, должны быть в соответствии с форматом секции конфигурации userDefinedConfigurationParameters, приведенным в таблице Г.4.
Таблица Г.4 - Формат секции конфигурации userDefinedConfigurationParameters П-С
Синтаксис | Число байтов | |
userDefinedConfigurationParameters() { | ||
userDefinedParameterLength | 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 | 2 | |
} | ||
Поле deviceId определено в таблице Г.10 (приложение Г). Поле содержит уникальный номер, который определяет Пользователя. Сеть использует это поле для конфигурации устройства Пользователя.
Структура дескриптора compatibilityDescriptor содержит параметры конфигурации для устройства Пользователя. Структура дескриптора compatibilityDescriptor должна быть согласно ISO/IEC [2] (раздел 6) и в соответствии с приложением Ж.
Г.2.5 Сообщение UNConfigConfirm передается от Сети к Пользователю в ответ на сообщение UNConfigRequest.
Формат сообщения UNConfigConfirm приведен в таблице Г.7.
Таблица Г.7 - Формат сообщения UNConfigConfirm
Синтаксис | Число байтов | |
UNConfigConfirm() { | ||
dsmccMessageHeader() | ||
deviceId | 6 | |
response | 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 | 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 | 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 определен в таблице В.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 | 2 | |
uuDataByte | 1 | |
privateDataLength | 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 | 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 | 20 | |
} | ||
Д.2.5.2 Сообщение ClientSessionSetUpConfirm передается от Сети к Клиенту в ответ на сообщение ClientSessionSetUpRequest.
Формат сообщения ClientSessionSetUpConfirm представлен в таблице Д.9.
Таблица Д.9 - Формат сообщения ClientSessionSetUpRequest П-С DSM-CC
Синтаксис | Число байтов | |
ClientSessionSetUpConfirm() { | ||
dsmccMessageHeader() | ||
sessionId | 10 | |
response | 2 | |
serverId | 20 | |
} | ||
Д.2.5.3 Сообщение ServerSessionSetUpIndication передается от Сети на Сервер, чтобы установить сеанс, который затребовал Клиент.
Формат сообщения представлен в таблице Д.10.
Таблица Д.10 - Формат сообщения ServerSessionSetUpIndication П-С DSM-CC
Синтаксис | Число байтов | |
ServerSessionSetUpIndication() { | ||
dsmccMessageHeader() | ||
sessionId | 10 | |
reserved | 2 | |
clientId | 20 | |
serverId | 20 | |
forwardСount | 2 | |
forwardServerId | 20 | |
} | ||
Д.2.5.4 Сообщение ServerSessionSetUpResponse передается от Сервера в Сеть в ответ на сообщение ServerSessionSetUpIndication.
Формат сообщения ServerSessionSetUpResponse представлен в таблице Д.11.
Таблица Д.11 - Формат сообщения ServerSessionSetUpResponse П-С DSM-CC
Синтаксис | Число байтов | |
ServerSessionSetUpResponse() { | ||
dsmccMessageHeader() | ||
sessionId | 10 | |
response | 2 | |
serverId | 20 | |
nextServerId | 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 | 2 | |
} | ||
Д.2.6.3 Сообщение ClientSessionReleaseIndication передается от Сети Клиенту при инициации разъединения сеанса.
Формат сообщения представлен в таблице Д.14.
Таблица Д.14 - Формат сообщения ClientSessionReleaseIndication П-С DSM-CC
Синтаксис | Число байтов | |
ClientSessionReleaseIndication() { | ||
dsmccMessageHeader() | ||
sessionId | 10 | |
reason | 2 | |
} | ||
Д.2.6.4 Сообщение ClientSessionReleaseResponse передается от Клиента в Сеть в ответ на сообщение ClientSessionReleaseIndication (как ответ на запрос).
Формат сообщения ClientSessionReleaseResponse представлен в таблице Д.15.
Таблица Д.15 - Формат сообщения ClientSessionReleaseResponse П-С DSM-CC
Синтаксис | Число байтов | |
ClientSessionReleaseResponse() { | ||
dsmccMessageHeader() | ||
sessionId | 10 | |
response | 2 | |
} | ||
Д.2.6.5 Сообщение ServerSessionReleaseRequest передается от Сервера к Сети для запроса прекращения сеанса. Сеть отвечает сообщением ServerSessionReleaseConfirm. Перед передачей сообщения ServerSessionReleaseConfirm Сеть должна разорвать сеанс между Сетью и Клиентом.
Формат сообщения ServerSessionReleaseRequest представлен в таблице Д.16.
Таблица Д.16 - Формат сообщения ServerSessionReleaseRequest П-С DSM-CC
Синтаксис | Число байтов | |
ServerSessionReleaseRequest() { | ||
dsmccMessageHeader() | ||
sessionId | 10 | |
reason | 2 | |
} | ||
Д.2.6.6 Сообщение ServerSessionReleaseConfirm передается от Сети на Сервер в ответ на сообщение ServerSessionReleaseRequest.
Формат сообщения представлен в таблице Д.17.
Таблица Д.17 - Формат сообщения ServerSessionReleaseConfirm П-С DSM-CC
Синтаксис | Число байтов | |
ServerSessionReleaseConfirm() { | ||
dsmccMessageHeader() | ||
sessionId | 10 | |
response | 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 | 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 | 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 | 2 | |
statusByte | 1 | |
} | ||
Д.2.10.2 Сообщение ClientStatusConfirm передается от Сети Клиенту в ответ на сообщение ClientStatusRequest.
Формат сообщения ClientStatusConfirm представлен в таблице Д.31.
Таблица Д.31 - Формат сообщения ClientStatusConfirm П-С DSM-CC
Синтаксис | Число байтов | |
ClientStatusConfirm() { | ||
dsmccMessageHeader() | ||
response | 2 | |
statusType | 2 | |
statusCount | 2 | |
statusByte | 1 | |
} | ||
Д.2.10.3 Сообщение ClientStatusIndication передается от Сети Клиенту для запроса сообщения состояния от Клиента.
Формат сообщения представлен в таблице Д.32.
Таблица Д.32 - Формат сообщения ClientStatusIndication П-С DSM-CC
Синтаксис | Число байтов | |
ClientStatusIndication() { | ||
dsmccMessageHeader() | ||
reason | 2 | |
statusType | 2 | |
statusCount | 2 | |
statusByte | 1 | |
} | ||
Д.2.10.4 Сообщение ClientStatusResponse передается от Клиента к Сети в ответ на ClientStatusIndication сообщение, чтобы указать ответ Клиента на запрос.
Формат сообщения ClientStatusResponse представлен в таблице Д.33.
Таблица Д.33 - Формат сообщения ClientStatusResponse П-С DSM-CC
Синтаксис | Число байтов | |
ClientStatusResponse() { | ||
dsmccMessageHeader() | ||
response | 2 | |
statusType | 2 | |
statusCount | 2 | |
status Byte | 1 | |
} | ||
Д.2.10.5 Сообщение ServerStatusRequest передается от Сервера в Сеть для запроса сообщения состояния.
Формат сообщения ServerStatusRequest представлен в таблице Д.34.
Таблица Д.34 - Формат сообщения ServerStatusRequest П-С DSM-CC
Синтаксис | Число байтов | |
ServerStatusRequest() { | ||
dsmccMessageHeader() | ||
reason | 2 | |
serverId | 20 | |
statusType | 2 | |
statusCount | 2 | |
statusByte | 1 | |
} | ||
Д.2.10.6 Сообщение ServerStatusConfirm передается от Сети на Сервер в ответ на сообщение ServerStatusRequest.
Формат сообщения ServerStatusConfirm представлен в таблице Д.35.
Таблица Д.35 - Формат сообщения ServerStatusConfirm П-С DSM-CC
Синтаксис | Число байтов | |
ServerStatusConfirm() { | ||
dsmccMessageHeader() | ||
response | 2 | |
statusType | 2 | |
statusCount | 2 | |
statusByte | 1 | |
} | ||
Д.2.10.7 Сообщение ServerStatusIndication передается от Сети на Сервер для запроса сообщения состояния от Сервера.
Формат сообщения представлен в таблице Д.36.
Таблица Д.36 - Формат сообщения ServerStatusIndication П-С DSM-CC
Синтаксис | Число байтов | |
ServerStatusIndication() { | ||
dsmccMessageHeader() | ||
reason | 2 | |
statusType | 2 | |
statusCount | 2 | |
statusByte | 1 | |
} | ||
Д.2.10.8 Сообщение ServerStatusResponse передается от Сервера в Сеть в ответ на сообщение ServerStatusIndication.
Формат сообщения ServerStatusResponse представлен в таблице Д.37.
Таблица Д.37 - Формат сообщения ServerStatusResponse П-С DSM-CC
Синтаксис | Число байтов | |
ServerStatusResponse() { | ||
dsmccMessageHeader() | ||
response | 2 | |
statusType | 2 | |
statusCount | 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 | 10 | |
} | ||
Описания полей в таблице Д.48 приведены в соответствии с ISO/IEC [2] (подпункт 4.2.12.1).
Д.2.13.2 Сообщение ServerConnectIndication передается от Сети на Сервер, чтобы сообщить, что Клиент получил соединение с сеансом и готов продолжать передачу сообщений П-П режима. Сеть посылает это сообщение после получения сообщения ClientConnectRequest.
Формат сообщения ServerConnectIndication представлен в таблице Д.49.
Таблица Д.49 - Формат сообщения ServerConnectIndication П-С DSM-CC
Синтаксис | Число байтов | |
ServerConnectIndication() { | ||
dsmccMessageHeader() | ||
sessionId | 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 | 20 | |
} | ||
Д.2.14.2 Сообщение ClientSessionTransferResponse передается от Клиента к Сети в ответ на сообщение ClientSessionTransferIndication.
Формат сообщения ClientSessionTransferResponse представлен в таблице Д.51.
Таблица Д.51 - Формат сообщения ClientSessionTransferResponse П-С DSM-CC
Синтаксис | Число байтов | |
ClientSessionTransferResponse() { | ||
dsmccMessageHeader() | ||
sessionId | 10 | |
response | 2 | |
} | ||
Д.2.14.3 Сообщение ServerSessionTransferRequest передается от Сервера к Сети с запросом о передаче сеанса.
Формат сообщения ServerSessionTransferRequest представлен в таблице Д.52.
Таблица Д.52 - Формат сообщения ServerSessionTransferRequest П-С DSM-CC
Синтаксис | Число байтов | |
ServerSessionTransferRequest() { | ||
dsmccMessageHeader() | ||
sessionId | 10 | |
reserved | 2 | |
destServerId | 20 | |
baseServerId | 20 | |
} | ||
Д.2.14.4 Сообщение ServerSessionTransferConfirm передается от Сети на Сервер в ответ на ServerSessionTransferRequest.
Формат сообщения ServerSessionTransferConfirm представлен в таблице Д.53.
Таблица Д.53 - Формат сообщения ServerSessionTransferConfirm П-С DSM-CC
Синтаксис | Число байтов | |
ServerSessionTransferConfirm() { | ||
dsmccMessageHeader() | ||
sessionId | 10 | |
response | 2 | |
} | ||
Д.2.14.5 Сообщение ServerSessionTransferIndication передается от Сети на Сервер с целью указать, что эту передачу требуют на этот Сервер.
Формат сообщения представлен в таблице Д.54.
Таблица Д.54 - Формат сообщения ServerSessionTransferIndication П-С DSM-CC
Синтаксис | Число байтов | |
ServerSessionTransferIndication() { | ||
dsmccMessageHeader() | ||
sessionId | 10 | |
reserved | 2 | |
clientId | 20 | |
srcServerId | 20 | |
baseServerId | 20 | |
} | ||
Д.2.14.6 Сообщение ServerSessionTransferResponse передается от Сервера к Сети в ответ на ServerSessionTransferIndication.
Формат сообщения ServerSessionTransferResponse представлен в таблице Д.55.
Таблица Д.55 - Формат сообщения ServerSessionTransferResponse П-С DSM-CC
Синтаксис | Число байтов | |
ServerSessionTransferResponse() { | ||
dsmccMessageHeader() | ||
sessionId | 10 | |
response | 2 | |
} | ||
Д.2.15 В состав сообщений группы Развития Сеанса входят следующие сообщения:
- ClientSessionInProgress;
- ServerSessionInProgress.
Д.2.15.1 Сообщение ClientSessionInProgress передается от Клиента к Сети периодически, чтобы сообщить Сети о сеансах с активными Клиентами.
Формат сообщения представлен в таблице Д.56.
Таблица Д.56 - Формат сообщения ClientSessionInProgress П-С DSM-CC
Синтаксис | Число байтов | |
ClientSessionInProgress() { | ||
dsmccMessageHeader() | ||
sessionCount | 2 | |
sessionId | 10 | |
} | ||
Описания полей в таблице Д.56 приведены в соответствии с ISO/IEC [2] (подпункт 4.2.14.1).
Д.2.15.2 Сообщение ServerSessionInProgress передается от Сервера к Сети периодически, чтобы сообщить Сети о сеансах, активных на Сервере.
Формат сообщения представлен в таблице Д.57.
Таблица Д.57 - Формат сообщения ServerSessionInProgress П-С DSM-CC
Синтаксис | Число байтов | |
ServerSessionInProgress() { | ||
dsmccMessageHeader() | ||
sessionCount | 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() { | ||||
if(Variable == 'Yes') { | ||||
resourceDataValueByte | 1 | |||
} | ||||
} | ||||
Описания полей resourceDescriptorDataFields и resourceDataFieldCount приведены в ISO/IEC [2] (пункт 4.7.1).
Д.7.2 В тех случаях, когда поле данных дескриптора ресурса является переменным (см. рисунок Д.5), это поле должно кодироваться как формат dsmccResourceDescriptorValue() в соответствии с таблицей Д.72.
Если поле данных дескриптора ресурса не определено как переменное, то значение дескриптора ресурса не должно использовать формат dsmccResourceDescriptorValue ().
Таблица Д.72 - Формат поля dsmccResourceDescriptorValue()
Синтаксис | Число байтов | ||
dsmccResourceDescriptorValue() { | |||
resourceValueType | 2 | ||
resourceValue() | |||
} | |||
resourceListCount | 2 | ||
} | |||
mostDesiredRangeValue() | |||
| } | ||
Поле 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 | 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 используется в соответствии с ISO/IEC [2] (пункт 7.3).
И.3 Синтаксис сообщения загрузки данных является специфичным. Формат сообщения загрузки данных приведен в таблице И.2.
Таблица И.2 - Синтаксис сообщения загрузки данных
Синтаксис |
downloadDataMessage() { |
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 | 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 | 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 | 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 | 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 | 20 | |
privateDataLength | 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 | 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 | 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 | 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 | Type | carouselld | specifier | privateData |
Рисунок М.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; | |||||
ServiceID | сontext_id; | ||||
sequence | сontext_data; | ||||
}; | |||||
struct MessageHeader | { | ||||
char | magic; | ||||
Version | biop_version; | ||||
boolean | byte_order; | ||||
octet | message_type; | ||||
unsigned long | message_size; | ||||
}; | |||||
sequence | objectKey; | ||||
sequence | objectKind; | ||||
sequence | objectInfo; | ||||
sequence | serviceContextList; | ||||
}; | |||||
MessageHeader | messageHeader; | ||||
MessageSubHeader | messageSubHeader; | ||||
sequence | 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 Istring; | |||
Istring id; | |||
}; | |||
Name | bindingName; | ||
octet | bindingType; | ||
IOP::IOR | objectRef; | ||
sequence | objectInfo; | ||
}; | |||
}; | |||
Пояснения к полям таблицы М.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 | 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 | 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 | 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 | 8 | uimsbf | |
selector_byte | 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 | 8 | uimsbf | ||
association_tag | 16 | uimsbf | ||
transport_stream_id | 16 | uimsbf | ||
program_number | 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 | |||
passThruDataByte | 1 | ||
} | |||
} | |||
Поле PassThruDataLength определяет общее число passThruDataBytes.
Поле PassThruDataByte содержет частные данные, не устанавливаемые настоящим стандартом.
Н.1.1 Транзитное сообщение PassThruRequest передается от Пользователя к Сети для запроса о доставке сообщения необходимому Пользователю.
Формат сообщения PassThruRequest представлен в таблице Н.3.
Таблица Н.3 - Формат сообщения PassThruRequest
Синтаксис | Число байтов | |
PassThruRequest() { | ||
dsmccMessageHeader() | ||
userId | 20 | |
passThruType | 2 | |
} | ||
Поле userId указывает Пользователя, которому посылают сообщение. Поле устанавливается передающим Пользователем.
Поле passThruType указывает тип передаваемого PassThruData. Это поле установлено передающим Пользователем.
Структура PassThruData() содержит частные данные, не устанавливаемые настоящим стандартом.
Н.1.2 Сообщение PassThruIndication посылают от Сети к Пользователю, чтобы освободить сообщение от обозначенного Пользователя.
Формат сообщения PassThruIndication приведен в таблице Н.4.
Таблица Н.4 - Формат сообщения PassThruIndication
Синтаксис | Число байтов | |
PassThruIndication() { | ||
dsmccMessageHeader() | ||
userId | 20 | |
passThruType | 2 | |
} | ||
Поле userId обозначает передающего Пользователя. Поле устанавливается сетью.
Поле passThruType указывает тип passThruType. Это поле определяется передающим Пользователем.
Структура PassThruData() частных данных определяется передающим Пользователем, настоящим стандартом не устанавливается.
Н.1.3 Сообщение PassThruReceiptRequest передается от Пользователя в Сеть с индикацией Пользователя и с запросом на прием сообщения от пользователя.
Формат сообщения PassThruReceiptRequest приведен в таблице Н.5.
Таблица Н.5 - Формат сообщения PassThruReceiptRequest
Синтаксис | Число байтов | |
PassThruReceiptRequest() { | ||
dsmccMessageHeader() | ||
sourceUserId | 20 | |
destinationUserId | 20 | |
passThruType | 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 | 2 | |
} | ||
Описания полей - в соответствии с ISO/IEC [2] (подпункт 12.2.2.5).
Н.1.6 Сообщение PassThruReceiptResponse передается от принимающего Пользователя к Сети.
Формат сообщения PassThruReceiptResponse приведен в таблице Н.8.
Таблица Н.8 - Формат сообщения PassThruReceiptResponse
Синтаксис | Число байтов | |
PassThruReceiptResponse() { | ||
dsmccMessageHeader() | ||
response | 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