LoRa (“longo alcance”) é uma excelente solução de comunicação sem fio sem recursos de rede. É uma tecnologia de conectividade sem fio confiável, com baixo consumo de energia, protegida por criptografia e de baixo custo. E como o próprio nome sugere, oferece um alcance extremamente longo.
LoRa opera na camada física de um modelo OSI e é implementado no nível do chip – excluindo o protocolo de gerenciamento de rede. Isso se tornou uma vantagem, pois os engenheiros de sistema podem implementar protocolos de enlace de dados e de camada de rede sobre modulação LoRa e de acordo com os requisitos de uma aplicação específica.
Na Europa, a maioria das redes LoRa está em configurações do tipo “faça você mesmo”. Além das redes personalizadas, a solução de rede ideal para uma rede LoRa é LoRaWAN.
LoRaWAN é um protocolo LPWAN aberto projetado para operar na modulação LoRa, adicionando links de dados e protocolos de camada de rede. O protocolo é responsável pela configuração dos dispositivos finais e pelo gerenciamento da comunicação de dados ponto a ponto.
Este artigo discutirá como os dispositivos são configurados em uma rede LoRa e como o LoRaWAN os conecta à Internet. Para uma introdução a essas tecnologias, leia primeiro O que é LoRa e LoRaWAN?.
Elementos de rede LoRaWAN
Existem cinco blocos de construção de uma rede LoRaWAN que estão conectados em uma topologia estrela de estrelas:
1. Dispositivos finais são sensores, atuadores ou ambos. Eles contêm um chip para modulação LoRa RF e se comunicam sem fio usando a tecnologia LoRa. A maioria funciona com bateria como parte de uma rede IoT, conectando-se à rede LoRaWAN por meio de gateways. Os dispositivos finais seguem um protocolo de acesso aleatório, ALOHA, e podem acessar a rede através de um ou mais gateways próximos dentro do alcance.
2. Entradas são dispositivos responsáveis por encaminhar mensagens de e para dispositivos finais para um servidor de rede. O gateway possui um backbone IP que é celular (3G/4G/5G), fibra óptica, Ethernet, Wi-Fi ou link de rádio de 2,4 GHz, que se conecta ao servidor. Cada gateway é registrado em um servidor de rede LoRaWAN.
Quando um dispositivo final transmite uma mensagem de uplink, ela é recebida por todos os gateways próximos dentro do seu alcance. A mensagem é encaminhada para o servidor de rede, onde é isolada por desduplicação. Esta arquitetura de rede dos dispositivos finais e gateways garante a precisão do pacote de uplink e serve como localização de baixo custo. Quando o gateway recebe um pacote de downlink para entrega a um dispositivo final, a carga útil é transmitida sem interrupção.
Os gateways operam na camada física do modelo OSI e servem como encaminhadores de mensagens LoRa RF. Os gateways são amplamente classificados em gateways internos e externos. Os gateways internos de oito ou 16 canais não possuem antena e, portanto, apresentam menor sensibilidade e alcance do receptor do que os gateways externos. Os gateways internos são ideais para edifícios de vários andares e locais internos profundos.
Os gateways externos de 64 canais possuem alta sensibilidade do receptor e grande alcance. Eles normalmente são conectados a uma antena com um cabo coaxial, por isso são ideais para torres de celular externas ou edifícios altos.
3. Servidor de rede é o software server-side para gerenciamento de rede LoRa, gerenciando a comunicação de dados entre os dispositivos finais (conectados ao servidor de rede via gateways) e o servidor de aplicação. Este servidor autentica os dispositivos finais, desduplica mensagens de uplink, criptografa mensagens de uplink e downlink entre dispositivos finais e servidores de aplicativos e confirma as mensagens de uplink.
Além disso, é responsável pelo endereçamento de dispositivos na rede LoRa por meio de comandos ADR, roteando mensagens de downlink para dispositivos finais por meio de gateways apropriados. O servidor de rede é o único servidor que encaminha mensagens de solicitação de adesão e aceitação de adesão entre os dispositivos finais e o servidor de adesão.
4. Servidor de aplicação é o software do lado do servidor responsável por executar o aplicativo principal e fornecer uma solução de negócios baseada em nuvem. Pode haver vários servidores de aplicativos conectados a um servidor de rede, cada um executando um aplicativo específico do lado do servidor. Os servidores de aplicativos recebem mensagens de dados de uplink específicos do aplicativo de dispositivos finais por meio do servidor de rede, processam dados de aplicativos e retornam resultados como cargas de downlink da camada de aplicativo.
5. Conectar-se ao servidor é o software do lado do servidor responsável por processar mensagens de solicitação de adesão e aceitação de adesão entre dispositivos finais e o servidor de aplicativos. Os servidores de junção foram introduzidos com LoRaWAN v.1.1 para a arquitetura LoRa para habilitar OTAA. Os dispositivos finais requerem ativação por meio de chaves de sessão de rede e de aplicação. O servidor de junção processa mensagens de solicitação de adesão, gera chaves de sessão de aplicativos, transfere chaves de rede e de aplicativos para o servidor de rede e para o servidor de aplicativos e permite a ativação do dispositivo final.
Os dispositivos finais conectados a uma rede LoRa são ativados de duas formas, Ativação por Personalização (ABP) e Ativação Over-The-Air (OTAA). ABP fornece dispositivos finais codificados com chaves para configurar e ingressar em uma rede LoRa. No entanto, apresenta problemas de segurança e não possui recursos para atualizações online.
Classes de dispositivos LoRaWAN
Os dispositivos finais têm três tipos de implementações LoRaWAN (Classe A, B e C), chamadas classes de dispositivos. Todos os dispositivos finais LoRaWAN possuem implementação Classe A. Eles podem ou não ter implementações de Classe B ou Classe C.
As três implementações LoRaWAN diferem na forma como o dispositivo recebe cargas de downlink e no tempo em que permanece ativo.
Classe A é implementado em todos os dispositivos finais LoRaWAN. Os dispositivos exclusivamente Classe A estão principalmente em modo de suspensão e se comunicam apenas com o servidor de aplicativos de forma intermitente.
O dispositivo pode enviar uma mensagem de dados de uplink para o servidor de aplicativos a qualquer momento. Após cada transmissão de uplink, o dispositivo abre duas janelas curtas de recebimento para as cargas de downlink do servidor de aplicativos. O servidor de aplicativos pode transferir a carga útil do downlink na primeira ou na segunda janela de recebimento do dispositivo final, mas não em ambas.
Se o dispositivo não puder receber uma carga de downlink após uma transmissão de uplink, outro downlink será iniciado após o próximo uplink. Os dispositivos finais LoRaWAN Classe A são normalmente sensores para alarmes, monitoramento ambiental ou rastreamento de localização.
Classe B os dispositivos têm uma janela de recebimento agendada para cargas periódicas de downlink do servidor de aplicativos. Os dispositivos são configurados para abrir as janelas de recepção em resposta aos beacons sincronizados no tempo do servidor de rede. Eles também possuem implementação Classe A e abrem duas janelas curtas de recepção após cada transmissão de uplink.
Os dispositivos Classe B são intermitentemente ativos, portanto, têm menor duração da bateria e menor latência do que os dispositivos Classe A. Eles são frequentemente usados para registro ou relatórios de dados de sensores.
Classe C os dispositivos têm uma janela de recebimento continuamente ativa, permitindo que recebam cargas de downlink sem qualquer latência. Os dispositivos LoRaWAN possuem comunicação de dados bidirecional half-duplex, portanto, não podem receber cargas de downlink ao transmitir mensagens de uplink. Eles são alimentados pela rede elétrica e permanecem no modo ativo. Medidores de serviços públicos operando válvulas de corte são um exemplo de uso de dispositivos.
Ativação do dispositivo final
Existem duas ativações de dispositivo final em uma rede LoRaWAN, Ativação por Personalização (ABP) e Ativação Over-The-Air (OTAA). Com LoRaWAN v1.1, OTAA é o método preferido de ativação de dispositivo. A ativação do dispositivo é um procedimento passo a passo e é totalmente gerenciado por um servidor de junção em uma rede LoRa.
Tipos de mensagens
As mensagens comunicadas entre os dispositivos finais e o servidor de aplicação em uma rede LoRa contêm dados de aplicação e/ou comandos MAC. O LoraWAN possui comunicação de dados bidirecional half-duplex entre o servidor de rede e os dispositivos finais. As mensagens são classificadas com base na direção dos dados.
Em termos de direção, eles são classificados da seguinte forma.
- Mensagens de uplink são transmitidos por dispositivos finais para o servidor de junção ou de aplicativos. As mensagens enviadas para um servidor de junção normalmente contêm comandos MAC. Aqueles comunicados ao servidor de aplicação geralmente contêm comandos MAC e/ou dados de aplicação. As mensagens são recebidas pelo servidor de rede através de vários gateways e roteadas para um servidor de junção ou de aplicação com base no tipo de mensagem MAC.
- Mensagens de downlink são enviados pelo servidor de rede para dispositivos finais. A mensagem é retransmitida através de um único gateway pelo servidor de rede para renderizá-la a um dispositivo final.
Tipos de mensagens MAC
As mensagens em uma rede LoRa são roteadas pelo servidor de rede de acordo com o tipo de mensagem MAC. Os seguintes tipos de mensagens MAC estão disponíveis nas especificações LoRaWAN 1.1 e LoRaWAN 1.0.
- Solicitação de adesão: Uma mensagem de uplink de um dispositivo final para ativação OTAA.
- Junte-se a aceitar: Uma mensagem de downlink de um servidor de junção para a ativação OTAA de um dispositivo final.
- Solicitação de reingresso: Uma mensagem de uplink para ingressar novamente na rede LoRA a partir de um dispositivo final. Este tipo de mensagem está reservado no LoRaWAN v1.0, mas disponível no LoRaWAN v1.1.
- Dados não confirmados: Um quadro de dados de uplink no qual a confirmação não é necessária.
- Dados não confirmados desativados: Um quadro de dados de downlink no qual a confirmação não é necessária.
- Dados confirmados: Um quadro de dados de uplink do dispositivo final pelo qual é solicitada a confirmação (isto é, reconhecimento do servidor de rede).
- Dados confirmados: Um quadro de dados de downlink do servidor de rede onde a confirmação é solicitada.
- Proprietário: Uma mensagem proprietária não padrão.
Segurança LoRaWAN
O link de rádio LoraWAN é confiável devido à modulação chirp. Além da modulação tipo FSK, a arquitetura LoRaWAN foi projetada para garantir que as mensagens sejam entregues com a máxima precisão.
As mensagens de uplink são comunicadas a vários gateways e desduplicadas no servidor de rede, não deixando chance de corrupção de dados. A comunicação de rede é protegida com chaves de segurança de 128 bits, incluindo NwkSKey, AppSKey e AppKey. O algoritmo AES-128 é usado para criptografar mensagens, que é semelhante à criptografia no padrão WiFi IEEE 802.15.4. Com a ativação do OTAA, essencialmente não há possibilidade de invasão de dispositivos ou ataques man-in-the-middle.
Para identificação exclusiva dos dispositivos finais pelo servidor de aplicativos, uma chave de aplicativo AppKey é compartilhada apenas entre o servidor de aplicativos e os dispositivos finais. Também pode haver uma chave de aplicativo padrão usada para a ativação de vários dispositivos ou chaves de aplicativo personalizadas geradas por dispositivo final. Essa chave é usada para gerar as chaves de sessão da rede e do aplicativo.
Assim que um dispositivo final ingressa na rede LoRa, o servidor de rede gera duas chaves de segurança: a chave de sessão de rede (NwkSKey) e a chave de sessão de aplicativo (AppSKey). Essas chaves de sessão são aplicáveis somente durante uma única sessão.
A chave de sessão de rede é compartilhada e usada para autenticar o dispositivo final no servidor de rede. A chave mapeia endereços de dispositivos não exclusivos para identificadores exclusivos estendidos de 64 bits DevEUI e AppEUI. Somente o dispositivo final autorizado pode ingressar na rede LoRa devido à chave de sessão da rede. O Código de Integridade da Mensagem (MIC) usa a mesma chave, que serve como soma de verificação para validar a integridade da mensagem.
A chave de sessão do aplicativo criptografa e descriptografa cargas de downlink entre os dispositivos finais e o servidor de aplicativos. Essa chave é privada e nunca é compartilhada na rede, portanto, apenas o dispositivo final autorizado pode transmitir ou receber mensagens com o servidor de aplicativos.
Na ativação OTAA, ambas as chaves de sessão geram uma sessão exclusiva por dispositivo. Na ativação ABP, as chaves são regeneradas somente quando alteradas explicitamente.
A segurança dos dados é ainda mais diversificada com o uso de contadores de quadros. Existem contadores de quadros para mensagens de uplink e downlink. Quando um dispositivo final é ativado, ambos os contadores de quadros são definidos como 0. Quando uma mensagem de uplink é transmitida, o respectivo contador de quadros é atualizado.
Da mesma forma, o contador de quadros de downlink é atualizado imediatamente quando um dispositivo final recebe uma carga útil de downlink. Os dispositivos finais e o servidor de aplicação ignoram qualquer mensagem que contenha um valor de contador de quadros inferior aos contadores de quadros atualizados.