Em uma rede 5G Core, um pool de AMF costuma estar associado a maior disponibilidade e compartilhamento de carga, mas simplesmente implantar várias instâncias de AMF não é suficiente. Quando um gNB se conecta a um pool de AMF, ele precisa saber mais do que quais AMFs estão online. Também precisa conhecer os GUAMIs atendidos por cada AMF, os PLMNs e fatias de rede suportados, a capacidade relativa e como o tráfego deve ser redirecionado quando um AMF é retirado de serviço para manutenção.

A interface N2 fornece o caminho de plano de controle para essa troca de informações. Ela opera sobre SCTP e usa sinalização NGAP para trocar capacidades e sincronizar o estado entre o gNB e o AMF. Durante a configuração inicial da rede, primeiro é estabelecida a associação SCTP e, em seguida, é executado o procedimento NG Setup. Durante a operação, alterações na capacidade do AMF, nas informações GUAMI ou nos pontos de extremidade SCTP precisam ser informadas ao gNB por meio de procedimentos de atualização de configuração. Antes de uma manutenção planejada, o AMF também pode indicar quais GUAMIs ficarão indisponíveis e fornecer informações sobre um AMF de backup.

Portanto, a interface N2 em um pool de AMF deve ser vista como uma relação de controle mantida continuamente, e não como uma conexão configurada uma única vez e deixada sem alterações. Essa perspectiva torna muito mais fácil entender os procedimentos de estabelecimento, atualização e reseleção como um processo completo de gerenciamento.

Por que um pool de AMF exige mais do que uma conexão estabelecida

Do ponto de vista da conectividade básica, depois que uma associação SCTP entre um gNB e um AMF é estabelecida, os dois nós podem trocar mensagens NGAP. Em um pool de AMF, porém, apenas a conectividade não é suficiente.

Uma única área de serviço pode conter AMF1, AMF2, AMF3 e outras instâncias de AMF. O gNB precisa saber não apenas se esses AMFs estão acessíveis, mas também quais GUAMIs, PLMNs e fatias de rede eles suportam e qual carga relativa cada AMF está atualmente apto a processar. Sem essas informações, todas as associações SCTP poderiam estar no estado UP enquanto o gNB ainda não teria os dados necessários para selecionar um AMF adequado para novos UEs.

O gerenciamento da interface N2 pode ser dividido em três etapas principais:

Esses três procedimentos tratam de três etapas diferentes no ciclo de vida de uma relação com um AMF: descoberta inicial, alterações de capacidade ou configuração e retirada temporária de serviço. Analisá-los em conjunto facilita o entendimento de como um pool de AMF oferece compartilhamento de carga e manutenção planejada entre vários nós da rede principal.

O que SCTP e NG Setup fazem, respectivamente, durante o estabelecimento de N2?

Em discussões de engenharia, toda essa etapa costuma ser chamada simplesmente de “configuração N2”. No nível de protocolo, porém, ela consiste em duas etapas consecutivas: primeiro estabelecer a associação SCTP e depois executar o procedimento NGAP NG Setup.

O gNB primeiro precisa obter o endereço do ponto de extremidade SCTP da interface N2 no lado do AMF. O endereço pode ser configurado estaticamente ou obtido por meio de um mecanismo adequado de resolução de endereços. Em seguida, o gNB estabelece uma associação SCTP com o AMF.

Uma configuração típica de associação SCTP consiste em quatro trocas: INIT, INIT ACK, COOKIE ECHO e COOKIE ACK. Depois que essas trocas são concluídas, a camada de transporte está pronta para carregar a sinalização NGAP. O gNB, no entanto, ainda não possui todas as informações de serviço do AMF de que precisa, por isso o procedimento NG Setup vem em seguida.

O gNB envia um NG Setup Request, que pode conter informações como Global gNB ID, Supported TA List, RAN Node Name e Default Paging DRX. Em termos práticos, essa mensagem informa ao AMF qual nó RAN está se conectando, quais áreas de rastreamento ele suporta e quais são seus parâmetros básicos de operação.

Depois de receber a solicitação, o AMF retorna um NG Setup Response. A resposta fornece informações importantes do lado do AMF, incluindo AMF Name, Served GUAMI List, informações sobre PLMNs suportados e RelativeAMFCapacity.

RelativeAMFCapacity é particularmente importante em um pool de AMF. Ela não deve ser interpretada simplesmente como o número máximo de assinantes que um AMF pode suportar. Em vez disso, fornece uma referência de capacidade relativa que o gNB pode usar ao comparar vários AMFs e tomar decisões de seleção de AMF e compartilhamento de carga para UEs subsequentes.

