iBeacon

Beim Thema Kommunikationsaufbau bei Bluetooth möchten wir iBeacon nicht ganz unerwähnt lassen. Wie oben angesprochen, schicken BluetoothLE-Geräte Inquiry Messages aus. Das Format als solches ist standardisiert - über EIF (Extended Inquiry Format) können Geräteproduzenten aber ein eigenes Subformat implementieren. Apple tut das bei iBeacons und packt standardkonform in die Inquiry Message gleich eine eindeutige Identifizierung des jeweiligen iBeacons. Außerdem ist die Sendestärke der Bluetooth-Geräte ebenfalls Teil der Inquiry-Nachricht.

Damit kann eine App errechnen, in welcher Entfernung sich welche iBeacons befinden. In Kombination mit der Registrierung der iBeacons und deren Position bei Apple kann eine App damit zielgenau eine Person bespielen. Wohlgemerkt: Das alles spielt sich ohne einen weiteren Verbindungsaufbau über Bluetooth ab, die eigentliche Logik läuft komplett über das Smartphone und die Server bei Apple. Das iBeacon muss keine Services bereitstellen.

Begriffsverwirrung

Bevor wir zu praktischen Fingerübungen kommen, gilt es noch, ein wenig Sprachpräzisierung zu betreiben. Die Bluetooth-Spezifikation verwendet diverse Begriffe, um zu beschreiben, wie Geräte miteinander in Beziehung stehen. Da ist von Server - Client, Observer - Observable, Controller - Target, Master - Slave, Source - Sink oder Central - Peripheral die Rede. Diese Begriffspaare sind zumeist profilspezifisch. Da aber viele APIs, Programme und Geräte mehrere Profile unterstützen, und aufgrund sprachlicher Gewohnheiten, werden die Begriffe gerne wild durcheinandergeworfen.

Beim GATT-Profil wird von einem "Peripheral"-Modul gesprochen, um das Daten erhebende beziehungsweise ausführende Gerät zu beschreiben. Im obigen Beispiel wäre es das Armband. Das "Central"-Modul ist hingegen das Gerät, welches das eigentliche Programm und die Logik ausführt, also zumeist ein Smartphone oder ein Computer. Parallel ist auch die Verwendung von GATT-Server für das Peripheral- und GATT-Client für das Central-Modul üblich.