Arquitectura Smart City: Buenas Prácticas con MQTT, ChirpStack, LoRaWAN, Kubernetes y Terraform

La versión corta: una plataforma smart city no es una sola plataforma. Es una cadena de decisiones aburridas que debe sobrevivir a clima, cobertura irregular, licitaciones, privacidad, salida de proveedores y una flota de dispositivos que nadie quiere tocar dos veces. La arquitectura resistente es por capas: dispositivos en el borde, LoRaWAN o celular para conectividad, MQTT para telemetría, registro de dispositivos y canal de comandos, modelo canónico de datos para interoperabilidad, almacenamiento de series temporales, flujo de eventos, APIs y una base de infraestructura como código. Kubernetes y Terraform ayudan cuando el equipo tiene madurez DevOps. Perjudican cuando se vuelven el proyecto.

La decisión que viene antes del stack

Muchas conversaciones smart city empiezan demasiado abajo: MQTT, Kafka, LoRaWAN, Kubernetes, FIWARE, AWS IoT Core, Azure IoT Hub, ThingsBoard o backend propio. Son decisiones reales, pero no son la primera. Primero hay que definir el modelo operativo. Así empezamos también los proyectos IoT: no con la herramienta favorita, sino con quién lo operará.

Una plataforma municipal tiene varios dueños: la administración que paga, el equipo que responde incidentes, los proveedores que mantienen dispositivos, la ciudadanía cuyos datos pueden verse afectados y los equipos futuros que reutilizarán la información. Si diseñas solo para el piloto, acabarás con arqueología de integraciones. Si diseñas solo para el gran espacio de datos, quizá el primer piloto nunca llegue a producción.

La pregunta práctica es: ¿estás construyendo un sistema operativo para un caso aislado, una plataforma de datos municipal multiárea o un espacio de datos federado? Para el primero bastan MQTT y un backend limpio. Para el segundo necesitas identidad, metadatos, gobierno, APIs estándar, almacenamiento duradero y límites entre aplicaciones. Para el tercero necesitas interoperabilidad semántica y contratos explícitos de intercambio.

Arquitectura de referencia para producción

1. Capa de dispositivo y campo. Sensores, gateways, controladores, cámaras solo si se justifican, PLCs para activos industriales e identidad de dispositivo. El dispositivo debe reconectar, hacer buffer, rotar credenciales, reportar firmware y fallar de forma controlada.
2. Conectividad. LoRaWAN para mensajes pequeños, poco frecuentes y con batería; NB-IoT o LTE-M cuando aceptas cobertura de operador y gestión SIM; Ethernet o redes industriales cuando la fiabilidad pesa más que la batería.
3. Ingesta. Broker MQTT o broker IoT gestionado para telemetría, comandos, eventos de ciclo de vida y topics puente. Aquí aplicas TLS, certificados, autorización por topic, cuotas y límites de payload.
4. Network server LoRaWAN. ChirpStack, The Things Stack o un servicio gestionado manejan join, deduplicación, ADR, downlinks, contadores de trama y routing. No metas lógica MAC de LoRaWAN en el backend de aplicación.
5. Normalización. Decodifica payloads, añade metadatos, valida unidades, rechaza valores imposibles, agrega versión de esquema y escribe de forma idempotente.
6. Modelo de contexto. NGSI-LD/FIWARE u OGC SensorThings cuando varios departamentos o proveedores deben entender la misma entidad. En sistemas aislados puede bastar un modelo interno, pero unidades, ubicación, propiedad, retención y calidad deben quedar documentadas.
7. Almacenamiento. Base de series temporales para observaciones, object storage para payloads crudos, base relacional para registro y configuración, índice geoespacial para mapas y logs inmutables para auditoría.
8. Eventos e integración. Eventos validados hacia analítica, alertas, dashboards, sistemas de órdenes de trabajo, open data e IA. MQTT suele ser el protocolo de borde; Kafka, NATS, Redpanda, Pulsar o colas cloud suelen encajar mejor tras la validación.
9. Aplicaciones. Dashboards, consolas de operación, servicios ciudadanos, anomalías, mantenimiento y APIs. Deben ser reemplazables.
10. Operación. Terraform para infraestructura, Kubernetes o servicios gestionados para workloads, GitOps, métricas, trazas, logs, backups, pruebas de restore, SBOMs, vulnerabilidades y runbooks.

MQTT: excelente para telemetría, insuficiente como arquitectura completa

MQTT.org define MQTT como un estándar OASIS para conectividad IoT: publish/subscribe, ligero y diseñado para dispositivos limitados y redes poco fiables. Por eso encaja en smart cities. Un dispositivo publica en un topic; las aplicaciones se suscriben sin que el dispositivo las conozca. El broker desacopla.

• El diseño de topics es diseño de API. city/{tenant}/{site}/{device}/telemetry se convertirá en contrato.
• QoS se elige, no se hereda. QoS 0 sirve para telemetría frecuente. QoS 1 conviene para alarmas y cambios de estado si el backend es idempotente.
• Retained messages no son histórico. Sirven para el último estado conocido, no para series temporales.
• El broker no es la fuente de verdad. La verdad vive en registry, modelo de contexto y almacenamiento.
• Diseña para desorden. Usa timestamp de dispositivo, timestamp de recepción, secuencias, contadores y validación monotónica cuando sea posible.

LoRaWAN y ChirpStack: su lugar correcto