Se o pool contiver AMF1, AMF2 e AMF3, o gNB poderá estabelecer associações N2 com os AMFs relevantes usando o mesmo processo e obter as informações de serviço e capacidade relativa retornadas por cada nó. É isso que permite que vários AMFs operem como um pool coordenado, em vez de nós isolados do plano de controle.

Uma captura de pacotes também mostra claramente essa sequência: o negociação SCTP aparece primeiro, seguido pelas mensagens NG Setup Request e NG Setup Response. Depois que a associação N2 básica está pronta, a sinalização de registro e mobilidade relacionada aos UEs pode usar o caminho de plano de controle estabelecido.

Por que o gNB precisa ser atualizado quando as capacidades do AMF mudam?

O estado operacional de um pool de AMF não é estático. Em um 5G Core baseado em nuvem, um AMF pode ser escalado quando a demanda de assinantes aumenta, ou suas informações GUAMI, área de serviço, endereços de ponto de extremidade ou capacidade de processamento podem ser alterados.

Se o gNB continuar usando os parâmetros obtidos durante a inicialização, a lógica de seleção de AMF no lado RAN pode deixar de refletir as capacidades reais da rede principal. É nesse ponto que o procedimento AMF Configuration Update se torna importante.

Esse procedimento não está relacionado a um UE específico. Em vez disso, permite que o AMF notifique o NG-RAN sobre alterações em sua própria configuração. Por exemplo, depois que um AMF é ampliado, sua capacidade relativa de processamento pode aumentar e um novo valor de RelativeAMFCapacity pode ser informado ao gNB. Alterações nas informações GUAMI também podem ser sincronizadas pelo mesmo procedimento, assim como inclusões ou remoções de endereços de ponto de extremidade SCTP.

Considere um caso em que um sistema de orquestração ou gerenciamento detecta um aumento significativo no número de usuários atendidos pelo AMF1 e expande automaticamente seus recursos de processamento. Após a expansão, o AMF1 pode processar uma parcela relativa maior da carga do plano de controle, portanto seu valor de capacidade é ajustado de acordo.

O AMF1 então envia um AMF CONFIGURATION UPDATE ao gNB. A mensagem pode conter informações GUAMI atualizadas, um novo valor de RelativeAMFCapacity e alterações nos pontos de extremidade SCTP. Depois de aplicar a atualização, o gNB responde com um AMF CONFIGURATION UPDATE ACKNOWLEDGE.

A partir desse momento, quando novos UEs chegarem ou o gNB precisar executar uma nova seleção de AMF, ele poderá usar as informações atualizadas em vez dos valores aprendidos durante a inicialização da rede.

Isso ilustra um princípio importante da operação de um pool de AMF: o compartilhamento de carga não é calculado apenas uma vez quando a rede é iniciada. Ele pode ser ajustado conforme os recursos da rede principal mudam.

Isso é particularmente relevante em um 5G Core nativo de nuvem. Os recursos de computação podem ser escalados dinamicamente, mas um aumento na capacidade computacional não altera automaticamente o comportamento de seleção de AMF no lado RAN. Os parâmetros atualizados do plano de controle também precisam ser comunicados ao gNB. AMF Configuration Update fornece o mecanismo de sinalização que conecta mudanças nos recursos da rede principal a mudanças no comportamento de seleção no lado RAN.

Como o gNB se prepara para a reseleção de AMF antes da manutenção?

O escalonamento adiciona capacidade. A manutenção cria a situação oposta: um AMF pode precisar ficar temporariamente indisponível devido a uma atualização de software, manutenção planejada ou outra tarefa operacional.

Se um AMF simplesmente ficar offline sem notificar o NG-RAN, o gNB poderá continuar selecionando-o com base nas informações armazenadas anteriormente até que ocorram falhas. Em um pool de AMF, uma abordagem melhor é avisar antecipadamente ao gNB que determinadas identidades de AMF deixarão de estar disponíveis.

O procedimento AMF Status Indication do NGAP é usado para esse tipo de cenário de gerenciamento de AMF.

Suponha que o AMF1 precise passar por uma atualização de software. Antes do início da manutenção, o AMF1 pode enviar um AMF STATUS INDICATION ao gNB e identificar os GUAMIs que ficarão indisponíveis. Se a mensagem também incluir um Backup AMF Name, como AMF2, o gNB poderá levar esse AMF em consideração durante reseleções posteriores, desde que a capacidade correspondente seja suportada.

Depois que o gNB recebe a indicação de status, ele trata os GUAMIs indicados como indisponíveis e ajusta de acordo a seleção e a reseleção posteriores de AMF.

Isso não significa que todos os contextos de UE existentes sejam movidos mecanicamente do AMF1 para o AMF2 exatamente no mesmo momento. O objetivo é evitar que o NG-RAN continue selecionando um AMF que está sendo retirado de serviço quando uma seleção ou reseleção de AMF posterior for necessária.

