Casos de uso e considerações para LoRaWAN

Nota importante: Link Labs é o criador do Symphony Link, um protocolo alternativo para LoRa focado em casos de uso industrial e empresarial de alta confiabilidade. Mais abaixo.

Ao procurar entender o LoRaWAN e seus casos de uso ideais e limitações, é importante entender um pouco da história. LoRaWAN (então chamado de LoRaMAC) foi desenvolvido pela Semtech (o único proprietário do LoRa PHY IP) em colaboração com a IBM Research (eles posteriormente deixaram o projeto). As premissas quando o protocolo foi projetado eram:

• Para ser usado por redes de operadoras de celular
• Em uma única rede coordenada
• Na banda de frequência não licenciada de 868 MHz

Essas são suposições importantes, porque o protocolo resultante tem:

• 1% de limite do ciclo de trabalho (para todos os transmissores E o gateway)
• Mapa de canal de frequência comum
• Processamento MAC (camada 2) apenas na nuvem

A fim de oferecer suporte à limitação do ciclo de trabalho de 1% para o gateway, em particular, muitas compensações são necessárias:

• Quase todas as mensagens de uplink não são confirmadas
• Todos os gateways ao alcance veem todo o tráfego de uplink
• Toda a criptografia é tratada com chaves estáticas

Uma vez que todas as mensagens de uplink não são reconhecidas e coordenadas, LoRaWAN é considerado um esquema “puro-aloha”. Essa rede tem cerca de 18% de eficiência. Isso significa que 82% dos pacotes são perdidos quando uma rede LoRaWAN é totalmente utilizada. Como a maioria das mensagens não é confirmada, o nó final não sabe que sua mensagem foi perdida. Para evitar isso, alguns usuários podem transmitir com mais frequência, agravando o problema. Leia esta postagem fácil de entender sobre a Aloha Networks.

Se reconhecimentos são adicionados a este sistema, a eficiência falha ainda mais. Isso ocorre porque, sempre que a estação base está transmitindo, ela não pode ouvir. Os nós finais não sabem que o gateway não pode ouvi-los. Como o gateway pode transmitir apenas 1% do tempo, isso resulta em apenas 1,65% de perda adicional de pacotes.

Além disso, se outra pessoa estiver usando uma rede LoRaWAN, todo o tráfego será contabilizado em relação à sua capacidade. Isso ocorre porque todos os gateways estão sintonizados nas mesmas frequências comuns.

Outra consideração importante para LoRaWAN é o problema de perto / longe. Uma vez que LoRa tem apenas 20-30dB de faixa dinâmica de co-canal, os nós que estão próximos ao gateway abafam os nós que estão distantes. Isso é menos preocupante em grandes redes MNO, uma vez que, idealmente, vários gateways estão ao alcance.

Nossos amigos da The Things Network também prepararam este artigo sobre as Limitações do LoRaWAN.

Dito isso, o caso de uso ideal para LoRaWAN é:

• Sensores simples que precisam transmitir com pouca frequência
• Às vezes, não há problema em se perder de 5 a 85% dos dados
• Pouca capacidade de controlar este dispositivo
• Sem capacidade de atualizar o firmware do dispositivo over-the-air
• Implantado em dezenas a centenas
• Pode implantar vários gateways para cobrir todos os nós

Algumas leituras automáticas do medidor são um ótimo exemplo de um bom caso de uso para LoRaWAN. Para medidores que atualizam a leitura, digamos uma vez por hora, não importa se algumas leituras são perdidas, desde que alguns consigam passar.

O Symphony Link resolve muitos desses problemas. Resumidamente, aqui está como:

1. Enquadramento: O gateway transmite um cabeçalho de quadro a cada 2 segundos, que contém informações sobre quais canais de uplink estão disponíveis e quando a janela de uplink é aberta.

2. Reconhecimentos compactados: No Symphony Link, por padrão, todas as mensagens de uplink são reconhecidas. Para fazer isso, todas as confirmações são misturadas em uma mensagem compactada que todos os nós (que acabaram de transmitir) recebem.

3. Alocação de tempo variável de uplink / downlink: O gateway decide quanto tempo precisa para transmitir com base no tráfego de downlink enfileirado. Diz aos nós quando a janela de downlink está completa, para que os nós nunca transmitam quando o gateway não está escutando

4. Alocação de tempo de uplink: Por causa do enquadramento síncrono, as janelas de uplink têm fendas, o que adiciona cerca de 100% a mais de capacidade. Isso é ainda mais aumentado com a adição de uma janela CSMA variável antes de cada transmissão.

5. Potência variável e fator de propagação: O nó final recebe o RSSI da mensagem de enquadramento do gateway e ajusta dinamicamente sua potência e fator de difusão para corresponder ao link mais um fator de margem configurável. Isso maximiza a capacidade, atenua o desbotamento rápido e evita o problema de perto / longe mencionado acima.

6. Qualidade de serviço: Os nós registram um fator QOS (0-15) com o gateway, e isso limita sua capacidade de acessar canais em cada quadro. Ele também fornece uma maneira para o gateway limitar o uplink durante os períodos de congestionamento.

7. Multicast: Ao atribuir grupos de nós em grupos multicast, a quantidade de downlink necessária para controle e streaming de arquivo é limitada.

8. MTU fixo de 256 bytes: 12 bytes é muito pequeno para a maioria dos aplicativos. O Symphony Link fornece uma MTU fixa de 256 bytes e lida com todos os subpacotes (por SF) e novas tentativas na camada MAC.

9. Firmware over the air: Por causa dos poderosos recursos de multicast no Symphony Link, os arquivos de firmware podem ser enviados para os nós.

10. Chaves AES de sessão baseadas em PKI: O Symphony Link não usa criptografia de chave fixa. Cada nó estabeleceu uma sessão AES segura usando Diffie-Helmann, com a chave pública do nó fornecida pelo servidor. Isso é conhecido em toda a indústria como o esquema de criptografia de canal mais seguro.

Quer saber mais? Entrar em contato.