Открыть сервис
Главная → Блог → Robust Header Compression

Robust Header Compression

Robust Header Compression (ROHC) — это метод сжатия заголовков сетевых пакетов, предназначенный для уменьшения накладных расходов (overhead) при передаче данных по каналам связи с низкой пропускной способностью, высокой задержкой или повышенной вероятностью ошибок. Разработанный в рамках стандартизации протоколов IP-телефонии и мобильной связи, ROHC позволяет сокращать размер заголовков протоколов IP, UDP, RTP и TCP до нескольких байт, что критически важно для эффективного использования ресурсов в сетях с ограниченной ёмкостью, таких как сотовые сети (2G, 3G, 4G), спутниковые каналы и системы связи с малым энергопотреблением (например, LPWAN). Технология была стандартизирована Рабочей группой по инженерным проблемам Интернета (IETF) в серии документов RFC, начиная с RFC 3095 (2001 год).

История и предпосылки создания

До появления ROHC сжатие заголовков в IP-сетях осуществлялось с помощью протокола Van Jacobson (VJ) Compression для TCP, описанного в RFC 1144 (1990 год). Однако этот метод был ориентирован на проводные линии с низкой вероятностью ошибок и не учитывал специфику беспроводных каналов, где потеря пакетов и битовые ошибки — обычное явление. С развитием голосовой связи по IP (VoIP) и мультимедийных приложений в мобильных сетях возникла потребность в более устойчивом к ошибкам сжатии, особенно для протоколов реального времени (RTP).

В 1999 году в IETF была сформирована рабочая группа Robust Header Compression (ROHC WG), которая к 2001 году выпустила RFC 3095 — основной стандарт ROHC. Впоследствии стандарт был расширен для поддержки различных профилей сжатия (например, для TCP, UDP-Lite, IPv6) и адаптирован для использования в сетях LTE (4G) и NR (5G).

Принцип работы

ROHC основан на концепции контекста — состояния, которое хранится как на стороне компрессора (отправителя), так и на стороне декомпрессора (получателя). Контекст содержит информацию о предыдущих заголовках пакетов, что позволяет передавать только изменяющиеся поля (дельта-кодирование) или даже опускать их полностью, если они предсказуемы.

Основные механизмы

  1. Классификация полей заголовка: Поля делятся на три категории:
  • Статические (неизменные в течение сессии): IP-адреса, порты UDP/TCP, версия протокола. Передаются только один раз.
  • Динамические (изменяющиеся, но предсказуемые): номера последовательности RTP, метки времени, идентификаторы IP-пакетов. Сжимаются с использованием кодирования разностей (W-LSB — Window-based Least Significant Bits).
  • Случайные (непредсказуемые): контрольные суммы, флаги. Могут передаваться в полном объёме или с частичным сжатием.
  1. Режимы работы: ROHC определяет три режима, которые выбираются в зависимости от характеристик канала:
  • Unidirectional (U-mode): Однонаправленный режим, при котором декомпрессор не отправляет обратную связь. Компрессор периодически обновляет контекст для предотвращения рассинхронизации. Используется в каналах с очень высокой задержкой или отсутствием обратного канала.
  • Bidirectional Optimistic (O-mode): Оптимистичный двунаправленный режим, при котором компрессор предполагает, что контекст у декомпрессора актуален, и отправляет обратную связь только при обнаружении ошибок. Наиболее распространённый режим.
  • Bidirectional Reliable (R-mode): Надёжный двунаправленный режим, при котором каждый пакет подтверждается. Обеспечивает максимальную устойчивость, но требует больше ресурсов.
  1. Профили сжатия: Каждый профиль определяет, как сжимается конкретный набор протоколов. Основные профили:
  • Profile 0 (RTP): Для голосовых и мультимедийных потоков (IP/UDP/RTP). Степень сжатия — до 1–2 байт на заголовок.
  • Profile 1 (UDP): Для UDP-трафика без RTP (например, DNS, SNMP). Сжатие до 3–4 байт.
  • Profile 2 (ESP): Для IPsec (Encapsulating Security Payload). Сжатие до 4–5 байт.
  • Profile 3 (TCP): Для TCP-трафика. Сжатие до 3–6 байт (в зависимости от состояния).
  • Profile 4 (UDP-Lite): Для UDP-Lite (протокол с частичной защитой контрольной суммой).

Процесс сжатия

Компрессор последовательно обрабатывает пакеты:

  1. Инициализация: При первом пакете сессии (или после потери синхронизации) передаётся полный заголовок (IR — Initialization and Refresh packet).
  2. Сжатие: Последующие пакеты сжимаются с использованием контекста. Если поля не изменились, передаётся только идентификатор контекста (CID — Context Identifier) и, возможно, минимальные изменения.
  3. Обновление контекста: При изменении статических или динамических полей (например, смена IP-адреса) отправляется пакет обновления (IR-DYN — Dynamic IR).
  4. Восстановление: Декомпрессор восстанавливает исходный заголовок, используя контекст и полученные сжатые данные. При ошибке (например, потеря пакета) декомпрессор может запросить повторную инициализацию.

