1

Bluetooth 2.1/3.0, Bluetooth Profile und Bluetooth Low Energy

Rudi Latuske, ARS Software GmbH

1. Einführung

Bluetooth wurde im Januar 1999 (Version 1.0a) vorgestellt und kann damit auf eine über 10 jährige Entwicklung zurückblicken. Grund eine kurze Zusammenfassung der Bluetooth Versionen zu geben und den aktuellen Stand bei Bluetooth (Version 2.1 und 3.0) genauer zu betrachten. Der Artikel gibt auch einen Überblick über die Bluetooth Low Energy Variante und einige Profile wie das Phone Book Access Profile (PBAP), Message Access Profile (MAP), Advanced Audio Distribution Profile (A2DP), Audio Video Remote Control Profile (AVRCP), Health Device Profile (HDP) sowie ein Überblick über die Synchronisation und PC Stacks sowie Bluetooth USB Adapter. Für eine Bluetooth Einführung wird auf die Literatur im Anhang verwiesen.

2. Bluetooth Versionen Die erste Bluetooth Spezifikation nach der Produkte entwickelt wurden war 1.0b vom Dezember 1999. Diese Version hatte einige Inkonsistenzen in der Spezifikation die zu unterschiedlichen Interpretationen geführt haben. Dadurch gab es vereinzelt Probleme bei der Interoperabilität.

Im Februar 2001 wurde Version 1.1 vorgestellt. Diese Version beinhaltet die Korrektur von Inkonsistenzen in der 1.0b Spezifikation sowie u. a. die genauere Definierung von Basisband Timern, MTU Size, HCI Events und der Arbeitsweis von Profilen. Basierend auf der Spezifikation 1.1 wurden nur 77 Endprodukte (inklusiv deren Varianten) wie z.B. verschiedene Mobiltelefone, Headsets und SDIO und PC-Card Adapter für PC und PDA vorgestellt.

Mit der Version 1.2 wurden im November 2003 erstmals grundlegend neue Funktionen eingeführt. Diese sind Faster Connection, Adaptive Frequency Hopping (AFH) zur Vermeidung von Störungen im 2,4 GHZ Band (wenn z. B. Bluetooth und WLAN im gleichen Empfangsbereich aktiv sind), Extended SCO (eSCO) Links für eine bessere Qualität bei der Übertragung von Sprache, Enhanced Error Detection and Flow Control im L2CAP Layer, Enhanced Synchronization Capability im Basisband und Enhanced Flow Specification im L2CAP Layer. Nicht alle neuen 1.2 Merkmale sind in der Bluetooth Hardware (ICs) integriert. Nach der Bluetooth 1.2 Spezifikation wurden insgesamt 1015 Endprodukte qualifiziert und vorgestellt.

Im November 2004 wurde schließlich die Version 2.0 + EDR vorgestellt. Wesentliches Merkmal dieser Version ist die EDR (Enhanced Data Rate) Erweiterung die eine deutlich erhöhte Geschwindigkeit (2 bzw. 3 Mbit/s) und neue Pakettypen für Daten und Sprache beinhaltet. Dadurch ist eine höhere Übertragungsrate bzw. auch Bandbreite der zu übertragenen Sprachsignale möglich. Tabelle 1 zeigt die Pakettypen und die damit mögliche Datenübertragungsrate. Weitere Änderungen betreffen kleinere Änderungen im HCI und die Entfernung der Unterstützung für den Periodic Page Scan Mode. Bluetooth 2.0 bedeutet nicht, dass das entsprechende Produkt auch EDR – und damit die höhere Datenübertragungsrate und i. d. R. die deutlich bessere Qualität – unterstützt! Es ist auch zulässig Geräte mit Bluetooth 2.0 (ohne EDR) in den Markt zu bringen. Bis Ende August 2009 wurden ~2040 Bluetooth 2.0 (ohne EDR) und ~2820 End Produkte nach der Bluetooth 2.0 + EDR Spezifikation qualifiziert. Im Juli 2007 wurde schließlich die Version Bluetooth 2.1 + EDR (2.1 ohne EDR ist zulässig!) vorgestellt. Bis Ende August 2009 wurden 80 Produkte nach 2.1 und ~1130 Produkte nach 2.1 + EDR qualifiziert. Aktuell sollte nur noch Bluetooth 2.0 und 2.1 mit EDR eingesetzt werden.

Im April 2009 wurde die Version 3.0 + HS (High Speed) vorgestellt. Die Markteinführung von Produkten die diese Bluetooth Version einsetzen ist 2010 geplant. Für 1.2 waren Änderungen der Hardware (Bluetooth IC) und den Hoststack, für 2.0/2.0 + EDR primär der Hardware, für 2.1 und 3.0 + HS der Hardware und des Hoststack notwendig. Für weitere Informationen zu Bluetooth wird auf die Literatur [1], [2], [3], [4]und [5] verwiesen.

2

3. Bluetooth 2.1 Diese Bluetooth Version ist auch unter dem Code Namen Lisbon bekannt und beinhaltet grundlegende neue Features die u. a. die Security verbessern, die Übertragungsqualität erhöhen und den Stromverbrauch reduzieren. Die neuen Features im Detail sind: Encryption Pause/Resume Verschlüsselung wird bei Bluetooth unterstützt. Bei einem Link auf dem verschlüsselte Daten übertragen werden ist aber kein Master/Slave Switch (Wechsel der Rollen einer Kommunikation) möglich. Ab Bluetooth 2.1 kann die Verschlüsselung für die Dauer des Master/Slave Switch unterbrochen werden. Nach Wechsel der Master/Slave Rollen wir die Verschlüsselung wieder aktiviert. Diese Operation werden im Bluetooth Controller (Link Manager) abgearbeitet. Damit wird sichergestellt, dass Daten niemals unverschlüsselt übertragen werden. Bei Verwendung dieses Feature ist der Wechsel des Link Key alle ~23 Stunden empfohlen. Auch für diese Operation (Austausch der Zufallszahl und des SRES) wird die Verschlüsselung kurzfristig unterbrochen. Wenn der neue Link Key beiden Geräten bekannt ist, wird ein neuer Encryption Key angelegt und alle Daten werden mit diesem neuen Key verschlüsselt übertragen. Erroneous Data Reporting SCO oder eSCO Pakete (andere werden durch Erroneous Data Reporting nicht unterstützt) mit Bitfehlern werden – wenn wie bei SCO nicht oder wie bei eSCO nicht öfter als eingestellt wiederholt – verworfen. In vielen Fällen beinhalten solche Pakete aber noch Informationen die z. B. von einer Sprachanwendung mit Fehlerbehandlung oder speziellen Algorithmen noch bearbeitet werden können. Dieses Feature erlaubt die Kennzeichnung fehlerhafter Pakete und ermöglicht damit höheren Layern die Erkennung dieser Pakete und deren gezielte Verarbeitung. Extended Inquiry Response Extended Inquiry Response (EIR) verkürzt die Zeit, die für eine erstmalige Aufnahme einer Verbindung notwendig ist. Das wird dadurch erreicht, dass in der Antwort (EIR Paket) der Gerätename (Device Name), unterstützte Profile, Sendeleistung und Herstellerinformationen (Namen, Versionen) übertragen werden. Diese Informationen werden in einem ACL Paket (1-, 3- oder 5 Slot) gesendet.

Diese Information konnten bei Bluetooth 2.0 (und den vorhergehenden Versionen) nur durch spezifische Abfragen mittels Remote Name Request und dem Service Discovery Protokoll (SDP Requests) erhalten werden. Ab Bluetooth 2.1 stehen diese Informationen zur Identifizierung von Geräten und deren unterstützter Services sofort noch der Antwort der entsprechenden Geräte auf ein Device Discovery (Gerätesuche) zur Verfügung.

Bis Bluetooth 2.0 dauert ein Inquiry Vorgang (Gerätesuche) ungefähr 10 Sekunden. Dieser Vorgang kann aber abgebrochen werden, wenn 1) das gesuchte Gerät gefunden wurde; 2) eine vorab eingestellte Anzahl von Geräten gefunden wurde oder aber 3) bei einem Timeout bzw. Abbruch durch den Anwender.

Ab Bluetooth 2.1 wird dem Host auch die Möglichkeit zur Geräteauswahl basierend auf dem Received Signal Strength Indicator (RSSI) gegeben. Damit ist es möglich die gefunden Geräte nach absteigender Empfangsleistung sortiert auf einem Display anzuzeigen. Unter der Annahme, dass sich in der Nähe befindliche Geräte eine höhere Eingangsleistung am Empfänger erzeugen, ist die gezielte Auswahl von Geräten möglich.

Mit der frühen Bereitstellung relevanter Geräteinformationen kann eine schnelle Geräteauswahl und schnellere Verbindung mit diesem Gerät erreicht werden. Mit EIR kann Bluetooth auch für Anwendungen ein gesetzt werde, die eine schnelle Verbindungsaufnahme erfordern. Der Bluetooth Host Controller kann EIR im Bluetooth IC aktivieren oder auch sperren. Damit kann ein Bluetooth 2.1 IC für rückwärtskompatible Anwendungen eingesetzt werden. Link Supervision Timeout (Link Supervision Timeout Changed Event) Scatternets basieren auf mindestens zwei Piconets (Bild 1) und bilden damit flächenmäßig ein größeres Bluetooth Netzwerk.

3

