ГОСТ Р 56451-2015. Национальный стандарт Российской Федерации. Телевидение вещательное цифровое. Общий протокол инкапсуляции потока. Основные параметры

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

от 15 июня 2015 г. № 672-ст

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

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

ОБЩИЙ ПРОТОКОЛ ИНКАПСУЛЯЦИИ ПОТОКА

ОСНОВНЫЕ ПАРАМЕТРЫ

Digital video broadcasting. Generic stream encapsulation protocol. Basic parameters

ETSI TS 102 606 V1.1.1 (2007-10) (NEQ)

ОКС 33.170

ОКП 65 7400

Дата введения 1 сентября 2015 года

Предисловие

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

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

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

4 Настоящий стандарт разработан с учетом основных нормативных положений стандарта Европейского института по стандартизации в области телекоммуникаций (ETSI) ЕТСИ ТС 102 606 V1.1.1 (2007-10) «Телевидение вещательное цифровое (ТВЦ); Протокол инкапсуляции общего потока» [ETSI TS 102 606 V1.1.1 (2007-10) «Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol», NEQ]

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

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

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

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

«Общий» физический уровень обеспечивает транспортировку последовательности битов или пакетов данных при размещении их в кадрах без конкретных ограничений синхронизации.

Первое поколение стандартов DVB поддерживало только транспорт данных при использовании формата MPEG ([1]) с мультиплексированием пакетов транспортного потока (MPEG-TS). Многопротокольная инкапсуляция является стандартом DVB ([2]) для инкапсуляции аудио/видео и контента других видов в пакетах транспортного потока MPEG.

Второе поколение стандартов DVB для переноса транспортных потоков MPEG предусматривает режим обратной совместимости и общие режимы переноса произвольных пакетов переменной длины. Общие режимы обозначаются как общие потоки GS (Generic Stream; GS).

Протокол инкапсуляции GS (Generic Stream Encapsulation; GSE) был разработан для применения на уровне адаптации, обеспечивающем представление функций инкапсуляции пакетов и фрагментации общего потока на сетевом уровне. Протокол GSE обеспечивает эффективную инкапсуляцию дейтаграмм IP в пакеты переменной длины уровня 2, которые предназначены для применения непосредственно на физическом уровне в кадрах Основной Полосы.

Протокол GSE повышает эффективность транспортировки дейтаграмм IP при сокращении издержек в 2 — 3 раза относительно варианта многопротокольной инкапсуляции (Multi Protocol Encapsulation; MPE) в транспортных потоках MPEG. Этот эффект достигается без потерь функциональности, предоставляемой протоколом, из-за переменной длины размера пакета уровня 2, характерной для трафика IP. Например, в интерактивной системе DVB-S2 издержки уменьшаются в среднем приблизительно от 10% для MPE/MPEG-TS до 2% — 3% для протокола GSE. При этом полное увеличение пропускной способности приблизительно от 5% до 15%. Показатели фактической эффективности будут определяться характеристиками конкретной системы и трафика.

В дополнение к сокращению накладных расходов GSE обеспечивает более эффективную работу интерактивных систем, которые используют на физическом уровне усовершенствованные методы с адаптивным кодированием и модуляцией (Adaptive Coding and Modulation; ACM). Присущая системе ACM изменчивость скорости передачи делает формат общего потока более удобным, чем формат транспортного потока. Протокол GSE обеспечивает гибкую фрагментацию и инкапсуляцию и позволяет использовать возможности интеллектуального планировщика для оптимизации производительности любой системы увеличением полной пропускной способности и/или улучшением средней задержки пакета от начала до окончания канала вещания. Кроме того, гибкость протокола GSE приводит к сокращению потери пакетов при замираниях, позволяя интеллектуальному планировщику изменять параметры передачи (например, формата модуляции, скорости кодирования) для конкретного пакета сетевого уровня.

К основным функциям и характеристикам протокола GSE относятся:

• поддержка многопротокольной инкапсуляции (IPv4, IPv6, MPEG, ATM, Ethernet, 802.1pQ VLANs и т.д.);
• прозрачность к функциям сетевого уровня, включая шифрование IP и сжатие заголовка IP;
• поддержка нескольких способов адресации: в дополнение к 6-байтовому адресу MAC (включая многоадресную передачу и одноадресную передачу), поддержка MAC безадресного режима и дополнительного режима 3-байтового адреса;
• механизм фрагментации дейтаграммы IP или других пакетов сетевого уровня кадра Основной Полосы для поддержки адаптивного кодирования и модуляции или кодирования и модуляции с переменными параметрами (ACM/VCM);
• расширяемость, позволяющая включать дополнительные протоколы канального уровня, устанавливая конкретные значения типа протокола (например: безопасность Уровень 2, Сжатие Заголовка IP и т.д.).

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

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

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

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

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

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

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

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

3.1.1 идентификатор типа пакета (packet identifier): Уникальное 13-разрядное значение, идентифицирующее тип данных, хранящихся в полезной нагрузке пакета ([3]).

3.1.2 метка времени воспроизведения (presentation time stamp; PTS): Число, указывающее время, когда данный видеокадр должен появиться на выходе декодера ([3]).

3.1.3 основная полоса (Base Band; BB): Полоса частот исходного немодулированного сигнала, частотные составляющие которого находятся в интервале между нулевой и верхней частотой спектра.

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

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

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

ТВЦ — телевидение вещательное цифровое;

