Que tipo de mensagem pode ser usado para protocolos de IoT orientados à rede celular?


14

Recentemente, isso me chamou a atenção quando encontrei um vídeo incrível no Youtube:

Micheal E. Anderson: Comparando técnicas de mensagens para a IoT, OpenIoTSummit, Linux Foundation .

Os slides da palestra estão disponíveis aqui

Nos slides 26 e 41 minutos do vídeo, ele está discutindo sobre como (deixe-me parafrasear):

As operadoras de celular preferem que seus consumidores de IoT usem mensagens do tipo HTML , XML ou JSON, pois consomem mais dados. Mais dados significa que eles podem cobrar dos consumidores mais dinheiro pelo serviço.

Eu entendo que muitos protocolos proprietários viz. SigFox , Wireless HART ou Z Wave têm taxas de dados mais baixas e o envio de dados volumosos por essas operadoras pode ser um assunto caro.

Questão

  • Existem outros formatos de mensagens leves que estão sendo usados ​​para uso em protocolos proprietários, o que os torna soluções econômicas para os consumidores atuais e futuros de IoT? (Filmado no escuro: algum formato chamado XML ou HTML leve ou JSON está em algum lugar?)

  • Talvez algo como o CBOR seja ou talvez usado?


1
Suspeito que a largura de banda de dados seja provavelmente um custo de segunda ordem e não seja realmente pago pelo desenvolvedor do aplicativo. Portanto, embora valha a pena se preocupar, mas provavelmente há mais desenvolvimento nesta área.
Sean Houlihane

1
Existe algum tipo de situação em particular em que você está interessado? Se você estiver enviando um tipo de dados previsível (por exemplo, apenas um número inteiro ou algo assim), poderá renunciar completamente a uma linguagem de marcação, mas isso limita a quantidade de informações que você pode expressar. Se você está interessado apenas em qualquer situação em que normalmente usa JSON / HTML / XML, tudo bem também.
Aurora0001

1
@ Aurora0001 Na verdade, não tenho um cenário específico, mas vale a pena pensar. Eu acho que a compatibilidade com redes baseadas na Web (dominadas por IP) que podem estar conectadas às linguagens de marcação da Cellular Networks é a melhor forma de formato de dados. Mas como o campo da IoT geralmente está decolando, pode valer a pena tentar diferentes formatos.
Shan-Desai 12/03

1
Desculpe misturar um pouco a imagem: as mensagens em qualquer rede têm várias camadas, onde a camada de dados é apenas uma em cima. Todos eles estão sob otimização, ou pelo menos poderiam estar. O 5G, por exemplo, aprimora a sinalização usada e, portanto, mais dados se encaixam.
Mico

Respostas:


6

Você está perguntando sobre o protocolo ou o formato da mensagem ? Geralmente, usamos incorretamente o termo protocolo quando entendemos o formato dos dados. Eu mesmo faço isso, geralmente porque a distinção não é clara para todos.

Os protocolos de mensagens usados ​​na IoT tendem a ser bastante compactos, pelo menos mais que o http, e oferecem recursos significativos que são importantes nas mensagens (sessões, controle de fluxo, confiabilidade, etc.). O formato da mensagem é o de dados na mensagem que é enviada. Suponho que é sobre isso que você está perguntando.

O formato de mensagem mais compacto é um formato binário enrolado à mão cuidadosamente considerado. É freqüentemente usado em cenários de baixa largura de banda quando você deseja enviar alguns bytes e sabe exatamente como eles são. Para mensagens maiores, as desvantagens são significativas e, em geral, devem ser evitadas a todo custo.

Fiz uma avaliação detalhada de muitas opções diferentes de serialização de dados. Eu esperava que o protobuf, messagepack fosse bastante compacto, o que eram. No entanto, meu segundo problema foi encontrar bibliotecas mantidas e disponíveis em várias plataformas diferentes, incluindo C no dispositivo.

O formato em que me acomodei, surpreendentemente, foi o JSON compactado com gzip. É fácil de implementar e entender, roda em qualquer lugar e, com os dados que eu estava usando, era praticamente o mesmo, ou menor, que outros métodos.

Lembre-se também de que, se você tiver um canal seguro como o TLS, consumirá uma grande quantidade de dados (> 6 KB) nos handshakes do TLS.

Há alguns anos, eu esperava que um formato como os buffers de protocolo dominasse, mas realmente não aconteceu muita coisa. Provavelmente devido à facilidade com que o json pode ser gravado e analisado (e compactado). Gosto da aparência dos Flatbuffers , mas a vantagem é mais na velocidade de análise do que em ser compacta.

Como você está na fase de investigação, sugiro que você escreva um pouco de código em cada um, usando dados típicos da sua situação, e faça algumas comparações. Ter dados concretos ao iniciar ajuda a confirmar suas escolhas.


4

A grande vantagem de um formato baseado em marcação é que você mantém a flexibilidade na escolha de quais dados você transmite. Isso é extremamente importante em um ecossistema em evolução, em que você antecipa um serviço em evolução ao longo de vários anos de desenvolvimento.

Embora uma estrutura de dados binários rigidamente codificada seja eficiente para transmitir, você precisa decidir antecipadamente, no mínimo, como será a estrutura. Quando, mais tarde, você perceber que mesmo um campo precisa de expansão, você ficará preso. Mesmo a implantação de uma atualização para o protocolo é difícil, pois você não pode obsoleta uma codificação antiga até que cada terminal seja atualizado.

Isso sugere que a abordagem ideal é misturar pacotes minimalistas e codificação baseada em marcação (usando o último como um fallback). O valor disso depende das cargas úteis de largura de banda mais altas. Se você já está transferindo trechos com tamanho de vídeo frequentes, otimizar os dados de controle pouco frequentes vale menos a pena. Se você tem pequenas transferências frequentes (talvez uma temperatura), faz sentido minimizar a sobrecarga na transmissão - mas talvez apenas a remessa das transferências seja tão boa.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.