Rascunho do padrão nacional de IoT do OpenUNB: revisão crítica

Olá Habr!

Há algum tempo, o Grupo de Trabalho da Internet das Coisas da Skoltech publicou um rascunho do padrão nacional de IoT de banda estreita chamado “OpenUNB”, cujo texto completo pode ser encontrado aqui . Por um lado, o fenômeno é indubitavelmente positivo - se no campo dos padrões de banda larga existe de fato aberto para uso de todos que desejam LoRaWAN, os padrões de banda estreita até hoje são extremamente proprietários (Sigfox, XNB da Strizh, NB-Fi da Vaviot - embora o último também é publicado na forma de um projeto de norma nacional, não revela partes essenciais para a implementação de terceiros).

Ao mesmo tempo, os sistemas de banda estreita e banda larga têm seus próprios prós e contras, portanto, dizer "por que você precisa de algo mais quando existe LoRaWAN" não é totalmente verdade. Ou seja, é necessário um padrão aberto para comunicações UNB.

No entanto, a necessidade é apenas uma das duas condições. O segundo é suficiência. Ok, o que a Skoltech publicou é necessário, mas é suficiente para uso prático?



Nós responderemos a isso em um formato semelhante a uma entrevista - sob as citações cortadas do rascunho do padrão OpenUNB e seus comentários, dados por Alexander Sheptovetsky (AS), diretor técnico da GoodWAN, e Oleg Artamonov (OA), diretor técnico da Unwired Devices.

Então vamos lá. A estilística, ortografia e pontuação dos autores são preservadas.

Um recurso do protocolo é o uso de modulação de banda ultra-estreita (a largura do espectro de emissão é menor que 1 kHz), que permite alcançar uma alta relação sinal-ruído (com restrições na potência irradiada na faixa não licenciada), o que significa transmitir dados a longas distâncias ou através de vários obstáculos (paredes de concreto, divisórias armários de metal).

OA: o primeiro erro dos autores da norma é que eles inicialmente assumem alta SNR (relação sinal / ruído) como o principal requisito para sinais em sistemas LPWAN - e a partir desses erros continuará a crescer no design e na implementação do próprio protocolo, como escolher preâmbulos, por exemplo.

Na realidade, a principal capacidade dos protocolos sem fio LPWAN, fornecendo seu "alcance", é a capacidade de receber um sinal com um SNR baixo , até um negativo, ou seja, casos em que o nível do sinal é inferior ao nível do ruído.

Além disso, os autores da norma não estão bem familiarizados com os princípios básicos da teoria da transmissão de sinais e, especificamente, com o limite de Shannon na taxa de transferência de dados no canal na presença de ruído. Essa velocidade é determinada pelo valor do SNR e pela largura do espectro do sinal - de fato, um é compensado pelo outro. Portanto, para transmitir dados em sistemas LPWAN a longas distâncias, os sinais de banda estreita e banda larga (por exemplo, na banda LoRaWAN - 125 kHz) são usados ​​com êxito, cada um dos métodos tem suas próprias vantagens e desvantagens.

Isso é possível devido ao fato de que os dispositivos de assinante transmitem dados sem estabelecer uma conexão com a estação base (modo simplex), como por exemplo, isso é feito em redes celulares móveis.

OA: além dos erros estilísticos e de pontuação, noto o uso inaceitável e inaceitável da terminologia. O modo simplex, isto é, a transmissão de mensagens pelo canal de comunicação apenas em uma direção, não está diretamente relacionado à necessidade de estabelecer uma conexão - e certamente estes não são sinônimos. O mesmo LoRaWAN fornece comunicação bidirecional no modo half-duplex, mas também não requer conexão prévia com o BS.

Provavelmente, os autores tinham em mente a ausência de um modo de operação de sessão no OpenUNB - mas esse é um recurso característico de todos os protocolos LPWAN.

Para simplificar e reduzir o custo do projeto do transceptor, a transmissão e a recepção são separadas no tempo, ou seja, os dados são trocados da estação base no modo simplex (transmissão da unidade de assinante para a estação base) ou no modo half duplex (transmissão da unidade de assinante para a estação base e a subseqüente recepção no dispositivo do assinante a partir da estação base).

