URL de Eddystone, Suporte para SSDP e mDNS da Web física

Índice
URL de Eddystone, Suporte para SSDP e mDNS da Web física

Introdução à Web Física

Beacons são adequados para todos os tipos de cenários de aplicativos que exigem comunicação entre objetos do cotidiano e seu ambiente. A web física ajuda os usuários a aproveitar ao máximo as oportunidades resultantes. Neste artigo, vamos apresentar como funciona a web física, e não há dúvida de que o URL Eddystone desempenha um papel importante durante o funcionamento do Eddystone.

No 2014, O Google apresentou seu projeto de código aberto Physical Web com o objetivo de vincular ainda mais o mundo virtual ao real. Ponto de ônibus, atrações turísticas, objetos do dia a dia ou itens de supermercado – em princípio, todos eles agora podem enviar mensagens independentemente para smartphones por meio de beacons. A base para tal comunicação é o Bluetooth Low Energy (PASSOU A SER) tecnologia de rádio. Se um item foi equipado com um farol, ele pode enviar mensagens para smartphones que suportam BLE, por exemplo, informar sobre atrasos, ofertas especiais ou dias de campanha.

Neste contexto, a web física garante, entre outras coisas, que os usuários não precisem instalar novos aplicativos em todos os lugares, mas pode ver as notícias em uma interface uniforme. Pode ser usado em quase todos os casos em que os usuários estão interessados ​​em informações sobre seu ambiente ou em que é necessária uma interação entre eles e objetos inteligentes. Para ter uma ideia melhor de tais cenários, seguem três breves exemplos de aplicação.

O ponto de ônibus inteligente: Um ponto de ônibus nas proximidades pode informar a espera de pessoas por meio de seu smartphone quando o próximo ônibus chegará. Nesse caso, o sensor BLE físico da web envia uma URL que leva ao site do ponto de ônibus. Para distingui-los dos demais, a URL conteria um código de identificação da parada.

Interação com máquinas de venda automática: Uma máquina de venda automática com conexão à Internet envia um URL que os clientes podem usar para acessar um site usando a função de pagamento da máquina de venda automática se não tiverem dinheiro com eles. A URL inclui um token que muda dinamicamente após cada compra. A máquina e o site abertos no smartphone se conectam ao servidor back-end do provedor usando o mesmo token. Após a compra ser processada, o servidor envia uma solicitação à máquina de venda automática para emitir os produtos adquiridos. A web física é usada para transferir a URL para o smartphone. Todas as outras etapas ocorrem na Internet como de costume. Por exemplo, os chamados web sockets podem ser usados ​​para comunicação bidirecional entre a máquina ou site e o servidor.

Eletrodomésticos monitorados: A web física também pode ser usada para controlar e monitorar eletrodomésticos, como a máquina de lavar. Cada dispositivo envia uma URL que se refere a um endereço IP e só pode ser acessada quando conectado à rede local. A visibilidade da URL pode ser limitada a dispositivos na rede se técnicas de descoberta de rede, como mDNS e SSDP, forem usadas em vez de BLE.

Web física ou aplicativos únicos

Ao contrário de outras ofertas de informação (por exemplo. informações de horários ou associação de turismo), onde os usuários precisam instalar seu próprio aplicativo para cada provedor, a web física integra a URL Eddystone transmitida pelos beacons como se fossem uma consulta de pesquisa em uma página. Assim, os usuários podem encontrar objetos inteligentes em seu ambiente com apenas um aplicativo e interagir diretamente com eles. Outra vantagem: nenhuma notificação proativa é enviada. O usuário só vê uma lista de objetos em sua área se quiser.

Além do BLE, MOKOSmart, em que o autor trabalha, propõe um método para enviar e receber URLs em redes locais que são baseados no Simple Service Discovery Protocol (SSDP). Com a ajuda do SSDP, é possível limitar a visibilidade do URL Eddystone enviado em redes locais e assim aumentar a segurança da conexão.

A Web Física está disponível como um projeto sob a licença Apache no MOKOSmart e inclui implementações para plataformas como Android, iOS, e Node.js. Os aplicativos web físicos para Android e iOS estão disponíveis na Apple App Store e na Google Play Store. Todas as aplicações devem ser entendidas como protótipos, que permitem que os desenvolvedores experimentem a web física em um estágio inicial. No futuro, deve estar disponível em outros dispositivos móveis além de smartphones.

url eddystone

Como funciona a web física?

A web física é considerada uma extensão da internet. Como todas as tecnologias da web, está aberto a todos e todos podem desenvolvê-lo ainda mais. Como o sistema é baseado na exibição de URLs, é descentralizado e não controlado por ninguém. A URL Eddystone pode levar a páginas de informações simples, para mais complexo, aplicativos da web interativos ou até mesmo para aplicativos nativos. A web física é comparável à pesquisa na web:

O usuário chama uma lista de objetos de sua vizinhança.
Uma lista de URLs é exibida.
O usuário seleciona um.
A URL sai na janela do navegador.
Os seguintes aspectos devem ser levados em consideração de uma perspectiva técnica:
1. Enviar comentários
2. História
3. Salvou
4. Comunidade

• Envio e recebimento de URLs: Há muitas maneiras de enviar URLs. A web física atualmente suporta transmissão via BLE, mDNS, e SSDP (mais sobre isso na próxima seção).
Recuperar informações básicas de sites: O cliente web físico coleta os URLs encontrados e os envia junto com todas as informações relevantes (por exemplo. sinal de força) para um serviço da web. este, por sua vez, chama as informações básicas, como o título, Descrição, e ícone do site e retorna os resultados da pesquisa para o cliente. A implementação do protótipo do serviço web está disponível no repositório GitHub do projeto.

• Exibindo os resultados: Uma classificação é importante quando se trata de exibir os muitos dispositivos de envio de URL da área. O cliente web físico pode classificar de acordo com a intensidade do sinal, preferência pessoal e outros critérios. O sistema deve separar o spam com antecedência. Como os motores de busca têm o mesmo problema, sua abordagem pode ser usada para a web física. Na exibição de resultados, o usuário clica em um objeto de lista e o navegador abre o site associado.

• Como mencionado, a web física atualmente conhece três maneiras de enviar e receber URLs. Eles são baseados em dois processos diferentes: Bluetooth Low Energy e descoberta de serviços de rede. Teoricamente, outros métodos podem ser adicionados no futuro. Por exemplo, os desenvolvedores podem usar a tecnologia de marca d'água de áudio para incorporar um URL em um sinal de áudio. Nesse caso, o cliente web físico teria que ser expandido para poder receber sinais de áudio e decodificar os URLs contidos nele.

Ble Bluetooth e Eddystone

O primeiro rascunho da Web física USA BLE para enviar a URL para o pacote apropriado. A tecnologia é muito eficiente em termos energéticos, especialmente se o produto que o utiliza for operado no modo de transmissão (modo BLE não conectável), como no caso da web física. Pequenos dispositivos BLE podem enviar URL Eddystone com uma única célula de botão por quase dois anos.

Um dos blocos de construção básicos da Web Física é o URL Eddystone. Como uma especificação de protocolo, Eddystone define um formato de mensagem Bluetooth de baixa potência para beacons de proximidade com base na especificação principal do Bluetooth. Descreve diferentes tipos de quadros que os beacons podem usar individualmente ou em combinação: Eddystone-UID, Eddystone-TLM, e o URL Eddystone mencionado acima, que é o único relevante para a web física.

Uma mensagem Eddystone consiste em dois tipos básicos de dados em um bloco de dados de publicidade (DE ANÚNCIOS): UUID e serviço de dados. Ambos os tipos usam um identificador universalmente exclusivo de 16 bits (UUID) que está em conformidade com os padrões Bluetooth. O serviço UUID reservado para Eddystone é 0xFEAA. Ele fornece um mecanismo de eficiência, varredura em segundo plano multiplataforma que o Android e o iOS permitem. Os bytes subsequentes do bloco AD contêm os dados específicos do quadro. O primeiro byte define o tipo de quadro. Apenas os quatro bits mais significativos são usados ​​atualmente. Os quatro inferiores são reservados para uso posterior e devem ter o valor 0000.

O quadro Eddystone UID envia um ID de beacon exclusivo de 16 bytes que consiste em um ID de namespace de 10 bytes e um ID de instância de 6 bytes. Embora o ID do namespace possa ser usado para agrupar um conjunto específico de beacons, o ID da instância é útil para identificar os dispositivos no grupo.

Se você olhar para o conceito do Eddystone UID, funciona de forma semelhante aos iBeacons introduzidos pela Apple em 2013. O pacote iBeacon contém 16 bytes perto do UUID, um domínio primário de 2 bytes, e um domínio secundário de 2 bytes. Os pacotes iBeacon contêm um UUID de proximidade de 16 bytes, 2-campos de byte major e 2 byte minor. O UUID de proximidade pode ser usado para identificar uma organização ou aplicativo como um negócio. Os campos principais e secundários permitem uma atribuição mais detalhada da identidade determinada pelo UUID, como no caso de uma filial. Eddystone-TLM agora está enviando informações telemétricas, como status da bateria, temperatura do dispositivo e o número de pacotes enviados pelo beacon.

O quadro de URL Eddystone envia uma versão reduzida do URL gerado pela codificação. A compressão permite transportar mais dados com o pacote de publicidade limitado. O formato do primeiro 11 bytes (bytes 0 Através dos 10) da mensagem Eddystone é a mesma para todos os tipos de moldura. Como os seguintes bytes são definidos (começando no byte 11), Contudo, depende do tipo de quadro:

• Byte 11 define o tipo de quadro. Seu valor para frames de URL Eddystone é 0x10.
• Byte 12 define a potência de TX. É um valor inteiro de 8 bits com sinal, conforme descrito no TX Power Level Bluetooth Characteristic

Descoberta de serviço de rede

Além de beacons BLE e URL Eddystone, métodos de descoberta de rede, como SSDP e mDNS, oferecem a opção de transmitir URLs. Você também pode enviar URLs para dispositivos em redes locais. O método tem duas vantagens sobre o BLE: Primeiro, somente usuários que estão logados em redes locais podem ver os URLs, e em segundo lugar, não há restrição de comprimento de URL como com BLE.

O uso do Network Discovery para a web física faz sentido em situações em que a segurança e a privacidade desempenham um papel fundamental. Um exemplo seria a área de casa inteligente se o acesso aos dispositivos devesse ser limitado apenas a pessoas da mesma casa.

O protocolo de descoberta de serviço simples (SSDP) é um protocolo de rede para publicidade e descoberta de serviços e dispositivos em redes locais. Ele forma a camada de descoberta do protocolo plug-and-play universal (UPnP) e ajuda a divulgar dispositivos recém-adicionados que são definidos como pontos de controle. Também permite pesquisar dispositivos e serviços específicos.

Tais funções são baseadas nos dois tipos de mensagens SSDP. Primeiro, há a mensagem de anúncio que um dispositivo envia assim que é adicionado à rede. A mensagem para o endereço e porta multicast padrão 239.255.255.250:1900 é ssdp: vivo. Pontos de controle escutam a porta para receber mensagens SSDP e assim poder detectar novos dispositivos e serviços. Antes que os dispositivos UPnP desapareçam da rede ou não estejam mais disponíveis, eles devem enviar a mensagem ssdp: bye-bye para o mesmo endereço multicast e a porta correspondente.

Por outro lado, existe uma função de descoberta na qual o SSDP permite que os pontos de controle encontrem dispositivos e serviços de interesse mesmo na rede. Nesse caso, um ponto de controle envia uma solicitação de pesquisa para o endereço e porta multicast 239.255.255.250:1900. Os dispositivos UPnP que suportam os serviços solicitados enviam uma resposta unicast para o endereço do ponto de verificação que enviou a solicitação. O formato da resposta é semelhante à mensagem SSDP do tipo ssdp: vivo.

Web física suporta SSDP para enviar e receber URLs em redes locais. Fraunhofer FOKUS desenvolveu o conceito e implementação do mecanismo correspondente. A implementação inclui a integração do SSDP no aplicativo web físico para Android e iOS para recebimento de URLs via protocolo. além do que, além do mais, uma ferramenta multiplataforma baseada em Node.js está disponível para enviar URLs da mesma forma.

Ao usar SSDP, um dispositivo web físico conectado à rede local envia o seguinte ssdp: mensagem viva assim que estiver disponível na rede:

NOTIFICAR * HTTP / 1.1 HOSPEDEIRO: 239.255.255.250:1900
CACHE-CONTROL: max-age = segundos até o anúncio expirar
LOCALIZAÇÃO: URL da página da web para anunciar
NT: urna: físico-web-org: dispositivo: Básico: 1
NTS: ssdp: vivo
SERVIDOR: SO / versão UPnP / 1.0 produtos / versão
USN: anúncio UUID
O método NOTIFY na primeira linha indica que é uma mensagem publicitária. Enquanto o cabeçalho LOCATION define o URL físico da web que é enviado, o cabeçalho NT define o tipo de dispositivo, que no caso da web física é urna: físico-web-org: dispositivo: Básico: 1. O ssdp: o valor vivo do cabeçalho NTS indica que o dispositivo web físico está disponível. Finalmente, o cabeçalho USN fornece um nome exclusivo que pode ser usado para identificar o dispositivo. Os clientes físicos da Web executados em smartphones ou tablets ouvem o endereço e a porta multicast 239.255.255.250:1900 e filtre as mensagens físicas do SSDP da web verificando o valor do cabeçalho NT. Você pode então analisar a mensagem SSDP e ler o valor do cabeçalho LOCATION que carrega o URL enviado.

Dispositivos web físicos devem enviar o seguinte ssdp: mensagem de adeus antes de desaparecer da rede:

NOTIFICAR * HTTP / 1.1 HOSPEDEIRO: 239.255.255.250: 1900
NT: urna: físico-web-org: dispositivo: Básico: 1
NTS: ssdp: tchau tchau
USN: anúncio UUID
ssdp: bye-bye deixa claro que o dispositivo web físico não está mais disponível a partir de agora. O valor do cabeçalho USN permanece o mesmo que no ssdp: mensagem viva. Os clientes da Web físicos que recebem essa mensagem procuram o URL associado ao USN e o removem da lista.

 

Escrito por --
Nick Ele
Nick Ele
usuario, um gerente de projeto experiente em nosso R&Departamento D, traz uma riqueza de experiência para MOKOSMART, tendo atuado anteriormente como engenheiro de projeto na BYD. Sua experiência em R&D traz uma habilidade completa para seu gerenciamento de projetos de IoT. Com um fundo sólido abrangendo 6 anos em gerenciamento de projetos e obtenha certificações como PMP e CSPM-2, Nick se destaca na coordenação de esforços em vendas, Engenharia, testando, e equipes de marketing. Os projetos de dispositivos IoT dos quais ele participou incluem Beacons, Dispositivos LoRa, entradas, e plugues inteligentes.
Nick Ele
Nick Ele
usuario, um gerente de projeto experiente em nosso R&Departamento D, traz uma riqueza de experiência para MOKOSMART, tendo atuado anteriormente como engenheiro de projeto na BYD. Sua experiência em R&D traz uma habilidade completa para seu gerenciamento de projetos de IoT. Com um fundo sólido abrangendo 6 anos em gerenciamento de projetos e obtenha certificações como PMP e CSPM-2, Nick se destaca na coordenação de esforços em vendas, Engenharia, testando, e equipes de marketing. Os projetos de dispositivos IoT dos quais ele participou incluem Beacons, Dispositivos LoRa, entradas, e plugues inteligentes.
Compartilhar esta postagem
Capacite seu conectado Necessidade com MOKOSmart Soluções para dispositivos loT!