Как мы тестируем ядро 5G: шторм регистраций, UPF, рестарты

В даташите ядра 5G две цифры, которые меряют по отдельности: сколько сессий держит UPF без трафика с таймерами по умолчанию и какой throughput он дает при нескольких сотнях открытых сессий. Живое ядро получает и то, и другое разом, а в плохой день после аварии RAN в сеть заново входит целый регион. В типичной приемке пара UPF держит число из даташита, пока сессии пустые, и начинает терять пакеты на 78 % расчетного числа, как только трафик идет в каждой сессии. Мы нагружаем ядро так, как это делают час пик и плохой день, и считаем, что оно выдерживает.

Стенд

Тестируемые функции (AMF, SMF, UPF и остальное ядро 5G, либо EPC) ставятся на стенд CloudLAB, запускаются как VM и контейнеры на гипервизоре стенда или остаются в вашем тенанте, и стенд подключается к ним. Вокруг функций стенд эмулирует RAN: gNB и eNB на N2 и N3, а за ними UE, которые регистрируются, открывают PDU-сессии, переходят между сотами и отключаются. N6 замыкают эмулированные серверы, трафик пользовательской плоскости идет на скоростях от 10G до 100G в миксе eMBB, URLLC и mMTC ваших сот.

Число абонентов, микс слайсов и профиль подключений берем из вашей статистики; таймеры, QoS flow, политики и расчет емкости из обезличенной выгрузки конфигурации. Хост под функцией (SR-IOV, NUMA, пиннинг) разобран в посте про виртуальные сетевые функции; здесь предмет теста сама функция.

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

• Темп регистраций: шторм после аварии RAN, регистрации в секунду против расчетной нормы и время на p95
• Установка PDU-сессий: открытие и закрытие через SMF, на каждой выдача IP-адреса и программирование UPF по N4
• Емкость: активные сессии с трафиком в каждой, наращиваем на ходу, пока UPF не перестанет пересылать пакеты; результат в процентах от расчета
• Пользовательская плоскость: throughput от N3 до N6 по классам сессий с заполненной таблицей, pps на процессорное ядро, накладные расходы GTP-U на ваших размерах пакетов
• Задержка через UPF: p50 и p99 по классам, URLLC против своего бюджета, пока eMBB заполняет линк
• Мобильность: хендоверы между эмулированными сотами под трафиком, переход из 4G в 5G и обратно через N26, EPS fallback для голоса; непрерывность и потери на каждом переходе
• Слайсинг: каждая PDU-сессия попадает в свой слайс и свой QoS flow, а шторм в одном слайсе не сдвигает время установки и задержку в остальных
• Рестарты: AMF, SMF или UPF перезапускаются при полной таблице; сколько сессий сохранилось, сколько UE регистрируются заново, окно потерь от последнего пакета до первого вернувшегося

Полосы прохождения берем из вашего дизайна и фиксируем до прогона. Маршрутизаторам между RAN и ядром посвящен пост про 5G transport.

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

Сессии с трафиком. В приемке из первого абзаца счетчики показали, что весь хэш GTP-U считает одно процессорное ядро: туннели от нескольких gNB идут с общими внешними адресами, и распределение потоков отправляло их на одно и то же ядро. Вендор поменял распределение потоков и маппинг очередей, и на 6-й день тот же разгон держал 108 % расчета с трафиком в каждой сессии. Разгон на пустых сессиях прошел бы в первый день.

Шторм. После аварии RAN десятки тысяч UE регистрируются в одни и те же секунды. AMF, который спокойно держал плавный разгон, теперь ждет ответов аутентификации, UE упираются в таймеры повтора и шлют запросы снова, и очередь забивают повторы. В типичном проекте AMF принимает запросы с расчетной скоростью, а завершает в первые минуты меньше половины. Back-off таймеры и overload control в сторону gNB возвращают число завершенных регистраций выше расчетной линии.

Рестарты. SMF, перезапущенный при полной таблице, в типичном прогоне сохраняет 99,6 % сессий при полосе 100 %. Обычно теряются сессии, открытые в последние секунды перед рестартом, их состояние не успело дойти до резерва. Каждая такая сессия означает абонента без данных, пока телефон не переподключится, и в отчете рядом с цифрой стоит интервал синхронизации, который ее дал.

Что в отчете

Регистрации и PDU-сессии в секунду с временем установки на p95, замеренные во время шторма. Число активных сессий, на котором каждая функция останавливается или замедляется, в процентах от расчета. Throughput и задержка от N3 до N6 по классам сессий с заполненной таблицей. Сохраненные сессии и окно потерь по каждому типу отказа, рядом строки конфигурации, которые стоят за каждым непройденным пунктом. Приложены статистика эмуляторов, таблицы сессий, счетчики CPU, захваты на N3 и N6 и выгрузка конфигурации каждого прогона. Новый релиз или новый слайс проходит те же пункты еще раз, с разницей по каждому KPI.

С чего начать

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