Uma falha na rede central nem sempre é causada por falta de capacidade de processamento. Muitas vezes, o verdadeiro problema é o estado. Se uma função de rede falhar, mas o contexto do usuário continuar disponível em um local confiável, outra função poderá manter o serviço. Se o contexto desaparecer junto com o nó que falhou, a recuperação se torna muito mais difícil. Essa é a lógica por trás de uma das ideias importantes de projeto do 5GC: separar os recursos de computação dos recursos de armazenamento.

Em uma rede central móvel, o contexto do usuário pode incluir estado de registro, informações de mobilidade, identidades temporárias, dados relacionados à sessão, referências de localização e outros estados de serviço. Esses valores ajudam a rede a saber quem é o UE, onde ele está, qual sessão utiliza e como a sinalização posterior deve ser tratada. Quando esse contexto fica fortemente vinculado a uma única instância local de função de rede, essa instância deixa de ser apenas um nó de processamento e passa a representar um ponto único de risco para a continuidade do serviço.

O 5GC reduz esse risco ao oferecer maior suporte a funções de rede sem estado. Isso não significa que uma função de rede nunca use estado durante a operação. O ponto principal é que estados duradouros ou recuperáveis não devem ficar presos em uma única instância local de computação. Ao permitir que dados não estruturados, como o contexto do UE, sejam armazenados e recuperados por meio da UDSF, o 5GC oferece ao AMF e a outras funções de rede um modelo de recuperação mais flexível.

Por que o estado local cria riscos

O exemplo do MME no 4G facilita a compreensão do problema. Em uma rede LTE/EPC, depois que um UE conclui o procedimento de attach por meio do MME1, esse MME cria e armazena localmente o contexto do UE. O contexto pode incluir informações de gerenciamento de mobilidade e de sessão, como localização do UE, GUTI e parâmetros relacionados ao IP do UE.

Se o MME1 falhar inesperadamente, o MME2 ainda poderá estar fisicamente disponível no pool de MMEs. No entanto, a disponibilidade de outro MME não significa continuidade automática do serviço. Se o contexto do UE existir apenas no MME1, o MME2 não terá informações suficientes para continuar atendendo o UE de forma transparente. O usuário poderá ter de reiniciar o dispositivo ou realizar um novo attach antes que o serviço seja restabelecido. Do ponto de vista da experiência do usuário, esse é um modelo de recuperação inadequado.

Uma solução tradicional é usar um cluster de MME com sincronização ativo-standby. Nesse projeto, o contexto do UE é sincronizado em tempo real entre o MME ativo e o MME de espera. Se o MME ativo falhar, o nó standby pode assumir o serviço usando o contexto sincronizado. Essa abordagem pode reduzir a interrupção, mas também apresenta limitações. Ela pode depender de implementação específica do fornecedor, ter pouco suporte padronizado, elevar os custos e reduzir a portabilidade entre diferentes ambientes de sistema.

O problema mais profundo é que o estado local cria uma relação estreita entre uma instância de serviço e seus dados. Quando o nó de computação se torna o único detentor prático do contexto do usuário, o failover fica mais complexo. O 5GC avança para um modelo mais limpo ao colocar o estado recuperável em uma função de armazenamento separada, acessível às funções de rede autorizadas.

O que a UDSF muda

UDSF significa Função de Armazenamento de Dados Não Estruturados. Ela permite que qualquer função de rede do 5GC armazene e recupere seus dados não estruturados, incluindo o contexto do UE. Nesse modelo, o AMF ou outra NF pode processar a sinalização como função de computação, enquanto a UDSF fornece um local independente para manter determinadas informações de estado.

O conceito é semelhante ao de uma estação de trabalho sem disco. Esse tipo de estação possui CPU, memória, interface de rede e outros recursos de execução, mas não guarda os dados de trabalho em um disco rígido local. Ela inicializa e obtém os dados de um servidor de rede. A estação executa a computação, enquanto o armazenamento permanece separado. No 5GC, as funções de rede podem ser projetadas de forma semelhante: a NF executa a sinalização e a lógica de serviço, enquanto os dados de contexto podem ser armazenados fora da instância local.

