Firmware-Over-the-Air (FOTA) vía LoRa: Por qué es difícil y cómo Symphony Link lo resuelve

Actualizar firmware de dispositivos over-the-air (FOTA) usando LoRaWAN es prácticamente imposible para nodos alimentados por batería.

La LoRa Alliance señala que tramas multicast —disponibles solo en dispositivos clase B y C— pueden transportar firmware, pero esto no aborda las limitaciones prácticas de dispositivos clase A que la mayoría de despliegues usan. Foros comunitarios como The Things Network, Libelium y otros confirman que FOTA estándar LoRaWAN no es viable. Symphony Link, un protocolo LoRa propietario, fue construido con FOTA en mente y ofrece una solución probada.

• Beneficios clave de negocio de Firmware-over-the-Air

Por qué FOTA sobre LoRaWAN es desafiante

1. Transmisiones de gateway no coordinadas – Los gateways transmiten segmentos de firmware sin escuchar la red. Los nodos no pueden detectar que el gateway está transmitiendo y perderán cualquier paquete que envíen durante ese período.
2. Sin capacidad multicast para Clase A – El multicast se añadió para clase B/C para soportar funciones como control de alumbrado público, no firmware. Nodos clase A alimentados por batería no pueden recibir multicast, haciendo FOTA imposible para ellos.
3. Restricciones de duty-cycle – En regiones gobernadas por ETSI, gateways pueden transmitir solo el 1% del tiempo. La mayor parte de ese ancho de banda se consume en acknowledgements y tráfico MAC, dejando virtualmente cero espacio para downlinks multicast. En EE. UU., la falta de límite de duty-cycle significa que la red se colapsaría durante actividad downlink intensa.

Firmware-over-the-Air usando Symphony Link

Symphony Link puede entregar un archivo hasta 256 KB desde un access point a un nodo individual o grupo de nodos. Extendiendo temporalmente el período Infrastructure Beacon (IB), el access point gana capacidad downlink extra para la transferencia de firmware mientras la red permanece funcional para tráfico uplink. Una vez finalizada la actualización, el access point vuelve a su horario IB normal.

Inicialización de transferencia de archivo OTA

Durante la inicialización, el access point anuncia un nuevo archivo de firmware a sus nodos finales asociados. Luego pausa, esperando respuestas. Una vez que se cumple un criterio predefinido —como un número mínimo o porcentaje de nodos listos— o ocurre un timeout, el access point comienza a transmitir el archivo en segmentos.

Proceso de transferencia de archivo OTA

Para maximizar throughput, un access point envía múltiples segmentos de archivo en una sola trama. A diferencia de downlinks típicos —donde solo se transmite un mensaje por nodo o un broadcast— el access point agrega varios segmentos. El nodo recibe y une estos segmentos. Tras cada ráfaga completa, el nodo reporta segmentos faltantes.

El access point entonces compila una lista de retransmisión basada en los reportes de los nodos y envía los segmentos faltantes. Este ciclo stop-and-wait de acknowledgment-retransmission (ARQ) continúa hasta que todos los nodos confirman recepción exitosa o se alcanza un umbral de fallo.

Terminación de transferencia de archivo OTA

Una vez que un nodo reporta recepción exitosa, permanece despierto hasta recibir un comando Apply File del access point. Ese comando finaliza la actualización y dispara la activación del firmware.

Conclusión

El método OTA de Symphony Link puede transportar código de aplicación, scripts, datos de configuración, claves de cifrado, bases de datos, o firmware de módulo. Desbloquea una gama de casos de uso industriales y enterprise que eran previamente infactibles con LoRaWAN estándar.