Al diseñar un despliegue LoRaWAN, tarde o temprano aparece la pregunta: ¿este nodo debe ser Clase A, B o C? No es un detalle menor. La clase que elija determina si el dispositivo puede durar años con una batería o si necesita alimentación fija, y también cuánto tiempo tarda la red en hacerle llegar una orden. Elegir mal la clase —o no elegirla a propósito— es una causa común de nodos que se agotan antes de tiempo o de actuadores que responden demasiado lento.
Por qué existen las clases en LoRaWAN
LoRaWAN fue diseñado, ante todo, para maximizar la duración de la batería de miles de dispositivos que transmiten poco y de forma espaciada. Ese diseño choca con una necesidad distinta: a veces la red necesita enviar algo al dispositivo —una orden, un cambio de configuración, una actualización— y no solo recibir sus datos. Las tres clases (A, B y C) son tres soluciones distintas a ese conflicto entre ahorro de energía y capacidad de recibir órdenes (downlink) rápido.
Todo dispositivo LoRaWAN certificado debe implementar, como mínimo, la Clase A. B y C son extensiones opcionales que un fabricante añade sobre esa base cuando el caso de uso lo justifica.
Clase A: la base obligatoria, la más eficiente
Un nodo Clase A solo abre su receptor después de transmitir. El flujo es siempre el mismo: el nodo envía un paquete (por ejemplo, una lectura de sensor) y, apenas termina de transmitir, abre dos ventanas cortas de recepción:
- RX1, exactamente 1 segundo después de terminar el uplink (en AU915, la banda que opera en Ecuador).
- RX2, 1 segundo después de que cierra RX1 —es decir, 2 segundos después del uplink—, en una frecuencia y velocidad de datos fijas.
Si el network server no tiene nada que enviarle en esas dos ventanas, el nodo cierra el receptor y vuelve a estado de bajo consumo hasta su próxima transmisión programada. El resultado: el radio del nodo está apagado la inmensa mayoría del tiempo, que es exactamente lo que permite que un sensor a batería dure meses o años.
La contrapartida es la latencia de downlink: si el gateway necesita enviarle algo al nodo, tiene que esperar a que el nodo transmita por su cuenta. En un sensor que reporta cada 15 o 30 minutos, eso significa que una orden puede tardar hasta ese mismo intervalo en llegar.
Cuándo usar Clase A: cualquier sensor a batería que reporta datos con periodicidad fija y no necesita recibir órdenes urgentes: humedad de suelo, oxígeno disuelto, temperatura ambiente, nivel de combustible. Es el caso del Sensor HUB de Yubox, que opera en Clase A para maximizar la autonomía en campo.
Clase B: ventanas programadas con reloj de red
La Clase B añade a la Clase A una tercera vía de recepción: ventanas programadas (ping slots) que se abren en horarios predecibles, sin depender de que el nodo transmita primero. Para lograr eso, el gateway transmite periódicamente una baliza (beacon) —cada 128 segundos según el estándar— que sincroniza el reloj de todos los nodos Clase B de la red. Con ese reloj común, cada nodo sabe exactamente cuándo abrir su siguiente ping slot, sin tener que dejar el receptor encendido todo el tiempo.
Esto reduce la latencia de downlink frente a Clase A —la red ya no depende del próximo uplink del nodo para poder enviarle algo—, pero consume más batería, porque el nodo debe mantenerse sincronizado con la baliza y abrir ventanas adicionales de forma constante. En la práctica, Clase B es la menos usada de las tres: exige buena cobertura de la baliza en todo el área del despliegue (si el nodo pierde la sincronización, deja de recibir en sus ping slots hasta resincronizar) y son pocos los fabricantes de chipsets y stacks que la implementan de forma completa.
Cuándo usar Clase B: casos intermedios donde se necesita downlink más predecible que en Clase A pero no se puede pagar el consumo de Clase C —por ejemplo, actuadores a batería que deben responder en un horario acotado, no en tiempo real. En los despliegues típicos de campo en Ecuador (agricultura, acuicultura, monitoreo ambiental) es la clase menos frecuente de las tres.
Clase C: receptor siempre encendido
La Clase C lleva el concepto al extremo opuesto: el nodo mantiene la ventana RX2 abierta de forma continua, y solo la cierra durante el instante en que transmite un uplink. Eso significa que el network server puede enviarle una orden en cualquier momento, con una latencia de milisegundos —prácticamente en tiempo real—, sin esperar a ningún ciclo de transmisión ni baliza.
El costo es evidente: un receptor de radio encendido de forma permanente consume mucha más energía que uno que se enciende solo por dos segundos tras cada uplink. Por eso los dispositivos Clase C casi siempre están conectados a alimentación fija (corriente eléctrica) y no a batería, salvo en despliegues de muy corta duración.
Cuándo usar Clase C: cualquier actuador que necesite responder a una orden de forma inmediata: encender o apagar un motor, un aireador, una bomba, una luminaria. Es el caso del Air Control de Yubox, un actuador LoRaWAN para riel DIN pensado para controlar hasta cuatro circuitos eléctricos con relés de grado industrial —típicamente alimentado desde el mismo tablero que controla, sin depender de batería.
Comparación rápida
| Clase A | Clase B | Clase C | |
|---|---|---|---|
| Obligatoria en el estándar | Sí | No | No |
| Cuándo recibe downlink | Solo tras un uplink propio | En ping slots programados + tras uplink | En cualquier momento |
| Latencia típica de downlink | Segundos a minutos (según periodicidad de uplink) | Segundos (según ping slot) | Milisegundos |
| Consumo de energía | Mínimo | Medio-alto | Alto |
| Alimentación típica | Batería | Batería (con concesiones) | Fija (corriente eléctrica) |
| Caso típico | Sensores de campo | Casos intermedios (poco comunes) | Actuadores y relés |
Un mismo dispositivo puede, en algunos casos, alternar entre Clase A y Clase C según el momento operativo —por ejemplo, un nodo que pasa a Clase C temporalmente durante una ventana de mantenimiento para recibir una actualización de configuración más rápido, y vuelve a Clase A el resto del tiempo—. Esa flexibilidad depende del stack LoRaWAN del dispositivo y de que el network server la soporte.
Un error común: forzar Clase C donde no hace falta
Es tentador usar Clase C “por si acaso” en un sensor, pensando que así la red siempre podrá alcanzarlo. En la práctica, eso descarta de entrada la posibilidad de operarlo a batería, y en la mayoría de sensores de campo —oxígeno disuelto, humedad, temperatura— no hace falta downlink inmediato: basta con que la próxima transmisión programada (cada 5, 10 o 15 minutos) traiga la configuración pendiente. Reservar la Clase C para lo que de verdad necesita reacción instantánea —motores, aireadores, relés— es lo que permite que el resto de la red opere con nodos a batería que duran años, como se explica en la nota sobre batería y panel solar para nodos IoT y en el análisis del Spreading Factor y su efecto en la autonomía.
Conclusión
La clase de un dispositivo LoRaWAN no es un detalle de configuración menor: define si puede vivir de batería o necesita corriente fija, y qué tan rápido puede reaccionar a una orden. Clase A para sensores que reportan datos y pueden esperar el próximo ciclo de transmisión; Clase C para actuadores que deben responder ya; Clase B para el caso intermedio, poco común en despliegues reales. La mayoría de una red de campo bien diseñada combina sensores Clase A con unos pocos actuadores Clase C donde realmente se necesita control en tiempo real.
Si está diseñando una red y no está seguro de qué clase necesita cada dispositivo, escríbanos: revisamos su caso de uso y le ayudamos a definir la arquitectura correcta desde el primer nodo.