Criando Aplicações LoRaWAN® com Interfaces P2P Simultaneamente

Motivação

Comunicação de dados é um dos assuntos mais importantes quando falamos de aplicações em Internet das Coisas. Cada opção de interface possui suas características próprias que se traduzem em pontos fortes e fracos para cada situação de uso. Quando um produto precisa atender a requisitos em campo que são muito amplos ou contraditórios, podemos ter dificuldade ou até a impossibilidade de atender às especificações de forma satisfatória com as interfaces existentes. Combinar as interfaces é a maneira mais natural de atender às demandas complexas de campo.

Neste artigo vou discutir os aspectos relevantes e mostrar alguns caminhos possíveis para o projetista de nível intermediário poder navegar no ambiente de um stack LoRaWAN, encontrando os pontos adequados para combinar mais de um método de comunicação para o seu dispositivo IoT.

Comunicação P2P

Quando falamos em comunicação ponto a ponto (ou P2P da sigla em inglês peer to peer), estamos simplificando bastante a argumentação. Explico aqui o que tenho em mente.

Rigorosamente falando, toda comunicação acontece inicialmente entre dois pares, ou seja, é P2P na sua essência. A organização de diversos links de comunicação P2P de formas mais complexas é que gera os padrões existentes. A própria comunicação LoRaWAN® faz uso de links de rádio entre as entidades básicas Endpoint (EP) e Gateway (GW). A coleção de todas as ligações entre EPs e um único GW é o que gera a topologia de estrela típica do padrão. Ok, precisamos admitir que como o GW é considerado um concentrador, também podemos dizer que existe aqui uma diferença hierárquica entre os elementos. Porém em outros casos, quando falamos numa rede Mesh por exemplo, temos todos os indivíduos idênticos hierarquicamente comunicando-se entre si de forma organizada e compondo uma topologia que gera caminhos para os dados fluírem pela rede e chegarem até seu destino final. Bem ou mal, em toda rede acaba surgindo aqui uma organização hierárquica mesmo que temporária.

Esta separação dos elementos é um pouco arbitrária ou artificial, e talvez não seja o que de fato identifica o que é um protocolo padronizado e um P2P. Esta dificuldade de descrever os fatos não elimina a necessidade de termos métodos alternativos de comunicação.

Falando de casos práticos, um exemplo muito comum em campo é a criação de caminhos de contingência para que os elementos possam se comunicar entre si quando o fluxo principal pelo protocolo principal se encontra interrompido.
No final, adota-se de forma bastante informal a nomenclatura P2P para toda conexão que foge ao fluxo principal de comunicação pelo protocolo principal. Geralmente estes links buscam resolver questões bastante específicas e usam formatações que são proprietárias.

Questões Práticas

Toda interface de comunicação demanda em vários momentos atenção total seja do HW ou do SW para operar adequadamente. É raro um protocolo de comunicação que não tenha critérios de tempo relativamente rígidos.

No caso específico de dispositivos de baixo custo em IoT duas demandas se somam e se somam para tornar a vida do projetista mais difícil:

1) A necessidade de baixo consumo – portanto reduzir o tempo de operação ao máximo para economizar bateria é essencial. Reduzindo o tempo, a criticidade de cada operação torna-se mais relevante.

2) A pressão por um HW mais enxuto e consequentemente mais barato – é necessário portanto fazer com que um único processador trate de mais de uma tarefa crítica em tempo simultaneamente através de compartilhamento do processamento.

ALERTA: Aqui no nosso texto, vamos tratar daquele caso muito familiar ao projetista brasileiro onde o mesmo processador irá tratar de duas interfaces ao mesmo tempo e não há orçamento disponível para qualquer exagero. Ou seja, a otimização em custo aqui é tratada como essencial.

Acesso ao Código Fonte

Bem, quem precisa entrar neste nível de projeto irá precisar certamente de acesso a todos os detalhes de funcionamento do protocolo principal de comunicação. A separação das tarefas em unidades atômicas é condição básica para tais casos. Um stack (ou pilha) de comunicação que dá suporte a este tipo de acesso é geralmente organizado em uma API bastante padronizada, onde podem ser localizados facilmente os seguintes elementos:

