BR112015032501B1

BR112015032501B1 - Meio legível em computador não transitório, método para enviar e receber mensagens entre dispositivos em uma rede em malha e dispositivo eletrônico

Info

Publication number: BR112015032501B1
Application number: BR112015032501-7A
Authority: BR
Inventors: Jay D. Logue; Grant M. Erickson; Zachary B. Smith; Osborne B. Hardison; Richard J. Schultz; Sunny P. Gujjaru; Matthew G. Neeley
Original assignee: Google Llc
Priority date: 2013-06-25
Filing date: 2014-06-23
Publication date: 2023-02-23
Also published as: EP3611677B1; CN110086763A; AU2014302721A1; AU2014302721B2; RU2018110075A; AU2017210654A1; KR101951785B1; US10693760B2; US20150046509A1; AU2017261508A1; MX368748B; CN114978791A; US9313280B2; RU2754308C1; JP2017108448A; JP2020102877A; KR20170014011A; AU2016203048A1; KR101847576B1; US9112790B2

Abstract

REDE EM MALHA. A presente invenção refere-se a sistemas e métodos relativos a uma comunicação em uma rede em malha que são apresentados. A rede em malha inclui uma ou mais redes lógicas que permitem que dispositivos conectado s à malha se comunique m com cada outro usando vários perfis conhecidos pelos dispositivos. Um dispositivo enviando uma mensagem pode seguir um formato de mensagem geral para a codificação da mensagem, de modo que outros dispositivos na malha possam entender a mensagem, independentemente de quais redes lógicas os dispositivos estão conectados. No formato de mensagem, uma carga útil de dados pode ser incluída para o dispositivo de recepção para encaminhar, armazenar ou process ar a mensagem. O formato e o conteúdo da carga útil pode m variar, de acordo com um cabeçalho na carga útil , que indica um perfil e um tipo de mensagem no perfil . Usando o perfil e o tipo de mensagem, os dispositivos de recepção podem de codificar a mensagem para processamento da mensagem.

Description

ANTECEDENTES

[001] A presente invenção refere-se a uma rede em malha ("fa bric network") que acopla dispositivos eletrônicos usando-se um ou mais tipos de rede.

[002] Pretende-se que esta seção introduza o leitor em vários as pectos da técnica que podem ser relacionados a vários aspectos das presentes técnicas, as quais são descritas e/ou reivindicadas abaixo. Acredita-se que esta discussão seja útil na provisão ao leitor de uma informação de antecedentes para facilitar um melhor entendimento dos vários aspectos da presente exposição. Assim sendo, deve ser entendido que estas declarações são para serem lidas nesta luz, e não como admissões da técnica anterior.

[003] Os dispositivos conectados em rede aparecem em todas as casas. Alguns destes dispositivos são frequentemente capazes de comunicação com cada outro através de um único tipo de rede (por exemplo, uma conexão WiFi) usando-se um protocolo de transferência. Pode ser desejado usar protocolos de conexão menos intensivos em potência para alguns dispositivos que são acionados à bateria ou recebem uma carga reduzida. Contudo, em alguns cenários, os dispositivos conectados a um protocolo de potência mais baixa podem não ser capazes de comunicação com dispositivos conectados a um protocolo de potência mais alta (por exemplo, WiFi).

SUMÁRIO

[004] Um sumário de certas modalidades expostas aqui é estabe lecido abaixo. Deve ser entendido que estes aspectos são apresentados meramente para a provisão ao leitor de um breve sumário destas certas modalidades e que estes aspectos não são pretendidos para limitação do escopo desta exposição. De fato, esta exposição pode envolver uma variedade de aspectos que podem não ser estabelecidos abaixo.

[005] As modalidades da presente exposição se referem a siste mas e métodos de uma rede em malha que inclui uma ou mais redes lógicas que permitem que dispositivos conectados à malha para comunicação com cada outro usando uma lista de protocolos e/ou perfis conhecidos para os dispositivos. As comunicações entre os dispositivos podem seguir um formato de mensagem típico que permite que os dispositivos entendam comunicações entre os dispositivos, independentemente de quais redes lógicas os dispositivos de comunicação estão conectados na malha. No formato de mensagem, uma carga útil de dados pode ser incluída para o dispositivo de recepção para armazenamento e/ou processamento. O formato e o conteúdo da carga útil podem variar, de acordo com um cabeçalho na carga útil, que indica um perfil (incluindo um ou mais protocolos) e/ou um tipo de mensagem que está sendo enviado de acordo com o perfil.

[006] De acordo com algumas modalidades, dois ou mais disposi tivos em uma malha podem se comunicar usando protocolos ou perfis de relatório de status. Por exemplo, em certas modalidades, um protocolo ou esquema de relatório de status pode ser incluído em um perfil de núcleo que está disponível para dispositivos conectados à malha. Usando o protocolo de relatório de status, os dispositivos podem enviar ou requisitar uma informação de status para ou a partir de outros dispositivos na malha.

[007] De modo similar, em certas modalidades, dois ou mais dis positivos em uma malha podem se comunicar usando protocolos ou perfis de software de atualização. Em algumas modalidades, um protocolo ou esquema de software de atualização pode ser incluído em um perfil de núcleo que está disponível para dispositivos conectados à malha. Usando o protocolo de software de atualização, os dispositivos podem requisitar, enviar ou notificar a presença de atualizações na malha.

[008] Em certas modalidades, dois ou mais dispositivos em uma malha podem se comunicar usando protocolos ou perfis de gerenciamento de dados. Em algumas modalidades, o protocolo ou esquema de gerenciamento de dados pode ser incluído em um perfil de núcleo que está disponível para dispositivos conectados à malha. Usando o protocolo de transferência de dados em massa, os dispositivos podem requisitar, ver ou rastrear uma informação residente em nó que é armazenada em outros dispositivos.

[009] Mais ainda, em certas modalidades, dois ou mais dispositi vos em uma malha podem transferir dados usando protocolos ou perfis de transferência de dados em massa. Em algumas modalidades, o protocolo ou esquema de transferência de dados em massa pode ser incluído em um perfil de núcleo que está disponível para dispositivos conectados à malha. Usando o protocolo de transferência de dados em massa, os dispositivos podem iniciar, enviar ou receber dados em massa usando quaisquer redes lógicas na malha. Em certas modalidades, um dispositivo de envio ou um de recebimento usando o protocolo de transferência de dados em massa pode ser capaz de "coman-dar" uma transferência síncrona entre os dispositivos. Em outras modalidades, a transferência em massa pode ser realizada com uma transferência assíncrona.

[0010] Vários refinamentos dos recursos citados acima podem existir em relação a vários aspectos da presente exposição. Outros recursos também podem ser incorporados nestes vários aspectos da mesma forma. Estes refinamentos e recursos adicionais podem existir individualmente ou em qualquer combinação. Por exemplo, vários re- cursos discutidos abaixo em relação a uma ou mais das modalidades ilustradas podem ser incorporados em qualquer um dos aspectos descritos acima da presente exposição sozinhos ou em qualquer combinação. O breve sumário apresentado acima é pretendido apenas para familiarizar o leitor com certos aspectos e contextos de modalidades da presente exposição, sem limitação para o assunto reivindicado.

BREVE DESCRIÇÃO DOS DESENHOS

[0011] Vários aspectos desta exposição podem ser mais bem en tendidos mediante uma leitura da descrição detalhada a seguir e mediante uma referência aos desenhos, nos quais:

[0012] a figura 1 é um diagrama de blocos de um dispositivo ele trônico que pode ser interconectado com outros dispositivos usando uma rede em malha, de acordo com uma modalidade;

[0013] a figura 2 ilustra um diagrama de blocos de um ambiente doméstico no qual o dispositivo geral da figura 1 pode se comunicar com outros dispositivos através da rede em malha, de acordo com uma modalidade;

[0014] a figura 3 ilustra um diagrama de blocos de um modelo de interconexão de sistemas abertos (OSI) que caracteriza um sistema de comunicação para o ambiente doméstico da figura 2, de acordo com uma modalidade;

[0015] a figura 4 ilustra a rede em malha tendo uma única topolo gia de rede lógica, de acordo com uma modalidade;

[0016] a figura 5 ilustra a rede em malha tendo uma topologia de rede em estrela, de acordo com uma modalidade;

[0017] a figura 6 ilustra a rede em malha tendo uma topologia de redes com superposição, de acordo com uma modalidade;

[0018] a figura 7 ilustra um serviço em comunicação com uma ou mais malhas de rede, de acordo com uma modalidade;

[0019] a figura 8 ilustra dois dispositivos em uma rede em malha em conexão comunicativa, de acordo com uma modalidade;

[0020] a figura 9 ilustra um formato de endereço local único (ULA) que pode ser usada para endereçar dispositivos em uma rede em malha, de acordo com uma modalidade;

[0021] a figura 10 ilustra um processo para criação de proxy de dispositivos periféricos em uma rede com hub, de acordo com uma modalidade;

[0022] a figura 11 ilustra um pacote de etiqueta - comprimento - valor (TLV) que pode ser usado para a transmissão de dados pela rede em malha, de acordo com uma modalidade;

[0023] a figura 12 ilustra um protocolo de mensagem geral (GMP) que pode ser usado para a transmissão de dados pela rede em malha que podem incluir o pacote de TLV da figura 11, de acordo com uma modalidade;

[0024] a figura 13 ilustra um campo de cabeçalho de mensagem do GMP da figura 12, de acordo com uma modalidade;

[0025] a figura 14 ilustra um campo de identificador de chave do GMP da figura 12, de acordo com uma modalidade;

[0026] a figura 15 ilustra um campo de carga útil de aplicativo do GMP da figura 12, de acordo com uma modalidade;

[0027] a figura 16 ilustra um esquema de relatório de status que pode ser usado para a atualização de uma informação de status na rede em malha, de acordo com uma modalidade;

[0028] a figura 17 ilustra um campo de perfil do esquema de rela tório de status da figura 16, de acordo com uma modalidade;

[0029] a figura 18 ilustra uma sequência de protocolo que pode ser usada para a execução de uma atualização de software entre um cliente e um servidor, de acordo com uma modalidade;

[0030] a figura 19 ilustra um quadro de consulta de imagem que pode ser usado na sequência de protocolo da figura 18, de acordo com uma modalidade;

[0031] a figura 20 ilustra um campo de controle de quadro do qua dro de consulta de imagem da figura 19, de acordo com uma modalidade;

[0032] a figura 21 ilustra um campo de especificação de produto do quadro de consulta de imagem da figura 19, de acordo com uma modalidade;

[0033] a figura 22 ilustra um campo de especificação de versão do quadro de consulta de imagem da figura 19, de acordo com uma modalidade;

[0034] a figura 23 ilustra um campo de especificação de local do quadro de consulta de imagem da figura 19, de acordo com uma modalidade;

[0035] a figura 24 ilustra um campo de tipos de integridade supor tados do quadro de consulta de imagem da figura 19, de acordo com uma modalidade;

[0036] a figura 25 ilustra um campo de esquemas de atualização suportados do quadro de consulta de imagem da figura 19, de acordo com uma modalidade;

[0037] a figura 26 ilustra um quadro de resposta de consulta de imagem que pode ser usado na sequência de protocolo da figura 18, de acordo com uma modalidade;

[0038] a figura 27 ilustra um campo de identificador de recurso uni forme (URI) do quadro de resposta de consulta de imagem da figura 26, de acordo com uma modalidade;

[0039] a figura 28 ilustra um campo de especificação de integrida de do quadro de resposta de consulta de imagem da figura 26, de acordo com uma modalidade;

[0040] a figura 29 ilustra um campo de esquema de atualização do quadro de resposta de consulta de imagem da figura 26, de acordo com uma modalidade;

[0041] a figura 30 ilustra uma sequência usada para empregar um protocolo de gerenciamento de dados para gerenciamento de dados entre dispositivos na rede em malha, de acordo com uma modalidade;

[0042] a figura 31 ilustra um quadro de requisição de instantâneo que pode ser usado na sequência da figura 30, de acordo com uma modalidade;

[0043] a figura 32 ilustra um esquema de perfil de exemplo que pode ser acessado usando-se o quadro de requisição de instantâneo da figura 31, de acordo com uma modalidade;

[0044] a figura 33 é um formato binário de um percurso que pode indicar um percurso em um esquema de perfil, de acordo com uma modalidade;

[0045] a figura 34 ilustra um quadro de requisição de assistência que pode ser usado na sequência da figura 30, de acordo com uma modalidade;

[0046] a figura 35 ilustra um quadro de requisição de atualização periódica que pode ser usado na sequência da figura 30, de acordo com uma modalidade;

[0047] a figura 36 ilustra um quadro de requisição de renovação que pode ser usado na sequência da figura 30, de acordo com uma modalidade;

[0048] a figura 37 ilustra uma requisição de cancelamento de visu alização que pode ser usada na sequência da figura 30, de acordo com uma modalidade;

[0049] a figura 38 ilustra um quadro de resposta de visualização que pode ser usado na sequência da figura 30, de acordo com uma modalidade;

[0050] a figura 39 ilustra um quadro de requisição de atualização explícita que pode ser usado na sequência da figura 30, de acordo com uma modalidade;

[0051] a figura 40 ilustra um quadro de requisição de atualização de visualização que pode ser usado na sequência da figura 30, de acordo com uma modalidade;

[0052] a figura 41 ilustra um quadro de item de atualização que pode ser atualizado usando-se a sequência da figura 30, de acordo com uma modalidade;

[0053] a figura 42 ilustra um quadro de resposta de atualização que pode ser enviado como uma mensagem de resposta de atualização na sequência da figura 30, de acordo com uma modalidade;

[0054] a figura 43 ilustra uma conexão comunicativa entre um emissor e um receptor em uma transferência de dados em massa, de acordo com uma modalidade;

[0055] a figura 44 ilustra uma mensagem SendInit que pode ser usada para se iniciar uma conexão comunicativa pelo emissor da figura 43, de acordo com uma modalidade;

[0056] a figura 45 ilustra um campo de controle de transferência da mensagem SendInit da figura 44, de acordo com uma modalidade;

[0057] a figura 46 ilustra um campo de controle de faixa da men sagem SendInit da figura 45, de acordo com uma modalidade;

[0058] a figura 47 ilustra uma mensagem SendAccept que pode ser usada para aceitação de uma conexão comunicativa proposta pela mensagem SendInit da figura 44 enviada pelo emissor da figura 44, de acordo com uma modalidade;

[0059] a figura 48 ilustra uma mensagem SendReject que pode ser usada para se rejeitar uma conexão comunicativa proposta pela mensagem SendInit da figura 44 enviada pelo emissor da figura 44, de acordo com uma modalidade; e

[0060] a figura 49 ilustra uma mensagem ReceiveAccept que pode ser usada para se aceitar uma conexão comunicativa proposta pelo receptor da figura 44, de acordo com uma modalidade.

DESCRIÇÃO DETALHADA

[0061] Uma ou mais modalidades específicas da presente exposi ção serão descritas abaixo. Estas modalidades descritas são apenas exemplos as técnicas presentemente expostas. Adicionalmente, em um esforço para a provisão de uma descrição concisa destas modalidades, todos os recursos de uma implementação real podem não ser descritos no relatório descritivo. Deve ser apreciado que no desenvolvimento de uma implementação real como essa, como em qualquer projeto de engenharia ou de design, numerosas decisões específicas de implementação devem ser feitas para a obtenção das metas específicas dos desenvolvedores, tal como uma conformidade com restrições relacionadas ao sistema e relacionadas ao negócio, o que pode variar de uma implementação para uma outra. Mais ainda, deve ser apreciado que um esforço de desenvolvimento como esse poderia ser complexo e consumir tempo, mas, não obstante, pode ser uma tarefa de rotina de projeto, fabricação e manufatura para aqueles de conhecimento comum tendo o benefício desta exposição.

[0062] Quando da introdução de elementos de várias modalidades da presente exposição, pretende-se que os artigos "um", "uma" e "o(a)" signifiquem que há um ou mais dos elementos. Os termos "compreendendo", "incluindo" e "tendo" são pretendidos para serem inclusivos e significam que pode haver outros elementos adicionais, além dos elementos listados. Adicionalmente, deve ser entendido que referências a "uma modalidade" ou "modalidade" da presente exposição não são pretendidas para serem interpretadas como excluindo a existência de modalidades adicionais que também incorporam os recursos recitados.

[0063] As modalidades da presente exposição se referem geral mente a uma rede em malha eficiente que pode ser usada por disposi- tivos e/ou serviços em comunicação com cada outro em um ambiente doméstico. Geralmente, os consumidores vivendo em casas podem achar útil coordenar as operações de vários dispositivos na sua casa, de modo que todos os seus dispositivos sejam operados eficientemente. Por exemplo, um dispositivo de termostato pode ser usado para a detecção de uma temperatura de uma casa e coordenar a atividade de outros dispositivos (por exemplo, luzes) com base na temperatura detectada. Neste exemplo, o dispositivo de termostato pode detectar uma temperatura que pode indicar que a temperatura fora da casa corresponde às horas de luz diurna. O dispositivo de termostato então pode levar para o dispositivo de iluminação que pode haver luz diurna para a casa e que assim, a luz deve ser desligada.

[0064] Além da operação destes dispositivos eficientemente, os consumidores geralmente preferem usar dispositivos amigáveis para o usuário que envolvem uma quantidade mínima de configuração ou inicialização. Isto é, os consumidores geralmente preferem comprar dispositivos que estejam plenamente operacionais após a execução de unas poucas etapas de inicialização que podem ser realizadas por quase qualquer indivíduo, independentemente da idade ou da experiência técnica.

[0065] Com o precedente em mente, para se permitir efetivamente comunicar dados entre cada outro no ambiente doméstico, os dispositivos podem usar uma rede em malha que inclui uma ou mais redes lógicas para gerenciamento da comunicação entre os dispositivos. Isto é, a rede em malha eficiente pode permitir que numerosos dispositivos em uma casa se comuniquem com cada outro usando uma ou mais redes lógicas. A rede de comunicação pode suportar uma comunicação de versão 6 de Protocolo de Internet (IPv6), de modo que cada dispositivo conectado possa ter um endereço local único (LA). Mais ainda, para se permitir que cada dispositivo se integre com uma casa, pode ser útil que cada dispositivo se comunique na rede usando quantidades baixas de potência. Isto é, ao permitir que dispositivos se comuniquem usando potência baixa, os dispositivos podem ser postos em qualquer lugar em uma casa, sem serem acoplados a uma fonte de potência contínua (por exemplo, acionados por bateria).

I. Introdução de Malha

[0066] A título de introdução, a figura 1 ilustra um exemplo de um dispositivo geral 10 que pode se comunicar com outros dispositivos em um ambiente doméstico. Em uma modalidade, o dispositivo 10 pode incluir um ou mais sensores 12, um componente de interface de usuário 14, um suprimento de potência 16 (por exemplo, incluindo uma conexão de potência e/ou uma bateria), uma interface de rede 18, um processador 20 e similares. Os sensores 12, os componentes de interface de usuário 14 e as configurações de suprimento de potência podem ser as mesmas ou similares com cada dispositivo 10. Contudo, deve ser notado que, em algumas modalidades, cada dispositivo 10 pode incluir sensores em particular 12, componentes de interface de usuário 14, configurações de suprimento de potência e similares com base em um tipo ou modelo de dispositivo.