O valor da UDSF não se limita a funcionar como um banco de dados. Seu valor arquitetural está no suporte ao projeto de NFs sem estado, à recuperação do AMF e a implantações nativas de nuvem mais flexíveis. Quando o estado está acessível por meio da UDSF, uma instância do AMF pode falhar sem causar necessariamente a perda permanente do contexto do UE. Um AMF recém-selecionado pode recuperar o contexto necessário e continuar o processamento quando ocorrer a próxima transação.

A UDSF também acompanha a direção mais ampla das redes centrais virtualizadas e nativas de nuvem. Em uma implantação em nuvem, as instâncias de funções de rede podem escalar horizontalmente, ser reduzidas, reiniciadas ou movidas pela infraestrutura. Se cada instância mantiver domínio rígido sobre seu estado local, a automação se torna difícil. Separar computação e armazenamento facilita o gerenciamento da expansão e da recuperação.

Como os tipos de dados diferem

Para compreender corretamente a UDSF, é importante distinguir dados estruturados de dados não estruturados. Na terminologia do 5GC, dados estruturados são aqueles cuja estrutura é definida pelas especificações do 3GPP. Os dados de assinatura são um exemplo típico, pois sua estrutura de recursos e seu modelo de acesso estão claramente descritos.

Dados não estruturados são aqueles cuja estrutura interna não é definida pelas especificações do 3GPP. O contexto do UE é um exemplo típico. Ele é essencial para a continuidade do serviço, mas sua organização interna exata não é padronizada da mesma forma que os dados de assinatura. Isso o torna adequado para armazenamento por meio da UDSF.

Essa diferença afeta o projeto de engenharia. Dados estruturados podem ser gerenciados por serviços de dados padronizados com modelos de recursos definidos. Dados não estruturados normalmente são produzidos e interpretados pela função de rede responsável pela lógica do serviço. A UDSF fornece a essa função um local para salvar e recuperar os dados sem obrigar que todo o formato interno seja convertido em uma árvore de dados padronizada.

No planejamento de implantação, os engenheiros não devem tratar todos os dados do 5GC como uma única categoria. Dados de assinatura, dados de política, estado de sessão, contexto temporário do usuário e informações de recuperação podem apresentar diferentes frequências de acesso, sensibilidades à latência, estruturas, responsabilidades e requisitos de recuperação. A UDSF concentra-se principalmente em armazenar o estado não estruturado de que as funções de rede precisam para manter resiliência e continuidade.

Como funciona a recuperação do AMF

Um processo típico de recuperação do AMF com UDSF segue uma sequência clara. Primeiro, um UE 5G se registra por meio do AMF1. O AMF1 cria o contexto do UE necessário ao gerenciamento de acesso e mobilidade. Em seguida, o AMF1 armazena esse contexto na UDSF. Nesse ponto, o estado do usuário deixa de ficar preso apenas à instância local do AMF.

Se o AMF1 falhar, a rede de acesso 5G ou as funções pares do plano de controle detectam a falha. O AMF que falhou deixa de ser considerado na seleção. Quando a rede precisa escolher outro AMF do mesmo conjunto de AMFs, ela pode selecionar o AMF2. É nesse ponto que a UDSF altera o comportamento de recuperação.

O AMF2 não precisa tratar o UE como um dispositivo totalmente desconhecido. Quando ocorre uma transação com o UE, o AMF2 pode recuperar o contexto do UE a partir da UDSF. A recuperação pode usar identificadores como SUPI, 5G-GUTI ou AMF UE NGAP ID. Depois de obter o contexto, o AMF2 pode processar a mensagem do UE e atualizar o 5G-GUTI junto ao UE, se necessário.

O resultado prático é uma melhor continuidade do serviço. A rede ainda precisa de detecção correta de falhas, nova seleção de AMF e lógica de recuperação de contexto, mas a base de recuperação é mais forte do que em um modelo no qual todo o contexto do usuário fica armazenado apenas no nó que falhou. Do lado do usuário, o resultado ideal é um processo que não exija reinicialização do dispositivo, novo attach manual nem interrupção perceptível do serviço.

