12. Introdução
O LoRaWAN não é apenas um protocolo de rádio. Ele depende de uma arquitetura de servidores bem definida, responsável por:
-
Gerenciamento da rede
-
Segurança
-
Processamento de mensagens
-
Integração com aplicações e plataformas IoT
Uma arquitetura mal planejada pode:
-
Limitar a escalabilidade
-
Comprometer a segurança
-
Criar gargalos de downlink
-
Dificultar a integração com sistemas corporativos
12.1 Visão geral da arquitetura LoRaWAN
A arquitetura lógica do LoRaWAN é composta por:
-
Gateway
-
Network Server (NS)
-
Join Server (JS)
-
Application Server (AS)
O Join Server pode estar integrado ao NS ou operar de forma independente.
12.2 Gateways (camada de acesso)
Os gateways são elementos de borda que:
-
Recebem pacotes LoRa
-
Encapsulam em IP
-
Encaminham para o Network Server
Características importantes
-
Não armazenam estado
-
Não decodificam payload
-
Podem ser compartilhados
-
Funcionam como “escuta passiva”
🔎 Boas práticas no AU915
-
Gateways multicanal (8, 16 ou 64 canais)
-
Downlink em 500 kHz habilitado
-
Backhaul confiável (Ethernet > Wi-Fi > LTE)
12.3 Network Server (NS)
O Network Server é o coração da rede LoRaWAN.
Principais responsabilidades
-
Deduplicação de uplinks
-
Gerenciamento de sessões
-
ADR
-
Controle de downlink
-
Aplicação de políticas regionais (AU915)
-
Processamento de comandos MAC
Exemplos de Network Servers
-
ChirpStack
-
The Things Stack (TTS / TTN)
-
Actility
-
Servidores proprietários
12.4 Join Server (JS)
O Join Server é responsável pelo processo de ativação OTAA.
Funções principais
-
Armazenar AppKey / NwkKey
-
Processar Join Requests
-
Gerar chaves de sessão
-
Enviar Join Accept
Modelos de implantação
-
Integrado ao Network Server
-
Servidor independente (multi-tenant)
🔎 Importante
Separar o Join Server aumenta:
-
Segurança
-
Escalabilidade
-
Isolamento entre aplicações
12.5 Application Server (AS)
O Application Server é onde:
-
Os dados já descriptografados chegam
-
O payload é processado
-
A lógica de negócio acontece
Funções típicas
-
Decodificação de payload
-
Persistência em banco de dados
-
Dashboards
-
Alertas
-
Integração com sistemas externos
12.6 Integração com plataformas IoT
As integrações mais comuns são:
MQTT
-
Streaming em tempo real
-
Ideal para Node-RED, microserviços
-
Baixa latência
HTTP / Webhooks
-
Integrações REST
-
Sistemas legados
-
Menor complexidade
Outros
-
AMQP
-
Kafka
-
gRPC (em plataformas modernas)
🔎 Prática comum no Brasil
Network Server → MQTT → Plataforma IoT própria
12.7 Arquitetura típica de plataforma IoT
Uma arquitetura moderna baseada em LoRaWAN geralmente inclui:
Componentes comuns
-
Node-RED (ETL e regras)
-
InfluxDB / TimescaleDB
-
Backend (REST / GraphQL)
-
Frontend (dashboards, alertas)
12.8 Multi-tenancy e escalabilidade
Multi-tenancy
Permite:
-
Vários clientes
-
Isolamento lógico
-
Controle de acesso
Implementado via:
-
RBAC
-
Namespaces
-
Isolamento de dados
Escalabilidade
Boas práticas:
-
Stateless services
-
Filas e streaming
-
Separação NS / AS
-
Monitoramento contínuo
12.9 Segurança na arquitetura
Camadas de segurança:
-
Criptografia LoRaWAN (AES-128)
-
TLS entre gateways e servidores
-
Autenticação de APIs
-
Controle de acesso
-
Auditoria e logs
🔎 LGPD / Compliance
Arquiteturas privadas facilitam:
-
Governança de dados
-
Conformidade regulatória
12.10 AU915 e impacto arquitetural
O AU915 impõe desafios específicos:
-
Muitos canais
-
Alto volume de uplinks
-
Downlink escasso
-
ADR crítico
➡️ A arquitetura deve ser otimizada para uplink.
12.11 Erros comuns de arquitetura
⚠️ Centralizar tudo em um único servidor
⚠️ Subestimar volume de dados
⚠️ Ignorar escalabilidade do MQTT
⚠️ Usar downlink excessivo
⚠️ Falta de observabilidade
Encerramento do Capítulo 12
Neste capítulo você aprendeu:
-
Componentes da arquitetura LoRaWAN
-
Papel do NS, JS e AS
-
Integração com plataformas IoT
-
Arquiteturas modernas e escaláveis
-
Considerações específicas do AU915
-
Boas práticas de segurança e operação
Comentários