[0067] Os sensores 12, em certas modalidades, podem detectar várias propriedades, tais como aceleração, temperatura, umidade, água, potência suprida, proximidade, movimento externo, movimento de dispositivo, sinais de som, sinais de ultrassom, sinais de luz, fogo, fumaça, monóxido de carbono, sinais de satélite de posicionamento global (GPS), frequência de rádio (RF), outros sinais ou campos eletromagnéticos, ou similares. Como tal, os sensores 12 podem incluir sensor(es) de temperatura, sensor(es) de umidade, sensor(es) relaci- onado(s) a risco ou outro(s) sensor(es) ambiental(is), acelerômetro(s), microfone(s), sensores óticos até e incluindo câmera(s) (por exemplo, um dispositivo de carga acoplada ou câmeras de vídeo), sensores de radiação ativa ou passiva, receptor(es) de GPS ou detector(es) de identificação de frequência de rádio. Embora a figura 1 ilustre uma modalidade com um sensor único, muitas modalidades podem incluir múltiplos sensores. Em alguns casos, o dispositivo 10 pode incluir um ou mais sensores primários e um ou mais sensores secundários. Aqui, o(s) sensor(es) primário(s) pode(m) detectar dados centrais para a operação de núcleo do dispositivo (por exemplo, detectar uma temperatura em um termostato ou detectar fumaça em um detector de fumaça), enquanto o(s) sensor(es) secundário(s) pode(m) detectar outros tipos de dados (por exemplo, movimento, luz ou som), os quais podem ser usados para objetivos de eficiência de energia ou objetivos de ope-ração inteligente.

[0068] Um ou mais componentes de interface de usuário 14 no dispositivo 10 podem receber uma entrada a partir do usuário e/ou apresentar uma informação para o usuário. O componente de interface de usuário 14 também pode incluir um ou mais componentes de entrada de usuário que podem receber uma informação a partir do usuário. A entrada recebida pode ser usada para a determinação de uma regu- lagem. Em certas modalidades, os componentes de entrada de usuário podem incluir um componente mecânico ou virtual que responde ao movimento do usuário. Por exemplo, o usuário pode mover mecanicamente um componente deslizante (por exemplo, ao longo de um trilho vertical ou horizontal) ou rodar um anel rotativo (por exemplo, ao longo de um trilho circular), o movimento de usuário ao longo de um touchpad pode ser detectado, e/ou movimentos / gestos podem ser detectados usando-se um sensor de detecção de gesto sem contato (por exemplo, um sensor de infravermelho ou câmera). Esses movimentos podem corresponder a um ajuste de regulagem, o qual pode ser determinado com base em uma posição absoluta de um componente de interface de usuário 104 ou com base em um deslocamento de um componente de interface de usuário 104 (por exemplo, ajuste de uma temperatura de ponto de regulagem por um grau F para cada rotação de 10° de um componente de anel rotativo). Os componentes de entrada de usuário móveis física ou virtualmente podem permitir que um usuário faça uma regulagem ao longo de uma porção de um contínuo aparente. Assim, o usuário pode não ser confinado a escolher entre duas opções discretas (por exemplo, conforme seria o caso se botões de para cima e para baixo fossem usados), mas pode definir de forma rápida e intuitiva uma regulagem ao longo de uma faixa de valores de regulagem possíveis. Por exemplo, uma magnitude de um movimento de um componente de entrada de usuário pode ser associada a uma magnitude de um ajuste de regulagem, de modo que um usuário possa alterar dramaticamente uma regulagem com um movimento grande ou sintonizar de forma fina uma regulagem com um movimento pequeno.

[0069] Os componentes de interface de usuário 14 também podem incluir um ou mais botões (por exemplo, botões de para cima e para baixo), um teclado, um teclado numérico, um comutador, um microfone e/ou uma câmera (por exemplo, para a detecção de gestos). Em uma modalidade, o componente de interface de usuário 14 pode incluir um componente de anel anular de clicar e rodar que pode permitir que o usuário interaja com o componente pela rotação do anel (por exemplo, para ajuste de uma regulagem) e/ou ao clicar no anel para dentro (por exemplo, para selecionar uma regulagem ajustada ou para selecionar uma opção). Em uma outra modalidade, o componente de interface de usuário 14 pode incluir uma câmera que pode detectar gestos (por exemplo, para indicar que uma potência ou um estado de alarme de um dispositivo é para ser mudado). Em alguns casos, o dispositivo 10 pode ter um componente de entrada primário, o qual pode ser usado para a regulagem de vários tipos de regulagens. Os componentes de interface de usuário 14 também podem ser configurados para apresentarem uma informação para um usuário, por exemplo, através de um visor (por exemplo, um visor de transistor de filme fino ou um visor de diodo de emissão de luz orgânico) e/ou um alto-falante de áudio.

[0070] O componente de suprimento de potência 16 pode incluir uma conexão de potência e/ou uma bateria local. Por exemplo, a conexão de potência pode conectar o dispositivo 10 a uma fonte de potência, tal como uma fonte de voltagem em linha. Em alguns casos, uma fonte de potência AC pode ser usada para repetidamente carregar uma bateria local (por exemplo, recarregável), de modo que a bateria possa ser usada para suprimento de potência para o dispositivo 10, quando a fonte de potência AC não estiver disponível. Em certas modalidades, o componente de suprimento de potência 16 pode incluir conexões de potência intermitentes ou reduzidas, que podem ser menores do que aquilo provido através de um plugue AC na casa. Em certas modalidades, os dispositivos com baterias e/ou potência intermitente ou reduzida podem ser operados como "dispositivos em espera" que alternam entre um estado ligado / ativado e um estado desligado / inativo para redução do consumo de potência.

[0071] A interface de rede 18 pode incluir um ou mais componen tes que permitem que o dispositivo 10 se comunique entre dispositivos usando uma ou mais redes lógicas na rede em malha. Em uma modalidade, a interface de rede 18 pode se comunicar usando uma camada de rede eficiente como parte de seu modelo de interconexão de sistemas abertos (OSI). Em certas modalidades, um componente da interface de rede 18 pode se comunicar com uma rede lógica (por exemplo, WiFi) e um outro componente da interface de rede pode se comunicar com uma outra rede lógica (por exemplo, 802.15.4). Em outras palavras, a interface de rede 18 pode permitir que o dispositivo 10 se comunique de forma sem fio através de múltiplas redes de IPv6. Como tal, a interface de rede 18 pode incluir uma placa sem fio, uma porta de Ethernet e/ou outras conexões de transceptor adequadas.

[0072] O processador 20 pode suportar uma ou mais de uma vari edade de funcionalidades de dispositivo diferentes. Como tal, o processador 20 pode incluir um ou mais processadores configurados e programados para a realização e/ou para se fazer com que sejam realizadas uma ou mais das funcionalidades descritas aqui. Em uma modalidade, o processador 20 pode incluir processadores de finalidade geral executando um código de computador armazenado em uma memória local (por exemplo, uma memória flash, um disco rígido, uma memória de acesso randômico), processadores de finalidade especial ou circuitos integrados específicos de aplicação, outros tipos de plataformas de processamento de hardware / firmware / software, e/ou alguma combinação dos mesmos. Ainda, o processador 20 pode ser implementado como versões localizadas ou contrapartes de algoritmos executados ou governados remotamente pelos servidores centrais ou sistemas baseados em nuvem, tal como em virtude de uma máquina virtual Java (JVM) que executa instruções providas a partir de um servidor de nuvem usando Javascript Assíncrono e XML (AJAX) ou protocolos similares. A título de exemplo, o processador 20 pode detectar quando uma localização (por exemplo, uma casa ou um cômodo) está ocupada, até e incluindo se está ocupada por uma pessoa específica ou está ocupado por um número específico de pessoas (por exemplo, em relação a um ou mais limites). Em uma modalidade, esta detecção pode ocorrer, por exemplo, pela análise de sinais de microfone, pela detecção de movimentos de usuário (por exemplo, na frente de um dispositivo), detecção de aberturas e fechamentos de portas ou portões de garagem, detecção de sinais sem fio, detecção de um endereço de IP de um sinal recebido, detecção de uma operação de um ou mais dispositivos em uma janela de tempo, ou similar. Mais ainda, o processador 20 pode incluir uma tecnologia de reconhecimento de imagem para a identificação de ocupantes ou objetos em particular.

[0073] Em alguns casos, o processador 20 pode predizer regula- gens desejáveis e/ou implementar aquelas regulagens. Por exemplo, com base em detecção de presença, o processador 20 pode ajustar as regulagens de dispositivo, por exemplo, para conservar potência quando ninguém estiver em casa ou em um cômodo em particular e estar de acordo com preferências de usuário (por exemplo, preferências gerais em casa ou preferências específicas de usuário). Como um outro exemplo, com base na detecção de uma pessoa em particular, um animal ou um objeto (por exemplo, uma criança, um animal de estimação ou um objeto perdido), o processador 20 pode iniciar um indicador de áudio ou visual de onde a pessoa, o animal ou o objeto está, ou pode iniciar um alarme ou um recurso de segurança, se uma pessoa não reconhecida for detectada sob certas condições (por exemplo, à noite ou quando as luzes estiverem desligadas).

[0074] Em alguns casos, os dispositivos podem interagir com cada outro, de modo que eventos detectados por um primeiro dispositivo influenciem as ações de um segundo dispositivo usando um ou mais perfis comuns entre os dispositivos. Por exemplo, um primeiro dispositivo pode detectar que um usuário entrou em uma garagem (por exemplo, pela detecção de um movimento na garagem, detecção de uma mudança na luz na garagem ou detecção de abertura do portão de garagem). O primeiro dispositivo pode transmitir esta informação para um segundo dispositivo através da rede em malha, de modo que o segundo dispositivo possa ajustar, por exemplo, uma regulagem de temperatura doméstica, uma regulagem de luz, uma regulagem de música e/ou uma regulagem de alarme de segurança. Como um outro exemplo, um primeiro dispositivo pode detectar um usuário se aproximando da porta dianteira (por exemplo, pela detecção de um movi- mento ou de mudanças súbitas no padrão de luz). O primeiro dispositivo pode fazer com que um sinal de áudio ou visual geral seja apresentado (por exemplo, tal como soar de uma campainha de porta) ou fazer com que um sinal de áudio ou visual específico de localização seja apresentado (por exemplo, para anunciar a presença do visitante em um cômodo que um usuário esteja ocupando).

[0075] Com o precedente em mente, a figura 2 ilustra um diagra ma de blocos de um ambiente doméstico 30 no qual o dispositivo 10 da figura 1 pode se comunicar com outros dispositivos através da rede em malha. O ambiente doméstico descrito 30 pode incluir uma malha 32, tal como uma casa, um prédio comercial, uma garagem ou um trailer de residência. Será apreciado que os dispositivos também podem ser integrados em um ambiente doméstico que não inclua uma malha 32 inteira, tal como um apartamento, um condomínio, um espaço de escritório ou similar. Ainda, o ambiente doméstico 30 pode controlar e/ou ser acoplado a dispositivos fora da malha real 32. De fato, vários dispositivos no ambiente doméstico 30 não precisam estar fisicamente na malha 32 de forma alguma. Por exemplo, um dispositivo controlando um aquecedor de piscina 34 ou um sistema de irrigação 36 pode estar localizado fora da malha 32.

[0076] A malha 32 descrita inclui múltiplos cômodos 38 separados pelo menos parcialmente de cada outro através das paredes 40. As paredes 40 podem incluir paredes internas ou paredes externas. Cada cômodo 38 ainda pode incluir um piso 42 e um teto 44. Os dispositivos podem ser montados em integrados com e/ou suportados pela parede 40, pelo piso 42 ou pelo teto 44.

[0077] O ambiente doméstico 30 pode incluir múltiplos dispositi vos, incluindo dispositivos inteligentes, de detecção múltipla, conectados em rede que podem integrar sem emendas com cada outro e/ou com sistemas de servidor baseados em nuvem para a provisão de qualquer um de uma variedade de objetivos domésticos úteis. Um, mais ou cada um dos dispositivos ilustrados no ambiente doméstico 30 podem incluir um ou mais sensores 12, uma interface de usuário 14, um suprimento de potência 16, uma interface de rede 18, um processador 20 e similares.

[0078] Os dispositivos 10 de exemplo podem incluir um termostato conectado em rede 46 que pode detectar características climáticas do ambiente (por exemplo, temperatura e/ou umidade) e controlar um sistema de aquecimento, ventilação e condicionamento de ar (HVAC) 48. Um outro dispositivo 10 de exemplo pode incluir uma unidade de detecção de risco 50 que pode detectar a presença de uma substância perigosa e/ou uma condição de risco no ambiente doméstico 30 (por exemplo, fumaça, fogo ou monóxido de carbono). Adicionalmente, dispositivos de interface de porta de entrada 52, os quais podem ser denominados uma "campainha de porta inteligente", podem detectar a aproximação de uma pessoa ou a partida de uma localização, controlar uma funcionalidade audível, anunciar a aproximação ou a partida de uma pessoa através de meios de áudio ou visuais, ou controlar as regulagens em um sistema de segurança (por exemplo, para ativação ou desativação do sistema de segurança).

[0079] Em certas modalidades, o dispositivo 10 pode incluir um comutador de luz 54 que pode detectar condições de iluminação do ambiente, detectar estados de ocupação de cômodo, e controlar uma potência e/ou um estado de regulagem de intensidade de uma ou mais luzes. Em alguns casos, os comutadores de luz 54 podem controlar um estado de potência ou uma velocidade de um ventilador, tal como um ventilador de teto.

[0080] Adicionalmente, as interfaces de plugue de parede 56 po dem detectar a ocupação de um cômodo ou encerrar e controlar o suprimento de potência para um ou mais plugues de parede (por exem- plo, de modo que a potência não seja suprida para o plugue se ninguém estiver em casa). O dispositivo 10 no ambiente doméstico 30 ainda pode incluir uma aparelhagem 58, tais como refrigeradores, fogões e/ou fornos, televisores, lavadoras, secadoras, luzes (dentro e/ou fora da malha 32), estéreos, sistemas de intercomunicação, controles de abertura de portão de garagem, ventiladores de piso, ventiladores de teto, ventiladores de casa inteira, condicionadores de ar de parede, aquecedores de piscina 34, sistemas de irrigação 36, sistemas de segurança e assim por diante. Embora as descrições da figura 2 possam identificar sensores específicos e funcionalidades associadas a dispositivos específicos, será apreciado que qualquer um de uma variedade de sensores e funcionalidades (tais como aquelas descritas por todo o relatório descritivo) pode ser integrado no dispositivo 10.

[0081] Além de conter capacidades de processamento e detecção, cada um dos dispositivos de exemplo descritos acima pode ser capaz de comunicações de dados e compartilhamento de informação com qualquer outro dispositivo, bem como com qualquer servidor de nuvem ou qualquer outro dispositivo que seja conectado em rede em qualquer lugar no mundo. Em uma modalidade, os dispositivos 10 podem enviar e receber comunicações através de uma rede em malha discutida abaixo. Em uma modalidade, a malha pode permitir que os dispositivos 10 se comuniquem com cada outro através de uma ou mais redes lógicas. Como tal, certos dispositivos podem servir como repetidoras sem fio e/ou podem funcionar como pontes entre dispositivos, serviços e/ou redes lógicas no ambiente doméstico que podem não estar diretamente conectados (isto é, um salto) a cada outro.

[0082] Em uma modalidade, um roteador sem fio 60 pode se co municar adicionalmente com os dispositivos 10 no ambiente doméstico 30 através de uma ou mais redes lógicas (por exemplo, WiFi). O roteador sem fio 60 então pode se comunicar com a Internet 62 ou outra rede, de modo que cada dispositivo 10 possa se comunicar com um serviço remoto ou um sistema de computação em nuvem 64 através da Internet 62. O sistema de computação em nuvem 64 pode ser associado a um fabricante, uma entidade de suporte ou um provedor de serviços associado a um dispositivo 10 em particular. Como tal, em uma modalidade, um usuário pode contatar um suporte ao consumidor usando um dispositivo em si, ao invés de usar algum outro meio de comunicação, tal como o telefone ou um computador conectado à Internet. Ainda, as atualizações de software podem ser automaticamente enviadas a partir do atuador linear 64 ou de dispositivos no ambiente doméstico 30 para outros dispositivos na malha (por exemplo, quando disponível, quando comprado, quando requisitado, ou em intervalos de rotina).

[0083] Em virtude da conectividade de rede, um ou mais dos dis positivos 10 ainda pode permitir que um usuário interaja com o dispositivo, mesmo se o usuário não estiver próximo do dispositivo. Por exemplo, um usuário pode se comunicar com um dispositivo usando um computador (por exemplo, um computador de mesa, um computador laptop ou um tablet) ou outro dispositivo eletrônico portátil (por exemplo, um smartphone) 66. Uma página da web ou um aplicativo pode receber as comunicações a partir do usuário e controlar o dispositivo 10, com base nas comunicações recebidas. Mais ainda, a página da web ou o aplicativo podem apresentar uma informação sobre a operação do dispositivo para o usuário. Por exemplo, o usuário pode ver uma temperatura de ponto de regulagem atual para um dispositivo e ajustá-lo usando um computador que pode ser conectado à Internet 62. Neste exemplo, o termostato 46 pode receber a requisição de visualização de temperatura de ponto de regulagem atual através da rede em malha via uma ou mais redes lógicas subjacentes.

[0084] Em certas modalidades, o ambiente doméstico 30 também pode incluir uma variedade de aparelhagens de legado não de comunicação 68, tais como lavadoras / secadoras convencionais antigas, refrigeradores e similares, os quais podem ser controlados, embora grosseiramente (LIGA / DESLIGA), em virtude das interfaces de plu- gue de parede 56. O ambiente doméstico 30 ainda pode incluir uma variedade de aparelhagens de legado parcialmente de comunicação 70, tais como condicionadores de ar de parede controlados por infravermelho (IR) ou outros dispositivos controlados por IR, os quais podem ser controlados por sinais de IR providos pelas unidades de detecção de risco 50 ou pelos comutadores de luz 54.

[0085] Conforme mencionado acima, cada um dos dispositivos de exemplo 10 descritos acima pode formar uma porção de uma rede em malha. Geralmente, a rede em malha pode ser parte de um modelo de interconexão de sistemas abertos (OSI) 90, conforme descrito na figura 4. O modelo de OSI 90 ilustra funções de um sistema de comunicação com respeito a camadas de abstração. Isto é, o modelo de OSI pode especificar uma malha de formação de rede ou como as comunicações entre os dispositivos podem ser implementadas. Em uma modalidade, o modelo de OSI pode incluir seis camadas: uma camada física 92, uma camada de enlace de dados 94, uma camada de rede 96, uma camada de transporte 98, um nível de plataforma 100 e um nível de aplicativo 102. Geralmente, cada camada no modelo de OSI 90 pode servir à camada acima dela e pode ser servida pela camada abaixo dela.

[0086] Tendo isso em mente, a camada física 92 pode prover es pecificações de hardware para dispositivos que podem se comunicar com cada outro. Como tal, a camada física 92 pode estabelecer como os dispositivos podem se comunicar com cada outro, ajudar no gerenciamento de como os recursos de comunicação podem ser compartilhados entre os dispositivos e similares.

[0087] A camada de enlace de dados 94 pode especificar como os dados podem ser transferidos entre os dispositivos. Geralmente, a camada de enlace de dados 94 pode prover uma forma pela qual os pacotes de dados sendo transmitidos podem ser codificados e decodificados em bits como parte de um protocolo de transmissão.

[0088] A camada de rede 96 pode especificar como os dados sen do transferidos para um nó de destino são roteados. A camada de rede 96 também pode prover um protocolo de segurança que pode manter a integridade dos dados sendo transferidos. A camada de rede eficiente discutida acima corresponde à camada de rede 96. Em certas modalidades, a camada de rede 96 pode ser completamente independente do nível de plataforma 100 e incluir qualquer tipo de rede de IPv6 adequada (por exemplo, WiFi, Ethernet, HomePlug, 802.15.4, etc.).

[0089] A camada de transporte 98 pode especificar uma transfe rência transparente dos dados a partir de um nó de fonte para um nó de destino. A camada de transporte 98 também pode controlar como a transferência transparente dos dados permanece confiável. Como tal, a camada de transporte 98 pode ser usada para se verificar que pacotes de dados pretendidos para a transferência para o nó de destino de fato atingiu o nó de destino. Os protocolos de exemplo que podem ser empregados na camada de transporte 98 podem incluir um protocolo de controle de transmissão (TCP) e protocolo de datagrama de usuário (UDP).

[0090] O nível de plataforma 100 inclui a rede em malha e estabe lece conexões entre os dispositivos de acordo com o protocolo especificado na camada de transporte 98, e pode ser agnóstica quanto ao tipo de rede usado na camada de rede 96. O nível de plataforma 100 também pode traduzir os pacotes de dados para uma forma que o nível de aplicativo 102 possa usar. O nível de aplicativo 102 pode supor- tar um aplicativo de software que pode ter uma interface diretamente com o usuário. Como tal, o nível de aplicativo 102 pode implementar protocolos definidos pelo aplicativo de software. Por exemplo, o aplicativo de software pode prover serviços tais como transferências de arquivo, correio eletrônico e similares.

II. Interconexão de Dispositivo de Malha

[0091] Conforme discutido acima, uma malha pode ser implemen tada usando-se um ou mais protocolos de comunicações adequados, tais como protocolos IPv6. De fato, a malha pode ser parcial ou completamente agnóstica quanto às tecnologias subjacentes (por exemplo, tipos de rede ou protocolos de comunicação) usadas para a implementação da malha. Em um ou mais protocolos de comunicações, a malha pode ser implementada usando-se um ou mais tipos de rede para acoplamento de forma comunicativa de dispositivos elétricos usando conexões sem fio ou com fio. Por exemplo, certas modalidades da malha podem incluir Ethernet, WiFi, 802.15.4, ZigBee®, ISA100.11a, WirelessHART, MiWi™, redes de linha de potência, e/ou outros tipos de redes adequados. Nos dispositivos de malha (por exemplo, nós), podem trocar pacotes de informação com outros dispositivos (por exemplo, nós) na malha, diretamente ou através de nós intermediários, tais como termostatos inteligentes, atuando como roteadores de IP. Estes nós podem incluir dispositivos de fabricante (por exemplo, termostatos e detectores de fumaça) e/ou dispositivos de consumidor (por exemplo, telefones, tablets, computadores, etc.). Adicionalmente, alguns dispositivos podem estar "sempre ligados" e ser acionados continuamente usando-se conexões elétricas. Outros dispositivos podem ter o uso de potência parcialmente reduzido (por exemplo, um ciclo de carga média) usando uma conexão de potência reduzida / intermitente, tal como um termostato ou uma conexão de potência de campainha de porta. Finalmente, alguns dispositivos po- dem ter um ciclo de carga curto e rodar unicamente com potência de bateria. Em outras palavras, em certas modalidades, a malha pode incluir dispositivos heterogêneos que podem ser conectados a uma ou mais sub-redes de acordo com um tipo de conexão e/ou um uso de potência desejado. As figuras A-C ilustram três modalidades que podem ser usadas par conexão de dispositivos elétricos através de uma ou mais sub-redes na malha.

A. Topologia de Rede Única

[0092] A figura 4 ilustra uma modalidade da malha 1000 tendo uma única topologia de rede. Conforme ilustrado, a malha 1000 inclui uma rede lógica única 1002. A rede 1002 poderia incluir redes de Ethernet, WiFi, 802.15.4, de linha de potência e/ou outros tipos de rede adequados nos protocolos de IPv6. De fato, em algumas modalidades em que a rede 1002 inclui uma rede de WiFi ou Ethernet, a rede 1002 pode cobrir múltiplos segmentos de WiFi e/ou ethernet que são ligados em uma camada de enlace.

[0093] A rede 1002 inclui um ou mais nós 1004, 1006, 1008, 1010, 1012, 1014 e 1016, referidos aqui coletivamente como 1004 a 1016. Embora a rede 1002 ilustrada inclua sete nós, certas modalidades da rede 1002 podem incluir um ou mais nós interconectados usando-se a rede 1002. Mais ainda, se a rede 1002 for uma rede WiFi, cada um dos nós 1004 a 1016 poderá ser interconectado usando-se o nó 1016 (por exemplo, um roteador de WiFi) e/ou emparelhado com outros nós usando WiFi Direct (isto é, WiFi P2P).

B. Topologia de Rede em Estrela

[0094] A figura 5 ilustra uma modalidade alternativa de uma malha 1000, tal como uma malha 1018 tendo uma topologia de rede em estrela. A malha 1018 inclui uma rede de hub 1020 que une em conjunto duas redes periféricas 1022 e 1024. A rede de hub 1020 pode incluir uma rede doméstica, tal como uma rede de WiFi / Ethernet ou uma rede de linha de potência. As redes periféricas 1022 e 1024 podem ser tipos diferentes de conexão de rede adicionais de tipos diferentes da rede de hub 1020. Por exemplo, em algumas modalidades, a rede de hub 1020 pode ser uma rede de WiFi / Ethernet, a rede periférica 1022 pode incluir uma rede 802.15.4 e a rede periférica 1024 pode incluir uma redundância de linha de potência, uma rede ZigBee®, uma rede ISA100.11a, uma rede WirelessHART, ou uma rede MiWi™. Mais ainda, embora a modalidade ilustrada da malha 1018 inclua três redes, certas modalidades da malha 1018 podem incluir qualquer número de redes, tais como 2, 3, 4, 5 ou mais redes. De fato, algumas modalidades da malha 1018 incluem múltiplas redes periféricas do mesmo tipo.

[0095] Embora a malha 1018 ilustrada inclua quatorze nós, cada um referido individualmente pelos números de referência 1024 a 1052, respectivamente, deve ser entendido que a malha 1018 pode incluir qualquer número de nós. Uma comunicação em cada rede 1020, 1022 ou 1024 pode ocorrer diretamente entre dispositivos e/ou através de um ponto de acesso, tal como o nó 1042 na rede de WiFi / Ethernet. As comunicações entre as redes periféricas 1022 e 1024 passam através da rede de hub 1020 usando-se nós de roteamento inter-rede. Por exemplo, na modalidade ilustrada, os nós 1034 e 1036 estão para serem conectados à rede periférica 1022 usando-se um primeiro tipo de conexão de rede (por exemplo, 802.15.4) e à rede de hub 1020 usando-se um segundo tipo de conexão de rede (por exemplo, WiFi), enquanto o nó 1044 é conectado à rede de hub 1020 usando-se o segundo tipo de conexão de rede e à 1024 usando-se um terceiro tipo de conexão de rede (por exemplo, uma linha de potência). Por exemplo, uma mensagem enviada a partir do nó 1026 para o nó 1052 pode passar através dos nós 1028, 1030, 1032, 1036, 1042, 1044, 1048 e 1050 em trânsito para o nó 1052.

C. Topologia de Redes com Superposição

[0096] A figura 6 ilustra uma modalidade alternativa da malha 1000 como uma malha 1054 tendo uma topologia de redes com superposição. A malha 1054 inclui as redes 1056 e 1058. Conforme ilustrado, cada um dos nós 1062, 1064, 1066, 1068, 1070 e 1072 pode ser conectado a cada uma das redes. Em outras modalidades, o nó 1072 pode incluir um ponto de acesso para uma rede de Ethernet / WiFi, ao invés de um ponto final, e pode não estar presente na rede 1056 ou na rede 1058, qualquer uma que não seja a rede de Ethernet / WiFi. Assim sendo, uma comunicação a partir do nó 1062 para o nó 1068 pode ser passada através da rede 1056, da rede 1058 ou de alguma combinação das mesmas. Na modalidade ilustrada, cada nó pode se comu-nicar com qualquer outro nó através de qualquer rede usando qualquer rede desejada. Assim sendo, diferentemente da topologia de rede em estrela da figura 5, a topologia de redes com superposição pode se comunicar diretamente entre nós através de qualquer rede sem o uso de um roteamento inter-rede.

D. Conexão de Rede de Malha para Serviços

[0097] Além das comunicações entre dispositivos em casa, uma malha (por exemplo, a malha 1000) pode incluir serviços que podem estar localizados fisicamente perto de outros dispositivos na malha ou fisicamente remotos desses dispositivos. A malha se conecta a estes serviços através de um ou mais pontos finais de serviço. A figura 7 ilustra uma modalidade de um serviço 1074 em comunicação com as malhas 1076, 1078 e 1080. O serviço 1074 pode incluir vários serviços que podem ser usados pelos dispositivos nas malhas 1076, 1078 e 1080. Por exemplo, em algumas modalidades, o serviço 1074 pode ser um serviço de horário do dia, que supre um horário do dia para dispositivos, um serviço de clima para a provisão de vários dados de clima (por exemplo, temperatura externa, pôr do Sol, informação de vento, previsão climática, etc.), um serviço de eco que dá o "ping" de cada dispositivo, serviços de gerenciamento de dados, serviços de gerenciamento de direção perpendicular e/ou outros serviços adequados. Conforme ilustrado, o serviço 1074 pode incluir um servidor 1082 (por exemplo, um servidor da web) que armazena / acessa dados relevantes e passa a informação através de um ponto final de serviço 1084 para um ou mais pontos finais 1086 em uma malha, tal como a malha 1076. Embora a modalidade ilustrada apenas inclua três malhas com um único servidor 1082, deve ser apreciado que o serviço 1074 podem se conectar a qualquer número de malhas e pode incluir servidores além do servidor 1082 e/ou conexões com serviços adicionais.

[0098] Em certas modalidades, o serviço 1074 também pode se conectar a um dispositivo de consumidor 1088, tal como um telefone, um tablet e/ou um computador. O dispositivo de consumidor 1088 pode ser usado para conexão ao serviço 1074 através de uma malha, tal como a malha 1076, uma conexão de Internet e/ou algum outro método de conexão adequado. O dispositivo de consumidor 1088 pode ser usado para acesso a dados a partir de um ou mais pontos finais (por exemplo, dispositivos eletrônicos) em uma malha diretamente através da malha ou via o serviço 1074. Em outras palavras, usando o serviço 1074, o dispositivo de consumidor 1088 pode ser usado para acesso / gerenciamento de dispositivos em uma malha remotamente da malha.

E. Comunicação entre Dispositivos em uma Malha

[0099] Conforme discutido acima, cada dispositivo eletrônico ou nó pode se comunicar com qualquer outro nó na malha, direta ou indiretamente, dependendo da topologia da malha e dos tipos de conexão de rede. Adicionalmente, alguns dispositivos (por exemplo, dispositivos remotos) podem se comunicar através de um serviço para comunicação com outros dispositivos na malha. A figura 8 ilustra uma modalidade de uma comunicação 1090 entre dois dispositivos 1092 e 1094. A comunicação 1090 pode cobrir uma ou mais redes direta ou indireta- mente através de dispositivos e/ou serviços adicionais, conforme descrito acima. Adicionalmente, a comunicação 1090 pode ocorrer por um protocolo de comunicação apropriado, tal como IPv6, usando um ou mais protocolos de transporte. Por exemplo, em algumas modalidades, a comunicação 1090 pode incluir o uso do protocolo de controle de transmissão (TCP) e/ou o protocolo de datagrama de usuário (UDP). Em algumas modalidades, o dispositivo 1092 pode transmitir um primeiro sinal 1096 para o dispositivo 1094 usando um protocolo sem conexão (por exemplo, um UDP). Em certas modalidades, o dispositivo 1092 pode se comunicar com o dispositivo 1094 usando um protocolo orientado para conexão (por exemplo, TCP). Embora a comunicação ilustrada 1090 seja descrita como uma conexão bidirecional, em algumas modalidades, a comunicação 1090 pode ser uma difusão unidire- cional.

i. Endereço Local Único

[00100] Conforme descrito acima, os dados transmitidos em uma malha recebidos por um nó podem ser redirecionados ou passados através do nó para um outro nó, dependendo do alvo desejado para a comunicação. Em algumas modalidades, a transmissão dos dados pode ser pretendida para ser difundida para todos os dispositivos. Nessas modalidades, os dados podem ser retransmitidos sem um processamento adicional para se determinar se os dados devem ser passados adiante para um outro nó. Contudo, alguns dados podem ser dirigidos para um ponto final específico. Para se permitir que mensagens endereçadas sejam transmitidas para os pontos finais desejados, aos nós pode ser atribuída uma informação de identificação.

[00101] A cada nó pode ser atribuído um conjunto de endereços de enlace - local (LLA), um atribuído a cada interface de rede. Estes LLAs podem ser usados para comunicação com outros nós na mesma rede. Adicionalmente, os LLAs podem ser usados para vários proce- dimentos de comunicação, tal como um Protocolo de Descoberta de Vizinho de IPv6. Além dos LLAs, a cada nó é atribuído um endereço local único (ULA).

[00102] A figura 9 ilustra uma modalidade de um endereço local único (ULA) 1098 que pode ser usado para endereçamento de cada nó na malha. Em certas modalidades, o ULA 1098 pode ser formatado como um formato de endereço de IPv6 contendo 128 bits divididos em um ID global 1100, um ID de sub-rede 1102, e um ID de interface 1104. O ID global 1100 inclui 40 bits e o ID de sub-rede 1102 inclui 16 bits. O ID global 1100 e o ID de sub-rede 1102 em conjunto formam um ID de malha 1103 para a malha.

[00103] O ID de malha 1103 é um identificador de 64 bits usado para a identificação de uma malha. O ID de malha 1103 pode ser gerado na criação da malha associada usando-se um algoritmo pseudorran- dômico. Por exemplo, o algoritmo pseudorrandômico pode 1) obter o horário atual do dia no formato de NTP de 64 bits, 2) obter o ID de interface 1104 para o dispositivo, 3) concatenar o horário do dia com o ID de interface 1104 para a criação de uma chave, 4) computar e digerir SHA-1 a chave resultante em 160 bits, 5) usar os 40 bits menos significativos como o ID global 1100, e 6) concatenar o ULA e regular o bit menos significativo para 1 para criar a ID de malha 1103. Em certas modalidades, uma vez que o ID de malha 1103 é criado com a malha, o ID de malha 1103 permanece até a malha ser dissolvida.

[00104] O ID global 1100 identifica a malha à qual o nó pertence. O ID de sub-rede 1102 identifica as redes lógicas na malha. O ID de sub- rede F3 pode ser atribuído de forma monotônica começando em um com a adição de cada nova rede lógica à malha. Por exemplo, uma rede WiFi pode ser identificada com um valor hexadecimal de 0x01, e uma rede 802.15.4 conectada mais tarde pode ser identificada com um valor hexadecimal de 0x02 continuando de forma incremental median- te a conexão de cada nova rede à malha.

[00105] Finalmente, o ULA 1098 inclui um ID de interface 1104 que inclui 64 bits. O ID de interface 1104 pode ser atribuído usando-se um identificador de 64 bits globalmente único de acordo com a norma EUI- 64 do IEEE. Por exemplo, os dispositivos com interfaces de rede IEEE 802 podem derivar o ID de interface 1104 usando um endereço de MAC queimado para a "interface primária" de dispositivos. Em algumas modalidades, a designação de qual interface é a interface primária pode ser determinada arbitrariamente. Em outras modalidades, um tipo de interface (por exemplo, WiFi) pode ser julgada a interface primária, quando presente. Se o endereço de MAC para a interface primária de um dispositivo for de 48 bits, ao invés de 64 bits, o endereço de MAC de 48 bits poderá ser convertido em um valor de EUI-64 através de encapsulação (por exemplo, uma encapsulação de identificador único de forma organizacional). Em dispositivos de consumidor (por exemplo, telefones ou computadores), o ID de interface 1104 pode ser atribuído pelos sistemas operacionais locais de dispositivos de consumidor.

ii. Roteamentos de Transmissão entre Redes Lógicas

[00106] Conforme discutido acima em relação a uma topologia de rede em estrela, um roteamento inter-rede pode ocorrer em comunicação entre dois dispositivos através de redes lógicas. Em algumas modalidades, um roteamento inter-rede é baseado no ID de sub-rede 1102. Cada nó inter-rede (por exemplo, um nó 1034 da figura 5) pode manter uma lista de outros nós de roteamento (por exemplo, o nó B 14 da figura 5) na rede de hub 1020 e suas respectivas redes periféricas anexadas (por exemplo, a rede periférica 1024 da figura 5). Quando um pacote chega endereçado a um outro nó além do nó de roteamen- to em si, o endereço de destino (por exemplo, um endereço para o nó 1052 da figura 5) é comparado com a lista de prefixos de rede e um nó de roteamento (por exemplo, o nó 1044) é selecionado que é anexado à rede desejada (por exemplo, a rede periférica 1024). O pacote então é encaminhado para o nó de roteamento selecionado. Se múltiplos nós (por exemplo, 1034 e 1036) forem anexados à mesma rede periférica, os nós de roteamento serão selecionados de uma forma alternada.

[00107] Adicionalmente, os nós de roteamento de inter-rede podem transmitir regularmente mensagens de anúncio de roteador de protocolo de descoberta de vizinho (NDP) na rede de hub para alertar dispositivos de consumidor para a existência da rede de hub e permitir que eles adquiram o prefixo de sub-rede. Os anúncios de roteador podem incluir uma ou mais opções de informação de rota para ajudarem na informação de roteamento na malha. Por exemplo, estas opções de informação de rota podem informar aos dispositivos de consumidor a existência das redes periféricas e como rotear os pacotes das redes periféricas.

[00108] Além disso, ou no lugar de opções de informação de rota, os nós de roteamento podem atuar como proxies para a provisão de uma conexão entre dispositivos de consumidor e dispositivos em redes periféricas, tal como o processo 1105, conforme ilustrado na figura 10. Conforme ilustrado, o processo 1105 inclui a cada dispositivo de rede periférica ser atribuído um endereço virtual na rede de hub pela combinação do ID de sub-rede 1102 com o ID de interface 1104 para o dispositivo na rede periférica (bloco 1106). Para ter um proxy usando os endereços virtuais, os nós de roteamento mantêm uma lista de todos os nós periféricos na malha que são diretamente alcançáveis através de uma de suas interfaces (bloco 1108). Os nós de roteamento ouvem na rede de hub mensagens de solicitação de vizinho requisitando o endereço de enlace de um nó periférico usando seu endereço virtual (bloco 1110). Mediante o recebimento de uma mensagem como essa, o nó de roteamento tenta atribuir o endereço virtual a sua inter face de hub após um período de tempo (bloco 1112). Como parte da atribuição, o nó de roteamento executa uma detecção de endereço em duplicata, de modo a bloquear um proxy do endereço virtual por maios do que um nó de roteamento. Após a atribuição, o nó de roteamento responde à mensagem de solicitação de vizinho e recebe o pacote (bloco 1114). Mediante o recebimento do pacote, o nó de roteamento reescreve o endereço de destino para ser o endereço real do nó periférico (bloco 1116) e encaminha a mensagem para a interface apropriada (bloco 1118).

iii. Dispositivos de Consumidor se Conectando a uma Malha

[00109] Para se unir a uma malha, um dispositivo de consumidor pode descobrir um endereço de um nó já na malha a que o dispositivo de consumidor deseja se unir. Adicionalmente, se o dispositivo de consumidor tiver sido desconectado de uma malha por um período de tempo estendido, poderá redescobrir os nós na rede, se a topografia da malha/layout tiver mudado. Para ajudar na descoberta / redesco- berta, os dispositivos de malha na rede de hub podem publicar registros de sistema de nome de domínio - descoberta de serviço (DNS- SD) através de mDNS que anunciam a presença da malha e proveem endereços ao dispositivo de consumidor.

111. Dados Transmitidos na Malha

[00110] Após a criação de uma malha e uma criação de endereço para os nós, os dados podem ser transmitidos através da malha. Os dados passados através da malha podem ser dispostos em um formato comum a todas as mensagens e/ou comum a tipos específicos de conversações na malha. Em algumas modalidades, o formato de mensagem pode permitir um mapeamento de um para um para a Notação de Objeto de JavaScript (JSON) usando-se um formato de serialização de TLV discutido abaixo. Adicionalmente, embora os quadros de dados a seguir sejam descritos como incluindo tamanhos específicos, deve ser notado que os comprimentos dos campos de dados nos quadros de dados podem ser variados para outros comprimentos de bit adequados.

[00111] Deve ser entendido que cada um dos quadros de dados a seguir, perfis e/ou formatos discutidos abaixo podem ser armazenados em uma memória (por exemplo, uma memória do dispositivo 10), antes de e/ou após uma transmissão de uma mensagem. Em outras palavras, embora o quadro de dados, os perfis e os formatos possam ser geralmente discutidos como transmissões de dados, eles também podem ser fisicamente armazenados (por exemplo, em um buffer), antes, durante e/ou após a transmissão do quadro de dados, dos perfis e/ou formatos. Mais ainda, os quadros de dados, perfis, esquemas e/ou formatos a seguir podem ser armazenados em um Meio legível em computador não transitório que permite que um dispositivo eletrônico acesse os quadros de dados, os perfis, os esquemas e/ou os forma-tos. Por exemplo, as instruções para formatação dos quadros de dados, perfis, esquemas e/ou formatos podem ser armazenadas em qualquer Meio legível em computador adequado, tal como na memória para o dispositivo 10, em uma memória de um outro dispositivo, um dispositivo de memória portátil (por exemplo, um disco compacto, uma unidade flash, etc.), ou outro dispositivo físico adequado que seja adequado para o armazenamento dos quadros de dados, dos perfis, dos esquemas e/ou dos formatos.

A. Segurança

[00112] Juntamente com dados pretendidos para serem transferidos, a malha pode transferir os dados com medidas de segurança adicionais, tais como criptografia, checagens de integridade de mensagem e assinaturas digitais. Em algumas modalidades, um nível de segurança suportado por um dispositivo pode variar de acordo com uma segurança física do dispositivo e/ou capacidades do dispositivo. Em certas modalidades, as mensagens enviadas entre os nós na malha podem ser criptografadas usando-se a cifra de bloco de Norma de Criptografia Avançada (AES) operando em modo de contador (AES- CTR) com uma chave de 128 bits. Conforme discutido abaixo, cada mensagem contém um id de mensagem de 32 bits. O id de mensagem pode ser combinado com um id de nó de envio para a formação de um nonce (número arbitrário usado apenas uma vez) para o algoritmo de AES-CTR. O contador de 32 bits permite que 4 bilhões de mensagem sejam criptografadas e enviadas por meio de cada nó, antes de uma nova chave ser negociada.

[00113] Em algumas modalidades, a malha pode garantir uma integridade de mensagem usando-se um código de autenticação de mensagem, tal como HMAC SHA-1, que pode ser incluído em cada mensagem criptografada. Em algumas modalidades, o código de autenticação de mensagem pode ser gerado usando-se uma chave de integridade de mensagem de 160 bits que é emparelhada um a um com a chave de criptografia. Adicionalmente, cada nó pode checar o id de mensagem de mensagens entrando com respeito a uma lista de ids recebidos recentemente mantidos em uma base de nó por nó para bloquear uma retransmissão das mensagens. B. Formatação de Etiqueta Comprimento Valor (TLV)

[00114] Para redução do consumo de potência, é desejável enviar pelo menos uma porção dos dados enviados pela malha de forma compacta, enquanto se permite que os contêineres de dados representem de forma flexível dados que acomodam dados de desvio que não são reconhecidos ou entendidos pelo desvio para a próxima localização de dados que seja entendida em uma serialização dos dados. Em certas modalidades, uma formatação de valor de etiqueta - comprimento - valor (TLV) pode ser usada para se codificarem / decodificarem dados de forma compacta e flexível. Pelo armazenamento de pelo menos uma porção dos dados transmitidos em TLV, os dados podem ser armazenados / enviados de forma compacta e flexível juntamente com baixos codificação / decodificação e tempo de processamento de memória, conforme discutido abaixo com referência à Tabela 7. Em certas modalidades, o TLV pode ser usado para alguns dados como dados extensíveis, flexíveis, mas outras porções de dados que não sejam extensíveis podem ser armazenadas e enviadas em uma unidade de dados de protocolo (PDU) padrão entendida.

[00115] Os dados formatados em um formato de TLV podem ser codificados como elementos de TLV de vários tipos, tais como tipos primitivos e tipos de contêiner. Os tipos primitivos incluem valores de dados em certos formatos, tais como inteiros ou strings. Por exemplo, o formato de TLV pode codificar: inteiros sinalizados / não sinalizados de 1, 2, 3, 4 ou 8 bytes, strings de UTF-8, strings de byte, números de flutuação de precisão única / dupla (por exemplo, um formato de IEEE 754-1985), booleanos, nulos e outros tipos de formato de dados adequados. Os tipos de contêiner incluem coleções de elementos que então são subclassificadas como tipos de contêiner ou primitivo. Os tipos de contêiner podem ser classificados em várias categorias, tais como dicionários, arranjos, percursos ou outros tipos adequados para agrupamento de elementos de TLV, conhecidos como membros. Um dispositivo de controle é uma coleção de membros, cada um tendo definições distintas e etiquetas únicas no dispositivo de controle. Um arranjo é uma coleção ordenada de membros com definições implicadas ou nenhuma definição distinta. Um percurso é uma coleção ordenada de membros que descrevem como atravessar uma árvore de elementos de TLV.

[00116] Conforme ilustrado na figura 11, uma modalidade de um pacote de TLV 1120 inclui três campos de dados: um campo de etiqueta 1122, um campo de comprimento 1124 e um campo de valor 1126. Embora os campos ilustrados 1122, 1124 e 1126 sejam ilustrados como de tamanho aproximadamente equivalente, o tamanho de cada campo pode ser variável e variar no tamanho em relação a cada outro. Em outras modalidades, o pacote de TLV 1120 ainda pode incluir um byte de controle antes do campo de etiqueta 1122.

[00117] Em modalidades tendo o byte de controle, o byte de controle pode ser subdividido em um campo de tipo de elemento e um campo de controle de etiqueta. Em algumas modalidades, o campo de tipo de elemento inclui 5 bits inferiores do byte de controle e o campo de controle de etiqueta ocupa os 3 bits superiores. O campo de tipo de elemento indica o tipo de elemento de TLV, e também como o campo de comprimento 1124 e o campo de valor 1126 são codificados. Em certas modalidades, o campo de tipo de elemento também codifica valores booleanos e/ou valores nulos para o TLV. Por exemplo, uma modalidade de uma enunciação de campo de tipo de elemento é provida na Tabela 1 abaixo.

Tabela 1. Valores de campo de tipo de elemento de exemplo. O campo de controle de etiqueta indica uma forma da etiqueta no campo de etiqueta 1122 atribuída ao elemento de TLV (incluindo uma etiqueta de comprimento zero). Os exemplos de valores de campo de controle de etiqueta são providos na Tabela 2 abaixo.

Tabela 2. Valores de exemplo de campo de controle de etiqueta. Em outras palavras, em modalidades tendo um byte de controle, o byte de controle pode indicar um comprimento da etiqueta.

[00118] Em certas modalidades, o campo de etiqueta 1122 pode incluir de zero a oito bytes, tais como oito, dezesseis, trinta e dois ou sessenta e quatro bits. Em algumas modalidades, a etiqueta do campo de etiqueta pode ser classificada como etiquetas específicas de perfil ou etiquetas específicas de contexto. As etiquetas específicas de perfil identificam elementos globalmente usando-se um Id de vendedor, um Id de perfil e/ou um número de etiqueta, conforme discutido abaixo. As etiquetas específicas de contexto identificam elementos de TLV em um contexto de contenção de elemento de dicionário, e podem incluir um número de etiqueta de byte único. Uma vez que etiquetas específicas de contexto são definidas no contexto de seus contêineres, uma etiqueta específica de contexto única pode ter interpretações diferentes, quando incluída em contêineres diferentes. Em algumas modalidades, o contexto também pode ser derivado a partir de contêineres alojados.

[00119] Em modalidades tendo o byte de controle, o comprimento de etiqueta é codificado no campo de controle de etiqueta, e o campo de etiqueta 1122 inclui três campos possíveis: um campo de Id de vendedor, um campo de Id de perfil e um campo de número de etiqueta. Na forma plenamente qualificada, o campo de etiqueta codificado 1122 inclui todos os três campos com o campo de número de etiqueta incluindo 16 ou 32 bits determinados pelo campo de controle de etiqueta. Na forma implícita, a etiqueta inclui apenas o número de etiqueta, e o Id de vendedor e o número de perfil são inferidos a partir do contexto de protocolo do elemento de TLV. A forma de perfil de núcleo inclui etiquetas específicas de perfil, conforme discutido acima. As etiquetas específicas de contexto são codificadas como um byte único portando o número de etiqueta. Elementos anônimos têm campos de etiqueta de comprimento zero 1122.

[00120] Em algumas modalidades sem um byte de controle, dois bits podem indicar um comprimento do campo de etiqueta 1122, dois bits podem indicar um comprimento do campo de comprimento 1124, e quatro bits podem indicar um tipo de informação armazenado no campo de valor 1126. Um exemplo de codificação possível para os 8 bits superiores para o campo de etiqueta é ilustrado abaixo na Tabela 3.

Tabela 3. Campo d e el iqueta d e um pacote de TLV. Conforme ilustrado na Tabela 3, os 8 bits superiores do campo de eti- queta 1122 podem ser usados para a codificação de uma informação sobre o campo de etiqueta 1122, o campo de comprimento 1124 e o campo de valor 1126, de modo que o campo de etiqueta 1122 possa ser usado para a determinação do comprimento para o campo de etiqueta 1122 e os campos de comprimento 1124. Os bits remanescentes no campo de etiqueta 1122 podem ser tornados disponíveis para valores de etiqueta alocados por usuário e/ou atribuídos por usuário.

[00121] O campo de comprimento 1124 pode incluir oito, dezesseis, trinta e dois ou sessenta e quatro bits, conforme indicado pelo campo de etiqueta 1122, conforme ilustrado na Tabela 3, ou pelo campo de elemento, conforme ilustrado na Tabela 2. Mais ainda, o campo de comprimento 1124 pode incluir um inteiro não sinalizado, que representa um comprimento de codificação no campo de valor 1126. Em algumas modalidades, o comprimento pode ser selecionado por um dispositivo enviando o elemento de TLV. O campo de valor 1126 inclui os dados de carga útil a serem decodificados, mas uma interpretação do campo de valor 1126 pode depender dos campos de comprimento de etiqueta e/ou do byte de controle. Por exemplo, um pacote de TLV sem um byte de controle incluindo uma etiqueta de 8 bits é ilustrado na Tabela 4 abaixo, para ilustração.

Tabela 4. Exemplo de um pacote de TLV incluindo uma etiqueta de 8 bits. Conforme ilustrado na Tabela 4, a primeira linha indica que o campo de etiqueta 1122 e o campo de comprimento 1124 têm, cada um, um comprimento de 8 bits. Adicionalmente, o campo de etiqueta 1122 indica que o tipo de etiqueta para a primeira linha é um contêiner (por exemplo, o pacote de TLV). O campo de comprimento 1124 para s linhas dois a seis indica que cada entrada no pacote de TLV tem um campo de etiqueta 1122 e um campo de comprimento 1124 consistindo em 8 bits cada. Adicionalmente, o campo de comprimento 1124 indica que cada entrada no pacote de TLV tem um campo de valor 1126 que inclui um ponto flutuante de 32 bits. Cada entrada no campo de valor 1126 corresponde a um número flutuante que pode ser decodificado usando-se o campo de etiqueta correspondente 1122 e a informação de campo de comprimento 1124. Conforme ilustrado neste exemplo, cada entrada no campo de valor 1126 corresponde a uma temperatura em Fahrenheit. Conforme pode ser entendido, pelo armazenamento de dados em um pacote de TLV, conforme descrito acima, os dados podem ser transferidos de forma compacta enquanto permanecem flexíveis para comprimentos variáveis e informação, conforme pode ser usado por dispositivos diferentes na malha. Mais ainda, em algumas modalidades, campos de inteiro de byte múltiplo podem ser transmitidos em uma ordem little-endian ou em uma ordem big-endian (Em big-endian, o byte mais significativo é armazenado em um ende-reço de memória em particular e os bytes subsequentes são armazenados nos endereços de memória de ordem mais alta seguintes, o byte menos significativo assim sendo armazenado no endereço de memória de ordem mais alta. Little-endian reverte a ordem e armazena o byte menos significativo no endereço de memória mais baixo, assim o byte mais significativo sendo armazenado no endereço de memória mais alto).

[00122] Pela transmissão de pacotes de TLV no uso de um protoco lo de ordem (por exemplo, little-endian) que pode ser usado pelos formatos de dispositivo de envio / recepção (por exemplo, JSON), dados transferidos entre nós podem ser transmitidos no protocolo de ordem usado por pelo menos um dos nós (por exemplo, little-endian). Por exemplo, se um ou mais nós incluírem ARM ou processadores ix86, as transmissões entre os nós poderão ser transmitidas usando-se uma ordenação de byte little-endian para redução do uso de reordenação de byte. Pela redução da inclusão de reordenação de byte, o formato de TLV permite que dispositivos se comuniquem usando menos potência do que uma transmissão que use reordenação de byte em ambas as extremidades da transmissão. Mais ainda, uma formatação de TLV pode ser especificada para a provisão de uma tradução um a um entre outras técnicas de armazenamento de dados, tal como JSON + linguagem de marcação extensível (XML). Como um exemplo, o formato de TLV pode ser usado para a representação da lista de propriedade de XML a seguir: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>OfflineMode</key> <false/> <key>Network</key> <dict> <key>IPv4</key> <dict> <key>Method</key> <string>dhcp</string> </dict> <key>IPv6</key> <dict> < key> Method</key> <string>auto</string> </dict> </dict> <key>Technologies</key> <dict> <key>wifi</key> <dict> <key>Enabled</key> <true/> <key>Devices</key> <dict> <key>wifi_18b4300008b027</key> <dict> <key>Enabled</key> <true/> </dict> </dict> <key>Services</key> <array> <string>wifi_18b4300008b027_3939382d33204 16c70696e652054657 272616365</string> </array> </dict> <key>802.15.4</key> <dict> <key>Enabled</key> <true/> <key>Devices</key> <dict> <key>802.15.4_18b43000000002fac4</key> <dict> <key>Enabled</key> <true/> </dict> </dict> <key>Services</key> <array> <string>802.15.4_18b43000000002fac4_3 939382d3320416c70696e6520546572</string> </array> </dict> </dict> <key>Services</key> <dict> <key>wifi_18b4300008b027_3939382d3320416c70696e65205465727 2616365</key> <dict> <key>Name</key> <string>998-3 Alpine Terrace</string> <key>SSID</key> <data>3939382d3320416c70696e652054657272616365 </data> <key>Frequency</key> <integer>2462</integer> <key>AutoConnect</key> <true/> < key> Favorite</key> <true/> <key>Error</key> <string/> < key> Network</key> <dict> <key>IPv4</key> <dict> <key>DHCP</key> <dict> <key>LastAddress</key> <data>0a02001 e</data> </dict> </dict> <key>IPv6</key> <dict/> </dict> </dict> <key>802.15.4_18b43000000002fac4_3939382d3320416c70696e652 0546572</key> <dict> <key>Name</key> <string>998-3 Alpine Ter</string> <key>EPANID</key> <data>3939382d3320416c70696e6520546572</data> <key>Frequency</key> <integer>2412</integer> <key>AutoConnect</key> <true/> <key>Favorite</key> <true/> <key>Error</key> <string/> <key>Network</key> <dict/> </dict> </dict> </dict> </plist

[00123] Como um exemplo, a lista de propriedade acima pode ser representada em etiquetas do formato de TLV descrito acima (sem um byte de controle), de acordo com a Tabela 5 abaixo.

Tabela 5. Representação de exemplo da lista de propriedade de XML em formato de TLV.

[00124] De modo similar, a Tabela 6 ilustra um exemplo de repre-sentações literais de etiqueta, comprimento e valor para a lista de pro-priedade de XML de exemplo.

Tabela 6. Exemplo de valores literais para campos de etiqueta, com-primento e valor para lista de propriedade de XML.

[00125] O formato de TLV permite uma referência de propriedades que podem ser enumeradas com XML, mas o faz com um tamanho de armazenamento menor. Por exemplo, a Tabela 7 ilustra uma comparação de tamanhos de dados da lista de propriedade de XML, uma lista de propriedade binária correspondente e o formato de TLV.

Tabela 7. Comparação dos taman hos de tamanhos de dados de lista de propriedade.

[00126] Pela redução da quantidade de dados usada para a transferência de dados, o formato de TLV permite que a malha 1000 transfira dados para e/ou a partir de dispositivos tendo ciclos de carga curtos, devido a uma potência limitada (por exemplo, dispositivos supridos por bateria). Em outras palavras, o formato de TLV permite uma flexibili- dade de transmissão, enquanto se aumenta a compacidade dos dados a serem transmitidos.

C. Protocolo de Mensagem Geral

[00127] Além do envio de entradas em particular de tamanhos variáveis, os dados podem ser transmitidos na malha usando-se um protocolo de mensagem geral que pode incorporar uma formatação de TLV. Uma modalidade de um protocolo de mensagem geral (GMP) 1128 é ilustrado na figura 12. Em certas modalidades, o protocolo de mensagem geral (GMP) 1128 pode ser usado para a transmissão de dados na malha. O GMP 1128 pode ser usado para a transmissão de dados através de protocolos sem conexão (por exemplo, UDP) e/ou protocolos orientados para conexão (por exemplo, TCP). Assim sendo, o GMP 1128 pode acomodar de forma flexível uma informação que é usada em um protocolo, enquanto se ignora essa informação quando se usa um outro protocolo. Mais ainda, o GMP 1226 pode permitir a omissão de campos que não sejam usados em uma transmissão específica. Os dados que podem ser omitidos a partir de um ou mais transferências de GMP 1226 é geralmente indicado usando-se bordas cinzas em torno das unidades de dados. Em algumas modalidades, os campos de inteiro de byte múltiplo podem ser transmitidos em uma ordem little-endian ou uma ordem big-endian. i. Comprimento de Pacote

