É quase impossível falar de 5G sem usar termos como “game-changing”, “revolucionário” e “avanço”. Enquanto nós que escrevemos sobre o assunto ficamos inclinados a utilizar muito essas palavras; e isso não é exagero: padrões 5G são muito mais ambiciosos do que as capacidades de redes legadas e LTE (long-term evolution).
Mas para entregar o que as redes 5G prometem, tanto dispositivos quanto aplicações que as utilizam terão de ser o mais eficientes possível. Cumprir com algo tão grande é quase impossível sem quebrá-lo em componentes menores e fáceis de gerenciar – e é exatamente o que aplicações modernas fazem. Hoje, examinaremos o papel dos microsserviços em redes 5G.
Aplicações monolíticas vs. microsserviços
Anteriormente, ainda nesta série de artigos, discutimos como as aplicações evoluíram de monolíticos – que eram construídas e lançadas de uma só vez – para coleções de funções independentes (ou microsserviços).
Esses componentes pequenos e self-contained são individualmente projetados para fazer bem uma tarefa, e são desenvolvidos e lançados como tal. Isso facilita o desenvolvimento e permite que novos recursos sejam implantados sem impactar toda a aplicação.
Microsserviços não somente tornam as aplicações vastamente fáceis de desenvolver e implantar, eles vêm com outros benefícios preciosos:
- fácil de escalar;
- habilita gerenciamento e automação serverless;
- baixa latência; e
- eficiência de recursos.
Mas talvez o benefício de longo prazo mais importante de microsserviços é que eles são necessários para interagir com arquiteturas de rede 5G. Para compreender os motivos pelos quais aplicações e redes devem ser projetadas dessa forma, é importante, primeiramente, relembrar o que o 5G se propõe a fazer.
Requisitos para o 5G
Conforme discutimos nas publicações anteriores, as vantagens do 5G em comparação ao 4G e demais redes legadas podem ser divididas em três categorias de comunicação:
- Extreme mobile broadband (eMBB): performance aprimorada de dispositivos móveis para consumidores que permite downloads mais rápidos, maiores transmissões de dados, menor latência e maior densidade de dispositivos;
- Ultra-reliable low-latency communications (URLCC ou IoT Crítica): serviços de missão crítica que dependem de latência ultrabaixa, em milissegundos, como condução de veículos automatizada;
- Massive machine-type communications (mMTC ou IoT Massiva): altas quantidades de sensores e outros dispositivos IoT com baixo consumo de energia e transmissões não frequentes para utilização em fábricas e cidades inteligentes.
Todos esses três casos de uso têm KPIs incrivelmente exigentes em termos de latência, throughput, confiabilidade e outros aspectos, mas os requisitos específicos são um pouco diferentes, requerendo diferentes implantações de rede para corresponder às suas necessidades. Implementações flexíveis não são apenas necessárias para entregas ágeis, mas, também, para assegurar que as redes 5G possam interagir e negociar com redes LTE até que elas se tornem suficientemente escaláveis.
Como resultado, redes 5G são construídas do zero para serem altamente modulares e interoperáveis. Hoje, falaremos sobre dois de seus princípios de arquitetura que fornecem tais qualidades: divisão de rede e CUPS, que significa “control and user plane separation” (ou controle e separação do plano do usuário, em português).
Princípios de arquitetura do 5G
Divisão de rede (network slicing)
Trata-se de um princípio de arquitetura de redes 5G que permite agilidade na entrega de diferentes QoS para várias aplicações ou funções de aplicação. O ITU define muito bem o funcionamento de uma divisão de rede como “uma rede lógica que atende a um cliente ou a uma finalidade comercial definida, consistindo em todos os recursos de rede necessários configurados juntos”. Isso inclui o PLMN (control plane, user plane network functions) e acesso à rede 5G, e pode abranger serviços de um único operador ou incorporados de múltiplos operadores.
Em outras palavras, um “slice” é um pedaço de uma rede 5G que inclui todos os componentes individuais necessários para executar uma aplicação na rede – mais ou menos como os contêineres dividem VMs em unidades individuais cumprindo todos os requisitos para executar um microsserviço específico. Assim como contêineres têm de ser orquestrados para rodar e escalar uma aplicação conforme necessário, esse tipo de orquestração monitora e gerencia o ciclo de vida dos slices de rede, atribuindo recursos automaticamente e criando, modificando e deletando slices a fim de otimizar a performance.
Divisão vertical vs. horizontal
Slicing de rede pode ser feito horizontal ou verticalmente, sendo a primeira opção discutida mais frequentemente. Slicing horizontal divide uma rede de acordo com os SLAs de cada aplicação – ou, mais especificamente, as funções individuais desta. Isso permite que casos de uso envolvendo URLLC, mMTC e eMBB sejam entregues separadamente e habilita mais customização acerca de como latência, eficiência energética e outros KPIs são priorizados.
Em contraste, o slicing vertical divide uma rede por negócios, colocando o controle de determinado slice nas mãos da própria empresa. Isso faz com que elas tenham mais autonomia, eliminando a necessidade de operadores de rede para fazer a intermediação.****
Slicing horizontal
- Multitenant
- Redes são divididas por funções
- Operadores controlam os recursos
- Serviços podem ser customizados para apps, usuários, dispositivos ou contextos específicos
Slicing vertical
- Single tenant
- Redes são divididas por empresas
- Empresa controla recursos
- Serviços podem ser customizados para apps, usuários, dispositivos ou contextos específicos
Independentemente de o slice ser feito horizontal ou verticalmente, a capacidade de criar múltiplas redes com infraestrutura compartilhada não só resulta em melhor desempenho, mas oferece vários benefícios práticos para as operadoras, tais como eficiência de custo e preços que se ajustam às necessidades. No entanto, localizar e dimensionar recursos para divisão de rede eficiente requer uso de outro princípio de arquitetura 5G: o CUPS.
CUPS
Separar o controle e os planos de usuário não é novidade. A arquitetura principal do 4G LTE, o Evolved Packet Core (EPC), introduziu essa ideia às redes móveis como um meio de fornecer um serviço mais flexível aos usuários de dispositivos móveis. Isso era fundamental para acomodar o uso de dispositivos mais prevalecentes e menos previsíveis, variando entre pacotes pequenos e intermitentes enviados por sensores IoT a filmes completos transmitidos em smartphones. Separar o plano de controle (que decide como os pacotes devem ser encaminhados) do plano do usuário (que encaminha os pacotes) tornou mais fácil lidar com essas circunstâncias variadas.
EPC vs. 5GC
No entanto, nem todos os elementos dos planos de usuário e controle são completamente separados no EPC. O stack de protocolo EPC inclui Mobility Management Entity Protocols (MME), o serving gateway (SGW) e packet data gateway (PGW). Cada vez mais, as redes móveis vêm incluindo outro elemento, a função de detecção de tráfego (traffic detection function - TDF).
No EPC, os planos de controle e usuário são separados para o MME, que cuida de uma série de funções importantes, como balanceamento de carga entre diferentes SGWs. No entanto, os próprios gateways (bem como o TDF) compartilham funções entre o plano de controle e do usuário, criando gargalos conforme o uso do dispositivo se intensifica.
Atualmente, a popularidade do streaming de vídeo e outras aplicações que consomem dados em grande escala já pressionam os SGWs. Uma vez que o 5G acelerará a quantidade de dados que usuários individuais estão consumindo, o core do 5G (5GC) é projetado para resolver esse problema separando o controle e a funcionalidade do plano do usuário para SGW, PGW e TDF.
Benefícios do CUPS
Ao separar completamente o controle e o plano do usuário do EPC, o CUPS permite que os ambos sejam hospedados em locais distintos, com um plano de controle centralizado e um plano do usuário mais próximo dos usuários finais. Além disso, permite que os dois planos sejam escalonados um do outro de forma independente, sem afetar sua funcionalidade. Isso resulta em uma série de benefícios melhor resumidos pelo 3GPP em sua especificação da versão 14 do CUPS:
- latência reduzida em serviços de aplicação;
- tráfego de dados mais amplo;
- habilidade de localizar, evoluir e escalar recursos de CP e UP com independência;
- Entrega mais eficiente de dados de plano do usuário por meio de rede definida por software (Software Defined Networking - SDN).
Design de app moderno para arquitetura 5G
Assim como as redes em que serão executados, aplicações 5G também precisam ser altamente modulares e interoperáveis. Aplicações monolíticas não podem acomodar princípios de arquitetura 5G, como divisão de rede, que exige que a funcionalidade seja dividida e automatizada para atender a diferentes QoSs. Além disso, o CUPS foi projetado para aproximar o plano do usuário dos usuários finais, exigindo que os aplicativos sejam o mais leves possível para acomodar a escassez de recursos do Multi-Access Edge Computing.
Por fim, dividir as aplicações em microsserviços e funções permite que sejam mais interoperáveis e reutilizáveis. O Network Slicing e CUPS são habilitados pela arquitetura baseada em serviços do 5G, consistindo em diferentes funções de rede que interagem por meio de APIs para consumir e produzir serviços.
Conclusão
Os elementos de design modular das redes 5G exigirão que os aplicativos monolíticos sejam completamente reprojetados para 5G. No entanto, a transição para a arquitetura de aplicativo moderna pode ser um desafio. O uso de uma abordagem serverless pode simplificar essa transição, evitando dificuldades de provisionamento, dimensionamento e manutenção dos recursos subjacentes necessários para executar funções individuais. Além disso, gerir aplicações de próxima geração é uma tarefa complexa, que requer Virtual Network Functions (VNF) definidos por software para permitir automação e orquestração de recursos de base.
Os produtos de Edge Computing da Azion são feitos para empresas construírem e executarem aplicações modernas com mais facilidade. O Azion Edge Functions, por exemplo, permite criar funções serverless para uma transição suave de aplicações legadas para uma arquitetura baseada na edge. Com o Edge Functions, você pode executar funções orientadas a eventos na extremidade da rede, escrevendo seu próprio código personalizado ou escolhendo entre as funções existentes do Edge Firewall ou do Edge Application. Como você só paga quando seu código é executado, ele permite que você migre workloads com máxima economia.
Além disso, o Azion Edge Orchestrator permite que os clientes implementem e gerenciem NFVs (Network Functions Virtualization) no Edge. O Edge Orchestrator é altamente interoperável e foi criado para operar na maioria das arquiteturas de rede e tipos de devices, para que você possa construir infraestruturas de Edge, conectar-se ao 5GC e automatizar, gerir e controlar recursos de Edge em tempo real.
Em nosso próximo post da série, daremos uma olhada em um dos recursos mais interessantes descritos no lançamento mais recente do 3GPP: a criação de redes 5G privadas. A capacidade das empresas de criar redes personalizadas adaptadas às necessidades exclusivas de suas organizações permite novas oportunidades de negócios, que examinaremos na postagem da próxima semana, juntamente com alguns dos outros recursos 5G especificados na versão 16 do 3GPP.