Устойчивость к ошибкам

Ключевая особенность ROHC — способность корректно работать в каналах с высоким уровнем битовых ошибок (BER — Bit Error Rate) и потерями пакетов. Это достигается за счёт:

  • Использования W-LSB-кодирования: Компрессор передаёт только младшие значащие биты разности, а декомпрессор восстанавливает значение, используя окно возможных вариантов. При ошибке декомпрессор может перебирать варианты в пределах окна.
  • Механизма обратной связи: В O- и R-режимах декомпрессор отправляет сообщения о статусе (ACK/NACK/STATIC-NACK), что позволяет компрессору корректировать контекст.
  • Периодического обновления контекста: В U-режиме компрессор через определённые интервалы отправляет полные заголовки, чтобы предотвратить долгосрочную рассинхронизацию.

Применение

Сотовые сети

ROHC широко используется в стандартах мобильной связи:

  • 3G (UMTS): Внедрён в протокол PDCP (Packet Data Convergence Protocol) для сжатия заголовков VoIP и потокового видео.
  • 4G (LTE): Является обязательным компонентом PDCP в LTE. Сжимает заголовки IP/UDP/RTP для голосовых вызовов (VoLTE) и видеозвонков (ViLTE). Степень сжатия достигает 90–95% для заголовков RTP.
  • 5G (NR): Поддерживается в PDCP версии 5G, с дополнительными профилями для новых типов трафика (например, для IoT-устройств с низким энергопотреблением).

Спутниковая связь

В спутниковых каналах с высокой задержкой (до 600 мс) и периодическими потерями ROHC позволяет эффективно передавать голос и видео. Например, в системах спутниковой телефонии (Iridium, Inmarsat) ROHC сокращает накладные расходы до 2–3 байт на пакет.

Военные и авиационные системы

ROHC применяется в тактических радиосетях (например, Link 16, JTRS) и авиационных системах связи (AeroMACS), где пропускная способность ограничена, а надёжность критична.

Интернет вещей (IoT)

В протоколах LPWAN (LoRaWAN, NB-IoT) ROHC используется для сжатия заголовков IPv6/UDP, что позволяет уменьшить размер пакетов до 10–20 байт и продлить срок службы батарей устройств.

Преимущества и недостатки

Преимущества

  • Высокая степень сжатия: Заголовки RTP могут быть сжаты до 1–2 байт (с 40–60 байт).
  • Устойчивость к ошибкам: Работает при BER до 10^-3.
  • Низкая задержка: Сжатие и декомпрессия выполняются за несколько микросекунд.
  • Масштабируемость: Поддерживает до 16383 контекстов (CID) на одно соединение.

Недостатки

  • Сложность реализации: Требует значительных вычислительных ресурсов для управления контекстами и кодирования.
  • Начальная задержка: Первый пакет (IR) имеет полный размер, что может быть критично для коротких сессий.
  • Зависимость от обратной связи: В O- и R-режимах требуется надёжный обратный канал, что не всегда доступно.
  • Ограниченная поддержка в старых устройствах: Многие маршрутизаторы и коммутаторы не поддерживают ROHC.

Стандартизация

Основные документы IETF, регламентирующие ROHC:

  • RFC 3095 (2001) — базовый стандарт для RTP/UDP/IP.
  • RFC 3843 (2004) — профиль для UDP/IP.
  • RFC 4995 (2007) — обновлённая архитектура ROHC.
  • RFC 5795 (2010) — профиль для TCP/IP.
  • RFC 6846 (2013) — профиль для UDP-Lite.
  • RFC 8824 (2021) — адаптация для 5G NR.

Критика и альтернативы

Критики ROHC отмечают его избыточную сложность для современных сетей с высокой пропускной способностью (например, для 5G с гигабитными скоростями сжатие заголовков может быть неоправданным). Альтернативными подходами являются:

  • IP Header Compression (IPHC): Упрощённая версия, используемая в 6LoWPAN для IoT.
  • Static Context Header Compression (SCHC): Более простой метод, стандартизированный для LPWAN (RFC 8724).
  • NAT/NAPT: Не сжимает заголовки, но уменьшает количество IP-адресов.

Тем не менее, ROHC остаётся стандартом де-факто для голосовых и мультимедийных приложений в мобильных сетях, обеспечивая баланс между сжатием и надёжностью.

Источники

  1. RFC 3095 — RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed.
  2. RFC 4995 — The RObust Header Compression (ROHC) Framework.
  3. RFC 5795 — The RObust Header Compression (ROHC) Profile for TCP.
  4. 3GPP TS 36.323 — Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification.
  5. 3GPP TS 38.323 — NR; Packet Data Convergence Protocol (PDCP) specification.
  6. Bormann, C. et al. (2001). "RObust Header Compression (ROHC): A new approach to header compression for IP over wireless links." IEEE Communications Magazine.
  7. Jonsson, L. (2004). "RObust Header Compression (ROHC): A survey." IEEE Communications Surveys & Tutorials.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы