ГОСТ Р 54994—2012
ную загрузку маршрутизаторов, выполняющих фрагментацию и в конце системы повторно собирающих
фрагменты. Для любой сети, использующей технологию Ethernet с MTU 1492 байта (кадр в соответ-
ствии с IEEE [30] с LLC) или 1500 байтов (кадр в соответствии с IEEE 802.3 [30], [31] без LLC), коли-
чество пакетов MPEG на IP пакет должно быть не более семи (из условия обеспечения максимальной
длины пакета не более 1356 байтов). Рекомендуется использовать в пакете IP меньше семи пакетов
MPEG, чтобы не превышать MTU. Протокол IP согласно IETF [19]) требует, чтобы хосты обеспечивали
обработку дейтаграмм не менее 576 байтов.
7.2.4 Обнаружение и использование инкапсуляции в протокол RTP и прямой инкапсуляции
в протокол UDP
Сигнализацию об использовании протокола RTP или UDP выполняет служба SD&S (5.2.10 на-
стоящего стандарта) при многоадресной передаче и протокол RTSP (6.3.3 настоящего стандарта) при
одноадресной потоковой передаче. Кроме того, обнаружить использование RTP или прямого UDP ин-
капсуляции можно поиском значения 0x47 в первом байте после заголовка UDP. В случае прямой ин-
капсуляции UDP это — первый байт 188-байтового пакета TП MPEG-2, который всегда имеет значение
0x47 (байт синхронизации заголовка транспортного потока). В случае инкапсуляции RTP это — первый
байт заголовка RTP, значение которого всегда отличается от 0x47. Таким образом, в случае, если у
первого байта есть значение 0x47 — используется прямая инкапсуляция UDP, если у первого байта
есть какое-либо другое значение, тогда используется инкапсуляция RTP.
7.2.5 Встроенная информация о службе (SI)
Для транспортных потоков «TП дополнительная SI» все таблицы MPEG-2 в соответствии с
ISO/IEC [18] и ETSI [9], кроме требуемых ETSI [24], являются опциональными.
Транспортные потоки «TП полная SI» должны соответствовать требованиям ETSI [9], [32] и долж-
ны содержать все необходимые DVB SI за исключением таблицы информации о сети NIT.
7.3 Требования к сети IP
28
7.3.1 Сеть IP должна обеспечивать выполнение требований, создающих условия для успешной
доставки и декодирования пакетов транспортных потоков (при условии совместимости транспортных
потоков с HNED). К указанным требованиям относятся джиттер пакетов и переупорядочивание пакетов.
7.3.1.1 Джиттер пакетов должен определяться как изменение задержки при передаче пакета от
источника потока до HNED. Пиковое значение джиттера J (от пика до пика) не должно превышать 40 мс.
При этом подразумевается, что величина отклонения сетевой задержки d находится в интервале зна-
чений J/2 ≤ d ≤ + J/2.
Это означает, что HNED должно устойчиво функционировать при значениях d ≤ 20 мс в соответ-
ствии с ISO/IEC [33].
7.3.1.2 Использование устройством HNED прямого пользовательского протокола дейтаграммы
(UDP) допускается в том случае, если сеть не вносит изменения в порядок следования пакетов.
7.3.2 Нижеследующие условия носят рекомендательный характер. Они представляют собой ти-
повые значения, которые пользователи могут оценивать как приемлемые. Невыполнение этих рекомен-
даций не будет приводить к отказу системы IPTV, но может значительно ухудшить мнение пользователя о
качестве работы системы.
7.3.2.1 Необходимое качество приема пакетов устанавливается исходя из допустимости появле-
ния не более одного артефакта в час. Такое качество приема обеспечивается при коэффициенте оши-
бок пакетов не более 1×10
–6
для транспортного потока со скоростью 4 Мбит/с с семью транспортными
пакетами на пакет IP.
При использовании AL-FEC или RET в соответствии с ETSI [12] (приложение E) и приложением В
настоящего стандарта, допустимый коэффициент ошибок пакетов может быть значительно увеличен.
7.3.2.2 При многоадресной передаче максимальные значения интервалов «Времени присоедине-
ния» (JOIN time) к многоадресным группам» и «Времени выхода» (LEAVE time) из многоадресных групп
не должны превышать 500 мс.
«Время присоединения» определяется как интервал времени между передачей запроса прото-
кола IGMP от оконечного устройства на присоединение к многоадресной передаче и приемом первого
пакета транспортного потока оконечным устройством.
«Время выхода» определяется как интервал времени между передачей запроса протокола IGMP
от оконечного устройства на выход из многоадресной передачи и получением соответствующего пакета
потока, связанного с передачей этого запроса.