ГОСТ Р 54994—2012
ны в ETSI [12] (таблица 12). Компрессия GZIP доступна только с ID полезной нагрузки 0x08 для исполь-
зования с RMS/FUS или с ID полезной нагрузки 0x07 с информационной записью районирования;
- P (ProviderID Flag): поле «Флаг рroviderID», 1 бит. Значение поля «1» означает присутствие в за-
головке поля ServiceProviderID;
- HDR_LEN (Private Header Length): поле «Длина частного заголовка», 4 бита. Поле показывает
количество слов по 32 бита. Поле используется для сигнализации о присутствии данных частного за-
головка. При отсутствии дополнительных данных заголовка у этого поля должно быть значение «0000».
Поле ID провайдера не рассматривается как часть частного заголовка и не учитывается полем Private
Header Length;
- ServiceProvider ID: поле «ID провайдера служб», 32 бита. Поле используется для идентификации
провайдера служб. Это число должно быть адресом IPv4 в соответствии с детализацией в 5.4.3.2 на-
стоящего стандарта. Провайдер служб обязан гарантировать, что этот адрес сохраняется соответству-
ющими органами и его уникальное значение используется в пределах контекста. Поле предназначено
только для использования HNED, а не для сетевой фильтрации. Использование поля обязательно, если
провайдер знает, что другие провайдеры не могут использовать этот же самый multicast адрес;
- Private Header Data: поле «Частные данные заголовка», опциональное. Это поле частных дан-
ных. Значение, синтаксис, семантика и правила использования этих данных настоящим стандартом не
определяются;
- Payload: поле «Полезная нагрузка». Размер пакета поля может быть определен из размера полу-
ченного пакета минус размер заголовка (включая опциональное поле ProviderID (если оно существует) и
любые опциональные частные существующие данные заголовка) и CRC (если оно существует). По-
лезная нагрузка может содержать нулевые байты;
- CRC: поле «CRC», опциональное, 32 бита. В поле CRC должен использоваться стандартный
CRC в соответствии с ISO/IEC [18] (приложениеA). CRC должен быть применен к данным полезной на-
грузки всех секций, включенных в сегмент. Граница этого поля не должна выравниваться до 32 битов.
5.4.3.2 Уточнения параметров секций и полей
5.4.3.2.1 Допускается разделение сегментов протокола UDP на секции. Каждая секция должна
точносоответствоватьодной дейтаграммеUDP.КаждаядейтаграммаUDPдолжна точносоответствовать
одной секции. Для сборки всего сегмента HNED должен собирать полезную нагрузку всех секций. Упо-
рядочивание секций выполняется с использованием номеров секций. После сборки сегмента может вы-
полняться проверка CRC. На рисунке 9 показана взаимосвязь между записями, сегментами и секциями.
19
Рисунок 9 — Взаимосвязь между секциями, сегментами и записями