Como Garantir QoS em Aplicações Críticas Numa Rede Privativa 4G/5G

Redes privativas LTE e 5G oferecem algo que nenhuma rede pública consegue garantir: controle total sobre como o espectro de rádio é distribuído entre as aplicações que dependem dela.

Numa rede 4G ou 5G, todas as aplicações competem pelo mesmo espectro de rádio. Sem QoS configurado corretamente, um fluxo de vídeo pode roubar banda de um sistema de controle industrial, e nenhum alarme vai disparar até que o dano já tenha acontecido.

Ambientes industriais, agropecuários e logísticos que operam redes privativas geralmente acumulam tipos de tráfego com requisitos radicalmente diferentes: câmeras de segurança gerando streams contínuos de alta largura de banda, sensores IoT enviando pacotes mínimos a cada poucos segundos, sistemas SCADA com exigências rígidas de latência baixa, e comunicações de voz entre operadores de campo.
Sem segmentação e priorização, esses fluxos concorrem de forma igualitária, o que, na prática, significa que os mais críticos ficam expostos às variações causadas pelos menos críticos.

Este artigo explica como funciona o QoS em redes privativas 4G/5G, quais mecanismos estão disponíveis e como um integrador pode estruturar as políticas para garantir desempenho previsível nas aplicações que não podem falhar.

O que QoS significa numa rede privativa

QoS - Quality of Service - é o conjunto de mecanismos que permite à rede tratar pacotes de dados de forma diferenciada conforme o tipo de aplicação e sua criticidade. Numa rede IP genérica, isso é implementado principalmente via DSCP (Differentiated Services Code Point), um campo de 6 bits no cabeçalho IPv4/IPv6 que classifica o pacote em até 64 categorias de prioridade.

Em redes celulares LTE e 5G, o mecanismo nativo é mais granular: o padrão 3GPP define os QoS Class Identifiers (QCI), identificadores de classe que associam cada fluxo de dados - chamado "bearer" - a um perfil específico de prioridade, taxa garantida, orçamento de latência e taxa de erro aceitável. Cada QCI corresponde a um tipo de serviço: voz em tempo real (QCI 1), sinalização IMS (QCI 5), streaming de vídeo (QCI 6), dados gerais de melhor esforço (QCI 9), entre outros.

A distinção fundamental entre bearers GBR (Guaranteed Bit Rate) e não-GBR define como a rede se comporta sob carga. Bearers GBR reservam recursos de rádio e garantem que a taxa mínima estará disponível independentemente do que os demais dispositivos estejam fazendo. Bearers não-GBR operam em regime de melhor esforço e são os primeiros a sofrer quando o espectro está congestionado.

Para aplicações de controle industrial, sistemas SCADA, alarmes de segurança e comunicações de voz em campo, a escolha do bearer correto e a configuração de GBR no core da rede para o seu caso particular fazem parte das boas práticas para atender requisitos de desempenho e confiabilidade.

A camada de rádio: onde o QoS começa de verdade

O QoS numa rede celular privativa não é apenas uma política configurada no core. Ele começa no eNodeB (4G) ou gNodeB (5G) - a estação rádio base que serve os dispositivos. O scheduler de rádio é o componente responsável por distribuir os blocos de recursos de rádio (Resource Blocks) entre os dispositivos conectados a cada milissegundo.

Um scheduler de rádio bem configurado em eNodeBs de qualidade, como os da linha Baicells Nova fornecidos pela Telesys, respeita os QCI atribuídos a cada UE (dispositivo) e prioriza os bearers GBR quando há contenção. Mas essa priorização só funciona se o core da rede tiver sido configurado para estabelecer os bearers corretos no momento da autenticação do dispositivo.

Isso significa que a política de QoS precisa ser implementada de ponta a ponta: do HSS (Home Subscriber Server) - que define o perfil de assinante de cada dispositivo, passando pelo PGW (Packet Data Network Gateway) que aplica as políticas, até o eNodeB que as executa no ar.

Network Slicing no 5G: QoS por arquitetura

