Você escolheu LoRaWAN pelo alcance e pela duração da bateria. Boa escolha. Agora vem uma segunda decisão que pesa tanto quanto a primeira, e que a maioria dos times atropela: quem opera a rede com a qual seus dispositivos vão conversar?
São três respostas possíveis. Você pode entrar em uma rede comunitária pública como a The Things Network. Pode usar uma rede de cobertura descentralizada como a Helium. Ou pode operar seus próprios gateways com um servidor de rede como o The Things Stack ou o ChirpStack. Os três transportam os mesmos pacotes LoRaWAN. O que muda é quem controla a cobertura, quem garante o uptime, quem enxerga o seu tráfego e quem paga por cada parte.
Este guia percorre os três modelos, as compensações entre eles e quando cada um é a decisão certa. No fim, ele conecta a escolha do servidor de rede à camada acima dela, porque é justamente essa a parte que os times esquecem até os dados começarem a fluir e ninguém ter decidido para onde eles vão.
Os três modelos, sem rodeios
Rede comunitária pública. A The Things Network é o exemplo mais conhecido. É uma rede LoRaWAN compartilhada e mantida pela comunidade. Qualquer um pode subir um gateway e adicioná-lo ao mapa público de cobertura, e qualquer um pode registrar dispositivos e usar a rede de graça, dentro dos limites de uso justo. A infraestrutura pertence a quem montou o gateway mais próximo, que pode ser você, pode ser um hobbysta a três quarteirões de distância ou pode não ser ninguém.
Rede de cobertura descentralizada. Aqui o caso conhecido é a Helium. Os operadores de gateway são remunerados por um incentivo em tokens para fornecer cobertura, o que, em tese, faz o mapa crescer mais rápido do que num modelo puramente voluntário. Do lado do dispositivo, continua se comportando como uma rede pública: você não é dono dos gateways, e o seu tráfego depende de uma cobertura que outras pessoas decidem manter no ar.
Rede privada. Você compra e instala seus próprios gateways e os aponta para um servidor de rede sob seu controle. Esse servidor costuma ser o The Things Stack ou o ChirpStack. A cobertura é sua, o uptime é seu para gerenciar, e os dados nunca passam pela infraestrutura de terceiros. Em troca, você assume o custo do hardware e o trabalho de operação.
O que o servidor de rede realmente faz
Antes das compensações, um pedaço de vocabulário que costuma confundir. O servidor de rede LoRaWAN é o cérebro entre os seus gateways e os seus dados. Ele remove pacotes duplicados que chegaram por vários gateways, verifica as chaves de segurança do dispositivo, trata pedidos de join, gerencia as taxas de dados e então encaminha o payload já descriptografado adiante.
O The Things Stack e o ChirpStack são ambos servidores de rede. A diferença entre LoRaWAN público e privado quase sempre se resume a quem opera esse servidor. Na The Things Network, a comunidade roda o The Things Stack por você. Numa rede privada, você mesmo roda o The Things Stack ou o ChirpStack, no seu próprio hardware ou na sua própria conta de nuvem.
Isso importa para a próxima seção, e importa muito para a parte sobre plataformas de aplicação mais adiante.
As compensações que decidem a escolha
Seis fatores separam os três modelos. Nenhum modelo vence em todos os seis.
Cobertura. Redes públicas e descentralizadas entregam uma cobertura que você não construiu, onde ela já existe. Numa cidade densa, a The Things Network ou a Helium podem já alcançar o seu local. Num campo rural, num porão ou num parque industrial fechado, essa cobertura é rala ou inexistente, e você não faz gateways comunitários surgirem só por querer. Uma rede privada entrega cobertura exatamente onde você coloca um gateway, e em lugar nenhum além disso.
Controle. Numa rede privada, você define o plano de canais, o posicionamento dos gateways, a política de taxa de dados e o cronograma de atualizações. Numa rede pública ou descentralizada, você fica com o que está disponível. Se um gateway comunitário perto de você cair, não é um gateway seu para consertar.
Confiabilidade. Um gateway que você é dono e monitora é um gateway que você pode cobrar. Gateways comunitários e descentralizados podem aparecer e sumir sem aviso, porque quem os opera não deve nada a você. Para um projeto de hobby, tudo bem. Para um site em produção, é um risco que você precisa precificar.
Segurança. O LoRaWAN criptografa os payloads de ponta a ponta independentemente do modelo, então o enlace de rádio não é a preocupação. A diferença é operacional: numa rede privada, seus join servers, suas chaves e seu tráfego permanecem dentro de uma infraestrutura que você controla. Para trabalho regulado, essa fronteira muitas vezes é o fator decisivo por si só.
Custo. Redes comunitárias públicas não custam nada por mensagem dentro do uso justo, o que é difícil de bater em projetos pequenos ou iniciais. Redes descentralizadas costumam ter um custo por pacote ou por crédito de dados. Uma rede privada tem o formato oposto: dinheiro de verdade na frente, para gateways e instalação, e depois um custo por mensagem perto de zero. Para uma implantação densa, com muitos dispositivos num mesmo local, o modelo privado costuma vencer no custo total ao longo da vida do dispositivo, mesmo parecendo mais caro no primeiro dia.
SLA. Esse é curto. Redes comunitárias e descentralizadas não vêm com nenhum acordo de nível de serviço. Ninguém promete uptime a você. Uma rede privada tem o SLA que você construir e operar, o que significa que você é dono tanto da promessa quanto do trabalho de cumpri-la.
Quando cada um se encaixa
Comece pelo trabalho a ser feito, não pela rede.
Hobby, prototipagem e prova de conceito. Se você está testando se o LoRaWAN sequer serve para a sua ideia, entre na The Things Network. Grátis, rápido de começar e sem compromisso de hardware se a cobertura já chega até você. A Helium se encaixa num estágio inicial parecido, quando você quer cobertura mais ampla e aceita um pequeno custo por pacote. Não suba seu próprio servidor para enviar cem mensagens de teste.
Implantações em produção. Quando os dispositivos já estão em campo se pagando, a conta muda em direção a controle e confiabilidade. Muitos times migram para uma rede privada nesse ponto, ou pelo menos para uma instância paga e operada do The Things Stack, para que cobertura e uptime sejam responsabilidade concreta de alguém. Quer você faça self-host ou use um servidor de rede operado, o objetivo é o mesmo: nada de buracos surpresa.
Sites regulados ou remotos. Saúde, utilities, qualquer coisa com regras de residência de dados, ou qualquer local sem nenhuma cobertura comunitária. Aqui a rede privada costuma ser a única resposta honesta. Você precisa da fronteira de dados, da cobertura garantida, ou de ambas, e um mapa público não entrega nenhuma das duas.
A linha não é rígida. Muitas implantações reais misturam modelos: uma rede privada no campus principal e a The Things Network para uma unidade satélite que já tem cobertura. Isso é perfeitamente válido, e leva direto ao próximo ponto.
O servidor de rede não é a sua aplicação
Qualquer que seja o modelo escolhido, o servidor de rede move e descriptografa pacotes. É só isso que ele faz. Ele não guarda histórico, não desenha um dashboard, não alerta um operador quando um tanque chega ao fundo nem aciona uma bomba. Esses trabalhos vivem uma camada acima, na plataforma de aplicação. É aqui que os projetos costumam empacar.
É aqui que a TagoIO entra. A TagoIO é uma plataforma de aplicação IoT gerenciada que roda acima do servidor de rede. Ela ingere os dados descriptografados que saem da sua rede LoRaWAN, armazena, exibe em dashboards, gerencia seus dispositivos e permite que você construa alertas, APIs e ações automatizadas em cima de tudo isso.
Como a TagoIO se integra abaixo do servidor de rede, o modelo que você escolheu lá embaixo não te prende. Usando a The Things Network? A TagoIO puxa os dados do The Things Stack. Fazendo self-host do ChirpStack numa rede privada? A TagoIO se conecta ao ChirpStack. Misturando os dois entre sites? A camada de aplicação continua a mesma enquanto as redes diferem por baixo. Você pode trocar ou combinar modelos de rede sem reconstruir os dashboards e a lógica de que o seu time depende.
Para times que precisam revender ou fazer white-label da aplicação para os próprios clientes, o TagoRUN oferece isso na mesma plataforma. Para processamento na borda, perto dos gateways, o TagoCore é um runtime open-source que roda a lógica da aplicação no local. A própria plataforma é certificada ISO 27001 e alinhada ao GDPR, algo que tende a importar mais para esses mesmos times regulados que pendem para o privado no lado da rede.
A versão curta
Não existe um melhor modelo de rede LoRaWAN, só o certo para o trabalho à sua frente. Decida por cobertura, controle, confiabilidade, segurança, custo e SLA, ponderados pelo que o seu projeto de fato precisa. Use a The Things Network para hobby e prototipagem, a Helium quando quiser cobertura descentralizada e aceitar o custo dela, e uma rede privada no The Things Stack ou ChirpStack quando precisar de controle, cobertura garantida ou uma fronteira de dados rígida para produção e trabalho regulado.
Depois escolha a camada de aplicação que fica acima de tudo isso, para que os dados que você se esforçou para coletar virem algo que uma pessoa consiga ver e sobre o qual possa agir. Acerte o modelo de rede cedo. Assim como a escolha do rádio que veio antes dele, é difícil desfazer depois que os sensores já estão em campo.