Bild 1 Scatternet mit mehreren Piconets. Geräte arbeiten als Master und Slave Technische Grundlage ist die Möglichkeit für ein Bluetooth Slave als Bluetooth Master zu arbeiten und andere Bluetooth Slaves zu verwalten. Diese Funktion ist nicht völlig ohne Risiko. Bei dieser Dual-Mode (Master/Slave) Rolle kann es zum Verbindungsabbruch kommen Master Nodes müssen nicht nur den Datenverkehr zwischen anderen Devices und sich selbst verwalten, sondern müssen sich auch von einer Verbindung entfernen können um in einem anderem Netzwerk als Slave mit einem anderem Master kommunizieren zu können. Dabei kann das erforderliche Zeitverhalten verletzt werden. Bei Bluetooth 2.0 waren die Link Timeout Settings nur dem Master bekannt, da nur der Master das Link Timing definiert. Bei Bluetooth 2.1 verwalten der Master und der Slave dieses Event für den Link Status. Damit ist ein stabilerer Betrieb im Scatternet ohne das Risiko eines Verbindungsabbruchs gegeben. Packet Boundary flag (Non-Flushable Packet Boundary Flag) Audiodaten die von einem Player (A2DP Source) in Echtzeit (Streaming) zu einem Headset (A2DP Sink) geschickt werden müssen – um eine gute Audioqualität zu gewährleisten - die Reihenfolge einhalten. Pakete mit Audiodaten können aber bis zu einem gewissen Grad verworfen oder verloren gehen bevor der Zuhörer eine Verschlechterung der Qualität erkennt. Pakete die als Ergebnis einer schlechten Funkstrecke fehlerhaft sind können immer noch von Audio CODEC verarbeitet werden. Diese Vorgehensweise führt innerhalb gewisser Grenzen nicht zu einer hörbaren Verschlechterung der Qualität. Situationen bei denen mehrere Profile gleichzeitig aktiv sind, können die Übertragungsqualität und den Durchsatz beeinflussen. Eine Übertragung von Daten auf einem ACL Link kann – da ein Paket bis zum korrekten Empfang immer wieder wiederholt werden kann - als zuverlässig betrachtete werden. Wenn aber die Daten nur eine bestimmte Zeit von Bedeutung sind (z. B. die Daten einer Musikübertragung) ist es nicht vorteilhaft die Daten bis zu einer endgültigen fehlerfreien Übertragung in der Queue zu halten. Solche Daten sind u. U. schon nach ein paar hundert Millisekunden nicht mehr relevant da neuere Pakete schon übertragen wurden. Das trifft besonders auf A2DP Daten zu. Wenn dazu noch verschiedenen Applikationsdaten auf einem Link gemeinsam übertragen werden, kann das zu Problemen führen. Wenn z. B. ein Mobiltelefon Musik überträgt und gleichzeitig ein Anruf eingeht, führt die Signalisierung (bzw. der Verbindungsaufbau) zwischen Mobiltelefon und z. B. einer Freisprecheinrichtung dazu, dass Daten für Control (Anrufsignalisierung o. ä.) mit den A2DP Daten auf einem ACL Link übertragen werden. Control Signale sind wichtig, Pakete mit Musikdaten können aber teilweise verworfen werden. Das selektive verwerfen von Paketen kann aber nur dann erfolgen, wenn die Pakete entsprechend markiert sind.

4

Das Packet Boundary Flag ermöglicht diese Identifikation und wird entsprechenden ausgehenden Paketen zugeordnet. Damit kann das entsprechende Flush Kommando abgesetzt werden, um – bedingt durch einen schlechten Radio Link – nicht gesendete Pakete zu verwerfen. Typischerweise werden nur A2DP Pakete mit diesem Flag markiert. Wie oben bereits erwähnt führt das kaum zu einer qualitativen Beeinträchtigung der Musikwiedergabe. Für diese Funktion wurde der L2CAP Layer bei Bluetooth 2.1 erweitert. Secure Simple Pairing Die Security Modes 1 (keine Security), 2 (servicespezifische), 3 (linkspezifische) wurden um den Mode 4 (Secure Simple Pairing) erweitert. Secure Simple Pairing ist ein Merkmal welches leichte Handhabung und strake Sicherheit vereint. Endanwender der Bluetooth Technologie sind i. d. R. nicht an den Abläufen der Kommunikation, des Protokolls und der Security interessiert. Stattdessen wird die problemlose Funktion der Technologie und der verwendeten Security Mechanismen vorausgesetzt. Security Mode 1 und 3 wird ab Bluetooth 2.1 nicht mehr unterstützt. Security Mode 2 wird von einem Bluetooth 2.1 Gerät nur unterstützt, wenn die Gegenstelle ein non-Bluetooth 2.1 Gerät ist. Pairing ist der Vorgang, bei dem der Anwender eine persönliche Nummer (PIN) auf seinem Gerät eingibt. Diese PIN muss mit der auf dem Server abgelegten/eingegeben übereinstimmen. Die für den Verbindungsaufbau notwendigen Schritte (Suchen der entsprechende Menüpunkte, Verbindungsaufbau, PIN Eingabe usw.) können für den Anwender, der die entsprechende Beschreibung nicht liest, problematisch sein.

Im Unterschied dazu ist Secure Simple Pairing wesentlich einfacher in der Handhabung und bietet eine stark erhöhte Sicherheit die ein Abhören und dekodieren der Kommunikation unmöglich macht. Abhören des Pairing und Berechnung des Link Key, der die Voraussetzung für die Authentication des Link und der Encryption der zu übertragenden Daten ist, kann nach dem aktuellen Stand der Technik völlig ausgeschlossen werden.

Viele Geräte haben keine Display oder eine Tastatur. Einige haben nur eines davon (Bluetooth Keyboard). Secure Simple Pairing berücksichtigt das und empfiehlt diverse Szenarios um ein Pairing, Authentication und letztendlich Bonding (abspeichern des Link Key) zu erreichen. Diese Szenarios werden Association Modes genannt und definieren die Art und Weise, mit der Geräte die PIN akzeptieren. Die Association Modes sind 1) Numeric Comparison, 2) Just Works, 3) Out of Band und 4) Passkey Eingabe. Jeder Mode spezifiziert eine Methode für die PIN Eingabe und definiert dabei auch die Länge der PIN.

Aktuell (Security Mode 2 und 3) ist die Verwendung einer 4-stelligen PIN für das Pairing sehr verbreitet. Bei Secure Simple Pairing wird eine PIN mit 6 Stellen (bzw. maximal 16 Stellen) verwendet. Dadurch und durch die Verwendung der Verschlüsselung mittels Elliptic Curve Diffie Hellman wird die Link Security stark verbessert. Bei einer Kommunikation zwischen 2.1 Geräten wird die gesamte Kommunikation (auch eine A2DP Übertragung) verschlüsselt. Untersuchungen zeigten, dass man sich eine 6-stellige PIN leicht merken kann. Im Unterschiede zu vorhergehenden Bluetooth Versionen kann bei Bluetooth 2.1 eine alphanumerische PIN – also Zahlen und Buchstaben – verwendet werden. Zuvor wurden nur numerische PIN unterstützt.

Numeric Comparison Dieser Mode wird in Situationen verwendet, bei denen beide Geräte ein Display und eine Tastatur haben. Eine 6-stellige PIN erscheint auf beiden Displays. Der Anwender wird gefragt ob die gezeigte PIN auf beiden Geräten identisch ist. Wenn der Anwender mit JA antwortet wird, ist die Authentication abgeschlossen. Encryption wird anschließend initiiert. Ein Beispiel für diesen Mode ist das Pairing zwischen einem Mobiltelefon und einem PC.

Just Works Dieser Mode erlaubt zwei Geräten die Authentication und ggf. das Bonding ohne Anwendereingriff. Wenn der Link aufgebaut ist wird Encryption unterstützt. Just Works ist für Geräte die weder Display noch Tastatur besitzen. Dabei werden z. T. Funktionen des Numeric Comparison Mode verwendet. Identische 6 stellige PIN werden in beiden Geräten für das Pairing verwendet. Der Anwender muss dabei aber nicht die Korrektheit der Zahlen bestätigen. Der Anwender kann aber vor dem Verbindungsaufbau gefragt werden, ob er die aufzubauende Verbindung wünscht. Das setzt aber auf mindestens einem Gerät ein User Interface voraus.

5

Out of Band Die Bluetooth Geräteadresse und die PIN wird zwischen den Geräten über einen anderen Kanal (Out of Band) als Bluetooth übertragen. Dafür kann IrDA oder auch NFC (Near Field Communication) verwendet werden. Die so ausgetauschten Informationen werden für die Durchführung des Authentication Vorgangs verwendet.

Passkey Eingabe Dieser Association Mode ist für Geräte bei denen eines ein Display, und das andere eine Tastatur hat Dabei wird eine 6-stellige PIN auf dem Display angezeigt. Diese PIN wird dann auf dem Geräte mit Tastatur eingegeben. Damit ist Authentication möglich.

Secure Simple Pairing bietet durch Verwendung einer längeren PIN und eines sicheren Verschlüsselungsalgorithmus ein Höchstmaß an Sicherheit bei gleichzeitig stark erleichterter Bedienung und Anwendung.

Secure Simple Pairing wird durch Erweiterungen im Stack unterstützt. Dabei wird über ein Kommando (I/O Capabilities), welches die Umsetzung der Association Modes und deren Unterstützung im lokalen und remote Gerät beschreibt, die Auswahl des Association Mode mit der jeweiligen Gegenstelle ausgehandelt.

Die I/O Capabilities (Display Only, Display Yes/No, Keyboard Only und No Input/No Output) und das Verhalten beim Secure Simple Pairing sind in Tabelle 1 beschrieben.

Initiator A Responder B

Display Only Display Yes/No Keyboard Only No Input/ No Output

Display Only Numerischer Vergleich mit automatischer Bestätigung auf beiden Geräten Unauthenticated

Numerischer Vergleich mit automatischer Bestätigung auf Gerät B Unauthenticated

Passkey Eingabe. Responder Display, Initiator Input Authenticated

Numerischer Vergleich mit automatischer Bestätigung auf beiden Geräten Unauthenticated

Display Yes/no Numerischer Vergleich mit automatischer Bestätigung auf Gerät A Unauthenticated

Numerischer Vergleich. Beide Display, Beide Confirm Authenticated

Passkey Eingabe. Responder Display, Initiator Input Authenticated

Numerischer Vergleich mit automatischer Bestätigung auf Gerät A Unauthenticated

Keyboard Only Passkey Eingabe. Initiator Display, Responder Input Authenticated

Passkey Eingabe. Initiator Display, Responder Input Authenticated

Passkey Eingabe. Initiator und Responder Input Authenticated

Numerischer Vergleich mit automatischer Bestätigung auf beiden Geräten Unauthenticated

No Input/ No Output

Numerischer Vergleich mit automatischer Bestätigung auf beiden Geräten Unauthenticated

Numerischer Vergleich mit automatischer Bestätigung auf Gerät B Unauthenticated

Numerischer Vergleich mit automatischer Bestätigung auf beiden Geräten Unauthenticated

Numerischer Vergleich mit automatischer Bestätigung auf beiden Geräten Unauthenticated

Die Security API eines Bluetooth 2.1 kompatiblen Stacks definiert für das Secure Simple Pairing die Security Level 0, 1, 2, und 3. Tabelle 2 vergleicht die Security Level und beschreibt deren wesentlichen Merkmale.

6

Für Services erforderliche Security Level

Erforderlicher Link Key Type für das remote Device

Erforderlicher Link Key Type für Geräte vor BT 2.1 (2.0, 1.2)

Anmerkungen

