Когда инженеры впервые знакомятся с интерфейсами ядра 5G, они часто начинают с запоминания всего диапазона от N1 до N50: сетевых функций на обоих концах, используемого протокола и ближайшего аналога в 4G. На начальном этапе такой подход может помочь, но при развертывании, анализе сигнализации и устранении неисправностей он быстро становится недостаточным. На практике полезнее отвечать на другие вопросы: относится ли этот интерфейс к доступу, управлению сеансом, управлению политиками или пользовательской плоскости? Передает ли он NAS, GTP-U, PFCP или сервис SBI? И по какому управляющему пути следует двигаться дальше при возникновении проблемы?

Это также одно из важнейших архитектурных отличий 5GC от EPC. В 5G интерфейсы S1, S11, Gx и S6a не просто получают новые названия. Вместо этого часть интерфейсов опорных точек сохраняется, а одновременно вводится сервисно-ориентированная архитектура Service-Based Architecture, или SBA, позволяющая сетевым функциям плоскости управления взаимодействовать посредством вызовов сервисов. Поэтому интерфейсы 5GC лучше анализировать одновременно с точки зрения опорных точек и сервисов SBA.

Как понимать SBA и архитектуру опорных точек

5GC удобно рассматривать с двух сторон. Первая — традиционная архитектура опорных точек, описывающая логическую связь между двумя функциональными сущностями, например N1 между UE и AMF, N2 между gNB и AMF, N3 между gNB и UPF и N4 между SMF и UPF. Вторая — представление SBA, в котором функции плоскости управления, такие как AMF, SMF, PCF, UDM, AUSF, NSSF, NEF и NRF, рассматриваются как поставщики и потребители сервисов.

Эти два представления не противоречат друг другу. Модель опорных точек удобна для трассировки сквозных путей сигнализации, тогда как SBA дает более наглядное понимание динамического обнаружения сетевых функций, вызова сервисов и расширения сервисов.

Например, N2 имеет очень четкую связь между конечными точками: gNB подключается к AMF и использует NGAP для передачи сигнализации NAS и поддержки управления соединением. N3 соединяет gNB с UPF и передает трафик пользовательской плоскости через GTP-U. Интерфейсы такого типа имеют явно выраженный путь «точка-точка».

Однако когда AMF обращается к UDM, AUSF или PCF, внимание смещается на сервисы, предоставляемые этими сетевыми функциями. N8 используется между AMF и UDM для получения данных подписки, связанных с управлением мобильностью, N12 поддерживает управление аутентификацией между AMF и AUSF, а N15 позволяет AMF получать политики, связанные с мобильностью. Эти связи отражают переход плоскости управления 5GC от традиционных специализированных протоколов к сервисному взаимодействию на базе HTTP/2.

Это означает, что при анализе дампов пакетов или архитектурных схем инженерам не следует воспринимать такой интерфейс, как N8, лишь как фиксированное физическое соединение. Важнее определить, какая NF потребляет какой сервис, как был обнаружен экземпляр сервиса и к какому этапу сервисной процедуры относится конкретная транзакция HTTP/2.

Как можно сгруппировать основные интерфейсы?

Вместо последовательного запоминания номеров интерфейсов практичнее группировать их по сетевым функциям, которые они поддерживают. Когда появляется сообщение сигнализации, инженер сначала определяет функциональную категорию, а затем сужает анализ до конкретного интерфейса.

Пути доступа и пользовательской плоскости

N1, N2 и N3 образуют наиболее базовую группу интерфейсов на стороне доступа 5G. N1 работает между UE и AMF и передает информацию управления мобильностью и сеансом в 5G NAS. N2 соединяет gNB и AMF, использует NGAP для передачи сигнализации NAS и поддерживает управление соединением. N3 соединяет gNB и UPF и передает фактический трафик пользовательской плоскости через GTP-U.

Внутри ядра сети UPF могут продолжать пересылать пользовательский трафик через N9 с использованием GTP-U, а через N6 UPF подключается к внешней сети данных Data Network, или DN. Трафик на N6 уже не является управляющей сигнализацией, специфичной для 5G; это IP-трафик прикладного уровня, например веб-контент, изображения, видео и другие пользовательские данные.

Поэтому, если регистрация UE прошла успешно и PDU-сеанс установлен, но прикладной трафик по-прежнему не проходит, поиск неисправности обычно следует перенести с плоскости управления AMF на N3, поведение пересылки UPF, N6 и внешнюю DN.

Управление сеансом и пользовательской плоскостью

N4 — один из важнейших управляющих интерфейсов 5GC. Он работает между SMF и UPF и использует PFCP. SMF отвечает за управление сеансом, а UPF выполняет пересылку пакетов, поэтому N4 используется для установки правил пересылки и управления поведением пользовательской плоскости.

