Os arquitetos de IoT corporativos dedicam um tempo considerável à avaliação de hardware e tecnologias de conectividade, e menos tempo ao mapeamento da pilha de protocolos que rege a forma como dispositivos, redes e plataformas se comunicam entre si. Esse desequilíbrio tende a se manifestar como problemas de integração após a implantação: dispositivos que não conseguem se autenticar na plataforma, dados que chegam em formatos que o head-end não consegue analisar, atualizações de firmware que falham porque o protocolo de transporte OTA não foi validado em relação à memória disponível do dispositivo e vulnerabilidades de segurança decorrentes de incompatibilidades de protocolo entre as camadas.
A pilha de protocolos da IoT é um conjunto em camadas de padrões, cada um deles regendo um aspecto diferente de como os dados se deslocam de um sensor físico para um aplicativo. As escolhas em cada camada limitam e possibilitam as escolhas nas camadas adjacentes, e as interações entre essas escolhas determinam se a pilha completa funciona como um sistema coerente ou como um conjunto de componentes validados individualmente que geram atrito nas interfaces.
Este artigo analisa a pilha de protocolos da IoT, desde a camada de conectividade física até a camada de aplicação, abordando os padrões relevantes para implantações corporativas, as vantagens e desvantagens em cada camada e as considerações de integração que determinam se a pilha se mantém coesa em grande escala.
Camada física e de acesso: Padrões de telefonia celular
A camada física e de acesso determina como um dispositivo estabelece uma conexão de rádio com uma rede. No caso da IoT corporativa, vale a pena identificar os padrões de telefonia celular relevantes e suas relações entre si, pois a linguagem de marketing em torno dessas tecnologias pode ser imprecisa de maneiras que afetam as decisões de implantação.
NB-IoT (IoT de banda estreita, 3GPP Release 13 e versões posteriores) opera em um canal de 180 kHz dentro do espectro licenciado, seja na banda (in-band) dentro de uma portadora de LTE , na banda de proteção ( LTE ) ou em implantação autônoma no espectro realocado de GSM . Principais características da camada física:
- Taxa de transferência máxima no sentido descendente: aproximadamente 250 kbps na operação de tom único
- Taxa de transferência máxima de upload: aproximadamente 250 kbps
- Orçamento de enlace: perda de acoplamento máxima de 164 dBm, o que representa uma melhoria de aproximadamente 20 dB em relação a GPRS
- Latência: de 1,6 a 10 segundos para uma transmissão típica de dados, incluindo a configuração, o que a torna inadequada para aplicações que exigem resposta em menos de um segundo
- Modo duplex: somente half-duplex
LTE-M (LTE-MTC, Cat-M1, 3GPP Release 13) opera em um canal de 1,4 MHz dentro do espectro de LTE , com suporte a full-duplex. Principais características da camada física:
- Taxa de transferência máxima no sentido descendente: aproximadamente 1 Mbps
- Taxa de transferência máxima de upload: aproximadamente 1 Mbps
- Orçamento de link: perda de acoplamento máxima de 155,7 dBm, o que representa uma melhoria de aproximadamente 15 dB em relação a GPRS
- Latência: 10 a 15 ms para a transmissão de dados após o estabelecimento da conexão
- Modo duplex: compatível com full-duplex, permitindo voz e dados bidirecionais em tempo real
5G NR para IoT apresenta duas categorias relevantes de dispositivos: o RedCap (Capacidade Reduzida, 3GPP Release 17), voltado para dispositivos de IoT de nível intermediário que exigem maior taxa de transferência do que o LTE-M, mas menor consumo de energia do que o NR UE de 5G completo, e o NR padrão 5G para aplicações de IoT de alta largura de banda. O RedCap visa uma taxa de transferência de 5 a 25 Mbps com reduções de consumo de energia e complexidade em relação ao NR “ 5G ” completo, preenchendo a lacuna entre o “ LTE-M” e o “ 5G ” completo, que historicamente tem sido ocupada por dispositivos 4G Cat-4.
A escolha da camada física define os limites máximo e mínimo para todas as camadas acima dela. Uma pilha de protocolos projetada para comunicação bidirecional com tempo de resposta inferior a um segundo, baseada em um NB-IoT , falhará na camada física antes mesmo que o protocolo de aplicação tenha a chance de ser executado.
Camada de rede: endereçamento IP e roteamento para a IoT
A maioria dos dispositivos de IoT corporativos se comunica por meio de IPv4 ou IPv6, mas a configuração da camada de rede que rege a forma como esses endereços são atribuídos e gerenciados traz implicações operacionais que as especificações da camada física não revelam.
Arquitetura de rede privada APN é a configuração padrão da camada de rede para implantações de IoT corporativas com requisitos de segurança de dados ou regulatórios. Em vez de rotear o tráfego dos dispositivos pela APN pública compartilhada da operadora para a internet pública, uma APN privada cria um caminho de rede dedicado do dispositivo até a infraestrutura de back-end da empresa. O tráfego em uma APN privada não atravessa a internet pública, o que é importante para:
- Conformidade regulatória em setores em que os dados não devem sair do perímetro da rede corporativa
- Superfície de ataque reduzida, uma vez que os dispositivos não são acessíveis diretamente a partir da internet pública
- Roteamento determinístico, uma vez que o tráfego privado de APN segue caminhos de rede definidos, em vez do roteamento da internet pública
IPv6 para a IoT é relevante, pois o esgotamento dos endereços IPv4 dificulta o endereçamento individual em implantações de IoT em grande escala. Uma implantação de um milhão de medidores inteligentes, cada um exigindo um endereço IP roteável para comunicação iniciada pela central, esbarra em restrições práticas de alocação de endereços IPv4 que o IPv6 elimina. O IPv6 também simplifica o endereçamento de ponta a ponta em arquiteturas nas quais os dispositivos precisam ser acessíveis individualmente sem a necessidade de atravessar o NAT.
Considerações sobre CGNAT afetam as implantações em que o NAT de nível de operadora (CGNAT) fica entre o dispositivo e o back-end corporativo, o que é a configuração padrão para a maioria dos planos tarifários de IoT para consumidores e padrão. O CGNAT impede conexões de entrada para os dispositivos, o que significa que qualquer arquitetura que exija comunicação iniciada pelo head-end para dispositivos individuais requer uma conexão privada APN, uma conexão sempre ativa iniciada pelo dispositivo ou um dispositivo que mantenha uma sessão persistente com a plataforma de back-end. Os arquitetos que não levam o CGNAT em consideração durante o projeto descobrem isso durante os testes de integração; nesse momento, as opções de correção são mais caras.
Camada de transporte: seleção de protocolos para a transmissão de dados da IoT
A camada de transporte determina como os dados são empacotados e transmitidos de forma confiável (ou intencionalmente não confiável) entre o dispositivo e a plataforma. Os protocolos de transporte predominantes na IoT corporativa apresentam, cada um, diferentes compromissos que se adequam a diferentes perfis de aplicação.
MQTT (Message Queuing Telemetry Transport) é o protocolo de transporte de IoT mais amplamente utilizado para dispositivos conectados por rede celular. Sua arquitetura de publicação-assinatura, sobrecarga leve (cabeçalho fixo mínimo de 2 bytes) e suporte a três níveis de QoS o tornam ideal para dispositivos com recursos limitados que transmitem pequenas cargas úteis com frequência por meio de conexões potencialmente instáveis:
- QoS 0 (no máximo uma vez): enviar e esquecer, sem confirmação, menor sobrecarga
- QoS 1 (pelo menos uma vez): entrega garantida com confirmação de recebimento, possíveis duplicatas
- QoS 2 (exatamente uma vez): entrega única garantida, maior sobrecarga
A capacidade de sessão persistente do MQTT permite que os dispositivos se reconectem após uma interrupção na conectividade e recebam as mensagens enfileiradas pelo broker durante o período em que estiveram offline, o que é importante para dispositivos “ NB-IoT ” no PSM que ficam periodicamente inacessíveis.
CoAP (Constrained Application Protocol) foi projetado para dispositivos com recursos extremamente limitados, nos quais a exigência de TCP do MQTT gera uma sobrecarga inaceitável. O CoAP opera sobre uma conexão UDP, utiliza um modelo de solicitação-resposta semelhante ao HTTP, mas com um cabeçalho binário otimizado para ambientes com recursos limitados, e oferece suporte à funcionalidade de observação para um comportamento semelhante ao de publicação-assinatura. É a escolha certa de transporte para dispositivos NB-IoT , nos quais a sobrecarga do gerenciamento de conexões TCP afetaria significativamente o consumo de energia.
AMQP (Advanced Message Queuing Protocol) é relevante na camada de integração de back-end, e não na camada entre o dispositivo e a nuvem. Seu roteamento de mensagens mais avançado, suporte a transações e compatibilidade com corretores de mensagens corporativos fazem dele o protocolo de transporte padrão para conectar plataformas de IoT a sistemas de back-end corporativos: ERP, gerenciamento de ativos e plataformas de tecnologia operacional que exigem corretores de mensagens compatíveis com AMQP.
HTTPS/REST continua sendo relevante para dispositivos de IoT com recursos computacionais suficientes e nos casos em que a simplicidade da integração REST API supera a sobrecarga do HTTP. Gateways de IoT de ponta, nós de computação de borda e dispositivos com conectividade 4G ou 5G costumam usar REST para integração com plataformas, especialmente em implantações em que a equipe de operações responsável pela integração de back-end está mais familiarizada com padrões de web API do que com a configuração de brokers MQTT.
Camada de segurança: Padrões de autenticação e de “ Encryption ”
A escolha de protocolos de segurança na IoT é complicada pelas restrições de computação e memória dos dispositivos de borda, o que torna os protocolos de segurança padrão em ambientes de TI corporativos impraticáveis ou impossíveis de serem implementados em hardware com recursos limitados.
TLS 1.2 e TLS 1.3 são os protocolos de criptografia padrão para dispositivos IoT com recursos computacionais suficientes. O TLS 1.3 reduz a latência do handshake em relação ao TLS 1.2 ao eliminar uma ida e volta da sequência de handshake, o que é importante para dispositivos NB-IoT e LTE-M, nos quais cada transmissão de rádio acarreta um custo mensurável de energia. A seleção do conjunto de cifras no TLS é importante para a IoT: a troca de chaves ECDHE e o AES-128-GCM são a combinação recomendada para implantações de IoT que buscam equilibrar a segurança com a eficiência computacional.
DTLS (Datagram TLS) é o protocolo de segurança adequado para implantações do CoAP, oferecendo garantias de segurança equivalentes às do TLS para o transporte baseado em UDP.
Autenticação mútua baseada em certificados X.509 é o mecanismo recomendado de autenticação de dispositivos para implantações corporativas de IoT em grande escala. Chaves pré-compartilhadas são mais simples de implementar, mas geram problemas de gerenciamento de chaves em grandes conjuntos de dispositivos: a rotação de uma chave pré-compartilhada comprometida em milhões de dispositivos implantados é um processo operacionalmente oneroso. Certificados X.509 com identidades individuais de dispositivos permitem a rotação e a revogação de certificados por dispositivo, sem afetar os demais dispositivos da frota.
Módulos de Segurança de Hardware (HSM) e Ambientes de Execução Confiáveis (TEE) são cada vez mais relevantes para dispositivos de IoT corporativos que lidam com dados confidenciais ou operam em ambientes onde o acesso físico ao dispositivo por pessoas não autorizadas representa um risco. Armazenar chaves privadas em um elemento protegido por hardware, em vez de na memória do firmware, impede a extração das chaves, mesmo que o firmware do dispositivo seja comprometido.
A pilha de protocolos de segurança precisa ser validada de ponta a ponta antes da implantação. Um dispositivo que implemente o TLS corretamente, mas se conecte a um ponto de extremidade da plataforma que não exija autenticação mútua, possui apenas metade de uma arquitetura de segurança. A validação de segurança na IoT precisa abranger todo o caminho do handshake, do dispositivo até a plataforma, incluindo a camada de rede ( APN privado), a camada de transporte (configuração do TLS) e a camada de aplicação (tratamento do token de autenticação e gerenciamento de sessão).
Formatos de dados e protocolos de Device Management
A camada de aplicação é onde as decisões relacionadas aos protocolos têm o impacto mais direto na complexidade da integração da plataforma.
LwM2M (Lightweight M2M, OMA SpecWorks) é o protocolo de gerenciamento de dispositivos projetado para a IoT, abrangendo o registro de dispositivos, a entrega de atualizações de firmware via OTA, a configuração remota e a geração de relatórios de telemetria em uma única estrutura de protocolo. Seu modelo de dados utiliza uma hierarquia padronizada de objetos e recursos que permite que plataformas de gerenciamento de dispositivos interajam com qualquer dispositivo compatível com LwM2M sem a necessidade de trabalho de integração específico para cada dispositivo. Para implantações corporativas que gerenciam grandes conjuntos de dispositivos heterogêneos, o modelo de gerenciamento padronizado do LwM2M reduz significativamente a sobrecarga de integração associada à adição de novos tipos de dispositivos à frota.
Considerações sobre o protocolo FOTA (Firmware Over The Air) na camada de aplicação costumam ser subestimadas durante o projeto da implantação. Os pacotes de atualização de firmware para dispositivos IoT podem variar de dezenas de kilobytes a vários megabytes. O protocolo FOTA precisa levar em conta:
- Recuperação de transferência interrompida, uma vez que um dispositivo NB-IoT ou LTE-M pode perder a conectividade no meio de um download de firmware
- Suporte à atualização delta, em que apenas os segmentos do firmware alterados são transmitidos, em vez da imagem completa, reduzindo o tamanho da transmissão e o consumo de energia
- Capacidade de reversão caso o novo firmware não seja validado no dispositivo
Formato de serialização de dados na camada de aplicação afetam a eficiência da transmissão e a complexidade da integração da plataforma. O JSON é amplamente compatível e legível por humanos, mas acarreta uma sobrecarga significativa em relação aos formatos binários para dispositivos com recursos limitados. O CBOR (Concise Binary Object Representation) oferece expressividade equivalente à do JSON em uma codificação binária que, normalmente, reduz o tamanho da carga útil em 50 a 70 por cento. Para dispositivos d NB-IoT m que transmitem em alta frequência ou com orçamentos de energia restritos, a redução da carga útil proporcionada pelo CBOR em comparação com o JSON se traduz diretamente em maior duração da bateria e menores custos de dados.
Coerência da pilha de protocolos em escala empresarial
As decisões relativas à pilha de protocolos descritas acima não operam de forma independente. Uma implantação que selecione o protocolo “ NB-IoT ” na camada física, o MQTT sobre TCP na camada de transporte e o TLS 1.2 com handshake completo na camada de segurança cria uma pilha em que a sobrecarga das camadas de transporte e segurança pode dominar o orçamento de energia do dispositivo, de forma a comprometer a lógica de eficiência energética que motivou a escolha do “ NB-IoT ” inicialmente. CoAP sobre UDP com DTLS seria a pilha coerente para um dispositivo NB-IoT com restrições de energia, enquanto MQTT sobre TCP com TLS é a pilha apropriada para um dispositivo LTE-M com um orçamento de energia mais generoso.
A coerência da pilha de protocolos também é importante para a infraestrutura de conectividade. Uma implantação em que os dispositivos se conectam por meio de uma rede privada APN com endereçamento IP estático, se comunicam via MQTT com um broker na nuvem e utilizam autenticação mútua X.509 apresenta requisitos específicos para a plataforma de gerenciamento de conectividade: provisionamento de APN privados, atribuição de IPs estáticos e gerenciamento do ciclo de vida de certificados que se integre à infraestrutura de identidade dos dispositivos.
A infraestrutura de conectividade da KORE fornece a base da camada de rede da qual dependem as pilhas de protocolos corporativos, incluindo a configuração de endereços IP privados ( APN ), o provisionamento de IPs estáticos e a conectividade com múltiplas operadoras por meio de mais de 40 parcerias com operadoras e em mais de 200 países. A plataforma ConnectivityPro oferece o gerenciamento do ciclo de vida dos SIMs e os controles de políticas de rede que regem a camada de conectividade subjacente a qualquer pilha de protocolos de aplicativos em que a implantação seja executada. Com mais de 21 milhões de SIMs ativos implantados em setores verticais onde a coerência da pilha de protocolos afeta diretamente os resultados operacionais, a infraestrutura foi projetada para suportar toda a gama de configurações de conectividade de IoT empresarial exigidas pelas implantações em produção.
Para definir corretamente a pilha de protocolos, é necessário avaliar cada camada no contexto das camadas adjacentes a ela e validar toda a pilha de ponta a ponta antes que a implantação seja concretizada em hardware em grande escala. Os problemas de integração decorrentes de incompatibilidades entre protocolos são solucionáveis, mas é mais econômico resolvê-los em ambiente de laboratório do que em campo.
Converse com um engenheiro de conectividade da KORE sobre os requisitos de infraestrutura da camada de rede para sua pilha de protocolos de IoT.
Publicado em 29 de maio de 2026.