Por exemplo, quando um UE iniciar posteriormente uma atualização de registro de mobilidade, o gNB poderá encaminhar a sinalização relevante para outro AMF. O novo AMF poderá então continuar fornecendo funções de gerenciamento de mobilidade e, quando exigido pelo procedimento, atribuir um novo 5G-GUTI ao UE.

Do ponto de vista operacional, AMF Status Indication é essencialmente um mecanismo para retirada planejada de serviço. Ele traduz um evento operacional como “AMF1 entrará em manutenção” em informações de status no nível de protocolo que o NG-RAN pode entender e usar antes que o AMF realmente fique indisponível.

O que o pool de AMF realmente gerencia por meio desses três procedimentos?

Quando NG Setup, AMF Configuration Update e AMF Status Indication são estudados separadamente, podem parecer facilmente três procedimentos NGAP sem relação entre si. Quando vistos ao longo do ciclo de vida de um pool de AMF, sua relação fica muito mais clara.

NG Setup estabelece a relação inicial. Quando o gNB se conecta pela primeira vez a um AMF, precisa saber com qual AMF está se comunicando, quais serviços ele fornece e qual é sua capacidade relativa de processamento dentro do pool.

AMF Configuration Update trata das mudanças de capacidade e configuração. O AMF continua disponível, mas suas informações GUAMI, sua capacidade relativa ou seus pontos de extremidade de transporte mudaram, então o NG-RAN precisa atualizar as informações armazenadas.

AMF Status Indication trata das mudanças de disponibilidade. Quando um AMF está se preparando para manutenção ou retirada temporária, o gNB precisa tratar os GUAMIs relevantes como indisponíveis e se preparar para a reseleção posterior de AMF.

Em conjunto, esses procedimentos mantêm uma visão operacional importante para o gNB: quais AMFs estão disponíveis, quais serviços fornecem, qual carga relativa estão aptos a processar e quais AMFs estão em processo de sair de serviço.

Portanto, um pool de AMF não alcança alta disponibilidade simplesmente com a implantação de várias instâncias de AMF. O gNB precisa manter continuamente uma visão atualizada das capacidades e do estado dos AMFs e usar essas informações ao tomar decisões de seleção. Só assim uma implantação com vários AMFs pode oferecer de forma efetiva compartilhamento de carga, escalabilidade elástica e manutenção planejada.

A mesma lógica é útil durante a solução de problemas. Comece confirmando se a associação SCTP está saudável e depois verifique se o NG Setup foi concluído com sucesso. Se a conexão continuar ativa, mas a distribuição de carga estiver anormal, verifique a sinalização AMF Configuration Update e RelativeAMFCapacity. Se o tráfego continuar sendo direcionado para um AMF que está sendo retirado de serviço, revise AMF Status Indication, as informações de disponibilidade GUAMI e o comportamento de reseleção de AMF.

Perguntas frequentes

Como distinguir rapidamente falhas de SCTP e falhas de NGAP em uma captura de pacotes?

Comece verificando se a associação SCTP foi estabelecida com sucesso. Se a troca INIT, INIT ACK, COOKIE ECHO e COOKIE ACK não for concluída, o problema ainda está na camada de transporte. Se o SCTP estiver estabelecido, mas nenhum NG Setup Response for recebido, ou se um erro no nível NGAP for retornado, a análise deve continuar nos parâmetros NGAP, na configuração TA, nas informações PLMN e nas configurações do lado do AMF.

RelativeAMFCapacity representa o número máximo de UEs que um AMF pode suportar?

Não. RelativeAMFCapacity é melhor entendida como um indicador de capacidade relativa usado dentro de um pool de AMF. Ela ajuda o NG-RAN a comparar a capacidade relativa de processamento de diferentes AMFs para fins de seleção. Não deve ser interpretada diretamente como um limite absoluto de assinantes.

Por que alterar apenas a configuração local do AMF não é suficiente quando as informações GUAMI mudam?

O gNB já armazenou informações de serviço do AMF obtidas pela interface N2. Se o AMF alterar sua configuração GUAMI sem notificar o NG-RAN, os dois lados podem ficar com visões inconsistentes da identidade do AMF e da disponibilidade do serviço. Por isso, as informações atualizadas precisam ser sincronizadas por meio do procedimento de gerenciamento NGAP correspondente.

AMF Status Indication sempre precisa incluir um Backup AMF Name?

Não. Backup AMF Name é opcional. Mesmo quando não é incluído, o NG-RAN ainda precisa processar os GUAMIs identificados como indisponíveis e executar o comportamento apropriado de gerenciamento e reseleção de AMF. Se Backup AMF Name estiver incluído e o NG-RAN suportar o procedimento correspondente, o AMF de backup especificado poderá ser considerado durante a reseleção.