O software de código aberto fornece componentes de rede que você pode usar para simular funções de rede 5G desde o núcleo da rede até o rádio.
por Lincoln Lavoie, Laboratório de Interoperabilidade da Universidade de New Hampshire
O desenvolvimento e a implantação de uma infraestrutura laboratorial para apoiar o teste de sistemas 5G e de redes abertas de acesso por rádio (Open RAN) podem representar uma tarefa assustadora e complexa. Antes do Open RAN, essa tarefa só era possível através do envolvimento direto com os grandes fornecedores de sistemas de rede. Desde então, vários projetos e organizações de código aberto desenvolveram materiais baseados nas especificações 3GPP e O-RAN Alliance. Essas ferramentas e recursos possibilitam a criação de uma implantação 5G completa, abrangendo desde o núcleo móvel até a RAN, fornecendo recursos inestimáveis para os engenheiros.
As atividades de código aberto desempenham um papel importante porque permitem a rápida prototipagem e verificação das especificações. Essas especificações ainda podem estar em forma de rascunho. Muitos grupos de padronização desenvolveram práticas e políticas para promover o uso de código aberto. Esses grupos incluem a Força-Tarefa de Engenharia da Internet (IETF), diretrizes e práticas em torno de “consenso aproximado e código em execução”, e a Comunidade de Software Aberto (OSC) da Aliança O-RAN, que implementou programas formais.
Na verdade, um dos aspectos mais complexos que envolvem projetos e componentes de código aberto num laboratório de testes 5G é por onde começar. Neste artigo, discutiremos alguns componentes fundamentais que os engenheiros podem usar como blocos de partida e explicaremos como o software de código aberto pode oferecer suporte a testes Open RAN.
Para iniciar o processo, primeiro você precisa entender alguns dos principais componentes de uma rede 5G. Neste caso, generalizaremos a rede principal como um componente único, uma vez que múltiplas opções de código aberto implementam atualmente as funções da rede principal exigidas pelas especificações 3GPP. O núcleo móvel 5G compreende várias funções de rede individuais que permitem a arquitetura baseada em serviços definida pelo 3GPP.
Três exemplos bem conhecidos de sistemas de código aberto que implementam o núcleo 5G são o projeto Open 5GS, o projeto 5GC gratuito e o componente de rede central Open Air Interface 5G. Os dois primeiros projetos são implementações autônomas do núcleo 5G. Ao mesmo tempo, este último está mais estreitamente acoplado ao projeto maior Open Air Interface (OAI), que também pode fornecer a RAN.
Na UNH-IOL, usamos frequentemente o núcleo Open 5GS, que implantamos como dois conjuntos de componentes. Primeiro, implantamos os componentes de controle primários, incluindo a função de gerenciamento de acesso e mobilidade (AMF), a função de gerenciamento de sessão 5G (SMF) e outros. Segundo, implementamos a função de plano de usuário (UPF), que é responsável por encaminhar o tráfego de assinantes das interfaces RAN para a rede de dados (por exemplo, a Internet). Isso permite efetivamente a separação do plano de controle/usuário (CUPS), com essas funções implantadas em máquinas virtuais separadas. Da mesma forma, também poderíamos implementar várias instâncias UPF em implantações maiores para balancear a carga do tráfego de assinantes. Figura 1 mostra um pouco da logística dessa implantação em nosso laboratório.
Figura 1. A UNH-IOL implantou esta topologia Open 5GS para testes de interoperabilidade de componentes de rede 5G.
Do núcleo à RAN
Quando a rede principal estiver funcionando, o próximo foco provável será a RAN. Dentro deste espaço, chegaremos mais perto da vanguarda dos esforços de desenvolvimento de código aberto, dependendo das direções tomadas na implantação. A RAN fornece uma conexão RF entre o equipamento do usuário (UE) e a rede central móvel. Isso é uma simplificação exagerada, mas continuaremos com essa definição funcional sem nos aprofundarmos em alguns tópicos complexos, como handovers, suporte a múltiplas células, agregação de operadoras e assim por diante. Aqui, o fator mais significativo nos processos de seleção provavelmente se concentrará nos componentes de rádio, para os quais temos duas opções.
Primeiro, poderíamos implantar um sistema baseado em rádio definido por software (SDR) que aproveitasse o projeto Open Air Interface para fornecer o software e o firmware para implementar a RAN completa ou, mais precisamente, uma boa estação base. Dependendo do hardware SDR selecionado, pode ser possível conectar portas RF diretamente à antena. Com cuidado para evitar a violação de qualquer espectro licenciado, uma conexão RF ao dispositivo UE deverá ser possível. Por falar nisso, um laboratório também precisará de câmaras blindadas ou salas de isolamento de RF, mas isso está fora do escopo deste artigo.
Outra abordagem para implementar RAN segue as especificações da Aliança O-RAN, onde o gNodeB é desagregado em componentes discretos: unidade de rádio (RU), unidade distribuída (DU) e unidade centralizada (CU). Neste espaço, o projeto OAI pode fornecer algum software, nomeadamente os componentes DU e CU, que então implementam a interface Open Fronthaul (OFH) para o RU. Para a RU, é necessário selecionar um produto de um fornecedor porque atualmente não existem RUs de código aberto.
Para garantir a transmissão correta de sinais ou quadros de rádio, a DU e a RU precisam sincronizar o tempo e entendê-lo bem o suficiente para suportar a interface OFH. Novamente, múltiplas arquiteturas ou abordagens são possíveis, descritas como diferentes configurações LLS-C1 a LLS-C4. Em nosso laboratório, estamos atualmente implementando o LLS-C3, com um dos switches fronthaul servindo como relógio grandmaster IEEE-1588, que fornece a temporização para o RU e o DU. O suporte de carimbo de data/hora de hardware é necessário para a NIC no servidor DU e o projeto ptp4l é usado para sincronizar os relógios do servidor com a rede. Figura 2 mostra essa configuração no laboratório.
Figura 2. Para Open RAN, o laboratório usa essa topologia desagregada, que leva em consideração a limitação da rede.
Supondo que você usará dispositivos UE prontos para uso, como telefones, tudo está pronto para teste, certo? Bem, quase. Até agora, foram implantadas uma rede principal e uma rede de rádio. Salvo quaisquer problemas de configuração, o gNodeB deve ser registrado e conectado à rede principal. Deve fornecer pelo menos uma célula na banda 5G desejada para o UE se conectar. O UE deve autenticar-se na rede, o que depende do cartão SIM. No 5G, a autenticação funciona “nos dois sentidos”, onde o UE autentica a rede e a rede autentica o UE. Sem mergulhar em todos os detalhes, isso requer que as informações da rede, ou seja, algumas das chaves fornecidas na rede principal correspondam às chaves do cartão SIM, permitindo assim que o desafio/resposta criptográfica seja concluído com êxito. Não é possível (por boas razões) ler esses valores-chave de um cartão SIM.
Alguns cartões SIM são, entretanto, programáveis, normalmente para fins de teste. Assim, a última parte do hardware do laboratório é um pequeno leitor/gravador de cartões SIM, junto com os SIMs programáveis. Felizmente, do lado da programação, existem algumas ferramentas de código aberto que permitem programar os valores da chave de rede e os IDs do assinante no cartão SIM, possibilitando o sucesso da autenticação. As ferramentas que usamos no laboratório para essa finalidade são pysim e sysmo-usim-tool.
Usando ferramentas de código aberto, você pode colocar o dispositivo UE on-line com uma conexão 5G funcional no laboratório. Todo o trabalho aqui apenas arranha a superfície da rede 5G e das possibilidades de teste. Ainda assim, você deve habilitar um laboratório com recursos de código aberto capazes de suportar recursos mais avançados com configuração adequada, como fatiamento de rede ou agregação de operadora/célula, apenas para citar alguns tópicos possíveis.