Como funciona la red LPWAN Sigfox

Tiempo de lectura estimado: 7 minutos

En el post de esta quincena os proponemos una descripción técnica sencilla de cómo opera la red Sigfox, una de las principales opciones actuales de red LPWAN para las comunicaciones de dispositivos en la Internet de las Cosas.

Lo primero, indicar que LPWAN viene de Low Power Wide Area Network, es decir, una red de gran cobertura y que requiere muy bajo consumo de potencia de transmisión para los dispositivos (o "cosas").

En IoT es básico que los dispositivos, sensores o actuadores consuman muy poca potencia porque reemplazar frecuentemente sus baterías hace el mantenimiento muy costoso.

Mientras esperamos la gran promesa de la tecnología Narrow-Band IoT, Sigfox junto con LoRa son las tecnologías LPWAN de mayor calado. La (a nuestro modesto juicio) brillante política comercial de Sigfox les ha llevado a tener cobertura en unos 60 países, productos innovadores y una red de partners y desarrolladores competente.

Si los lectores lo deseáis dedicaremos otro artículo a LoRa. De momento podéis encontrar algo de contexto y comparativas aquí y aquí.

Hoy nos vamos a centrar en Sigfox y cómo utiliza espectro y energía de una manera eficiente para soportar grandes proyectos de IoT: su modulación, su topología y algunas funcionalidades.

Foto de NASA en Unsplash

Modulación UNB (Ultra Narrow Band)

Sigfox utiliza un ancho de 200 kHz dentro de la banda pública no licenciada de los 868 a 869 MHz en Europa y 902 a 928 MHz en el resto del mundo, según restricciones locales. Concretamente en Europa se transmite entre 868,034 y 868,226MHz.

La transmisión radio de Sigfox utiliza tecnología Ultra Narrow Band (UNB) combinada con modulación DBPSK y GFSK.

Ejemplo de señal UNB

Cada mensaje ocupa un ancho de banda de 100 Hz y se transmite a una velocidad de datos de 100 ó 600 bits por segundo según la región.

Esto implica que un mensaje de 12 bytes tarda unos 2 segundos en transmitirse.

No hay tráfico de sincronización ni señalización entre la red y el dispositivo (de nuevo para ahorrar consumo y ancho de banda). El dispositivo transmite 3 veces el mensaje en 3 frecuencias diferentes mediante técnicas de salto de frecuencias (frequency hopping). De este modo se consigue más robustez gracias a la diversidad en tiempo y en frecuencia.

Salto de frecuencias en mensajes replicados

Las estaciones base monitorizan todo el espectro de 192KHz a la búsqueda de señales UNB para demodular.

Mensajes de uplink y downlink

Posiblemente habréis escuchado que Sigfox permite un número máximo de mensajes al día, la llamativa cifra de 144 y os habréis preguntado por qué esta limitación tan original, que limita algunos usos. Ahí va la explicación:

La regulación en Europa establece que se puede ocupar la banda pública el 1% del tiempo como máximo. Esto se traduce en 6 mensajes (cada uno repetido tres veces como hemos visto) de 12 bytes por hora, es decir 144 mensajes por día.

El límite del número de mensajes del servicio para mensajes Uplink (del dispositivo a la red) es de 140. Básicamente, los dispositivos eligen cuándo envían los mensajes.

Se permiten 4 mensajes de bajada (Downlink) con un payload limitado a 8 bytes. La frecuencia de downlink es la frecuencia del primer mensaje de uplink más un delta conocido.

2s * 6 mensajes * 3 veces = 36 segundos, 1% de 3600

6 * 24horas = 144 mensajes permitidos al día, 140 de uplink y 4 downlink

Red con topología en estrella

En la figura siguiente se muestra la arquitectura de alto nivel de la red de Sigfox. Los dispositivos no están asociados a una estación base concreta. El mensaje que el dispositivo Sigfox envía se recibe en las diversas estaciones que estén lo suficientemente cerca para recibirlo. En entornos urbanos habitualmente hay 3 estaciones disponibles para cada dispositivo.

Topología Red Sigfox

De esta manera se consigue diversidad espacial además de las mencionadas en tiempo y frecuencia.

Alta resiliencia frente a errores y largo alcance

UNB es muy robusta frente a interferencias provocadas o no gracias a la diversidad mencionada espacial, en tiempo y en frecuencia.

Además, la baja tasa de transferencia y una modulación simple DBPSK permiten un budget de enlace de 163.3 dB que facilita alcanzar largas distancias.

Eficiencia de consumo

El protocolo radio Sigfox mantiene la longitud de la trama al mínimo, incluso se transmiten sólo los bytes que el dispositivo tenga que transmitir; si tiene menos de 12, el payload se reduce al número de bytes real.

Consumo reducido

Como hemos dicho, no se transmite tráfico de señalización ni sincronización. Combinando una potencia de transmisión baja y que el tiempo de transmisiónes muy corto (menos de un minuto al día) se consigue un consumo muy bajo y gran autonomía.

Seguridad

El ecosistema Sigfox se presenta como diseñado con una filosofía Security-by-default, integrando:

Autenticación+integridad+anti-copia
Criptografía basada en AES
Opción de encriptar el payload
Aislamiento de las partes de la red
Control de números de secuencia
Control de ID de dispositivos, añadiendo a la lista negra dispositivos sospechosos de haber sido objeto de hacking

La figura siguiente muestra un extracto de las medidas de seguridad implementadas.

Seguridad de Red Sigfox

Backend de Sigfox

Sigfox proporciona para el administrador de IoT una interfaz web para la gestión de dispositivos, usuarios e información recogida. A continuación mostramos qué se puede hacer a través de esta interfaz y uno de sus puntos fuertes: la posibilidad de configurar callbacks.

Gestión de dispositivos y usuarios

Permite:

realizar altas, bajas y modificaciones así como la creación de diferentes tipos de dispositivos con propósitos de agrupación.
visualizar y exportar los mensajes recibidos de un dispositivo
configurar, recibir y visualizar eventos.
ver estadísticas de mensajes, y de estado del dispositivo
crear callbacks (lo veremos más adelante)
crear usuarios y grupos de usuarios con diferentes perfiles

Registro de un nuevo dispositivo a través del backend de Sigfox

Registro de un usuario a través del backend de Sigfox

Creación de callbacks

Desde el backend podemos ver los mensajes enviados por un dispositivo, y exportar el histórico. No obstante, probablemente preferiremos que los datos que envía el sensor o dispositivo IoT se envíen a nuestras aplicaciones o bases de datos, y no se queden en la nube Sigfox.

Para poder remitir los datos incluidos en el payload de mensajes Sigfox, se puede emplear el mecanismo de callback. En la figura puede verse la función en la parte derecha inferior.

Básicamente, este mecanismo sirve para enviar datos mediante correo o mediante protocolo REST a un servidor, utilizando POST o PUT.

Existen ya callbacks predefinidos para la nube de Amazon y de Azure. Para una aplicación genérica en la nube se puede implementar un callback a medida (custom).

La figura siguiente muestra el formulario de creación de custom callback en el backend de Sigfox.

Nota: para dotar de redundancia al sistema se pueden configurar dos callbacks a dos servidores diferentes en la nube, de manera que siempre exista una plataforma de backup. Obsérvese que esto no equivale a seleccionar la opción “Send duplicate”, que envía 2 copias al mismo endpoint HTTP.