Firmware-over-the-Air (FOTA) com LoRa

Seria quase impossível atualizar o firmware do dispositivo over-the-air (FOTA) usando LoRaWAN ^TM .

A LoRa Alliance afirma que tal operação é possível nesta página, embora se refira a quadros multicast disponíveis em dispositivos de classe B e C.

Aqueles nos fóruns de usuários discordam:

O Fórum da Rede Things.

Fórum Libelium

Symphony Link ^TM , o protocolo Link Labs para LoRa foi projetado com FOTA em mente. Mais sobre o Symphony Link FOTA abaixo.

• Veja também:Principais benefícios comerciais do Firmware-over-the-Air

O motivo pelo qual o firmware over the air com LoRaWAN é difícil decorre de alguns fatores:

1. As transmissões do gateway não são coordenadas. Isso significa que, independentemente do tempo que o gateway gasta transmitindo mensagens de downlink de firmware, ele não está ouvindo a rede. Os nós em uma rede LoRaWAN não sabem que o gateway não está ouvindo, portanto, qualquer mensagem que eles tentarem enviar durante o tempo de transmissão do gateway será perdida.
2. Não existe um conceito de camada MAC para colocar um nó de Classe A em um modo em que possa receber quadros multicast. Multicast foi adicionado no LoRaWAN aos nós de classe B / C para permitir coisas como controle de luz de rua, não realmente para transferências de firmware. O que isso significa é que FOTA para dispositivos LoRaWAN alimentados por bateria não é possível , uma vez que não podem receber frames multicast.
3. Gateways LoRaWAN têm ciclo de trabalho limitado. Os gateways LoRaWAN podem transmitir apenas 1% do tempo (ETSI) e, portanto, provavelmente precisam de todo esse recurso de downlink para confirmações e mensagens de controle MAC. Muito, muito pouco sobraria para o multicast FOTA. No esquema dos EUA, onde o limite de ciclo de trabalho de 1% não é necessário, a rede basicamente para de funcionar para uplink devido ao # 1.

Firmware-over-the-Air usando Symphony Link

O Symphony fornece um mecanismo para fazer downlink de um arquivo de até 256 KB de um ponto de acesso para um nó final ou grupos de nós. O ponto de acesso define o período do Infrastructure Beacon (IB) com um valor alto, fornecendo mais capacidade de downlink para a transferência de arquivos. Isso permite que a rede ainda funcione para uplink durante as operações FOTA. Assim que a transferência for concluída, o ponto de acesso retorna ao período IB programado anteriormente.
Figura 1. Transferência de arquivos OTA. Inicialização para a primeira transmissão completa de todos os segmentos de arquivo

Inicialização de transferência de arquivo OTA

Um exemplo de inicialização de transferência de arquivo OTA pode ser visto na Figura 1. Um ponto de acesso notifica seus nós finais associados que possui um novo arquivo para fazer o downlink. O ponto de acesso então pausa e espera a resposta dos nós finais. Uma vez que os critérios especificados pelo usuário são atendidos (por exemplo, número ou porcentagem de nós capazes de participar, tempo limite), o ponto de acesso começa a fazer o downlink do arquivo em segmentos.
Figura 2. Transferência de arquivos OTA. Exemplo de retransmissão de segmento de arquivo. ARQ até o final da transferência.

Transferência de arquivo OTA

Para aumentar o rendimento da transferência de arquivos, um ponto de acesso faz o downlink de vários segmentos de arquivo por quadro. Isso contrasta com outros pacotes de downlink, em que um ponto de acesso apenas faz o downlink de apenas uma mensagem por nó por quadro ou de uma mensagem de broadcast por quadro. O nó final recebe e agrega todos os segmentos de arquivo recebidos em um determinado quadro. Uma vez que um ponto de acesso está pronto para fazer o downlink de seu arquivo, ele envia todos os segmentos de arquivo sequencialmente e, em seguida, faz uma pausa.

Na Figura 1, a sequência de tempo termina depois que todos os segmentos de arquivo são transmitidos uma vez. Nesse momento, cada nó final que participa da transferência de arquivos envia uma lista de segmentos de arquivo não recebidos com êxito por esse nó final. O ponto de acesso então monta uma lista de retransmissão de segmento de arquivo com base nas solicitações de seus nós finais. Um nó final também pode solicitar que o ponto de acesso retransmita todos os segmentos de arquivo. O ponto de acesso retransmite os segmentos de arquivo e o processo se repete até que todos os nós participantes notifiquem o ponto de acesso de uma transmissão bem-sucedida ou de um critério de falha ser atendido.

A Figura 2 mostra um exemplo de retransmissão de segmento de arquivo e um nó relatando uma recepção de arquivo bem-sucedida. O ponto de acesso envia segmentos de arquivo como mensagens de downlink não confirmadas. O esquema ARQ é obtido à medida que os nós relatam suas solicitações de retransmissão.

Término da transferência de arquivos OTA

Uma vez que um nó relata que recebeu o arquivo com sucesso em seu ponto de acesso, ele permanece acordado até receber um comando do ponto de acesso para aplicar o arquivo. Na Figura 2, o evento final é o ponto de acesso que encerra a transferência do arquivo com o comando “Aplicar Arquivo”.

Conclusão

O método de transferência de arquivo OTA pode ser usado para transferir software aplicativo, scripts, configuração, chaves de criptografia, bancos de dados ou atualizações de firmware do módulo Symphony Link. É uma adição poderosa ao Symphony Link que possibilita muitos casos de uso industriais e corporativos.