Level 3 - MITM Schutz erforderlich - Encryption gewünscht - Anwendereingriffe werden akzeptiert

Authenticated Combination Key mit 16 Zeichen ist empfohlen

Hohe Security

Level 2 - MITM Schutz nicht notwendig - Encryption gewünscht

Unauthenticated Combination Key Mittlere Security

Level 1 - MITM Schutz nicht notwendig - Encryption nicht notwendig ist aber MANDATORY für alle Services außer SDP wenn die Gegenstelle ein 2.1 Gerät ist - Minimale Anwender- eingriffe gewünscht

Unauthenticated Keiner Geringe Security

Level 0 - MITM Schutz nicht notwendig - Encryption nicht notwendig - Keine Anwendereingriff Gewünscht

Keiner Keiner Nur für SDP erlaubt!

Es ist möglich Schutz vor “Man in the Middle” Angriffen zu spezifizieren. Wenn beide Bluetooth Geräte Version 2.1 unterstützen und Security Level 3 spezifiziert ist, wird der Schutz vor „Man in the Middle“ und Verschlüsselung automatisch aktiviert. Security Level 1 und 2 hat keinen Schutz vor “Man in the Middle” Angriffen. Die Bonding Modes (abspeichern der Link Keys) Dedicated, General und No Bonding werden von Secure Simple Pairing unterstützt. Sniff Subrating Beim Sniff Mode kann der Slave nur zu einer bestimmten Zeit (Sniff Anchor Points, Sniff Intervall) ACL Daten empfangen. Dieses Intervall (Duty Cycle) ist fix. Um Strom zu sparen, ist ein Datenempfang in den außerhalb des Intervalls liegenden Time Slots nicht möglich. Sniff Subrating ist eine Erweiterung des Sniff Mode. Wenn Sniff Subrating im Link Manager aktiviert ist wechselt das Gerät zwischen Sniff Mode und Sniff Subrating und der Duty Cycle wird – wenn für längere Zeit keine Daten gesendet wurden – erhöht. Die Dauer der Periode während der nicht gesendet wird kann mehrere 10 Sekunden betragen. Ein Gerät kann in den Sniff Mode wechseln wenn die Datenübertragung nicht mehr kontinuierlich ist. Wenn die Zeit in der keine Daten gesendet werden sich weiter vergrößert (Bild 2), kann ein Gerät in den Sniff Subrating Mode wechseln und der Duty Cycle wird weiter reduziert.

7

Bild 2 Sniff-Mode und Sniff Subrating Wenn Daten gesendet werden wird dieser Mode verlassen und das Gerät überträgt wieder kontinuierlich Daten. Die Anwendung von Sniff Subrating ermöglicht eine Stromreduzierung bei mobilen Geräten oder PC Zubehör (HID Geräte wie Maus, Pen usw.).

4. Bluetooth 3.0 Diese Bluetooth Version ist auch unter dem Code Namen Seattle bekannt. Bluetooth 3.0 hat als Ziel eine wesentliche Steigerung der Datenrate (bei 2.1 + EDR beträgt die Bruttodatenrate ca. 3 Mbit/s) durch die Verwendung anderer PHY (Radio) Layer. Dafür begannen bereits 2006 Planungen die die Verwendung von Ultra-Wideband (Variante der WiMedia Alliance) und IEEE 802.11 als PHY Layer vorgesehen haben. Eine zu Anfang bestehende Präferenz für Ultra-Wideband wurde im Jahre 2008 aufgegeben. Ultra-Wideband hat zwar einen sehr geringen Stromverbrauch pro Byte, allerdings ist der Stromverbrauch der Ultra-Wideband Controller für mobile Geräte nur bedingt geeignet. Auch war die Verfügbarkeit von Ultra-Wideband ICs für mobile Endgeräte nicht zufriedenstellend geklärt. Da der Markt sich bei Ultra-Wideband nicht wie erwartet entwickelt hat, gab es eine Reihe von Firmenzusammenschlüssen von Ultra-Wideband IC Herstellern bzw. einige Konkurse. Die Ultra-Wideband Spezifikation der WiMedia Alliance sind im März 2009 auf die Wireless USB Promoter Group, das USB Implementers Forum und die Bluetooth SIG übergangen.

Die Bluetooth SIG hat daher den Fokus auf IEEE 802.11 gesetzt. Die Bluetooth Spezifikation 3.0 + HS (High Speed) definiert einen generischen Abstraktions-Layer A2MP (Alternate MAC/PHY Manager Protocol) für den AMP (Alternate MAC/PHY) und einen 802.11 PAL (Protocol Adaptation Layer) für den IEEE 802.11-2007 Standard. AMP und A2MP sind grundsätzlich auch für Ultra-Wideband geeignet. Der entsprechende PAL für UWB (Ultra-Wideband) hat den Stand einer Prototypenspezifikation (v09 vom Juni 2008). Eine Annahme der UWP PAL Spezifikation ist für Ende 2010 geplant.

Die Bluetooth 3.0 + HS Spezifikation erlaubt zwei mögliche Systemvarianten: Bluetooth 3.0 (ohne HS) aber mit mindestens einem 3.0 + HS Merkmal (das wird in den meisten Fällen Enhanced Retransmission sein) und 3.0 + HS. Ein System mit Bluetooth 3.0 + HS muss – gemäß der aktuellen Spezifikation – alle Mandatory Merkmale des 802.11 PAL, des A2MP und dafür erforderlichen L2CAP Merkmale (u. a. Enhanced Retransmission, Fixed Channel Unterstützung) beinhaltem.

Die Architektur eines Bluetooth 2.0/2.1 Systems wird als bekannt angenommen. Im Folgenden wird daher nur die 802.11 PAL/A2MP spezifische Architektur besprochen. Bild 3 zeigt ein Bluetooth 3.0 + HS System. Bild 3 Bluetooth 3.0 + HS System (Maximalausbau)

8

Das Bild zeigt den BR/EDR (Basic Rate/Enhanced Data Rate) Controller von Bluetooth 1.X/2.X und den AMP (Alternate MAC/PHY) von Bluetooth 3.0 + HS. Das im Bild schematisch gezeigte Bluetooth System hat einen Bluetooth 2.1 BR/EDR und einen (802.11 PAL) oder mehrere (802.11 PAL oder UWB PAL) AMP Controller. Die Verbindung zwischen den Controllern und dem Host erfolgt über das bekannte HCI (Host Controller Interface). Bei Bluetooth 3.0 + HS ist mit neuen Anbietern im Controller Markt zu rechnen. Dabei werden separate AMP Controller und solche mit BR/EDR und AMP auf einem Chip angeboten. Letzteres bedeutet, dass auf einem Controller 3 Transceiver (BR, EDR und AMP) integriert sind. Mit einem ULP (Ultra Low Power) Controller sind es dann 4 Transceiver. Aktuelle Controller verwenden weiterhin die UART Schnittstelle (H4 oder H5) für Bluetooth und SDIO für den AMP (802.11) Controller. Die Architektur eines 3.0 + HS Systems ist um einiges komplexer (Bild 4).

Bild 4 Bluetooth 3.0 + HS Core Architektur mit L2CAP Layer

9

Bei A2MP übernimmt der AMP Manager die Suche nach anderen AMP Managern in remote Geräten. Der AMP Manager ist für die Abfrage der Informationen (maximale und garantierte Bandbreite, Verzögerungszeit) andere AMP Manager, die Verwaltung der physikalischen (Radio) Links und des Erzeugung spezifischer AMP Schlüssel (bei erstmaliger Verwendung) unter Verwendung von Secure Simple Pairing zuständig. Pairing und Link Key Erzeugung ist identisch zu Bluetooth 2.1. Der Link Key für AMP wird aus dem Bluetooth 2.1 Link Key für jeden AMP (z. B. 802.11b) abgeleitet und zusammen mit dem Bluetooth BR/EDR Link Key abgespeichert. Wie bisher auch wird der AMP Link Key für die Authentication der Devices verwendet. A2MP verwendet ausschließlich den Bluetooth BR/EDR Controller, d.h. dafür werden die Links und Pakete von Bluetooth 2.1 und ein fixer (Eigenschaften werden nicht ausgehandelt) L2CAP Channel verwendet. Der L2CAP Layer wurde – um die Funktionalität von 3.0 + HS umsetzen zu können – stark erweitert. Das beinhaltet eine verbesserte Flow Spezifikation (Aushandlung mittels Lockstep zwischen den beteiligten Geräten), eine erweiterte Window Size (mehr Buffer für Übertragungen die eine hohe Datenrate erfordern), die Integration von Enhanced Retransmission Mode (Verbesserung des bisher eingesetzten Retransmission Mode unter Verwendung eines HDLC Subset basierend auf ISO/IEC 13239) mit Unterstützung von Segmentation and Reassembly und Streaming Mode. Der Streaming Mode ist für die Übertragung von Audio und Video optimiert und verwendet SAR (Segmentation and Reassembly). Basisband Flow Control wird im Streaming Mode nicht verwendet. Die auf einem AMP Link übertragenen Daten werden verschlüsselt. Bluetooth 3.0 + HS unterstützt die Zuverlässigkeit der Datenübertragung durch die Möglichkeit Daten eines AMP Kanals auch auf einem BR/EDR Kanal zu übertragen. Das ist dann von Interesse wenn die Übertragung auf einem AMP temporär unterbrochen wird. Der Wechsel auf einen BR/EDR Kanal, erneuter Aufbau eines AMP Kanals und Wechsel auf den AMP Kanal erfolgt automatisch. Dafür wird der ERTM (Enhanced Retransmission Mode) verwendet.

