Automatizando redes 5G com o serviço AWS Telco Network Builder

Por Marcelo da Silveira Sobrinho, Arquiteto de soluções para o setor de telecomunicações na AWS do Brasil,
Oscar Ramirez, Arquiteto de soluções na AWS do México e
Hugo Chimello, Arquiteto de soluções para o setor de telecomunicações na AWS do Brasil

Introdução

Espera-se que o número de implantações de redes 5G, públicas e privadas, aumente nos próximos anos. Neste cenário, é esperado que diferentes operadoras de redes móveis (Customer Service Providers – CSPs) em todo o mundo, considerem usar os serviços da AWS para acelerar seu tempo de lançamento de ofertas no mercado, reduzir seus altos investimentos iniciais em infraestrutura e focar em soluções inovadoras para monetizar sua rede 5G.

Mas, ao mesmo tempo em que a tecnologia 5G traz novas possibilidades para monetizar sua rede, ela também traz novos desafios. Por exemplo, como aproveitar os componentes nativos da nuvem. Esses novos conceitos aumentaram a dependência das operadoras em seus parceiros, fornecedores independentes de software (Independent Software Providers – ISVs), para implementar suas funções de rede 5G.

Do outro lado desta equação, os ISVs também estão sendo desafiados a acelerar os tempos de desenvolvimento e implementação das suas soluções. Por exemplo, como eles podem automatizar a implementação de funções de rede 5G para execução em regiões da AWS, AWS Local Zones ou AWS Outposts para cenários híbridos usando os mesmos artefatos? ou como eles podem integrar suas soluções de orquestração de redes para usar as APIs da AWS para implementar suas funções de rede 5G?

O que é o serviço AWS Telco Network Builder?

O AWS Telco Network Builder (AWS TNB) é um serviço da AWS que fornece as operadoras uma maneira eficiente de implementar, gerenciar e escalar suas redes 5G na AWS usando imagens de software em contêineres, de forma automatizada, seguindo o conceito de IaC (Infrastructure as Code).

As operadoras não precisam incorporar sozinhas um profundo conhecimento sobre os serviços da AWS. Em vez disso, elas podem descrever a infraestrutura de sua rede, seguindo às especificações dos padrões de virtualização de funções de rede do Instituto Europeu de Padrões de Telecomunicações (ETSI NFV), e o AWS TNB fornecerá a automação e a infraestrutura necessária para implementar suas funções 5G na AWS.

Como fazer uso do serviço AWS TNB?

Para usar o AWS TNB, as operadoras precisam fornecer:

1. Imagens de contêineres para cada função de rede 5G;
2. O arquivo de descritor de função de rede virtual (VNFD) para cada função 5G NF;
3. O arquivo do Network Service Descriptor (NSD) para cada implantação;
4. Os arquivos, Helm charts, utilizados pela aplicação Helm, descrevendo como será feita a implementação do software.

Como o AWS TNB se integra ao ecossistema das operadoras?

O AWS TNB oferece suporte à integração com os orquestradores de serviços das operadoras visando automatizar o fornecimento da infraestrutura necessária da AWS, implementar funções de rede em contêineres e configurar o gerenciamento de rede e acesso, criando um serviço de rede totalmente operacional. O serviço AWS TNB está alinhado com as seguintes especificações do grupo ETSI NFV:

O diagrama a seguir ilustra as integrações lógicas entre o serviço AWS TNB e as soluções de orquestradores de serviços das operadoras para implementar funções de rede usando interfaces padrões baseadas na especificação ETSI.

Fig 1. Topologia de referência para o serviço AWS TNB.

O serviço AWS TNB usa os arquivos de referência da Especificação de Topologia e Orquestração para Aplicativos em Nuvem (Topology and Orchestration Specification for Cloud Applications – TOSCA) para permitir esta integração. TOSCA é uma sintaxe declarativa que as operadoras podem usar para descrever uma topologia de serviços em nuvem, seus componentes, relacionamentos e os processos que os gerenciam. Em um modelo TOSCA, as operadoras descrevem os pontos de conexão, os links lógicos entre os pontos de conexão e as políticas, como afinidade e segurança.

