LoRa, LPWAN, LoRaWAN, gateway...

Quem não gosta de fazer um projeto com rádio frequência? Mais ainda se for de longo alcance, mas a eficiência a uma boa implementação dependem de diversos conceitos. Vamos começar definindo alguns desses conceitos e então (provavelmente em outro artigo) faremos uma configuração utilizando esses recursos e um hat LoRa da AFEletronica, o AFMultiRadio.

Adianto que esse artigo é mais um estudo que iniciei poucas horas antes de escrever e estou escrevendo para ter registro de consulta a posteriori.

Como trafegar dados à distância

Nem sempre temos um ponto de Internet para conectar nossos dispositivos, principalmente se estivermos em lugares distantes de áreas urbanas, onde as coberturas de redes sem fio são maiores. Atualmente temos as redes de telefonia para auxiliar no transporte de dados, mas o custo é alto. Uma das formas seria utilizando um smartphone com conexão de dados via OTG ou então módulos GSM (me parece que o SIM800 já está morto em vários lugares, mas o SIM808 é homologado no Brasil).

Para distâncias menores, indo de metros a quilômetros, podemos usar faixas de rádiofrequência livres (não licenciadas) nas bandas ISM 2.4GHz, 915MHz (já subgiga, tal como se lê), 868MHz, 433MHz, 169MHz. Uma regra que podemos ter em mente é que quanto maior a frequência, menor o alcance e maior a velocidade. Quanto menor a frequência, maior o alcance e menor a velocidade.

Uma outra questão importante é a sensibilidade, da qual espero escrever a respeito - se não nesse, em outro artigo. Em média, utiliza-se -130 dBm. Essa sensibilidade é possível em taxas de modulação mais lentas, aumentando a taxa de energia por símbolo. Pretendo esclarecer, mas vamos seguindo o raciocínio.

Com as frequências subgiga, alcançamos até 10km em áreas urbanas e mais de 30km em áreas rurais com linha de visada. Apenas para constar, a linha de visada é um plano aberto entre os dois pontos, sem interferências físicas como muros ou árvores. Nesse caso, a maneira mais segura de aumentar o alcance é dispor esses pontos sobre antenas altas.

LPWAN

LPWAN é o acrônimo de Low Power Wide Area Network. Se trata de um conjunto de tecnologias para redes de baixa potência, arquitetadas para uso machine-to-machine. Não é o propósito dessa rede lhe dar acesso à navegação web nem fazer download de suas séries favoritas. Trata-se de uma rede para transferência sucinta de dados para telemetria.

A topologia de rede é estrela e os nós se comunicam com o gateway. Mas o gateway nessa rede é transparente, o que o difere de um gateway tradicional de redes TCP/IP. Entraremos em detalhes sobre o gateway mais adiante.

Outra diferença em relação às redes TCP/IP é que na LPWAN o uplink é predominante, uma vez que o importante é o informe dos nós sobre os dados de telemetria. Normalmente o downlink é utilizado para o ACK (acknowledge). Eventualmente pode-se utilizar o downlink para interagir com a rede, mas considerando diversos fatores expostos mais adiante, não parece ser uma opção de grande interesse nesse modelo de aplicação.

A cobertura LPWAN é composta  por malhas, possibilitando uma vasta cobertura e, conforme a disposição, diminui o número de gateways para cobrir uma determinada área.

LoRa

A tecnologia LoRa é propriedade da Semtech. Utilizando espelhamento espectral derivado da modulação (Chirp Spread Spectrum),  pode-se trocar a taxa de transmissão por sensibilidade nos receptores, com a mesma largura de banda por canal. Mais adiante veremos os parâmetros de modulação.

Através de fatores de espelhamento ortogonais, pode-se fazer troca de taxa de transmissão por potência ou alcance para otimizar performance em uma considerada largura de banda constante.

Fatores chave de modulação

Maiores detalhes poderão ser vistos no site da Semtech. Nesse link ("o que é LoRa/o que é LoRaWAN?") já mostra de cara conceitos importantes a respeito da tecnologia. Basicamente, podemos usar LoRa para uma comunicação entre sensores e atuadores para fazer um controle de uma infraestrutura qualquer, havendo ou não conectividade à Internet. Quando falamos de LoRaWAN, pensamos em uma rede maior, com diversas implementações; um conjunto de protocolos maior, que inclui um gateway, uma topologia definida e padrões comportamentais seguindo os protocolos envolvidos.

Os fatores de modulação chave são:

Largura de banda escalável

A largura de banda e frequência são escaláveis, necessitando ajustes de configuração nos dispositivos.

Consumo de energia linear e encapsulamento

A potência de saída é controlável, podendo ser reduzida.

Robustez

Seletividade de 90dB e rejeição co-canal melhor que 20dB obtidas por ajustes.

Resistência a multipercurso e desvanecimento

A resistência ao desaparecimento de sinal é um fator importante que permite sua utilização em áreas urbanas.

Resistência a desvio de frequência

As fontes de clock não precisam ser de alta precisão, graças a essa resistência - o que significa também que o menor dos problemas que se possa deparar na implementação seja relacionado ao hardware em si.

Capacidade de longo alcance

Já citado tanto em distância quanto em suas razões, podemos ter diversos quilômetros de alcance.

Capacidade de rede

Múltiplos sinais podem ser espalhados e transmitidos ao mesmo tempo em um mesmo canal com degradação mínima de sensibilidade do receptor. Os atores de espelhamento diferentes aparecem como ruído e se trata como tal.

LoRaWAN

Começo esse parágrafo recomendando o vídeo "LoRaWAN desmistificado", que explica em poucos minutos diversos conceitos importantes, mostra um nó, um gateway e uma malha de rede pública da thethingsnetwork.

Os protocolos LoRaWAN são convencionados pela LoRa Alliance, que envolve empresas como Actility, IBM, Microchip e Semtech. Os dispositivos ficam mais tempo em espera do que transmitindo, utilizando um modelo de duty cycle.

Os três tipos de dispositivos; os nós, os gateways e o broker.

Arquitetura LoRaWAN

A arquitetura LoRaWAN pode ser representada em diversos aspectos. Meu documento de estudos (que originou esse artigo) é esse.

O modelo descrito também pode ser encontrado no google images em diversos sites, assim como outras representações.

No documento de Marco Centenaro, da Universidade de Cornell, encontram-se as referências de arquitetura como a imagem acima e a mais simplificada, que é a interconectividade a seguir:

Não é necessário associação direta com um gateway para acesso à rede, o que caracteriza esse gateway como transparente, já ao broker (ou por definição, "netserver"), atrelando informações da relação sinal-ruído, RSSI e outros. Com isso, o netserver pode filtrar mensagens duplicadas advindas de um nó percebido por mais de 1 gateway. Os gateways podem processar até 9 canais paralelos.

Uma grande abstração acontece com essa configuração, migrando a complexidade dos nós para o netserver e permitindo a criação simplificada de componentes das pontas.

Aproveito esse parágrafo para mais uma vez recomendar o documento de Jean Michel de Souza Sant'Ana, que originou esse artigo e que a partir dele pude pesquisar outras fontes, uma vez absorvidas referências conceituais.

Classes de operação LoRaWAN

Um ponto de referência para estudos é a LoRa Alliance. Nesse site encontram-se fundamentos importantes e referências essenciais. Em um grupo de LoRaWAN no facebook esse é provavelmente o link que mais aparece como referência.

Nesse link tem a topologia, classes, taxa de dados e segurança. As classes são descritas como:

Classe A

Menos energia, nós bi-direcionais.

A classe padrão que deve ser suportada por todos os nós LoRaWAN. Uma comunicação é sempre iniciada pelo dispositivo final e é completamente assíncrono. Cada transmissão uplink pode ser enviada a qualquer momento e é seguida por duas janelas curtas de downlink, dando a oportunidade de comunicação bi-direcional, ou comandos de controle da rede, se necessário. Esse é um tipo de protocolo ALOHA.

O dispositivo final está apto a entrar em sleep através de sua própria aplicação. Não há requerimentos de periodicidade para wake-ups.

Devido ao downlink precisar seguir uma transmissão uplink, com um schedule definido pela aplicação do nó, a comunicação de downlink deve ser armazenada em buffer na rede do servidor até o próximo evento de uplink.

À parte, comento que essa rede é ideal para dispositivos alimentados por bateria, já que ele pode dormir sem regras.

Classe B

Dispositivos-final com latência de downlink determinístico.

Além das janelas de recebimento iniciadas na classe A, dispositivos da classe B são sincronizados com a rede usando beacons periódicos e abrem o 'ping slots' de downlink em tempos programados. Isso provê à rede a habilidade de enviar comunicação de downlink com uma latência determinística, mas com um consumo maior de energia no nó. A latência é programável para até 128 segundos para se adequar a diferentes aplicações e o consumo de energia adicional é baixo o suficiente para ainda ser válido para aplicações rodando em bateria.