OA: e literalmente meia página depois, verifica-se que também existe o modo half-duplex no OpenUNB! Em geral, quero observar que existem muitas contradições internas no rascunho da norma.

A ordem de bytes no pacote é do mais antigo para o mais novo (big endian)

OA: big-endian é um tipo de arquitetura de computador com uma ordem de bytes específica em um número multibyte. Em um pacote, a ordem dos bytes é sempre a mesma - do primeiro ao último. Repito: para um rascunho de padrão nacional, um uso tão descuidado da terminologia estabelecida é inaceitável.

Os pacotes podem ter comprimentos diferentes, dependendo do tamanho da carga útil. Opções de comprimento de carga útil: 0, 64 ou 128 bits. Uma mensagem com carga útil zero pode ser usada como um sinal regular de que o dispositivo está funcionando (pulsação). Os comprimentos de pacotes de 64 e 128 bits são determinados pelo tamanho dos blocos de criptografia dos algoritmos de criptografia.

AS: Os desenvolvedores limitaram o comprimento da carga útil a 0, 64 ou 128 bits, justificando isso com a conveniência da criptografia. Essa é uma limitação completamente artificial. Às vezes, você precisa enviar mensagens muito curtas, mas precisa usar 64 bits. De que eficiência energética podemos falar depois disso! Como criptografar mensagens curtas com chaves longas pode ser lido, por exemplo, no protocolo LoRaWAN.

OA: sim, no mesmo LoRaWAN, o esquema de criptografia AES-CTR é usado regularmente, o que permite criptografar pacotes de qualquer tamanho, incluindo menor comprimento da chave.

Para alcançar uma faixa de transmissão alta na faixa não licenciada, é necessária uma alta relação sinal / ruído. Isso é alcançado devido à largura de banda de transmissão ultra pequena (da ordem de 100 Hz).

AS: no rascunho do padrão, não há sequer uma única opinião sobre a largura de banda - é "inferior a 1 kHz", depois "cerca de 100 Hz". Não foi possível chegar a uma única declaração na norma?

OA: e novamente sobre a necessidade de um alto SNR. Não não O LPWAN também é LPWAN para funcionar mesmo com um SNR negativo.

Alguns transceptores podem alterar suas propriedades bastante fortemente no início de uma transmissão. Isso pode afetar a frequência e o comprimento do sinal modulado dos primeiros bits no pacote. Para compensar esse fator, recomenda-se emitir um sinal em uma frequência de pacotes com duração igual a uma duração de transmissão de 1-2 bits antes de iniciar a transmissão do preâmbulo (Figura 2). [...] No final da transmissão, após a soma de verificação, você também deve estudar 1 bit a mais e reduzir gradualmente a amplitude do sinal, o que aumentará a probabilidade de recepção correta do último bit.

AS: As informações e os desenhos são retirados da descrição técnica do SigFox e estão conectados a alguns recursos da descrição do SigFox. O receptor corrige os bits não no momento da mudança de fase, mas antes e depois. Você não deve copiar sem pensar os recursos e erros de descrição de outras pessoas.

Valor recomendado do preâmbulo para o pacote de ligação ascendente: 10101010101010101010 ₂ . A critério dos desenvolvedores, os valores de preâmbulo para toda a rede podem ser alterados. Por exemplo, isso pode ser usado para criar várias redes em um território, cuja recepção de uma ou outra estação base será dividida com base em vários preâmbulos.

AS: Breve explicação. Os receptores de sinal UNB operam no nível do ruído do ar. Como regra, são utilizados receptores de conversão direta, após os quais são feitas FFTs. Se o sinal tiver modulação de fase, observe mais a mudança de fase para cada canal de frequência. Se uma sequência digital correspondente ao preâmbulo for encontrada em qualquer canal, será tomada uma decisão sobre a presença de um sinal útil. Ao mesmo tempo, em cada correlacionador após a FFT, uma sequência aleatória de zeros e uns está constantemente saindo do ruído do éter - isso significa que sempre há a possibilidade de obter um preâmbulo do ruído do éter. Agora vamos ver com que frequência os preâmbulos falsos de 16 bits aparecerão, por exemplo, no receptor, cuja utilização é declarada por Vaviot, os autores de um "esboço de padrão nacional" similar. A banda de recepção declarada por eles é de 200 kHz com um passo de 7 Hz na FFT, o que significa que são necessários mais de 28 mil correlacionadores. Para um acerto exato em um bit de 10 ms (velocidade de transmissão de 100 bps), os correlacionadores iniciam a cada 2,5 ms. No total, 11 milhões de correlatos devem ser verificados a cada segundo quanto à possível presença de um preâmbulo, e uma média de 178 preâmbulos falsos será derramada do ruído do éter a cada segundo . Cada preâmbulo falso precisa ser processado - e ao mesmo tempo não perder a recepção dos preâmbulos verdadeiros. Essa é uma tarefa irracionalmente redundante para um processador BS, que já funciona até o limite.