N11 соединяет AMF и SMF и в основном поддерживает сигнализацию управления PDU-сеансом. Когда UE инициирует PDU Session Establishment, AMF передает запрос управления сеансом в SMF для дальнейшей обработки. Если регистрация проходит успешно, но установка PDU-сеанса завершается ошибкой, N11 и последующие процедуры SMF обычно становятся важными точками диагностики.

N16 поддерживает взаимодействие между экземплярами SMF, включая процедуры, связанные с повторным выбором SMF. По сравнению с EPC, в 5GC управляющие функции разделены на большее число независимых NF. Обязанности, которые раньше были сосредоточены в MME, SGW или PGW, распределены между такими функциями, как AMF, SMF, PCF и UDM, что создает новые сервисные связи.

Политики, аутентификация и данные подписки

Управление политиками в основном сосредоточено вокруг PCF. N7 соединяет SMF и PCF и используется для запроса политик, связанных с управлением сеансом. N5 работает между PCF и AF и передает параметры и требования сервисов прикладного уровня. N15 позволяет AMF получать политики, связанные с мобильностью.

Для данных подписки N8 позволяет AMF обращаться к UDM и получать информацию подписки для управления мобильностью, а N10 соединяет SMF и UDM для получения данных подписки, связанных с управлением сеансом. Аутентификация дополнительно разделена между N12, соединяющим AMF и AUSF, и N13 между AUSF и UDM.

Это разделение особенно важно. В EPC HSS выполнял значительную часть функций, связанных с данными абонентов и аутентификацией. В 5GC обязанности более точно распределены между UDM, AUSF и связанными функциями хранения данных. При сбое аутентификации уже недостаточно проверить только наличие данных абонента. Необходимо также определить, произошел ли сбой при запуске аутентификации со стороны AMF, во время обработки в AUSF или при попытке AUSF получить требуемую информацию из UDM.

Что делают расширенные сервисные интерфейсы?

Масштабируемость модели интерфейсов 5GC особенно хорошо заметна за пределами диапазона N1–N16. По мере внедрения сетевого слайсинга, раскрытия возможностей сети, сетевой аналитики, роуминга и разделения данных вокруг независимых сетевых функций появляются дополнительные интерфейсы.

N22 соединяет AMF и NSSF для выбора сетевого слайса. N34 соединяет NSSF и NWDAF, чтобы сетевая аналитика могла поддерживать решения, связанные со слайсами. NWDAF также может передавать аналитическую информацию в PCF через N23, позволяя использовать данные аналитики при принятии решений по политикам. В результате управление политиками больше не обязано опираться только на статические данные подписки и заранее определенные правила.

Раскрытие сетевых возможностей в основном связано с NEF. N29 работает между SMF и NEF, а N30 соединяет NEF и PCF. N33 поддерживает вызов сервисов между API и AF. Таким образом, NEF занимает важное место между внешними приложениями и возможностями ядра сети, предоставляя контролируемый механизм раскрытия сетевых функций прикладным сервисам.

Хранение данных также разделено более детально. N35 соединяет UDM и UDR для хранения данных подписки, N36 соединяет PCF и UDR для хранения данных политик, а N37 позволяет NEF обращаться к UDR за данными, связанными с раскрытием возможностей и приложениями. UDSF также используется для хранения неструктурированных данных, поддерживая разделение вычислительных и хранилищных функций.

В сценариях роуминга и взаимодействия между операторами используются дополнительные интерфейсы: N24 между гостевым PCF и домашним PCF, N27 между гостевым NRF и домашним NRF, N31 между V-NSSF и H-NSSF, а также N32 между V-SEPP и H-SEPP. SEPP обеспечивает контроль безопасности на межоператорских границах. В локальной тестовой среде одного оператора такие интерфейсы могут встречаться редко, но при анализе роуминговой архитектуры они становятся важными.

Функции тарификации также переходят от традиционной модели на базе Diameter к сервисному взаимодействию. N28 соединяет PCF и CHF, чтобы информация о тарификации могла использоваться при принятии решений по правилам PCC, а N40 соединяет SMF и CHF. N41–N49 зарезервированы в соответствующем диапазоне спецификаций. Еще один специализированный интерфейс — N50, соединяющий AMF и CBCF для сервисов публичного оповещения и предупреждения о чрезвычайных ситуациях.

Что учитывать при сопоставлении 5GC и EPC?

Опыт работы с EPC очень полезен при переходе от 4G к 5G, однако эти отношения не следует воспринимать как механическую замену «один к одному». Сходства между интерфейсами 5GC и EPC в основном являются функциональными ориентирами, а не точными эквивалентами.