Der 802.11 PAL ist der Adaptation Layer zwischen dem IEEE 802.11 MAC Layer und dem HCI. Der aktuell bei 3.0 + HS spezifizierte 802.11 PAL unterstützt den IEEE 802.11-2007 (mit Anhang 1) Standard in der Ausprägung 802.11g (Enhanced Rate PHY, ERP). Die 802.11 Variante (OFDM PHY) kann optional unterstützt werden. Aktuell wird 802.11n nicht unterstützt. Die Übernahme dieser 802.11 Versionen ist – wenn vom IEEE die Spezifikation verabschiedet wurde – geplant. Der Verbindungsaufbau über den AMP unterscheidet sich nicht von dem bei 802.11. Beacons und der Response werden für die Signalisierung von AMP Operationen an andere Geräte und Netzwerke verwendet. Die Auswahl des PHY Kanals erfolgt vom Initiator der Verbindung unter Verwendung einer Kanalliste. Kanalauswahl ist wie bei 802.11 definiert. 802.11 Open Authentication, Association, AES-CCMP und die 4 Adressformate für die 802.11 Ad-hoc und Infrastrukturmodes werden unterstützt. Die von der IEEE vergebene Herstellerkennung (OUI) für den 802.11 PAL ist 00:19:58. Bluetooth 3.0 + HS Geräte müssen den Durchsatz in geringer und größerer Entfernung gewährleisten. Deswegen wird der Short Range Mode (Reduzierung der Sendeleistung auf +4 dBm) unterstützt. Dabei kann bei jedem Controller (BR/EDR bzw. AMP) eine getrennte Einstellung der Sendeleistung erfolgen. Die Power Control bei 3.0 + HS verwendet den Receive Signal Strenght Indication (RSSI) Parameter. Zusätzlich kann dieser Wert durch das Kommando HCI_Short_Range_Mode auf eine Obergrenze gesetzt werden. Es ist davon auszugehen, dass die Bluetooth 3.0 + HS Hardware sich bei der Möglichkeit die optimale (notwendige) Sendeleistung ein zustellen sehr stark unterscheiden.

Die geplante Nettodatenrate bei 3.0 + HS (802.11 PAL) beträgt >24 Mbit/s. Wenn ein SCO Link besteht, beträgt die Datenrate über den 802.11 PAL ca. 15 Mbit/s. Die garantierte und maximale (Total) Bandbreite wird vom Host – auch in Abhängigkeit vom HCI Durchsatz – bestimmt. Die Verwendung von Enhanced Distributed Channel Access (EDCA) für die Definition von Verkehrsklassen ist optional. Um einen hohen Datendurchsatz zu gewährleisten wurden die zwei für AMP in Frage kommenden HCI SDIO und USB überarbeitet. Es ist möglich Geräte mit BR/EDR und AMP) über ein Interface (Composite Interfaces) anzusteuern. Ein Gerät mit 802.11 PAL kann auch mit einem WLAN 802.11 Access Point kommunizieren.

Neu bei Bluetooth 3.0 ist auch die Unterstützung von HCI Read Encryption Key Size und Unicast Connectionless Data.

10

Mit HCI Read Encryption Key Size ist das Auslesen der Schlüssellänge für Encryption über ein HCI Kommando möglich. Die Schlüssellänge für Encryption wir beim ACL Verbindungsaufbau ausgehandelt. Es gibt aber bisher kein Bluetooth Event welches die ausgehandelte Schlüssellänge dem Host Controller – damit dieser seine Security Policy umsetzen kann – mitteilt. Das SIM Access Profile verlangt z. B. eine Schlüssellänge des Encryption Key von mindestens 64 Bits (häufig auch 128 Bits). Andere Profile/Anwendungen erfordern deutlich weniger. Mit dem neuen HCI Kommando brauchen kundenspezifische Lösungen nicht mehr verwendet zu werden.

Unicast Connectionless Data ist für die Unterstützung einer verzögerungsfreien Übertragung kleinen Datenmengen. Beispiele für solche Anwendungen sind Fernbedienungen, Tastaturen u. ä. Für Unicast Connectionless Data Transfers werden ein verbindungsloser L2CAP Kanal (CID 0x0002) verwendet. Bisher wurde dieser Kanal nur für Broadcasts vom Master zum Slave verwendet. Durch setzen eines Flags auf Unicast ist ein Point-to-Point betrieb möglich. Da ein Connectionless Kanal verwendet wird, empfiehlt sich nur die Übertragung kleiner Datenmengen. Denkbar ist auch der Beginn der Datenübertragung mittels Unicast Connectionless Data und anschließendem Wechsel auf verbindungsorientierte Kanäle. Bluetooth Versionen und Endprodukte Bluetooth besteht immer aus Controller (Hardware) und einem Host System. Dabei ist es möglich, dass diese beiden Teile mit unterschiedlichen Versionen kompatibel sind und trotzdem zusammen eingesetzt werden können. Das hat Auswirkungen auf die Bluetooth Version des Endproduktes. Tabelle 3 zeigt mögliche Kombinationen von BR/EDR Controller, AMP Controller, Host und das in den Handel gebrachte Endprodukt. Für den Anwender ist nur die Version des Endproduktes von Interesse.

BR/EDR Controller AMP Controller Host System Endprodukt 1.2 - 1.2 und höher 1.2 2.0 - 1.2 und höher 2.0 2.0 + DER - 1.2 und höher 2.0 + EDR 2.1 - 1.2 2.0 2.1 - 2.0 2.0 2.1 - 2.1 2.1 2.1 - 3.0 3.0 2.1 - 3.0 + HS 3.0 2.1 3.0 + HS 3.0 + HS 3.0 2.1 + EDR - 1.2 2.0 + EDR 2.1 + EDR - 2.0 2.0 + EDR 2.1 + EDR - 2.1 2.1 + EDR 2.1 + EDR - 3.0 3.0 2.1 + EDR - 3.0 + HS 3.0 2.1 + EDR 3.0 + HS 3.0 + HS 3.0 + HS 3.0 - 1.2 2.0 3.0 - 2.0 2.0 3.0 - 2.1 2.1 3.0 + EDR - 1.2 2.0 + EDR 3.0 + EDR - 2.0 2.0 + EDR 3.0 + EDR - 2.1 2.1 + EDR 3.0 - 3.0 3.0 3.0 - 3.0 + HS 3.0 3.0 3.0 + HS 3.0 + HS 3.0 3.0 + EDR 3.0 + HS 3.0 + HS 3.0 + HS

Tabelle 3 Bluetooth Versionen

11

5. Bluetooth Low Energy (LE) Bluetooth LE (früher Wibree oder Bluetooth Ultra Low Power) ist eine Wireless Übertragungstechnologie für Low Power Anwendungen u. a. in der Medizintechnik, Sport/Fitness, Uhren, Werbung, Fernbedienungen und Alarmanlagen. Bluetooth LE ist aktuell ein Voting Draft 0.9 und soll Ende 2009/Anfang 2010 verabschiedet werden. Im Unterschied zu Bluetooth 2.x/3.x – beide Versionen sind sehr auf die effektive Übertragung von Sprache abgestimmt – ist Bluetooth LE nur für die Datenübertragung ausgelegt. Ziel von Bluetooth LE (Low Energy) ist eine schnellere Verbindungsaufnahme (Connection Setup), einen stark reduzierten Spitzenstromverbrauch und eine wesentlich kürzere Standby Time (0,6 – 1,2ms vs. 22,5ms bei Bluetooth 2.x/3x) für die Abfrage eingehender Anfragen/Daten auf dem PHY (Radio Kanal). Bluetooth Low Energy kann standalone (z. B. in einem Sensor) oder als Dual-Mode Variante zusammen mit Bluetooth 3.x in z. B. in einem Mobiltelefon eingesetzt werden. Dabei hat der 3.x Bluetooth Chip mindestens drei Transceiver (Bluetooth Basic Rate, Enhanced Data Rate und Low Energy) auf einem IC integriert. Ziel von Bluetooth sind Anwendungen im Low-Power Bereich. Eine schnelle Verbindungsaufnahme und ein optimierter Stromverbrauch machen Bluetooth LE besonders für batteriebetriebene Geräte im Fitnessbereich (Uhren, Pulsmessgeräte) bzw. im Medizinbereich (portable Recorder, Messgeräte) geeignet.

Bild 5 Bluetooth Lowe Energy (LE) Architektur im Host und Standalone Mode Bluetooth LE arbeitet im 2,4 GHz Band und belegt 40 Kanäle. Davon sind 37 Kanäle für die Datenübertragung und 3 Kanäle für die Signalisierung (Connectable and Discoverable) mit 2 MHz Kanalabstand. Für die Übertragung wird Frequency Hopping mit GFSK (Gaussian Frequency Shift Keying), TDMA (Time Division Multiple Access) und FDMA (Frequency Division Multiple Access) verwendet. LE liegt im Frequenzbereich der WLAN Kanäle 1, 6 und 11. Die Sendeleistung beträgt mindestens -10 dBm (0,01 mW) bis maximal 10 dBm (10 mW). Die Empfängerempfindlichkeit beträgt -83 dBm. Die angestrebte Reichweite beträgt ca. 10 Meter. Bluetooth LE arbeitet im Master/Slave Betrieb ohne Master/Slave Switch und unterstützt Point-to-Point. Point-to-MultiPoint (ein Master kann mehrere Verbindungen zu mehreren Slaves haben) ist optional möglich. Scatternets werden nicht unterstützt. Die maximale Brutto Datenübertragungsrate beträgt 1 Mbit/s.

Da die Datenübertragung bei typischen LE Anwendungen im Sekundenabstandabstand, die zu übertragenen Daten häufig nur ein paar Bytes umfassen wird der Stromverbrauch eines LE Standalone Gerätes zum größten Teil von Stromverbrauch im Idle bzw. Sleep Mode bestimmt. Praktisch alle LE Standalone werden mit einer Batterie ausgestattet.

12

Um die heute schon bei Uhren vorhandene Batterielebensdauer von einem Jahr und mehr zu erreichen, sind andere Verfahren bei der Gerätesuche und der Verbindungsaufnahme erforderlich. Die erforderliche Zeit für den Aufbau einer Verbindung bis zum Sende von Daten beträgt bei LE 3 ms und ist damit um Größenordnungen geringer als bei Bluetooth 2.x/3.x (mindestens 150 ms). Auch dieses Verhalten trägt zu einer deutlich längeren Batterielebensdauer bei. Bei einem typischen LE Standalone Gerät ist der Transceiver 99,9% der Zeit im AUS Zustand.

Bild 6 Die einzelnen States eines Bluetooth LE Systems

Ein Gerät im Advertising State zeigt auf den Kanälen 37, 38 und 39 seine Bereitschaft zur Verbindungsaufnahme an. Dafür werden im Abstand von 0,02 bis 10,24 s Advertising Pakete (pro Kanal für max. 1,5 ms) gesendet. Ein Gerät im Scanner Mode (Initiator) sucht aktiv andere Geräte. Wenn das Gerät im Scanner Mode der Initiator der Gerätesuche ist, so wird dieses Gerät der LE Master, das oder die Geräte, die im Advertising Mode sind arbeiten dann als Slaves.

Bild 7 Ablauf der Verbindungsaufnahme bis zur Datenübertragung

