В сети 5G Core пул AMF обычно используется для повышения доступности и распределения нагрузки, однако одного развертывания нескольких экземпляров AMF недостаточно. Когда gNB подключается к пулу AMF, ему необходимо знать не только, какие AMF находятся в сети. Также требуются сведения о GUAMI, обслуживаемых каждым AMF, поддерживаемых PLMN и срезах сети, относительной емкости, а также о том, как следует перенаправлять трафик, когда AMF выводится из обслуживания для технических работ.

Интерфейс N2 предоставляет путь плоскости управления для такого обмена информацией. Он работает поверх SCTP и использует сигнализацию NGAP для обмена данными о возможностях и синхронизации состояния между gNB и AMF. При первоначальном запуске сети сначала устанавливается SCTP-ассоциация, после чего выполняется процедура NG Setup. Во время работы изменения емкости AMF, информации GUAMI или конечных точек SCTP должны передаваться gNB через процедуры обновления конфигурации. Перед плановым обслуживанием AMF также может указать, какие GUAMI станут недоступны, и предоставить сведения о резервном AMF.

Поэтому интерфейс N2 в пуле AMF следует рассматривать как постоянно поддерживаемое управляющее взаимодействие, а не как соединение, которое один раз настраивается и затем остается неизменным. Такой подход позволяет гораздо проще воспринимать процедуры установления, обновления и повторного выбора как единый процесс управления.

Почему для пула AMF недостаточно просто установленного соединения

С точки зрения базовой связности после установления SCTP-ассоциации между gNB и AMF два узла могут обмениваться сообщениями NGAP. Однако для пула AMF одной связности недостаточно.

В одной зоне обслуживания могут находиться AMF1, AMF2, AMF3 и другие экземпляры AMF. gNB должен знать не только, доступны ли эти AMF, но и какие GUAMI, PLMN и срезы они поддерживают, а также какую относительную долю нагрузки каждый AMF в данный момент способен обрабатывать. Без этой информации все SCTP-ассоциации могут находиться в состоянии UP, но gNB все равно не будет иметь данных, необходимых для выбора подходящего AMF для новых UE.

Управление интерфейсом N2 можно разделить на три основных этапа:

Эти три процедуры соответствуют трем различным этапам жизненного цикла взаимодействия с AMF: первоначальному обнаружению, изменениям возможностей или конфигурации и временному выводу из обслуживания. Совместное рассмотрение этих процедур помогает понять, как пул AMF обеспечивает распределение нагрузки и плановое обслуживание между несколькими узлами ядра сети.

Что именно делают SCTP и NG Setup при установлении N2?

В инженерных обсуждениях весь этот этап часто называют просто «установлением N2». Однако на уровне протоколов он состоит из двух последовательных шагов: сначала устанавливается SCTP-ассоциация, затем выполняется процедура NGAP NG Setup.

Сначала gNB должен получить адрес конечной точки SCTP интерфейса N2 на стороне AMF. Адрес может быть задан статически либо получен через подходящий механизм разрешения адресов. После этого gNB устанавливает SCTP-ассоциацию с AMF.

Типичное установление SCTP-ассоциации включает четыре обмена: INIT, INIT ACK, COOKIE ECHO и COOKIE ACK. После их завершения транспортный уровень готов передавать сигнализацию NGAP. Однако gNB еще не располагает всей необходимой информацией о сервисах AMF, поэтому далее выполняется NG Setup.

gNB отправляет NG Setup Request, который может содержать такие данные, как Global gNB ID, Supported TA List, RAN Node Name и Default Paging DRX. На практике это сообщение сообщает AMF, какой RAN-узел подключается, какие зоны отслеживания он поддерживает и каковы его основные рабочие параметры.

После получения запроса AMF возвращает NG Setup Response. Ответ содержит ключевую информацию со стороны AMF, включая AMF Name, Served GUAMI List, сведения о поддерживаемых PLMN и RelativeAMFCapacity.

RelativeAMFCapacity особенно важен в пуле AMF. Его не следует понимать просто как максимальное число абонентов, которое способен обслуживать AMF. Это относительный показатель емкости, который gNB может использовать при сравнении нескольких AMF и принятии решений о выборе AMF и распределении нагрузки для последующих UE.

