Construyendo un dispositivo IoT de baja potencia y alcance de red – CodesCode

Equilibrar las limitaciones del dispositivo y las limitaciones de infraestructura plantea desafíos, pero hay esperanza y oportunidad para soluciones innovadoras.

Construir un dispositivo de IoT con batería es un desafío muy interesante. Los avances tecnológicos han permitido que los chips de módulos IoT realicen más funciones que nunca antes. Hoy en día, existen conjuntos de chips que son más pequeños que un centavo, pero están equipados con GPS, Wi-Fi, conectividad celular y capacidades de procesamiento de aplicaciones. Con estos desarrollos, es un momento propicio para la creación de dispositivos IoT de factor de forma pequeño que puedan conectarse a la nube y resolver problemas interesantes en todos los ámbitos.

Hay muchas aplicaciones en las que el dispositivo IoT necesita ser accedido externamente por una aplicación para solicitar una tarea específica que se ejecute. Piensa en un dispositivo de cerradura inteligente para el hogar que necesita abrir y cerrar la cerradura de la puerta desde una aplicación móvil. O un dispositivo de seguimiento de activos que debe comenzar a registrar su ubicación cuando se le solicite. La idea básica es poder emitir un comando a estos dispositivos y hacer que realicen una acción.

Enunciado del problema

A primera vista, puede parecer bastante sencillo lograr esto. Conectar el dispositivo IoT a la red, emparejarlo con un servidor y hacer que espere comandos. ¿Cuál es el problema, se podría preguntar? Hay algunos obstáculos para que funcione en una configuración de baja potencia alimentada por batería.

La radio celular es costosa en términos de batería. Mantener el dispositivo constantemente conectado a la red agotará la batería rápidamente. Mantener una conexión de red constante puede consumir una cantidad significativa de energía y reducir la vida útil de la batería a un nivel inaceptable para la mayoría de las aplicaciones alimentadas por batería, donde se espera que la vida útil de la batería sea de meses a años. Un dispositivo así debe estar diseñado para conservar la energía tanto como sea posible para prolongar su vida útil operativa.

Aplicando el pensamiento de primeros principios al problema del alto consumo de energía causado por las conexiones celulares, podemos plantear una pregunta crítica: ¿Es necesario que el dispositivo permanezca conectado a la red todo el tiempo? En la mayoría de los casos, es posible que el dispositivo no necesite transferir o recibir datos y puede que no tenga sentido mantenerlo conectado a la red. ¿Y si pudiéramos hacer que permanezca en modo de “reposo” y que se despierte periódicamente para verificar si hay comandos entrantes? Esto significaría que el dispositivo solo se conectaría a la red cuando sea necesario, ahorrando así energía. Esta es la idea fundamental detrás de los modos de ahorro de energía LTE-M. LTE-M ofrece dos modos: PSM y eDRX. Veámoslos en detalle.

Modo PSM

En el modo PSM, un dispositivo IoT puede solicitar entrar en un estado inactivo (RRC Idle) durante un período de hasta 413 días. Este modo es particularmente útil para dispositivos que necesitan transmitir datos periódicamente a través de la red y luego volver a dormir. Es importante tener en cuenta que el dispositivo es completamente inaccesible mientras está en estado inactivo.

Este es el perfil de consumo de energía de un dispositivo en modo PSM.

[Fig 1: Perfil de consumo de energía de PSM]

El dispositivo permanece en estado inactivo durante un período prolongado hasta que se despierta para transferir datos. Además, hay una breve ventana de notificación durante la cual el dispositivo es alcanzable, después de lo cual vuelve al modo de sueño. Solicitar tiempos de sueño más largos puede resultar en un mayor ahorro de energía, pero también puede requerir sacrificar la frecuencia de transferencia de datos. En última instancia, depende del desarrollador determinar el equilibrio ideal entre el tiempo de sueño y la resolución de datos requerida, según los requisitos de la aplicación. Es posible que un medidor de energía inteligente esté perfectamente bien enviando actualizaciones una vez al día, pero un rastreador GPS que necesita enviar actualizaciones más frecuentes requeriría tiempos de sueño más cortos.

Modo eDRX

El término eDRX significa “Recepción discontinua extendida”. El concepto es similar al modo PSM, donde el dispositivo se coloca en estado RRC Idle, pero a diferencia del modo PSM, en el eDRX, el dispositivo se despierta periódicamente para “registrarse” en la red cada período de ciclo de eDRX.

El tiempo máximo de sueño para los dispositivos eDRX varía de hasta 43 minutos para dispositivos que utilizan LTE-M.

[Fig 2: Perfil de consumo de energía de eDRX]

