В плоскости управления 5G Core функция AMF отвечает за ключевые задачи, включая управление доступом UE, управление мобильностью и сигнализацию NAS. Поэтому надежность архитектуры AMF напрямую влияет на общую непрерывность обслуживания. В традиционном развертывании gNB может быть статически связана с конкретной AMF. Такой подход относительно прост при небольшом размере сети, однако его ограничения становятся все заметнее по мере роста числа абонентов, повышения динамичности трафика и распространения облачных развертываний. AMF, обслуживающая загруженный деловой район, может оставаться сильно нагруженной в часы пик, в то время как соседние ресурсы используются недостаточно. Если одна AMF сталкивается с программным или аппаратным отказом, пользователи в ее зоне обслуживания могут пострадать. Обычные операции, такие как обновление программного обеспечения и изменение конфигурации, также могут требовать тщательно запланированных окон обслуживания.
AMF Pool, представленный в архитектуре 3GPP концепцией AMF Set, решает эти проблемы за счет модели совместного развертывания нескольких AMF. Несколько AMF образуют одну логическую сервисную группу, а gNB могут устанавливать N2-соединения с AMF в пуле. В сочетании с иерархической структурой идентификатора GUAMI, взвешенным выбором AMF и сохранением контекста UE такая архитектура обеспечивает распределение нагрузки, устойчивость к отказам, уменьшение сигнализации при мобильности и более гибкое обслуживание. Идея объединения узлов плоскости управления в пул не является уникальной для 5G. Подобные концепции существовали в SGSN Pool для GPRS и MME Pool для 4G и следовали одному принципу: заменить жесткую привязку к узлу общими сетевыми ресурсами. В 5G AMF Pooling дополнительно сочетается с облачно-нативным развертыванием и эластичным управлением ресурсами.
Почему AMF Pooling важен
Одна из основных причин развертывания AMF Pool — устранение несоответствия между меняющимся распределением абонентов и фиксированной емкостью узлов. Мобильный трафик по своей природе динамичен. В рабочее время большое число абонентов может концентрироваться в деловых районах, а вечером нагрузка смещается в жилые зоны. Концерты, спортивные мероприятия и праздничные поездки также способны создавать внезапные временные пики трафика. Если географическая область зависит только от небольшого числа статически назначенных AMF, некоторые узлы могут оказаться сильно перегруженными, тогда как другие будут использоваться недостаточно.
Когда несколько AMF работают в одном пуле, gNB могут поддерживать соединения со всеми соответствующими экземплярами AMF, а новые UE распределяются в соответствии с настроенными весами AMF. Например, если три AMF с одинаковой вычислительной производительностью обслуживают одну зону, одинаковые веса позволяют относительно равномерно распределять новые регистрации UE и контексты мобильности, повышая общую эффективность использования ресурсов.
Второе важное преимущество — отказоустойчивость. Если одна AMF сталкивается с программным или аппаратным отказом, другие AMF в пуле остаются доступными для обработки последующих запросов доступа и мобильности. Для плоскости управления 5G Core такая многоузловая модель снижает чрезмерную зависимость от одной AMF и создает более прочную основу для высокодоступной работы.
Pooling также повышает эксплуатационную гибкость. Перед обновлением программного обеспечения, изменением конфигурации или расширением экземпляра AMF оператор может сначала уменьшить или перенести активную нагрузку этого узла и позволить другим AMF в пуле принять новый или перераспределенный трафик. После того как AMF перестает обслуживать активных пользователей, обслуживание можно выполнить с меньшим влиянием на действующие сервисы и с большей свободой при выборе окна работ.
Оптимизация мобильности внутри пула
Ценность AMF Pool не ограничивается многоузловым резервированием. Важным преимуществом является возможность уменьшить сигнализацию при перемещении UE по сети. Один пул может охватывать несколько Tracking Area, а gNB в этом сервисном домене поддерживают N2-соединения с AMF, входящими в один AMF Set.
Предположим, что UE первоначально регистрируется в TA1, а AMF1 создает его контекст. Если затем UE перемещается в TA2 внутри того же пула, новая gNB может продолжить выбирать AMF1 для обработки NAS-сигнализации этого UE. Пока UE остается в зоне обслуживания того же AMF Pool, сеть может стараться сохранить исходную связь с AMF.
Такая схема сокращает ненужную сигнализацию мобильности. Без pooling переход между зонами обслуживания мог бы потребовать смены обслуживающей AMF, что привело бы к дополнительной передаче контекста и процедурам, связанным с регистрацией. Pooling отделяет изменения местоположения на радиостороне от обязательной смены узла плоскости управления, позволяя UE перемещаться между gNB и Tracking Area без автоматической смены обслуживающей AMF.
С инженерной точки зрения пул фактически расширяет географическую область, в которой контекст AMF может оставаться стабильным. UE может перемещаться между несколькими gNB и TA, сохраняя одну и ту же AMF в качестве опорной точки, пока остается в сервисной зоне соответствующего AMF Set. Это уменьшает взаимодействия в плоскости управления и повышает непрерывность управления мобильностью.
В архитектуре 3GPP эта логика представлена иерархической структурой. AMF Set содержит несколько AMF, которые обслуживают определенную область и поддерживают один и тот же Network Slice или набор slices. В одной AMF Region может существовать несколько AMF Set, что позволяет крупным сетям делить плоскость управления на управляемые сервисные домены.
Как GUAMI идентифицирует AMF
Когда плоскость управления переходит от одиночного узла к архитектуре с пулом, сети требуется структурированный способ идентифицировать регионы, наборы и отдельные экземпляры AMF. GUAMI, Globally Unique AMF Identifier, предоставляет такую иерархию.
GUAMI состоит из MCC, MNC, AMF Region ID, AMF Set ID и AMF Pointer. Вместе эти поля формируют иерархическую модель адресации от PLMN через AMF Region и AMF Set до конкретного экземпляра AMF. AMF Region ID идентифицирует более крупный регион AMF, AMF Set ID — конкретный AMF Set внутри этого региона, а AMF Pointer различает отдельную AMF внутри набора.
Та же иерархия присутствует и во временных идентификаторах UE. 5G-GUTI состоит из GUAMI и 5G-TMSI. Поэтому информация, связанная с временной идентичностью UE, может указывать на AMF, которая ранее обслуживала этого UE. 5G-S-TMSI содержит AMF Set ID, AMF Pointer и 5G-TMSI и предоставляет сведения, используемые в процедурах, таких как paging.
Именно поэтому GUAMI напрямую влияет на выбор AMF. Если UE при установлении RRC предоставляет информацию, позволяющую определить ранее обслуживавшую AMF, gNB не обязательно должна выполнять полностью новый выбор только на основе нагрузки. Вместо этого она может попытаться выбрать исходную AMF и сохранить существующие сервисные отношения.
Помимо двоичных идентификаторов, для обнаружения AMF могут использоваться механизмы FQDN и DNS. gNB может сформировать AMF Set-FQDN и выполнить DNS-запрос для получения сведений об AMF, входящих в определенный набор, что дает данные для последующего установления N2-ассоциации. AMF Instance-FQDN идентифицирует отдельный экземпляр AMF и может помогать находить ранее обслуживавшую AMF в применимых сценариях мобильности или межсетевого взаимодействия.
Как gNB выбирает AMF
После запуска AMF Pool gNB должна обрабатывать две принципиально разные ситуации с UE. Первая — новый UE без пригодной информации о ранее обслуживавшей AMF. Вторая — UE, который передает информацию, позволяющую идентифицировать прежнюю AMF. Для этих случаев используются разные приоритеты выбора.
Если UE при установлении RRC не предоставляет GUAMI или другую информацию, позволяющую определить прежнюю AMF, gNB выбирает AMF из AMF Set на основе настроенных значений веса. Каждой AMF может быть назначен вес от 0 до 255, обычно в соответствии с ее вычислительной производительностью. AMF с большей емкостью может получить больший вес и принимать больше новых пользователей, а экземпляр меньшей емкости — меньший вес.
Например, если три AMF настроены с весами 100, 50 и 50, первая AMF при прочих сопоставимых условиях может получить примерно половину вновь распределяемых пользователей. Эти веса не обязаны оставаться постоянными. Если AMF расширяется, сокращается или ее емкость меняется по иной причине, обновленную информацию о весе можно передать подключенным gNB через процедуру обновления конфигурации N2, чтобы последующее распределение UE отражало новую структуру емкости.
Если же UE предоставляет действующий GUAMI, цель выбора меняется. Вместо немедленного перераспределения UE на другую AMF gNB пытается идентифицировать и выбрать ранее обслуживавшую AMF. Сохранение исходной AMF помогает поддерживать непрерывность контекста и избегать ненужных изменений в плоскости управления.
Таким образом, выбор AMF внутри пула можно свести к двум принципам: если историческая связь с AMF отсутствует, приоритет отдается распределению нагрузки; если предыдущая AMF известна, приоритет отдается непрерывности обслуживания. Первый принцип повышает использование ресурсов, второй уменьшает сигнализацию мобильности. Эффективный AMF Pool не предназначен для переноса каждого UE на AMF с минимальной текущей нагрузкой, а балансирует распределение ресурсов и стабильность контекста.
От первоначального развертывания к эластичному масштабированию
Ввод AMF Set в эксплуатацию включает несколько этапов. Сначала через систему оркестрации MANO или платформу управления сетью создаются несколько экземпляров AMF и настраиваются адреса SCTP-ассоциаций, необходимые для N2-связности.
Затем gNB устанавливает SCTP-ассоциации с AMF в пуле и выполняет процедуру N2 Setup с каждой соответствующей AMF. N2 Setup не только устанавливает соединение. Она также позволяет gNB получать параметры, связанные с работой и выбором AMF, включая относительную емкость или вес, поддерживаемые slices и информацию о зоне обслуживания. После установления этих отношений AMF Set готов обслуживать UE.
Когда появляется новый UE, gNB определяет, следует ли сохранить прежнюю связь с AMF или выбрать AMF в соответствии с доступной информацией о пуле и настроенными весами. Если все AMF имеют сопоставимую вычислительную мощность и одинаковые веса, со временем их абонентская нагрузка должна стремиться к относительно равномерному распределению.
С архитектурной точки зрения AMF Pool не следует рассматривать как традиционное решение active-standby. В схеме active-standby резервный узел может оставаться практически неактивным до возникновения отказа. В AMF Pool несколько AMF могут одновременно активно обслуживать пользователей. Отказоустойчивость является одним из результатов pooling, но более широкая цель состоит в том, чтобы несколько экземпляров AMF работали как единая логическая сервисная группа.
Эта особенность также делает AMF Pooling важной основой облачных развертываний 5GC. В cloud-native среде экземпляры AMF можно масштабировать посредством оркестрации. Количество экземпляров, вычислительная емкость и веса выбора могут меняться со временем, тогда как логический AMF Set, видимый gNB и UE, остается стабильным. Таким образом, pooling создает постоянную сервисную границу поверх динамически изменяющихся ресурсов ядра сети и поддерживает эластичное поведение, ожидаемое от ориентированного на облако 5G Core.
Часто задаваемые вопросы
Может ли одна AMF Region содержать несколько AMF Set?
Да. Одна AMF Region может содержать несколько AMF Set. Разные наборы могут обслуживать разные области, при этом AMF внутри одного набора поддерживают один и тот же Network Slice или slices, необходимые этому набору.
Соответствует ли один Tracking Area только одной gNB?
Нет. Между Tracking Area и gNB нет отношения один к одному. Один TA может содержать несколько ячеек, а одна gNB может содержать несколько ячеек, принадлежащих одному или нескольким Tracking Area.
В чем разница между AMF Pointer и AMF Set ID?
AMF Set ID идентифицирует AMF Set, а AMF Pointer различает конкретный экземпляр AMF внутри этого набора. Вместе с AMF Region ID они образуют важные части иерархической адресной информации, содержащейся в GUAMI.
Требует ли изменение веса AMF повторного установления всех N2-соединений?
Нет. При изменении емкости AMF обновленные сведения о весе или относительной емкости могут быть переданы уже подключенным gNB через соответствующую процедуру обновления конфигурации N2. Новое значение затем может влиять на распределение новых UE без необходимости заново строить существующую N2-связность.