Если пул содержит AMF1, AMF2 и AMF3, gNB может по одной и той же процедуре установить N2-ассоциации с соответствующими AMF и получить от каждого узла данные о сервисах и относительной емкости. Именно это позволяет нескольким AMF работать как согласованный пул, а не как изолированные узлы плоскости управления.

Последовательность также хорошо видна в трассировке пакетов: сначала появляется процедура установления SCTP, затем сообщения NG Setup Request и NG Setup Response. После готовности базовой N2-ассоциации сигнализация регистрации и мобильности UE может использовать установленный путь плоскости управления.

Почему gNB необходимо обновлять при изменении возможностей AMF?

Рабочее состояние пула AMF не является статичным. В облачном 5G Core AMF может масштабироваться при росте числа абонентов; также могут изменяться его информация GUAMI, зона обслуживания, адреса конечные точки или вычислительная емкость.

Если gNB продолжит использовать параметры, полученные при первоначальном запуске, логика выбора AMF на стороне RAN может перестать соответствовать фактическим возможностям ядра сети. Именно для этого важна процедура AMF Configuration Update.

Эта процедура не относится к конкретному UE. Она позволяет AMF уведомлять NG-RAN об изменениях собственной конфигурации. Например, после масштабирования AMF его относительная вычислительная емкость может увеличиться, и gNB может получить новое значение RelativeAMFCapacity. Изменения информации GUAMI также синхронизируются тем же способом, как и добавление или удаление адресов конечных точек SCTP.

Рассмотрим ситуацию, когда система оркестрации или управления обнаруживает значительный рост числа пользователей, обслуживаемых AMF1, и автоматически увеличивает его вычислительные ресурсы. После расширения AMF1 способен принять большую относительную долю нагрузки плоскости управления, поэтому его показатель емкости соответствующим образом корректируется.

Затем AMF1 отправляет gNB сообщение AMF CONFIGURATION UPDATE. Оно может содержать обновленную информацию GUAMI, новое значение RelativeAMFCapacity и изменения конечных точек SCTP. После применения обновления gNB отвечает сообщением AMF CONFIGURATION UPDATE ACKNOWLEDGE.

С этого момента при появлении новых UE или необходимости выполнить новый выбор AMF gNB может использовать обновленные данные вместо значений, полученных при первоначальном запуске сети.

Это иллюстрирует важный принцип работы пула AMF: распределение нагрузки не рассчитывается только один раз при запуске сети. Оно может корректироваться по мере изменения ресурсов ядра сети.

Это особенно актуально для облачно-нативного 5G Core. Вычислительные ресурсы могут масштабироваться динамически, однако увеличение вычислительной мощности не меняет автоматически поведение выбора AMF на стороне RAN. Обновленные параметры плоскости управления также должны быть переданы gNB. AMF Configuration Update является сигнальным механизмом, связывающим изменения ресурсов ядра сети с изменениями поведения выбора на стороне RAN.

Как gNB готовится к повторному выбору AMF перед обслуживанием?

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

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

Для такого сценария управления AMF в NGAP используется процедура AMF Status Indication.

Предположим, AMF1 требуется обновление ПО. До начала обслуживания AMF1 может отправить gNB AMF STATUS INDICATION и указать GUAMI, которые станут недоступны. Если сообщение также содержит Backup AMF Name, например AMF2, gNB сможет учитывать этот AMF при последующем повторном выборе, при условии поддержки соответствующей возможности.

После получения индикации состояния gNB считает указанные GUAMI недоступными и соответствующим образом корректирует последующий выбор и повторный выбор AMF.

Это не означает, что все существующие контексты UE механически перемещаются из AMF1 в AMF2 в один и тот же момент. Цель заключается в том, чтобы при последующей необходимости выбора или повторного выбора AMF NG-RAN не продолжал выбирать AMF, который выводится из обслуживания.

Например, если позднее UE инициирует обновление регистрации мобильности, gNB может направить соответствующую сигнализацию к другому AMF. Новый AMF продолжит выполнять функции управления мобильностью и, если это предусмотрено процедурой, назначит UE новый 5G-GUTI.