Некоторые соответствия достаточно очевидны. N2 функционально можно сравнить с S1-MME, а N3 напоминает S1-U. N4 функционально близок к Sxa, Sxb и Sxc в архитектуре EPC на базе CUPS. С точки зрения управления политиками N7 можно сравнить с Gx, а N5 помогает понять роль прикладных политик, традиционно связанную с Rx.

Похожие закономерности перехода наблюдаются и в функциях подписки и аутентификации. N8 можно функционально сравнить с частью взаимодействия S6a между MME и HSS. N14, поддерживающий управление мобильностью между AMF, можно сопоставить с S10 между MME, а N17 для проверки идентификатора оборудования функционально соответствует взаимодействию S13 между MME и EIR.

Однако у многих интерфейсов 5GC нет прямого аналога в 4G. К ним относятся N22 для выбора слайса, N23 для сетевой аналитики, N27 для междоменного обнаружения NRF, а также интерфейсы, связанные с хранением данных на базе UDR. Эти связи появились благодаря сервисно-ориентированной архитектуре и более глубокой функциональной декомпозиции в 5GC.

Поэтому более правильный подход к миграции — сначала сравнивать функции, а затем механизмы сигнализации, а не пытаться принудительно сопоставить каждый N-интерфейс с S-интерфейсом или опорной точкой Diameter. Эволюция протоколов особенно заметна: сигнализация плоскости управления EPC во многом опиралась на Diameter и GTPv2, тогда как многие взаимодействия плоскости управления 5GC сегодня используют сервисы SBI на базе HTTP/2.

Практический подход к анализу интерфейсов 5GC

При реальном анализе сигнализации 5GC часто эффективнее двигаться назад от симптома сервиса, чем вперед от номера интерфейса. Если UE не может зарегистрироваться, начните с N1, N2 и последующих процедур аутентификации AMF и получения данных абонента. Если регистрация успешна, но PDU-сеанс не устанавливается, продолжайте проверку N11, SMF, N7, N10 и N4. Если PDU-сеанс установлен, но пользовательский трафик не достигает сети данных, перенесите внимание на N3, пересылку UPF и N6.

Для проблем, связанных с политиками, продолжайте анализ N7 и цепочки сигнализации PCF. При проблемах выбора слайса сосредоточьтесь на N22 между AMF и NSSF. Для раскрытия возможностей или требований к политикам, задаваемых приложениями, расширьте анализ до интерфейсов, связанных с NEF, AF и PCF. После построения четырехуровневого соответствия «этап сервиса — сетевая функция — интерфейс — протокол» десятки N-интерфейсов становятся гораздо понятнее.

От изучения архитектуры до поиска неисправностей в действующей сети главное в анализе интерфейсов 5GC — понимать взаимосвязь функций. Уровень доступа вводит UE в ядро сети, управление сеансом устанавливает PDU Session, сервисы политик и подписки определяют, как этот сеанс должен обрабатываться, пользовательская плоскость переносит фактический прикладной трафик, а SBA позволяет функциям плоскости управления взаимодействовать через сервисную модель. Понимание этой сквозной логики дает больше инженерной пользы, чем простое запоминание полной таблицы интерфейсов.

Часто задаваемые вопросы

Означает ли больший номер N-интерфейса более новую функцию?

Нет. Номера N-интерфейсов используются для обозначения логических опорных точек и не указывают на поколение технологии, важность или хронологический порядок. N1, N2 и N3 относятся к наиболее фундаментальным интерфейсам 5GC, а интерфейсы с более высокими номерами включают как новые функциональные связи, так и зарезервированные опорные точки.

Все ли интерфейсы плоскости управления 5GC используют HTTP/2?

Нет. Многие взаимодействия плоскости управления, связанные с SBA, используют HTTP/2, однако в 5GC применяются и другие протоколы. N2 использует NGAP, N3 и N9 — GTP-U, N4 — PFCP, а связь между UE и AMF также включает 5G NAS. Поэтому устранение неисправностей следует начинать с определения типа интерфейса, а уже затем выбирать подходящий метод анализа протокола.

Почему имя N-интерфейса иногда не видно в дампе пакетов?

Имена N-интерфейсов обозначают логические опорные точки архитектуры. В дампе пакетов обычно отображается фактически используемый протокол, например HTTP/2, NGAP, PFCP или GTP-U, а также IP-адреса взаимодействующих сетевых функций. Поэтому логический N-интерфейс необходимо определять по ролям двух NF и анализируемой сервисной процедуре.

Нужно ли в тестовой сети 5GC развертывать все определенные интерфейсы?

Нет. Набор реально используемых интерфейсов зависит от масштаба сети, включенных сервисов и поддержки таких функций, как роуминг, сетевой слайсинг, раскрытие возможностей, сетевая аналитика или публичное оповещение. Для базовой регистрации и передачи данных используется лишь часть полного набора интерфейсов 5GC.