Die Adressierung der LE Geräte erfolgt über eine 48 Bit (24 Bit vom IC Hersteller, 24 Bit vom Hersteller des Produktes) MAC Adresse. Alternativ kann mit einer 48 Bit Zufallsadresse oder einer Access Adresse für den Link (und damit für das Gerät) gearbeitet werden. Ein zusätzliches Bit dient der Unterscheidung der verwendeten Adresse (vergeben bzw. registriert oder Zufall).

13

Der Master sendet zu vorgegeben Zeiten (Connection Events) und Slaves hören bzw. synchronisieren sich mit dem Master. Jedes Connection Event arbeitet auf einem anderen Frequenzsprung (Hop). Der Hop wird dabei in einem Abstand von 5-16 Hops vom vorhergehenden Hop gewechselt. Eine dynamische Kanalverwaltung erlaubt und unterstützt Koexistenz mit anderen Wireless Systemen im gleichen Frequenzbereich. Der Abstand zwischen der Datenübertragung von Master und Slave beträgt 150 µs. Sniff Modes und Latency können eingestellt werden. Beide Werte sind aber auch vom jeweiligen Chip abhängig. Die Datenübertragung arbeitet mit Acknowledge (Sequence Number/Next Expected Sequence Number). Alle PHY-Layer Pakete haben eine im Prinzip identische Struktur. Bild 8 zeigt den Paketaufbau.

Der Message Integrity Check (MIC) stellt die Integrität (Authentizität) der gesendeten Daten sicher. Bevor die Daten zum Host geschickt werden, kann der MIC verifiziert werden. Der MIC basiert auf einem CCM (Counter with Cipher Block Chaining-Message Authentication Code) Algorithmus der in RFC 3610 definiert ist. Die CRC wird über den Header, die Länge, die Daten und den MIC gebildet.

Security (Encryption und Authentication) bei Bluetooth LE ist sehr ähnlich zu der bei Bluetooth BR/EDR und erfolgt im Link Layer unter Verwendung von AES-128 (Advanced Encryption Standard mit 128 Bit Schlüssellänge) und eines Link Key. Die Security Einstellungen und Informationen werden vom Master verwaltet. Bei Verlust von Keys kann der Slave diese vom Master erfragen. Das Security Protocol (Security Manager Protocol, SMP) wird im Host abgearbeitet. Die Pairing Mechanismen sind praktisch identisch zu denen bei Secure Simple Pairing. Die Anforderungen und Merkmale werden zwischen den beteiligten Geräten ausgetauscht und der gewählte Algorithmus (Key) verwendet. Beispiele sind Encryption, Eingabe des Passkey (PIN) oder Out of Band. Alle Pairing Varianten erzeugen zwei Keys (Temporary Key, TK und Short Term Key, STK). Je nach verwendeter MAC Adresse (vergeben/registriert oder Zufall) werden unterschiedliche Keys und Zufallszahlen abgeleitet. Aus dem TK, dem STK und diversen Initialisierungsvektoren werden der Long Term Key (LTK) für die Encryption der Daten abgeleitet.

Für die Kommunikation zwischen LE Host und dem LE Controller wird auch das bereits von Bluetooth her bekannte HCI Interface (UART, USB, SDIO) verwendet. Dabei wurden neue HCI Kommandos und Events für LE eingeführt.

Für die Datenübertragung werden drei (für Signalisierung, Security und Anwendung) verbindungslose L2CAP Kanäle (feste CID) ohne Protocol Service Multiplexer verwendet.

Die Generic Access Profile (GAP) Konfiguration ist im Wesentlichen identisch zu der bei Bluetooth BR/EDR. Der Name gefundener Geräte wird zwischen BR/DER und LE Bluetooth geteilt, d. h. jede Bluetooth Variante verwendet für das identische Gerät einen gleichen Namen Das Geräteverhalten (Discoverable, Connectable, Bondable) und die Rolle bei der Verbindungsaufnahme werden im GAP eingestellt.

Oberhalb L2CAP sind das Attribute Protokoll und das Remote Display Protokoll mit den LE Profilen für die Übertragung und Abbildung der Anwendungsdaten und Kontrollinformationen zuständig. Als Attribute werden bei LE Daten bezeichnet, die mit einem Wert, einem UUID und einem Handle beschrieben. Ein Attribute kann ein Hardwareregister sein, Anwendungsdaten, Konfigurationsdaten oder aber Kommando- bzw. Control Informationen.

Ein Attribut beinhaltet Typ (u. a. Temperatur, Puls, absolute/relative Zeit, Gewicht), den Wert (z. B. 37 Grad), Permissions (Lesen, Schreiben) und Kommandos (Read, Write, Read Modify Write, Show Value). Metaattribute können definiert werden.

Das Attribut Protokoll hat einen Attribute Server (beinhaltete alle Attribute mit deren Wert, empfängt Requests und sendet den Response) und Attribute Client (kommuniziert mit dem Server, sendet Requests, wartet auf den Response und kann Quittierung senden).

14

Der Attributzugriff erfordert ggf. eine Autorisation. Das Lesen von unterstützten Attributen ist i. A. immer erlaubt. Das Attributprotokoll verwendet einen Connectionless Channel mit Informationen über Device (Name), Version, Services (z. B. Pulsmessung) und Servicewerte (Pulswert). Das Attribute Protokoll beinhaltete Operationen für Push, Pull, Set, Broadcast und GET. Bei Pull sendet der Server die Daten wenn diese geändert wurden. Der Client hat die Möglichkeit einen Trigger im Server zu setzen. Der Client kann dabei eine zuverlässige Kommunikation mit Acknowledgement verlangen und verbessert dadurch auch die Flusskontrolle im System. Bei Pull fordert der Client die Daten vom Server bei Bedarf an. Mittels Set kann der Client einen Attribute Wert (z. B. 20° C) auf dem Server setzen. Der Server sendet mittels Broadcast Daten an verschiedene Clients gleichzeitig. Mit GET kann der Client oder Server Attribute und deren Handle auf der Gegenstelle abfragen.

Das Remote Display Protokoll unterstützt Funktionen für die Verwaltung der Anzeige und Displaysteuerung. Damit ist auch ein stromsparender Displaymode möglich. Damit ist die Anzeige von Werten möglich, wenn der Messwert aktualisiert oder gesendet wurde.

Attribute Profile definieren den Funktionsumfang (Sammlung von Attributen und der Werte dieser Attribute) einer Anwendung bei LE. Aktuell sind bei Bluetooth LE inkl. GAP vier Profile definiert. Diese sind das Sensor Profile (mit Public Sensor und Private Sensor), Watch Profile (mit Remote Display und Remote Control für das Call Management, email) und das HID Profile (Attribute Protokoll ersetzt hier das SDP). Die Entwicklung und der Einsatz von kundenspezifischen Profilen für spezielle Aufgaben sind möglich.

Unterstützte Datentypen sind u. a. signed, unsigned, IEEE (inkl. IEEE 11073) und Binary. Als Teil von Metaattributen können Trigger (Alarmgrenzen) und die Häufigkeit (Frequenz) der zu übertragenden Daten definiert werden. Bluetooth LE in der Medizintechnik

Für medizinische Anwendungen ist besonders das Sensor Profil geeignet. Es kann leicht an für besondere Aufgabenstellungen und Datenformate angepasst werden. Systeme mit LE können permanent auch als auch ereignisgesteuert arbeiten. Besonders Anwendungen mit geringen (kein Streaming!) Datenaufkommen, Systeme die mit Batterie über mehre Monate oder Jahre arbeiten müssen und kleine mobile Geräte können von Bluetooth LE profitieren. Im Unterschied zu Bluetooth HDP ist bei LE keine Unterstützung des IEEE 11073 Datenformats erforderlich. Geplante Verfügbarkeit von Bluetooth LE Controllern (Standalone und Dual-Mode) ist Anfang 2010. Durch die Verwendung eines definierten Stacks und Profils ist auch die Interoperabilität mit Gegenstellen (PC, Mobiltelefonen) gewährleistet.

6. Phone Book Access Profile (PBAP) Das Phone Book Access Profile (PBAP) wurde von der Car Working Group (CWG) innerhalb der Bluetooth SIG spezifiziert. Die aktuelle Version ist 1.0 vom April 2006. An der Weiterentwicklung (V1.1) wird gearbeitet. Das PBAP erlaubt den Transfer des Telefonbuchinhaltes eines Mobiltelefons in die Bluetooth Freisprecheinrichtung des Fahrzeuges. Die Telefonbuchdaten (Name, Rufnummer, Adresse …) können damit im Fahrzeug auf einem Display angezeigt und für komfortable Funktionen wie z. B. Sprachwahl und –bedienung verwendet werden. Das PBAP erlaubt erstmals eine standardisierte Übertragung der Telefonbuchdaten eines Mobiltelefons. Die bisher am häufigsten verwendete Methode über AT-Kommandos ist bei vielen Mobiltelefonen nicht mehr implementiert bzw. bietet – da die Kommandos und die Datenformate nicht einheitlich implementiert sind – nur eine eingeschränkte Interoperabilität die zu dem stark von jeweiligen Hersteller abhängig ist. Andere Methoden wie IrMC (Infrared Mobil Communication) wurden durch eine vollständige Synchronisation mit SyncML abgelöst bzw. sind – wie OBEX Object Push – für die Übertragung hunderter Einträge nicht geeignet.

Das PBAP definiert Client (z. B. Freisprecheinrichtung) und Server (Mobiltelefon). Der Client kann aus dem Server das vollständige Telefonbuch (inkl. SIM Karte, Liste der angenommenen bzw. entgangenen Anrufe) übertragen bzw. einzelnen Rufnummern auswählen und für den Rufaufbau verwenden. Die einzelnen Einträge werden dabei immer als vCARD übertragen.

15

Das PBAP erlaubt dabei keine Änderung der Einträge und anschließendes zurückschreiben auf dem Server. Es wird also nur Read-Only und kein Read/Write unterstützt.

Bild 9 Bei PBAP Gerätefunktionen und Protokolle

PBAP Client (Car Kit, PND) PBAP Server (Mobiltelefon) PBAP verwendet das Generic OBEX Exchange Profil und das OBEX Protokoll. Die Security Modes 2 und 3 (bzw. 4 bei Bluetooth 2.1), Bonding und de Verschlüsselung der zu übertragenden Daten mit mindestens 64 Bit (128 Bit sind aber die Regel) sind vorgeschrieben.