Comparado con eDRX, un dispositivo PSM requiere mucho más tiempo para despertar del modo de sueño y permanecer activo, ya que debe establecer una conexión con la red antes de poder recibir datos de aplicaciones. Cuando se usa eDRX, el dispositivo solo necesita despertar y escuchar durante 1 ms, mientras que con PSM, el dispositivo debe despertar, recibir y transmitir mensajes de control durante aproximadamente 100-200 ms antes de poder recibir un mensaje de la aplicación en la nube, lo que resulta en una diferencia de 100 veces. [1]

Aunque estos modos de encendido parecen prometedores para dispositivos IOT de baja potencia de red, construir un dispositivo alcanzable, es decir, un dispositivo que pueda enviar un paquete de mensaje externamente a través de la red, sigue siendo un desafío. Entraremos en detalles sobre los desafíos que se encuentran con los protocolos de comunicación TCP, SMS y UDP.

Consideraciones del Protocolo de Comunicación

Existen una variedad de protocolos de comunicación IOT disponibles para diferentes tipos de aplicaciones IOT, pero con el propósito de este artículo, los categorizaremos en dos tipos.

Basados en Conexión: MQTT basado en TCP, Websockets, HTTP
Sin Conexión: MQTT-SN basado en UDP, CoAP, LWM2M y SMS.

Protocolos Basados en Conexión

Estos protocolos de comunicación requieren una conexión activa a través de la red para que los datos se transfieran. La conexión se establece mediante un tres pasos de saludo, y se ve algo así:

[Fig 3: Ilustración de tres pasos de saludo]

Observa que antes de que se pueda transferir cualquier dato real (mostrado en verde), hay tres paquetes de red que necesitan ser enviados de ida y vuelta. Esta carga adicional puede parecer poca cosa para un sistema donde el consumo de datos o la duración de la batería no son un problema, pero en nuestro caso, esto costaría una gran cantidad de recursos preciosos de la batería, a veces consumiendo más datos que la carga útil real solo para iniciar una conexión.

En segundo lugar, obsérvalo en la figura, el cliente es el que inicia la conexión; esto es intencional y una gran limitación de los protocolos basados en conexión (TCP, MQTT, etc.) en la aplicación de un dispositivo alcanzable de red, que requiere que el dispositivo responda a la solicitud del servidor.

Uno podría hacer que el cliente inicie una primera conexión y mantenga abierta la conexión, pero para mantenerla viva, se deben enviar paquetes keep-alive a intervalos predefinidos, lo que nuevamente tiene un costo tremendo en la batería, haciendo que este tipo de protocolos sean inutilizables e imprácticos para un dispositivo alcanzable de baja potencia de red.

[Fig 4: Perfil de energía del protocolo de comunicación basado en TCP]

Protocolos sin conexión

Los protocolos sin conexión no requieren una conexión activa con el servidor para que se produzca la transferencia de datos. Estos ofrecen una perspectiva mucho más prometedora para la aplicación de dispositivos IOT alcanzables en la red. Algunos ejemplos de estos protocolos son MQTT-SN, CoAP y LWM2M, que se implementan sobre UDP.

Estos protocolos son ligeros y optimizados para el consumo de energía y recursos, lo cual es favorable para la plataforma con restricciones de recursos en la que se pretende utilizar. Sin embargo, existe un desafío logístico con estas redes en cuanto a que el dispositivo sea alcanzable en la red.

A pesar de que los protocolos en sí mismos no requieren conexión, la red subyacente todavía requiere transferencia ocasional de datos para mantener activas las traducciones NAT. Los dispositivos NAT (traducción de direcciones de red), comúnmente utilizados en redes domésticas y empresariales, tienen tiempos de espera para las entradas de traducción en sus tablas. Si un dispositivo que utiliza protocolos sin conexión permanece inactivo durante un período prolongado, superando el tiempo de espera NAT, la entrada de traducción correspondiente se purga, haciendo que el cliente original sea inalcanzable para la red. Para abordar esto, es necesario implementar mensajes de mantenimiento de conexión o mecanismos similares para mantener las traducciones NAT y garantizar una continuidad en la conectividad de red para los dispositivos IOT que utilizan protocolos sin conexión, pero esto es muy costoso para la batería y no es ideal para un dispositivo IOT donde la batería es un recurso escaso.

Conclusión

Como hemos explorado en este artículo, construir un dispositivo alcanzable en la red es un desafío en todos los niveles, desde las limitaciones del dispositivo hasta las limitaciones de la infraestructura. Los protocolos de comunicación basados en UDP ofrecen un futuro prometedor para dispositivos alcanzables de baja potencia en la red, porque, fundamentalmente, el desafío logístico de los tiempos de espera NAT, mencionado anteriormente, puede eliminarse utilizando una red privada y eludiendo por completo el NAT. A medida que crece el interés en la necesidad de dispositivos alcanzables en la red, deberíamos ver infraestructuras de red comerciales específicas que ofrezcan soluciones listas para usar para estos desafíos.