Los arquitectos de IoT empresarial dedican mucho tiempo a evaluar el hardware y la tecnología de conectividad, y menos tiempo a definir la pila de protocolos que rige la forma en que los dispositivos, las redes y las plataformas se comunican entre sí. Ese desequilibrio suele manifestarse en forma de problemas de integración tras la implementación: dispositivos que no pueden autenticarse en la plataforma, datos que llegan en formatos que el servidor central no puede procesar, actualizaciones de firmware que fallan porque el protocolo de transporte OTA no se ha validado en función de la memoria disponible del dispositivo, y vulnerabilidades de seguridad que surgen de la incompatibilidad entre los protocolos de las distintas capas.
La pila de protocolos del IoT es un conjunto de estándares organizados en capas, cada uno de los cuales rige un aspecto diferente del modo en que los datos se transmiten desde un sensor físico hasta una aplicación. Las decisiones que se toman en cada capa limitan y determinan las opciones en las capas adyacentes, y las interacciones entre esas decisiones determinan si la pila completa funciona como un sistema coherente o como un conjunto de componentes validados individualmente que generan fricciones en las interfaces.
Este artículo analiza la pila de protocolos del IoT, desde la capa de conectividad física hasta la capa de aplicación, y aborda los estándares relevantes para las implementaciones empresariales, las ventajas e inconvenientes de cada capa y las consideraciones de integración que determinan si la pila se mantiene cohesionada a gran escala.
Capa física y de acceso: Estándares de telefonía móvil
La capa física y de acceso regula la forma en que un dispositivo establece una conexión de radio con una red. En el caso del IoT empresarial, conviene determinar cuáles son los estándares de telefonía móvil pertinentes y cómo se relacionan entre sí, ya que el lenguaje comercial que rodea a estas tecnologías puede ser impreciso, lo que puede influir en las decisiones de implantación.
NB-IoT (IoT de banda estrecha, 3GPP Release 13 y posteriores) funciona en un canal de 180 kHz dentro del espectro con licencia, ya sea en banda dentro de una portadora de « LTE », en la banda de protección « LTE » o en un despliegue autónomo en el espectro « GSM » reasignado. Características clave de la capa física:
- Ancho de banda máximo de bajada: aproximadamente 250 kbps en modo de tono único
- Ancho de banda máximo de subida: aproximadamente 250 kbps
- Presupuesto de enlace: pérdida de acoplamiento máxima de 164 dBm, lo que supone una mejora de aproximadamente 20 dB con respecto a GPRS
- Latencia: de 1,6 a 10 segundos para una transmisión de datos típica, incluida la configuración, lo que la hace inadecuada para aplicaciones que requieren una respuesta inferior a un segundo.
- Modo dúplex: solo semidúplex
LTE-M (LTE-MTC, Cat-M1, 3GPP Release 13) funciona en un canal de 1,4 MHz dentro del espectro de LTE con soporte full-duplex. Características clave de la capa física:
- Ancho de banda máximo de descarga: aproximadamente 1 Mbps
- Ancho de banda máximo de subida: aproximadamente 1 Mbps
- Presupuesto de enlace: pérdida de acoplamiento máxima de 155,7 dBm, lo que supone una mejora de aproximadamente 15 dB con respecto a GPRS
- Latencia: de 10 a 15 ms para la transmisión de datos tras el establecimiento de la conexión
- Modo dúplex: compatible con dúplex completo, lo que permite la transmisión de voz y datos bidireccionales en tiempo real
5G NR para el IoT introduce dos categorías de dispositivos relevantes: RedCap (capacidad reducida, 3GPP Release 17), dirigido a dispositivos de IoT de gama media que requieren un mayor rendimiento que el de « LTE-M», pero un menor consumo energético que el de un NR UE « 5G » completo, y el NR estándar « 5G » para aplicaciones de IoT de gran ancho de banda. RedCap tiene como objetivo un rendimiento de entre 5 y 25 Mbps con reducciones de consumo energético y complejidad en comparación con el NR « 5G » completo, cubriendo así el hueco entre LTE-M y el NR « 5G » completo que, históricamente, han ocupado los dispositivos 4G Cat-4.
La elección de la capa física establece los límites máximo y mínimo para todas las capas superiores. Una pila de protocolos diseñada para una comunicación bidireccional en menos de un segundo y basada en NB-IoT fallará en la capa física antes de que el protocolo de aplicación tenga oportunidad de funcionar.
Capa de red: direccionamiento IP y enrutamiento para el IoT
La mayoría de los dispositivos IoT empresariales se comunican a través de IPv4 o IPv6, pero la configuración de la capa de red que rige la forma en que se asignan y gestionan esas direcciones conlleva implicaciones operativas que las especificaciones de la capa física no ponen de manifiesto.
Arquitectura de red privada APN es la configuración estándar de la capa de red para implementaciones de IoT empresariales con requisitos de seguridad de datos o normativos. En lugar de enrutar el tráfico de los dispositivos a través de la red pública compartida APN del operador hacia la Internet pública, una red privada APN crea una ruta de red dedicada desde el dispositivo hasta la infraestructura de backend de la empresa. El tráfico de una red privada APN no atraviesa la Internet pública, lo cual es importante para:
- Cumplimiento normativo en sectores en los que los datos no deben salir del perímetro de la red de la empresa
- Superficie de ataque reducida, ya que no se puede acceder directamente a los dispositivos desde la Internet pública
- Enrutamiento determinista, ya que el tráfico privado de APN sigue rutas de red definidas en lugar del enrutamiento de la Internet pública
IPv6 para el IoT es relevante, ya que el agotamiento de las direcciones IPv4 dificulta que las implementaciones de IoT a gran escala puedan gestionarse de forma individual. Una implementación de un millón de contadores inteligentes, cada uno de los cuales requiere una dirección IP enrutable para la comunicación iniciada desde la cabecera, se enfrenta a limitaciones prácticas en la asignación de direcciones IPv4 que IPv6 elimina. IPv6 también simplifica la direccionabilidad de extremo a extremo en arquitecturas en las que es necesario poder acceder a cada dispositivo de forma individual sin necesidad de atravesar NAT.
Consideraciones sobre CGNAT afectan a las implementaciones en las que el NAT de nivel de operador se sitúa entre el dispositivo y el backend de la empresa, que es la configuración predeterminada para la mayoría de los planes de tarifas de IoT estándar y para consumidores. El CGNAT impide las conexiones entrantes a los dispositivos, lo que significa que cualquier arquitectura que requiera una comunicación iniciada desde el head-end hacia dispositivos individuales necesita o bien un « APN » privado, una conexión iniciada por el dispositivo que esté siempre activa, o un dispositivo que mantenga una sesión persistente con la plataforma backend. Los arquitectos que no tienen en cuenta el CGNAT durante el diseño lo descubren durante las pruebas de integración, momento en el que las opciones de corrección resultan más costosas.
Capa de transporte: selección de protocolos para la transmisión de datos del IoT
La capa de transporte regula cómo se empaquetan y se transmiten los datos de forma fiable (o, intencionadamente, de forma no fiable) entre el dispositivo y la plataforma. Los protocolos de transporte predominantes en el IoT empresarial presentan diferentes compensaciones que se adaptan a distintos perfiles de aplicación.
MQTT (Message Queuing Telemetry Transport) es el protocolo de transporte de IoT más utilizado para dispositivos conectados a redes móviles. Su arquitectura de publicación-suscripción, su baja sobrecarga (encabezado fijo mínimo de 2 bytes) y su compatibilidad con tres niveles de calidad de servicio (QoS) lo hacen ideal para dispositivos con recursos limitados que transmiten con frecuencia pequeñas cargas útiles a través de conexiones potencialmente poco fiables:
- QoS 0 (como máximo una vez): «disparar y olvidar», sin acuse de recibo, mínima sobrecarga
- QoS 1 (al menos una vez): entrega garantizada con acuse de recibo, posibles duplicados
- QoS 2 (una sola vez): entrega única garantizada, mayor sobrecarga
La capacidad de sesión persistente de MQTT permite a los dispositivos volver a conectarse tras una interrupción de la conexión y recibir los mensajes que el broker ha puesto en cola durante el periodo en el que estuvieron desconectados, lo cual es importante para los dispositivos « NB-IoT » en el modo PSM que quedan periódicamente inaccesibles.
CoAP (Constrained Application Protocol) está diseñado para los dispositivos con mayores limitaciones de recursos, en los que el requisito de TCP de MQTT genera una sobrecarga inaceptable. CoAP se ejecuta sobre UDP, utiliza un modelo de solicitud-respuesta similar al de HTTP, pero con un encabezado binario optimizado para entornos con recursos limitados, y admite la funcionalidad de «observación» para un comportamiento similar al de la publicación-suscripción. Es la opción de transporte adecuada para dispositivos NB-IoT , en los que la sobrecarga derivada de la gestión de conexiones TCP afectaría significativamente al consumo energético.
AMQP (Protocolo Avanzado de Colas de Mensajes) es relevante en la capa de integración de backend, más que en la capa de comunicación entre dispositivos y la nube. Su mayor capacidad de enrutamiento de mensajes, su compatibilidad con transacciones y su compatibilidad con los intermediarios de mensajes empresariales lo convierten en el protocolo de transporte estándar para conectar plataformas de IoT con los sistemas de backend empresariales: ERP, gestión de activos y plataformas de tecnología operativa que requieren intermediarios de mensajes compatibles con AMQP.
HTTPS/REST sigue siendo relevante para los dispositivos IoT que cuentan con recursos informáticos suficientes y en los que la simplicidad de la integración REST API compensa la sobrecarga que supone el uso de HTTP. Las pasarelas IoT de gama alta, los nodos de computación periféricos y los dispositivos con conectividad 4G o 5G suelen utilizar REST para la integración en la plataforma, especialmente en implementaciones en las que el equipo de operaciones que gestiona la integración del backend está más familiarizado con los patrones web API que con la configuración de los brokers MQTT.
Capa de seguridad: Normas de autenticación y Encryption
La elección de protocolos de seguridad en el IoT se ve complicada por las limitaciones de potencia de cálculo y memoria de los dispositivos periféricos, lo que hace que los protocolos de seguridad habituales en los entornos informáticos empresariales resulten poco prácticos o imposibles de implementar en hardware con recursos limitados.
TLS 1.2 y TLS 1.3 son los protocolos de cifrado estándar para dispositivos IoT con recursos informáticos suficientes. TLS 1.3 reduce la latencia del protocolo de enlace en comparación con TLS 1.2 al eliminar una ida y vuelta de la secuencia de enlace, lo cual es importante para los dispositivos NB-IoT y LTE-M, en los que cada transmisión por radio conlleva un coste energético cuantificable. La selección del conjunto de cifrado dentro de TLS es importante para el IoT: el intercambio de claves ECDHE y AES-128-GCM son la combinación recomendada para implementaciones de IoT que buscan un equilibrio entre la solidez de la seguridad y la eficiencia computacional.
DTLS (Datagram TLS) es el protocolo de seguridad adecuado para las implementaciones de CoAP, ya que ofrece garantías de seguridad equivalentes a las de TLS para el transporte basado en el protocolo de control de acceso a la red ( UDP).
La autenticación mutua basada en certificados X.509 es el mecanismo de autenticación de dispositivos recomendado para implementaciones empresariales de IoT a gran escala. Las claves precompartidas son más sencillas de implementar, pero plantean problemas de gestión de claves cuando hay un gran número de dispositivos: la rotación de una clave precompartida comprometida en millones de dispositivos desplegados supone una carga operativa considerable. Los certificados X.509 con identidades individuales para cada dispositivo permiten la rotación y revocación de certificados por dispositivo sin afectar al resto de dispositivos del parque.
Los módulos de seguridad de hardware (HSM) y los entornos de ejecución de confianza (TEE) cobran cada vez más importancia para los dispositivos IoT empresariales que gestionan datos confidenciales o que operan en entornos en los que existe el riesgo de que personas no autorizadas accedan físicamente a los dispositivos. Almacenar las claves privadas en un elemento protegido por hardware, en lugar de en la memoria del firmware, impide la extracción de las claves incluso si el firmware del dispositivo se ve comprometido.
La pila de protocolos de seguridad debe validarse de extremo a extremo antes de su implementación. Un dispositivo que implemente TLS correctamente, pero que se conecte a un punto final de la plataforma que no exija la autenticación mutua, solo cuenta con la mitad de una arquitectura de seguridad. La validación de la seguridad en el IoT debe abarcar toda la ruta del protocolo de establecimiento de conexión desde el dispositivo hasta la plataforma, incluyendo la capa de red ( APN privado), la capa de transporte (configuración de TLS) y la capa de aplicación (gestión de tokens de autenticación y gestión de sesiones).
Formatos de datos y protocolos de « Device Management »
La capa de aplicación es donde las decisiones relativas a los protocolos tienen un impacto más directo en la complejidad de la integración de la plataforma.
LwM2M (Lightweight M2M, OMA SpecWorks) es el protocolo de gestión de dispositivos diseñado para el IoT, que abarca el registro de dispositivos, la entrega de actualizaciones de firmware por OTA, la configuración remota y la generación de informes de telemetría en un único marco de protocolo. Su modelo de datos utiliza una jerarquía estandarizada de objetos y recursos que permite a las plataformas de gestión de dispositivos interactuar con cualquier dispositivo compatible con LwM2M sin necesidad de realizar trabajos de integración específicos para cada dispositivo. En el caso de implementaciones empresariales que gestionan grandes poblaciones de dispositivos heterogéneos, el modelo de gestión estandarizado de LwM2M reduce significativamente la carga de integración que supone añadir nuevos tipos de dispositivos a la flota.
Consideraciones sobre el protocolo FOTA (Firmware Over The Air) en la capa de aplicación suelen quedar insuficientemente especificadas durante el diseño de la implementación. Los paquetes de actualización de firmware para dispositivos IoT pueden oscilar entre decenas de kilobytes y varios megabytes. El protocolo FOTA debe tener en cuenta:
- Recuperación de una transferencia interrumpida, ya que un dispositivo NB-IoT o LTE-M puede perder la conexión en mitad de la descarga del firmware.
- Compatibilidad con actualizaciones delta, en las que solo se transmiten los segmentos de firmware modificados, en lugar de la imagen completa, lo que reduce el tamaño de la transmisión y el consumo energético.
- Posibilidad de revertir la actualización si el nuevo firmware no supera la validación en el dispositivo
Formato de serialización de datos Las opciones en la capa de aplicación afectan a la eficiencia de la transmisión y a la complejidad de la integración en la plataforma. JSON goza de una amplia compatibilidad y es legible para los usuarios, pero conlleva una sobrecarga significativa en comparación con los formatos binarios para dispositivos con recursos limitados. CBOR (Concise Binary Object Representation) ofrece una expresividad equivalente a la de JSON en una codificación binaria que suele reducir el tamaño de la carga útil entre un 50 y un 70 por ciento. En el caso de los dispositivos « NB-IoT » que transmiten con alta frecuencia o con un presupuesto energético limitado, la reducción de la carga útil que ofrece CBOR frente a JSON se traduce directamente en una mayor duración de la batería y menores costes de datos.
Coherencia de la pila de protocolos a escala empresarial
Las decisiones relativas a la pila de protocolos descritas anteriormente no funcionan de forma independiente. Una implementación que seleccione « NB-IoT » en la capa física, MQTT sobre TCP en la capa de transporte y TLS 1.2 con handshake completo en la capa de seguridad ha creado una pila en la que la sobrecarga de las capas de transporte y seguridad puede llegar a dominar el presupuesto energético del dispositivo, lo que socava la razón de ser de la eficiencia energética por la que se eligió « NB-IoT » en primer lugar. CoAP sobre UDP con DTLS sería la pila coherente para un dispositivo NB-IoT con limitaciones de consumo energético, mientras que MQTT sobre TCP con TLS es la pila adecuada para un dispositivo LTE-M con un presupuesto energético más generoso.
La coherencia de la pila de protocolos también es importante para la infraestructura de conectividad. Una implementación en la que los dispositivos se conectan a través de una red privada APN con direcciones IP estáticas, se comunican mediante MQTT con un broker en la nube y utilizan autenticación mutua X.509 plantea requisitos específicos para la plataforma de gestión de la conectividad: aprovisionamiento de la red privada APN , asignación de direcciones IP estáticas y gestión del ciclo de vida de los certificados que se integre con la infraestructura de identidad de los dispositivos.
La infraestructura de conectividad de KORE proporciona la base de la capa de red de la que dependen las pilas de protocolos empresariales, incluyendo la configuración privada de « APN », el aprovisionamiento de direcciones IP estáticas y la conectividad con múltiples operadores a través de más de 40 acuerdos de colaboración con operadores y más de 200 países. La plataforma « ConnectivityPro » ofrece la gestión del ciclo de vida de las tarjetas SIM y los controles de políticas de red que rigen la capa de conectividad subyacente a cualquier pila de protocolos de aplicación que se ejecute en la implementación. Con más de 21 millones de tarjetas SIM activas desplegadas en sectores verticales en los que la coherencia de la pila de protocolos afecta directamente a los resultados operativos, la infraestructura está diseñada para dar soporte a toda la gama de configuraciones de conectividad IoT empresarial que requieren las implementaciones en producción.
Para diseñar correctamente la pila de protocolos es necesario evaluar cada capa en el contexto de las capas adyacentes y validar la pila completa de extremo a extremo antes de que la implementación se lleve a cabo en hardware a gran escala. Los problemas de integración que surgen de los desajustes entre protocolos tienen solución, pero resulta más económico resolverlos en un entorno de pruebas que en condiciones reales.
Habla con un ingeniero de conectividad de KORE sobre los requisitos de infraestructura de la capa de red para tu pila de protocolos de IoT.
Publicado el 29 de mayo de 2026.