Para todos os fabricantes de sistemas UNB que eu conheço, o preâmbulo tem 32 bits e foi escolhido não por acaso, mas como resultado de cálculos e experimentos.

Além disso, o objetivo do preâmbulo não é apenas extrair um sinal útil do fluxo de ruído, mas também fornecer sincronização. Nos sistemas UNB, sequências M especiais de bits com uma função de autocorrelação pronunciada são usadas como preâmbulo . Por exemplo, se antes da sequência proposta pelos autores (101010101010101010 ₂ ), mais um par 10 _{2 for} recebido acidentalmente do ruído, o receptor determinará o início das informações úteis dois bits mais cedo e não poderá receber o pacote.

Alguns sistemas usam preâmbulos regulares, mas depois deles sempre aparece a palavra sincronização, que não é fornecida neste protocolo. Pelas mesmas razões, é incorreto usar o identificador do dispositivo como preâmbulo do downlink, conforme fornecido por este protocolo.

OA: os autores do rascunho da norma são claramente resumidos pela idéia de uma “alta relação sinal / ruído” profundamente enraizada em suas cabeças, que eles já enfatizaram várias vezes. Sim, durante experimentos no laboratório, o SNR é alto e o receptor pode trabalhar no modo "eu vejo o sinal - recebo o sinal" (e muitos produtos baratos vendidos no Aliexpress funcionam com sucesso nesse modo, fornecendo um alcance de comunicação de várias centenas de metros).

Em quaisquer condições reais, e mais ainda a distâncias declaradas de 50 km, o preâmbulo proposto simplesmente morre em ruído: um bit ruim ou ruído aleatório à sua frente será suficiente para impedir que o receptor reconheça o pacote.

AS: Sem elementos de codificação à prova de ruído, é impossível obter comunicações de alta qualidade nas condições do ruído do ar cotidiano, especialmente na faixa de frequência não licenciada, este é um "clássico do gênero". Qualquer interferência de pulso curto no canal, tocando apenas um bit em toda a sequência, e o receptor não aceita nada.

O ID do remetente é uma sequência exclusiva de 32 bits atribuída a um dispositivo durante sua produção. Informações adicionais sobre identificadores são fornecidas no Apêndice E: Formato para escrever identificadores, unidades de assinantes, cálculo de informações de controle e intervalos reservados de identificadores.

OA: o padrão, que afirma ser a base de um sistema unificado de transferência de dados em sistemas de contabilidade de recursos, não descreve as regras pelas quais os fabricantes escolhem identificadores para si mesmos - nem sequer é indicado que tais regras jamais existirão. O que isso levará? É isso mesmo, para um monte de dispositivos de diferentes fabricantes, mas com os mesmos identificadores, porque cada segundo fabricante simplesmente numerará os dispositivos do zero.

As informações de serviço consistem em 8 bits, com os 6 bits mais à esquerda reservados para uso futuro. 2 bits são reservados para o número do pacote na mensagem.

OA: uma quantidade muito estranha e muito modesta de informações gerais. Pode-se especificar o número de pacote de ponta a ponta, o tipo de criptografia, o tamanho do pacote e muito mais. Não está claro por que precisamos de um número de pacote "local" na mensagem - digamos que recebemos o número de pacote 0 e depois o número 1. Devemos descartar o segundo? E se esse já é o pacote número 1 da próxima mensagem, da qual perdemos o número 0 no ar? E se não podemos descartar pacotes com base nisso, como resolvemos o problema com o fato de o dispositivo poder transmitir 4 pacotes idênticos seguidos - aceitamos e consideramos todos eles, recebendo várias cargas duplicadas na saída?