1. 1. Funções básicas para inicialização e configuração do HW (Init)
   2. Funções de Transmissão de Dados (Tx) e Leitura dos Buffers de Recepção (Rx)
   3. Funções de Call Back para retornos de Interrupção
   4. Funções de Temporização e Loop de Comunicação de Dados, que são responsáveis pela execução das máquinas de estado do protocolo

Como cada momento do protocolo é organizado em processamentos separados, fica extremamente fácil de criar as conexões do sistema principal ao stack. Esta conexão pode ser feita de duas formas: a) Diretamente pela chamada das funções nos pontos de interesse, em arquiteturas baremetal (sem sistemas operacionais – OS); b) Com arquiteturas baseadas em sistemas operacionais de tempo real onde as chamadas são organizadas em tasks de forma padronizada.

Em qualquer dos dois casos, usa-se o restante do tempo de processamento não usado pelo protocolo de comunicação para que sejam realizadas as demais tarefas de comunicação de outros protocolos ou ainda tarefas relacionadas ao tratamento de sensores, atuadores ou inteligência local do equipamento.

É aqui que o planejamento de tempo é crucial. As duas interfaces de comunicação precisam ser intercaladas em tempo para que ocorra o processamento dos dois protocolos sem que qualquer dos lados seja prejudicado e cause a queda de qualquer dos links.

Combinando outras Comunicações com LoRaWAN®

O protocolo LoRaWAN® pode ser operado pelo dispositivo em 3 classes, conforme sua iniciativa e disponibilidade em tempo. A Classe A possui uma característica que facilita muito esta organização: a iniciativa da comunicação é sempre realizada pelo Endpoint e o momento do handshake é limitado a um período extremamente curto de Rx num tempo precisamente localizado após o evento de Tx. Esta altíssima disponibilidade do HW, previsibilidade e simplicidade do protocolo abre inúmeras possibilidades de combinar LoRaWAN® com outros protocolos.

Mesmo assim, cabe salientar que o outro protocolo usado precisa abrir mão do HW por algum tempo para que a comunicação LoRaWAN® aconteça. Se este requisito básico não puder ser atendido sem prejuízo grave às outras tarefas, temos uma impossibilidade de atender aos dois num mesmo processador de forma definitiva.

Aqui entra a questão de comunicação P2P como sendo uma alternativa bastante razoável. Como comunicações feitas de forma proprietária podem ser adaptadas para qualquer caso de uso, fica também muito fácil encontrar maneiras de atender a uma especificação básica de linke entre dois EPs.

Uma comunicação P2P, neste caso, é algo que fica sob responsabilidade total do projetista. Uma consulta bastante comum que recebo de clientes nestes momentos é onde encontrar um stack P2P pronto. A verdade é que existe muito pouco material livremente disponível na rede para quem procura isso. Existem alguns motivos para isso. O primeiro é que quase todos os protocolos P2P que são desenvolvidos por empresas acabam sendo mantidos como sigilosos. É o pulo do gato que garante alguma proteção dos produtos contra a cópia não autorizada. O segundo é que sendo tais protocolos predominantemente desenvolvidos para casos específicos, sua formatação não é pensada para ser universal.

Se por um lado isso representa uma dificuldade, por outro, também podemos dizer que não é tão difícil assim de criar um novo protocolo para atender a uma demanda simples. Isso vai demandar algum trabalho, mas geralmente é uma tarefa bem razoável.

Para quem não quer este trabalho ou precisa atender a outras interfaces padronizadas simultaneamente, temos diversos protocolos formais disponíveis. Para exemplificar este caso, lembramos o código das duas bibliotecas LoRaWAN® que estamos disponibilizando aqui contemplam a comunicação do EP também com um aparelho de celular pelo Bluetooth.

Prioridades entre Protocolos

Cada caso de uso vai exigir uma análise cuidadosa de qual protocolo precisará ser priorizado. Definido isso, o outro protocolo será acomodado em torno da codificação do primeiro. Estas definições normalmente seguem a regra de qual dos dois é mais crítico em tempo. Entretanto podemos ter outros motivos para priorizar um deles. No nosso exemplo com Bluetooth, o fato de existir uma aplicação pronta em torno de uma biblioteca fechada cria uma dificuldade adicional para modificar os pontos de chamada e controle do protocolo Bluetooth. Acaba que os motivos se somam aqui. Bluetooth exige uma temporização mais rígida e ao mesmo tempo seria quase impossível entrar no mérito do stack com uma biblioteca à qual não teremos acesso completo.

