Aktuell wird Bluetooth Dual-Mode Hardware von verschiedenen Herstellern geliefert. Beispiele sind Texas Instruments, Marvell, Broadcom und CSR. Von der Applikationsebene her verhalten sich alle Controller identisch. Auf der Link-Layer-Ebene (Timing, Durchsatz usw.) und den Low-Power-Modus betreffend gibt es aber Unterschiede. Mobiltelefonhersteller abstrahieren diese Unterschiede aber im API der Entwicklungsumgebungen für die jeweilige Plattform. Entwickler von Apps, die mit Bluetooth-LE-Systemen zusammenarbeiten, sollten die API-Funktion der jeweiligen Plattform prüfen. Aktuell sind Entwicklungsplattformen für iOS (Apple), Android (Google) und BB 10 (RIM) lieferbar. Derzeit unterstützt die Bluetooth-Spezifikation keine LE-Kommunikation zwischen zwei Dual-Mode-Controllern. Das ist aber mit entsprechender Host-Software kein Problem. Im Folgenden noch ein kurzer Überblick über die Bluetooth-LE-Funktionen der einzelnen Entwicklungsumgebungen.
Apple iOS
Bluetooth LE Devices, die mit Apple-Geräten kommunizieren, werden bei Apple „Accessory” genannt und können die Peripheral- oder Broadcaster-Rolle verwenden. Alle drei Advertising-Kanäle sollen verwendet werden. Abhängig vom State des Apple Device wird aktives Scanning nicht immer unterstützt. Nur die Advertising PDU ADV_IND, ADV_NOCONN_IND und ADV_SCAN_IND werden unterstützt. Das ADV_DIRECT_INC (Connectable Direct Advertising Event) kann nicht verwendet werden. Das Accessory sollte (Empfehlung) als Teil der Advertising-Daten den Tx-Power-Level-Wert (Bereich: -70 bis zu +20 dBm), den lokalen Namen (Device Name), Flags (Adresse ist Public oder Random) und die unterstützten Services übermitteln. Diese Daten werden in der SCAN_RSP PDU gesendet.
Es werden nur Primary Services unterstützt. Das Advertising-Intervall sollte den Default-Wert von 20 ms für 30 s verwenden. Wenn nach den ersten 30 s keine Verbindung aufgebaut werden konnte, empfiehlt Apple längere Advertising-Intervalle. Diese sind 645, 768, 961, 1065 und 1294 ms. Die Hardware der LE-Controller muss dafür konfiguriert werden. iOS arbeitete mit einem Satz von definierten Parametern für die Verbindungsaufnahme. Diese müssen eingehalten werden, sonst kann die Verbindung u.U. nicht aufgebaut werden.
Das Accessory ist verantwortlich für die Connection-Parameter, welche in einem L2CAP Paket verschickt werden. Die von Apple empfohlenen Werte sind maximal 4 für Slave Latency und kleiner 6 s für Supervision Timeout. Connection-Parameter, welche das Peripheral Device anzeigt, werden vom Apple Device nicht verwendet, d.h. es müssen die Apple-Einstellungen verwendet werden. Das Apple Device nutzt eine Random-Device-Adresse. Das Accessory Device soll kein Pairing verlangen. Alle Sicherheitsprozeduren werden vom Apple Device initiiert. Wenn das Accessory auch Binding unterstützt, Binding aber nicht von der App verwendet wird, kann das Accessory den Attribute Request ablehnen. Der zurückgegebene Error Code ist „Insufficient Authentication“. Das Accessory Device sollte die DeviceName Characteristic mit dem Write-Attribut unterstützen, denn damit kann das Apple Device den Namen ändern. Die Umsetzung dafür ist bis jetzt allerdings sehr speziell. Informationen über das Device sind Teil des Device Information Service. Die UUID dieses Service sollte nicht in den Advertising-Daten enthalten sein. Die Characteristic für diesen Service sind Herstellername, Modellnummer, Firmware- und Software-Version. ATT- und GATT-Client/Server-Funktionen werden unterstützt.
Die Entwicklung unter iOS v6 und höher gestaltet sich mit Xcode relativ einfach. Es wird ein Peripheral Manager mit den gewünschten Services und Characteristics angelegt. Indication wird auch unterstützt. Die Services werden dem Peripheral Manager hinzugefügt und dann advertised. Wichtig sind die Verwendung des aktuellen iOS Core Bluetooth Framework und die Behandlung bestimmter Hardware-Zustände der Dual-Mode Hardware. Mitunter kommt es zu einem Reset des Dual-Mode-Funkteils, so dass hier erfahrungsgemäß die meisten Probleme liegen.
Ab iOS v7 wird auch HID über GATT unterstützt. Damit ist die Anbindung externer Tastaturen über Bluetooth LE möglich. Weitere Erweiterungen sind ein Message Notification Center für eintreffende Anrufe, E-Mail, SMS, Termine usw.
Android
Ab Version 4.2 verwendet Android einen Bluetooth Stack von Broadcom. Ab Android 4.3 wird auch Bluetooth LE mit einem Broadcom Stack unterstützt. Von Motorola und Broadcom war bisher Bluetooth-LE-Software (z.T. Chip-spezifisch) erhältlich.
Die Motorola-Software beherrscht nur die GATT-Client-Funktion für Verbindungen zu einem Remote GATT Server. Das Pulsprofil (Monitor) ist integriert. Die Device-Rolle ist Collector mit den Client Services. Die Software erlaubt aber auch die Integration von Profilen der Bluetooth SIG sowie von herstellerspezifischen Services und Profilen.
Das Bluetooth-LE-Paket von Broadcom läuft unter einer Apache-Lizenz und umfasst die ATT- und GATT-Client/Server-Funktion. Profile werden nicht mitgeliefert. Die Integration von Bluetooth-SIG-definierten, aber auch von spezifischen Services und Profilen ist möglich.
Aktuell sollten nur die Bluetooth LE APIs von Android 4.3 eingesetzt werden. Wenn die App aktiv die Suche nach anderen LE-Geräten betreibt, müssen einige Rechte gesetzt werden. Man kann das Android-Gerät aber auch als Peripheral definieren. Die Suche des Android-Gerätes nach Devices mit einer bestimmten UUID wird unterstützt. Die LE-Unterstützung in Android ist noch relativ neu. Die Stabilität entspricht nicht der bei iOS. Support ist übrigens nicht bei allen Geräten gegeben. Bei einigen Nexus-Geräten muss ein Rooting erfolgen, damit LE verwendet werden kann.
BB10 (RIM)
Die neue BlackBerry-Entwicklungsumgebung BB10 für BB Z10/Q10 unterstützt auch Bluetooth LE. Für Bluetooth LE steht eine sehr komfortable Entwicklungsumgebung zur Verfügung. Es werden GATT Client und Server unterstützt.
Windows 8.1 RT
Dieses Betriebssystem ist aktuell das einzige von Microsoft mit Bluetooth-LE-Unterstützung. Bluetooth-LE-Geräte werden bei 8.1 RT als über Device Objects unterstützte Services und Profile abgebildet. Aktuell ist nur Notification unterstützt. Man sollte die bei iOS empfohlenen Lower-Layer-Parameter auch für andere Systeme verwenden. Da die Profil- und Service-Implementierung z.T. aufwendig ist und sich die Entwicklung ohne Protokollanalysatoren aufwendig gestaltet, empfiehlt sich die Verwendung von kommerziellen Bluetooth-Service/Profile-Bibliotheken. Diese werden auch von den meisten Konsumgütern verwendet. Damit ist auch eine ausreichende Interoperabilität und Robustheit der Implementierung gewährleistet.
Rudi Latuske |
---|
ist Geschäftsführer der ARS Software GmbH und beschäftigt sich seit 15 Jahren mit Software für die Nahbereichsvernetzung über Bluetooth/Bluetooth Low Energy, ZigBee und IrDA. Darüber hinaus ist er Mitglied im DKE-Normungsgremium (DIN/VDE) und diversen Fachverbänden. |