Columna técnica de ManThink | Serie LoRaWAN, artículo 5
Para desarrolladores, ingenieros de soluciones y responsables de decisiones de proyectos IoT
Introducción: ¿por qué los medidores de agua, las farolas y las pasarelas se ven diferentes en la misma red?
Abra la hoja de datos de cualquier dispositivo LoRaWAN y encontrará una línea: Clase de dispositivo. Los medidores de agua indican Clase A. Las farolas inteligentes podrían ser Clase B. Los gabinetes de relés y las pasarelas son Clase C.
Estas letras no son etiquetas de marketing. Son las tres convenciones de la especificación LoRaWAN para cómo un dispositivo recibe datos de enlace descendente — y determinan directamente:
- cuánto tiempo puede funcionar el dispositivo con una batería;
- con qué rapidez recibe los comandos enviados por la plataforma;
- cómo debe planificar el suministro de energía y el mantenimiento del proyecto.
Una frase captura la esencia: en LoRaWAN, el enlace ascendente es fácil, el enlace descendente es costoso. Enviar datos es barato para un dispositivo; pero para "escuchar siempre lo que dice la plataforma", el receptor de radio debe permanecer encendido — y el consumo de un receptor suele ser cien veces o más superior al del sueño profundo. Las Clases A/B/C son las tres respuestas del protocolo a este conflicto.
Este artículo explica los tres mecanismos y le ofrece una tabla de selección que puede usar directamente en su próximo proyecto.
1. Primero, comprenda el conflicto: ¿por qué es tan difícil el enlace descendente?
LoRaWAN es una red de área amplia de baja potencia (LPWAN). Su endpoint típico es un sensor alimentado por batería, con un objetivo de diseño de "una batería que dure 5–10 años".
Para lograrlo, el dispositivo debe pasar la gran mayoría de su vida en sueño profundo — y un dispositivo dormido está sordo. No puede oír ninguna llamada de la pasarela. Si la plataforma debe poder enviar comandos en cualquier momento (apagado remoto, cambio del intervalo de reporte), el receptor tiene que permanecer encendido continuamente, y la vida de la batería se reduce de inmediato de "una década" a "unos pocos meses".
El consumo de energía y la capacidad de respuesta del enlace descendente son adversarios naturales. Las Clases A, B y C no son tres "tecnologías" — son tres puntos de compromiso a lo largo de este eje: desde "no gastar nada en enlace descendente" (A), pasando por "despertar según un horario para comprobar si hay comandos" (B), hasta "siempre en línea" (C).
Lleva esta guía a tu proyecto
ManThink ofrece productos IoT para conectar dispositivos, desplegar redes y trabajar con datos. Consulta estos recursos de producto junto con las recomendaciones técnicas del artículo:
GD61 Gateway LoRaWAN para interiores · ThinkLink
Conoce los productos de ManThink y consulta tu proyecto →
2. Clase A: escuchar solo después de hablar — la base de menor consumo
Mecanismo: las dos ventanas de recepción
La Clase A es la base obligatoria para todos los dispositivos LoRaWAN — sea cual sea la clase que declare un dispositivo, siempre implementa primero el comportamiento de Clase A.
La lógica es simple: el dispositivo duerme profundamente y solo abre brevemente dos ventanas de recepción después de haber enviado un enlace ascendente:
Device ──uplink──► Gateway/NS
│
│ wait RECEIVE_DELAY1 (default 1 second)
▼
RX1 window opens (brief)
│ if nothing, wait another second
▼
RX2 window opens (brief)
│ if still nothing
▼
back to deep sleep
- RX1: se abre aproximadamente 1 segundo después de que termina el enlace ascendente, normalmente en la misma frecuencia y tasa (o similares) que el enlace ascendente;
- RX2: sigue aproximadamente 1 segundo después, usando la frecuencia y tasa fijas de la región (p. ej., EU868 de RX2 está fijado en 869.525 MHz / DR0; consulte sus Parámetros Regionales).
Ambas ventanas son cortas; una vez cerradas, el dispositivo vuelve a dormir. En otras palabras, la red solo puede alcanzar a un dispositivo Clase A "aprovechando un viaje" — debe esperar a que el dispositivo hable primero. Las cargas útiles de enlace descendente se encolan en el NS hasta que el siguiente enlace ascendente abra RX1/RX2.
Características y casos de uso
| Dimensión |
Rendimiento |
| Potencia |
La más baja de las tres; predomina el sueño profundo |
| Momento del enlace descendente |
Solo después del enlace ascendente; no se puede despertar bajo demanda |
| Latencia del enlace descendente |
Limitada por el intervalo de reporte: reportes cada hora → hasta ~1 hora de espera |
| Suministro típico |
Batería primaria (litio), vida de 8–10 años alcanzable |
Casos de uso: medidores de agua/gas/electricidad, sensores de temperatura/humedad y de suelo — cualquier cosa que "sensar y reportar, con casi ningún enlace descendente". Por eso la Clase A domina el ecosistema de sensores LoRaWAN.
3. Clase B: escucha programada — el punto intermedio
Mecanismo: sincronización por Beacon + Ping Slots
La Clase B añade un "despertar según un horario y echar un vistazo" mecanismo sobre la Clase A:
- Sincronización por Beacon: las pasarelas difunden periódicamente Beacons; tras recibir uno, el dispositivo se alinea con la hora de la red — a partir de entonces, "sabe qué hora es".
- Ping Slots: con la sincronización temporal establecida, el dispositivo abre brevemente una ventana de recepción en momentos fijos periódicos (Ping Slots), escuchando el enlace descendente dirigido a él. ¿Nada? Vuelve a dormir. ¿Algo? Recibe y procesa.
El periodo de Ping Slot es configurable (la especificación define varios niveles desde segundos hasta 128 segundos): periodo más corto → enlace descendente más receptivo, pero más despertares y mayor consumo.
After Beacon sync, the device's timeline:
──┬────┬────┬────┬────┬──►
│ │ │ │
Ping Ping Ping Ping ← scheduled brief windows
Slot Slot Slot Slot
(awake for milliseconds, deep sleep the rest)
Características y casos de uso
| Dimensión |
Rendimiento |
| Potencia |
Ligeramente superior a la Clase A (recepción de Beacon + despertares de Ping Slot) |
| Momento del enlace descendente |
Se puede programar en Ping Slots; ya no depende totalmente del enlace ascendente |
| Latencia del enlace descendente |
Acotada: en el peor caso, un periodo de Ping Slot |
| Requisito de despliegue |
El lado de la red debe soportar la difusión de Beacon — tanto la pasarela como el NS; no es algo que un dispositivo pueda hacer por sí solo |
Casos de uso: farolas inteligentes (horarios estacionales de encendido/apagado enviados remotamente), dispositivos que necesitan sincronización temporal periódica, puntos de monitoreo que deben recibir enlace descendente en minutos. La Clase B es comparativamente rara en la práctica, en gran medida por este umbral de despliegue: toda la cadena (dispositivo–pasarela–NS) debe soportarla.
4. Clase C: el "modo en tiempo real" — para dispositivos alimentados por red eléctrica
Mecanismo: recibir todo excepto mientras transmite
La Clase C abandona por completo la idea de "dormir para ahorrar energía": el receptor de radio permanece encendido casi continuamente, cerrándose solo durante el instante de la transmisión de enlace ascendente (para evitar la autointerferencia), y luego volviendo inmediatamente al modo de recepción.
──RX──RX──RX──│TX│──RX──RX──RX──RX──►
(receiver off only while transmitting)
Con esto, los comandos de la plataforma llegan casi instantáneamente — la latencia de enlace descendente baja de "minutos/horas" a "segundos".
El costo: el consumo está dominado por la corriente de RX
Esta es la cuenta que todo ingeniero debe hacer. Un receptor de radio suele consumir de miliamperios a decenas de miliamperios, mientras que un dispositivo de Clase A en sueño profundo consume microamperios — tres a cuatro órdenes de magnitud de diferencia.
Existe una conclusión de ingeniería bien establecida (no una prohibición del protocolo): la Clase C generalmente no es adecuada para dispositivos con batería primaria. Una celda primaria (p. ej., cloruro de tionilo de litio) no puede sostener una corriente de RX continua; sin un presupuesto completo del ciclo de vida de la alimentación, ninguna afirmación de vida útil de varios años es creíble.
Por lo tanto, las alimentaciones típicas de la Clase C: red eléctrica, PoE o baterías recargables grandes.
| Dimensión |
Prestaciones |
| Consumo |
El más alto de los tres; corriente media dominada por RX |
| Temporización de enlace descendente |
En cualquier momento, casi en tiempo real |
| Latencia de enlace descendente |
Segundos |
| Alimentación típica |
Red eléctrica / PoE / siempre encendido |
Casos de uso: relés y armarios de control (conmutación remota), monitoreo industrial en tiempo real, actuadores — y los propios gateways LoRaWAN (un gateway, como dispositivo "siempre encendido", es naturalmente de Clase C en comportamiento).
5. Comparación lado a lado
| Dimensión |
Clase A |
Clase B |
Clase C |
| Temporización de recepción |
RX1/RX2 solo después del enlace ascendente |
Ventanas de enlace ascendente + Ping Slots periódicos |
Continua excepto durante la transmisión |
| Capacidad de enlace descendente |
La más débil (depende del enlace ascendente) |
Programada, latencia acotada |
Casi en tiempo real |
| Latencia de enlace descendente |
Siguiente enlace ascendente (minutos–horas) |
En el peor caso, un periodo de Ping (segundos–minutos) |
Segundos |
| Consumo |
El más bajo |
Ligeramente superior a A |
El más alto (dominado por RX) |
| Alimentación típica |
Batería primaria |
Batería (capacidad sobredimensionada en consecuencia) |
Red eléctrica/PoE |
| Orden de magnitud de la vida útil de la batería |
5–10 años |
Años (depende del periodo de Ping) |
No aplicable a baterías primarias |
| Requisitos del lado de la red |
Ninguno especial |
El gateway + NS deben soportar Beacons |
Ninguno especial |
| Dispositivos típicos |
Medidores de servicios, sensores de temperatura/humedad |
Farolas inteligentes |
Relés, actuadores, gateways |
Un punto que vale la pena enfatizar: la clase de dispositivo no cambia las definiciones regionales de velocidad de datos, ni puede eludir las regulaciones locales de transmisión — es una convención de comportamiento de recepción de la capa MAC, independiente de los parámetros de la capa física (SF/BW/CR — véase el Artículo 4 de esta serie).
6. Selección: hágase tres preguntas
Pregunta 1: ¿Este dispositivo necesita recibir comandos de enlace descendente?
- Casi nunca (solo reporte) → Clase A, sin dudarlo.
- Sí, pero esperar minutos está bien → véase la Pregunta 2.
- Sí, con respuesta de nivel de segundos (control) → Clase C, y planifique alimentación de red eléctrica/PoE.
Pregunta 2: ¿El dispositivo funciona con batería?
- Sí, y debe durar 5+ años → Clase A; si realmente se requiere enlace descendente periódico, evalúe Clase B y presupueste el consumo con cuidado.
- Red eléctrica/siempre encendido → Clase C está disponible; disfrute del enlace descendente en tiempo real.
Pregunta 3 (para Clase B): ¿La infraestructura lo soporta?
- ¿El gateway y el NS soportan la difusión de Beacon? Sin ello, la Clase B existe solo en el papel.
Una regla práctica: los sensores por defecto a Clase A, los actuadores por defecto a Clase C, y considere la Clase B solo para el punto intermedio. Esto coincide con la mezcla de productos que se ve en la mayoría de los proveedores LoRaWAN hoy en día.
7. Tres conceptos erróneos comunes
Concepto erróneo 1: "La Clase C es más avanzada — elíjala y estará a salvo."
La Clase C no es una mejora; es un compromiso diferente. Configurar un sensor a batería como Clase C significa consumir su batería en corriente de RX — la vida útil cae de una década a meses, mientras también consume capacidad de downlink del gateway. Elegir la clase incorrecta cuesta más directamente que elegir el SF incorrecto.
Idea errónea 2: "Los dispositivos Clase A nunca pueden recibir downlink".
Falso. Un dispositivo Clase A recibe downlink en las ventanas RX1/RX2 después de cada uplink — ACKs, comandos MAC y cambios de configuración caben todos en estas ventanas. Solo la temporización está ligada al uplink. En la práctica, con un intervalo de reporte sensato y encolado de comandos, la Clase A cubre la mayoría de las necesidades de entrega de configuración.
Idea errónea 3: "La clase está fijada en el dispositivo y no puede cambiar".
La clase es comportamiento de la capa MAC. Muchos dispositivos (especialmente DTUs y módulos configurables) admiten conmutación Clase A/C, permitiéndote elegir dinámicamente según la fase del proyecto: Clase C durante la puesta en marcha para aprovisionamiento en tiempo real, de vuelta a Clase A en producción para ahorrar energía. Solo asegúrate de que la lógica de conmutación coincida con la fuente de alimentación.
8. Consejos de práctica de ingeniería
- Primero el presupuesto de energía: sea cual sea la clase, realiza primero la estimación del ciclo de vida energético (corriente de RX/TX/reposo × proporción de tiempo), luego elige la capacidad de batería — especialmente para Clase B y C. Las "promesas de vida útil a ojo" son la principal fuente de disputas posventa.
- Recorta los requisitos de downlink: audita cada requisito de "necesita downlink en tiempo real". Muchos controles llamados de tiempo real se degradan de forma aceptable a "entregar la configuración en el próximo reporte" — lo cual satisface la Clase A.
- Ten en cuenta el cuello de botella del downlink: un gateway típico tiene 8 canales y 16 demoduladores — 16 paquetes de uplink en paralelo pero a menudo solo un único canal de downlink. Muchos dispositivos Clase C más downlink frecuente saturarán ese recurso; planifica la densidad de tráfico de downlink en consecuencia.
- La activación es especial: durante OTAA, el propio Join Accept se entrega en RX1/RX2 — incluso los dispositivos Clase C siguen la temporización de Clase A durante la activación. Esto es otra muestra más de que A es la base.
Conclusión
Las Clases A/B/C son, en esencia, tres líneas que LoRaWAN traza entre "bajo consumo" y "capacidad de respuesta de downlink": A lleva el consumo al mínimo y encola el downlink; B cambia sincronización temporal por latencia de downlink acotada; C cambia alimentación de red por respuesta de nivel de segundos.
Una vez que interiorizas este eje principal, puedes mirar la etiqueta de clase de cualquier dispositivo LoRaWAN e inferir de inmediato su fuente de alimentación, su capacidad de downlink y sus casos de uso apropiados — una habilidad más valiosa que memorizar cualquier parámetro.
Escrito por el equipo técnico de ManThink. ManThink se compromete con una infraestructura LoRaWAN de código abierto y fiable: el gateway de código abierto GD6 (ESP32-S3 + SX1302) admite bandas globales y servidores de red convencionales, y el motor de computación de borde EdgeBus propio admite la conmutación de modo Clase A/C para conectar sensores a LoRaWAN con un consumo mínimo.
Lectura de la serie:
- Artículo 1: Activación LoRaWAN explicada: OTAA vs ABP — Cómo elegir
- Artículo 2: ADR de LoRaWAN explicado: Quién controla la tasa de datos
- Artículo 3: Parámetros regionales de LoRaWAN: Por qué CN470 y EU868 tienen distinto número de canales
- Artículo 4: Capa física de LoRa: Cómo SF, BW y CR determinan el alcance y la tasa