Redes privativas baseadas em 5G introduzem um mecanismo mais poderoso que a simples configuração de QCI: o Network Slicing. Em vez de priorizar fluxos dentro de uma única rede, o slicing cria redes lógicas completamente separadas sobre a mesma infraestrutura física, cada uma com seus próprios recursos de rádio, core e políticas.

Para um ambiente industrial com requisitos heterogêneos, o slicing permite estruturar, por exemplo: um slice URLLC (Ultra-Reliable Low-Latency Communication) dedicado exclusivamente aos sistemas de controle e automação, com latência garantida abaixo de 5 ms; um slice eMBB (enhanced Mobile Broadband) para câmeras de vigilância e sistemas de visão computacional; e um slice mMTC (massive Machine-Type Communication) para sensores IoT de baixo consumo e transmissão esporádica.

O padrão 3GPP define esses três tipos de serviço como as classes fundamentais do 5G. Cada slice opera como uma rede independente do ponto de vista do desempenho, o congestionamento num slice não afeta os demais.

Configuração prática: o que observar para evitar problemas comuns

Em muitos projetos de redes privativas com desafios de QoS, o ponto de atenção nem sempre está nos equipamentos, mas na etapa de mapeamento das aplicações antes da configuração. Entender quais fluxos existem, quais são mais críticos e qual é a sensibilidade de cada um à latência e à perda de pacotes é o que permite definir políticas de QoS mais adequadas ao ambiente.

• A primeira é manter todos os dispositivos no bearer padrão (QCI 9, melhor esforço), sem diferenciação por perfil de assinante no HSS. Nesse cenário, câmeras de alta resolução e sensores SCADA acabam compartilhando os mesmos recursos de rádio sem priorização adequada.
• A segunda é configurar QoS apenas no core, sem validar se o eNodeB aplica corretamente os parâmetros ou se o scheduler de rádio do equipamento oferece suporte efetivo às políticas definidas.
• A terceira é deixar de avaliar o comportamento da rede sob carga. Muitos desafios relacionados à QoS só se tornam visíveis quando o tráfego total se aproxima do limite do espectro disponível.

Um dimensionamento correto começa com o inventário de aplicações: tipo de tráfego, volume, frequência, sensibilidade à latência e à perda de pacote. A partir disso, define-se a segmentação de bearers, os perfis de assinante no HSS e os parâmetros de scheduler no eNodeB e valida-se tudo com tráfego sintético antes do go-live.

O papel do core local na garantia de QoS

Uma rede privativa com core hospedado localmente (on-premises) tem uma vantagem estrutural sobre configurações com core em nuvem: a latência de processamento entre o eNodeB e o PGW/UPF é mínima. Em implementações locais típicas, a latência end-to-end fica entre 5 ms e 15 ms, valores que tornam viáveis aplicações de controle em tempo real que seriam impossíveis sobre redes públicas ou cores remotos.

Sistemas de gestão centralizados (EMS/NMS) integrados ao core permitem controle granular de QoS por aplicação, estabelecimento de SLAs por tipo de serviço e análise de tráfego em tempo real. Essa visibilidade é o que permite ao gestor da rede identificar qual aplicação está consumindo recursos além do esperado e agir antes que o impacto chegue às operações críticas.

QoS como parte do projeto

Em geral, os melhores resultados acontecem quando a QoS é considerada como um requisito de engenharia desde o início do projeto. Como o espectro de rádio é um recurso finito e compartilhado, a forma como ele é distribuído influencia diretamente a capacidade da rede de atender diferentes demandas operacionais.

Para integradores e gestores de TI envolvidos na especificação ou no comissionamento de redes privativas, escolher os equipamentos adequados é um passo importante, mas faz parte de um conjunto maior de decisões. eNodeBs Baicells com suporte a políticas de QCI, cores locais com configuração PCRF e ferramentas de monitoramento por bearer ajudam a construir uma base técnica consistente. Complementando essa estrutura, o planejamento das políticas de QoS e a validação sob carga contribuem para uma operação mais previsível.