Eddystone-URL, SSDP en mDNS ondersteunen fysiek web

Eddystone-URL, SSDP en mDNS ondersteunen fysiek web

Inleiding tot het fysieke web

Bakens zijn geschikt voor allerlei toepassingsscenario's die communicatie tussen alledaagse voorwerpen en hun omgeving vereisen. Het fysieke web helpt gebruikers optimaal gebruik te maken van de kansen die hieruit voortvloeien. In dit artikel, we zullen introduceren hoe fysiek internet werkt, en het lijdt geen twijfel dat de Eddystone-URL een belangrijke rol speelt tijdens de werking van de Eddystone.

In 2014, Google presenteerde zijn open-sourceproject Physical Web met als doel de virtuele wereld nog nauwer te verbinden met de echte. Bus stopt, Toeristische attracties, alledaagse voorwerpen of supermarktartikelen – in principe, ze kunnen nu allemaal onafhankelijk berichten via bakens naar smartphones sturen. De basis voor dergelijke communicatie is de Bluetooth Low Energy (WERD) radiotechnologie. Als een item is uitgerust met een baken, het kan berichten sturen naar smartphones die BLE ondersteunen, bijvoorbeeld informeren over vertragingen, speciale aanbiedingen of actiedagen.

In deze context, het fysieke web zorgt, onder andere, dat gebruikers niet overal nieuwe apps hoeven te installeren, maar kan het nieuws op een uniforme interface bekijken. Het kan worden gebruikt in bijna alle gevallen waarin gebruikers geïnteresseerd zijn in informatie over hun omgeving of waarin een interactie tussen hen en slimme objecten noodzakelijk is. Om een ​​beter beeld te krijgen van dergelijke scenario's, drie korte toepassingsvoorbeelden volgen.

De intelligente bushalte: Een bushalte in de buurt kan mensen via hun smartphone laten wachten wanneer de volgende bus komt. In dit geval, de fysieke web-BLE-sensor zendt een URL uit die naar de website van de bushalte leidt. Om ze van anderen te onderscheiden, de URL zou een identificatiecode van de halte bevatten.

Interactie met automaten: Een automaat met een internetverbinding verstuurt een URL die klanten kunnen gebruiken om toegang te krijgen tot een website met de betaalfunctie van de automaat als ze geen contant geld bij zich hebben. De URL bevat een token dat na elke aankoop dynamisch verandert. De machine en de website die op de smartphone zijn geopend, maken met hetzelfde token verbinding met de back-end-server van de provider. Nadat de aankoop is verwerkt, de server stuurt een verzoek naar de automaat om de gekochte producten uit te geven. Het fysieke web wordt gebruikt om de URL naar de smartphone over te dragen. Alle andere stappen vinden zoals gewoonlijk plaats op internet. Bijvoorbeeld, de zogenaamde websockets kunnen worden gebruikt voor bidirectionele communicatie tussen de machine of website en de server.

Bewaakte huishoudelijke apparaten: Het fysieke web kan ook worden gebruikt om huishoudelijke apparaten zoals de wasmachine aan te sturen en te monitoren. Elk apparaat zendt een URL uit die verwijst naar een IP-adres en is alleen bereikbaar wanneer het is verbonden met het lokale netwerk. De zichtbaarheid van de URL kan worden beperkt tot apparaten in het netwerk als netwerkdetectietechnieken zoals mDNS en SSDP worden gebruikt in plaats van BLE.

Fysiek web of afzonderlijke apps

In tegenstelling tot andere informatieaanbiedingen (bijv. informatie over dienstregeling of toerismevereniging), waarbij gebruikers voor elke provider hun eigen app moeten installeren, het fysieke web integreert de Eddystone-URL die door de bakens wordt verzonden alsof het een zoekopdracht op een pagina is. Zodat gebruikers slimme objecten in hun omgeving kunnen vinden met slechts één app en er rechtstreeks mee kunnen communiceren. Een ander voordeel: er worden geen proactieve notificaties verstuurd. De gebruiker ziet alleen een lijst met objecten in zijn omgeving als hij dat wil.