Die von PBAP unterstützten Telefonbücher sind das zentrale Telefonbuch im Hauptspeicher (telecom/pb) und das auf der SIM Karte (SIM/telecom/pb). Beide beinhalten Angaben über entgangene (Missed Calls History, MCH) und ein- bzw. ausgehende Anrufe (Incoming/Outgoing Calls History). Die Definition der Telefonbücher bzw. der File- und Verzeichnisstruktur und der Datums- bzw. Zeitangabe bei den jeweiligen Anrufen folgt der IrMC Spezifikation und wird in dieser Form bei den meisten Mobiltelefonen seit Jahren eingesetzt. Die Übertragung der Daten des jeweiligen Telefonbuchs erfolgt vom Server als vCard im v2.1 oder v3.0 Format. Die Datendarstellung erfolgt im UTF-8 Format. Der Client gibt dabei das verlangte Format (v2.1 oder v3.0) vor. PBAP schreibt die mindestens zu verwendeten Attribute für den jeweiligen vCard Standard vor. Diese sind Name und Telefonnummer bei v2.1 und Name, Vorname und Telefonnummer bei v3.0. Hier gibt es zwischen den einzelnen Herstellern große Unterschiede. Die Minimalanforderung wird von vielen Herstellern übererfüllt. PBAP definiert verbindlich die Übertragung mehrerer Einträge unter einem Attribut. Damit ist die Übertragung mehrerer – unter einem Namen gespeicherten - Telefonnummern (Büro, Privat, Mobil) möglich. Das war mit AT-Kommandos nicht immer einfach umzusetzen und führte zu doppelten Einträgen.

Auf die Telefonbucheinträge im Server kann mittels Download (Auswahl eines oder aller Telefonbücher) oder Browsing zugegriffen werden. Der Server muss beide Funktionen unterstützen. Der Client Download oder Browsing. Bei der Übertragung erfolgt keine Sortierung (z. B. nach dem Namen) der Telefonbuchdaten. Diese Aufgabe muss im Client durchgeführt werden. Bei Browsing wird das zu übertragende Telefonbuch oder eine bestimmter Eintrag ausgewählt.

Die meisten PBAP Implementierungen sind heute (August 2009) sehr stabil. Unterschiede gibt es beim Komfort für Download und Browsing (Auswahl der Telefonbücher bzw. Einträge) und den zu übertragenen Daten. Je nach Gerät werden nicht alle Telefonbücher unterstützt. Das Browsing, Setzen der Pfade und PullCardListung bzw. PullCardEntry setzen eine vollständige OBEX (IrDA Standard!) Implementierung voraus und werden daher in vielen Endprodukten nicht unterstützt. Dadurch erklären sich die teilweise großen Unterschiede in der Funktionalität der einzelnen Endprodukte.

16

