Un municipio decide que quiere “sensorizar la ciudad” y la primera reunión termina en la pregunta equivocada: ¿cuántos gateways compramos? Comprar hardware es la parte fácil. Lo que de verdad separa una red municipal que sigue operando en cinco años de un proyecto piloto que se apaga cuando cambia la administración es el orden en que se toman las decisiones: primero qué se va a medir y quién lo va a usar, después cómo se conecta, y solo al final cuánto fierro hace falta. Esta guía ordena ese proceso en pasos concretos, con las cifras y advertencias que ya hemos ido documentando al hablar de casos de uso de smart cities con LoRaWAN y de estacionamiento, activos y ambiente en ciudades conectadas.
Paso 1: Mapear casos de uso y dueños, antes que gateways
Antes de mirar un catálogo de hardware, hay que responder quién va a usar cada dato y para qué decisión. Alumbrado público, recolección de residuos, presión de agua potable, ocupación de parqueaderos y calidad de aire suelen depender de secretarías o empresas municipales distintas —energía, aseo, agua potable, movilidad, ambiente—, cada una con su propio presupuesto y su propio criterio de éxito. Un error común es diseñar la red pensando solo en el primer caso de uso (por ejemplo alumbrado) y descubrir después que el segundo departamento (agua) necesita gateways en zonas completamente distintas, con lo que la “red única” termina siendo dos redes que compiten por presupuesto. La salida práctica es un inventario simple antes de cualquier compra: qué se mide, dónde, con qué frecuencia de reporte, y qué departamento paga y usa ese dato. Ese inventario es el que después determina cuántos nodos y en qué polígonos de la ciudad se necesita cobertura.
Paso 2: Red pública o privada, y qué network server usarla
Con los casos de uso claros, la siguiente decisión es de arquitectura: unirse a una red pública compartida (como The Things Network) o levantar una red privada propia con ChirpStack o The Things Stack. Para infraestructura de la que depende un servicio crítico —presión de agua, control remoto de alumbrado— una red privada tiene sentido casi siempre: el municipio controla la capacidad del canal, no comparte gateways con otros usuarios impredecibles, y evita la Fair Access Policy que limita el tiempo en aire por dispositivo en redes compartidas. La contrapartida es que el municipio pasa a ser responsable de operar el network server (actualizaciones, respaldo, disponibilidad) y no solo de los sensores. Una alternativa intermedia, frecuente en despliegues nuevos, es empezar con ChirpStack autoalojado para las secretarías que pagan la red y dejar que integradores o proyectos comunitarios (semáforos escolares, estaciones de un colegio) se conecten como aplicaciones adicionales sobre la misma infraestructura, sin duplicar gateways.
Paso 3: El plan de frecuencia que sí aplica en Ecuador
Un error de diseño frecuente —heredado de documentación pensada para Europa— es asumir un límite de duty cycle del 1% por hora. En Ecuador la red opera bajo el plan AU915 (915-928 MHz), regulado por ARCOTEL bajo un esquema tipo FCC donde no existe duty cycle regulatorio; la restricción real es el dwell time de 400 ms por transmisión, como ya explicamos en detalle en duty cycle y Time on Air en LoRaWAN. Para una red municipal con cientos o miles de nodos —contenedores, luminarias, medidores de agua—, esto importa doblemente: el diseño de intervalos de reporte y Spreading Factor debe calcularse sobre el límite real (dwell time y, si se usa una red compartida, la Fair Access Policy de 30 segundos de tiempo en aire diario por dispositivo), no sobre una regla que ni siquiera aplica en esta región.
Paso 4: Site survey urbano y ubicación de gateways
A diferencia de una finca o una piscina camaronera con línea de vista relativamente despejada, una ciudad atenúa la señal con concreto, estructuras metálicas y la propia curvatura de las calles entre edificios. El alcance típico de un gateway baja a 2-5 km en zonas de alta densidad de edificación, frente a los 10-15 km posibles en campo abierto. Esto obliga a un site survey previo, no a instalar y ver qué pasa: identificar 3-5 ubicaciones candidatas por polígono de cobertura (azoteas municipales, torres de telecomunicaciones, edificios altos con acceso administrativo garantizado), probar con un gateway móvil o portátil en cada una antes de fijar la instalación definitiva, y —para una ciudad mediana— asumir desde el diseño que se necesitarán varios gateways superpuestos en vez de uno solo, con la misma lógica de redundancia que ya documentamos para camaroneras grandes con varias zonas de cobertura. Un gateway con antena mal ubicada rinde muy por debajo de su capacidad nominal, un punto que desarrollamos en por qué la antena importa más que el gateway: en entorno urbano, la altura y la línea de vista sobre el propio bloque de edificios pesan más que las especificaciones del equipo.
Paso 5: Aprovisionar dispositivos a escala sin comprometer seguridad
Una red de cientos de sensores urbanos no se aprovisiona nodo por nodo a mano. La práctica recomendada es OTAA (Over-The-Air Activation) de fábrica en cada dispositivo, con una AppKey única por nodo —nunca compartida entre lotes—, tal como detallamos en OTAA vs. ABP y en cómo el cifrado AES-128 protege los datos LoRaWAN. Para una implementación municipal esto se traduce en un flujo operativo concreto: el proveedor entrega un listado de DevEUI/AppKey por lote de nodos, ese listado se carga al network server antes de la instalación física, y el instalador en campo solo necesita el DevEUI (visible en una etiqueta o QR) para confirmar que el nodo correcto quedó activado en el polígono correcto. Este flujo importa más en gobierno que en una finca privada: un sensor de nivel de agua o un actuador de alumbrado mal aprovisionado, o con una clave reutilizada, es un vector de auditoría y de posible manipulación de un servicio público.
Paso 6: Piloto acotado antes del rollout completo
La secuencia que mejor funciona en despliegues municipales reales no es “cubrir toda la ciudad de una vez”, sino un piloto de 60-90 días en un solo distrito o corredor: 1-2 gateways, 20-50 nodos del caso de uso prioritario, medición real de cobertura, de vida de batería en campo y de la carga operativa (¿quién revisa alarmas?, ¿quién reemplaza baterías?). El piloto es también el momento de ajustar supuestos de RF antes de comprometer presupuesto en gateways adicionales: un polígono que en el papel parecía tener buena línea de vista puede rendir peor de lo esperado por un obstáculo no identificado en el survey inicial. Recién con esos datos de campo tiene sentido dimensionar el rollout a los demás distritos, en vez de replicar un diseño teórico sin validar.
Paso 7: Gobernanza entre departamentos y un solo tablero
El mayor riesgo operativo de una red municipal no es técnico sino organizacional: sin un dueño claro de la infraestructura compartida (gateways, network server), cada secretaría termina pidiendo su propio despliegue paralelo, duplicando gateways en el mismo edificio. La solución que funciona en la práctica es designar una unidad técnica (a menudo la de tecnología o movilidad) como operadora de la capa de red, mientras cada secretaría es dueña de sus propios dispositivos y de su capa de aplicación sobre el mismo servidor. En Yubox Cloud esto se organiza como capas por servicio y por zona geográfica dentro de un mismo tablero, el mismo principio que ya aplicamos al integrar variables de aireadores, oxígeno y combustible en un solo dashboard para operaciones acuícolas: cada departamento ve su alarma y su escala, pero la infraestructura de red se administra una sola vez.
Paso 8: Mantenimiento y crecimiento, no solo instalación
Una red municipal que empieza con 50 nodos y crece a 2.000 en tres años necesita, desde el diseño inicial, un inventario de activos (qué gateway y qué nodo está en qué ubicación, con qué batería y desde cuándo), rutas de mantenimiento por zona en vez de visitas reactivas, y monitoreo del propio estado de los gateways —no solo de los sensores que dependen de ellos—. Ecuador ya tiene un ejemplo de esta escala: Cuenca se declara la primera ciudad inteligente y sostenible del país, con una red LoRaWAN propia que alimenta tableros de calidad de aire, tráfico y ruido, además de medidores inteligentes de agua conectados a la misma infraestructura. Ese tipo de despliegue no se sostiene sin un plan de mantenimiento tan cuidado como el plan de instalación inicial.
Conclusión
Construir una red LoRaWAN municipal es, en el fondo, un proyecto de gobernanza con una capa de radiofrecuencia debajo: el orden correcto es casos de uso y dueños primero, arquitectura de red después, site survey antes de comprar gateways, aprovisionamiento seguro desde el primer lote de nodos, y un piloto acotado antes de comprometer presupuesto en toda la ciudad. Los municipios que se saltan estos pasos terminan con gateways duplicados, cobertura mal calculada o una red que nadie mantiene después del primer año.
¿Su municipio está evaluando una red LoRaWAN propia? Conversemos sobre el diseño de su proyecto.