При захвате сигнализации регистрации 5G на одном и том же соединении N2 часто видна такая последовательность: сначала появляется Initial UE Message, затем Uplink NAS Transport и Downlink NAS Transport, после них Initial Context Setup, а когда UE фактически начинает устанавливать передачу данных, появляется PDU Session Resource Setup. Понять каждое отдельное сообщение не особенно сложно. Гораздо труднее понять, почему они возникают именно в таком порядке и что NGAP в действительности делает во всей плоскости управления 5G. Удобно рассматривать N2 как постоянно действующий канал управления между gNB и AMF. Сначала сетевые узлы устанавливают отношения между собой, затем создается контекст UE, и только после этого подготавливаются ресурсы RAN для PDU-сессии. При перемещении UE, переходе в состояние ожидания или изменении параметров обслуживания запускаются дополнительные процедуры NGAP.
Что на самом деле делает интерфейс N2?
N2 — это интерфейс плоскости управления между gNB и AMF, использующий NGAP, то есть NG Application Protocol (прикладной протокол NG). По функциям он в некоторой степени похож на интерфейс S1-MME, применяемый в 4G, но работает в архитектуре системы 5G.
SCTP используется как транспортный уровень N2. NGAP работает поверх SCTP, а сообщения NAS, которыми UE обменивается с ядром 5G, могут передаваться между gNB и AMF через NGAP. Типичный стек протоколов N2 можно представить так: IP обеспечивает сетевую достижимость между gNB и AMF, SCTP создает транспортную ассоциацию N2, NGAP переносит управляющие процедуры и параметры N2, а 5G NAS при необходимости передается в виде NAS-PDU.
Сам NGAP не переносит обычный пользовательский трафик UE. Реальные пользовательские данные, как правило, передаются через пользовательскую плоскость N3. N2 отвечает за такие функции управления, как создание ресурсов, управление контекстом UE, транспорт сигнализации NAS и координация мобильности. Функционально N2 поддерживает создание, сопровождение и освобождение ресурсов NG-RAN, связанных с PDU-сессиями, а также участвует в управлении контекстом UE, управлении мобильностью, передаче сигнализации NAS и управлении ресурсами пользовательской плоскости.
Почему процедуры NGAP делятся на связанные с UE и не связанные с UE?
При первом изучении NGAP переход сразу к десяткам процедур и названий сообщений быстро превращает обучение в упражнение на запоминание. Практичнее сначала определить, относится ли процедура к конкретному UE.
Процедуры, связанные с UE, работают с контекстом, сессией или состоянием мобильности конкретного пользователя. К ним относятся управление ресурсами PDU-сессии, управление контекстом UE, хэндовер, пейджинг, транспорт NAS, отчет о местоположении и процедуры радиовозможностей UE. Процедуры, не связанные с UE, напротив, в основном поддерживают отношения на уровне узлов между gNB и AMF. Типичные примеры: NG Setup, RAN Configuration Update, AMF Configuration Update, NG Reset, AMF Status Indication и Overload Start/Stop.
Такое разделение очень полезно при анализе захвата пакетов. Если затронуты пользователи всего gNB, сначала следует проверить процедуры уровня узла: SCTP, NG Setup, Reset, состояние AMF или обработку перегрузки. Если проблема касается только одного UE, анализ нужно вести по его NGAP ID, сообщениям транспорта NAS, процедурам контекста и сигнализации ресурсов PDU-сессии.
Процедуры NGAP также можно разделить на Class 1 и Class 2 в зависимости от необходимости ответа. Процедуры Class 1 обычно включают Request и Response, а также могут иметь результат Failure. Процедуры Class 2 не требуют ответа на уровне процедуры от другой стороны. В реальном поиске неисправностей обычно полезнее понять, должна ли процедура завершиться успешным или неуспешным результатом, чем запоминать класс каждого сообщения NGAP.
Как N2 формирует состояние от запуска gNB до регистрации UE?
До появления любого UE первая задача gNB — вовсе не регистрация абонента. Сначала нужно убедиться, что он может корректно обмениваться данными с AMF.
Первым шагом обычно является NG Setup. После установления SCTP-ассоциации между gNB и AMF gNB отправляет NG Setup Request. Если AMF принимает соединение, она возвращает NG Setup Response. В конфигурации с пулом AMF gNB может понадобиться установить отношения N2 с несколькими AMF и получить информацию, которая позднее используется при выборе AMF. На этом этапе установлены только отношения на уровне узлов; контекста конкретного UE еще нет.
Когда UE начинает регистрацию, сигнализация переходит на следующий уровень. Получив первое NAS-сообщение UE, gNB может переслать его в AMF с помощью Initial UE Message. Последующая NAS-сигнализация между UE и AMF обычно передается по N2 с помощью Uplink NAS Transport и Downlink NAS Transport. Важно, что gNB не обязан интерпретировать всю логику услуг NAS. Для значительной части NAS-сигнализации его основная задача — определить правильный контекст UE и доставить NAS-PDU соответствующей AMF.
По мере регистрации AMF также должна инициировать создание контекста UE на стороне RAN в gNB. Здесь появляются Initial Context Setup Request и Initial Context Setup Response. Initial Context Setup Request может содержать важные данные UE, включая Allowed NSSAI, GUAMI, UE Security Capabilities, Mobility Restriction List и NAS-PDU. На этом этапе gNB уже не просто пересылает NAS-сигнализацию, а начинает создавать состояние, необходимое для дальнейшего обслуживания данного UE.
Как NGAP создает ресурсы PDU-сессии, когда UE начинает передачу данных?
Успешная регистрация не означает, что все ресурсы пользовательской плоскости для UE уже доступны. Когда UE необходимо получить доступ к сети передачи данных и установить PDU-сессию, N2 также участвует в подготовке соответствующих ресурсов RAN.
Одна из ключевых процедур — PDU Session Resource Setup. AMF отправляет gNB сообщение PDU Session Resource Setup Request. Оно передает в NG-RAN информацию, связанную с PDU-сессией и ее QoS Flow, например PDU Session ID, S-NSSAI, сведения о туннеле пользовательской плоскости и QoS Flow List. Затем gNB выделяет требуемые радиоресурсы в соответствии с локальными условиями, например настраивает необходимые DRB для QoS Flow и подготавливает соединение пользовательской плоскости N3.
После завершения выделения ресурсов gNB отправляет AMF PDU Session Resource Setup Response, указывая, какие ресурсы были успешно созданы. Ответ может содержать информацию пользовательской плоскости gNB и успешно допущенные QoS Flow.
Именно здесь часто путают роли N1, N2 и N3. N1 переносит к UE информацию PDU-сессии уровня NAS. N2 координирует ресурсы RAN и пользовательской плоскости, которые должен создать gNB. N3 переносит фактический пользовательский трафик после подготовки этих ресурсов.
Поэтому при поиске причины сбоя PDU-сессии нельзя останавливаться после того, как уровень NAS вернул сообщение Accept. Если процедура PDU Session Resource Setup на N2 не завершилась успешно, UE мог уже получить параметры сессии, но пользовательская плоскость по-прежнему может не работать.
N2 продолжает работать и после установления PDU-сессии
NGAP не прекращает работу после активации PDU-сессии. Пока UE остается в сети, изменения состояния или условий обслуживания могут запускать дополнительные процедуры N2.
При переходе UE к другому gNB может запускаться хэндовер на основе N2 или Xn. Хэндовер N2 может включать Handover Required, Handover Request, Handover Request Acknowledge, Handover Command и Handover Notify. После установления нового пути могут последовать Path Switch Request и ответ на него, а старый контекст UE на исходном gNB освобождается.
Если UE находится в состоянии ожидания и поступает нисходящий трафик, AMF может через NGAP отправить сообщение Paging в NG-RAN, после чего RAN выполняет радиопроцедуру пейджинга. Paging — типичная односторонняя процедура NGAP. Если сети нужно изменить QoS или другие ресурсы RAN, может быть запущена PDU Session Resource Modify. Когда сессия больше не нужна, используется PDU Session Resource Release. Поэтому жизненный цикл N2 для PDU-сессии включает не только Setup, но также Modify, Release, Notify и связанные процедуры Indication.
Помимо сервисных процедур, связанных с UE, инженеры могут видеть сообщения управления интерфейсом, такие как NG Reset, Error Indication, Overload Start, Overload Stop, AMF Status Indication и процедуры обновления конфигурации. Они особенно полезны для определения, затрагивает ли проблема один UE или отражает более широкое изменение отношений между узлами N2.
В каком порядке лучше всего анализировать захват пакетов NGAP?
NGAP содержит множество сообщений, но для практического поиска неисправностей не требуется просматривать список сообщений 3GPP сверху вниз. Эффективнее следовать порядку формирования сетевого состояния.
Первый шаг — проверить SCTP. Если Transport Network Layer Association между gNB и AMF не установлена корректно, анализ последующих сервисных процедур NGAP почти не имеет смысла.
Второй шаг — проверить NG Setup и убедиться, что отношения N2 на уровне узлов исправны. Если NG Setup завершился неудачно, обычно нет смысла сразу переходить к диагностике регистрации UE.
Третий шаг — определить конкретный UE. Сообщения NGAP, связанные с UE, обычно содержат соответствующие значения UE-NGAP-ID. При анализе пакетов следует отслеживать одни и те же идентификаторы UE во времени, а не фильтровать только по тип сообщения.
Четвертый шаг — убедиться, что сигнализация NAS передается корректно. Проверьте, образуют ли Initial UE Message, Uplink NAS Transport и Downlink NAS Transport непрерывную последовательность. Если NAS-PDU уже достиг AMF, но ответа нет, направление расследования будет совсем иным, чем в случае, когда gNB изначально не доставил NAS-сообщение.
Пятый шаг — проверить создание контекста UE. Если регистрация дошла до Initial Context Setup, проанализируйте параметры в Request и убедитесь, что Response завершился успешно.
Шестой шаг — проверить ресурсы PDU-сессии. Если UE зарегистрирован, но не может получить доступ к сети передачи данных, сосредоточьтесь на PDU Session Resource Setup Request/Response и возвращенных результатах ресурсов PDU-сессии и QoS Flow.
Если проблема возникает во время мобильности, перенесите анализ на Handover, Path Switch и освобождение старого контекста UE. Если к неактивному UE не удается обратиться нисходящим трафиком, проверьте Paging.
Следование цепочке SCTP → NG Setup → идентификация UE → NAS → контекст UE → PDU-сессия → мобильность в реальной инженерной работе обычно намного эффективнее, чем попытка запомнить десятки названий сообщений NGAP.
Часто задаваемые вопросы
Как связаны NGAP и 5G NAS?
NGAP — это протокол прикладного уровня, используемый на интерфейсе N2 между gNB и AMF, а NAS переносит управляющую сигнализацию между UE и ядром 5G. Многие NAS-сообщения инкапсулируются как NAS-PDU внутри сообщений NGAP и пересылаются gNB между UE и AMF, поэтому эти два протокола работают на разных уровнях.
Передает ли интерфейс N2 интернет-трафик UE?
Нет. N2 не используется как обычный путь пользовательской плоскости для данных UE. Он переносит сигнализацию плоскости управления. Пользовательский трафик обычно передается между gNB и UPF через N3, а NGAP указывает RAN, какие связанные ресурсы необходимо создать, изменить или освободить.
Означает ли успешный NG Setup, что UE сможет нормально зарегистрироваться?
Нет. NG Setup создает только отношения N2 на уровне узлов между gNB и AMF. После появления конкретного UE должны также успешно завершиться Initial UE Message, транспорт NAS, создание контекста UE и последующие процедуры ресурсов PDU-сессии.
Почему при диагностике NGAP нельзя полагаться только на фильтры тип сообщения?
Один gNB может одновременно обслуживать множество UE, и одни и те же типы сообщений NGAP могут многократно появляться для разных пользователей. Фильтрация только по названию сообщения легко смешивает несвязанные процедуры. При диагностике конкретного UE следует совместно учитывать значения UE-NGAP-ID, время сообщений и соответствующий контекст NAS или PDU-сессии.