LoRaWAN atrae en ciudades porque su física encaja: largo alcance, bajo consumo, poco ancho de banda, bajo coste por dispositivo y red privada si despliegas gateways propios. La especificación LoRaWAN describe una topología star-of-stars donde los gateways retransmiten mensajes a un Network Server central, que enruta a Application Servers.

ChirpStack es el Network Server LoRaWAN open source que evaluaríamos primero si la ciudad quiere una red privada y puede operarla. Incluye gestión de gateways, dispositivos, tenants e integraciones, además de API gRPC. Su configuración muestra la realidad operativa: PostgreSQL, Redis, integración MQTT, regiones, clases de dispositivo, deduplicación, downlink timing y endpoints de monitorización.

Usa ChirpStack cuando necesitas control. Usa LoRaWAN gestionado si no hay equipo para operar red de radio. Usa NB-IoT o LTE-M cuando cobertura de operador, movilidad o mayor throughput pesan más. La economía de radio está desglosada en nuestra guía LoRaWAN vs NB-IoT vs Sigfox.

FIWARE, NGSI-LD y SensorThings

Las plataformas smart city fallan lentamente cuando cada proveedor trae su propio modelo de datos. Un aparcamiento es device para uno, asset para otro, occupied: true para un tercero y status: 1 para otro. El dashboard lo oculta el primer año. El tercer año, cuando llega open data, analítica transversal o una nueva licitación, duele.

El catálogo FIWARE gira alrededor de context data management y una API NGSI común. FIWARE posiciona NGSI-LD como interoperabilidad JSON-LD para federaciones y espacios de datos. Sus tutoriales son pragmáticos: NGSI-v2 para sistemas aislados más simples; NGSI-LD para data spaces y systems of systems.

OGC SensorThings encaja cuando el dominio central son observaciones: things, sensors, datastreams, observed properties, features of interest y observations. La API OGC SensorThings también define una extensión MQTT. Si el municipio vive en GIS y datos de sensores, SensorThings puede ser el API más limpio. Si modelas contexto amplio entre activos, organizaciones y relaciones, NGSI-LD/FIWARE suele encajar mejor.

Terraform y Kubernetes

Terraform permite definir y versionar infraestructura. En smart city es valioso porque los entornos duran años y deben auditarse. Úsalo para redes, DNS, bases de datos, buckets, IAM, clusters, colas y monitorización. Mantén el state remoto, bloqueado, cifrado y fuera de git; la documentación de HashiCorp advierte del riesgo de state local o almacenado sin locking y control de acceso.

Kubernetes es un control plane de workloads. Sirve cuando hay muchos servicios, entornos, autoscaling, GitOps y un equipo que entiende probes, límites, secrets, network policies y recovery. Para un piloto de 20 dispositivos puede ser teatro. Para una plataforma multiárea con decenas de servicios puede ser la base adecuada. Si falta esa experiencia, una revisión de fractional CTO antes de comprar suele ser más barata que reconstruir después.

Comparación de enfoques

Buenas prácticas que evitan rebuilds

• Separa telemetría, estado y comandos. Telemetría es flujo de eventos; estado es la última vista conocida; comando es intención con ack, timeout, autorización y auditoría.
• Todo write debe ser idempotente. LoRaWAN, MQTT QoS 1, retries y reglas cloud duplican eventos.
• Versiona payloads y codecs. El decoder es código de producción. Guarda firmware, versión de codec, perfil de dispositivo y unidades.
• Diseña para datos tardíos o ausentes. Las redes de campo no son redes de oficina.
• Identidad de dispositivo real. Claves LoRaWAN, certificados X.509, SIMs, API keys y usuarios son identidades distintas.
• Guarda raw payloads para replay. Cuando un decoder falla, replay salva meses de datos.
• Trata ubicación como sensible. Movilidad, ocupación y cámaras pueden volverse datos personales al combinarse.
• Define salida de proveedor antes de firmar. Export, APIs, credenciales, esquemas, infra code y firmware process deben estar en el contrato.

Seguridad, gobierno y roadmap

Una smart city no necesita paranoia; necesita disciplina. Usa least privilege, rotación de credenciales, logs de comandos, auditoría de downlinks, tenants separados, TLS, cifrado en reposo, monitorización de certificados y pruebas de restore. Usa el NIST Cybersecurity Framework como vocabulario compartido para gobernar, identificar, proteger, detectar, responder y recuperar. Las mismas grietas aparecen en technical due diligence: sin ownership, sin runbooks, sin contratos de datos.

El roadmap sano es simple: primero un piloto pequeño y creíble con un caso, una zona, una familia de dispositivos y una métrica, algo más cercano a un minimum credible product que a una demo. Después endurecimiento: lifecycle de dispositivos, firmware, monitorización, backups, replay, schema registry y APIs, hasta llegar a infraestructura production-ready. Solo entonces plataforma: data contracts, open data, work orders, analítica y casos de IA.

Fuentes y caveat de arquitectura

Las plataformas smart city viven años, pero los productos de proveedor y los servicios cloud cambian rápido. Trata los principios de arquitectura como estables y los detalles de herramientas como una foto de julio de 2026. Revisa antes de presupuesto o licitación MQTT.org, la página de especificación MQTT, la especificación LoRaWAN 1.1, ChirpStack, FIWARE, OGC SensorThings, Terraform, Terraform state, Kubernetes object management, AWS IoT protocols, AWS IoT rules y Azure IoT Hub device twins.

"La mejor arquitectura smart city es aburrida en cada capa y explícita en cada frontera. Los sensores pueden ser caóticos. Los contratos no."