O AWS TNB também oferece a capacidade de realizar operações de gerenciamento do ciclo de vida por meio da console de gerenciamento AWS, via interface AWS CLI, via API REST do AWS TNB e SDKs. As operadoras podem então, usar modelos para implantar repetidamente várias configurações desse pacote, especificando modelos de serviço de rede e detalhando a infraestrutura e as funções de rede a serem implementadas.

O AWS TNB permite usar a substituição de parâmetros para implementar configurações diferentes em locais diferentes e fornece total visibilidade destas implementações.

Fig 2. AWS Telco Network Builder ciclo de vida.

Na imagem acima, você pode ver algumas tarefas que cada equipe pode realizar ao utilizar o serviço AWS TNB:

• Equipes de desenvolvedores e engenheiros criando modelos de funções de rede e serviços de rede;
• Equipes de operações que instanciam o serviço ou a função de rede necessária.

Agora, vamos ver como reunir todas as informações e arquivos necessários para se beneficiar dos recursos de gerenciamento do ciclo de vida fornecidos pelo serviço AWS TNB.

Imagens de contêineres

Como mencionamos anteriormente, as operadoras dependerão das imagens de contêiner dos ISVs para implantar suas funções de rede 5G, e essas imagens devem ser carregadas em um repositório privado com o objetivo de cumprir os requisitos de segurança. Em nosso caso, o serviço Amazon Elastic Container Registry (Amazon ECR) permite que o procedimento de instanciação do AWS TNB extraia essas imagens de contêineres e, em seguida, implemente no Amazon Elastic Kubernetes Service (Amazon EKS).

O Amazon ECR oferece suporte a algumas funcionalidades importantes, como escaneamento de imagens, que ajuda a identificar vulnerabilidades de software em imagens de contêineres. Os seguintes tipos de escaneamento são oferecidos:

• Escaneamento avançado – suas imagens de contêineres são verificadas quanto a vulnerabilidades em sistemas operacionais e pacotes de idiomas de programação
• Escaneamento básico – o Amazon ECR usa o banco de dados de vulnerabilidades e exposições comuns (CVEs) do projeto de código aberto Clair.

Então, vamos começar criando um repositório privado e fazendo o upload das imagens dos contêineres. Usaremos os comandos da interface AWS CLI para essa finalidade.

A documentação completa da AWS sobre como instalar a interface AWS CLI, criar uma imagem de contêiner e enviá-la para o repositório pode ser encontrada no link abaixo:

https://docs.thinkwithwp.com/pt_br/AmazonECR/latest/userguide/getting-started-cli.html#cli-create-repository

• Criar um repositório

Crie um repositório chamado amf-repository para o qual enviará a imagem amf:latest. Para criar um repositório, execute o seguinte comando:

• Enviar uma imagem ao repositório Amazon ECR

Envie a imagem para o repositório Amazon ECR. Há alguns pré-requisitos que devem ser satisfeitos para que isso funcione corretamente:

• A versão mínima do docker que está instalada deve ser a 7;
• O token de autorização do Amazon ECR foi configurado com docker login;
• O repositório do Amazon ECR deve existir, e o usuário deve possuir permissão de acesso para enviar imagens ao repositório.

a. Liste as imagens que você armazenou localmente para identificar a imagem a ser marcada e enviada

b. Marque a imagem a ser enviada ao seu repositório

c. Envie a imagem

• Extrair uma imagem do Amazon ECR

Depois que a imagem do contêiner da operadora for enviada para o repositório Amazon ECR, você poderá extrai-la utilizando o comando abaixo.

Pacotes de funções de rede

Agora que as imagens foram enviadas para o repositório privado do Amazon ECR, vamos criar os pacotes de funções de rede

Com o serviço AWS TNB, as operadoras podem armazenar pacotes de funções de rede que estejam em conformidade com o padrão ETSI SOL001/SOL004 em um catálogo de funções. Em seguida, elas podem carregar pacotes de arquivos Cloud Service Archive (CSAR) que contêm artefatos descrevendo sua função de rede. Um pacote CSAR é um arquivo zip que está em conformidade com a especificação YAML do OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA)