AS: Geralmente, um preâmbulo segue um cabeçalho que indica o comprimento do pacote; este não é o caso neste protocolo. Como o receptor entende quantos bits discar? É claro que você pode verificar todos os comprimentos possíveis usando CRC, mas ninguém faz isso, é muito caro do ponto de vista do hardware do receptor.

A soma de verificação do pacote é calculada com base no algoritmo do Apêndice B: Cálculo da soma de verificação do pacote.

OA: para ser sincero, apenas fico de boca aberta. Não, geralmente não há proteção contra ataques típicos no protocolo! Com a segurança e a segurança declaradas do protocolo, o uso de cifras fortes e outros e outros, qualquer um pode pegar o pacote de outra pessoa, alterar os campos nele, substituir a carga útil de outro pacote, recalcular a soma de verificação - e transmiti-la, e a estação base aceitará e não pode de forma alguma distinguir um pacote falso de um pacote "nativo".

AS: os desenvolvedores protegem informações úteis com criptografia, mas isso claramente não é suficiente! Os desenvolvedores afirmam que estão familiarizados com os protocolos LoRaWAN e NB-FI; nesse caso, eles entenderiam por que a proteção contra repetições é necessária e por que uma inserção adicional de imitação é necessária no pacote. Por exemplo, um pacote com uma carga útil de 0 bits é absolutamente inseguro, não há problema em escrevê-lo do ar e repeti-lo, e o sistema o entenderá como seu. Também não é difícil para um invasor enviar qualquer lixo ao sistema ou repetir em nome de qualquer sensor em pacotes com comprimento diferente de zero.

O padrão a priori já se tornou protocolos de segurança da informação no LoRaWAN, que justificavam o uso de duas chaves de segurança, para a rede e para o usuário, além da capacidade de gerar chaves de sessão através do ar, aparentemente os desenvolvedores do protocolo nem pensavam nisso.

As chaves de criptografia devem ser armazenadas no dispositivo do assinante e nos servidores de rede em um armazenamento seguro. Para criptografar pacotes de uplink e downlink, diferentes chaves de criptografia devem ser usadas. Para cada dispositivo, o conjunto de chaves de criptografia deve ser exclusivo.

OA: por um lado, os desenvolvedores do OpenUNB se credenciam com "tamanhos de campo selecionados em múltiplos de 8 bits, para processamento mais eficiente em microprocessadores" (ortografia do autor), por outro lado, parece que eles simplesmente não conhecem uma técnica de otimização simétrica tão eficaz criptografia, como a capacidade de manter o dispositivo final em vez de dois procedimentos - criptografia e descriptografia - apenas um, o que reduz bastante o tamanho do firmware nos microcontroladores. Pelo menos no rascunho da norma não é mencionado.

AS: mas eles realmente conseguiram escolher o tamanho dos campos em múltiplos de 8 bits!

Enviar uma mensagem de um canal a jusante só é possível em resposta a uma mensagem de um canal a montante. Existem várias razões para isso. Em primeiro lugar, o protocolo é especializado em dispositivos de assinante que não possuem energia externa e são projetados para uma duração de bateria extra longa, o que significa que o consumo de energia desempenha um papel fundamental. Como o consumo do transmissor no modo de recebimento é bastante alto, você deve alternar para esse modo apenas por um curto período de tempo.

OA: Não entendo muito bem por que limitar conscientemente o escopo do padrão, já o faça já do que o indicado na introdução ao mesmo padrão. Um medidor elétrico doméstico comum possui energia externa? Tem. O que impede você de manter o "transmissor no modo de recebimento" ligado o tempo todo? Nada.

Em segundo lugar, não é possível selecionar um intervalo de tempo específico em um dispositivo de assinante, pois, a fim de reduzir o custo dos dispositivos de assinante, eles geralmente são equipados com osciladores de cristal instáveis ​​e não possuem um relógio em tempo real.