[00128] Em algumas modalidades, o GMP 1128 pode incluir um campo de comprimento de pacote 1130. Em algumas modalidades, o campo de comprimento de pacote 1130 inclui 2 bytes. Um valor no campo de comprimento de pacote 1130 corresponde a um inteiro não sinalizado indicando um comprimento geral da mensagem em bytes, excluindo o campo de comprimento de pacote 1130 em si. O campo de comprimento de pacote 1130 pode estar presente quando o GMP 1128 é transmitido por uma conexão de TCP, mas, quando o GMP 1128 é transmitido por uma conexão de UDP, o comprimento de men-sagem pode ser igual ao comprimento de carga útil do pacote de UDP subjacente tornando desnecessário o campo de comprimento de pacote 1130. ii. Cabeçalho de Mensagem

[00129] O GMP 1128 também pode incluir um cabeçalho de mensagem 1132, independentemente de o GMP 1128 ser transmitido usando-se conexões de TCP ou UDP. Em algumas modalidades, o cabeçalho de mensagem 1132 inclui dois bytes de dados dispostos no formato ilustrado na figura 13. Conforme ilustrado na figura 13, o cabeçalho de mensagem 1132 inclui um campo de versão 1156. O campo de versão 1156 corresponde a uma versão do GMP 1128 que é usado para a codificação da mensagem. Assim sendo, conforme o GMP 1128 é atualizado, novas versões do GMP 1128 podem ser criadas, mas cada dispositivo em uma malha pode ser capaz de receber um pacote de dados em qualquer versão de GMP 1128 conhecida para o dispositivo. Além do campo de versão 1156, o cabeçalho de mensagem 1132 pode incluir um campo de referência ("flag camp") S 1148 e um campo de referência D 1160. A 1158 é um bit único que indica que um campo de Id de nó de fonte (discutido abaixo) está incluído no pacote transmitido. De modo similar, o campo de referência D 1160 é um bit único que indica se um campo de Id de nó de destino (discutido abaixo) é incluído no pacote transmitido.

[00130] O cabeçalho de mensagem 1132 também inclui um campo de tipo de criptografia 1162. O campo de tipo de criptografia 1162 inclui quatro bits que especificam qual tipo de criptografia / checagem de integridade aplicado à mensagem, se houver. Por exemplo, 0x0 pode indicar que nenhuma criptografia ou checagem de integridade de mensagem está incluída, mas um 0x1 decimal pode indicar que uma criptografia de AES-128-CTR com checagem de integridade de mensa- gem HMAC-SHA-1 é incluída.

[00131] Finalmente, o cabeçalho de mensagem 1132 adicionalmente inclui um campo de tipo de assinatura 1164. O campo de tipo de assinatura 1164 inclui quatro bits que especificam qual tipo de assinatura digital é aplicado à mensagem, se houver. Por exemplo, 0x0 pode indicar que nenhuma assinatura digital está incluída na mensagem, mas 0x1 pode indicar que o algoritmo de assinatura digital de curva elíptica (ECDSA) com parâmetros de curva elíptica Prime256v1 é incluído na mensagem. iii. Id de Mensagem

[00132] Retornando para a figura 12, o GMP 1128 também inclui um campo de Id de mensagem 1134 que pode ser incluído em uma mensagem transmitida, independentemente de a mensagem ser enviada usando-se TCP ou UDP. O campo de Id de mensagem 1134 inclui quatro bytes que correspondem a um valor inteiro não sinalizado que unicamente identifica a mensagem a partir da perspectiva do nó de envio. Em algumas modalidades, os nós podem atribuir valores crescentes de Id de mensagem 1134 para cada mensagem que eles enviam retornando para zero após atingirem 232 mensagens. iv. Id de Nó de Fonte

[00133] Em certas modalidades, o GMP 1128 também pode incluir um campo de Id de nó de fonte 1136 que inclui oito bytes. Conforme discutido acima, o campo de Id de nó de fonte 1136 pode estar presente em uma mensagem, quando a referência S de bit único 1158 no cabeçalho de mensagem 1132 for regulado para rede periférica. Em algumas modalidades, o campo de Id de nó de fonte 1136 pode conter a ID de interface 1104 do ULA 1098 ou o ULA 1098 inteiro. Em algumas modalidades, os bytes do campo de Id de nó de fonte 1136 são transmitidos em uma ordem de valor de índice ascendente (por exemplo, EUI [0] então EUI[1] então EUI[2] então EUI[3], etc.). v. Id de Nó de destino

[00134] O GMP 1128 pode incluir um campo de Id de nó de destino 1138 que inclui oito bytes. O campo de Id de nó de destino 1138 é similar ao campo de Id de nó de fonte 1136, mas o campo de Id de nó de destino 1138 corresponde a um nó de destino para a mensagem. O campo de Id de nó de destino 1138 pode estar presente em uma mensagem quando a referência D de bit único 1160 no cabeçalho de mensagem 1132 é regulado para 1. Também similar ao campo de Id de nó de fonte 1136, em algumas modalidades, os bytes do campo de Id de nó de destino 1138 podem ser transmitidos em uma ordem de valor de índice ascendente (por exemplo, EUI [0] então EUI[1] então EUI[2] então EUI[3], etc.). vi. Id de Chave

[00135] Em algumas modalidades, o GMP 1128 pode incluir um campo de Id de chave 1140. Em certas modalidades, o campo de Id de chave 1140 inclui dois bytes. O campo de Id de chave 1140 inclui um valor inteiro não sinalizado que identifica as chaves de criptografia / integridade de mensagem usadas para a criptografia da mensagem. A presença do campo de Id de chave 1140 pode ser determinado pelo valor de campo de tipo de criptografia 1162 do cabeçalho de mensagem 1132. Por exemplo, em algumas modalidades, quando o valor para o campo de tipo de criptografia 1162 do cabeçalho de mensagem 1132 é 0x0, o campo de Id de chave 1140 pode ser omitido da mensagem.

[00136] Uma modalidade do campo de Id de chave 1140 é apresentada na figura 14. Na modalidade ilustrada, o campo de Id de chave 1140 inclui um campo de tipo de chave 1166 e um campo de número de chave 1168. Em algumas modalidades, o campo de tipo de chave 1166 inclui quatro bits. O campo de tipo de chave 1166 corresponde a um valor inteiro não sinalizado que identifica um tipo de criptografia / integridade de mensagem usado para a criptografia da mensagem. Por exemplo, em algumas modalidades, se o campo de tipo de chave 1166 for 0x0, a chave de malha será compartilhada por todos ou pela maioria dos nós na malha. Contudo, se o campo de tipo de chave 1166 for 0x1, a chave de malha será compartilhada por um par de nós na malha.

[00137] O campo de Id de chave 1140 também inclui um campo de número de chave 1168 que inclui doze bits que correspondem a um valor inteiro não sinalizado que identifica uma chave em particular usada para a criptografia da mensagem de um conjunto de chaves disponíveis, compartilhadas ou chaves de malha. vii. Comprimento de Carga Útil

[00138] Em algumas modalidades, o GMP 1128 pode incluir um campo de comprimento de carga útil 1142. O campo de comprimento de carga útil 1142, quando presente, pode incluir dois bytes. O campo de comprimento de carga útil 1142 corresponde a um valor inteiro não sinalizado que indica um tamanho em bytes do campo de carga útil de aplicativo. O campo de comprimento de carga útil 1142 pode estar presente quando a mensagem for criptografada usando-se um algoritmo que use enchimento de mensagem, conforme descrito abaixo em relação ao campo de enchimento. viii. Vetor de Inicialização

[00139] Em algumas modalidades, o GMP 1128 também pode incluir um campo de vetor de inicialização (IV) 1144. O campo de IV 1144, quando presente, inclui um número variável de bytes de dados. O campo de IV 1144 contém valores de IV criptografados usados para a criptografia da mensagem. O campo de IV 1144 pode ser usado quando a mensagem for criptografada com um algoritmo que use um IV. O comprimento do campo de IV 1144 pode ser derivado pelo tipo de criptografia usado para a criptografia da mensagem. ix. Carga Útil de Aplicativo

[00140] O GMP 1128 inclui um campo de carga útil de aplicativo 1146. O campo de carga útil de aplicativo 1146 inclui um número variável de bytes. O campo de carga útil de aplicativo 1146 inclui um número variável de bytes. O campo de carga útil de aplicativo 1146 inclui os dados de aplicativo portados na mensagem. O comprimento do campo de carga útil de aplicativo 1146 pode ser determinado a partir do campo de comprimento de carga útil 1142, quando presente. Se o campo de comprimento de carga útil 1142 não estiver presente, o comprimento do campo de carga útil de aplicativo 1146 poderá ser determinado pela subtração do comprimento de todos os outros campos do comprimento total da mensagem e/ou de valores de dados incluídos no campo de carga útil de aplicativo 1146 (por exemplo, TLV).

[00141] Uma modalidade do campo de carga útil de aplicativo 1146 é ilustrada na figura 15. O campo de carga útil de aplicativo 1146 inclui um campo de APVersion 1170. Em algumas modalidades, o campo de APVersion 1170 inclui oito bits que indicam que versão de software de malha é suportada pelo dispositivo de envio. O campo de carga útil de aplicativo 1146 também inclui um campo de tipo de mensagem 1172. O campo de tipo de mensagem 1172 pode incluir oito bits que correspondem a um código de operação de mensagem que indica o tipo de mensagem sendo enviado em um perfil. Por exemplo, em um perfil de atualização de software, um 0x00 pode indicar que a mensagem sendo enviada é um anúncio de imagem. O campo de carga útil de aplicativo 1146 ainda inclui um campo de Id de troca 1174 que inclui dezesseis bits que corresponde a um identificador de troca que é único para o nó de envio para a transação.

[00142] Além disso, o campo de carga útil de aplicativo 1146 inclui um campo de Id de perfil 1176. O campo de Id de perfil 1176 indica um "tema de discussão" usado para indicar que tipo de comunicação ocor- re na mensagem. O campo de Id de perfil 1176 pode corresponder a um ou mais perfis que um dispositivo pode ser capaz de comunicar. Por exemplo, o campo de Id de perfil 1176 pode indicar que a mensagem se refere a um perfil de núcleo, um perfil de atualização de software, um perfil de atualização de status, um perfil de gerenciamento de dados, um perfil de clima e conforto, um perfil de seguro, um perfil de segurança e/ou outros tipos de perfil adequados. Cada dispositivo na malha pode incluir uma lista de perfis os quais são relevantes para o dispositivo e nos quais o dispositivo é capaz de "participar na discussão". Por exemplo, muitos dispositivos em uma malha podem incluir o perfil de núcleo, o perfil de atualização de software, o perfil de atualização de status e o perfil de gerenciamento de dados, mas apenas alguns dispositivos incluiriam o clima e o perfil de conforto. O campo de APVersion 1170, o campo de tipo de mensagem 1172, o campo de Id de troca, o campo de Id de perfil 1176 e o campo de cabeçalho específico de perfil 1178, se presente, podem ser referidos em uma combinação como o "cabeçalho de aplicativo".

[00143] Em algumas modalidades, uma indicação do Id de perfil através do campo de Id de perfil 1176 pode prover uma informação suficiente para a provisão de um esquema para dados transmitidos para o perfil. Contudo, em algumas modalidades, uma informação adicional pode ser usada para se determinar uma recomendação adicional para a decodificação do campo de carga útil de aplicativo 1146. Nessas modalidades, o campo de carga útil de aplicativo 1146 pode incluir um campo de cabeçalho específico de perfil 1178. Alguns perfis podem não usar o campo de cabeçalho específico de perfil 1178, desse modo se permitindo que o campo de carga útil de aplicativo 1146 omita o campo de cabeçalho específico de perfil 1178. Mediante a determinação de um esquema a partir do campo de Id de perfil 1176 e/ou do campo de cabeçalho específico de perfil 1178, os dados podem ser codificados / decodificados no subcampo de carga útil de aplicativo 1180. O subcampo de carga útil de aplicativo 1180 inclui os dados de aplicativo de núcleo a serem transmitidos entre os dispositivos e/ou serviços a serem armazenados, redifundidos e/ou atuados pelo dispositivo / serviço de recepção. x. Checagem de Integridade de Mensagem

[00144] Retornando à figura 12, em algumas modalidades, o GMP 1128 também pode incluir um campo de checagem de integridade de mensagem (MIC) 1148. O campo de MIC 1148, quando presente, inclui um comprimento variável de bytes de dados contendo uma MIC para a mensagem. O comprimento e a ordem de byte do campo dependem do algoritmo de checagem de integridade em uso. Por exemplo, se a mensagem for checada quanto à integridade de mensagem usando-se HMAC-SHA-1, o campo de MIC 1148 incluirá vinte bytes em ordem big-endian. Mais ainda, a presença do campo de MIC 1148 pode ser determinada por se o campo de tipo de criptografia 1162 do cabeçalho de mensagem 1132 inclui qualquer outro valor além de 0x0. xi. Enchimento

[00145] O GMP 1128 também pode incluir um campo de enchimento 1150. O campo de enchimento 1150, quando presente, inclui uma sequência de bytes representando um enchimento criptográfico adicionado à mensagem para tornar a porção criptografada da mensagem uniformemente divisível pelo tamanho de bloco de criptografia. A presença do campo de enchimento 1150 pode ser determinada por se o tipo de algoritmo de criptografia (por exemplo, cifras de bloco no modo de encadeamento de bloco de cifra) indicado pelo campo de tipo de criptografia 1162 no cabeçalho de mensagem 1132 usa um enchimento criptográfico. xii. Criptografia

[00146] O campo de carga útil de aplicativo 1146, o campo de MIC 1148 e o campo de enchimento 1150 em conjunto formam um bloco de criptografia 1152. O bloco de criptografia 1152 inclui as porções da mensagem que são criptografadas, quando o campo de tipo de criptografia 1162 no cabeçalho de mensagem 1132 for qualquer outro valor além de 0x0. xiii. Assinatura de Mensagem

[00147] O GMP 1128 também pode incluir um campo de assinatura de mensagem 1154. O campo de assinatura de mensagem 1154, quando presente, inclui uma sequência de bytes de comprimento variável que contém uma assinatura criptográfica da mensagem. O comprimento e o conteúdo do campo de assinatura de mensagem 1154 podem ser determinados de acordo com o tipo de algoritmo de assinatura em uso e indicados pelo campo de tipo de assinatura 1164 do cabeçalho de mensagem 1132. Por exemplo, se ECDSA usando os parâmetros de curva elíptica Prime256v1 for o algoritmo em uso, o campo de assinatura de mensagem 1154 poderá incluir dois inteiros de trinta e dois bits codificados em uma ordem little-endian.

IV. Perfis e Protocolos

[00148] Conforme discutido acima, um ou mais esquemas de informação podem ser selecionados mediante um tipo de discussão geral desejado para a mensagem. Um perfil pode consistir em um ou mais esquemas. Por exemplo, um conjunto de esquemas de informação pode ser usado para a codificação / decodificação de dados no subcampo de carga útil de aplicativo 1180, quando um perfil for indicado no campo de Id de perfil 1176 do campo de carga útil de aplicativo 1146. Contudo, um conjunto diferente de esquemas pode ser usado para a codificação / decodificação de dados no subcampo de carga útil de aplicativo 1180, quando um perfil diferente for indicado no campo de Id de perfil 1176 do campo de carga útil de aplicativo 1146.

[00149] Adicionalmente, em certas modalidades, cada dispositivo pode incluir um conjunto de métodos usados para o processamento de perfis. Por exemplo, um protocolo de núcleo pode incluir os perfis a seguir: GetProfiles, GetSchema, GetSchemas, GetProperty, GetPro- perties, SetProperty, SetProperties, RemoveProperty, RemoveProperties, RequestEcho, NotifyPropertyChanged e/ou NotifyProperties- Changed. O método de GetProfiles pode retornar um arranjo de perfis suportados por um nó consultado. Os métodos de GetSchema e Ge- tSchemas podem retornar respectivamente um ou todos os esquemas para um perfil específico. GetProperty e GetProperties podem resistência retornar um valor ou todos os pares de valor para um esquema de perfil. SetProperty e SetProperties podem respectivamente regular um valor único ou múltiplos para um esquema de perfil. RemoveProperty e RemoveProperties podem respectivamente tentar remover um único valor ou múltiplos de um esquema de perfil. RequestEcho pode enviar uma carga útil arbitrária de dados para um nó específico, a qual o nó retorna não modificada. NotifyPropertyChange e NotifyProper- tiesChanged podem respectivamente emitir uma notificação, se um único par de valores / múltiplos pares de valores tiverem mudado para um esquema de perfil.

[00150] Para ajudar no entendimento de perfis e esquemas, uma lista não exclusiva de perfis e esquemas é provida abaixo para fins ilustrativos.

A. Relatório de Status

[00151] Um esquema de relatório de status é apresentado como o quadro de relatório de status 1182 na figura 16. O esquema de relatório de status pode ser um perfil separado ou pode ser incluído em um ou mais perfis (por exemplo, um perfil de núcleo). Em certas modalidades, o quadro de relatório de status 1182 inclui um campo de perfil 1184, um campo de código de status 1186, um campo de próximo status 1188, e pode incluir um campo de informação de status adicional 1190. i. Campo de Perfil

[00152] Em algumas modalidades, o campo de perfil 1184 inclui quatro bytes de dados que definem o perfil sob o qual a informação no presente relatório de status é para ser interpretada. Uma modalidade do campo de perfil 1184 é ilustrada na figura 17 com dois subcampos. Na modalidade ilustrada, o campo de perfil 1184 inclui um subcampo de Id de perfil 1192 que inclui dezesseis bits que corresponde a um identificador específico de vendedor para o perfil sob o qual o valor do campo de código de status 1186 é definido. O campo de perfil 1184 também pode incluir um subcampo de Id de vendedor 1194 que inclui dezesseis bits que identifica um vendedor provendo o perfil identificado no subcampo de Id de perfil 1192. ii. Código de Status

[00153] Em certas modalidades, o campo de código de status 1186 inclui dezesseis bits que codificam o status que está sendo reportado. Os valores no campo de código de status 1186 são interpretados em relação a valores codificados no subcampo de Id de perfil 1192 e no subcampo de Id de vendedor 1194 providos no campo de perfil 1184. Adicionalmente, em algumas modalidades, o espaço de código de status pode ser dividido em quatro grupos, conforme indicado na Tabela 8 abaixo.

Tabela 8. Tabela de Faixa de Código de Status Embora a Tabela 8 identifique faixas de código de status em geral que podem ser usadas separadamente atribuídas e usadas para cada Id de perfil específico, em algumas modalidades, alguns códigos de status podem ser comuns a cada um dos perfis. Por exemplo, estes perfis podem ser identificados usando-se um identificador de perfil comum (por exemplo, um perfil de núcleo), tal como 0x00000000. iii. Próximo Status

