URL di Eddystone, SSDP e mDNS supportano Web fisico

URL di Eddystone, SSDP e mDNS supportano Web fisico
URL di Eddystone, SSDP e mDNS supportano Web fisico

Introduzione al Web fisico

Beacons sono adatti a tutti i tipi di scenari applicativi che richiedono la comunicazione tra gli oggetti quotidiani e il loro ambiente. Il Web fisico aiuta gli utenti a sfruttare in modo ottimale le opportunità risultanti. In questo articolo, presenteremo come funziona il web fisico, e non c'è dubbio che l'URL di Eddystone svolga un ruolo importante durante il funzionamento di Eddystone.

Nel 2014, Google ha presentato il suo progetto open source Physical Web con l'obiettivo di collegare ancora più strettamente il mondo virtuale con quello reale. Fermata dell'autobus, attrazioni turistiche, oggetti di uso quotidiano o articoli da supermercato – in linea di principio, tutti ora possono inviare messaggi in modo indipendente agli smartphone tramite beacon. La base di tale comunicazione è il Bluetooth Low Energy (DIVENNE) tecnologia radiofonica. Se un oggetto è stato dotato di un faro, può inviare messaggi a smartphone che supportano BLE, ad esempio informare sui ritardi, offerte speciali o giorni di campagna.

In questo contesto, assicura il web fisico, tra l'altro, che gli utenti non devono installare nuove app ovunque, ma può visualizzare le notizie su un'interfaccia uniforme. Può essere utilizzato in quasi tutti i casi in cui gli utenti sono interessati a informazioni sul loro ambiente o in cui è necessaria un'interazione tra loro e oggetti intelligenti. Per avere un'idea migliore di tali scenari, seguono tre brevi esempi di applicazione.

La fermata dell'autobus intelligente: Una fermata dell'autobus nelle vicinanze potrebbe dire alle persone in attesa tramite il loro smartphone quando arriverà il prossimo autobus. In questo caso, il sensore Web BLE fisico invia un URL che porta al sito Web della fermata dell'autobus. Per distinguerli dagli altri, l'URL conterrebbe un codice identificativo della fermata.

Interazione con distributori automatici: Un distributore automatico con connessione Internet invia un URL che i clienti possono utilizzare per accedere a un sito Web utilizzando la funzione di pagamento del distributore se non hanno contanti con loro. L'URL include un token che cambia dinamicamente dopo ogni acquisto. La macchina e il sito web aperti sullo smartphone si connettono al server back-end del provider utilizzando lo stesso token. Dopo che l'acquisto è stato elaborato, il server invia una richiesta al distributore automatico di emettere i prodotti acquistati. Il Web fisico viene utilizzato per trasferire l'URL allo smartphone. Tutti gli altri passaggi si svolgono su Internet come di consueto. Per esempio, le cosiddette web socket possono essere utilizzate per la comunicazione bidirezionale tra la macchina o il sito web e il server.

Elettrodomestici monitorati: Il web fisico può essere utilizzato anche per controllare e monitorare elettrodomestici come la lavatrice. Ogni dispositivo invia un URL che fa riferimento a un indirizzo IP e può essere raggiunto solo quando connesso alla rete locale. La visibilità dell'URL può essere limitata ai dispositivi nella rete se vengono utilizzate tecniche di rilevamento della rete come mDNS e SSDP anziché BLE.

Web fisico o singole app

A differenza di altre offerte di informazioni (per esempio. informazioni orari o associazione turistica), dove gli utenti devono installare la propria app per ciascun provider, il web fisico integra l'URL Eddystone trasmesso dai beacon come se fosse una query di ricerca su una pagina. In questo modo gli utenti possono trovare oggetti intelligenti nel loro ambiente con una sola app e interagire direttamente con essi. Un altro vantaggio: non vengono inviate notifiche proattive. L'utente vede un elenco di oggetti nella sua area solo se lo desidera.

Oltre al BLE, MOKOSmart, in cui l'autore lavora, propone un metodo per l'invio e la ricezione di URL in reti locali basato sul Simple Service Discovery Protocol (SSDP). Con l'aiuto di SSDP, è possibile limitare la visibilità dell'URL Eddystone inviato nelle reti locali e aumentare così la sicurezza della connessione.

Il Physical Web è disponibile come progetto sotto la licenza Apache su MOKOSmart e include implementazioni per piattaforme come Android, iOS, e Node.js. Le applicazioni web fisiche per Android e iOS sono disponibili nell'Apple App Store e nel Google Play Store. Tutte le applicazioni sono da intendersi come prototipi, che consentono agli sviluppatori di sperimentare il Web fisico in una fase iniziale. Nel futuro, dovrebbe essere disponibile su altri dispositivi mobili oltre agli smartphone.

url eddystone

Come funziona il Web fisico?

Si dice che il Web fisico sia un'estensione di Internet. Come tutte le tecnologie web, è aperto a tutti e tutti possono svilupparlo ulteriormente. Poiché il sistema si basa sulla visualizzazione di URL, è decentralizzato e non controllato da nessuno. L'URL di Eddystone può portare a semplici pagine di informazioni, a più complesso, app web interattive o anche ad applicazioni native. Il web fisico è paragonabile alla ricerca sul web:

L'utente richiama un elenco di oggetti nelle sue vicinanze.
Viene visualizzato un elenco di URL.
L'utente ne seleziona uno.
L'URL viene visualizzato nella finestra del browser.
Da un punto di vista tecnico devono essere presi in considerazione i seguenti aspetti:
1. Invia feedback
2. Storia
3. Salvato
4. Comunità

• Invio e ricezione di URL: Esistono molti modi per inviare URL. Il Web fisico attualmente supporta la trasmissione tramite BLE, mDNS, e SSDP (più su questo nella prossima sezione).
Recupera le informazioni di base dai siti Web: Il client Web fisico raccoglie gli URL trovati e li invia insieme a tutte le informazioni rilevanti (per esempio. la potenza del segnale) a un servizio web. Questo, a sua volta, richiama le informazioni di base come il titolo, descrizione, e l'icona del sito Web e restituisce i risultati della ricerca al cliente. L'implementazione prototipo del servizio web è disponibile nel repository GitHub del progetto.

• Visualizzazione dei risultati: Una classifica è importante quando si tratta di visualizzare i numerosi dispositivi di invio di URL dell'area. Il client Web fisico può ordinare in base alla potenza del segnale, preferenze personali e altri criteri. Il sistema dovrebbe eliminare lo spam in anticipo. Dal momento che i motori di ricerca hanno lo stesso problema, il loro approccio può essere utilizzato per il web fisico. Nella visualizzazione dei risultati, l'utente fa clic su un oggetto elenco e il browser apre il sito Web associato.

• Come menzionato, il Web fisico attualmente conosce tre modi per inviare e ricevere URL. Si basano su due diversi processi: Bluetooth a basso consumo energetico e rilevamento dei servizi di rete. Teoricamente, ulteriori metodi potrebbero essere aggiunti in futuro. Per esempio, gli sviluppatori potrebbero utilizzare la tecnologia di filigrana audio per incorporare un URL in un segnale audio. In questo caso, il client web fisico dovrebbe essere espanso per poter ricevere segnali audio e decodificare gli URL in esso contenuti.

Ble Bluetooth e Eddystone

La prima bozza del Web fisico USA BLE per inviare l'URL al pacchetto appropriato. La tecnologia è molto efficiente dal punto di vista energetico, soprattutto se il prodotto che lo utilizza funziona in modalità di trasmissione (modalità BLE non collegabile), come nel caso del web fisico. I piccoli dispositivi BLE possono inviare URL Eddystone con una singola cella a bottone per quasi due anni.

Uno degli elementi costitutivi di base del Physical Web è l'URL di Eddystone. Come specifica di protocollo, Eddystone definisce un formato di messaggio Bluetooth a bassa potenza per i radiofari di prossimità basato sulla specifica principale Bluetooth. Descrive diversi tipi di frame che i beacon possono utilizzare singolarmente o in combinazione: Eddystone-UID, Eddystone-TLM, e il summenzionato URL di Eddystone, che è l'unico rilevante per il web fisico.

Un messaggio Eddystone è costituito da due tipi di dati di base in un blocco di dati pubblicitari (ANNO DOMINI): UUID e servizio dati. Entrambi i tipi utilizzano un identificatore univoco universale a 16 bit (UUID) conforme agli standard Bluetooth. Il servizio UUID riservato a Eddystone è 0xFEAA. Fornisce un meccanismo efficiente, scansione in background multipiattaforma consentita sia da Android che da iOS. I byte successivi del blocco AD contengono i dati specifici del frame. Il primo byte definisce il tipo di frame. Attualmente vengono utilizzati solo i quattro bit più significativi. I quattro inferiori sono riservati per un uso successivo e devono avere il valore 0000.

Il frame Eddystone UID invia un ID beacon univoco a 16 byte che consiste in un ID spazio dei nomi a 10 byte e un ID istanza a 6 byte. Sebbene l'ID dello spazio dei nomi possa essere utilizzato per raggruppare un insieme specifico di beacon, l'ID istanza è utile per identificare i dispositivi nel gruppo.

Se guardi al concetto di Eddystone UID, funziona in modo simile agli iBeacon introdotti da Apple in 2013. Il pacchetto iBeacon contiene 16 byte vicini all'UUID, un dominio primario a 2 byte, e un dominio secondario a 2 byte. I pacchetti iBeacon contengono un UUID di prossimità a 16 byte, 2-campi byte major e 2 byte minor. L'UUID di prossimità può essere utilizzato per identificare un'organizzazione o un'applicazione come un'azienda. I campi maggiori e minori consentono un'assegnazione più dettagliata dell'identità determinata dall'UUID, come nel caso di una succursale. Eddystone-TLM sta ora inviando informazioni telemetriche come lo stato della batteria, la temperatura del dispositivo e il numero di pacchetti inviati dal beacon.

Il frame URL Eddystone invia una versione ridotta dell'URL generato dalla codifica. La compressione consente di trasportare più dati con il pacchetto pubblicitario limitato. Il formato del primo 11 byte (byte 0 attraverso 10) del messaggio Eddystone è lo stesso per tutti i tipi di frame. Come vengono impostati i seguenti byte (a partire da byte 11), però, dipende dal tipo di telaio:

• Byte 11 definisce il tipo di cornice. Il suo valore per i frame URL di Eddystone è 0x10.
• Byte 12 definisce la potenza di TX. È un valore intero a 8 bit con segno come descritto nella caratteristica Bluetooth del livello di potenza TX

Scoperta del servizio di rete

Oltre ai beacon BLE e all'URL Eddystone, metodi di rilevamento della rete come SSDP e mDNS offrono la possibilità di trasmettere URL. Puoi anche inviare URL a dispositivi su reti locali. Il metodo ha due vantaggi rispetto a BLE: Primo, solo gli utenti che hanno effettuato l'accesso alle reti locali possono vedere gli URL, e secondo, non ci sono restrizioni sulla lunghezza dell'URL come con BLE.

L'utilizzo di Network Discovery per il Web fisico ha senso in situazioni in cui la sicurezza e la privacy giocano un ruolo fondamentale. Un esempio potrebbe essere l'area della casa intelligente se l'accesso ai dispositivi dovesse essere limitato solo alle persone della stessa famiglia.

Il protocollo di rilevamento del servizio semplice (SSDP) è un protocollo di rete per la pubblicità e la scoperta di servizi e dispositivi nelle reti locali. Costituisce il livello di rilevamento del protocollo plug-and-play universale (UPnP) e aiuta a pubblicizzare i dispositivi appena aggiunti definiti come punti di controllo. Consente inoltre di cercare dispositivi e servizi specifici.

Tali funzioni si basano sui due tipi di messaggi SSDP. Primo, c'è il messaggio pubblicitario che un dispositivo invia non appena viene aggiunto alla rete. Il messaggio all'indirizzo e alla porta multicast standard 239.255.255.250:1900 è ssdp: vivo. I punti di controllo ascoltano la porta per ricevere messaggi SSDP e quindi essere in grado di rilevare nuovi dispositivi e servizi. Prima che i dispositivi UPnP scompaiano dalla rete o non siano più disponibili, devono inviare il messaggio ssdp: ciao allo stesso indirizzo multicast e alla porta corrispondente.

D'altro canto, esiste una funzione di discovery in cui SSDP permette ai punti di controllo di trovare dispositivi e servizi di interesse anche nella rete. In questo caso, un punto di controllo invia una richiesta di ricerca all'indirizzo e alla porta multicast 239.255.255.250:1900. I dispositivi UPnP che supportano i servizi richiesti inviano una risposta unicast all'indirizzo del checkpoint che ha inviato la richiesta. Il formato della risposta è simile al messaggio SSDP del tipo ssdp: vivo.

Physical Web supporta SSDP per inviare e ricevere URL nelle reti locali. Fraunhofer FOKUS ha sviluppato il concetto e l'attuazione del meccanismo corrispondente. L'implementazione prevede l'integrazione di SSDP nella web app fisica per Android e iOS per la ricezione di URL tramite protocollo. Inoltre, uno strumento multipiattaforma basato su Node.js è disponibile per inviare URL allo stesso modo.

Quando si utilizza SSDP, un dispositivo web fisico connesso alla rete locale invia il seguente ssdp: messaggio vivo non appena è disponibile nella rete:

NOTIFICARE * HTTP / 1.1 OSPITE: 239.255.255.250:1900
CONTROLLO DELLA CACHE: max-age = secondi fino alla scadenza dell'annuncio
POSIZIONE: URL della pagina web da pubblicizzare
NT: urna: fisico-web-org: dispositivo: Di base: 1
NTS: ssdp: vivo
SERVER: TU / versione UPnP / 1.0 Prodotto / versione
USN: annuncio UUID
Il metodo NOTIFY nella prima riga indica che si tratta di un messaggio pubblicitario. Mentre l'intestazione LOCATION definisce l'URL Web fisico che viene inviato, l'intestazione NT definisce il tipo di dispositivo, che nel caso del web fisico è urna: fisico-web-org: dispositivo: Di base: 1. Il ssdp: il valore attivo dell'intestazione NTS indica che il dispositivo Web fisico è disponibile. Finalmente, l'intestazione USN fornisce un nome univoco che può essere utilizzato per identificare il dispositivo. I client Web fisici in esecuzione su smartphone o tablet ascoltano l'indirizzo e la porta multicast 239.255.255.250:1900 e filtrare i messaggi SSDP web fisici controllando il valore dell'intestazione NT. È quindi possibile analizzare il messaggio SSDP e leggere il valore dell'intestazione LOCATION che contiene l'URL inviato.

I dispositivi Web fisici devono inviare il seguente ssdp: messaggio di arrivederci prima di scomparire dalla rete:

NOTIFICARE * HTTP / 1.1 OSPITE: 239.255.255.250: 1900
NT: urna: fisico-web-org: dispositivo: Di base: 1
NTS: ssdp: Ciao ciao
USN: annuncio UUID
ssdp: bye-bye chiarisce che il dispositivo web fisico non è più disponibile da ora in poi. Il valore dell'intestazione USN rimane lo stesso di ssdp: messaggio vivo. I client Web fisici che ricevono tale messaggio cercano l'URL associato all'USN e quindi lo rimuovono dall'elenco.

 

Scritto da --
Nick Lui
Nick Lui
Nick, un project manager esperto nel nostro R&Dipartimento D., porta una ricchezza di esperienza a MOKOSMART, avendo precedentemente lavorato come ingegnere di progetto presso BYD. La sua competenza in R&D apporta competenze a tutto tondo alla gestione dei suoi progetti IoT. Con uno sfondo solido che si estende 6 anni nella gestione di progetti e ottenere certificazioni come PMP e CSPM-2, Nick eccelle nel coordinare gli sforzi tra le vendite, ingegneria, test, e team di marketing. I progetti di dispositivi IoT a cui ha partecipato includono Beacons, Dispositivi LoRa, gateway, e prese intelligenti.
Nick Lui
Nick Lui
Nick, un project manager esperto nel nostro R&Dipartimento D., porta una ricchezza di esperienza a MOKOSMART, avendo precedentemente lavorato come ingegnere di progetto presso BYD. La sua competenza in R&D apporta competenze a tutto tondo alla gestione dei suoi progetti IoT. Con uno sfondo solido che si estende 6 anni nella gestione di progetti e ottenere certificazioni come PMP e CSPM-2, Nick eccelle nel coordinare gli sforzi tra le vendite, ingegneria, test, e team di marketing. I progetti di dispositivi IoT a cui ha partecipato includono Beacons, Dispositivi LoRa, gateway, e prese intelligenti.
Condividi questo post