Classe C

Baixa latência, nós bi-direcionais.

Inicialmente como a classe A, seguido pelas duas janelas de downlink, a classe C reduz a latência no downlink deixando o receptor do dispositivo final aberto sempre que o dispositivo não estiver transmitindo (half-duplex). Baseado nisso, o servidor da rede pode inicar uma transmissão de downlink a qualquer momento ao assumir que o dispositivo final receptor está aberto, portanto, sem latência. A contrapartida é o consumo de energia do receptor (até ~50mW), e portanto, a classe C é aplicável para situações onde uma fonte de alimentação externa supre o dispositivo.

Para dispositivos alimentados por bateria, um modo de troca entre as classes A e C é aplicável e útil para tarefas intermitentes, como update de firmware via OTA (em 2.4GHz, porque na subgiga é como instalar um Windows 10 em um Celeron).

Mensagens da camada física

Uma biblioteca poupará muito esforço, certamente. Fiz um fork de uma biblioteca LoRaWAN que utiliza a rede TheThingsNetwork, que deve servir bem. Mas não deixe de ler o conteúdo desse artigo. Essa biblioteca propõe algumas vantagens, como separar o código da rede do código da aplicação, reaproveitamento de código para leitura dos sensores, framework para programação de baixo consumo e gerenciamento de armazenamento (FRAM) de modo estável e atômico. Entrarei em detalhes mais adiante ou em outro artigo (porque esse já está consideravelmente extenso).

Uplink

Como anteriormente citado, o uplink trata das mensagens enviadas ao netserver, através dos gateways. A comunicação de redes desses dispositivos é um pouco mais "dura" de implementar do que TCP/IP, uma vez que devemos tratar desde a camada física, mas a biblioteca supracitada abstrai um bocado, a ponto de não ser fundamental saber os conceitos todos, mas não deixa de ser necessário ter uma noção ao menos breve da comunicação.

A camada física LoRa utiliza um cabeçalho PHDR seguido de um CRC próprio (PHDR_CRC) e o payload (a mensagem em si) é verificada através de outro CRC, sendo todos os campos inseridos pelo transceiver. A estrutura do uplink também é descrita pela LoRa Alliance:

Downlink

No downlink estão as mensagens enviadas pelo servidor para um nó através de um gateway específico. O cabeçalho da camada física não tem o último CRC.

Após a transmissão do último bit no uplink, duas janelas temporizadas são abertas. Durante essas janelas há a possibilidade de receber configurações de canais para frequência central e espelhamento espectral.

Camada de enlace

Como salientado, o payload  da transação está contido na camada física. Semelhante ao modelo OSI, temos a ligação de dados na camada 2. Ainda na camada 1 (física), a mensagem tem um formato iniciado por um header MAC (MHDR) procedido pelo payload, terminando com o chamado "código de integridade da mensagem" (MIC), no tamanho de 4 octetos.

É importante notar a disposição a seguir, onde cada campo é explodido para um nível macro, semelhante a um DFD:

Para fins de depuração, certamente é válido conhecer essa estrutura. A análise dependerá de um código de depuração que eventualmente poderá se tornar uma rotina replicável. Como estou nos primeiros passos, precisarei analisar a viabilidade e aplicabilidade desse recurso, mas isso ficará para outro artigo.

Tipos de mensagem MAC

No MHDR temos o tipo da mensagem e a versão principal do quadro LoRaWAN. Estão especificados 6 tipos de mensagens MAC, cujos valores estão dispostos a seguir.

Formato proprietário é permitido, mas incompatível com o padrão LoRaWAN, limitando a comunicação entre os dispositivos específicos.

MACPayload

No MACPayload está contido o cabeçalho do quadro (FHDR), porta (FPort) e payload (FRMPayload). Os tamanhos de cada campo são descritos a seguir:

O tamanho máximo do payload N varia conforme região e M sendo o tamanho máximo de payload do MAC, cuja regra é:

N <= M - 1 - (FHDR em octetos)

O FHDR contém o short address do dispositivo, um octeto de controle de quadro (FCtrl), um contador de quadros de 2 octetos (FCnt) e um campo de até 15 octetos para transporte de comandos MAC (FOpts). O endereço do dispositivo tem 32 bits separados em 2 campos, sendo o identificador de rede (NwkID) - utilizado para evitar duplicidades em redes próximas em caso de roaming e o endereço de rede do nó (NwkAddr), cujo endereço pode ser definido de forma arbitrária.