[00154] Em algumas modalidades, o campo de próximo código de status 1188 inclui oito bits. O campo de próximo código de status 1188 indica se há uma informação de status seguinte após o status reportado atualmente. Se uma informação de status seguinte for para ser incluída, o campo de próximo código de status 1188 indicará que tipo de informação de status é para ser incluída. Em algumas modalidades, o campo de próximo código de status 1188 pode sempre ser incluído, desse modo potencialmente se aumentando o tamanho da mensagem. Contudo, pela provisão de uma oportunidade para encadear uma informação de status em conjunto, o potencial para uma redução geral dos dados enviados pode ser reduzido. Se o campo de código de status 1186 for 0x00, nenhum campo de informação de status seguinte 1190 será incluído. Contudo, valores não nulos podem indicar que dados podem ser incluídos e indicar a forma pela qual os dados são incluídos (por exemplo, em um pacote de TLV). iv. Informação de Status Adicional

[00155] Quando o campo de próximo código de status 1188 é não nulo, o campo de informação de status seguinte 1190 é incluído na mensagem. Se presente, o campo de item de status pode conter um status em uma forma que pode ser determinada pelo valor do campo de tipo de status precedente (por exemplo, um formato de TLV). B. Atualização de Software

[00156] O perfil ou protocolo de atualização de software é um conjunto de esquemas e um protocolo de cliente / servidor que permite que os clientes sejam tornados cientes de ou busquem uma informação sobre a presença de um software que eles podem transferir (via download) e instalar. Usando-se o protocolo de atualização de software, uma imagem de software pode ser provida para o cliente de perfil em um formato conhecido para o cliente. O processamento subsequente da imagem de software pode ser genérico, específico de dispositivo ou específico de vendedor e determinado pelo protocolo de atualização de software e pelos dispositivos. i. Cabeçalhos de Aplicativo Gerais para a Carga Útil de Aplicativo

[00157] De modo a serem reconhecidos e manipulados apropriadamente, os quadros de perfil de atualização de software podem ser identificados no campo de carga útil de aplicativo 1146 do GMP 1128. Em algumas modalidades, todos os quadros de perfil de atualização de software podem usar um Id de perfil comum 1176, tal como 0x0000000C. Adicionalmente, os quadros de perfil de atualização de software podem incluir um campo de tipo de mensagem 1172 que indica uma informação adicional e pode escolher de acordo com a Tabela 9 abaixo e o tipo de mensagem sendo enviado.

Tabela 9. Tipos de mensagem de perfil de atualização de software. Adicionalmente, conforme descrito abaixo, a sequência de atualização de software pode ser iniciada por um servidor enviando a atualização como um anúncio de imagem ou um cliente recebendo a atualização como uma consulta de imagem. Em qualquer modalidade, um Id de troca 1174 a partir do evento se iniciando é usado para todas as mensagens usadas em relação com a atualização de software. ii. Sequência de Protocolo

[00158] A figura 18 ilustra uma modalidade de uma sequência de protocolo 1196 para uma atualização de software entre um cliente de atualização de software 1198 e um servidor de atualização de software 1200. Em certas modalidades, qualquer dispositivo na malha pode ser o cliente de atualização de software 1198 ou o servidor de atualização de software 1200. Certas modalidades da sequência de protocolo 1196 pode incluir etapas adicionais, tais como aquelas ilustradas como linhas tracejadas que podem ser omitidas em algumas transmissões de atualização de software. 1. Descoberta de Serviço

[00159] Em algumas modalidades, a sequência de protocolo 1196 começa um servidor de perfil de atualização de software anunciando a presença da atualização. Contudo, em outras modalidades, tal como a modalidade ilustrada, a sequência de protocolo 1196 começa com uma descoberta de serviço 1202, conforme discutido acima. 2. Anúncio de Imagem

[00160] Em algumas modalidades, uma mensagem de anúncio de imagem 1204 pode passar por multidifusão ou unidifusão pelo servidor de atualização de software 1200. A mensagem de anúncio de imagem 1204 informa aos dispositivos na malha que o servidor 1200 tem uma atualização de software a oferecer. Se a atualização for aplicável para o cliente 1198, mediante o recebimento da mensagem de anúncio de imagem 1204, o cliente de atualização de software 1198 responde com uma mensagem de consulta de imagem 1206. Em certas modalidades, a mensagem de anúncio de imagem 1204 pode não ser incluída na sequência de protocolo 1196. Ao invés disso, nessas modalidades, o cliente de atualização de software 1198 pode usar uma programação de interrogação para determinar quando enviar a mensagem de consulta de imagem 1206. 3. Consulta de Imagem

[00161] Em certas modalidades, a mensagem de consulta de imagem 1206 pode passar por uma unidifusão a partir do cliente de atualização de software 1198 em resposta a uma mensagem de anúncio de imagem 1204 ou de acordo com uma programação de interrogação, conforme discutido acima. A mensagem de consulta de imagem 1206 inclui uma informação a partir do cliente 1198 em si. Uma modalidade de um quadro da mensagem de consulta de imagem 1206 é ilustrada na figura 19. Conforme ilustrado na figura 19, certas modalidades da mensagem de consulta de imagem 1206 podem incluir um campo de controle de quadro 1218, um campo de especificação de produto 1220, um campo de dados específicos de vendedor 1222, um campo de especificação de versão 1224, um campo de especificação de local 1226, um campo suportado de tipo de integridade 1228 e um campo de esquemas de atualização suportados 1230. a. Controle de Quadro

[00162] O campo de controle de quadro 1218 inclui 1 byte e indica uma informação variada sobre a mensagem de anúncio de imagem 1204. Um exemplo do campo de controle de quadro 1218 é ilustrado na figura 20. Conforme ilustrado, o campo de controle de quadro 1218 pode incluir três subcampos: uma referência específica de vendedor 1232, uma referência de especificação de local 1234 e um campo reservado S3. A referência específica de vendedor 1232 indica se o campo de dados específicos de vendedor 1222 está incluído na mensagem de consulta de imagem de mensagem. Por exemplo, quando a referência específica de vendedor 1232 é 0, nenhum campo de dados específicos de vendedor 1222 pode estar presente na mensagem de consulta de imagem, mas, quando a referência específica de vendedor 1232 é 1, o campo de dados específicos de vendedor 1222 pode estar presente na mensagem de consulta de imagem, e um valor 0 indica que o campo de especificação de local 1226 não está presente na mensagem de consulta de imagem. b. Especificação de Produto

[00163] O campo de especificação de produto 1220 é um campo de seis bytes. Uma modalidade do campo de especificação de produto 1220 é ilustrada na figura 21. Conforme ilustrado, o campo de especificação de produto 1220 pode incluir três subcampos: um campo de Id de vendedor 1236, um campo de Id de produto 1238 e um campo de revisão de produto 1240. O campo de Id de vendedor 1236 inclui dezesseis bits que indicam um vendedor para o cliente de atualização de software 1198. O campo de Id de produto 1238 inclui dezesseis bits que indicam o produto de dispositivo que está enviando a mensagem de consulta de imagem 1206 como o cliente de atualização de software 1198. O campo de revisão de produto 1240 inclui dezesseis bits que indicam um atributo de revisão do cliente de atualização de software 1198. c. Dados Específicos de Vendedor

[00164] O campo de dados específicos de vendedor 1222, quando presente na mensagem de consulta de imagem 1206, tem um comprimento de número variável de bytes. A presença do campo de dados específicos de vendedor 1222 pode ser determinada a partir da referência específica de vendedor 1232 do campo de controle de quadro 1218. Quando presente, o campo de dados específicos de vendedor 1222 codifica uma informação específica de vendedor sobre o cliente de atualização de software 1198 em um formato de TLV, conforme descrito acima. d. Especificação de Versão

[00165] Uma modalidade do campo de especificação de versão 1224 é ilustrada na figura 22. O campo de especificação de versão 1224 inclui um número variável de bytes subdivididos em dois subcampos: um campo de comprimento de versão 1242 e um campo de string de versão 1244. O campo de comprimento de versão 1242 inclui oito bits que indicam um comprimento do campo de string de versão 1244. O campo de string de versão 1244 é de comprimento variável e determinado pelo campo de comprimento de versão 1242. Em algumas modalidades, o campo de string de versão 1244 pode ser capeado em 255 caracteres de UTF-8 no comprimento. O valor codificado no campo de string de versão 1244 indica um atributo de versão de software para o cliente de atualização de software 1198. e. Especificação de Local

[00166] Em certas modalidades, o campo de especificação de local 1226 pode ser incluído na mensagem de consulta de imagem 1206, quando a referência de especificação de local 1234 do controle de quadro 1218 for 1. Uma modalidade do campo de especificação de local 1226 é ilustrada na figura 23. A modalidade ilustrada do campo de especificação de local 1226 inclui um número variável de bytes dividido em dois subcampos: um campo de comprimento de string local 1246 e um campo de string local 1248. O campo de string local 1248 do campo de especificação de local 1226 pode ser variável no comprimento e conter uma string de caracteres de UTF-8 codificando uma descrição local com base em códigos locais de interface de sistema operacional portátil (POSIX). O formato padrão para códigos locais de POSIX é [language[_territory][.codeset][@modifier]]. Por exemplo, a representação POSIX para Inglês da Austrália é en_AU.UTF8. f. Tipos de Integridade Suportados

[00167] Uma modalidade do campo suportado de tipo de integridade 1228 é ilustrada na figura 24. O campo suportado de tipo de integridade 1228 inclui de dois a quatro bytes de dados divididos em dois subcampos: um campo de comprimento de lista de tipo 1250 e um campo de lista de tipo de integridade 1252. O campo de comprimento de lista de tipo 1250 inclui oito bits que indicam o comprimento em bytes do campo de lista de tipo de integridade 1252. O campo de lista de tipo de integridade 1252 indica o valor do atributo de tipo de integridade de atualização de software do cliente de atualização de software 1198. Em algumas modalidades, o tipo de integridade pode ser derivado a partir da Tabela 10 abaixo.

Tabela 10. Tipos de integridade de exemplo.

[00168] O campo de lista de tipo de integridade 1252 pode conter pelo menos um elemento a partir da Tabela 10 ou outros valores adicionais não incluídos. g. Esquemas de Atualização Suportados

[00169] Uma modalidade do campo de esquemas suportados 1230 é ilustrada na figura 25. O campo de esquemas suportados 1230 inclui um número variável de bytes divididos em dois subcampos: um campo de comprimento de lista de esquema 1254 e um campo de lista de esquema de atualização 1256. O campo de comprimento de lista de esquema 1254 inclui oito bits que indicam um comprimento do campo de lista de esquema de atualização em bytes. O campo de lista de esquema de atualização 1256 do campo suportado de esquemas de atualização 1222 é de comprimento variável determinado pelo campo de comprimento de lista de esquema 1254. O campo de lista de esquema de atualização 1256 representa atributos de esquemas de atualização do perfil de atualização de software do cliente de atualização de software 1198. Uma modalidade de valores de exemplo é mostrada na Tabela 11 abaixo.

Tabela 11. Esquemas de atualização de exemplo. Mediante o recebimento da mensagem de consulta de imagem 1206, o servidor de atualização de software 1200 usa a informação transmitida para determinar se o servidor de atualização de software 1200 tem uma atualização para o cliente de atualização de software 1198, e como mais bem entregar a atualização para o cliente de atualização de software 1198. 4. Resposta de Consulta de Imagem

[00170] Retornando à figura 18, após o servidor de atualização de software 1200 receber a mensagem de consulta de imagem 1206 a partir do cliente de atualização de software 1198, o servidor de atualização de software 1200 responde com uma resposta de consulta de imagem 1208. A resposta de consulta de imagem 1208 inclui uma qualquer detalhando a razão pela qual uma imagem de atualização não está disponível para o cliente de atualização de software 1198 ou uma informação sobre a atualização de imagem disponível para se permitir que o cliente de atualização de software 1198 transfira (via download) e instale a atualização.

[00171] Uma modalidade de um quadro da resposta de consulta de imagem 1208 é ilustrada na figura 26. Conforme ilustrado, a resposta de consulta de imagem 1208 inclui cinco subcampos possíveis: um campo de status de consulta 1258, um campo de identificador de recurso uniforme (URI) 1260, um campo de especificação de integridade 1262, um campo de esquema de atualização 1264 e um campo de opções de atualização 1266. a. Status de Consulta

[00172] O campo de status de consulta 1258 inclui um número variável de bytes e contém dados formatados reportando status, conforme discutido acima com referência ao relatório de status. Por exemplo, o campo de status de consulta 1258 pode incluir códigos de status de resposta de consulta de imagem, tais como aqueles ilustrados abaixo na Tabela 12.

. Tabela 12. Códigos de status de resposta de consulta de imagem de exemplo. b. URI

[00173] O campo de URI 1260 inclui um número variável de bytes. A presença do campo de URI 1260 pode ser determinada pelo campo de status de consulta 1258. Se o campo de status de consulta 1258 indicar que uma atualização está disponível, o campo de URI 1260 poderá ser incluído. Uma modalidade do campo de URI 1260 é ilustrada na figura 27. O campo de URI 1260 inclui dois subcampos: um campo de comprimento de URI 1268 e um campo de string de URI 1270. O campo de comprimento de URI 1268 inclui dezesseis bits que indicam o comprimento do campo de string de URI 1270 em caracteres de UTF-8. O campo de string de URI 1270 indica o atributo de URI da atualização de imagem de software sendo apresentada, de modo que o cliente de atualização de software 1198 possa ser capaz de localizar, transferir (via download) e instalar uma atualização de imagem de software, quando presente. c. Especificação de Integridade

[00174] O campo de especificação de integridade 1262 pode ser de comprimento variável e estar presente quando o campo de status de consulta 1258 indicar que uma atualização está disponível a partir do servidor de atualização de software 1200 para o cliente de atualização de software 1198. Uma modalidade do campo de especificação de in-tegridade 1262 é ilustrada na figura 28. Conforme ilustrado, o campo de especificação de integridade 1262 inclui dois subcampos: um campo de tipo de integridade 1272 e um campo de valor de integridade 1274. O campo de tipo de integridade 1272 inclui oito bits que indicam um atributo de tipo de integridade para a atualização de imagem de software e podem ser preenchidos usando-se uma lista similar àquela ilustrada na Tabela 10 acima. O campo de valor de integridade 1274 inclui o valor de integridade que é usado para verificar que a mensagem de atualização de imagem manteve a integridade durante a transmissão. d. Esquema de Atualização

[00175] O campo de esquema de atualização 1264 inclui oito bits e está presente quando o campo de status de consulta 1258 indica que uma atualização está disponível a partir do servidor de atualização de software 1200 para o cliente de atualização de software 1198. Se presente, o campo de esquema de atualização 1264 indica um atributo de esquema para a imagem de atualização de software sendo apresentada para o servidor de atualização de software 1200. e. Opções de Atualização

[00176] O campo de opções de atualização 1266 inclui oito bits e está presente quando o campo de status de consulta 1258 indica que uma atualização está disponível a partir do servidor de atualização de software 1200 para o cliente de atualização de software 1198. O campo de opções de atualização 1266 pode ser subdividido conforme ilustrado na figura 29. Conforme ilustrado, o campo de opções de atualização 1266 inclui quatro subcampos: um campo de prioridade de atualização 1276, um campo de condição de atualização 1278, uma referência de status de relatório 1280 e um campo reservado 1282. Em algumas modalidades, o campo de prioridade de atualização 1276 in- clui dois bits. O campo de prioridade de atualização 1276 indica um atributo de prioridade da atualização e pode ser determinado usando- se valores, tais como aqueles ilustrados na Tabela 13 abaixo.

Tabela 13. Valores de prioridade de atualização de exemplo. O campo de condição de atualização 1278 inclui três bits que podem ser usados para a determinação de fatores condicionais para se determinar quando ou se é para atualizar. Por exemplo, os valores no campo de condição de atualização 1278 podem ser decodificados usando-se a Tabela 14 abaixo.

Tabela 14. Condições de atualização de exemplo. A referência de status de relatório 1280 é um bit único que indica se o cliente de atualização de software 1198 deve responder com uma mensagem de notificação de transferência (via download) 1210. Se a referência de status de relatório 1280 for regulada para 1, o cliente de atualização de software 1198 estará requisitando que uma mensagem de notificação de transferência (via download) 1210 seja enviada após a atualização de software ser transferida (via download) pelo cliente de atualização de software 1198.

[00177] Se a resposta de consulta de imagem 1208 indicar que uma atualização está disponível. O cliente de atualização de software 1198 transfere (via download) 1210 a atualização usando a informação incluída na resposta de consulta de imagem 1208 em um tempo indicado na resposta de consulta de imagem 1208. 5. Notificação de Transferência (via Download)

[00178] Após a transferência (via download) de atualização 1210 ser completada de forma bem-sucedida ou ter falhado e a referência de status de relatório 1280 ser 1, o cliente de atualização de software 1198 pode responder com a mensagem de notificação de transferência (via download) 1212. A mensagem de notificação de transferência (via download) 1210 pode ser formatada de acordo com o formato de relatório de status discutido acima. Um exemplo de códigos de status usados na mensagem de notificação de transferência (via download) 1212 é ilustrado na Tabela 15 abaixo.

Tabela 15. Códigos de status de notificação de transferência (via download) de exemplo. Além do relatório de status descrito acima, a resposta de consulta de imagem 1208 pode incluir uma informação de status adicional que pode ser relevante para a transferência (via download) e/ou a falha na transferência (via download). 6. Resposta de Notificação

[00179] O servidor de atualização de software 1200

Tabela 16. Códigos de status de notificação de transferência (via download) de exemplo Além do relatório de status descrito acima, a 1214 pode incluir uma informação de status adicional que pode ser relevante para a transferência (via download), a atualização e/ou a falha na transferência (via download) / atualização da atualização de software. 7. Notificação de Atualização

[00180] Após a atualização ter sido completada de forma bem su- cedida ou ter falhado e o valor de referência de status de relatório 1280 ser 1, o cliente de atualização de software 1198 pode responder com a mensagem de notificação de atualização 1216. A mensagem de notificação de atualização 1216 pode usar o formato de relatório de status descrito acima. Por exemplo, a mensagem de notificação de atualização 1216 pode incluir códigos de status conforme enumerado na Tabela 17 abaixo.

Tabela 17. Códigos de status de notificação de atualização de exemplo. Além do relatório de status descrito acima, a mensagem de notificação de atualização 1216 pode incluir uma informação de status adicional que pode ser relevante para a atualização e/ou a falha na atualização. C. Protocolo de Gerenciamento de Dados

[00181] Um gerenciamento de dados pode ser incluído em um perfil comum (por exemplo, um perfil de núcleo) usado em vários dispositivos eletrônicos na malha, ou pode ser projetado como um perfil em separado. Em uma situação, o protocolo de gerenciamento de dispositivo (DMP) pode ser usado para nós para navegação, compartilhamento e/ou atualização de uma informação residente em nó. Uma sequência 1284 usado no DMP é ilustrada na figura 30. A sequência 1284 ilustra um nó de visualização 1286 que requisita uma visualização e/ou mudança de dados residentes de um nó visualizado 1288. Adicionalmente, o nó de visualização 1286 pode requisitar a visualização dos dados residentes usando-se uma das várias opções de visualização, tal como uma requisição de instantâneo, uma requisição de assistên- cia que a visualização persista por um período de tempo, ou outro tipo de visualização adequado. Cada mensagem segue o formato para a campo de carga útil de aplicativo 1146 descrito com referência à figura 15. Por exemplo, cada mensagem contém um Id de perfil 1176 que corresponde ao perfil de gerenciamento de dados e/ou o perfil de núcleo relevante, tal como 0x235A0000. Cada mensagem também contém um tipo de mensagem 1172. O tipo de mensagem 1172 pode ser usado para a determinação de vários fatores relativos à conversação, tal como o tipo de visualização para visualização. Por exemplo, em algumas modalidades, o campo de tipo de mensagem 1172 pode ser codificado / decodificado de acordo com a Tabela 18 abaixo.

Tabela 18. Tipos de mensagem de perfil de atualização de software de exemplo. i. Requisição de Visualização

[00182] Embora uma mensagem de requisição de visualização 1290 requisite a visualização de dados residentes em nó, o tipo de requisição pode ser determinado pelo campo de tipo de mensagem 1172, conforme discutido acima. Assim sendo, cada tipo de requisição pode incluir um quadro de requisição de visualização diferente. 1. Requisição de Instantâneo

[00183] Uma requisição de instantâneo pode ser enviada pelo nó de visualização 1286 quando o nó de visualização 1286 deseja uma visu-alização instantânea dos dados residentes em nó no nó visualizado 1288, sem a requisição de atualizações futuras. Uma modalidade de um quadro de requisição de instantâneo 1292 é ilustrada na figura 31.

[00184] Conforme ilustrado na figura 31, o quadro de requisição de instantâneo 1292 pode ser de comprimento variável e incluir três campos: um campo de manipulação de visualização 1294, um campo de lista de comprimento de percurso 1296 e um campo de lista de percurso 1298. O campo de manipulação de visualização 1294 pode incluir dois bits que proveem uma "manipulação" para a identificação da visualização requisitada. Em algumas modalidades, o campo de manipulação de visualização 1294 é preenchido usando-se um número randô- mico de 16 bits ou um número de sequência de 16 bits juntamente com uma checagem de singularidade executada no nó de visualização 1286, quando a requisição for formada. O campo de lista de comprimento de percurso 1296 inclui dois bytes que indicam um comprimento do campo de lista de percurso 1298. O campo de lista de percurso 1298 é de comprimento variável e indicado pelo valor do campo de lista de comprimento de percurso 1296. O valor do campo de lista de percurso 1298 indica um percurso de esquema para os nós.

[00185] Um percurso de esquema é uma descrição compacta para um item de dados ou contêiner que faz parte de um esquema residente nos nós. Por exemplo, a figura 32 provê um exemplo de um esquema de perfil 1300. No esquema de perfil ilustrado 1300, um item de percurso para dados 1302 pode ser escrito como "Foo:bicycle:mountain" em um formato binário. O formato binário do percurso pode ser representado como um formato binário de perfil 1304, conforme descrito na figura 33. O formato binário de perfil 1304 inclui dois subcampos: um campo de identificador de perfil 1306 e um campo de dados de TLV 1308. O campo de identificador de perfil 1306 identifica qual perfil está sendo referenciado (por exemplo, o perfil Foo). O campo de dados de TLV 1308 é uma informação de percurso. Conforme discutido previamente, os dados de TLV incluem um campo de etiqueta que inclui uma informação sobre os dados encerrados. Os valores de campo usados para referência ao perfil Foo da figura 32 podem ser similares àqueles valores listados na Tabela 19.

Tabela 19. Valores de etiqueta para o perfil Foo.

[00186] Usando a Tabela 19 e o perfil Foo da figura 32, uma string binária em um formato de TLV representando o percurso "Foo:bicycle:mountain" pode ser representada conforme mostrado na Tabela 20 abaixo.

Tabela 20. Lista de etiqueta binária de exemplo para percurso de es-quema.

[00187] Se o nó de visualização 1286 desejar receber um conjunto de dados inteiro definido em um esquema de perfil (por exemplo, um esquema de perfil Foo da figura 33), a mensagem de requisição de visualização 1290 poderá requisitar um item "nulo" (por exemplo, 0x0D00 TL) e um comprimento vazio com referência ao contêiner.

2. Requisição de Assistência

[00188] Se o nó de visualização 1286 desejar mais do que um instantâneo, o nó de visualização 1286 poderá requisitar uma requisição de assistência. Uma requisição de assistência pede ao nó visualizado 1288 para enviar atualizações, quando as mudanças forem feitas nos dados de interesse no nó visualizado 1288, de modo que o nó de visualização 1286 possa manter uma lista sincronizada dos dados. O quadro de requisição de assistência pode ter um formato diferente da requisição de instantâneo da figura 31. Uma modalidade de um quadro de requisição de assistência 1310 é ilustrada na figura 34. O quadro de requisição de assistência 1310 inclui quatro campos: um campo de manipulação de visualização 1312, um campo de comprimento de lista de percurso 1314, um campo de lista de percurso 1316 e um campo de contagem de mudança 1318. O campo de manipulação de visualização 1312, o campo de comprimento de lista de percurso 1314 e o campo de lista de percurso podem ser respectivamente formatados similares ao campo de manipulação de visualização 1294, ao campo de lista de comprimento de percurso 1296 e ao campo de lista de percurso 1298 da requisição de instantâneo da figura 31. O campo adici-onal, o campo de contagem de mudança 1318, indica um limite de um número de mudanças nos dados requisitados nos quais uma atualização é enviada para o nó de visualização 1286. Em algumas modalidades, se o valor do campo de contagem de mudança 1318 for 0, o nó visualizado 1288 poderá determinar quando enviar uma atualização por si mesmo. Se o valor do campo de contagem de mudança 1318 for não nulo, então, após um número de mudanças igual ao valor, então, uma atualização será enviada para o nó de visualização 1286.

3. Requisição de Atualização Periódica

[00189] Um terceiro tipo de visualização também pode ser requisitado pelo nó de visualização 1286. Este terceiro tipo de visualização é referido como uma atualização periódica. Uma atualização periódica inclui uma visualização de instantâneo, bem como atualizações periódicas. Conforme pode ser entendido, uma requisição de atualização periódica pode ser similar à requisição de instantâneo com uma informação adicional determinando o período de atualização. Por exemplo, uma modalidade de um quadro de requisição de atualização periódica 1320 é descrito na figura 35. O quadro de requisição de atualização periódica 1320 inclui quatro campos: um campo de manipulação de visualização 1322, um campo de comprimento de lista de percurso 1324, um campo de lista de percurso 1326 e um campo de período de atualização 1328. O campo de manipulação de visualização 1322, o campo de comprimento de lista de percurso 1324 e o campo de lista de percurso 1326 podem ser formatados similares a seus respectivos campos no quadro de requisição de instantâneo 1292. O campo de período de atualização 1328 é de quatro bytes de comprimento e contém um valor que corresponde a um período de tempo a decorrer entre atualizações em uma unidade de tempo relevante (por exemplo, segundos).

4. Requisição de Renovação

[00190] Quando o nó de visualização 1286 deseja receber um instantâneo atualizado, o nó de visualização 1286 pode enviar uma mensagem de requisição de visualização 1290 na forma de um quadro de requisição de renovação 1330, conforme ilustrado na figura 36. O quadro de requisição de renovação 1330 essencialmente reenvia um campo de manipulação de visualização de instantâneo (por exemplo, o campo de manipulação de visualização 1294) a partir de uma requisi- ção de instantâneo prévia que o nó visualizado 1288 pode reconhecer como uma requisição prévia usando-se o valor de manipulação de vi-sualização no quadro de requisição de renovação 1330.

5. Requisição de Cancelamento de Visualização

[00191] Quando o nó de visualização 1286 deseja cancelar uma visualização em andamento (por exemplo, uma atualização periódica ou uma visualização de assistência), o nó de visualização 1286 pode enviar uma mensagem de requisição de visualização 1290 na forma de um quadro de requisição de cancelamento de visualização 1332, conforme ilustrado na figura 37. O quadro de requisição de cancelamento de visualização 1332 essencialmente reenvia um campo de manipulação de visualização a partir de uma atualização periódica ou uma visualização de assistência (por exemplo, os campos de manipulação de visualização 1310 ou 1322) a partir de uma requisição prévia que o nó visualizado 1288 pode reconhecer como uma requisição prévia usando o valor de manipulação de visualização no quadro de requisição de renovação 1330 e para cancelar uma atualização periódica ou uma visualização de assistência atualmente. ii. Resposta de Visualização

[00192] Retornando para a figura 30, após o nó visualizado 1288 receber uma mensagem de requisição de visualização 1290, o nó visualizado 1288 responde com uma mensagem de resposta de visualização 1334. Um exemplo de um quadro de mensagem de resposta de visualização 1336 inclui três campos: um campo de manipulação de visualização 1338, um campo de status de requisição de visualização 1240 e uma lista de item de dados 1242. O campo de manipulação de visualização 1338 pode ser formatado de modo similar a qualquer um dos campos de manipulação de visualização referenciados acima 1338. Adicionalmente, o campo de manipulação de visualização 1338 contém um valor que combina com um respectivo campo de manipula- ção e visualização a partir da mensagem de requisição de visualização 1290 à qual a mensagem de resposta de visualização 1334 está res-pondendo. O campo de status de requisição de visualização 1340 é um campo de comprimento variável que indica um status da requisição de visualização e pode ser formatado de acordo com o formato de atualização de status discutido acima. O campo de lista de item de dados 1342 é um campo de comprimento variável que está presente quando o campo de status de requisição de visualização 1340 indicar que a requisição de visualização foi bem-sucedida. Quando presente, o campo de lista de item de dados 1342 contém uma lista ordenada de dados requisitados correspondentes à lista de percurso da mensagem de requisição de visualização 1290. Mais ainda, os dados no campo de lista de item de dados 1342 podem ser codificados em um formato de TLV, conforme discutido acima. iii. Requisição de Atualização

[00193] Conforme discutido acima, em algumas modalidades, o nó visualizado 1288 pode enviar atualizações para o nó de visualização 1286. Estas atualizações podem ser enviadas como uma mensagem de requisição de atualização 1344. A mensagem de requisição de atualização 1344 pode incluir um formato especificado dependente de um tipo de requisição de atualização. Por exemplo, uma requisição de atualização pode ser uma requisição de atualização explícita ou um campo de requisição de atualização e visualização que pode ser identificado pelo Id de mensagem 1172.

1. Requisição de Atualização Explícita

[00194] Uma requisição de atualização explícita pode ser transmitida em qualquer momento como resultado de um desejo por informação a partir de um outro nó na malha 1000. Uma requisição de atualização explícita pode ser formatada em um quadro de requisição de atualização 1346 ilustrado na figura 39. O quadro de requisição de atualização ilustrado 1346 inclui quatro campos: um campo de manipu-lação de atualização 1348, um campo de comprimento de lista de percurso 1350, um campo de lista de percurso 1352 e um campo de lista de item de dados 1354.

[00195] O campo de manipulação de atualização 1348 inclui dois bytes que podem ser preenchidos com números randômicos ou sequenciais com checagens de singularidade para a identificação de uma requisição de atualização, ou respostas à requisição. O campo de comprimento de lista de percurso 1350 inclui dois bytes que indicam um comprimento do campo de lista de percurso 1352. O campo de lista de percurso 1352 é um campo de comprimento variável que indica uma sequência de percursos, conforme descrito acima. O campo de lista de item de dados 1354 pode ser formatado de modo similar ao campo de lista de item de dados 1242.

2. Requisição de Atualização de Visualização

[00196] Uma mensagem de requisição de atualização de visualização pode ser transmitida por um nó que requisitou previamente uma visualização em um esquema de um outro nó ou um nó que estabeleceu uma visualização em seus próprios dados em nome de um outro nó. Uma modalidade de um quadro de requisição de atualização de visualização 1356 é ilustrado na figura 40. O quadro de requisição de atualização de visualização 1356 inclui quatro campos: um campo de manipulação de atualização 1358, um campo de manipulação de visualização 1360, um campo de comprimento de lista de item de atualização 1362 e um campo de lista de item de atualização 1364. O campo de manipulação de atualização 1358 pode ser composto usando-se o formato descrito acima com referência ao campo de manipulação de atualização 1348. O campo de manipulação de visualização 1360 inclui dois bytes que identificam a visualização criada por uma mensagem de requisição de visualização relevante 1290 tendo a mesma ma- nipulação de visualização. O campo de comprimento de lista de item de atualização 1362 inclui dois bytes e indica o número de itens de atualização que são incluídos no campo de lista de item de atualização 1364.

[00197] O campo de lista de item de atualização 1364 inclui um número variável de bytes e lista os itens de dados constituindo os valores atualizados. Cada lista de item atualizado pode incluir múltiplos itens de atualização. Os itens de atualização individuais são formatados de modo conforme com o quadro de item de atualização 1366 ilustrado na figura 41. Cada quadro de item de atualização 1366 inclui três subcampos: um campo de índice de item 1368, um campo de estampa de tempo de item 1370 e um campo de item de dados 1372. O campo de índice de item 1368 inclui dois bytes que indicam a visualização sob a qual a atualização está sendo requisitada e o índice na lista de percurso daquela visualização para o campo de item de dados 1372.

[00198] O campo de estampa de tempo de item 1370 inclui quatro bytes e indica o tempo decorrido (por exemplo, em segundos) a partir da mudança, até a atualização sendo comunicada ter sido feita. Se mais de uma mudança tiver sido feita no item de dados, o campo de estampa de tempo de item 1370 poderá indicar a mudança mais recente ou a mais antiga. O campo de item de dados 1372 é um campo de comprimento variável codificado em formato de TLV que é para ser recebido como a informação atualizada. iv. Resposta de Atualização

[00199] Após uma atualização ser recebida, um nó (por exemplo, um nó de visualização 1286) pode enviar uma mensagem de resposta de atualização 1374. A mensagem de resposta de atualização 1374 pode ser codificada usando-se um quadro de resposta de atualização 1376 ilustrado na figura 42. O quadro de resposta de atualização 1376 inclui dois campos: um campo de manipulação de atualização 1378 e um campo de status de requisição de atualização 1380. O campo de manipulação de atualização 1378 corresponde a um valor de campo de manipulação de atualização da mensagem de requisição de atualização 1344 à qual a mensagem de resposta de atualização 1374 está respondendo. O campo de status de requisição de atualização 1380 reporta um status da atualização de acordo com o formato de relatório de status discutido acima. Adicionalmente, um perfil usando DMP (por exemplo, um perfil de núcleo ou um perfil de gerenciamento de dados) pode incluir códigos específicos de perfil, tais como aqueles enumerados na Tabela 21 abaixo.

Tabela 21. Exemplo de cód igos de status para um perfil incluindo o DMP. D. Transferência em massa

[00200] Em algumas modalidades, pode ser desejável transferir arquivos de dados em massa (por exemplo, dados de sensor, registros ou imagens de atualização) entre nós / serviços na malha 1000. Para se permitir a transferência de dados em massa, um perfil ou protocolo em separado pode ser incorporado em um ou mais perfis e tornado disponível para os nós / serviços nos nós. O protocolo de transferência de dados em massa pode modelar arquivos de dados como coleções de dados com anexos de metadados. Em certas modalidades, os dados podem ser opacos, mas os metadados podem ser usados para se determinar se é para prosseguir com uma transferência de arquivo requisitada.

[00201] Os dispositivos participantes em uma transferência em massa podem ser geralmente divididos de acordo com a comunicação de transferência em massa e criação de evento. Conforme ilustrado na figura 43, cada comunicação 1400 em uma transferência em massa inclui um emissor 1402 que é um nó / serviço que envia os dados em massa 1404 para um receptor 1406 que é um nó / serviço que recebe os dados em massa 1404. Em algumas modalidades, o receptor pode enviar uma informação de status 1408 para o emissor 1402 indicando um status da transferência em massa. Adicionalmente, um evento de transferência em massa pode ser iniciado pelo emissor 1402 (por exemplo, uma transferência (via upload)) ou pelo receptor 1406 (por exemplo, uma transferência (via download)) como o iniciador. Um nó / serviço que responde ao iniciador pode ser referido como o responde- dor na transferência de dados em massa.

[00202] A transferência de dados pode ocorrer usando-se modos síncronos ou assíncronos. O modo no qual os dados são transferidos pode ser determinado usando-se uma variedade de fatores, tal como o protocolo subjacente (por exemplo, UDP ou TCP) no qual os dados em massa são enviados. Em protocolos sem conexão (por exemplo, UDP), os dados em massa podem ser transferidos usando-se um modo síncrono que permite que um dos nós / serviços ("o driver") controle uma taxa na qual a transferência prossegue. Em certas modalidades, após cada mensagem em uma transferência de dados em massa de modo síncrono, um reconhecimento pode ser enviado, antes do envio da próxima mensagem na transferência de dados em massa. O driver pode ser o emissor 1402 ou o receptor 1406. Em algumas modalidades, o driver pode alternar entre um estado ativado e um modo desativado, enquanto se enviam mensagens para avançar a transferência, quando no estado ativado. Em transferências de dados em massa usando protocolos orientados para conexão (por exemplo, TCP), os dados em massa podem ser transferidos usando-se um modo assíncrono que não usa um reconhecimento, antes do envio de mensagens sucessivas ou um driver único.

[00203] Independentemente de a transferência de dados em massa ser realizada usando-se um modo síncrono ou assíncrono, um tipo de mensagem pode ser determinado usando-se um tipo de mensagem 1172 na carga útil de aplicativo 1146 de acordo com o Id de perfil 1176 na carga útil de aplicativo. A Tabela 22 inclui um exemplo de tipos de mensagem que podem ser usados em relação a um valor de perfil de transferência de dados em massa no Id de perfil 1176.

Tabela 22. Exemplos de tipos de mensagem de perfis de transferência de dados em massa. i. SendInit

[00204] Uma modalidade de uma mensagem SendInit 1420 é ilustrada na figura 44. A mensagem SendInit 1420 pode incluir sete campos: um campo de controle de transferência 1422, um campo de controle de faixa 1424, um campo de comprimento de designador de arquivo 1426, um campo de tamanho de bloco máximo proposto 1428, um campo de deslocamento de começo 1430, um campo de comprimento 1432 e um campo de designador de arquivo 1434.

[00205] O campo de controle de transferência 1422 inclui um byte de dados ilustrado na figura 45. O campo de controle de transferência inclui pelo menos quatro campos: uma referência Asynch 1450, uma referência RDrive 1452, uma referência SDrive 1454 e um campo de versão 1456. A referência Asynch 1450 indica se a transferência proposta pode ser realizada usando-se um modo síncrono ou assíncrono. A referência RDrive 1452 e a referência SDrive 1454, cada um, res-pectivamente, indicam se o receptor 1406 é capaz de transferir dados com o emissor 1402 ou o emissor 1402 comandando uma transferência de modo síncrono.

[00206] O campo de controle de faixa 1424 inclui um byte de dados, tal como o campo de controle de faixa 1424 ilustrado na figura 46. Na modalidade ilustrada, o campo de controle de faixa 1424 inclui pelo menos três campos: uma referência BigExtent 1470, uma referência de deslocamento de começo 1472 e uma referência de comprimento definido 1474. A referência de comprimento definido 1474 indica se a transferência tem um comprimento definido. A referência de comprimento definido 1474 indica se o campo de comprimento 1432 está presente na mensagem SendInit 1420, e a referência BigExtent 1470 indica um tamanho para o campo de comprimento 1432. Por exemplo, em algumas modalidades, um valor de 1 na referência BigExtent 1470 indica que o campo de comprimento 1432 é de oito bytes. Caso contrário, o campo de comprimento 1432 é de quatro bytes, quando presente. Se a transferência tiver um comprimento definido, a referência de deslocamento de começo 1472 indicará se um deslocamento de começo está presente. Se um deslocamento de começo estiver presente, a referência BigExtent 1470 indicará um comprimento para o campo de deslocamento de começo 1430. Por exemplo, em algumas modalidades, um valor de 1 na referência BigExtent 1470 indica que o campo de deslocamento de começo 1430 é de oito bytes. Caso contrário, o campo de deslocamento de começo 1430 é de quatro bytes, quando presente.

[00207] Retornando à figura 44, o campo de comprimento de desig- nador de arquivo 1426 inclui dois bytes que indicam um comprimento do campo de designador de arquivo 1434. O campo de designador de arquivo 1434 é um campo de comprimento variável dependente do campo de comprimento de designador de arquivo 1426. O campo de tamanho de bloco máximo 1428 propõe um tamanho máximo de bloco que pode ser transferido em uma única transferência.

[00208] O campo de deslocamento de começo 1430, quando presente, tem um comprimento indicado pela referência BigExtent 1470. O valor do campo de deslocamento de começo 1430 indica uma localização no arquivo a ser transferido a partir da qual o emissor 1402 pode começar a transferência, essencialmente permitindo que transferências de arquivo grande sejam segmentadas em múltiplas sessões de transferência em massa.

[00209] O campo de comprimento 1432, quando presente, indica um comprimento do arquivo a ser transferido, se a referência de comprimento definido 1474 indicar que o arquivo tem um comprimento definido. Em algumas modalidades, se o receptor 1406 receber um bloco final, antes de o comprimento ser atingido, o receptor poderá considerar que a transmissão falhou e reportar um erro, conforme discutido abaixo.

[00210] O campo de designador de arquivo 1434 é um identificador de comprimento variável escolhido pelo emissor 1402 para a identificação do arquivo a ser enviado. Em algumas modalidades, o emissor 1402 e o receptor 1406 podem negociar o identificador para o arquivo, antes da transmissão. Em outras modalidades, o receptor 1406 pode usar metadados juntamente com o campo de designador de arquivo 1434 para determinar se é para aceitar a transferência e como manipular os dados. O comprimento do campo de designador de arquivo 1434 pode ser determinado a partir do campo de comprimento de de- signador de arquivo 1426. Em algumas modalidades, a mensagem SendInit 1420 também pode incluir um campo de metadados 1480 de um comprimento variável codificado em um formato de TLV. O campo de metadados 1480 permite que o iniciador envie uma informação adicional, tal como uma informação específica de aplicativo, sobre o arquivo a ser transferido. Em algumas modalidades, o campo de metadados 1480 pode ser usado para se evitar negociar com o campo de designador de arquivo 1434, antes da transferência de dados em massa. ii. SendAccept

[00211] Uma mensagem de aceitação de envio é transmitida a partir do respondedor para indicar o modo de transferência escolhido para a transferência. Uma modalidade de uma mensagem SendAccept 1500 é apresentada na figura 47. A mensagem SendAccept 1500 inclui um campo de controle de transferência 1502 similar ao campo de controle de transferência 1422 da mensagem SendInit 1420. Contudo, em algumas modalidades, apenas a referência RDrive 1452 ou o SDri- ve 1454 podem ter um valor não nulo no campo de controle de transferência 1502 para a identificação do emissor 1402 ou do receptor 1406 como o driver de uma transferência de modo síncrono. A mensagem SendAccept 1500 também inclui um campo de tamanho de bloco máximo 1504 que indica um tamanho de bloco máximo para a transferência. O campo de tamanho de bloco máximo 1504 pode ser igual ao valor do campo de tamanho de bloco máximo proposto 1428 da mensagem SendInit 1420, mas o valor do campo de tamanho de bloco máximo 1504 pode ser menor do que o valor proposto no campo de bloco máximo 1428. Finalmente, a mensagem SendAccept 1500 pode incluir um campo de metadados 1506 que indica uma informação que o receptor 1406 pode passar para o emissor 1402 sobre a transferência. iii. SendReject

[00212] Quando o receptor 1406 rejeita uma transferência após uma mensagem SendInit, o receptor 1406 pode enviar uma mensagem SendReject que indica que um ou mais problemas existem com respeito à transferência de dados em massa entre o emissor 1402 e o receptor 1406. A mensagem de rejeição de envio pode ser formatada de acordo com o formato de relatório de status descrito acima e ilustrado na figura 48. Um quadro de rejeição de envio 1520 pode incluir um campo de código de status 1522 que inclui dois bytes que indicam uma razão para a rejeição da transferência. O campo de código de status 1522 pode ser decodificado usando-se valores similares àqueles enumerados conforme indicado na Tabela 23 abaixo.

Tabela 23. Códigos d e status de exemplo para uma mensagem de re- jeição de envio.

[00213] Em algumas modalidades, a mensagem de rejeição de envio 1520 pode incluir um campo de próximo status 1524. O campo de próximo status 1524, quando presente, pode ser formatado e codificado conforme discutido acima com respeito ao campo de próximo código de status 1188 de um quadro de relatório de status. Em certas modalidades, a mensagem de rejeição de envio 1520 pode incluir um campo de informação adicional 1526. O campo de informação adicional 1526, quando presente, pode armazenar uma informação sobre um status adicional e pode ser codificado usando-se o formato de TLV discutido acima. iv. ReceiveInit

[00214] Uma mensagem ReceiveInit pode ser transmitida pelo receptor 1406 como o iniciador. A mensagem ReceiveInit pode ser formatada e codificada de modo similar à mensagem SendInit 1420 ilustrada na figura 44, mas o campo de BigExtent 1470 pode ser referido como um campo de comprimento máximo que especifica o tamanho de arquivo máximo que o receptor 1406 pode manipular. v. ReceiveAccept

[00215] Quando o emissor 1402 recebe uma mensagem ReceiveI- nit, o emissor 1402 pode responder com uma mensagem ReceiveAc- cept. A mensagem ReceiveAccept pode ser formatada e codificada como a mensagem ReceiveAccept 1540 ilustrada na figura 49. A mensagem ReceiveAccept 1540 pode incluir quatro campos: um campo de controle de transferência 1542, um campo de controle de faixa 1544, um campo de tamanho de bloco máximo 1546 e, às vezes, um campo de comprimento 1548. A mensagem ReceiveAccept 1540 pode ser formatada de modo similar à mensagem SendAccept 1500 da figura 47, com o segundo byte indicando o campo de controle de faixa 1544. Mais ainda, o campo de controle de faixa 1544 pode ser formatado e codificado usando-se os mesmos métodos discutidos acima com referência ao campo de controle de faixa 1424 da figura 46. vi. ReceiveReject

[00216] Se o emissor 1402 encontrar um problema com a transferência do arquivo para o receptor 1406, o emissor 1402 poderá enviar uma mensagem ReceiveReject formatada e codificada de forma similar a uma mensagem SendReject 48 usando o formato de relatório de status, ambos discutidos acima. Contudo, o campo de código de status 1522 pode ser codificado / decodificado usando-se valores similares àqueles enumerados conforme indicado na Tabela 24 abaixo.

Tabela 24. Códigos d e status de exemplo para uma mensagem de re- jeição de recepção. vii. BlockQuery

[00217] Uma mensagem BlockQuery pode ser enviada por um emissor 1402 conduzindo em uma transferência de dados em massa de modo síncrono para requisitar o próximo bloco de dados. Uma BlockQuery reconhece de forma implícita um bloco prévio de dados, se um reconhecimento explícito não tiver sido enviado. Em modalidades usando transferências assíncronas, uma mensagem BlockQuery pode ser omitida do processo de transmissão. vii. Block

[00218] Os blocos de dados transmitidos em uma transferência de dados em massa podem incluir qualquer comprimento maior do que 0 e menor do que um tamanho de bloco máximo acordado pelo emissor 1402 e pelo receptor 1406. ix. BlockEOF

[00219] Um bloco final em uma transferência de dados pode ser apresentado como um fim de arquivo de bloco (BlockEOF). O BlockE- OF pode ter um comprimento entre 0 e um tamanho de bloco máximo. Se o receptor 1406 encontrar uma discrepância entre um tamanho de arquivo pré-negociado (por exemplo, o campo de comprimento 1432) e a quantidade de dados realmente transmitida, o receptor 1406 poderá enviar uma mensagem de erro indicando a falha, conforme discutido abaixo. x. Ack

[00220] Se o emissor 1402 estiver conduzindo uma transferência de modo síncrono, o emissor 1402 poderá esperar até o recebimento de um reconhecimento (Ack) após o envio de um bloco, antes do envio do próximo bloco. Se o receptor estiver conduzindo uma transferência de modo síncrono, o receptor 1406 poderá enviar um Ack explícito ou uma BlockQuery para reconhecimento do recebimento do bloco prévio. Mais ainda, em transferências em massa de modo assíncrono, a mensagem Ack pode ser omitida do processo de transmissão de toda forma. xi. AckEOF

[00221] Um reconhecimento de um fim de arquivo (AckEOF) pode ser enviado em transferências em massa enviadas em modo síncrono ou modo assíncrono. Usando o AckEOF, o receptor 1406 indica que todos os dados na transferência foram recebidos e os sinaliza o fim da sessão de transferência de dados em massa. xii. Error

[00222] Na ocorrência de certos problemas na comunicação, o emissor 1402 ou o receptor 1406 pode enviar uma mensagem de erro para prematuramente terminar a sessão de transferência de dados em massa. As mensagens de erro podem ser formatadas e codificadas de acordo com o formato de relatório status discutido acima. Por exemplo, uma mensagem de erro pode ser formatada de modo similar ao quadro de SendReject 1520 da figura 48. Contudo, os códigos de status podem ser codificados / decodificados com valores incluindo e/ou similares àqueles enumerados na Tabela 25 abaixo.

Tabela 25. Códigos de status de exemplo para uma mensagem de erro em um perfil de transferência de dados em massa.

[00223] As modalidades específicas descritas acima foram mostra- das a título de exemplo, e deve ser entendido que estas modalidades podem ser susceptíveis a várias modificações e formas alternativas. Deve ser entendido, ainda, que as concretizações não são pretendidas para serem limitadas às formas expostas em particular, mas, ao invés disso, para cobrirem todas as modificações, equivalentes e alternativas caindo no espírito e no escopo desta exposição.

Claims

1. Meio legível em computador não transitório, tendo arma-zenado nele um formato de mensagem, caracterizado pelo fato de que o formato de mensagem compreende: um campo de cabeçalho de mensagem (1132) compreen-dendo: um indicador de versão (1156) para indicar uma versão do formato de mensagem usado para formatar a mensagem; um indicador de endereçamento (1158, 1160) para indicar se uma informação de endereçamento está incluída na mensagem; e um indicador de segurança (1162) para indicar se uma in-formação de segurança está incluída na mensagem; um campo de ID de mensagem (1134) configurado para identificar uma mensagem com um identificador que é único para um dispositivo (10) em uma rede em malha que codifica ou envia a men-sagem, em que o campo de ID de mensagem (1134) segue o campo de cabeçalho de mensagem (1132); e um campo de carga útil de aplicativo (1146) seguindo o campo de ID de mensagem (1134) e compreendendo dados transmitidos a partir do dispositivo (10) para dentro da rede em malha.

2. Meio legível em computador não transitório, de acordo com a reivindicação 1, caracterizado pelo fato de que o campo de cabeçalho de mensagem (1132) compreende dois bytes de dados.

3. Meio legível em computador não transitório, de acordo com a reivindicação 1, caracterizado pelo fato de que o campo de ID de mensagem (1134) compreende quatro bytes de dados.

4. Meio legível em computador não transitório, de acordo com a reivindicação 1, caracterizado pelo fato de que o campo de carga útil de aplicativo (1146) compreende dados formatados em um formato de etiqueta - comprimento - valor.

5. Meio legível em computador não transitório, de acordo com a reivindicação 1, caracterizado pelo fato de que a informação de endereçamento compreende uma referência de ID de fonte (1158) que indica se um endereço de fonte para o dispositivo (10) está incluído na mensagem, em que o endereço de fonte indica o dispositivo (10) formatado em um formato de endereço local único compreendendo: uma ID global (1100) tendo 40 bits de dados configurada para identificar a rede em malha na qual o dispositivo (10) de envio está conectado; uma ID de sub-rede (1102) tendo 16 bits de dados configu-rada para identificar uma rede lógica na rede em malha na qual o dis-positivo (10) de envio é conectado; e uma ID de interface (1104) tendo 64 bits de dados configu-rada para identificar o dispositivo (10) de envio.

6. Meio legível em computador não transitório, de acordo com a reivindicação 1, caracterizado pelo fato de que a informação de endereçamento compreende uma referência de ID de destino (1160) que indica se um endereço de destino está incluído na mensagem, em que o endereço de destino indica um dispositivo (10) de destino que é conectado à rede em malha, em que o endereço de destino é formatado em um formato de endereço local único compreendendo: uma ID global (1100) tendo 40 bits de dados configurada para identificar a rede em malha na qual o dispositivo (10) de destino está conectado; uma ID de sub-rede (1102) tendo 16 bits de dados configu-rada para identificar uma rede lógica na rede em malha na qual o dis-positivo (10) de destino é conectado; e uma ID de interface (1104) tendo 64 bits de dados configu-rada para identificar do dispositivo (10) de envio.

7. Meio legível em computador não transitório, de acordo com a reivindicação 1, caracterizado pelo fato de que o campo de carga útil de aplicativo compreender um comprimento variável de dados.

8. Método para enviar e receber mensagens entre dispositi-vos (1092, 1094) em uma rede em malha, caracterizado pelo fato de que o método compreende as etapas de: enviar ou receber uma mensagem usando um formato de mensagem geral, em que o formato de mensagem geral compreende: um campo de cabeçalho de mensagem (1132) que com-preende: um indicador de versão (1156) para indicar uma versão do formato de mensagem usado para formatar a mensagem; um indicador de endereçamento (1158, 1160) para indicar se uma informação de endereçamento está incluída na mensagem; e um indicador de segurança (1162) para indicar se uma ou mais informações de segurança estão incluídas na mensagem; um campo de ID de mensagem (1134) seguinte ao campo de cabeçalho de mensagem (1132), em que o campo de ID de mensagem (1134) é configurado para identificar uma mensagem com um identificador que é único para um dispositivo de envio dos um ou mais dispositivos eletrônicos (1092, 1094) que enviam a mensagem; e um campo de carga útil de aplicativo (1146) seguinte ao campo de cabeçalho de mensagem (1132), em que o campo de carga útil de aplicativo (1146) compreende dados transmitidos a partir do dispositivo de envio dentro da rede em malha.

9. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que um ou mais campos de informação de segurança compreendem: um campo de ID chave (1140) precedente ao campo de carga útil de aplicativo (1146), em que o campo de ID chave (1140) compreende dois bytes que indicam uma criptografia ou uma chave de integridade de mensagem usada para criptografar a mensagem indicada pelo campo de tipo de criptografia; um campo de vetor de inicialização (1144) imediatamente precedente ao campo de carga útil de aplicativo (1146), em que o campo de vetor de inicialização (1144) compreende um vetor de inicialização usado para criptografar a mensagem indicada pelo campo de tipo de criptografia; um campo de preenchimento (1150) seguinte ao campo de carga útil de aplicativo (1146), em que o campo de preenchimento (1150) compreende um comprimento de bytes representando um preenchimento criptográfico adicionado à mensagem para se tornar uma porção criptografada (1152) da mensagem uniformemente divisível por um tamanho de bloco de criptografia, em que a porção criptografada compreende o campo de carga útil de aplicativo (1146), um campo de integridade de mensagem (1148) que é seguinte ao campo de carga útil de aplicativo (1146), e o campo de preenchimento; ou um campo de assinatura de mensagem (1154) localizado em uma extremidade da mensagem, em que o campo de assinatura de mensagem (1154) inclui uma assinatura criptográfica para a mensagem.

10. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que o formato de mensagem geral compreende um campo de comprimento de pacote (1130) imediatamente precedendo o campo de cabeçalho de mensagem (1132), em que o campo de comprimento de pacote (1130) indica um comprimento de um pacote enviado usando um tipo de conexão usado para enviar a mensagem.

11. Método, de acordo com a reivindicação 10, caracterizado pelo fato de que o tipo de conexão compreende uma conexão de protocolo de controle de transmissão.

12. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que o formato de mensagem geral compreende um campo de comprimento de carga útil (1142) seguinte ao campo de ID de mensagem (1134) e precedendo ao campo de carga útil de aplicativo (1146), em que o campo de comprimento de carga útil compreende 2 bytes e é configurado para indicar um comprimento do campo de carga útil de aplicativo (1146).

13. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que o formato de mensagem geral compreende um campo de checagem de integridade de mensagem (1148) imediatamente seguinte ao campo de carga útil de aplicativo (1146).

14. Dispositivo eletrônico (10), configurado para enviar ou receber mensagens para outros dispositivos eletrônicos em uma rede em malha, caracterizado pelo fato de que as mensagens compreendem: um formato de mensagem geral compreendendo: um campo de cabeçalho de mensagem (1132) compreen-dendo: um indicador de versão (1156) para indicar uma versão do formato de mensagem usado para formatar a mensagem; um indicador de endereçamento (1158, 1160) para indicar se uma informação de endereçamento está incluída na mensagem; e um indicador de segurança (1162) para indicar se uma ou mais informações de segurança estão incluídas na mensagem; um campo de ID de mensagem (1134) seguinte ao campo de cabeçalho de mensagem (1132), em que o campo de ID de mensagem (1134) é configurado para identificar uma mensagem com um identificador que é único para um dispositivo de envio dos um ou mais dispositivos eletrônicos (1092, 1094) que enviam a mensagem; e um campo de carga útil de aplicativo (1146) seguinte ao campo de cabeçalho de mensagem (1132), em que o campo de carga útil de aplicativo (1146) compreende dados transmitidos a partir do dispositivo de envio dentro da rede em malha.

15. Dispositivo eletrônico, de acordo com a reivindicação 14, caracterizado pelo fato de que o formato de mensagem geral compreende um campo de comprimento de pacote (1130) imediatamente precedendo o campo de cabeçalho de mensagem (1132), em que o campo de comprimento de pacote (1130) indica um comprimento de um pacote enviado usando um tipo de conexão usado para enviar a mensagem.

16. Dispositivo eletrônico, de acordo com a reivindicação 15, caracterizado pelo fato de que o tipo de conexão compreende uma conexão de protocolo de controle de transmissão.

17. Dispositivo eletrônico, de acordo com a reivindicação 14, caracterizado pelo fato de que o formato de mensagem geral compreende um campo de comprimento de carga útil (1142) seguinte ao campo de ID de mensagem (1134) e precedendo ao campo de carga útil de aplicativo (1146), em que o campo de comprimento de carga útil compreende 2 bytes e é configurado para indicar um comprimento do campo de carga útil de aplicativo (1146).

18. Dispositivo eletrônico, de acordo com a reivindicação 14, caracterizado pelo fato de que o formato de mensagem geral compreende um campo de checagem de integridade de mensagem (1148) imediatamente seguinte ao campo de carga útil de aplicativo (1146).

19. Dispositivo eletrônico, de acordo com a reivindicação 14, caracterizado pelo fato de que o campo de carga útil de aplicativo compreender um comprimento variável de dados.

20. Dispositivo eletrônico, de acordo com a reivindicação 14, caracterizado pelo fato de que o campo de carga útil de aplicativo (1146) compreende dados formatados em um formato de etiqueta – comprimento – valor.