No caso de um protocolo proprietário P2P combinado com LoRaWAN® provavelmente a decisão seria invertida.

Outra consideração que merece destaque é sobre a utilização do próprio rádio LoRa já codificado no protocolo LoRaWAN®. Esta configuração é possível, sim. Desde que sejam tomados cuidados para que seja garantida a preservação de contexto (variáveis de estado principalmente) de cada interface bem como a completa configuração de todos os parâmetros de transmissão e recepção de pacotes de cada protocolo, não há qualquer problema em rodar dois protocolos sobre o mermo circuito de RF. No final o ambiente percebe o dispositivo como se ele tivesse de fato duas interfaces distintas, cada uma operando um protocolo próprio.

Certificação do Produto

Cada interface de um produto de comunicação por rádio frequência exige o cumprimento de regras legais. No caso do Brasil, a Anatel é quem determina o que pode e deve ser feito.

No caso de LoRaWAN® e Bluetooth, existem regras definidas e claras. Além disso, as entidades certificadoras possuem experiência de como realizar tanto o processamento da documentação quanto dos testes em laboratório. No caso de uma interface P2P proprietária, será necessário o investimento de tempo para entender as possibilidades e encontrar uma maneira autorizada de operar. Depois disso, a certificação desta interface também irá demandar um trabalho específico. Novamente, nada que não seja razoável. O importante é ter ciência do fato e reservar os tempos adequados no cronograma e o orçamento para cada caso.

O Material Básico

Feitas todas as considerações, vamos agora ao que interessa, o exemplo prático.

Existem diversos repositórios hoje disponíveis com exemplos de aplicações LoRaWAN®. O stack básico foi criado faz um certo tempo por uma empresa tradicional no mercado e foi disponibilizado pela Semtech à época da sua criação. Ao longo do tempo, diversos fabricantes de microcontroladores no mercado tomaram este material como base e desenvolveram suas versões adaptadas para diversos modelos de MCUs.

Os dois exemplos que vamos mostrar aqui operam em MCUs da Silicon Labs. Vamos deixar os links dos exemplos para uso com e sem Bluetooth. Mas como o objetivo é demonstrar a operação com interfaces simultaneamente, vamos focar no segundo caso.
Temos duas versões principais do mesmo stack hoje disponíveis para estes processadores:

1) Stack conforme adotado pela Arm e formatado conforme o ambiente mbed:

a. Com Bluetooth (para processador Blue Gecko 13):
https://github.com/udev-br/Silabs-Blue-LoRaWan-Mbed
b. Sem Bluetooth (Para processador Pearl Gecko 12):
https://github.com/udev-br/Silabs-Pearl-LoRaWan-Mbed

2) Stack conforme a herança original:

a. Com Bluetooth (para processador Blue Gecko 22):
https://github.com/udev-br/LoRaMac-Node-xG22-soc_thermometer
b. Sem Bluetooth (para Processador Pearl Gecko 22):
https://github.com/udev-br/LoRaMac-Node-PG22-DK2503A

Todos os exemplos acima foram feitos em implementação baremetal, ou seja, sem a utilização de um sistema operacional. As chamadas às funções da API do stack LoRaWAN acontecem por inclusões do código dentro do fluxo principal do exemplo, conforme veremos a seguir.

O Exemplo SoC Thermometer

Como aplicação exemplo, optamos por usar um medidor de temperatura e umidade disponível em diversos kits da Silabs.

Para maiores detalhes sobre este exemplo, deixamos aqui o link para um Application Note com todas as informações necessárias para repeti-lo da forma mostrada.

De modo geral, o fluxo de trabalho adotado foi o seguinte:

1. 1. Criar um projeto exemplo que implementasse uma aplicação de termômetro, conforme disponível nas ferramentas da Silabs;
   2. Incluir os arquivos e diretórios do stack LoRaWAN no mesmo projeto;
   3. Adaptar os arquivos para tornar o conjunto compilável (modificações dos includes, configurações, adaptação dos defines de configuração, dados de comissionamento LoRaWAN, etc);
   4. Incluir as chamadas de funções da API LoRaWAN nos pontos adequados.