Naast de BLE, MOKOSmart, waarin de auteur werkt, stelt een methode voor voor het verzenden en ontvangen van URL's in lokale netwerken die zijn gebaseerd op het Simple Service Discovery Protocol (SSDP). Met behulp van SSDP, het is mogelijk om de zichtbaarheid van verzonden Eddystone URL in lokale netwerken te beperken en zo de verbindingsbeveiliging te verhogen.

Het fysieke web is beschikbaar als een project onder de Apache-licentie op MOKOSmart en omvat implementaties voor platforms zoals Android, iOS, en Node.js. De fysieke webapplicaties voor Android en iOS zijn beschikbaar in de Apple App Store en de Google Play Store. Alle toepassingen moeten worden opgevat als prototypes, waardoor ontwikkelaars in een vroeg stadium kunnen experimenteren met het fysieke web. In de toekomst, het zou naast smartphones beschikbaar moeten zijn op andere mobiele apparaten.

eddystone url

Hoe werkt het fysieke web??

Het fysieke web zou een verlengstuk van het internet zijn. Zoals alle webtechnologieën, het staat open voor iedereen en iedereen kan het verder ontwikkelen. Omdat het systeem is gebaseerd op de weergave van URL's, het is gedecentraliseerd en wordt door niemand gecontroleerd. De Eddystone-URL kan leiden naar eenvoudige informatiepagina's, tot complexer, interactieve webapps of zelfs naar native applicaties. Het fysieke web is vergelijkbaar met zoeken op internet:

De gebruiker roept een lijst met objecten uit zijn omgeving op.
Er wordt een lijst met URL's weergegeven.
De gebruiker kiest er een.
De URL verschijnt in het browservenster.
Vanuit technisch oogpunt moet met de volgende aspecten rekening worden gehouden:
1. Stuur feedback
2. Geschiedenis
3. Opgeslagen
4. Gemeenschap

• URL's verzenden en ontvangen: Er zijn veel manieren om URL's te verzenden. Het fysieke web ondersteunt momenteel verzending via BLE, mDNS, en SSDP (meer hierover in de volgende sectie).
Haal basisinformatie op van websites: De fysieke webclient verzamelt gevonden URL's en verstuurt deze samen met alle relevante informatie (bijv. de signaalsterkte) naar een webservice. Dit, op zijn beurt, roept de basisinformatie op, zoals de titel, Beschrijving, en pictogram van de website en retourneert de zoekresultaten aan de klant. De prototype-implementatie van de webservice is beschikbaar in de GitHub-repository van het project.

• Weergave van de resultaten: Een rangschikking is belangrijk als het gaat om het weergeven van de vele URL-zendende apparaten uit het gebied. De fysieke webclient kan sorteren op signaalsterkte, persoonlijke voorkeur en andere criteria. Het systeem moet van tevoren spam uitzoeken. Omdat zoekmachines hetzelfde probleem hebben, hun aanpak kan worden gebruikt voor het fysieke web. In het resultatendisplay, de gebruiker klikt op een lijstobject en de browser opent de bijbehorende website.

• Zoals genoemd, het fysieke web kent momenteel drie manieren om URL's te verzenden en te ontvangen. Ze zijn gebaseerd op twee verschillende processen: Bluetooth Low Energy en Network Service Discovery. Theoretisch, in de toekomst kunnen er nog meer methoden worden toegevoegd. Bijvoorbeeld, ontwikkelaars kunnen audiowatermerktechnologie gebruiken om een ​​URL in een audiosignaal in te sluiten. In dit geval, de fysieke webclient zou moeten worden uitgebreid om audiosignalen te kunnen ontvangen en de daarin opgenomen URL's te kunnen decoderen.

Ble Bluetooth en Eddystone

De eerste versie van het fysieke web GEBRUIKT BLE om de URL naar het juiste pakket te sturen. De techniek is erg energiezuinig, vooral als het product dat het gebruikt, in de zendmodus wordt gebruikt (niet-aansluitbare BLE-modus), zoals in het geval van het fysieke web. Kleine BLE-apparaten kunnen de Eddystone-URL bijna twee jaar lang met een enkele knoopcel verzenden.

Een van de basisbouwstenen van het fysieke web is de Eddystone-URL. Als protocolspecificatie, Eddystone definieert een Bluetooth-berichtindeling met laag vermogen voor proximity bakens op basis van de Bluetooth-kernspecificatie. Het beschrijft verschillende frametypen die bakens afzonderlijk of in combinatie kunnen gebruiken: Eddystone-UID, Eddystone-TLM, en de eerder genoemde Eddystone-URL, dat is de enige die relevant is voor het fysieke web.

Een Eddystone-bericht bestaat uit twee basisgegevenstypen in een advertentiegegevensblok (ADVERTENTIE): UUID en dataservice. Beide typen gebruiken een 16-bits universeel unieke identificatiecode (UUID) die voldoet aan de Bluetooth-normen. De UUID-service gereserveerd voor Eddystone is 0xFEAA. Het biedt een mechanisme voor efficiënt, cross-platform achtergrondscannen die zowel Android als iOS toestaan. De volgende bytes van het AD-blok bevatten de gegevens die specifiek zijn voor het frame. De eerste byte definieert het frametype. Momenteel worden alleen de vier belangrijkste bits gebruikt. De vier onderste zijn gereserveerd voor later gebruik en moeten de waarde hebben 0000.

Het Eddystone UID-frame verzendt een unieke 16-byte beacon-ID die bestaat uit een 10-byte naamruimte-ID en een 6-byte instance-ID. Hoewel de naamruimte-ID kan worden gebruikt om een ​​specifieke set bakens te groeperen, de instantie-ID is handig om de apparaten in de groep te identificeren.

Als je kijkt naar het concept van de Eddystone UID, het werkt op een vergelijkbare manier als de iBeacons die door Apple zijn geïntroduceerd in 2013. Het iBeacon-pakket bevat 16 bytes dicht bij de UUID, een primair domein van 2 bytes, en een secundair domein van 2 bytes. iBeacon-pakketten bevatten een proximity-UUID van 16 bytes, 2-byte major en 2-byte minor velden. De nabijheids-UUID kan worden gebruikt om een ​​organisatie of applicatie zoals een bedrijf te identificeren. Hoofd- en secundaire velden maken een meer gedetailleerde toewijzing van de identiteit mogelijk die wordt bepaald door de UUID, zoals in het geval van een filiaal. Eddystone-TLM verzendt nu telemetrische informatie, zoals de batterijstatus, apparaattemperatuur en het aantal pakketten dat door het baken wordt verzonden.

Het Eddystone URL-frame verzendt een gereduceerde versie van de URL die is gegenereerd door codering. De compressie maakt het mogelijk om met het beperkte advertentiepakket meer data te transporteren. Het formaat van de eerste 11 bytes (bytes 0 door 10) van het Eddystone-bericht is hetzelfde voor alle frametypes. Hoe de volgende bytes worden ingesteld (beginnend bij byte 11), echter, afhankelijk van het frametype:

• Byte 11 definieert het frametype. De waarde voor URL-frames van Eddystone is 0x10.
• Byte 12 definieert de kracht van TX. Het is een ondertekende 8-bits gehele waarde zoals beschreven in de TX Power Level Bluetooth Characteristic

Network Service Discovery

Naast BLE-bakens en Eddystone-URL, netwerkdetectiemethoden zoals SSDP en mDNS bieden de mogelijkheid om URL's te verzenden. U kunt ook URL's verzenden naar apparaten op lokale netwerken. De methode heeft twee voordelen ten opzichte van BLE: Eerste, alleen gebruikers die zijn aangemeld bij lokale netwerken kunnen de URL's zien, en ten tweede, er is geen beperking van de URL-lengte zoals bij BLE.

Het gebruik van Network Discovery voor het fysieke web is zinvol in situaties waarin beveiliging en privacy een sleutelrol spelen. Een voorbeeld hiervan is het smarthome-gebied als de toegang tot apparaten alleen beperkt zou moeten zijn tot mensen uit hetzelfde huishouden.

Het Simple Service Discovery Protocol (SSDP) is een netwerkprotocol voor het adverteren en ontdekken van diensten en apparaten in lokale netwerken. Het vormt de ontdekkingslaag van het universele plug-and-play-protocol (UPnP) en helpt bij het publiceren van nieuw toegevoegde apparaten die zijn gedefinieerd als controlepunten. U kunt er ook naar apparaten en specifieke services zoeken.

Dergelijke functies zijn gebaseerd op de twee soorten SSDP-berichten. Eerste, er is het advertentiebericht dat een apparaat verstuurt zodra het aan het netwerk wordt toegevoegd. Het bericht naar het standaard multicast-adres en de poort 239.255.255.250:1900 is ssdp: levend. Controlepunten luisteren naar de poort om SSDP-berichten te ontvangen en zo nieuwe apparaten en diensten te kunnen detecteren. Voordat UPnP-apparaten uit het netwerk verdwijnen of niet langer beschikbaar zijn, ze moeten het bericht ssdp verzenden: bye-bye tegen hetzelfde multicast-adres en de corresponderende poort.

Anderzijds, er is een detectiefunctie waarbij SSDP de controlepunten toestaat apparaten en diensten van belang te vinden, zelfs in het netwerk. In dit geval, een controlepunt stuurt een zoekverzoek naar het multicast-adres en de poort 239.255.255.250:1900. UPnP-apparaten die de aangevraagde services ondersteunen, sturen een unicast-antwoord naar het adres van het controlepunt dat het verzoek heeft verzonden. Het formaat van het antwoord is vergelijkbaar met het SSDP-bericht van het type ssdp: levend.

Physical Web ondersteunt SSDP om URL's in lokale netwerken te verzenden en te ontvangen. Fraunhofer FOKUS ontwikkelde het concept en de implementatie van het bijbehorende mechanisme. De implementatie omvat de integratie van SSDP in de fysieke web-app voor Android en iOS voor het ontvangen van URL's via het protocol. In aanvulling op, een platformonafhankelijke tool op basis van Node.js is beschikbaar om URL's op dezelfde manier te verzenden.

Bij gebruik van SSDP, een fysiek webapparaat dat is verbonden met het lokale netwerk, verzendt de volgende ssdp: levend bericht zodra het beschikbaar is in het netwerk:

MELDEN * HTTP / 1.1 GASTHEER: 239.255.255.250:1900
CACHE-CONTROLE: max-age = seconden tot advertentie verloopt
PLAATS: URL van de webpagina om te adverteren
NT: urn: fysieke-web-org: apparaat: Basic: 1
NTS: ssdp: levend
SERVER: U / versie UPnP / 1.0 Product / versie
USN: advertentie UUID
De NOTIFY-methode in de eerste regel geeft aan dat het een reclameboodschap is. Terwijl de LOCATION-header de fysieke web-URL definieert die wordt verzonden, de NT-header definieert het apparaattype, wat in het geval van het fysieke web urn is: fysieke-web-org: apparaat: Basic: 1. Het SSDP: de levende waarde van de NTS-header geeft aan dat het fysieke webapparaat beschikbaar is. Tenslotte, de USN-header biedt een unieke naam die kan worden gebruikt om het apparaat te identificeren. Fysieke webclients die op smartphones of tablets draaien, luisteren naar het multicast-adres en de poort 239.255.255.250:1900 en filter de fysieke web-SSDP-berichten door de waarde van de NT-header te controleren. U kunt vervolgens het SSDP-bericht analyseren en de waarde lezen van de LOCATION-header die de verzonden URL bevat.

Fysieke webapparaten moeten de volgende ssdp verzenden: bye-bye bericht voordat het uit het netwerk verdwijnt:

MELDEN * HTTP / 1.1 GASTHEER: 239.255.255.250: 1900
NT: urn: fysieke-web-org: apparaat: Basic: 1
NTS: ssdp: tot ziens
USN: advertentie UUID
ssdp: bye-bye maakt duidelijk dat het fysieke webapparaat vanaf nu niet meer beschikbaar is. De waarde van de USN-header blijft hetzelfde als in de ssdp: levend bericht. Fysieke webclients die een dergelijk bericht ontvangen, zoeken naar de URL die is gekoppeld aan het USN en verwijderen deze vervolgens uit de lijst.

 

Praat met een expert