Internet das Coisas e o Protocolo SigFox - Blue Eyes Systems
O termo IoT, sigla em inglês para Internet of Things, ou em português Internet das Coisas tem se popularizado cada vez mais nos últimos anos. O termo se refere nada mais nada menos a uma rede de objetos físicos, como veículos, prédios e até mesmo objetos mais cotidianos, como sua geladeira a internet.
Dentro desse universo, cada vez mais empresas desenvolvem soluções para este ramo e uma delas é a Sigfox, uma operadora de rede global francesa fundada em 2010 que constrói redes sem fio para conectar objetos. Um dos grandes desafios endereçados por essa empresa foi conciliar objetos que precisam estar continuamente ativados e emitindo sinais com um sistema de baixo uso energético. Garantindo assim cumprir os requisitos da maioria das aplicações de IoT: baixo custo, baixo uso energético, alto range de comunicação e alta confiabilidade de rede.
A tecnologia SigFox e os desafios de desenvolvimento
A tecnologia Sigfox se fundamenta, assim como toda tecnologia sem-fio, sobre princípios básicos de funcionamento de sistemas de telecomunicações. Durante o decorrer deste texto abordarei cada um desses pontos.
As bases da tecnologia
Como base de funcionamento a Sigfox utiliza a técnica Ultra Narrow Band para transmissão de dados. Está técnica consiste em um receptor que pode rejeitar ruídos e interferências que podem entrar no receptor fora de sua largura de banda¹, garantindo assim uma relação de sinal versus ruído extremamente vantajosa permitindo que sinais relativamente fracos e baixos possam ser recebidos e interpretados. Sendo assim, por consequência, os níveis de potência do transmissor podem ser mais baixos e o alcance efetivo de transmissão pode ser maior que no uso de outras tecnologias que não utilizem essa abordagem de seletividade de sinal/ruído.
A tecnologia se apoia sob três pilares: baixo consumo de energia, baixo custo de implementação e confiabilidade de informação.
Imagine a seguinte situação hipotética: considere um dispositivo monitorando a temperatura de um determinado ambiente e está conectado a um dispositivo Sigfox, seus dados de temperatura serão convertidos para se encaixarem no protocolo de comunicação, que são basicamente, as características necessárias para você se comunicar dentro da rede sigfox. Assim como os idiomas onde para que seja estabelecida uma conversa ambos os participantes devem falar a mesma língua, os protocolos de comunicação funcionaram da mesma maneira, ou seja, para que você envie o sinal algumas características devem ser levadas em consideração.
Uma dessas características é a frequência central que estabelecerá em qual rodovia trafegarei, e a outra é o tamanho dessa rodovia (quantidade de faixas onde podem passar carros) e chamaremos isso de largura de banda. Sendo assim minha frequência central será a minha faixa do meio e minha largura de banda delimitará a quantidade de faixas do lado esquerdo e direito em minha rodovia. Assim como mostrado no desenho abaixo:
Dentro da minha largura de banda de transmissão o meu dispositivo SigFox irá montar sua mensagem, ou Payload, que vai conter as informações que quero enviar, as informações do meu dispositivo e seus dados criptográficos.
Diferente dos protocolos de celular o dispositivo Sigfox não fica conectado diretamente a uma estação de sinal, ele apenas enviara as mensagens da seguinte maneira: enviara 3 as mensagens em torno da Fc ocupando 100Hz da minha largura de banda a estação assim receberá a mensagem e a passará para o Cloud Sigfox. A comunicação do meu dispositivo para estação é chamada de Uplink e a resposta será chamada de Downlink, onde cada um desses lados de comunicação possui uma velocidade especifica de transmissão, por analogia, seria o quão rápido os carros trafegam e em qual sentido e ela é chamada de Uplink Data Rate e Downlink Data Rate medida em bits por segundo.
Características Técnicas do protocolo
Atualmente existem 7 zonas de operação de Sigfox no mundo como podemos ver no gráfico abaixo:
Fonte: https://build.sigfox.com/sigfox-radio-configurations-rc
Cada uma dessas regiões possui suas características particulares no que se resume a configurações de rádio e/ou de envio de mensagens, como pode ser visto na tabela abaixo:
Focando nas duas últimas linhas da tabela alguns conceitos a serem explicados, vamos começar pelo EIRP (Effective Isotropic Radiated Power) que é basicamente a potência máxima da minha frequência central.
Na última linha temos algumas particularidades quanto ao envio de mensagens são eles: Duty Cycle, Frequency hopping e Listen Before Talk.
Duty Cicle: razão cíclica ou ciclo de trabalho corresponde a quantidade de tempo que um sistema fica operando em nível alto e nível baixo, como mostrado no gráfico abaixo:
Como descrito na tabela, este modo de operação do dispositivo nas regiões RC1 e RC7 utilizam deste mecanismo com duty cicle a 1%, ou seja, em 1% fica em estado de nível alto por hora (36 segundos) para um payload de 8 a 12 bytes.
Frequency hopping: O dispositivo enviara 3 mensagens em 3 frequencias diferentes com um tempo máximo de 400ms segundo por canal e não permitira reemissão de mensagens em até 20 segundos.
Listen Before Talk: O dispositivo verificara se o canal SigFox dentro de sua largura de banda de 200kHz está livre de qualquer outro sinal com potência maior que -80dBm antes de transmitir.
Em telecomunicações, incluso os sistemas de IoT não escapando o protocolo Sigfox dessa regra, antes de ser transmitida tem que passar por um processo chamado de modulação. Tudo que falamos até agora sobre as mensagens sigfox se tratavam de banda base, ou seja, antes de ser modulada para ser transmitida pelo ar. Os dispositivos tanto em uplink como em downlink tem que modular e ou demodular um sinal antes de analisá-lo. Mas afinal, o que é o processo de modulação? Basicamente é o processo no qual o meu sinal de base, banda base, passa por um processo de adição de outras ondas eletromagnéticas que vão permitir que a mesma seja interpretada do outro lado. Lembrando que as comunicações digitais se baseiam em sinais binários (0 ou 1) o processo de modulação vai marcar onde essas transições de nível alto e baixo existem. Por exemplo: a modulação por amplitude vai alterar amplitude do meu sinal de modo que meu dispositivo demodulador entenda quando eu encontro 0 ou 1, exemplificando: posso modular um sinal de forma que 24 dBm represente 1 e 0 dBm represente zero. Neste caso as demais características da onda como frequência e fase se mantém inalteradas.
Outros tipos de modulação são: modulação por frequência (FM) e modulação por fase (PM).
Modulação Uplink – Sigfox
Para comunicação do tipo Uplink o dispositivo Sigfox utilizara a modulação 2-BPSK Binary Phase Shifting Key, ou modulação binaria por chaveamento de fase em português. Que significa basicamente que o dispositivo representará as mudanças de estado 0 e 1 através de uma alteração na fase da onda, ou seja, se a onda mantém a fase constante eu tenho um estado, quando a mudança de fase significa que houve alteração de estado. Como pode ser visto na demonstração abaixo:
Fonte: https://www.disk91.com/2017/technology/sigfox/the-sigfox-radio-protocol/
Modulação Downlink – Sigfox
Diferente da comunicação Uplink o Downlink utiliza a modulação 2-GFSK, 2-Level Gaussian Frequency Shift Key, que é basicamente uma modulação por variação de frequência com um filtro gaussiano de ordem 2 aplicado a ele. Abaixo temos a demonstração de uma modulação do tipo FSK sem o filtro aplicado para facilitar o entendimento:
Fonte: https://sites.google.com/site/nearcommunications/gfsk-modulation
Como citado acima cada protocolo de comunicação, assim como um idioma, tem seus formatos padrões de como se montar uma sentença, e com Sigfox não é diferente. Para explicar o formato da mensagem, vamos primeiro lembrar que cada transmissão de mensagens é enviado 3 sinais, chamaremos cada um deles de frame e dividiremos cada um desses frames em 8 partes, são elas: F.Sync, F.Type, Flag, SeqID, Device ID, Payload, HMAC e CRC16.
F.SYNC: É a parte do frame que trata da sincronização, é uma sequência padrão de zeros e um's que vai permitir o receptor sincronizar corretamente o restante da mensagem.
F.Type: vai determinar duas coisas o tamanho do payload e indica qual repetição é de frame, lembrando que o sigfox envia três frames iguais para compor uma mensagem.
Flag: Indica o número de bytes adicionado para o frame se encaixar no tamanho padrão. Por exemplo, o payload tem tamanho máximo de 12 bytes, caso você adicione uma informação de 8 bytes, o flag indicara que você precisou de 4 bytes vazios para completar o tamanho padrão. Além disso o flag indicara se a mensagem fez ou não uma requisição de downlink.
SEQ.ID: É o contador de mensagens e indica qual é o número da mensagem, por exemplo, a primeira mensagem do dia é 1, o SEQ.ID identificara isso para a SigFox API. Esse número é incrementado a cada mensagem enviada.
DEVICE.ID: Este número é o CPF do seu dispositivo Sigfox um identificador que é usada pela SigFox API.
Payload: É a porção do frame que contém a informação que será enviada na mensagem.
HMAC: O HMAC é um hash único que contém os dados criptografados do protocolo de comunicação, contendo, o código de correção de erros (ECC) e o código AES (Advanced Encrypt Standard).
CRC (Cyclic Redundancy Check): Representa o método de correção de erros do frame detectando mudanças acidentais na cadeia de dados.
A abaixo podemos ver o formato do frame de forma mais clara:
Tecnologia Monarch
Dentro da tecnologia Sigfox a o certificado SigFox Monarch que consiste em dispositivos capazes de se conectarem à rede Sigfox de forma automática em qualquer lugar do mundo dentro das 7 zonas de operação. Isso funciona de maneira bem simples: o dispositivo enviará um sinal beacon que auxiliara o dispositivo identificar em qual zona ele está e assim adequar suas características a ela. Esse é um recurso exclusivo da rede SigFox.
O protocolo Sigfox é perfeito para monitoramento onde não há necessidade de grandes volumes de dados e/ou altíssima velocidade de monitoramento sendo perfeito para utilização em dados pequenos que precisam ser transmitidos esporadicamente. Por exemplo:
Rastreamento na indústria do agronegócio, monitoramento de cabeças de gado
Monitoramento de violações de segurança
Desafios na construção do sistema de teste e suas soluções
No processo de certificação de um produto Sigfox a etapa de teste é fundamental para garantir o sucesso da aplicação, sendo assim, a Blue Eyes Systems optou pelas tecnologias National Instruments por garantir a rápida prototipagem da API de comunicação utilizando a linguagem LabVIEW. E para gerenciamento do supervisório de teste foi utilizado o TestStand. O hardware utilizado para a aquisição e geração de sinais foi o seguinte:
Chassi PXIe-1095, é o gabinete onde os componentes modulares abaixo foram encaixados.
Controladora PXIe-8880 com Windows 10, a controladora é o cérebro do sistema é a CPU que vai controlar todos os periféricos envolvidos.
Placa PXIe-5644R – VST, Vector Signal Transceiver, placa responsável pela geração e aquisição de sinais de rádio frequência.
Placa SMU PXIe-4145 – Source Measurement Unit, fonte de tensão controlada por software.
Da esquerda para direita temos, PXIe-8880, PXIe-4145 e por último PXIe-5644R
Configuração de plano de testes
A Sigfox disponibiliza os documentos completos de planos de teste e neste texto abordaremos apenas as configurações de alto nível e os requisitos primários de cada uma delas. Os testes fundamentalmente conectavam o dispositivo Sigfox a ser tesado com a seguinte disposição:
Glossário de teste
2GFSK: 2-Level Gaussian Frequency Shift Key (Modulação de Downlink).
DBPSK: Differential Binary Phase Shift Key (Modulação de Uplink).
DUT: Device Under Test (Dispositivo a ser testado).
Configuração de teste de Qualidade de Modulação
Fonte: SigFox RF & Protocol Test Plan for RC3a-UDL-ENC, Versão 3.8.1 – 11 de Outubro, 2018
A controladora PXI nesta configuração cumpria o papel de enviar os comandos de Test Mode Activation para o DUT, a placa SMU alimentava o mesmo e a placa VST era responsável por receber os sinais. Neste modo de teste o DUT gera apenas em sinais em banda base, de forma que o VST pudesse analisar os componentes do sinal. Se dividindo em forma de requisitos de alto nível como:
Análise de frequência para verificação se os canais não ultrapassam o limite de 100Hz, verificação de desvio de fase, estabilidade de desvio de frequência e analisa de tolerância estática de frequência.
Análise de Modulação: Ao receber o sinal em banda base o PXI deve modular o sinal e verificar: o baudrate da informação recebida, o tempo de duração dos bits extras acrescentados ao frame como banda de guarda e o sinal está realizando corretamente as mudanças de fase.
Análise de potência: Verificação de distribuição de potência dentro da largura de banda e níveis de potência por divisão de largura de banda como pode ser visto nas duas imagens abaixo.
Neste caso da imagem acima o teste verifica se 99% da potência fica distribuída em até 36kHz da largura de banda.
Na imagem acima cada um dos degraus é analisado e uma mascara é criada sobre o sinal de forma a validar se o formato da distribuição de potência está dentro das especificações.
Configuração de teste de análise de Informação Demodulada
Assim como na configuração anterior a controladora PXI enviava os comandos de operação para o DUT via canal serial, a placa SMU o alimentava e o VST analisaria os sinais. Nesta configuração em questão, o DUT envia uma mensagem modulada e o VST deve ser capaz de: analisar o ID e chave de criptografia assim como ser capaz de gravar as o gráfico de constelação de modulação e analisá-los para verificação de desvio de sinal, assim como verificar a quantidade de frames de uma mensagem, que deve ser igual a 3 e o tempo entre eles.
Configuração para validação de Downlink
Nesta configuração de teste a placa VST fica responsável por enviar um frame padrão ao DUT e o mesmo deve retornar via serial a potência na qual o sinal foi recebido, este parâmetro serve como base para a correta calibração do sistema de recepção de informações do DUT.
Configuração de teste de validação de comunicação TX/RX
Nesta configuração, o VST deve enviar e receber sinais do DUT, ou seja, o recebe uma mensagem com requisição de downlink e deve ser capaz de detectar em qual canal da largura de banda a mensagem foi enviada, e responder a mesma e aguarda uma confirmação do DUT de que a troca de mensagens foi bem sucedida, chamamos este procedimento de Bi-Direcional. Essa configuração valida as especificações temporais de troca de mensagens além de verificar os tempos entre os 3 frames enviados dentro da mensagem, seguindo as especificações abaixo:
Fonte: Sigfox connected Objects: Radio specifications – Fev 2019
Na tabela 4-1 temos os tempos e intervalos entre uma mensagem de Uplink na primeira linha, na segunda temos os tempos de Downlink para resposta e nas duas últimas os tempos mínimos e máximos para mensagem de confirmação.
Configuração de Teste Listen Before Talk
Nesta configuração de teste, usada apenas para zona RC3 e RC5, o sistema de teste deve ser capaz de receber o sinal do DUT e ao mesmo tempo enviar um sinal de bloqueio. A operação listen before talk(LBT) consiste no DUT analisar se a banda está livre de outros sinais antes de enviar um frame, sendo assim neste procedimento o VST enviara um sinal de bloqueio concomitantemente ao DUT tentando enviar 6 frames, para validar o comportamento do LBT o DUT deve enviar apenas 2, o primeiro e o último conforme imagem abaixo:
Em vermelho temos o sinal do DUT tentando ser transmitido, em azul claro temos o bloqueador e em verde os frames que não sofreram influência do bloqueador que são os sinais realmente enviados ao VST.
[1] Sigfox connected Objects: Radio Specification – Fevereiro 2019
[2] Sigfox RF & Protocol Test Plan for RC3a-UDL-ENC – Versão 3.8.1 – 11 Outubro de 2018
[3] Sigfox RF & Protocol Test Plan for RC2-UDL-ENC – Versão 3.8.1 – 11 Outubro de 2018
[4] MEDEIROS, Julio Cesar de Oliveira. Princípios de Telecomunicações – Teoria e Prática. 5. Ed. São Paulo: Saraiva, 2009
[5] National Instruments Corporation, Managing Software Engineering in LabVIEWᵀᴹ Course Manual, Austin, Texas, 2009.
[6] National Instruments Corporation, LabVIEWᵀᴹ Core 3 Course Manual, Austin, Texas, 2014.
[7] National Instruments Corporation, Advanced Architectures for LabVIEWᵀᴹ, Austin, Texas, 2011.
[8] T. Janssen, M. Aernouts, R. Berkvens and M. Weyn, "Outdoor Fingerprinting Localization Using Sigfox," 2018 International Conference on Indoor Positioning and Indoor Navigation (IPIN), Nantes, 2018, pp. 1-6, doi: 10.1109/IPIN.2018.8533826.
[9] A. Lavric, A. I. Petrariu and V. Popa, "Long Range SigFox Communication Protocol Scalability Analysis Under Large-Scale, High-Density Conditions," in IEEE Access, vol. 7, pp. 35816-35825, 2019, doi: 10.1109/ACCESS.2019.2903157.