# Network server LoRaWAN vs plataforma de aplicação IoT: o que cada um realmente faz

> Um network server LoRaWAN move pacotes; uma plataforma de aplicação IoT os transforma em dashboards, alertas, previsões e aplicações. O que cada camada faz, por que você precisa das duas e como elas se conectam.

![Network server LoRaWAN vs plataforma de aplicação IoT: o que cada um realmente faz](https://tago.io/og/pt-br/blog/lorawan-network-server-vs-application-platform.png)

Todo projeto LoRaWAN encontra a mesma confusão na primeira semana. O time sobe um network server, vê os dados do dispositivo chegando e pergunta por que ainda precisa de outra plataforma. Ou então assina uma plataforma de aplicação, cadastra um sensor e pergunta por que nada aparece. As duas perguntas têm a mesma resposta: implantações LoRaWAN rodam em duas camadas distintas que costumam ser confundidas com uma só, e cada uma faz um trabalho que a outra deliberadamente não faz.

Acertar essa divisão economiza semanas. O que vem a seguir é o que cada camada possui, onde fica a fronteira e como as duas se conectam na prática.

![A pilha LoRaWAN em duas camadas, com o network server embaixo e a plataforma de aplicação em cima](https://tago.io/images/blog/lorawan-network-server-vs-application-platform/lns-vs-application-platform-stack.svg)

## O que o network server possui

Um network server LoRaWAN (LNS) é gestão de infraestrutura de rádio. Ele autentica dispositivos quando eles entram na rede, elimina duplicatas do mesmo pacote que chegou por vários gateways, agenda downlinks pelo melhor gateway, gerencia a taxa de dados adaptativa para preservar bateria e aplica a camada MAC do LoRaWAN. ChirpStack, The Things Stack e servidores operados por operadoras como a Actility vivem todos aqui, e comparamos as opções públicas e privadas em [redes LoRaWAN privadas vs públicas](https://tago.io/blog/private-vs-public-lorawan-networks).

O que o LNS entrega ao fim de todo esse trabalho é um payload descriptografado: algumas dezenas de bytes binários, mais metadados de rádio. Sem dashboards, sem usuários, sem alertas, sem histórico que valha consultar. Isso não é uma lacuna do produto. É o projeto dele.

## O que a plataforma de aplicação possui

Uma plataforma de aplicação IoT começa onde o pacote deixa de importar e os dados começam. Ela decodifica o payload binário em variáveis nomeadas, armazena tudo como séries temporais consultáveis e transforma isso nas coisas que as pessoas de fato compram: dashboards, alertas, contas de usuário com permissões, relatórios e integrações com o resto do negócio.

A camada que cada vez mais separa uma plataforma de aplicação das outras é a inteligência. Guardar uma leitura de temperatura é o mínimo. Prever onde ela estará em seis horas, sinalizar que um sensor começou a desviar dois dias antes de falhar e converter uma previsão em ordem de serviço é onde o valor se concentra. A TagoIO faz isso com scripts de Analysis e [Analytics e IA nativos](https://tago.io/analytics), então previsões, alertas de anomalia e recomendações aparecem dentro da mesma interface dos dados ao vivo, em vez de em uma ferramenta de BI separada que alguém tem de lembrar de abrir.

![Uma visão só com dashboard ao lado de outra em que a camada de analytics adiciona previsões, alertas de anomalia e recomendações](https://tago.io/images/blog/shared/intelligence-beyond-dashboards.svg)

## A fronteira em uma frase

O network server garante que o pacote chegue uma vez, com segurança e eficiência. A plataforma de aplicação faz o pacote significar algo para uma pessoa ou outro sistema. Se a tarefa envolve rádio, ingresso na rede, gateways ou fatores de espalhamento, ela pertence ao LNS. Se envolve um usuário, um gráfico, um limite, uma previsão ou um ERP, ela pertence à plataforma de aplicação.

Confundir as camadas custa tempo de verdade. Times tentam construir alertas dentro de um LNS com webhooks e scripts, e acabam mantendo uma plataforma de aplicação frágil que nunca pretenderam escrever. Ou esperam que uma plataforma de aplicação diagnostique cobertura de gateway, o que ela não consegue ver. Cada camada é deliberadamente cega ao trabalho da outra.

## Como as duas se conectam

Na prática, a integração é uma ponte de dados. O LNS empurra todo uplink decodificado para a plataforma de aplicação por HTTPS ou MQTT, e os downlinks voltam pelo mesmo caminho. A TagoIO já vem com integrações prontas para os principais network servers, incluindo The Things Network, ChirpStack e redes de operadoras, além de uma [biblioteca de conectores](https://tago.io/devices) com centenas de sensores, de modo que decodificar payload é configuração, não código.

Uma pilha típica de produção termina assim: sensores, gateways, um LNS (rede pública ou ChirpStack privado) e a TagoIO em cima para tudo que o cliente vê. A escolha do LNS e a escolha da plataforma são decisões independentes, o que é saudável: você pode trocar de operadora de rede sem reconstruir sua aplicação, e vice-versa.

## Alguma vez você precisa de apenas um?

Às vezes. Um estudo puro de cobertura pode viver só no LNS. Uma implantação celular ou Wi-Fi dispensa o LNS por completo e fala direto com a plataforma de aplicação. Mas se o projeto envolve sensores LoRaWAN e alguém além de um engenheiro olhando os dados, você precisa das duas camadas, e o orçamento honesto inclui as duas desde o início.

Se você já tem um LNS rodando e quer ver a camada de aplicação funcionando sobre ele, a TagoIO conecta em minutos. [Agende uma demonstração](https://tago.io/request-demo) ou [comece gratuitamente](https://admin.tago.io).

[llms.txt](https://tago.io/llms.txt)