OA: Isso, é claro, não é assim. Primeiramente, olhando para a frente dois parágrafos, os autores já estão segurando uma enorme janela de recepção - 8 segundos (no mesmo LoRaWAN, as janelas de recepção têm 1-2 segundos de tamanho). Em segundo lugar, é suficiente calcular com que freqüência o dispositivo deve sincronizar o relógio com a estação base (e fornecer um método para essa sincronização) para que o problema da instabilidade do quartzo não seja um problema. No LoraWAN, isso é feito em dispositivos de classe B.

Em terceiro lugar, a baixa estabilidade dos osciladores de cristal nos dispositivos de assinante requer o uso do algoritmo de ajuste de frequência descrito no Apêndice D: Ajuste da frequência de transmissão no downlink. Mas, como a última mensagem do canal upstream é usada para calcular o desvio de frequência, e a frequência do oscilador de cristal pode mudar com o tempo (por exemplo, quando a temperatura muda), o tempo entre a última mensagem upstream e a jusante deve ser pequeno o suficiente para alterar o desvio de frequência no canal do assinante. dispositivo durante esse período foi insignificante.

AS: A julgar pelos detalhes da descrição, os desenvolvedores do protocolo OpenUNB consideram sua solução para o problema da sincronização de canal descendente em frequência como a conquista mais importante.

O próprio método de cálculo é bastante aceitável, mas há vários problemas:

• , , .
• .
• , 7 50 , 7 .
• , .
• .
• , , .

Realizamos os estudos apropriados e não conseguimos obter, em condições reais, uma precisão de acerto na faixa de 868 MHz acima de ± 150 Hz. Para receber um sinal de 100 Hz BPSK, é necessária uma precisão de pelo menos 30 Hz.

SigFox opera no canal de retorno com uma modulação de frequência de 600 Hz. Penso que a organização máxima possível do canal de retorno é 2GFSK com um desvio de 300 Hz e um aumento na potência do sinal a jusante para 100 mW.

Além disso, sistemas UNB com chaveamento de sinal de mudança de fase não funcionam muito bem em objetos em movimento, devido a um aumento no ruído de fase durante a propagação do sinal de caminhos múltiplos. O método proposto para determinar a frequência do sinal descendente na presença de viés Doppler dará um erro adicional na determinação da frequência portadora do canal de ligação ascendente, o que levará a um erro adicional na determinação da frequência descendente.

Talvez os autores do protocolo tenham outros dados, confirmados não "em cima da mesa", mas em condições reais, eu gostaria de ver os relatórios dos testes.

OA:Acrescento que mesmo um desvio de 30 Hz com uma faixa de 100 Hz não é a recepção ideal, mas cerca de 10% dos erros de bits (nos sistemas LPWAN isso é tradicionalmente levado para o exterior, no qual a qualidade da recepção ainda pode ser considerada aceitável). Dada a falta de codificação de ruído no OpenUNB, a probabilidade de uma mensagem da ordem de algumas centenas de bits capturar pelo menos um erro com um BER de 10% é muito alta - ou seja, especificamente no OpenUNB, eu avaliaria o desvio de frequência permitido em que algo de alguma forma às vezes, são tomadas, no máximo 5%. Em trinta vezes melhor do que é possível obter na realidade.

Em suma, há sérias dúvidas de que o método de organização de um canal de comunicação reversa descrito no rascunho da norma seja geralmente operacional em princípio.

A duração do intervalo de tempo T _dl é selecionada para ser várias vezes a duração da transmissão de um pacote de downlink. Esse aumento no tamanho da janela de tempo é necessário, pois geralmente existem muitos dispositivos por estação, o que pode levar à necessidade de enviar um pacote de downlink para vários dispositivos ao mesmo tempo.

OA: Toda mágica tem um preço, como disse o herói de uma série. No caso do planejamento de redes de rádio, esse preço deve ser calculado - ou os autores do rascunho da norma não encontraram tempo para tais cálculos (mas talvez não valesse a pena apressar-se a publicar o projeto?), Ou não pensaram em fazê-lo.