O quadro de controle FCtrl é composto por 5 campos, sendo:

• ADR (Adaptative Data Rate) - responsável por ativar o controle adaptativo da taxa de transmissão do LoRa.
• ADRACKReq - que faz a validação do ADR. O ADR estará correto se a taxa otimizada for maior que a taxa padrão do dispositivo. O dispositivo conta um número de mensagens não respondidas pelo servidor, então configura o ADRACKReq para 1.
• ACK - resposta ao ADRACKReq.
• FPending - usado apenas no downlink, indicando que o gateway possui mais dados prontos para serem transmitidos, então uma janela de transmissão deverá ser aberta tão breve quanto possível.
• FOptsLen - Tamanho do FOpts; se não houver o campo, o valor será 0, de outro modo, existem comandos MAC. FPort deve ser diferente de 0 ou também ausente.
• RFU - Reservado para uso futuro; na classe B, para indicar a classe em uso.

Fcnt

Os nós possuem dois contadores, sendo FCntUp para uplink, que recebe incremento pelo nó, e FCntDown, incrementado pelo netserver, com base no FCntUp para gerar o próximo incremento. Os contadores são zerados após a ocorrência de um Join Accept.

FOpts

Esse campo transporta comandos MAC de até 15 octetos no quadro de dados. Esses comandos não podem estar presentes no payload e opts ao mesmo tempo.

Podemos rodar mais de uma aplicação por nó, diferenciando-as pela porta. Para tal, o campo FRMPayload não deve ser vazio. Se o valor for 0, significa que FRMPayload contém apenas comandos MAC. Os valores de porta vão de 0x01 à 0xDF e o complemento desse byte é reservado.

Criptografia

Na questão de segurança, a comunicação utiliza criptografia AES com chaves de 128 bits. Ela é utilizada no MACPayload previamente ao cálculo do MIC, quando o quadro carregar um payload.

A chave de sessão de rede é identificada pelo NwkSKey, cada dispositivo contendo uma própria. O FRMPayload é criptografado com a chave de sessão de aplicação (AppSKey). Ambas utilizadas simultaneamente impossibilita que o provedor da rede acesse o conteúdo, portanto, NwkSkey é obrigatória, mas a AppSKey é recomendada.

Estou descrevendo conforme a melhor das referências, citada em link e com nome do autor. Inclusive estou seguindo a mesma ordem de apresentação do conteúdo. Em breve citarei mais referências baseadas nos livros recém adquiridos sobre o tema, mas achei fundamental expor os conceitos nesse nível porque tenho minhas dúvidas de que uma análise de redes será feita em caso de problemas. Utilizar LoRaWAN vai muito além de uma mera conectividade, trata-se de uma estrutura robusta, cabeçalhos e transações elaborados. Acredito que essa deva ser uma nova categoria no curso de Tecnologia em Redes de Computadores, da qual sou formado. Apenas com esses conceitos iniciais já vislumbro ferramentas de diagnóstico, análise de conteúdo, sniffing, scanning e muito, muito código. Acredito que essa seja uma área completa e apartada da aplicação, seja ela qual for, de modo que teremos designação de nome para o profissional que atuar em redes LoRaWAN. Por perceber a complexidade da estrutura, decidi comprar 2 livros sobre o tema durante a escrita desse estudo, que escrevo primordialmente como referência técnica. É chato demais para a maioria dos leitores, eu sei, mas é assim que eu costumava guardar meu entendimento de estudo antes de escrever artigos para o blog. Dessa vez decidi compartilhar, pois vi que não é fácil encontrar material desse nível.

Para completar esse tema, em outro artigo darei continuidade às referências e introduzirei conteúdo aprendido nos livros, faltando apenas duas partes que considero importante, então pretendo iniciar uma implementação completa, em parceria com a AFEletronica, que possui o melhor hat LoRa do mercado no mundo - e afirmo sem receio.

Se quiser conhecer um pouco mais sobre o AFMultiRadio, já escrevi alguns artigos relacionados, como esse. Dificilmente você não encontrará um artigo aqui no blog sobre RF, desde 433MHz à 2.4GHz. Minha sugestão é digitar na caixa de pesquisa ou no Google, usando a palavra chave seguida pela palavra "dobitaobyte".

Até a próxima!

Revisão: Ricardo Amaral de Andrade

Inscreva-se no nosso canal Manual do Maker no YouTube.

Também estamos no Instagram.