As operadoras precisam fornecer informações para as seções AWS.VNF e AWS.Artifacts.Helm, conforme o exemplo abaixo do arquivo:

A parte da seção Helm especifica o caminho onde estão localizados os arquivos, Helm charts, que serão usados na implementação da função de rede, e fazem parte do arquivo CSAR.

Fig 3. Exemplo do arquivo VNFD.

A especificação completa do modelo de referência AWS TNB VNFD pode ser encontrada aqui:

https://docs.thinkwithwp.com/pt_br/tnb/latest/ug/vnfd-template.html

Depois de criar um pacote de funções para cada função de rede, é hora de criar um pacote de rede para a rede definindo as funções a serem implantadas em conjunto (por exemplo, AMF, SMF, UPF etc.) e fazendo o upload do arquivo descritor de serviço de rede (Network Service Descriptor – NSD).

O serviço AWS TNB armazena os descritores de serviços de rede (NSDs) sobre as funções de rede que as operadoras desejam implementar e como desejam fazê-lo no catálogo. Elas podem fazer o upload do arquivo YAML NSD, conforme descrito pelo padrão ETSI SOL007, para incluir:

• Função de rede que você deseja implementar;
• Instruções de rede;
• Instruções de computação;
• Lifecycle hooks (scripts personalizados).

O serviço AWS TNB oferece suporte aos padrões ETSI para a modelagem de recursos, como rede, serviço e função na linguagem TOSCA.

A seção vnfds no arquivo NSD é a conexão entre os arquivos VNFD e NSD.

A informações para o campo descriptor_id, fornecidas na seção tosca.nodes.aws.vnf em cada um dos arquivos VNFD anteriores, devem ser as mesmas fornecidas no arquivo NSD. Por exemplo:

Fig 4. Exemplo do arquivo NSD.

Fig 5. Exemplo da seção vnfds no arquivo NSD.

Há outra seção muito importante no arquivo NSD (topology_template), e descreveremos algumas subseções desta parte para fornecer mais detalhes.

Inputs sub-section – A subseção Inputs é usada para descrever valores padrões que podem ser usados em outras partes do modelo. Por exemplo, definimos na subseção inputs do nosso modelo NSD, o valor da variável vpc_cidr_block. E posteriormente, na subseção node_templates, é possível fazer referência a essa variável, permitindo flexibilidade para reutilizar o modelo para outras implantações. Veja abaixo um exemplo desse procedimento.

Fig 6. Exemplo da seção inputs no arquivo NSD.

Fig 7. Exemplo da seção topology_template – node_templates do arquivo NSD referenciando a seção input.

node_templates sub-section – Essa subseção é a maior parte da seção topology_template no arquivo NSD, e explicaremos a importância desses atributos para a correta parametrização pelas operadoras.

Vamos começar com:

• nodes.AWS.Compute.EKSManagedNode;
• nodes.AWS.Compute.EKSSelfManagedNode.

Esses atributos definem as características da implantação do cluster EKS ao usar o serviço AWS TNB.

Os grupos de nós gerenciados pelo Amazon EKS automatizam o provisionamento e o gerenciamento do ciclo de vida dos nós, instâncias do Amazon Elastic Compute Cloud (Amazon EC2), para clusters do Amazon EKS Kubernetes. Com os grupos de nós gerenciados pelo Amazon EKS, as operadoras não precisam provisionar ou registrar separadamente as instâncias do Amazon EC2 que fornecem capacidade computacional para executar seus aplicativos Kubernetes. Elas podem criar, atualizar ou encerrar os nós automaticamente em seu cluster com uma única operação. As atualizações e terminações de nós drenam automaticamente os nós para garantir que os aplicativos permaneçam disponíveis.

Cada nó gerenciado é provisionado como parte de um grupo auto escalável do serviço Amazon EC2 gerenciado pelo serviço Amazon EKS. Todos os recursos, incluindo as instâncias e os grupos auto escaláveis, são executados na conta das operadoras na AWS. Cada grupo de nós é executado em várias zonas de disponibilidade definidas pelas próprias operadoras.

