Fuente: LinkedIn / Escribe: Tugberk B. / Imagen: Sigfox Canada
No es muy sencillo comparar diferentes tecnologías de comunicación de IoT en términos de consumo de datos. Si se hace tal comparación sin una buena investigación sobre los detalles de las tecnologías de radio, se pueden sacar conclusiones falsas.
Este artículo explica las diferencias de un objeto conectado Sigfox frente a un objeto conectado IP en términos de transferencia de datos y explica los detalles técnicos cuando se trata de lo que significa con “12 bytes de carga útil” dentro de un concepto de red Sigfox.
Se concluye que el consumo de datos correspondiente de un mensaje Sigfox de 12 bytes en comparación con un objeto conectado a IP con el mismo comportamiento es de 8,2 KBytes. Luego, esto se convierte en consumo de datos mensual y anual para ayudar a encontrar el precio correcto para los objetos conectados por celular. Se hace un último punto sobre las letras pequeñas en los datos móviles y cómo se aplican a los objetos con sesiones de transferencia de datos poco frecuentes.
Introducción
En un artículo reciente en Internet se comparan los precios de los datos de varias suscripciones de comunicaciones de IoT, y se presenta una conclusión injusta al hacer un cálculo de “Euros por byte”. Esta es una conclusión injusta porque compara tecnologías fundamentalmente diferentes sin entrar en detalles sobre cómo se envían los datos por aire y cómo se presentan al cliente final.
El propósito de este artículo es intentar encontrar un terreno común para comparar el mensaje de “12 bytes” de Sigfox con un objeto de IoT habilitado para IP con un comportamiento similar. Para poder demostrar las diferencias, se presenta una descripción general de la tecnología Sigfox y se intenta calcular el consumo de datos de un objeto habilitado para IP de contraparte, ya que la conectividad IP es la implementación más común de objetos de IoT en el mundo celular. Finalmente, hay una sección que habla un poco sobre las condiciones de letra pequeña en M2M, planes IoT SIM y su efecto en el consumo de datos para comunicaciones de objetos con bajos intercambios de datos.
Cómo funciona la conexión Sigfox
La siguiente imagen muestra el flujo de mensajes de un objeto conectado a Sigfox.
La radio Sigfox es famosa por ser la tecnología de acceso por radio más simple que permite que los objetos IoT de bajo costo y bajo consumo se conecten de forma inalámbrica a Internet. La simplicidad proviene de algunas opciones de diseño diferentes. A los efectos de este artículo, hablaremos de lo siguiente:
° El objeto se despierta, transmite su mensaje y se vuelve a dormir.
° El objeto envía 12 bytes de carga útil como parte del mensaje. Estos 12 bytes deben ser utilizados por la aplicación, generalmente de forma codificada para aprovecharlos al máximo. Un buen ejemplo de tal codificación se puede encontrar en uno de los objetos de Sigfox Ecosystem Partner llamado Oyster. Como se puede ver aquí, en lugar de enviar un mensaje estructurado de 174 bytes como:
Message Type = 0 (GPS Data Record) In Trip = True Last Fix Failed = False Lat = 1.3401526 Long = 103.7762054 Heading = 304 degrees Speed = 22km/h Battery = 4.85V.
Un objeto Sigfox simplemente envía la carga útil de datos de 12 bytes:
10b67dcc0006efda3d9816c2
y deja que el servidor de aplicaciones del cliente lo decodifique correctamente, de acuerdo con reglas predefinidas y específicas.
A continuación se muestra una indicación de cuántos bytes necesitan los distintos tipos de datos de sensor.
También vale la pena mencionar que se pueden realizar algunas optimizaciones en estos valores. Por ejemplo, si se sabe que una determinada temperatura ambiente está entre 0 y 40 grados con un tamaño de paso de 0,5 grados, solo se necesitan 80 valores discretos y 1 byte en lugar de 2 bytes será suficiente para representar estos datos.
° El objeto también envía una trama de 14 bytes para la sobrecarga de radio, que consta de algunos parámetros de radio, el campo de verificación CRC y también los siguientes campos:
Sequence ID: A transmission sequence identifier to avoid certain replay attacks and preserve authenticity. Also used for calculating message success rate. Object ID: A 4-byte global sigfox ID to uniquely identify an object within Sigfox. Object Authentication Code: HMAC signature used by Sigfox Cloud in authenticating the object.
Para obtener más detalles sobre la estructura de la trama de radio de Sigfox, consulte este enlace.
Los datos de los objetos son capturados por las estaciones base de Sigfox y enviados a Sigfox Cloud. Durante esta fase, se pueden agregar al mensaje del objeto algunos metadatos, incluida la marca de tiempo, la identificación del objeto, el número de secuencia y el indicador de calidad del enlace.
Sigfox Cloud autentica el mensaje y lo reenvía a las instalaciones del cliente a través de una devolución de llamada HTTPS. Una devolución de llamada de datos HTTPS típica es la siguiente.
POST {URL of the destination endpoint} HTTP/1.0
accept-encoding : gzip,deflate
connection : Keep-Alive
accept-charset : UTF-8;q=0.9,*;q=0.7
x-amz-security-token : {security token ~356 characters}
content-type :
authorization : {authorization credentials ~211 characters}
content-length : 203
host : {URL_host}
accept-language : fr
user-agent : SIGFOX
accept : */*
x-amz-date : 20200824T045545Z
{
"object" : "2C4A89",
"time" : 1598244944,
"data" : "10b67dcc0006efda3d9816c2",
"seqNumber" : 1262,
"lqi" : 3
}
Tenga en cuenta que los campos sensibles se han reemplazado por descripciones entre llaves.
También cabe mencionar que:
- La red Sigfox también admite aplicaciones donde se requiere un mensaje de regreso al objeto (comunicación de enlace descendente). Esta comunicación de enlace descendente tiene un efecto mínimo o nulo para el propósito de este artículo y será ignorado. Consulte este enlace para obtener más información sobre el enlace descendente.
- Se puede realizar algún nivel de decodificación del mensaje sin procesar en Sigfox Cloud para enviar valores reales en lugar de datos sin procesar.
- Se pueden configurar múltiples devoluciones de llamada a diferentes destinos, sin costo adicional.
- Sigfox Cloud intenta devolver la llamada cuatro veces, en los momentos T0, T0 + 1 minuto, T0 + 2 minutos y T0 + 4 minutos. Si los 4 intentos fallan, Sigfox Cloud conserva el mensaje para que lo recupere un punto final de API especial. Esto también es gratuito.
Cómo funciona la conexión IP
La siguiente imagen muestra el flujo de mensajes de un objeto conectado a IP a través de una red celular.
En los objetos conectados a celulares, es común implementar la conectividad IP directamente en el objeto. Aunque en teoría es posible hacer una no comunicación IP con NB-IoT, actualmente no es una implementación muy habitual. Los precios de los datos de los operadores de redes celulares casi siempre se anuncian para los objetos conectados a IP. Tampoco está claro cómo funcionan los precios para la entrega de datos que no son IP (NIDD), ya que el operador debe proporcionar una interfaz API para que el cliente extraiga / envíe los datos y esto generalmente significa un servicio adicional con un costo.
Si un objeto similar se comunica a través de la IP, así es como funciona el flujo:
- El objeto se despierta, establece una conexión RRC con la red celular.
- El objeto obtiene una dirección IP y establece una sesión IP con la aplicación. Todos los gastos generales de TCP, SSL y HTTP entre Sigfox Cloud y el servidor de aplicaciones del cliente, como se describe en la sección anterior, tienen lugar entre el objeto y el servidor de aplicaciones del cliente y todos estos gastos generales se contabilizan en el consumo de datos del objeto.
- Las pérdidas y retransmisiones habituales de paquetes TCP / IP debido a la naturaleza de las ráfagas de Internet ocurren entre el objeto y el servidor de aplicaciones, y se contabilizan en el consumo de datos del objeto.
Cálculo del consumo de datos
Teniendo en cuenta la información proporcionada anteriormente, se puede realizar una mejor estimación y comparación del consumo de datos de un objeto Sigfox frente a un objeto conectado a IP.
A continuación se muestran algunas suposiciones realizadas durante este cálculo:
Supuestos del objeto Sigfox:
- El objeto Sigfox envía 140 mensajes al día, con 12 bytes de carga útil.
- No se realiza ninguna decodificación de datos en Sigfox Cloud. (es decir, la carga útil de 12 bytes se envía tal cual al servidor de aplicaciones).
- Se define una devolución de llamada desde Sigfox Cloud al servidor de aplicaciones.
A continuación se muestran los datos + metadatos enviados dentro de la devolución de llamada:
Timestamp in epoch time: 10 bytes Object ID: 4 bytes Payload: 12 bytes Sequence number: 1 byte Link quality indicator: 1 byte
Objeto celular con el mismo comportamiento:
En comparación, el objeto celular establece 140 sesiones al día al servidor de aplicaciones del cliente directamente y envía exactamente la misma carga útil y metadatos en una devolución de llamada https. A continuación se muestran los datos enviados:
Timestamp in epoch time: 10 bytes Object ID: 4 bytes Payload: 12 bytes Sequence number: 1 byte Link quality indicator: 1 byte
° Los datos en la devolución de llamada https están en formato json.
° Esta comunicación se realiza a través de TCP / IP.
° Se descuidan las solicitudes de DNS para resolver la URL.
° El servidor de aplicaciones responde a la recepción exitosa de la devolución de llamada con un mensaje http 204.
° Tasa de éxito de TCP del 100% (sin retransmisiones)
En primer lugar, mostramos cómo se ven los datos después de “convertirlos de 12 bytes a un formato HTTP POST. A continuación se muestra una figura que describe esa evolución.
Una carga útil de 12 bytes que contiene datos del sensor se convierte a json con la adición de algunos metadatos que son obligatorios para el análisis, y luego estos datos json se convierten en una solicitud http POST con la autenticación adecuada y otros parámetros http. La solicitud POST resultante tiene un tamaño de 1040 bytes.
En segundo lugar, calculamos la cantidad total de tráfico generado enviando de forma segura la carga útil a través de una devolución de llamada HTTP a través de TLS. Para averiguar la cantidad total de tráfico creado para el intercambio de datos, se utilizó postman para enviar devoluciones de llamada https con todos los encabezados y carga útil adecuados. A continuación, se muestran capturas de pantalla de la solicitud de devolución de llamada de la API del postman.
Y la recepción exitosa de la devolución de llamada se puede ver a continuación
Al enviar estas solicitudes, se han realizado volcados de Wireshark para analizar el tráfico creado por este intercambio. La captura de pantalla del tráfico se puede ver a continuación.
Todo este intercambio de tráfico suma un total de 8202 bytes (8,2 KBytes) cuyo desglose se detalla a continuación.
Notas sobre la comparación
Tenga en cuenta que esta comparación es un escenario de caso óptimo en el que:
Se asumen las condiciones ideales de TCP / IP, es decir, no se considera la retransmisión de datos. Si se produce una retransmisión, que es probable que suceda a una tasa del 1,5% en el mundo IP, eso significará un consumo de datos adicional de un objeto conectado a IP, sin embargo, el equivalente de Sigfox no tiene ningún costo adicional, ya que todas las comunicaciones TCP / IP, incluidas las retransmisiones, son manejado por Sigfox Cloud.
No se asume ninguna decodificación en el objeto. Si el objeto envía datos decodificados en formato de texto, eso da como resultado un consumo de datos adicional en el objeto conectado a IP. El equivalente de Sigfox puede realizar la decodificación a nivel de Sigfox Cloud sin costo adicional.
Cálculos de consumo de datos mensuales y anuales
Con algunas matemáticas simples, el consumo de datos de un objeto conectado IP equivalente se puede calcular fácilmente para 3 niveles de suscripción diferentes que ofrecen los planes de conectividad de Sigfox. A continuación se muestra un desglose de los niveles de suscripción de Sigfox y sus correspondientes cantidades de consumo de datos mensual y anual para las contrapartes conectadas a IP correspondientes.
Para dar un ejemplo de la tabla anterior, un objeto conectado a IP con un comportamiento equivalente a un objeto conectado Sigfox con nivel de suscripción Ultra Level (es decir, 140 Uplinks por día) terminará consumiendo alrededor de 413 Megabytes por año (~ 35 Megabytes por mes), asumiendo condiciones de tráfico ideales sin pérdida de paquetes y sin solicitudes de DNS.
Notas sobre planes de datos móviles
Las impresiones pequeñas sobre los cargos de datos deben investigarse cuidadosamente para evitar cualquier impacto en la factura de un objeto conectado a IP. Algunas de estas pequeñas impresiones que pudimos capturar de las páginas públicas son las siguientes:
°La carga de datos se realiza para la comunicación de enlace ascendente y descendente combinados.
°Bloque de carga mínimo: el consumo total de datos dentro de una sesión generalmente se redondea al 1 kbyte o 10 kbyte más cercano. Para volúmenes de datos pequeños como nuestro caso, la cantidad de datos enviados durante una sesión será muy pequeña y se redondeará, lo que puede marcar una diferencia significativa en términos de facturación. En nuestro caso, el objeto se cobraría por 9 o 10 kbytes por sesión si el bloque de carga mínimo fuera de 1 o 10 Kbytes respectivamente.
°Importe mínimo de cobro por sesión: algunos operadores tienen un importe mínimo de cobro por sesión. Esto también es importante para los casos de uso en los que la duración de la batería del objeto se maximiza mediante sesiones de activación y transferencia de datos poco frecuentes. Imagine una tarifa de datos en la que la cantidad mínima de cobro fuera tan baja como 1 centavo. ¡Esto daría como resultado un coste de datos de 1,4 euros por día!
Conclusión
Al contrario de lo que algunos creen, 12 bytes en realidad significan mucho. No solo 12 bytes pueden representar una cantidad significativa de información del sensor, la versión conectada a IP de la transmisión de datos de 12 bytes podría resultar en un intercambio de tráfico de 10 Kbytes. Gracias al diseño centrado en la simplicidad de la conectividad Sigfox, el procesamiento y la transmisión de pequeñas cantidades de datos se vuelve muy fácil y mucho más eficiente.