ACM — адаптивное кодирование и модуляция (Adaptive Coding and Modulation);

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

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

BB — основная полоса (Base Band);

bslbf — мнемоническое обозначение: последовательность битов, левый бит первый (bit string left bit first);

CRC — метод обнаружения ошибок циклическим контролем по четности (Cyclic Redundancy Check);

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

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

DVB-RCS — цифровое телевизионное вещание-система обратного канала (Digital Video Broadcasting-DVB-Return Channel via Satellite);

DVB-S2 (Digital Video Broadcasting-Satellite 2) — стандарт спутникового цифрового телевизионного вещания второго поколения;

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

GS — общий поток (Generic Stream);

GSE — инкапсуляция общего потока (Generic Stream Encapsulation);

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

ID Frag — идентификатор фрагмента (Fragment Identifier);

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

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

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

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

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

LAN — локально-вычислительная сеть (Local Area Network);

LT — индикатор типа метки (Label Type Indicator);

MAC — управление доступом к среде передачи данных (Media Access Control);

MPE — многопротокольная инкапсуляция (Multi Protocol Encapsulation);

MPEG — группа экспертов по движущимся изображениям, являющаяся автором разработки группы стандартов MPEG-1, MPEG-2, MPEG-4, MPEG-7, MPEG-21 (Motion Pictures Expert Group);

MPLS — многопротокольная коммутация по меткам (Multiprotocol Label Switching);

NIT — таблица сетевой информации (Network Information Table);

NPA — поле точка присоединения к сети (Network Point of Attachment);

PDU — блоки данных протокола (Protocol Data Units);

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

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

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

rpchof — коэффициенты остаточного многочлена, самый старший коэффициент обрабатывается первым (remainder polynomial coefficients, highest order first);

SCTP — транспортный протокол управления потоком (Stream Control Transmission Protocol);

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

uimsbf — мнемоническое обозначение последовательности битов «целое число без знака, старший бит следует первым» (unsigned integer, most significant bit first);

ULE — протокол однонаправленной облегченной инкапсуляции (Unidirectional Lightweight Encapsulation);

VCI — идентификатор виртуального канала (Virtual Channel Identifier);

VCM — кодирование и модуляции с переменными параметрами (Variable Coding and Modulation);

VLAN — виртуальная LAN (Virtual LAN);

VPI — идентификатор виртуального пути (Virtual Path Identifier).

4. Протокол инкапсуляции общего потока

4.1. Принципы инкапсуляции общего потока

Рисунок 1 иллюстрирует схему процесса инкапсуляции GS со стеком протоколов DVB. В процессе выполнения GSE участвуют дейтаграммы IP или кадры Ethernet или другие пакеты сетевого уровня.

Блоки данных протокола (Protocol Data Units; PDU), которые запланированы для передачи, инкапсулируются в нескольких пакетах GSE.

В процессе инкапсуляции определяется начало и конец каждого PDU сетевого уровня с добавлением управляющей информации (тип сетевого протокола и метка адреса). При необходимости обеспечивается полная проверка целостности PDU.

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

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

В процессе инкапсуляции GS не предусматривается проверка целостности одного пакета GSE. Для проверки правильности операции сборки только к последнему фрагменту фрагментированного PDU присоединяется пакет CRC-32. На физическом уровне возможность применения GSE основывается на условии обеспечения необходимого обнаружения ошибок и/или коррекции вероятности ошибок ([4]) и не зависит от конкретной реализации физического уровня при условии, что он соответствует требуемому уровню возможности обнаружения ошибки.

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

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

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

По условию обеспечения оптимальной эффективности протокола GSE на физическом уровне при работе с ACM инкапсулятор/планировщик должны априорно знать длину кадров основной полосы (или фиксированной, или переменной). Использование поля данных DataField кадра основной полосы может быть оптимизировано путем разделения PDU на фрагменты произвольного размера.

Дополнительная информация о процессе обработки потока инкапсулятором приведена в приложении А.

4.1.1 Фрагментация и сборка PDU

Основной заголовок GSE включает поля протокола для выполнения фрагментации и инкапсуляции. Процесс фрагментации и последующей сборки использует метку идентификатора фрагментации (ID Frag). Поле ID Frag присутствует в заголовке GSE каждого пакета GSE, который переносит фрагмент PDU, и указывает на PDU, которому принадлежит фрагмент. Этот механизм поддерживает сборку пакетов GSE, которые перемежаются, но переносят фрагменты различных PDU, адресуемых как одному приемнику, так и различным приемникам. Блок проверки целостности CRC-32 добавлен в конце фрагмента для обнаружения ошибок сборки.

Максимальное количество фрагментов PDU, которые могут одновременно присутствовать в каждом потоке GS, равно N = 256. В случае прямого канала предполагается единственный поток данных типа «точка-многоточек», используемый совместно терминалами приемников. В случае обратного канала, соединение типа «многоточек-точка» представляется в форме нескольких потоков данных «точка-точка» между каждым передатчиком и терминалом приемника. Когда отправитель завершает передачу конкретного PDU, связанное с ним значение идентификатора фрагмента освобождается и может использоваться при фрагментации другого PDU. Предполагается, что количество ID Frag, равное 256, превышает потребности существующих систем и достаточно для использования в системах следующего поколения. Поэтому количество буферов в приемниках может не превышать 256 в зависимости от системы. Правила работы приемника в соответствии с приложением Б. Заголовок каждого пакета GSE переносит бит S (индикатор старта) — старший значащий бит. Бит S величиной «1» указывает на начало PDU после заголовка GSE. Дополнительно заголовок GSE содержит индикатор конца (бит E) — второго старшего значащего бита в заголовке. Бит E с величиной «1» указывает на окончание PDU в поле данных пакета GSE. В случае, если биты S и E имеют величину «1», пакет GSE должен перенести полный PDU. Максимальная длина пакета GSE составляет 4096 байтов, значение этой длины переносится в самых правых 12 битах первых двух байтов в заголовке GSE.PDU, который не размещается в единственном пакете GSE, должен быть фрагментирован.

