Seite 3: BLE und Eddystone

Inhaltsverzeichnis

Bluetooth Low Energy und Eddystone

Der erste Entwurf des Physical Web nutzt BLE, um die URL in einem entsprechenden Paket auszusenden. Die Technik ist sehr energieeffizient, insbesondere wenn das sie nutzende Produkt wie im Fall des Physical Web im Sendemodus (Non-connectable BLE-Mode) betrieben wird. Kleine BLE-Geräte können fast zwei Jahre lang mit einer einzelnen Knopfzelle URLs aussenden.

Einer der Grundbausteine des Physical Web ist die Eddystone-URL. Bei Eddystone handelt es sich um eine Protokollspezifikation, die ein Bluetooth-Low-Energy-Nachrichtenformat für Proximity Beacons gemäß der Bluetooth Core Specification definiert. Sie beschreibt unterschiedliche Frame-Typen, die Beacons einzeln oder in Kombination verwenden können: Eddystone-UID, Eddystone-TLM und die besagte Eddystone-URL, die als einzige für das Physical Web relevant ist.

Eine Eddystone-Nachricht besteht aus zwei Basis-Datentypen in einem Advertising-Data-Block (AD): UUID- und Data-Service. Beide Typen nutzen einen 16-Bit Universally Unique Identifier (UUID), der den Bluetooth-Standards entspricht. Der für Eddystone reservierte UUID-Service lautet 0xFEAA. Er liefert einen Mechanismus für effizientes, plattformübergreifendes Hintergrund-Scanning, das sowohl Android als auch iOS zulassen. Die darauf folgenden Bytes des AD-Blocks enthalten die für den Frame spezifischen Daten. Das erste Byte definiert jeweils den Frame-Typ. Dabei kommen derzeit nur die vier höchstwertigen Bits zum Einsatz. Die vier niedrigeren sind für den späteren Gebrauch reserviert und müssen den Wert 0000 aufweisen.

Der Eddystone-UID-Frame sendet eine eindeutige 16-Byte-Beacon-ID aus, die aus einer 10-Byte-Namespace-ID und einer 6-Byte-Instance-ID besteht. Sie lässt sich beispielsweise dazu verwenden, ein Gerät einem Datensatz in der Datenbank zuzuordnen. Während die Namespace-ID dazu dienen kann, einen bestimmten Satz Beacons zu gruppieren, ist die Instance-ID hilfreich, um Einzelgeräte in der Gruppe zu identifizieren.

Betrachtet man das Konzept der Eddystone-UID, funktioniert sie ähnlich wie die 2013 von Apple vorgestellten iBeacons. Auch die iBeacon-Spezifikation definiert ein BLE-Nachrichtenformat für Proximity Beacons. iBeacon-Pakete enthalten eine 16-Byte-Proximity-UUID, 2-Byte-Major- und 2-Byte-Minor-Felder. Die Proximity-UUID lässt sich dafür nutzen, eine Organisation oder eine Applikation wie ein Geschäft zu identifizieren. Major- und Minor-Felder ermöglichen eine detailliertere Zuordnung der von der UUID festgelegten Identität, wie im Fall einer Filiale. Telemetrische Informationen wie Batteriestatus, Gerätetemperatur und Anzahl ausgesandter Pakete des Beacons sendet derweil Eddystone-TLM.

Der Eddystone-URL-Frame verschickt eine durch Kodierung erzeugte verkleinerte Version der URL. Durch die Komprimierung ist es möglich, mehr Daten mit dem begrenzt großen Advertisement-Paket zu transportieren. Das Format für die ersten 11 Bytes (Byte 0 bis 10) einer Eddystone-Nachricht ist für alle Frame-Typen identisch. Wie die darauf folgenden Bytes gesetzt sind (ab Byte 11), ist hingegen abhängig vom Frame-Typ:

• Byte 11 legt den Frame-Typ fest. Sein Wert für Eddystone-URL-Frames ist 0x10.
• Byte 12 definiert die TX Power. Es ist ein vorzeichenbehafteter 8-Bit-Integer-Wert wie in der TX Power Level Bluetooth Characteristic beschrieben. Dort wird die Signalstärke bei 0 Metern (TX Power) in dBm spezifiziert. Der Wertumfang reicht bei einer Auflösung von 1 dBm von -100 bis +20 dBM. So lässt sich etwa der Wert 0x12 als +18 dBm interpretieren.
• Byte 13 definiert eine optionale Kennung für URL-Schema-Präfixe. Derzeit werden vier verschiedene Erweiterungen unterstützt (siehe Tabelle 2).
• Bytes 14-30 des Eddystone-URL-Frames enthalten die kodierte URL, deren Maximallänge 17 Bytes beträgt. Um den Wert nicht zu überschreiten, lassen sich URL-Shortener-Dienste nutzen. Die Eddystone-URL-Kodierung benutzt zusätzlich zu den druckbaren Zeichen des US-ASCII-Zeichensets (Codes 0x20 bis 0x7E) auch weitere Codes, die als Abkürzungen für übliche Top-Level-Domains dienen (siehe Tabelle 3).

Beispielsweise lässt sich der Eddystone-URL-Frame für die URL https://www.fraunhofer.de mit einer TX Power von +18dBm (0x12) wie in Abbildung 3 kodieren.