Nesse caso, como os mesmos autores observaram corretamente acima, a operação do receptor é um procedimento que consome bastante energia. Em um caso, obtemos 8 segundos de operação ociosa, no outro (quando o slot de recepção é reduzido para 1-2 segundos) - a possibilidade da estação base não responder (não havia tempo para o intervalo de tempo definido) e a necessidade de reiniciar as mensagens do receptor. Era necessário estimar pelo menos aproximadamente a carga do éter e o consumo de energia em ambos os casos, dependendo da intensidade das trocas de rádio na rede, e também fornecer uma maneira explicitamente descrita para confirmar que o receptor recebeu mensagens da estação base.

Finalmente, não está claro no texto da norma se toda a premissa a jusante deve cair em T _dl- ou o destinatário, depois de pegar o preâmbulo e seu endereço, estenderá a janela de recepção até tempo suficiente para receber todo o pacote. Como regra, nos sistemas LPWAN eles seguem o segundo caminho, novamente permitindo reduzir a duração necessária da janela de recebimento.

Em caso de recepção bem-sucedida pelo dispositivo assinante da mensagem do canal downstream, em resposta, envia uma mensagem sobre a recepção bem-sucedida no uplink. Os dados do usuário devem conter uma indicação da mensagem confirmada.

[...] Uma mensagem com carga zero pode ser usada como confirmação de que a estação base recebeu dados de uma unidade de assinante (reconhecimento).

OA: Olá novamente, segurança! Como confirmação da entrega, propõe-se enviar um pacote criptograficamente desprotegido da estação base, que qualquer um pode falsificar em meio minuto. Sem mencionar o que você tenta entender nesses dois parágrafos - o dispositivo deve enviar uma mensagem sobre sua recepção bem-sucedida ao ACK? No texto literal do rascunho da norma, verifica-se que deveria. ACK para ACK. Mas, pelo menos, não é dito em nenhum lugar que a estação base deve responder ACK por ACK em ACK - ou melhor, o rascunho da norma não diz em nenhum lugar como a BS deve entender se deve reconhecer o pacote ou não. Esta não é uma propriedade do pacote (embora com 6 bits vazios no cabeçalho, um possa ser alocado para o sinalizador de confirmação de entrega).

E o que significa "uma indicação de uma mensagem confirmada" deve ser contida? Como apontar para uma mensagem específica em um sistema no qual não é fornecida uma rotulagem individual de mensagens por um protocolo?

O padrão OpenUNB requer uma quantidade mínima de energia para enviar um pouco de informação. De acordo com os resultados de testes preliminares, agora é um dos protocolos com maior economia de energia.

AS: Uma declaração controversa e não confirmada. O protocolo contém pelo menos alguns elementos que indicam sua baixa eficiência energética:

• Uma soma de verificação excessivamente longa de 32 bits, apesar de todos os fabricantes desses sistemas custarem 16 bits de CRC.
• A restrição no comprimento da informação é apenas estritamente de 64 ou 128 bits. Se você precisar enviar uma mensagem curta de vários bits (por exemplo, de qualquer sensor binário - 1 bit), será necessário transmitir alguns bytes extras a cada vez, qual é a eficiência aqui.
• A necessidade declarada de duplicar a transmissão de uma mensagem até quatro vezes, o que altera imediatamente os parâmetros de energia em 4 vezes.
• Uma janela de 8 segundos para receber pacotes a jusante.

Eu gostaria muito de ver os relatórios de teste, existem algumas dúvidas de que eles existem.

OA: sim, é difícil entender onde Skoltech estava com tanta pressa que ele não podia compartilhar relatórios de teste e outras informações de suporte para avaliar em que desempenho real do OpenUNB se pode contar.

O OpenUNB é um padrão aberto universal, absolutamente pronto para uso prático.

AS: O texto da norma é bruto, contém descrições fragmentárias, incompletas e imprecisas de elementos perfurados individuais; seu uso na prática é impossível. Não há nada sobre as especificidades do elemento-chave dos sistemas UNB - o receptor da estação base.

OA: No geral, tenho a sensação de um bom trabalho de curso de terceiro ano escrito em uma semana ou duas. Muito bem, participei de todas as palestras, compreendi até 70% a 80%, ainda não há experiência real, mas pelo menos há um assunto para uma discussão proveitosa com o professor ao passar no teste. Antes da aplicação prática, não é como antes da lua - para aplicação prática na LPWAN, todo esse projeto terá que ser jogado fora e reescrito.