7. Message Access Profile (MAP Das Message Access Profile (MAP) wurde von der Car Working Group (CWG) innerhalb der Bluetooth SIG spezifiziert. Die aktuelle Version ist 1.0 vom Juni 2009. Das MAP erlaubt den Empfang und das Versenden von Messages (SMS, MMS, email) im Fahrzeug. Der Anwender hat dabei die Möglichkeit im Nachrichtenverzeichnis des Mobiltelefons zu browsen bzw. einzelne Messages zu übertragen und auf dem im Fahrzeug integrierten Display bzw. einem PND anzuzeigen. Das Schreiben neuer Messages bzw. das Löschen einzelner Messages wird unterstützt. Dabei ist auch die Signalisierung bei Eingang einer neuen Message möglich. Dabei kommt je nach Umfang der MAP Anwendung auch eine Text-to-Speech Umsetzung zum Einsatz.

Bild 10 Bei PBAP Gerätefunktionen und Protokolle

Messaging Client (Car Kit) Messaging Server (Mobiltelefon) Der MAP Client ist typischerweise die Bluetooth Freisprecheinrichtung im Fahrzeug bzw. ein PND oder auch der PC. MSAP Server ist das Mobiltelefon. MAP basiert auf dem OBEX Protokoll.

Die Security Modes 2 und 3 (bzw. 4 bei Bluetooth 2.1), Bonding und de Verschlüsselung der zu übertragenden Daten mit mindestens 64 Bit (128 Bit sind aber die Regel) sind vorgeschrieben.

Die unterstützten Message Typen sind email (RFC2822, MIME), SMS (GSM und CDMA Netze) und MMS (3GPP Netze). Die Größe der Nachrichten ist wie bei den jeweiligen Standards beschrieben. Bei email werden Attachements unterstützt. Die Größe der Attachements wird in einem Parametersatz beschrieben. Ob Attachements zum Client übertragen und angezeigt werden hängt von der jeweiligen Client Implementierung ab. Absender und Empfänger werden im vCard 2.1 oder 3.0 Format beschrieben. Die unterstützten Attribute sind die Minimalanforderungen bei PBAP plus die die email Adresse. Die Message im bMessage Format. Das Folderverzeichnis ist telecom/msg mit Unterverzeichnissen für Inbox, Outbox, gesendet und gelöschte Nachrichten.

Dem Message Parser und Message Builder kommt eine besondere Bedeutung zu. Beide sind nicht Teil der Bluetooth Spezifikation, bestimmen aber zum großen Teil die Funktionalität der Anwendungsebenen. Unterstützung internationaler Zeichensätze und die flexible Handhabung von nicht interpretierbaren Zeichen bestimmen wesentlich die Akzeptanz durch den Anwender. Leider fallen Ausnahmen Berücksichtigung

Heute (August 2009) sind keine Endprodukte mit MAP auf dem Markt. Es ist daher zu früh etwas über integrierte Funktionalität zu sagen. Bei Mobiltelefonherstellern durchgeführte MAP Server Implementierungen erlauben jedoch Rückschlüsse auf eine große Bandbreite der umgesetzten MAP Funktionalität im jeweiligen Mobiltelefon.

17

8. Advanced Audio Distribution Profile (A2DP) Die aktuelle Version des Advanced Audio Distribution Profile (A2DP) ist 1.2 vom April 2007. A2DP ist Teil einer Profil und Protokollsuite mit dem Audio Visual Distribution Transport Protocol (AVDTP) und dem Audio Visual Control Transport Protocol (AVCTP) für die Audio- und Videoübertragung im Streaming Mode. A2DP ist ausschließlich für die Übertragung von Musik zuständig. Sprache kann mit A2DP nicht übertragen werden. A2DP unterscheidet die zwei Gerätevarianten A2DP Source (Mobiltelefon, MP3 Player) und A2DP Sink (Kopfhörer, Stereoempfänger, Car Kit). In der aktuellen Version unterstützt A2DP nur eine Punkt-zu-Punkt Übertragung. Ein Sender kann die Musik immer nur auf einen Empfänger übertragen. Mit einer A2DP Instanz ist es nicht möglich von einem Mobiltelefon Musik auf zwei Kopfhörer zu übertragen. Dazu muss das A2DP Profil auf dem Host zweimal gestartet werden.

Bild 11 A2DP Gerätefunktionen und Protokolle

A2DP Source (Player) A2DP Sink (Kopfhörer, Car Kit) Die Musikübertragung bei A2DP erfolgt komprimiert, d. h. das analoge Musiksignal wird digitalisiert und schließend enkodiert. A2DP schreibt Sub Band Coding (SBC) als Mandatory Codec vor. Jedes Gerät muss den SBC unterstützen. Andere Codecs wie MP3, AAC und ATRAC sind optional. Grund für den Einsatz von SBC ist die etwas größere Unempfindlichkeit gegen Fehler auf der Funkübertragungsstrecke und der Umstand, dass der SBC CODEC lizenzfrei ist. Es müssen daher für die jeweiligen Geräte keine Gebühren (bei MP3) abgeführt werden.

Da Parameter wie Abtastrate, Stereo/Mono, Codec und auch einige Codec Parameter ausgehandelt werden, erfolgt eine Einigung auf einen gemeinsamen Parametersatz. Da praktisch alle A2DP Sink Devices keinen MP3 Codec für die Übertragung über Bluetooth unterstützen, wird die zu übertragende Musik von MP3 in SBC (Sub Band Coding) konvertiert. Dieses Transcoding erfordert einen erheblichen Aufwand im Mobiltelefon bzw. MP3 Player.

A2DP unterscheidet verschiedene Qualitätsstufen. Die Übertragung von Mono, Mono Dual Channel und Stereo ist zulässig. Die Sampling Frequenz (Abtastfrequenz) bestimmt wesentlich die Qualität der wiedergegebenen Musik und kann 16, 32, 44,1 oder 48 KHz betragen. Bei einem CD Player beträgt die Abtastrate 44100 Hz (44,1 KHz). Die genannten Punkte haben einen direkten Einfluss auf die Musikwiedergabe. Viele A2DP Geräte orientieren sich auch heute (August 2009) an den untersten Parametern des A2DP Standards. Das bedingt dann eine nicht optimale Musikqualität, macht aber die Entwicklung einfacher und erlaubt die Verwendung preiswerterer Hardware.

A2DP stellt – was den Durchsatz betrifft – aktuell die höchsten Anforderungen an ein Bluetooth System. Bei Verwendung der bestmöglichen SBC Codec Parameter und einer Bluetooth Hostimplementierung bedingt das eine kontinuierliches HCI Datenaufkommen von bis zu ~550 Kbit/s über die UART Schnittstelle. Überraschenderweise haben viele UART Lösungen mit dieser Datenrate ein Problem. Häufig ist sind die Buffer zu klein, DMA funktioniert nicht einwandfrei oder RTS/CTS wird nur unzureichend unterstützt.

18

Deswegen werden häufig andere H5 HCI (SLIP ähnlich) und BCSP (herstellerspezifisch) unterstützt. In vielen Fällen bedingt eine sehr einfacher UART auch eine hohe Interruptlast für die CPU. Diese Punkte führen dazu, dass das A2DP Systemdesign qualitativ sehr unterschiedlich ausfällt. Die Ursachen lagen in der Vergangenheit häufig in der geringen Performance des Bluetooth Controllers und in der Entwicklung der Geräte selbst. Heute ist es fast immer die Entwicklung selbst. In vielen Fällen ist ein qualitativ schlechtes HF Design dafür verantwortlich. Dieses bedingt u. a. durch Nichtlinearitäten im Sender/Empfänger häufig Paketfehler die zu Paketwiederholungen führen. Häufig ist dann aber der Buffer für die Speicherung der Daten zu klein. Das führt dann zu Verlusten ganzer Pakete, was wiederum zu einer schlechten Qualität bei der Musikwiedergabe führt. Deswegen muss bei A2DP das Systemdesign (inkl. der Buffer) für ein zuverlässiges Streaming ausgelegt werden.

Da Bluetooth eine sehr geringe Sendeleistung hat (deutlich weniger als z. B. WLAN am PC), ist das Signal nicht sehr „stark“. Es empfiehlt sich daher immer eine Sichtverbindung und eine (abhängig von den beteiligten Geräten) Entfernung von maximal 10-20 Meter zwischen den beteiligten A2DP Geräten einzuhalten.

9. Audio Video Remote Control Profile (AVRCP) Die aktuelle Version des Audio/Video Remote Control Profile (AVRCP) ist 1.4 vom Juni 2008. Das AVRCP ist zusammen mit dem A2DP Bestandteil einer Profil und Protokollsuite mit dem AVDTP und dem AVCTP für die Übertragung von Audio und Video Daten im Streaming Mode.

A2DP kann nur einen Stream starten. Auswahl eines Titels, Pause, erneutes Starten ist mit A2DP nicht möglich. Dafür wird das AVRCP verwendet. AVRCP ermöglicht die Steuerung einer A2DP Source (z. B. Laut/Leise) bzw. einer A2DP Source (Start, Stopp, Pause, Titelauswahl, Verwaltung der Play Liste usw.) ähnlich dem einer Fernbedienung für ein TV oder HiFi Gerät. Diese Funktionen sind reine Komfortfunktionen und haben keinen Einfluss auf die Musikübertragung. Beide Geräte (A2DP Sink und A2DP Source) müssen AVRCP unterstützen, damit die jeweiligen Funktion verwendet werden kann. AVRCP baut einen eine Control Channel für die Übertragung von Kommandos auf. Dafür wurde der L2CAP Layer erweitert

Bild 12 AVRCP Gerätefunktionen und Protokolle

AVRCP Controller AVRCP Target Der AVRCP Controller baut einen Control Channel zu einem AVRCP Target für die Übertragung von Kommandos auf. Das Target führt die Kommandos aus, sendet einen Response bzw. die verlangten Informationen (Metadaten wie Name des gespielten Musiktitels bzw. des Künstlers und andere Trackinformationen) oder aber eigene Kommandos.

19

Der Controller ist typischerweise ein Mobiltelefon, PC, Headset (Bild 13) oder Car Kit. Target ist ein A/V Geräte wie z. B. Headset oder ein Stereoempfänger. Damit ist ein Browsen in den Musikstücken des Players möglich. AVRCP unterstützt auch Fernbedienungen die nur den Player steuern. Bild 13 Zeigt ein AVRCP Target und Controller mit den Signalpfaden und deren Richtung

Die Verwendung von Funktionen einer Fernbedienung macht – aus Anwendersicht – AVRCP mit einer handelsüblichen Fernbedienung für TV Geräte vergleichbar. Um einen entsprechenden Komfort zu bieten, muss das Target schnell auf Kommandos von Controller reagieren können. Eine Empfehlung ist daher, dass das Target (wenn es der Bluetooth Master) ist, den Slave mit 10 Hz pollt. Zusätzlich definiert AVRCP auch Timer (100 ms, 200 ms und 1000 ms) innerhalb deren Zeit ein AVRCP Target eine Antwort schicken muss.

AVRCP klassifiziert die A/V Gerätefunktionen in die 4 Kategorien Player/Recorder, Monitor/Verstärker, Tuner, Menü und definiert die Verwendung des Audio Video/Command Digital Interface Command Set wie von der 1394 Trade Association definiert. Diese Spezifikation definiert die Gerätefunktionen über Unit- und Subunitbeschreibungen die den Funktionsumfang z. B. eines Players vollständig beschreiben. Bei einem AVRCP Gerät werden alle Bluetooth und AVRCP Features (z. B. Verbindungsaufnahme für Control Operationen, Steuerung der Lautstärke, Übertragung der Playliste, Browserfunktionen) und die eigentlichen AV/C Kommandos (z. B. Abfrage des Playerstatus, Trackauswahl, Steuerung mit Start, Stopp, Pause, Resume, Vorwärts, Rückwärts, Menüauswahl) über Attribute beschrieben. Bei den Kommandos wird daher zwischen AV/C und Browsing Kommandos unterschieden. Ein A/V System kann daher ziemlich komplex sein. Bild 14 zeigt die einzelnen Verbindungen.

Bild 14 Mediadaten und Control Channel bei A/V Geräten mit A2DP und AVRCP

20

Ein wichtiges Feature von AVRCP v1.4 ist die umfangreiche Unterstützung von Metadaten. AVRCP unterstützt u. a. die Übertragung der Audio Track ID3-Tag Information des aktuell abgespielten Songs, aller im Player vorhanden Audio Tracks (Songs, Playlist), von Playerinformationen (Gerätenamen, Typ, Klasse und Gerätefunktionen), Konfiguration des Players, Suche nach einem bestimmten Audio Track unter Verwendung der ID3 Tag Informationen oder des Filenamens, direktes Auswahl eines Audio Track mit einem Identifier oder eines besonderen Label sowie die Event Notification (Informationen über Wechsel des Tracks, abgelaufene Zeit des Songs oder Fehler) vom Target.

ID-3 Tags beinhalten u. a. Informationen den CD Identifier, CD Title, Name des Tracks/Songs, Namen des Künstlers/Sängers/Komponisten, Datum der Aufnahme, Länge des Tracks, ein Bild des CD Covers. Der Umfang von AVRCP v1.4 führt zu einer großen Vielfalt der einzelnen Implementierungen mit durchaus stark unterschiedlichen Komfort. Eine vollständige AVRCP Lösung ist sehr aufwendig und hat einen erheblichen Speicherbedarf. Der Umfang der Trackinformationen ist mit dem von Gracenote vergleichbar.

Aktuell gibt es kein End Produkt (Mobiltelefon, Player) mit AVRCP v1.4 Unterstützung. Aktuelle AVRCP v1.3 Implementierung haben einen sehr eingeschränkten Funktionsumfangs. Browsing und Suche wird meistens nicht unterstützt.

10. Gleichzeitige Nutzung von A2DP, AVRCP mit HFP Der gleichzeitige Betrieb von A2DP, AVRCP zusammen mit dem Hands-free Profile (HFP) gehört zu den anspruchsvolleren Anwendungen von Bluetooth. Wenn eine solche Anwendung ein Multi-Profile/Multi-Link Szenario mit 2 oder auch 3 Geräten (Car Kit, Player, Mobiltelefon) bildet, sind die möglichen Varianten des Verbindungsaufbaus, der Datenübertragung und des Call Handling (für Telefone) vielfältig, komplex und erfordern eine sorgfältige Abstimmung der einzelnen Schritte um eine reibungslose Interoperabilität zwischen den beteiligten Geräten zu ermöglichen. Die Bluetooth SIG hat für solche Fälle eine White Paper [15] geschrieben, welches unbedingt bei der Entwicklung berücksichtigt werden sollte. Da dieses von der Bluetooth SIG erstellte White Paper aber nicht (!) Mandatory ist, halten sich viele Gerätehersteller nicht daran. Das führt letztendlich zu Problemen bei der Interoperabilität.

11. Bluetooth Health Device Profile (HDP) Die aktuelle Version des Health Device Profil (HDP) ist 1.0 vom Juni 2008. Bisher wurde für Bluetooth Anwendungen in der Medizintechnik sehr häufig das Serial Port Profile (SPP) eingesetzt. Das führte in praktisch allen Fällen dazu, dass das Gerät von Hersteller A nicht mit dem von Hersteller B zusammenarbeiten konnte. Interoperabilität ist mit solchen Lösungen nicht gegeben. Wenn ein PC Teil der Anwendung ist, gibt es sehr häufig Konflikte mit vorhanden Bluetooth Stacks bzw. anderen Applikationen. Die Verwendung von SPP auf dem PC war in vielen Fällen nur mit dem Bluetooth Stack eines Hersteller gegeben. Spezifische Lösungen unter Verwendung virtueller COM Ports unterliegen praktisch immer Abhängigkeiten der verwendeten Hardware und Software (Betriebssystem, Treiber).

Die Medical Working Group (Med WG) der Bluetooth SIG hat daher schon 2006 mit der Entwicklung eines Profiles (Definition des Verhaltens und der Merkmale eines Gerätes für eine bestimmte Anwendung) begonnen. Ergebnis war die Erstellung der Spezifikation des HDP (Health Device Profile), des MCAP (Multi-Channel Adaptation Protocol) und des Device ID Profile (DI). HDP/MCAP arbeiten Connection-oriented um Verbindungsabbrüche schnell zu erkennen und erlauben ein Reconnect von L2CAP Channels. Dabei werden ein Control Channel und ein oder zwei Data Channels (Streaming Data Channel, Reliable Data Channel) zwischen zwei Devices aufgebaut. Im L2CAP auch die Field Check Sequence (FCS) unterstützt werden.

Unterstützt werden Streaming- (EKG, EEG) und Non-Streaming- (Waagen, Blutdruckmessgeräte, Blutzuckermessgeräte, Spirometer, Sensoren) Anwendungen. EEG/ECG Systeme erfordern – wegen dem Datenaufkommen – eine qualitativ sehr gute und „saubere“ Bluetooth Implementierung. Bild 15 zeigt einige Anwendungsbereiche.

21

Bild 15 HDP Anwendungen und Channels HDP und MCAP beinhalten auch die Unterstützung der Übertragung unterschiedlicher Daten über einen ACL.

Um eine genaue Beurteilung der entsprechenden physiologischen Daten zu ermöglichen, ist sehr häufig die zeitliche Synchronisation der Signale untereinander notwendig. Dafür wird der Bluetooth Clock des Masters und der Offset des Slaves verwendet. HDP Geräte arbeiten als Sync-Master oder Sync-Slave. Der Time Stamp erfolgt mit einer Auflösung von 1 µs. Verzögerungen – hervorgerufen durch die Verarbeitung im jeweiligen Gerät – werden im Feld SyncLeadTime angegeben. Die Zeitdarstellung erfolgt nach IEEE 1003.1-2001 (absolute Zeit, Sekunden).

Der Inhalt der Daten und deren Kontext ist nicht von der Bluetooth SIG definiert. Hier hat die Bluetooth SIG sich für das IEEE 11073-20601 Personal Health Device Communication Application Profile (einziges bei HDP zugelassenes Protokoll für den Datenaustausch) und die Device Spezifikation von IEEE 11073-104xx entschieden. Bild 16 zeigt die Architektur eines HDP Systems.

Bild 16 HDP Gerätefunktionen und Protokolle

Jedes Gerät mit HDP kann einen oder mehrere MCAP Data End Points (MDEP) aufweisen. Ein MDEP beschreibt die Anwendungen in einem Gerät mit dem HDP.

Das HIDP empfiehlt die Verwendung der Sniff Modes und die erweiterten Security Funktionen (SSP) von 2.1. Encryption ist Mandatory. Die Länge der PIN bei Bluetooth 2.0 ist 6 Zeichen.

22

Für die Übertragung von Audio Daten (z. B. eines Stethoskop) sollen die Voice Profile verwendet werden. Die Verwendung von EDR, AFH (Adaptive Frequency Hopping) und Transmit Power Control wird zur Vermeidung von Koexistenz Problemen mit anderen Systemen empfohlen.

Von Bedeutung sind die IEEE11073 Spezifikationen. Diese definiert mit IEEE 11073-20601 das Datenformat und mit IEEE 11073-104xx das Datenaustauschformat und die Größe der zu sendenden und empfangenen Daten. Bild 17 zeigt die Architektur eines Systems mit Bluetooth und IEEE-11073-20601 und den Device Spezifikationen IEEE-11073 (-104xx).

Bild 17 Bluetooth und die IEEE-11073 Software mit den Gerätedefinitionen (-104xx) Die Länge der übertragenen Daten beträgt meistens 896 Bytes für das Senden und 224 Bytes für den Empfang. Ausnahme ist das Oximeter. Hier betragen die jeweiligen Werte 9216 bzw. 256 Bytes. Segmentation und Reassembly (SAR) werden unterstützt. Diese Parameter werden für die Konfiguration der MTU Size herangezogen. Tabelle 4 führt die IEEE 11073-104xx Standards für die einzelnen Geräte auf. Weitere Informationen zu 11073 siehe [16], [17] und [18].

IEEE 11073- Gerät 10404 Pulse Oxymeter 10406 Pulse/Herzfrequenz 10407 Blutdruck 10408 Thermometer 10415 Waage 10417 Blutzucker 10441 Kardiovaskulärer Fitness Monitor 10442 Fitnessgeräte (Beanspruchbarkeit) 10471 Überwachung 10472 Verabreichung von Medikamenten 20601 Protokoll für den Datenaustausch

11073-20601 beinhaltet Funktionen für die Kommunikation (zuverlässige Kommunikation), Services (Event Reporting, Object Access mit GET/SET) und die Domain Informationen (Objekt-orientiertes Modell, Attribute, Klassen für die Gerätekonfiguration). Auf der Ebene von 11073-20601 bauen Geräte eine logische Verbindung auf. Die Beschreibung der Gerätefunktionen und Attribute erfolgt mit ASN.1. Ein Oxymeter hat z. B. Objekte für den Puls, Sauerstoffsättigung und Kurvenverlauf. Diese Daten werden in einem Data Update Event verschickt. Die Kommunikation erfolgt zwischen einem HDP Source Node bzw. 11073-20601 Agent (medizinisches Gerät) und einem HDP Sink Node bzw. 11072-20601 Manager (PC, Mobiltelefon, STB…). Agent oder Manager können die Datenübertragung starten. Der Manger kann nach einem Datenwert fragen, Daten für eine bestimmte Zeit in Sekunden anfordern oder aber die Daten über Start/Stop vom Agent abfragen. Agents verarbeiten keine Daten. Ein Bluetooth Verbindungsabbruch wird nicht sofort dem 11073-20601 Layer mitgeteilt.

Mit Stand vom August gibt es keine bei der Bluetooth SIG gelisteten medizinischen Produkte die das HDP verwenden.

23

12. Synchronisation von PIM Daten über Bluetooth Für die echte Synchronisation (Abgleich von Datensätzen auf durchgeführte Änderungen, also kein einfacher Transfer kompletter Datensätze wie z. B. bei OOP oder PBAP) von PIM (Personal Information Management) Daten gibt es bei Bluetooth eine Reihe von Varianten.

Die am frühestens eingesetzte Variante der Synchronisation ist IrMC (Infrared Mobile Communication), ein ursprünglicher IrDA Standard. Diese Variante ist auch heute noch sehr (vor allen bei Sony Ericsson) verbreitet.

Im Jahre 2006 hat die Bluetooth SIG den SyncML Standard (heute Open Mobile Alliance Data Sync, OMA-DS) als Standard für die Synchronisation empfohlen. Dafür wurde bei SyncML das Binding von OBEX Paketen auf das SyncML Protokoll bzw. die Datendarstellung bei SyncML standardisiert. SyncML ist heute herstellerübergreifend in sehr vielen Mobiltelefonen integriert. Das Mobiltelefon arbeitet dabei als SyncML Client, der PC (mit der entsprechenden Software des Mobiltelefonherstellers) als SyncML Server. Es gibt aber auch sehr viele Telematiksysteme die im Fahrzeug einen SyncML Server implementiert haben. Da die meisten SyncML Client Implementierungen heute (August 2009) multiple Server Beziehungen (Synchronisation mit mehreren Servern, z. B. PC Office, PC Home, Car Kit im Fahrzeug) unterstützen, ist die Verwendung von SyncML sehr komfortabel. SyncML Implementierungen unterscheiden sich durch die Methoden der Konfliktauflösung (was liegt auf dem Sever und was wurde im Client geändert).

13. Stacks und USB Adapter für Windows, Linux und Android Bluetooth Hosts Stacks für Windows und Linux sind von Microsoft, Broadcom, IVT, Toshiba und iAnyhwere erhältlich. Dazu kommt noch der BlueZ von Linux. Im folgenden die Informationen von der Bluetooth Qualification Seite der Bluetooth SIG zu 2.1 Stacks dieser Firmen.

Microsoft unterstützt für Windows Vista und Windows 7 einen Bluetooth 2.1+EDR kompatiblen Hoststack. Die Liste der unterstützten Profile ist mit DUN, OOP, PAN, HCRP Client und HID Host aber sehr kurz. Das dürfte der wesentliche Grund für die diversen anderen Angebote sein.

Broadcom liefert einen Bluetooth 2.1 + EDR Stack für Windows2000/XP mit HFP 1.5, A2DP, VDP, AVRCP 1.3, BIP, HID Host, HCRP, DUN, PAN, OOP, FTP und IrMC und Windows Vista mit HFP 1.5, A2DP, VDP, AVRCP 1.3, BIP und IrMC.

IVT liefert einen Bluetooth 2.1 + EDR Stack für Windows2000/XP/Vista mit HSP, HFP 1.5, A2DP, AVRCP 1.2 (Target), BIP, HID, HCRP, DUN, PAN, OOP, FTP, IrMC, Fax und CTP.

Toshiba liefert einen Bluetooth 2.1 + EDR Stack für Windows2000/XP/Vista mit HSP, HFP 1.5, A2DP, AVRCP 1.3 (Target), BIP, HID Host, HCRP 1.2, DUN, PAN, OOP, FTP, Fax und CTP.

iAnywhere liefert einen Bluetooth 2.1 + EDR Stack für Windows2000/XP/Vista mit HSP, HFP 1.5, A2DP, AVRCP 1.4 (Target), BIP, HID Host, HCRP 1.2, DUN, PAN, OOP und FTP.

Für BlueZ liegt bis Ende August 2009 keine Bluetooth 2.1 Qualifizierung vor. BlueZ bietet auch unter Standard Linux Distributionen keine mit kommerziellen Stacks vergleichbare Interoperabilität oder Robustheit. Beleg dafür sind die einschlägigen Webseiten und die dort hinterlegten Meldungen. Die letzten qualifizierten BlueZ Versionen entsprechen Bluetooth 2.0 + EDR. Der Profilsupport ist sehr lückenhaft und entspricht nicht dem letzten Stand. Das dürfte auch der Grund gewesen sein, bei Android auf BlueZ in der zu verzichten. Einige Firmen bieten daher kommerzielle und Bluetooth qualifizierte Stacks für Android an.

Die Vielfalt der Bluetooth Stacks für Windows und die qualitativ sehr unterschiedlichen Bluetooth USB Adapter – viele sind trotz Logo auf dem Adapter nicht qualifiziert und funktionieren nicht immer einwandfrei – sind häufig nicht unproblematisch. Unterschiedliche PC-Installationen bzw. Unverträglichkeit mit anderen – auf dem gleichen Rechner vorhandenen Stacks – erschweren den Einsatz der Anwendungen, die mit Bluetooth arbeiten. Da nur zwei Hersteller ICs mit USB anbieten, ist die Auswahl an wirklich unterschiedlichen Adaptern gering. Die Anzahl der Bluetooth USB Adapter die 2.1 + EDR unterstützen ist leider gering.

24

Literatur [1] Merkle/Terzis, Digitale Funkkommunikation mit Bluetooth, Franzis, 2002 [2] Wollert, Das Bluetooth Handbuch, Franzis, 2002 [3] Lüders, Lokale Funknetze, Vogel, 2007 [4] www.ars2000.com/Bluetooth-drahtlose-Komm.pdf [5] Bluetooth Spezifikation 3.0 + HS der Bluetooth SIG [6] Bluetooth Lowe Energy Spezifikation (Controller, L2CAP, Error Codes) der Bluetooth SIG [7] Phone Book Access Profile Spezifikation v1.0 der Bluetooth SIG [8] Message Access Profile Spezifikation v1.0 der Bluetooth SIG [9] Advanced Audio Distribution Profile v1.2 der Bluetooth SIG [10] Audio Video Remote Control Profile Spezifikation v1.4 der Bluetooth SIG [11] Health Device Profile Spezifikation v1.0 der Bluetooth SIG [12] AV/C Digital Interface Command Set – General Specification, Version 4.0, 1394 TA [13] AV/C Digital Interface Command Set - General Specification, Version 4.1, 1394 TA [14] AV/C Panel Subunit, Version 1.1, 1394 Trade Association [15] Simultaneous Use of HFP A2DP and AVRCP_WP v11, White Paper der Bluetooth SIG [16] Norgall, e-Health–Standards für Kommunikation/Interoperabilität, HL7, 2005, [17] IEEE-11073, IEEE WG Meeting, San Antonio, Januar 2008 [18] IEEE-11073-20601 und IEEE-104xx Spezifikationen

Links www.bluetooth.org https://www.bluetooth.org/tpg/listings.cfm www.continuaalliance.org www.pasife.com http://standards.ieee.org

August 2009

Rudi Latuske ARS Software GmbH

Starnberger Str. 22 D-82131 GAUTING/München

Telefon: 089-893 41 30 Telefax: 089-893 41 310

Email: info@ars2000.com www.ars2000.com