Bluetooth 2.1/3.0, Bluetooth Profile und Bluetooth Low Energy
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
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.
13. 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.
2Bild 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.
3Das 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.
4Out 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 Display Only Display Yes/No Keyboard Only No Input/
No Output
Responder B
Display Only Numerischer Numerischer Passkey Eingabe. Numerischer
Vergleich mit Vergleich mit Responder Vergleich mit
automatischer automatischer Display, automatischer
Bestätigung auf Bestätigung auf Initiator Input Bestätigung auf
beiden Geräten Gerät B beiden Geräten
Unauthenticated Unauthenticated Authenticated Unauthenticated
Display Yes/no Numerischer Numerischer Passkey Eingabe. Numerischer
Vergleich mit Vergleich. Responder Vergleich mit
automatischer Beide Display, Display, automatischer
Bestätigung auf Beide Confirm Initiator Input Bestätigung auf
Gerät A Gerät A
Unauthenticated Authenticated Authenticated Unauthenticated
Keyboard Only Passkey Eingabe. Passkey Eingabe. Passkey Eingabe. Numerischer
Initiator Display, Initiator Display, Initiator und Vergleich mit
Responder Input Responder Input Responder Input automatischer
Bestätigung auf
beiden Geräten
Authenticated Authenticated Authenticated Unauthenticated
No Input/ Numerischer Numerischer Numerischer Numerischer
No Output Vergleich mit Vergleich mit Vergleich mit Vergleich mit
automatischer automatischer automatischer automatischer
Bestätigung auf Bestätigung auf Bestätigung auf Bestätigung auf
beiden Geräten Gerät B beiden Geräten beiden Geräten
Unauthenticated Unauthenticated Unauthenticated 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.
5Für Services Erforderlicher Link Erforderlicher Link Anmerkungen
erforderliche Security Key Type für das Key Type für Geräte
Level remote Device vor BT 2.1 (2.0, 1.2)
Level 3 Authenticated Combination Key mit Hohe Security
16 Zeichen ist
- MITM Schutz empfohlen
erforderlich
- Encryption gewünscht
- Anwendereingriffe
werden akzeptiert
Level 2 Unauthenticated Combination Key Mittlere Security
- MITM Schutz nicht
notwendig
- Encryption gewünscht
Level 1 Unauthenticated Keiner Geringe Security
- 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
Level 0 Keiner Keiner Nur für SDP erlaubt!
- MITM Schutz nicht
notwendig
- Encryption nicht
notwendig
- Keine Anwendereingriff
Gewünscht
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.
6Bild 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)
7Das 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
8Bei 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.
9Mit 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
105. 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.
11Um 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).
12Der 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).
13Der 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.
14Das 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.
157. 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.
168. 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.
17Deswegen 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.
18Sie können auch lesen