4.1.2 Идентификация сетевого протокола

Заголовок GSE содержит 2 байта поля тип протокола/расширение (Protocol Type/Extension), которое указывает на тип протокола, который переносит PDU, и на наличие расширения заголовка. Поле тип протокола размещено в заголовке GSE каждого полного PDU или первого фрагмента инкапсулированного PDU и использует метод, определенный протоколом однонаправленной облегченной инкапсуляции (Unidirectional Lightweight Encapsulation; ULE) [5]. Применение облегченной инкапсуляции позволяет определять расширенные заголовки в соответствии с ULE. Это обеспечивает эффективную поддержку нескольких форматов PDU, включая IPv4, IPv6, Ethernet, MPLS, ARP, 802.1pQ, и разрешение включения новых типов протокола. Кроме того, этим поддерживается формат механизма безопасности уровня 2, обеспечивающий такие функции, как шифрование, сокрытие идентификационных данных и методов аутентификации без изменения структуры заголовка GSE.

4.1.3 Адресация и аппаратурная фильтрация

Протокол GSE поддерживает четыре формата адресации:

• формат адресации «по умолчанию» использует 6-байтовую метку (например, MAC-адрес IEEE);
• формат адресации, уменьшающий издержки в случаях, рассмотренных в разделе 5 настоящего стандарта, индицируется 3-байтовой меткой;
• формат адресации без метки применяется для служб вещания или для сетей, в которых реализована обработка IP-адресов (или адресации другого типа сетевого уровня);
• формат адресации с повторным использованием метки, позволяющий использовать метку предыдущего пакета GSE для последующих пакетов GSE в данном кадре основной полосы на тот же адрес получателя. Это обеспечивает уменьшение объема сигнализации MAC в одном кадре основной полосы.

На тип используемого формата адресации указывает индикатор типа метки (Label Type Indicator, LT) в заголовке GSE (в поле 2 бита). Значение индикатора типа метки указывает на формат метки: метка длиной 6 байтов, метка длиной 3 байта, отсутствие метки или метки повторного использования. При наличии метки приемник должен ее проверить и отбрасывать любые пакеты GSE, если их метки не соответствуют типу, указанному индикатором типа метки, сконфигурированным в приемнике. Поле Длина GSE (GSE Length) в заголовке GSE указывает на длину пакета GSE (и на начало следующего пакета GSE) и позволяет приемнику отбрасывать остаток пакета, который не передан. В том случае если величина LT указывает на работу канала в режиме вещания (или в режиме обработки заголовка IP), то пакет GSE должны обрабатывать все приемники. В случае повторного использования метки приемник должен обработать пакет GSE только в том случае, если адрес последнего ранее предоставленного пакета GSE соответствует адресу приемника. Повторное использование метки допускается только в текущем кадре основной полосы.

4.1.4 Определение местоположения потоков GSE

Терминал приемника должен определить применимость протокола GSE к конкретному принятому потоку информации. В случае, например, DVB-S2, эту информацию переносят в поле SYNC заголовка кадра основной полосы ([6]).

В зависимости от стандарта физического уровня многоадресные потоки могут быть мультиплексированы в передатчике и приняты на стороне терминала. Каждый поток нужно рассматривать как отдельный логический канал. Поэтому инкапсуляция GS, включая фрагментацию, должна быть выполнена отдельно для входящих данных каждого общего потока. Содержание метки ID Frag относится к общему потоку.

4.1.5 Перенос информации сигнализации

Перенос информации сигнализации может выполняться транспортным потоком (см. раздел 6). Допускается использование одиночного общего потока, параметры сигнализации которого настоящий стандарт не устанавливает.

4.2. Формат пакета GSE

4.2.1 Спецификация

Общий поток состоит из последовательности кадров основной полосы переменной длины. В таблице 1 представлен синтаксис структуры кадра основной полосы. Пакеты GSE мультиплексированы и размещены в кадрах основной полосы. Инкапсулированные PDU или фрагменты PDU (см. 4.3) транспортируются в пакетах GSE. Дополнение (при необходимости) добавляется после последнего пакета GSE в кадре основной полосы.

Синтаксис структуры кадра основной полосы