С эксплуатационной точки зрения AMF Status Indication фактически является механизмом планового вывода из обслуживания. Он преобразует такое событие, как «AMF1 переводится на обслуживание», в статусную информацию протокольного уровня, которую NG-RAN способен понять и использовать до того, как AMF действительно станет недоступным.

Чем на самом деле управляет пул AMF с помощью этих трех процедур?

Если изучать NG Setup, AMF Configuration Update и AMF Status Indication по отдельности, они легко могут показаться тремя не связанными друг с другом процедурами NGAP. Если же рассматривать их на протяжении жизненного цикла пула AMF, взаимосвязь становится значительно яснее.

NG Setup устанавливает первоначальное взаимодействие. Когда gNB впервые подключается к AMF, ему необходимо знать, с каким AMF он взаимодействует, какие сервисы тот предоставляет и какова его относительная вычислительная способность внутри пула.

AMF Configuration Update обрабатывает изменения возможностей и конфигурации. AMF остается доступным, но его информация GUAMI, относительная емкость или транспортные конечные точки изменились, поэтому NG-RAN должен обновить сохраненные данные.

AMF Status Indication обрабатывает изменения доступности. Когда AMF готовится к обслуживанию или временному выводу из работы, gNB должен считать соответствующие GUAMI недоступными и подготовиться к последующему повторному выбору AMF.

В совокупности эти процедуры поддерживают для gNB важное рабочее представление: какие AMF доступны, какие сервисы они предоставляют, какую относительную нагрузку они способны обрабатывать и какие AMF находятся в процессе вывода из обслуживания.

Таким образом, пул AMF не достигает высокой доступности только за счет развертывания нескольких экземпляров AMF. gNB должен постоянно поддерживать актуальное представление о возможностях и состоянии AMF и использовать эти данные при принятии решений о выборе. Только тогда развертывание с несколькими AMF сможет эффективно поддерживать распределение нагрузки, эластичное масштабирование и плановое обслуживание.

Та же логика полезна и при поиске неисправностей. Сначала убедитесь, что SCTP-ассоциация исправна, затем проверьте успешное завершение NG Setup. Если соединение остается активным, но распределение нагрузки ненормально, проверьте сигнализацию AMF Configuration Update и RelativeAMFCapacity. Если трафик продолжает направляться к AMF, выводимому из обслуживания, проверьте AMF Status Indication, информацию о доступности GUAMI и поведение повторного выбора AMF.

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

Как быстро отличить сбой SCTP от сбоя NGAP в трассировке пакетов?

Сначала проверьте, успешно ли установлена SCTP-ассоциация. Если обмен INIT, INIT ACK, COOKIE ECHO и COOKIE ACK не завершен, проблема все еще находится на транспортном уровне. Если SCTP установлен, но NG Setup Response не получен либо возвращена ошибка уровня NGAP, следует продолжить проверку параметров NGAP, конфигурации TA, информации PLMN и настроек на стороне AMF.

Означает ли RelativeAMFCapacity максимальное число UE, которое может поддерживать AMF?

Нет. RelativeAMFCapacity правильнее понимать как показатель относительной емкости, используемый внутри пула AMF. Он помогает NG-RAN сравнивать относительную вычислительную способность разных AMF при выборе. Его нельзя напрямую интерпретировать как абсолютный предел числа абонентов.

Почему при изменении информации GUAMI недостаточно изменить только локальную конфигурацию AMF?

gNB уже хранит сервисную информацию AMF, полученную через интерфейс N2. Если AMF изменит конфигурацию GUAMI без уведомления NG-RAN, представления двух сторон об идентичности AMF и доступности сервисов могут разойтись. Поэтому обновленные данные должны быть синхронизированы через соответствующую процедуру управления NGAP.

Всегда ли AMF Status Indication должен содержать Backup AMF Name?

Нет. Backup AMF Name является необязательным. Даже если он не включен, NG-RAN все равно должен обработать GUAMI, отмеченные как недоступные, и выполнить соответствующие действия по управлению и повторному выбору AMF. Если Backup AMF Name включен и NG-RAN поддерживает соответствующую процедуру, указанный резервный AMF может учитываться при повторном выборе.