Toda implantação LoRaWAN tem três camadas: dispositivos em campo, gateways que os escutam e um servidor de rede LoRaWAN que transforma pacotes de rádio em dados utilizáveis. As duas primeiras são hardware que você pode segurar. A terceira é software — e decidir onde ele roda é uma das escolhas de maior consequência de todo o projeto.

O que um servidor de rede LoRaWAN realmente faz?

O servidor de rede LoRaWAN (LNS) é o cérebro da rede. Os gateways são deliberadamente simples — encaminham todo pacote que escutam. O trabalho de verdade é do servidor de rede: ele deduplica pacotes recebidos por vários gateways, valida sessões dos dispositivos e trata os joins, gerencia a camada MAC (taxas de dados, planos de canais, adaptive data rate), agenda downlinks pelo gateway mais bem posicionado e entrega à sua aplicação payloads limpos e decifrados.

Sem um servidor de rede, o tráfego LoRaWAN é só ruído. Com um, a mesma infraestrutura atende lado a lado sensores de porta, hidrômetros, rastreadores e telemetria industrial.

Suas três opções para rodar um

Em linhas gerais, toda equipe escolhe entre três modelos.

Open source auto-hospedado. O ChirpStack (licença MIT) e o núcleo open source do The Things Stack podem ser auto-hospedados gratuitamente, sem limites de uso. Você ganha a propriedade total da camada de conectividade — e toda a responsabilidade por ela: hospedar, escalar, aplicar patches e monitorar o servidor e suas dependências. Ambos são apenas servidores de rede: dashboards, visualização de dados, regras e alertas precisam vir de uma plataforma de aplicação separada. Nossos comparativos honestos cobrem os dois: Kilo vs ChirpStack e Kilo vs The Things Stack.

Uma rede hospedada. O Sandbox comunitário do The Things Stack é gratuito para pequenos usos não comerciais sob uma política de uso justo, e os níveis comerciais são pagos. Você pula a hospedagem, mas a camada de aplicação continua sendo um produto separado, que você integra e paga.

Embutido na plataforma. O terceiro modelo colapsa a pilha: o servidor de rede vem dentro da própria plataforma IoT. A plataforma IoT da Kilo inclui um servidor de rede LoRaWAN embutido (e um mioty) em todos os planos, inclusive no nível gratuito de 5 dispositivos — os gateways apontam para a plataforma, e dashboards, regras, alarmes e IA trabalham diretamente sobre os dados decifrados, sem camada de integração no meio.

Nuvem ou auto-hospedado: o trade-off honesto

A auto-hospedagem vence quando o requisito é ser dono da camada de conectividade: um site isolado da rede (air-gapped), uma operadora que constrói o negócio sobre a camada de rede ou uma equipe que realmente quer modificar o servidor. O custo é uma função de operações — o servidor passa a ser infraestrutura de produção que você mantém.

Um servidor de rede embutido vence em tempo e custo total para a maioria das implantações focadas na aplicação: não há um segundo sistema para implantar, nem ponte MQTT para manter entre o LNS e seus dashboards, nem uma fatura separada. Quando servidor de rede, gestão de dispositivos e automação são um único produto, um gateway offline dispara os mesmos alarmes, com as mesmas cadeias de escalonamento, que um sensor offline.

Conectar um gateway leva minutos, não dias

Qualquer gateway que fale LoRa Basics Station ou o packet forwarder Semtech UDP pode apontar para o servidor de rede embutido da Kilo — registre o gateway, adicione seus dispositivos e, em minutos, os dados ao vivo aparecem com intensidade de sinal e saúde dos dispositivos. Se você ainda está escolhendo o hardware, nosso guia de gateways LoRaWAN cobre modelos indoor e outdoor, planos de frequência por região e posicionamento.

Conclusão

O servidor de rede LoRaWAN não é onde seu projeto cria valor — é o encanamento que precisa funcionar. Rode-o você mesmo quando a propriedade desse encanamento for o objetivo. Quando o objetivo é a aplicação, escolha uma plataforma que já traga o servidor de rede embutido e invista seu tempo de engenharia naquilo para que os sensores existem.