As operadoras também podem adicionar um grupo de nós gerenciados em clusters novos ou existentes usando a console do serviço Amazon EKS, a linha de comando eksctl, a interface AWS CLI, a API da AWS ou o AWS CloudFormation. Os nós lançados como parte de um grupo de nós gerenciados são automaticamente marcados para descoberta automática pelo autoescalador do cluster Kubernetes. E as operadoras podem usar o grupo de nós para aplicar rótulos (TAGs) do Kubernetes aos nós e atualizá-los a qualquer momento.

Ao selecionar grupos de nós autogerenciados do Amazon EKS, um cluster contém um ou mais nós do Amazon EC2 nos quais os pods estão programados. Os nós do Amazon EKS são executados na conta AWS das operadoras e se conectam ao plano de controle do cluster por meio do endpoint do servidor da API do cluster. É possível implementar um ou mais nós em um grupo de nós. Um grupo de nós é composto por uma ou mais instâncias do Amazon EC2 que são implementadas em um grupo auto escalável do Amazon EC2. O grupo autogerenciado é recomendado quando o cliente deseja ter controle do escalonamento automático do grupo de nós para diferentes aplicativos em execução em cada nó.

Outras informações muito importantes a serem fornecidas no arquivo NSD estão relacionadas às funções de IAM (IAM Roles) que executarão os procedimentos em diferentes recursos da AWS. Essas funções de IAM diferentes são necessárias em várias subseções dentro do arquivo NSD, por exemplo:

Fig 8. Função do IAM requerida no arquivo NSD na subseção tosca.nodes.AWS.Compute.EKS.

Fig 9. Função do IAM requerida no arquivo NSD na subseção tosca.nodes.AWS.Compute.EKSManagedNode.

Fig 10. Função do IAM requerida no arquivo NSD na subseção tosca.nodes.AWS.HookDefinition.

Abaixo, você pode ver um exemplo do nosso arquivo NSD que pode ajudar a orientar como podem ser definidas as funções necessárias em seus arquivos NSD.

Fig 11. Exemplo de arquivo NSD com as funções de IAM requeridas.

A especificação completa do modelo de referência AWS TNB NSD pode ser encontrada aqui:

https://docs.thinkwithwp.com/pt_br/tnb/latest/ug/nsd-template.html

Agora que explicamos sobre os arquivos necessários e eles foram criados, é hora de interagir com o serviço AWS TNB.

Neste blog, usaremos a console AWS TNB para mostrar como podemos criar e gerenciar as redes 5G.

A primeira etapa é criar o pacote de funções necessário para cada função de rede 5G (AMF, SMF, UPF, etc.) fazendo o upload do respectivo arquivo zip CSAR e depois:

• Faça login na console da AWS;
• Selecione o serviço AWS TNB;
• Selecione a opção Pacotes de funções no menu esquerdo do console;
• Clique em Criar pacote de funções. Quando a janela aparecer, escolha o respectivo arquivo zip CSAR contendo o arquivo VNFD e as charts do Helm a serem carregados.
• Clique em Avançar.

Fig 11. Crie um pacote de funções na console da AWS.

As operadoras podem criar um catálogo completo de funções de rede de seus diferentes ISVs na seção de pacotes de funções do AWS TNB e, em seguida, combinar suas opções de implementação utilizando-se do arquivo NSD para definir.

Fig 12. Criação de catálogo de pacotes de funções na console da AWS.

Um aspecto importante a ser mencionado aqui é que o valor do campo VNFD ID na console do serviço AWS TNB é o mesmo que usamos anteriormente no arquivo VNFD, então é fácil encontrar o ID da função para posterior reutilização.

Uma vez criado o catálogo de funções de rede no AWS TNB, estamos prontos para criar o pacote de rede para implementá-lo como parte do nosso blog. As etapas necessárias para criar o pacote de rede são muito semelhantes as anteriores que fizemos para criar o pacote de funções de rede:

• Selecione o serviço AWS TNB;
• Selecione a opção Pacotes de rede no menu esquerdo do console;
• Clique em Criar pacote de rede e escolha o arquivo CSAR com o arquivo NSD a ser carregado;
• Clique em Avançar.

Fig 13. Criação de catálogo de pacotes de rede na console da AWS.

Depois de carregar o arquivo CSAR, o pacote de rede valida o arquivo NSD antes de criar o pacote de rede, atribuindo um número, Package ID, conforme mostrado na tela abaixo.

Finalmente, para fazer a implementação do pacote de rede, basta selecionar o pacote de rede necessário, selecionar o menu suspenso na opção “Ações” e clicar em “criar instância de rede”.

Depois de selecionar, o AWS TNB fará a implementação do pacote de rede na infraestrutura da AWS e todo este processo permite validar, por meio da console, todas as etapas executadas pelo AWS TNB para concluir a ação solicitada.

AWS TNB Pricing

Há duas dimensões ao usar o serviço AWS TNB:

• Horas do item de função de rede gerenciado (MNFI);
• Número de solicitações de API. Você também incorre em cobranças adicionais pelos outros serviços utilizados em conjunto com o AWS TNB.

Horas do item de função de rede gerenciada

Cada função de rede que você cria com o AWS TNB se torna um item de função de rede gerenciada (MNFI), que é a unidade usada para faturamento.

As operadoras pagam por hora por cada MNFI em sua rede de telecomunicações. As cobranças horárias da MNFI começam quando é instanciada a rede de telecomunicações à qual uma função de rede pertence. As cobranças por hora terminam quando você encerra essa rede de telecomunicações e as cobranças são rateadas por minuto em horas parciais.

Os outros serviços são pagos separadamente. Por exemplo, alguns serviços da AWS que são necessários para executar funções de rede na infraestrutura da AWS são: Amazon Elastic Compute Cloud (EC2), Elastic Load Balancing (ELB) e Amazon Simple Storage Service (S3) somente para citar alguns.

Solicitações de API

As operadoras podem usar a interface AWS CLI, os AWS SDKs ou a console do serviço AWS TNB para fazer chamadas de API, como CREATE, UPLOAD, INSTANTIATE, TERMINATE, UPDATE, GET, POST, ENABLE/DISABLE e LIST, para citar alguns. Serão cobradas as solicitações de API quando excederem 45.000 solicitações por mês, por região da AWS, em todas as funções de rede que são gerenciadas usando-se o AWS TNB.

Alguns exemplos de preços podem ser encontrados no link a seguir.

https://thinkwithwp.com/tnb/pricing/

Conclusão

Neste post, descrevemos alguns recursos do serviço AWS TNB que visam melhorar as operações de rede pelas operadoras, permitindo que elas se concentrem nas estratégias de monetização de sua rede 5G. Para resumir, esses são os recursos proporcionados pelo serviço AWS TNB:

• Acelera a implementação de infraestrutura e serviços de rede baseados em nuvem enquanto faz uso de padrões do setor de telecomunicações;
• Funciona como um serviço central para implementar, e atualizar funções e serviços de rede na nuvem da AWS;
• Monitora e supervisiona as funções de rede e os serviços da AWS a partir de um painel centralizado.

References

https://docs.thinkwithwp.com/pt_br/tnb/index.html

https://www.etsi.org/committee/nfv

Sobre os autores

Marcelo Sobrinho é um arquiteto de soluções para o setor de telecomunicações na AWS. Marcelo possui mais de 23 anos de experiência no mercado de tecnologia, sendo reconhecido como um técnico advisor por seu conhecimento no setor, tendo participado em muitos projetos com entregas de soluções para redes móveis.

Oscar Ramirez é um arquiteto de soluções para clientes corporativos na AWS do México.

Hugo Chimello é arquiteto de soluções de para o setor telecomunicações e trabalha há 5 anos na AWS. Ele trabalha para auxiliar os clientes em suas transformações, modernizações e migrações digitais. Seu profundo conhecimento de análise de dados foi fundamental para ajudar vários clientes durante seu tempo na AWS.