Valor de engenharia e limitações

O principal valor de engenharia da separação entre computação e armazenamento é a resiliência. Se uma instância do AMF falhar, o estado do serviço ainda poderá estar disponível por meio da UDSF. Isso reduz a dependência do estado local do nó e ajuda a rede a se recuperar com menor impacto. Também oferece suporte à expansão elástica, pois novas instâncias de função de rede podem ser introduzidas sem que todo o estado histórico precise ser sincronizado localmente com antecedência.

O segundo valor é a portabilidade arquitetural. Em comparação com a sincronização ativo-standby específica de fornecedor, a UDSF faz parte da arquitetura do 5GC e se alinha melhor ao projeto padronizado de redes centrais nativas de nuvem. Ela permite uma abordagem mais aberta para armazenamento e recuperação de estado, em vez de prender a alta disponibilidade a um mecanismo privado de cluster.

Entretanto, a UDSF não elimina toda a complexidade. Ela se torna um componente crítico da cadeia de recuperação. Se a UDSF for lenta, indisponível, inconsistente ou mal protegida, poderá se transformar em um novo gargalo. Portanto, a própria UDSF deve ser projetada com alta disponibilidade, leitura e gravação rápidas, replicação confiável, controle seguro de acesso e capacidade de recuperação de desastres.

A escolha do banco de dados também importa. Bancos de dados relacionais e não relacionais podem aparecer em projetos relacionados à UDSF, dependendo da implementação do fornecedor e dos requisitos do sistema. A questão principal não é apenas qual tipo de banco de dados é usado, mas se toda a camada de armazenamento consegue atender aos requisitos de latência, confiabilidade, consistência e recuperação de nível de telecomunicações.

Para os engenheiros, as verificações mais importantes incluem confirmar se o contexto do UE é gravado na UDSF no momento correto, se o AMF recém-selecionado consegue recuperá-lo adequadamente, se a seleção do conjunto de AMFs funciona como esperado, se os identificadores são tratados de forma consistente e se o failover é realmente invisível ou quase invisível para o usuário. A separação só tem valor quando todo o caminho de recuperação é testado de ponta a ponta.

Perguntas frequentes

A UDSF é usada apenas pelo AMF?

Não. A UDSF foi projetada para qualquer função de rede que precise armazenar e recuperar dados não estruturados. A recuperação do AMF com o contexto do UE é apenas um dos exemplos mais claros.

Por que o contexto do UE é tratado como dado não estruturado?

O contexto do UE é importante, mas sua estrutura interna não é totalmente definida como uma estrutura de dados padronizada pelo 3GPP. Isso o torna adequado para armazenamento como dado não estruturado.

A UDSF substitui todo o estado local dentro das funções de rede?

Não completamente. As funções de rede ainda podem usar estado local temporário durante o processamento. A UDSF é usada principalmente para preservar dados não estruturados recuperáveis que não devem ser perdidos junto com uma única instância de computação.

A UDSF pode garantir ausência total de interrupção do serviço?

Não sozinha. Ela melhora a base da recuperação, mas a continuidade real também depende da detecção de falhas, da nova seleção do AMF, da atualidade dos dados, do comportamento da sinalização e da disponibilidade da UDSF.

O que deve ser testado antes de implantar a UDSF em produção?

Os testes devem abranger o momento de gravação do contexto, sua recuperação, a detecção de falha do AMF, a nova seleção do conjunto de AMFs, o failover do banco de dados, a latência de leitura e gravação, a segurança de acesso e a experiência real do UE durante a recuperação.

A separação entre computação e armazenamento no 5GC é mais do que um ajuste no banco de dados. Ela muda a forma como a rede central entende estado, falha e recuperação. Ao usar a UDSF para armazenar dados não estruturados, como o contexto do UE, as funções de rede podem depender menos do armazenamento local e se adaptar melhor a implantações resilientes e nativas de nuvem. A ideia essencial é simples: instâncias de computação podem falhar ou mudar, mas o estado do usuário deve continuar recuperável.