Os Pontos de Conexão do Stack LoRaWAN® com a Aplicação Bluetooth
Além do procedimento óbvio de incluir os arquivos da pilha LoRaWAN® no código original do exemplo SoC Thermometer, existe uma tarefa que exige maior cuidado que é a própria chamada das funções principais da API que irão criar o funcionamento correto de ambos os protocolos simultaneamente.

Aqui mostramos o código do arquivo main.c onde fica a função main do código. Observe que foram removidos comentários do código original para deixar o conjunto mais legível.

Veja que existe um bloco de inicializações (e que precede o loop principal da função main). Outra coisa que chama a atenção é a chamada da função que faz o processamento do stack periodicamente como parte do loop principal. Apesar de ser a primeira coisa a ser feita, a organização geral da pilha Bluetooth foi preservada. Todo o tratamento de eventos é o tratamento original da pilha Bluetooth.

Logo no meio dos eventos também existe uma chamada à função que faz a medida (leitura do sensor) de temperatura. Essa função também fica localizada no arquivo main.c em outro trecho que detalhamos a seguir.

Em verde foi marcado o processamento da leitura do sensor, em azul o envio desta informação por Bluetooth e em vermelho, a parte que foi inserida para gerar o processamento LoRaWAN desta aplicação. Isso significa que optou-se por chamar o processamento LoRaWAN para cada leitura do sensor.

Cabe aqui uma pergunta importante: Em virtude desta decisão, o que precisamos observar com o máximo de cuidado? A resposta não é óbvia, mas essencial. Já que o protocolo LoRaWAN assume um tempo de handshake que inclui ambos os timers RX_DELAY_WINDOW1 e RX_DELAY_WINDOW2, a chamada à leitura dos sensores não pode ser mais frequente do que o maior destes timers. De fato, é necessário inclusive reservar tempo de sobra para permitir o processamento com alguma folga.

A última parte do código que vamos detalhar aqui é a chamada da construtora da classe LoRaWANClass dentro do arquivo LoRaWAN.cpp.
Veja que a definição da interface de rádio em uso acontece ali dentro, a partir da chamada do construtor de uma das classes SX126X_LoRaRadio ou SX1272_LoRaRadio. A seleção de qual construtor é chamado é feita de maneira bastante trivial com diretivas de pre compilação.

Existem diversos outros pontos no código onde é possível observar a integração e interação dos dois códigos, mas estes são os principais e que merecem destaque. Veja que é um trabalho relativamente simples, mas que exige um bom conhecimento de ambos os protocolos, os códigos disponíveis e principalmente um bom planejamento e debug durante os trabalhos.

Conclusão

Realizar projetos que resultem em produtos multiprotocolos é perfeitamente possível e muito útil para levar a economias significativas de custo bem como habilitar o projeto a complementar as funcionalidades de um protocolo com outro.

Apesar do exemplo simples apresentado realizar apenas o compartilhamento da mesma informação básico de temperatura e umidade, podem ser realizadas tarefas bem mais complexas, como por exemplo permitir a atualização de FW através de uma conexão local via Bluetooth utilizando-se um celular, por exemplo, enquanto que a interface LoRaWAN fica reservada para a operação diária em baixo consumo e com distâncias muito maiores de alcance.

Também discutimos aqui a possibilidade de utilização de protocolos rodando sobre a mesma interface de rádio.

Estas possibilidades elevam o valor de uma solução de IoT para o cliente final ao mesmo tempo em que dão recursos ao projetista para ampliar seu repertório ao resolver soluções de campo.

Faça download do manual complementar abaixo, que ensina como criar rapidamente uma solução com conectividade multiprotocolo Bluetooth e LoRaWAN utilizando-se placas de desenvolvimento da Silicon Labs e da Semtech interconectadas e combinadas com o recentemente lançado stack LoRaWAN.

Solução Bluetooth Comunicando com a Rede LoRaWAN

Preencha o formulário abaixo que enviaremos o manual para o seu e-mail: