Как мы тестируем 5G transport: GTP-U, задержка по классам, обрыв

Маршрутизатор для транспорта 5G приезжает с даташитом «5G ready»: порты 100G, иерархический QoS, PTP boundary clock. Оператору нужны другие цифры. Держит ли класс URLLC свой бюджет задержки, когда backhaul забит видео? Сколько миллисекунд теряют туннели при обрыве линка в кольце? Удерживает ли устройство синхронизацию, пока все это происходит? Эти цифры мы и измеряем.

Стенд

DUT – маршрутизатор сайта, агрегации или коммутатор fronthaul, от 8 до 32 портов 10G и 100G, 400G и быстрее – под проект. Радио на стенде нет: ни радиоблоков, ни эфира. Оба конца играет генератор. Со стороны RAN он эмулирует gNB с туннелями GTP-U и миксом сессий ваших сот, на N3 и на F1-U там, где RAN разделена; со стороны ядра принимает каждый туннель и меряет каждый поток. Оба конца сидят на одном генераторе, поэтому одностороннюю задержку считаем по одним часам. Это транспортный класс со страницы 5G и мобильное ядро.

Fronthaul – отдельный случай: радиосигнал через eCPRI с бюджетом около 100 мкс в одну сторону. Профиль потоков берем из вашего дизайна, а мерить здесь нужно одностороннюю задержку против этого бюджета. Настройки QoS, маршрутизации, защиты и синхронизации ваши.

Что проверяем

• Throughput GTP-U: туннели от эмулированных gNB на 10G–100G на порт, с накладными расходами туннеля и вашими размерами кадров
• Задержка и jitter по классам: URLLC, голос, eMBB, сигнализация и синхронизация, каждый в своей очереди, на ступенях нагрузки, например 30, 70 и 90%, против бюджета участка
• QoS из конца в конец: внешний DSCP каждого туннеля попадает в нужную очередь на каждом хопе, перемаркировка там, где ее требует дизайн
• Балансировка: тысячи туннелей между несколькими адресами gNB и UPF по путям ECMP и членам LAG, перекос по каждому линку
• Окно потерь: выдернут линк кольца, перезагружен узел, трафик ушел на резервный путь; разрыв по классу и по потоку в миллисекундах
• Синхронизация: PTP эмулируем на наших генераторах и смотрим, держит ли устройство класс синхронизации впереди пользовательского трафика на полной нагрузке и не теряет ли захват при отказе
• Soak: 24 часа на 80% измеренной емкости со всеми классами

Чего пока не меряем: time error в наносекундах против класса часов устройства. Для этого нужен отдельный анализатор синхронизации, которого на стенде пока нет; полный анализ организуем под проект, и такие проекты мы сейчас собираем. Приемку по классам можно провести по Y.1564.

Что обычно ломается

Маркировка QoS. gNB маркирует внутренний пакет и оставляет внешний заголовок с нулем, а транспортные маршрутизаторы читают только внешний. Все классы, включая URLLC, едут как best effort. На 90% класс с низкой задержкой ведет себя так же, как видео.

Второй случай: балансировка. У туннелей между одной gNB и одним UPF общие внешние адреса и часто общие UDP-порты, поэтому маршрутизатор, который хэширует по этим полям, кладет их все на один линк. Пример: один член LAG 100G загружен на 95%, три почти пустые, потери в сети, заполненной на четверть. Помогает хэширование по ID туннеля, если устройство его умеет.

Третий: синхронизация под нагрузкой. Сообщения PTP стоят в одной очереди с пользовательским трафиком, и на полной нагрузке их задержка гуляет настолько, что устройство теряет захват. На стенде это смена состояния на известной ступени нагрузки. В сети это доходит до TDD-радио как интерференция между сотами, и такую проблему трудно связать с очередью.

Что в отчете

Throughput по портам и миксам. Задержку и jitter по классам на каждой ступени нагрузки рядом с бюджетом участка. Окно потерь таблицей: событие, класс, разрыв в миллисекундах, худший поток и медианный. Балансировку по линкам. Раздел синхронизации с состоянием захвата по сценариям и пометкой, что проверка шла с эмулированным PTP. Конфигурацию устройства, настройки эмулированных gNB и туннелей, прошивку и порты, чтобы вендор мог повторить любой пункт. На тех же маршрутизаторах идут и кейсы BGP, IS-IS и segment routing из раздела маршрутизация и коммутация.

С чего начать

Пришлите нам модель маршрутизатора или коммутатора, прошивку, которую планируете запускать, и дизайн транспорта: участки, QoS-маппинг, схему защиты и план синхронизации. Мы ответим черновиком плана: что проверяем, как соберем стенд и в какие сроки. Отчет остается у вас, его можно показать вендору. Напишите нам или посмотрите, что еще умеет стенд.