В том случае, когда информация о фактическом размещении данных кадра основной полосы (например, в DVB-S2 в поле длина поля данных (Data Field Length) не представлена, так как информация сигнализации переносится в Заголовке Основной Полосы, то приемник должен распознавать присутствие дополнения посредством обнаружения конкретной комбинации битов индикатора старта, индикатора конца и типа метки. Синтаксис структуры кадра основной полосы показан в таблице 2. Приемник должен отбрасывать любые пакеты GSE, следующие за этой комбинацией, которая никогда не должна использоваться для каких-либо заголовков GSE.

Таблица 2

Синтаксис структуры кадра основной полосы

Каждый пакет GSE состоит из Заголовка GSE и последующей полезной нагрузки GSE, где находится инкапсулированный PDU или фрагмент инкапсулированного PDU. На рисунке 2 показан формат заголовка GSE. Применение незаштрихованных полей всегда обязательно, а заштрихованные поля могут быть опущены в зависимости от типов предыдущих полей управления в первых 4 битах заголовка GSE. Наличие возможных заголовков расширения определяется типом протокола. Минимальная длина заголовка GSE 2 байта.

Рисунок 2 — Формат заголовков GSE

Далее представлена семантика основных пакетов GSE:

Label_Type_Indicator: Поле 2 бита. При наличии дополнения в поле Label_Type_Indicator должно быть установлено «00». В противном случае, если в поле Start_Indicator установлен «0», то Label_Type_Indicator зарезервирован, и в поле должно быть установлено «11». Семантика величин поля Label_Type_Indicator показана в таблице 3. Определение меток и способов адресации представлено в разделе 5.

Таблица 3

Семантика величин поля Label_Type_Indicator

Padding_bits: Биты дополнения должны быть установлены в «0».

Примечание - N1 это количество байтов до конца кадра основной полосы.

Padding_bytes: Байты дополнения, в поле должен быть установлен «0». В случае применения дополнения в Start_Indicator, End_Indicator и Label_Type_Indicator должен быть установлен «0»/«00».

GSE_Length: Поле 12 битов указывает размер в байтах пакета GSE, отсчитываемого от байта после поля GSE_Length. Максимальная длина GSE_Length для пакета GSE может составлять 4096 байт. Поле GSE_Length указывает на начало следующего пакета GSE, на окончание поля данных (Data Field) или начало поля дополнения, если пакет GSE является в кадре последним.

Protocol_Type: Поле 16 битов указывает тип нагрузки, переносимой в PDU или присутствие Next-заголовка. Совокупность значений, которые могут переноситься в этом поле, делится на диапазоны двух типов и должны следовать правилам, описанным в [5]:

• Тип 1: Тип поля Next-заголовок. Первый тип диапазона пространства значений соответствует диапазону от 0 до 1535 десятичных значений. Эти значения могут быть использованы для идентификации конкретных канальных протоколов и/или могут указывать на наличие Заголовков расширения, которые несут дополнительные поля опциональных протоколов (например, шунтирование инкапсуляции). Диапазон подразделен на значения от 0 до 256 и от 256 до 1535 в зависимости от типа расширения. Использование этих значений координируется реестром [5].
• Тип 2: Тип поля совместимый EtherType. Второй тип диапазона пространства лежит в интервале значений между 0x600 (1536 десятичных значений) и 0xFFFF. Этот набор присвоений типа следует назначениям DIX/IEEE (не допускается использование этого диапазона в качестве указателя длины кадра). Все присвоения в этом пространстве используют значения, определенные для EtherType. Следующие два значения типа представлены в качестве примеров (взятых из реестра EtherTypes IEEE):

Пример:

0x0800: IPv4 Payload 0x86DD: IPv6 Payload.

6_byte_Label: Поле 48 битов содержит метку 6 байт, применяемую для адресации (см. раздел 5).

3_byte_Label: Поле 24 бита содержит метку 3 байта, применяемую для адресации (см. раздел 5).

Примечание — N2 является длиной в байтах расширения заголовков, установленных в соответствии с [5].

Extension_Header_byte: Опциональные байты могут быть использованы для выполнения одного или нескольких заголовков расширения. Формат заголовка расширения определен в [5].

Примечание - N3 представляет собой длину инкапсулированного PDU или фрагмента PDU в байтах.

PDU_data_byte: Эти байты содержат данные PDU.

CRC_32: Это поле присутствует только в пакете GSE, который несет последний фрагмент PDU. Это поле должно быть установлено в соответствии с 4.2.3.

Детализированная семантика пакета GSE представлена в [7] (4.2.1).

4.2.2 Кодер CRC-32

При сборке приемником фрагментов PDU, рассеянных по нескольким кадрам, существует вероятность того, что фрагмент может отсутствовать. Возможность обнаружения ошибок GSE, обусловленных неправильной сборкой, достигается вычислением CRC-32 на уровне PDU для каждого фрагментированного PDU.

Каждый пакет GSE, в котором бит S равен «0», а бит E равен «1», переносит 32-битовое поле CRC в последних четырех байтах пакета GSE. Это облегчает вычисление CRC аппаратными средствами. При вычислении CRC используется полином CRC-32, представленный ниже. Это 32-битовое значение рассчитывается в соответствии с порождающим полиномом 0x104С11DB7 , представленным в шестнадцатеричном исчислении:

X32 + X26 + X23 + X22 + X16 + X12 + X11 + X10 + X8 + X7 + + X5 + X4 + X2 + X1 + X0.

Инкапсулятор инициализирует накапливающий регистр CRC-32, устанавливая значение 0xFFFF FFFF. Затем он вычисляет значение CRC-32 пакета GSE для передачи. Пакет GSE включает все байты полезной нагрузки PDU и поля: общей длины, типа протокола, метки (если передается) и расширения заголовков (если имеют место). Вычисленное значение CRC-32 помещается в поле CRC. Процедура вычисления близка к процедуре, применяемой в протоколе SCTP ([8]) при вычислении контрольной суммы.

При сборке PDU приемник выполняет поверку целостности независимым вычислением величины CRC всего собранного PDU с добавлением вышеупомянутых полей и сравнением этой величины с переданной величиной в последнем трейлере пакета GSE.

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

Пример вычислений CRC показан на рисунке 3. В качестве примера приведен случай, когда PDU разделен на три фрагмента, которые переданы в трех пакетах GSE.

Рисунок 3 — Пример вычислений CRC

Затененные поля на рисунке 3 обозначают те фрагменты, которые участвуют в вычислении CRC: байты, по которым должен быть вычислен CRC, опуская поле общая длина, не принимая во внимание все последующие заголовки пакета GSE вплоть до поля ID Frag и не включая поле CRC.

4.3. Фрагментация PDU

Пакеты GSE с данными от PDU должны иметь одинаковый ID Frag и должны передаваться по порядку. Однако они не могут быть переданы последовательно, так как могут чередоваться с пакетами GSE, переносящими полные PDU или фрагменты с другими ID Frag. Собранные PDU будут поставлены на более высокие уровни после приема последнего фрагмента PDU.

При фрагментации применяются следующие правила:

• все пакеты GSE, переносящие данные одного и того же PDU, должны иметь одинаковые ID Frag;
• первый пакет GSE с конкретным ID Frag должен иметь бит S, равный «1», и бит E, равный «0»;
• пакеты GSE, переносящие фрагменты PDU, которые не являются ни первым, ни последним фрагментом PDU, должны иметь бит S, равный «0», и бит E, равный «0»;
• последний пакет GSE с конкретным ID Frag должен иметь бит S, равный «0», и бит E, равный «1»;
• до тех пор, пока PDU не заполнен, его ID Frag не должен повторно использоваться на интервале 256 кадров основной полосы;
• все пакеты GSE с одинаковым ID Frag должны передаваться в порядке очередности;
• поле метка должно использоваться только в первом пакете GSE.

Всякий раз при фрагментации инкапсулятор GSE исполняет первые байты X1 PDU и следующие операции:

• формирует пакет GSE с установкой бита S, равного «1», и с установкой бита E, равного «0»;
• устанавливает в поле длина GSE расчетное количество байтов, включая длину данных X1 PDU (см. рисунок 3), длины полей ID Frag, общей длины, тип протокола, уровень (если поле уровень существует) и любого заголовка расширения. Полезная нагрузка GSE переносится в первой части инкапсулированного PDU с длиной X1 байтов. Полученная длина GSE не должна превышать величину остающегося свободного пространства в текущем поле данных кадра основной полосы;
• устанавливает свободное значение ID Frag;
• устанавливает в поле общая длина расчетное количество байтов, включая длину нефрагментированного PDU, поля тип протокола, поля метка (при наличии) и любого заголовка расширения;
• добавляет поле тип протокола;
• добавляет поле метка (если применяется);
• выполняет вставки X1 (см. рисунок 3) байтов из данных PDU в полезную нагрузку GSE;
• помещает этот пакет GSE в текущем кадре первым пакетом GSE или после любого другого пакета GSE, уже присутствующего в кадре.

Когда PDU разделен на количество фрагментов более двух, инкапсулятор GSE принимает следующие X2 (см. рисунок 3) данные PDU и:

• формирует пакет GSE с установкой бита S в «0» и с установкой бита E в «0»;
• устанавливает в поле общая длина в заголовке GSE расчетное количество байтов, включая длину данных X2 PDU и поля ID Frag. Полученная длина GSE не должна превышать величину остающегося свободного пространства в текущем поле данных кадра основной полосы;
• устанавливает то же значение ID Frag, что и в предыдущем фрагменте этого PDU;
• вставляет байты X2 (см. рисунок 3) из PDU в полезную нагрузку GSE и следующие операции;
• помещает этот пакет GSE в выбранный кадр (в зависимости от алгоритма планирования) как первый пакет GSE или после любого другого пакета GSE уже присутствующего в кадре. Такая же операция повторяется для всех фрагментов PDU за исключением последнего.

Инкапсулятор GSE обрабатывает остающиеся X3 данные PDU (см. рисунок 3) и следующие операции:

• формирует пакет GSE с установкой бита S в «0» и с установкой бита E в «1»;
• устанавливает в поле длина GSE в заголовке GSE расчетное количество байтов, включая длину поля данные PDU X3, поля ID Frag и размера поля CRC-32. Полученная длина GSE не должна превышать остающееся свободное пространство в текущем поле данных кадра основной полосы;
• устанавливает в поле ID Frag ту же самую величину, что и в предыдущих фрагментах этого PDU;
• вставляет остающийся X3 (см. рисунок 3), данные PDU в полезной нагрузке GSE и добавляет CRC 32;
• помещает этот пакет GSE в выбранном кадре основной полосы в качестве первого пакета GSE или после любого другого пакета GSE, уже установленного в кадре.

Примеры форматов пакетов GSE приведены в приложении В.

5. Зависимость параметров адресации и связывания пакетов GSE от параметров поля метка

Поле метка является опциональным. В зависимости от величины, установленной в поле индикатор типа метки, оно может иметь длину 6 байтов, 3 байта или может отсутствовать. Зависимость параметров поля метка от установленного значения в поле индикатор типа метки (LT) представлена ниже.

Поле индикатор типа метки, содержащее «00» или «01», соответствует одноадресным пакетам IP, предназначенным для использования маршрутизаторами линий коллективного пользования (т.е. линий, соединяющих несколько приемников).

Поле метка может не использоваться (установлено «10») в тех случаях, когда одноадресные IP-пакеты и/или многоадресные пакеты поставляются к приемникам, которые могут использовать дискриминатор поля (например, адрес получателя IPv4/IPv6 или параллельный MAC адрес доставки) инкапсулированные протоколом, которые могут быть интерпретированы как адреса уровня 2.

При значении индикатора типа метки «00» 6-байтовая метка следует непосредственно за полем тип протокола (например, может переносить поле точка присоединения к сети (Network Point of Attachment; NPA)).

При значении индикатора типа метки «01» 3-байтовая метка (например, поле NPA), следует непосредственно за полем тип протокола. Обработка приемником пакетов GSE с 3-байтовой меткой является опциональной.

В режиме адресации «По умолчанию» адресация поля тип протокола соответствует адресам назначения NPA, которые являются 6-байтовыми числами, обычно выражаемыми в шестнадцатеричном исчислении. Метки могут использоваться для идентификации тех приемников в сети, которые должны обрабатывать конкретные пакеты GSE. 3-байтовая метка может использоваться в качестве альтернативной адресации, например, в сетях DVB-RCS, где 3-байтовая метка может представить 1-байтовый ID группы и 2-байтовый ID входа (в систему).

Значение адреса 0x00:00:00:00:00:00 в качестве метки в пакете GSE не используется. Младший значащий бит первого байта поля тип протокола устанавливается в «1» для многоадресных кадров. Остающиеся байты определяют групповой адрес канального уровня. Конкретное значение адреса 0xFF:FF:FF:FF:FF:FF определяет адрес соединения вещания. Это означает, что собранный PDU (если он был фрагментирован) должен быть поставлен всем приемникам.

Пакеты IPv4, переносящие адрес вещания подсети IPv4, должны быть поставлены всем системам с тем же префиксом сети. В присутствии 6-байтовой метки GSE индикатор типа метки установлен в «00», 6-байтовая метка должна переносить адрес NPA соединения вещания (0xFF:FF:FF:FF:FF:FF). В тех случаях, когда PDU является многоадресным пакетом IP и используется 6-байтовая метка GSE (индикатор типа метки установлен в «00»), групповой адрес приемника IP многоадресного пакета должен быть отображен в многоадресном поле тип протокола (в соответствии с методом, используемым для формирования MAC-адреса назначения в Ethernet). Метод отображения групповых адресов IPv4 определен в [9]. Метод отображения групповых адресов IPv6 определен в [10].

При передаче нескольких последовательных PDU к одному месту назначения метки повторного использования могут быть опущены. В этом случае поле тип протокола может быть удалено из всех сцепленных пакетов GSE, кроме первого (индикатор типа этикетки установлен на «11»). Первый пакет из объединенных пакетов GSE должен содержать метку 3 байта или метку 6 байтов (индикатор поля тип протокола установлен на «00» или «01»). Приемник, который принимает пакет GSE с меткой в режиме повторного использования, предполагает, что поле тип протокола ранее принятого пакета GSE остается в силе. Метку повторного использования допускается применять в том случае, когда пакеты GSE передаются в том же кадре основной полосы.

Допускается поддержка протоколом GSE одновременного использования нескольких 6-байтовых адресов и одного 3-байтового адреса. Механизм привязки для каждого адреса настоящим стандартом не определен и должен разрабатываться дополнительно.

Терминал может использовать следующие варианты адресации:

• все терминалы с одноадресным MAC могут использовать свой аппаратный адрес MAC как 6-байтовый адрес. Такая адресация действительна для всех типов терминалов (например, в системе DVB-S2 — в режиме приема, в системе DVB-RCS — в наземном обратном канале и т.д.);
• терминалы могут использовать механизм отображения MAC к IP, описанный в [9] и [10] для IPv4 и IPv6 многоадресной сигнализации адреса при получении сигнала в прямом канале (см. раздел 6).

Терминал также может поддерживать другие механизмы адресации, такие как:

• однонаправленный механизм для безадресного режима при инкапсуляции IP дейтаграмм для передачи через транспортный поток MPEG-2, описанный в [5];
• терминалы DVB-RCS могут связывать свой ID групповой регистрации с 3-байтовым адресом, если это отображено в прямом канале (см. раздел 6);
• возможны другие варианты привязки 3-байтовой метки:
• в режиме ATM: привязка к идентификатору виртуального канала/идентификатору виртуального пути (Virtual Channel Identifier/Virtual Path Identifier; VCI/VPI) (см. раздел 6);
• в режиме расширения виртуальной локальной сети VLAN (3-байтовый MAC-адрес как ID VLAN для простых случаев неявной привязки с выделенным групповым маркером, например, 0xFFFF) (см. раздел 6).

6. Параметры сигнализации информации о службах GSE

Сигнализация присутствия в транспортном потоке MPEG потока GSE IP/MAC выполняется дескриптором generic_stream_location_descriptor, определенным в [2] (8.4.5.15), который переносится в таблице уведомления (Network Information Table; NIT) (также см. [2]).

В дескрипторе generic_stream_location_descriptor должны использоваться селекторные байты в IP/MAC для передачи поля generic_stream_binding_info, синтаксис которого представлен в таблице 4.

Таблица 4

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

multicast_binding: Флаг устанавливается в «1», если используется IP для отображения адресов MAC в соответствии с [9] для групповых адресов IPv4 и в соответствии с [10] для групповых адресов IPv6. Если флаг устанавливается в «0», то отображение IP-адресов к MAC-адресам для групповых адресов выполняется вне контекста настоящего стандарта.

dvb_rcs_group_logon_id_binding: Флаг устанавливается в «1», если интерактивный терминал должен связать (обработать) groupid/logon_id как 3_byte_label.

atm_pvc_binding: Флаг устанавливается в «1», если идентификатор VPI/VCI будет передаваться в поле 3_byte_label.

vlan_extension_binding: Флаг устанавливается в «1», если vlan_id будет передаваться в поле 3_byte_label.

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

ОСНОВНЫЕ ПРИНЦИПЫ ФУНКЦИОНИРОВАНИЯ ИНКАПСУЛЯТОРА И ПЛАНИРОВЩИКА

А.1 Правила работы инкапсулятора и планировщика

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

Рисунок А.1 — Блок-схема инкапсулятора и планировщика

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

Планировщик в инкапсуляторе GS выполняет рациональное размещение пакетов GSE в кадрах основной полосы, что позволяет оптимизировать эффективность системы. На рисунке А.2 показаны несовмещенные операции инкапсуляции и планирования. PDU1, PDU2 и PDU3 образуют последовательность PDU, предварительно запланированную внешним планировщиком. Термин MODCOD содержит параметры формата модуляции и скорости кодирования, связанные с данным PDU. Предполагается, что производительность MODCOD2 выше, чем MODCOD1, то есть MODCOD1 соответствует случаю более устойчивой (робастной) передачи. PDU инкапсулируются и размещаются в кадрах основной полосы инкапсулятора GSE.

Рисунок А.2 — Несовмещенные операции инкапсуляции и планирования

Когда PDU фрагментирован с целью оптимального заполнения поля данных кадра основной полосы, как в случае с PDU2 в вышеупомянутом примере, остающийся фрагмент PDU инкапсулируется в независимом пакете GSE, который должен быть передан в одном из следующих кадров основной полосы. Однако если интеллектуальная стратегия планирования не используется, то сгенерированный пакет GSE будет запланирован для кадра основной полосы, вместе с другими предварительно запланированными инкапсулированными PDU. Так как параметры передачи являются постоянными для того же кадра, инкапсулятор должен «понизить» к уровню MODCOD 1 фрагмент следующего PDU, необходимого для заполнения кадра. Это подразумевает ухудшение емкости мгновенного канала по отношению к достижимому значению из-за несогласованности процессов планирования и инкапсуляции. На рисунке А.3 приведены совмещенные операции инкапсуляции и планирования. Показано, как объединенная операция планирования и инкапсуляции может устранить потери эффективности линии и может обеспечить лучшую эффективность системы.

Рисунок А.3 — Совмещенные операции инкапсуляции и планирования

Настоящий стандарт не устанавливает правила выполнения совмещенных операций инкапсуляции и планирования.

А.2 Использование индикатора типа метки

Индикатор типа метки позволяет инкапсулятору сообщать приемникам формат адреса NPA, который должен использоваться для фильтрации принятых пакетов GSE. Присутствие Индикатора типа метки в каждом пакете GSE в серии пакетов GSE, имеющих один и тот же адрес NPA является избыточным, избыточность устраняется использованием значения LT «11». Инкапсулятор должен использовать значение типа метки «11» только в рамках одного единственного кадра и никогда не использовать для первого пакета кадра GSE. Это правило предотвращает возникновение неоднозначностей в случае потери кадра.

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

ПРАВИЛА РАБОТЫ ПРИЕМНИКА

Приемник настраивается на конкретный общий непрерывный поток с приемным фильтром для приема всех кадров этого потока. Эти кадры собраны для формирования потока пакетов GSE. Единственный приемник может принять несколько общих потоков. В каждом случае сборка должна выполняться независимо для каждого общего потока и для каждого фрагментированного PDU. Для выполнения сборки приемник может использовать буфер для хранения частично собранного PDU. В конкретных реализациях приемника могут использоваться другие структуры данных, но при этом должно обеспечиваться выполнение эквивалентных операций, описанных ниже.

В минимальной комплектации приемник должен содержать один буфер сборки для каждого адреса, с которым он связывается. Механизмы поддержки QoS развитой сети могут использовать различные ID Frag на адрес, чтобы учесть чередование фрагментов PDU по этому адресу. Поэтому для работы в этом виде сетей приемник должен быть в состоянии обработать в общем потоке одновременно до 256 фрагментированных PDU.

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

Примечание - Кадр основной полосы может содержать более одного пакета GSE.

Б.1 Фильтрация

Приемник должен фильтровать пакеты GSE для конкретных режимов маркировки (например, 3-байтовые или 6-байтовые метки). Если бит S в заголовке GSE установлен в «1», то приемник должен интерпретировать биты метки. Если заголовок GSE содержит 6 байтов или 3 байта, то метка соответствует любому фильтру, и приемник продолжает обработку пакета. В противном случае приемник должен отбросить пакет GSE и продолжать обработку следующего пакета GSE. Если биты LT установлены в «10» (метка не существует), то приемник должен обрабатывать пакет независимо от любых фильтров. Если поле LT установлено в «11» (режим повторного использования метки), то приемник должен проверить, был ли предыдущий пакет GSE в кадре предназначен для приемника. Если это так, приемник обрабатывает пакет, в противном случае приемник должен отбросить пакет GSE. Использование величины LT «11» после предыдущей величина LT «10» (отсутствие метки) недопустимо.

Если оба бита S и E установлены в «1», то пакет GSE содержит единственный PDU. Приемник считывает поле длина GSE и может обработать пакет в соответствии с Б.3 настоящего приложения, в противном случае пакет GSE должен пройти процесс сборки в соответствии с Б.2 настоящего приложения.

Б.2 Процесс сборки

Если бит S установлен на «1», а бит E установлен на «0», то пакет GSE содержит первый фрагмент PDU с данным Frag ID. Перед входом в процессе сборки для этого ID Frag приемник должен выполнить операции:

• проверить факт использования идентификатора, что означает наличие в буфере перекомпоновки приемника фрагментов с этим ID Frag. Если идентификатор ID Frag уже используется, то приемник должен сначала отбросить сохраненные ранее в буфере фрагменты, соответствующие этому ID Frag;
• инициализировать процесс сборки для данного ID Frag и начать сборку нового PDU. Необходимое пространство буфера представлено в поле Общей Длины.

Когда бит S установлен на «0», то пакет GSE содержит продолжение или окончание фрагмента. Если буфер приемника находится в состоянии сборки для ID Frag, соответствующего ID Frag в Заголовке GSE, то он продолжает обработку. В противном случае пакет GSE должен быть отброшен.

Если биты S и E установлены на «0», то пакет GSE содержит продолжение фрагмента PDU с ID Frag, соответствующему ID Frag в заголовке GSE. Он должен быть добавлен к фрагменту в буфер сборки. Приемник может проверить размер фрагмента, чтобы общая собранная длина не превышала размер общей длины (если размер общей длины превышен, то приемник должен отбрасывать в буфере фрагменты, соответствующие этим ID Frag и прервать сборку).

Если бит S установлен на «0», а бит E установлен на «1», то пакет GSE содержит последний фрагмент PDU с ID Frag, заданной в заголовке GSE. Приемник должен добавить фрагмент к сборке в буфер для этого ID Frag. Приемник должен проверить, соответствует ли количество принятых байтов, в том числе длину нефрагментированной PDU, поля тип протокола, поля тип метки (при наличии), а также любого продления этого заголовка, общему значению длины поля в первом пакете GSE для этого PDU. Если длина собранного PDU и дополнительных вышеперечисленных полей не соответствуют общему значению длины поля, приемник должен отбрасывать PDU. Наконец, приемник сравнивает CRC (последние 4 байта текущего пакета GSE) с текущим CRC в буфере PDU. Если CRC не совпадают, то приемник должен отбросить текущий буфер PDU. Эта ошибка должна учитываться как ошибка PDU CRC. Если CRC сопоставимы, то это означает, что инкапсулированный PDU принят правильно и PDU должны быть обработаны (см. Б.3). После этого приемник освобождает этот ID Frag, чтобы обеспечить его повторное использование для следующих блоков PDU.

Если PDU, принадлежащий данному ID Frag, не может быть собран на интервале 255 последовательных кадров, то приемник должен его отбросить из буфера и освободить ID Frag. Эта ошибка должна учитываться как ошибка тайм-аута сборки PDU.

Б.3 Тип протокола и обработка следующего заголовка

После приема достоверного и полного PDU приемник начинает проверку типа поля. Ряд типов заголовков описаны в [5], другие типы могут быть указаны в будущем реестре заголовков. Значения типа поля (не превышающие 256) указаны в обязательных расширениях заголовка. Приемник должен выполнять обработку для указанного значения типа поля. Заголовки, расширяемые в будущем, могут следовать за этим расширением заголовка. Все нереализованные значения принятых данных должны отбрасываться и обработка должна продолжаться со следующего пакета GSE. Это событие ошибки должно быть записано как ошибка расширения заголовка PDU.

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

После этого полезная нагрузка PDU передается на следующий уровень протокола. PDU со значением поля типа, превышающим 1536 (которое не поддерживается приемником), может быть отброшено. Это событие ошибки должно быть записано как ошибка типа PDU.

Б.4 Метки повторного использования

Если первый пакет GSE в кадре основной полосы имеет индикатор типа метки, установленный на «11», то приемник должен отбросить пакет GSE и обрабатывать следующие пакеты GSE, пока он не обнаруживает пакет GSE, значение индикатора типа метки которого не равно «11»

Б.5 Дополнение

Прием заголовка GSE, в котором индикатор начала и индикатор конца установлены в «0» и индикатор тип метки установлен в «00», означает, что дополнение обнаружено, и приемник не может отбросить все следующие байты до конца кадра основной полосы.

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

ПРИМЕРЫ ФОРМАТОВ ПАКЕТОВ GSE

На рисунках В.1, В.2, В.3, В.4, В.5 показаны примеры форматов пакетов GSE.

Рисунок В.1 — Пакет GSE, переносящий полный нефрагментированный PDU с 6-байтовым адресом NPA

Рисунок В.2 — Пакет GSE, переносящий полный нефрагментированный PDU с 3-байтовым адресом NPA

Рисунок В.3 — Последовательность пакетов GSE, переносящих начало, продолжение и окончание PDU

Рисунок В.4 — Сцепленные пакеты GSE: форматы пакетов GSE и распределение в кадре основной полосы

Рисунок В.5 — Пакеты сигнализации MPEG инкапсуляции GSE

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