Nota de la serie: Esta es la Parte 10 de la serie LoRaWAN Technical Deep-Dive de ManThink. Ya hemos cubierto los parámetros de capa física, los compromisos SF/BW/CR, las Clases A/B/C, el linaje SX1301/1302/1303, el ESP32-S3 como host de puerta de enlace, la geolocalización TDOA/RSSI y los tres protocolos de backhaul (Basic Station / UDP / MQTT). Este artículo vuelve a la pregunta de ingeniería más frecuente — y más a menudo mal respondida —: ¿cuántos dispositivos finales puede soportar una puerta de enlace?
"¿Cuántos dispositivos puede manejar su puerta de enlace?"
Esta es la primera pregunta que se hace en cada reunión de soluciones LoRaWAN y la primera celda que se rellena en la hoja de cálculo de cada responsable de compras. La respuesta no está en ninguna hoja de datos de producto, porque la misma puerta de enlace en un despliegue real puede servir dispositivos 700 — o 20,000. El hardware no ha cambiado. Solo han cambiado las condiciones del despliegue.
Esto no es exageración del proveedor. Una puerta de enlace SX1302 puede efectivamente transportar decenas de miles de sensores bajo un conjunto particular de supuestos — solo que esos supuestos casi nunca se declaran explícitamente. Así, el mismo hardware soporta honestamente una dispersión de dos órdenes de magnitud entre despliegues. La diferencia no es la puerta de enlace. Es principalmente la cobertura.
Este artículo desglosa la capacidad de la puerta de enlace: qué te da el hardware, qué te quita el protocolo ALOHA, qué parámetros puedes realmente ajustar en campo y, finalmente, una fórmula de estimación lista para usar con un flujo de decisión de tres pasos.
Las puertas de enlace LoRaWAN modernas están casi universalmente construidas en torno al concentrador Semtech SX1302. Para hablar de capacidad, primero debemos mirar dentro de este chip.
De la hoja de datos oficial del SX1302 de Semtech:
Sensibilidad -141 dBm con el front-end de RF SX1250. El consumo de energía es aproximadamente un orden de magnitud menor que el de su predecesor, el SX1301.
Idea clave: los 8 canales de frecuencia y los 16 demoduladores son compartidos, no están vinculados uno a uno. El mismo canal de frecuencia con diferentes SF puede ser decodificado en paralelo por diferentes demoduladores; diferentes canales de frecuencia con diferentes SF obviamente también pueden serlo.
Pero 16 no es un número grande. Cuando llega el paquete número 17, se descarta silenciosamente — sin cola, sin solicitud de retransmisión. El techo de concurrencia del SX1302 termina justo aquí.
Es precisamente aquí donde el SX1303 traza otra línea en la arena: habilitar su función Fine Timestamp reduce el techo de concurrencia de 16 a 8 — véase la Parte 8 de esta serie.
En despliegues reales, la capacidad de la puerta de enlace rara vez está limitada por los demoduladores. Está limitada por el tiempo de aire.
Para que esto sea intuitivo, aquí están los tiempos de aire medidos para una carga útil de 13 bytes, BW=125 kHz, CR=4/5. Estos son números reales de la calculadora LoRa oficial de Semtech, que utiliza el modelo físico de RF interno de Semtech:
| SF | Tiempo de aire | Relativo a SF7 |
|---|---|---|
| SF7 | 46.3 ms | 1.0× |
| SF9 | 164.9 ms | 3.6× |
| SF10 | 288.8 ms | 6.2× |
| SF11 | 577.5 ms | 12.5× |
| SF12 | 1155.1 ms | 25× |
Un dispositivo en SF12 consume tanto recurso de red como 25 dispositivos en SF7. La carga útil es idéntica. La única diferencia es lo lejos que está, o lo mala que es la conexión.
Por esto la distribución de SF, y no el número de dispositivos, es la métrica real de capacidad en la ingeniería LoRaWAN, y por lo que una mejor cobertura te da más capacidad gratis — no porque hayas mejorado el hardware, sino porque la proporción SF7/SF8 de tu flota aumentó.
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:
Los dispositivos LoRaWAN hablan cuando tienen algo que decir: sin planificación, sin reserva de canal y, en la mayoría de las regiones, sin escuchar antes de transmitir. Esto hace que el canal de enlace ascendente sea esencialmente un canal ALOHA.
ALOHA tiene una propiedad desagradable: el rendimiento aumenta con el tráfico ofrecido hasta un punto, y luego cae. No se estabiliza — cae. Pasado el pico, más transmisiones producen menos recepciones exitosas, porque las colisiones destruyen paquetes, los dispositivos reintentan y los reintentos crean más colisiones.
El pico se produce en torno al 18% de utilización del canal. Superado este número, la red pasa de "funcionar" directamente a "parecer un fallo de los dispositivos".
LoRaWAN no se degrada de forma gradual al alcanzar su capacidad. Funciona, y luego colapsa. Este modo de colapso aparece en un panel de monitorización como "pérdidas aleatorias de dispositivos" en lugar de "gateway llena", que es exactamente la razón por la que tantos ingenieros de campo no logran encontrar el cuello de botella.
ALOHA no es del todo desesperanzador. LoRa tiene un Efecto de captura: cuando dos paquetes colisionan en el mismo canal y SF, el más fuerte —unos 6 dB por encima del otro— aún puede decodificarse.
Esto significa que una red bien planificada con dispositivos distribuidos a lo largo de un gradiente de pérdida de trayecto supera al modelo teórico. También es la razón por la que una buena planificación de cobertura equivale a una ganancia de capacidad gratuita — los dispositivos deben distribuirse a lo largo de un gradiente para que el efecto de captura haga su trabajo.
Pero el efecto de captura no cambia la forma de la curva, solo la desplaza un poco hacia la derecha.
Traduzcamos los números anteriores a "presupuesto de canal por hora" (EU868, 8 canales):
Hourly channel budget = 8 channels × 3600 seconds = 28,800 channel-seconds/hour
ALOHA usable budget = 28,800 × 18% ≈ 5,200 channel-seconds/hour
Divídelo entre el tiempo de aire que consume cada dispositivo por hora y la capacidad teórica se obtiene directamente. La base de conocimiento de ThinkLink, suponiendo cargas útiles de 13 bytes, gateways de 8 canales e intervalos de enlace ascendente horarios, ofrece las siguientes estimaciones oficiales:
| Nivel de SF | Tiempo de aire de 13 bytes | Capacidad teórica con 8 canales |
|---|---|---|
| SF7 | 46.3 ms | ~787,000 |
| SF9 | 164.9 ms | ~253,000 |
| SF12 | 1155.1 ms | ~29,000 |
Nota: este es el techo teórico, suponiendo cero colisiones, cero retransmisiones y cero enlace descendente. La capacidad de despliegue en el mundo real suele ser del 30–50% del valor teórico — por lo que las afirmaciones de "cientos de miles por canal" de los folletos casi nunca se materializan sobre el terreno.
La decisión de diseño más contraintuitiva de LoRaWAN es su asimetría entre enlace ascendente y descendente:
Así que la "congestión del enlace descendente" es el mayor riesgo oculto al escalar LoRaWAN, y casi nunca aparece en despliegues pequeños. Una vez que se superan los 1,000 dispositivos, el enlace descendente empieza a convertirse en el cuello de botella: Join Accept, ACK, comandos MAC — todo el tráfico de enlace descendente tiene que pasar por este único canal de transmisión.
Muchos equipos evalúan la carga de LoRaWAN por el "número de dispositivos". Esto es un error. La métrica correcta es el tiempo de aire total ponderado por SF.
Ejemplo: un sitio tiene 1,000 dispositivos, de los cuales 200 están atascados en SF12. Su carga equivalente es aproximadamente 200 × 25 = 5,000 dispositivos SF7. El sitio parece "verde" en una hoja de cálculo de "1,000 dispositivos", pero en la capa de red ya está en rojo.
Si quieres saber cuánto se acerca tu red al umbral de ALOHA, el método más directo es consultar el histograma de distribución de SF de las últimas 24 horas en el backend de tu servidor de red. Más de un 10% de cuota SF12 es una señal de advertencia; más de un 20% significa que es momento de hacer optimización de cobertura.
Una carga útil de 13 bytes y una de 50 bytes en SF12 consumen 1155 ms y 2468 ms respectivamente — el paquete de 50 bytes consume el doble de tiempo de aire.
Muchos equipos empiezan metiendo todo en el cable (marca de tiempo, ID del dispositivo, lectura del sensor, voltaje de la batería, intensidad de señal, versión del firmware, CRC). Recortar las cargas útiles es la forma más barata de escalar — pasar de 50 bytes a 13 bytes reduce a la mitad el tiempo de aire con el mismo SF, lo que equivale a duplicar la capacidad.
Estas palancas están ordenadas de menor a mayor coste. Ajusta siempre las primeras antes de gastar en hardware nuevo.
ADR es el mecanismo integrado de adaptación de velocidad de LoRaWAN. Deshabilitar ADR equivale a reducir a la mitad tu capacidad — todos los dispositivos usarán SF12 por defecto, consumiendo 25× el tiempo de aire de SF7.
Con ADR habilitado, el NS ajusta el SF de cada dispositivo según el presupuesto de enlace. Con el tiempo, la cuota SF7/SF8 debería aumentar significativamente.
Advertencia: el ADR del lado del servidor puede sufrir retrasos en la entrega bajo una alta carga de enlace descendente, dejando los dispositivos atascados en SF12. El ADR local permite que los dispositivos se autoajusten según el RSSI/SNR local, lo que es más fiable. El runtime propietario EdgeBus (EB) de ManThink incluye ADR local de serie.
Cada enlace ascendente confirmado requiere un ACK de enlace descendente. El enlace descendente es un solo carril.
Pasa los datos no críticos (temperatura, humedad, voltaje de la batería, latidos periódicos) de Confirmado a No confirmado, y traslada la fiabilidad a la capa de aplicación (reintento, deduplicación, agregación). Esto reduce significativamente el tráfico de enlace descendente — la forma más barata de aliviar el cuello de botella del enlace descendente.
"Encender y unirse" es un antipatrón clásico. Imagine 5,000 dispositivos, tras un corte masivo, todos encendiéndose a la vez — todos enviarán solicitudes de unión en el mismo segundo, y el canal de enlace descendente de aceptación de unión se saturará.
La forma correcta:
- Unión bajo demanda: activar una unión solo tras N enlaces ascendentes fallidos consecutivos
- Retardo aleatorio basado en UTC: cada dispositivo usa pseudo_random_delay = (DevAddr & 0xFF) × 100 ms para distribuir los intentos
La protección de unión de ManThink EdgeBus hace exactamente esto: retardo aleatorio integrado y reintento de unión, evitando la "avalancha de uniones" tras una recuperación de energía a gran escala.
Una regla empírica contraintuitiva pero verificada repetidamente:
| Escenario de despliegue | Referencia de densidad de gateways |
|---|---|
| Urbano denso | 1–2 por km² |
| Suburbano / rural | 1 por 5–10 km² |
| En interior de edificios (penetración de 5–10 pisos) | 1–2 por edificio |
| Planta de fábrica | 1 por 5,000–10,000 m² |
Demasiado denso (3+ gateways en la misma área recibiendo todos el mismo paquete) desperdicia hardware pero se compensa con una mayor tasa de éxito de recepción; demasiado disperso empuja a los dispositivos a SF altos y colapsa la red.
"23.5" como int16 ahorra 2 bytes directamenteMueva el juicio de alarmas, el filtrado de umbrales y la agregación de datos al gateway o al dispositivo final. Envíe solo excepciones y resúmenes — esta es la verdadera característica clave para escalar LoRaWAN.
ManThink EdgeBus (EB) está diseñado exactamente para esto: ejecutar lógica de computación en el borde orientada a eventos en MCUs de bajo consumo (Cortex-M0 es suficiente), haciendo que "la mayor parte del tiempo sin enlace ascendente" sea la norma. Esto eleva la métrica de capacidad de "paquetes por segundo" a "anomalías por día" — una escala completamente diferente.
Paso 1 | Calcule el tiempo de aire por hora por dispositivo
T_airtime = packet_time(SF, payload_size) // Use the Semtech LoRa calculator
T_device_hourly = (3600 / send_interval_sec) × T_airtime
Paso 2 | Calcule el presupuesto de canales por hora del gateway
B_gateway_hourly = 8 × 3600 × 0.18 = 5,184 channel-seconds/hour
Paso 3 | Calcule la capacidad teórica, deje un margen del 50%
N_max = B_gateway_hourly / T_device_hourly
N_recommended = N_max × 0.5
Un despliegue de agricultura inteligente: - 1,000 sensores de humedad del suelo - Enlace ascendente cada 10 minutos - Carga útil de 8 bytes (humedad + temperatura) - Con ADR habilitado, distribución estimada de SF: 60% SF7 / 25% SF8 / 15% SF9
Tiempos de aire medidos (8 bytes, BW125, CR4/5, calculadora de Semtech): - SF7 ≈ 41 ms - SF8 ≈ 77 ms - SF9 ≈ 164 ms
Tiempo de aire promedio ponderado:
T_avg = 0.6 × 41 + 0.25 × 77 + 0.15 × 164 ≈ 69 ms
Consumo por hora por dispositivo:
T_device = (3600 / 600) × 0.069 = 0.414 channel-seconds/hour
Capacidad teórica de un solo gateway:
N_max = 5,184 / 0.414 ≈ 12,500 devices
Límite de despliegue recomendado con un margen del 50%:
N_recommended ≈ 6,200 devices
1,000 dispositivos es cómodo bajo este presupuesto. Un único gateway SX1302 de 8 canales es más que suficiente.
Contraste: si la cobertura es deficiente y todos los dispositivos están en SF12:
T_device = 6 × 1.155 ≈ 6.93 channel-seconds/hour
N_max = 5,184 / 6.93 ≈ 748 devices
N_recommended ≈ 374 devices
Los mismos 1,000 dispositivos — pero con cobertura deficiente, un único gateway no puede soportar la carga, y un segundo gateway (u optimización del despliegue de antenas) es inmediatamente necesario.
El ManThink GD6 (ESP32-S3 + SX1302) está posicionado para despliegues pequeños y medianos. Aplicaciones típicas:
El gateway comercial exterior ManThink GDO518 (SX1302, 16 puntos de frecuencia + demodulación concurrente de 32 paquetes): - Escala de dispositivos recomendada: 5,000–20,000 dispositivos / gateway - Adecuado para despliegues a gran escala urbana (ciudad inteligente, agricultura inteligente, seguimiento de activos) - Soporte de Docker para ejecutar computación en el borde EB en el gateway - Ranura SIM externa + puerto serie de depuración — sin necesidad de abrir la carcasa para mantenimiento
Un caso real: un despliegue de agricultura inteligente en Jiangsu, China — un único gateway GDO518 soportando 8,000 sensores de suelo (enlace ascendente cada 15 minutos, carga útil de 6 bytes, ADR habilitado), funcionando de forma estable durante 12 meses.
Concepto erróneo 1: SX1303 equivale a mayor capacidad
Incorrecto. El SX1303 es compatible en pines con el SX1302 y tiene el mismo número de demoduladores, pero habilitar Fine Timestamp reduce el límite de concurrencia de 16 a 8. El verdadero valor del SX1303 es la precisión de geolocalización, no el rendimiento.
Concepto erróneo 2: "Dispositivos conectados" significa "Dispositivos soportados"
Muchos proveedores anuncian "este NS tiene conectados XX0,000 dispositivos" — eso es solo el recuento de registros, no capacidad simultánea en línea. La capacidad real es la carga concurrente ponderada por SF.
Concepto erróneo 3: para escalar, basta con comprar más gateways
Incorrecto. La mayoría de las redes LoRaWAN pueden escalar 3–5× haciendo solo tres cosas: habilitar ADR, recortar las cargas útiles y escalonar las uniones. Comprar más gateways es el último paso, no el primero.
Concepto erróneo 4: cuantos más dispositivos, más necesitas Clase C
Incorrecto. La Clase C mantiene los receptores siempre encendidos; su consumo de corriente es más de 1,000× el del estado de reposo de la Clase A. La Clase A es el caballo de batalla para despliegues a gran escala — el ancho de banda de enlace descendente es naturalmente estrecho, y la "ventana RX solo después del enlace ascendente" de la Clase A encaja realmente con esta restricción.
Concepto erróneo 5: todo dispositivo debería usar enlaces ascendentes Confirmados
Incorrecto. Temperatura, humedad, voltaje de batería, latidos periódicos — estos elementos de datos reenviables usan No confirmado. Las alarmas y los comandos de control usan Confirmado. El ancho de banda de enlace descendente es un recurso escaso — no lo desperdicies en datos que no necesitan garantías de entrega.
La próxima vez que estimes la capacidad de un despliegue LoRaWAN, recorre esta lista:
Volviendo a la celda de la hoja de cálculo del principio: ¿cuántos dispositivos puede manejar un gateway SX1302?
Si se requiere un solo número: un rango típico es 1,000 a 10,000 dispositivos por gateway. Pero el número en sí carece de sentido — depende de la distribución de SF, el tamaño de la carga útil, la frecuencia de enlace ascendente, la relación enlace ascendente/enlace descendente, la estrategia de unión y la calidad de la cobertura.
La capacidad es un resultado diseñado, no un parámetro comprado. El hardware que compras es solo el punto de partida de la curva de capacidad; la distribución de SF, la gobernanza de las cargas útiles y la planificación de la cobertura — estas decisiones de la capa de software deciden si el mismo hardware puede soportar 700 o 20,000 dispositivos.
Para despliegues LoRaWAN a gran escala, el único orden de escalado fiable es:
ADR → recorte de carga útil → escalonado de uniones → computación en el borde → optimización de cobertura → añadir un gateway
Recorre estos seis pasos, y la mayoría de los proyectos no necesitan un segundo gateway.
Autor: Equipo técnico de ManThink Revisores: EdgeBus / GW Tool Group Versión del documento: v1.0 · 2026-09-09 Licencia: CC BY-SA 4.0 (conserva el autor y el enlace al republicar)