Bluetooth in a Nutshell - Institut für Pervasive Computing

UNIVERSITÄT LINZ
Institut für Praktische Informatik
Univ.Prof. Dr. Alois Ferscha
Bluetooth in a Nutshell
Context Framework for Mobile User Applications
Strategic Alliance Siemens AG – JKU Linz
Institut für Praktische Informatik – Universität Linz
Univ.Prof. Dr. Alois Ferscha
Kurzbeschreibung:
In diesem Dokument werden Bluetooth-Grundlagen vermittelt,
verwandte Technologien untersucht, eine Bluetooth-Marktstudie
präsentiert, zukünftige Entwicklungen abgeschätzt und anhand
praktischer Beispiele der Einsatz von Bluetooth demonstriert.
Autor(en):
Clemens Holzmann ([email protected])
Stefan Oppl ([email protected])
Daum:
2003.12.02
Status:
Final
Inhaltsverzeichnis
1
EINLEITUNG .......................................................................................4
1.1
Geschichte von Bluetooth................................................................................................... 4
1.2
Anwendungsszenarien........................................................................................................ 6
2
BLUETOOTH GRUNDLAGEN .......................................................... 21
2.1
Systembeschreibung ......................................................................................................... 21
2.2
Protokollstack Teil 1 – Bluetooth Modul ........................................................................ 27
2.3
Protokollstack Teil 2 – Bluetooth Host ........................................................................... 52
2.4
Schichtenübergreifende Funktionalitäten ...................................................................... 63
2.5
Bluetooth-Profile .............................................................................................................. 77
2.6
Bluetooth 1.2 ..................................................................................................................... 90
2.7
Performance ...................................................................................................................... 94
2.8
Bewertung ......................................................................................................................... 99
3
VERWANDTE TECHNOLOGIEN .................................................... 103
3.1
IrDA ................................................................................................................................. 103
3.2
WLAN (802.11x) ............................................................................................................. 103
3.3
DECT ............................................................................................................................... 105
3.4
HiperLAN2 ..................................................................................................................... 105
3.5
ZigBee .............................................................................................................................. 106
-2-
3.6
Bluetooth 2.0 ................................................................................................................... 108
3.7
Ultra Wideband .............................................................................................................. 109
3.8
WiMedia .......................................................................................................................... 110
3.9
Zusammenfassung .......................................................................................................... 111
4
BLUETOOTH DEVELOPMENT ...................................................... 113
4.1
Open Source-Protokollstacks ........................................................................................ 113
4.2
Bluetooth auf Betriebssystemen für mobile Geräte ..................................................... 119
4.3
Bluetooth für Java .......................................................................................................... 121
4.4
„Ping-Pong“ mit Java unter Symbian OS 7.0 .............................................................. 128
5
BLUETOOTH MARKT ..................................................................... 137
5.1
Bluetooth kommt langsam, aber stark ......................................................................... 137
5.2
Die kritische Masse ist erreicht ..................................................................................... 139
5.3
Bluetooth im Endgerätemarkt ....................................................................................... 140
6
BLUETOOTH – QUO VADIS? ........................................................ 144
7
LITERATURVERZEICHNIS ............................................................. 146
7.1
Bücher und Publikationen ............................................................................................. 146
7.2
Internet ............................................................................................................................ 149
8
ABBILDUNGSVERZEICHNIS ......................................................... 153
-3-
1 Einleitung
1.1
Geschichte von Bluetooth
Die Geschichte von Bluetooth begann 1994, als die Firma Ericsson Mobile Communications mit
einer Studie begann, welche die Möglichkeit untersuchen sollte, mittels eines kostengünstigen und
energiesparenden Übertragungssystems Daten zwischen Mobiltelefonen und deren Zubehör
auszutauschen. Ziel war es, durch Einbau eines Funkteils in ein Mobiltelefon und ein Notebook ohne
lästige Kabel Daten austauschen zu können. Mit der Zeit erkannten die Entwickler, dass diese
Funktechnologie auch als Schnittstelle zur Peripherie dienen kann bzw. die Vernetzung von
verschiedenen Geräten außerhalb einer fest integrierten Netzwerkinfrastruktur ermöglicht.
1998 schlossen sich schließlich die Firmen IBM, Intel, Ericsson, Nokia und Toshiba als „Special
Interest Group“ (SIG) [3] zusammen und entwickelten unter dem Namen Bluetooth eine Technologie für
die drahtlose Funkübertragung von Sprache und Daten. Kurz darauf stießen auch noch die Firmen
Microsoft, Agere Systems, 3COM und Motorola dazu, und bildeten zusammen die Gruppe der s.g. „Core
Promoter“. Sie veröffentlichten 1999 die Version 1.0 der Bluetooth-Spezifikation. Neben der PromoterGruppe gibt es auch noch Associate-Firmen, die einen jährlichen Beitrag zahlen um dafür an neuen
Bluetooth-Spezifikationen aktiv teilnehmen zu können, sowie Adopter-Firmen, deren Mitgliedschaft
kostenlos ist und die diese Technologie verwenden wollen. Siemens AG [4] gehört neben rund 140
weiteren Firmen zur Gruppe der Associate-Members. Die Zahl der Adoper beläuft sich mittlerweile auf
rund 2800 Mitglieder.
Abbildung 1: Bluetooth-Logo [1]
Ziel der SIG war es, eine preiswerte und energiesparende Funkverbindung zu schaffen, die Kabel
auf kurze Distanz ersetzt und weltweit ein großes Angebot an untereinander kompatiblen Geräten
entstehen lässt. [Merk02] Ein weiteres Designziel war die geringe physische Größe, die sich mittlerweile
auf Münzgröße verringert hat. Als Beispiel kann an dieser Stelle das SieMos S50037-Bluetooth Modul
-4-
[5] von Siemens [4] angeführt werden (siehe Abbildung 3), das die komplette Bluetooth v1.1Funktionalität sowie eine UART und USB-Schnittstelle bietet.
Abbildung 2: SieMos Bluetooth Modul [5]
Bei Bluetooth handelt es sich um einen offenen Industriestandard, der kostenlos und ohne
Anmeldung via Internet bezogen werden kann, wodurch die SIG eine weite Verbreitung der Technologie
erreicht. Die Bluetooth-Spezifikation [2], die seit 22. Februar 2001 in der Version 1.1 vorliegt, besteht im
Wesentlichen aus folgenden zwei Hauptdokumenten:
Core Specification: Spezifikation des Bluetooth Protokollstacks (rund 1200 Seiten) +
Addendum, zusätzlich gibt es ergänzende Korrekturdokumente. [BCOR01]
Profiles Specification: Spezifikation der Bluetooth-Profile (rund 500 Seiten) [BPRO01]
Da Version 1.1 ausschließlich die Profile umfasst, die im zweiten Hauptdokument genannt und
spezifiziert sind, gibt es eine Reihe weiterer Dokumente, die neu hinzugekommene Profile – AVCTP,
AVDTP, BNEP, A2DP, AVRCP, HFP, PAN, HID, SAP etc. – spezifizieren. [Kral03]
Seit 5. November 2003 ist die Core Specification in Version 1.2 [BCOR03] verfügbar.
IEEE hat mit dem Projekt 802.15 WPAN Task Group 1 (IEEE 802.15.1) aus den BluetoothSpezifikationen v1.1 einen Wireless Personal Area Standard abgeleitet und Bluetooth somit den Status
eines IEEE-Standards zuerkannt. Geräte, die auf der Grundlage von 802.15.1-2002 (aktuelle
Spezifikation vom 14. Juni 2002) entwickelt werden, sollen voll kompatibel zu jenen sein, die auf der
aktuellen Bluetooth-Spezifikation 1.1 aufsetzen. [11] IEEE hat sich dabei aber traditionellerweise nur auf
die Bitübertragungs- und Sicherungsschicht beschränkt, wohingegen Bluetooth auch die höheren
Schichten, Anwendungsprofile, Dienstbeschreibungen etc. spezifiziert.
Der Vollständigkeit wegen sei noch angemerkt, dass der Name Bluetooth (Blauzahn) von Ericsson
in Erinnerung an den Wikingerkönig Harald Blåtand gewählt wurde, der von rund 1000 Jahren herrschte
und diesen Beinamen nicht aufgrund seiner Vorliebe für Blaubeeren sondern aufgrund seines dunklen
-5-
Erscheinungsbildes trug (Blå war auch das Wort für „dunkel“ im Mittelalter). [Schi03] Wegen des durch
ihn eingeleiteten erfolgreichen Zusammenschlusses einzelner Gebietsteile zu einem einheitlichen
Königreich steht sein Name auch heute noch für fortschrittliches Denken auf Basis eines großen
Grundgedankens; ähnlich ist es bei der nach ihm benannten Funktechnologie Bluetooth. [Merk02]
1.2
Anwendungsszenarien
Für Bluetooth gibt es im Wesentlichen drei Anwendungsszenarien:
Daten- und Sprach-Access Points: Sie stellen eine Brücke zwischen der drahtgebundenen
und der drahtlosen Welt dar.
Bildung von Ad-hoc Netzwerken: Unter Ad-hoc Netzwerken versteht man die spontane
Vernetzung von Geräten ohne feste Infrastruktur. Daten können automatisch
ausgetauscht, synchronisiert oder gezielt aktualisiert werden.
Ersetzen von Kabelverbindungen: Dies ist eines der wichtigsten Argumente für die
Bluetooth-Technologie; durch eine einheitliche Funkschnittstelle ist man unabhängig von
proprietären Anschlusskabeln und Adaptern.
Im Folgenden ist eine Vielzahl von Anwendungen angeführt, wobei man davon ausgehen kann,
dass in Zukunft weitere Einsatzmöglichkeiten hinzukommen. Einige davon sind zwar noch nicht
serienreif, sollten aber eine Abschätzung des Potenzials der Bluetooth-Technologie ermöglichen.
[Merk02]
1.2.1 Verbindung von Notebook, PDA und Mobiltelefon
Ein interessantes Anwendungsgebiet für Bluetooth ist die spontane drahtlose Vernetzung
unterschiedlicher Geräte verschiedenster Hersteller. Dies ermöglicht einen schnellen temporären
Verbindungsaufbau zwischen Geräten, um beispielsweise Dateien, Termine oder Kontakte
auszutauschen, ohne auf lästige Kabel mit proprietären Schnittstellen angewiesen zu sein. Ein mögliches
Szenario sind interaktive Konferenzräume, die es den Teilnehmern ermöglichen, während der Konferenz
Daten auszutauschen. [Lule01] [Mill01]
1.2.2 Das drei-in-einem Telefon
Ein nützliches Anwendungsmodell ist das „drei-in-einem“-Telefon. Viele Menschen benutzen
heute drei verschiedene Telefone: Ein Geschäftstelefon im Büro, ein Telefon zuhause und ein
-6-
Mobiltelefon für unterwegs. [Merk02] Sie haben im Prinzip alle die gleiche Aufgabe, nämlich analoge
Sprache zu digitalisieren und in das externe Telefonnetzwerk weiterzuleiten. [Lule01]
Bluetooth ermöglicht hier die Vereinigung in ein Telefon. Unterwegs kann über das
Mobilfunknetzwerk telefoniert werden und im Büro kann mit demselben Bluetooth-fähigen Telefon über
Sprachzugangspunkte telefoniert werden. Vorteilhaft ist dabei nicht nur die Integration in ein einziges
Gerät, sondern auch die Tatsache, dass sämtliche Telefonnummern nur in diesem einen Telefon
gespeichert sind. Das Prinzip ist in Abbildung 3 veranschaulicht.
Eine zusätzliche Funktionalität ergibt sich durch einen „Walkie-Talkie-Betrieb“, der eine direkte
Kommunikation zwischen zwei Bluetooth-Mobiltelefonen ermöglicht. [Merk02] Einschränkend wirkt
hier allein die begrenzte Reichweite, die aber in der Leistungsklasse 1 bei 100m liegt und somit auch
sinnvolle Anwendungsszenarien ermöglicht. [Lule01]
Abbildung 3: Telefonie über verschiedene Medien [Lule01]
1.2.3 Automatische Datensynchronisation
Heute ist es üblich, mehrere Geräte – meist ein Notebook, ein Mobiltelefon und einen PDA
(Personal Digital Assistant) – zu nutzen. Alle diese Geräte fungieren u.a. als Informationsträger, die
gespeicherten Daten reichen von Telefonnummern bis hin zu täglichen Terminen. Unter einer
Datensynchronisation versteht man in diesem Zusammenhang das Synchronisieren der verschiedenen
Informationen auf allen Geräten. Besonders komfortabel gestaltet sich diese Synchronisation mit
Bluetooth, da die einzelnen „Datenbanken“ automatisch synchronisiert werden können, ohne dass das mit
Aufwand verbunden ist. [Merk02] Eine solche automatische Synchronisation fällt in den Bereich des
„Hidden Computing“ oder „Invisible Computing“, worunter man im Hintergrund ablaufende, unbemerkte
Informationsverarbeitung versteht. [Matt03]
-7-
Folgendes Beispiel soll dieses Szenario verdeutlichen: Jemand teilt einem unterwegs seine
Telefonnummer mit, die man ins Mobiltelefon einträgt. Zuhause angekommen wird automatisch ein Adhoc Netzwerk mit dem Notebook und dem PDA gebildet und die Änderungen werden entsprechend
synchronisiert.
Da es aber immer mehr Bluetooth-fähige Geräte gibt, drängt sich die Frage auf, ob sich alle Geräte
im selben Überdeckungsbereich automatisch synchronisieren sollten. Hierfür bietet Bluetooth aber
entsprechende Konfigurationsmöglichkeiten, um diese unerwünschte Aktion zu verhindern. [Merk02]
Ein innovatives Szenario stellt das am Institut für Praktische Informatik der Johannes Kepler
Universität Linz entwickelte Konzept der Digitalen Aura dar, welches auf einen automatischen
Informationsabgleich zwischen Geräten abzielt. So wäre es denkbar, dass zwei aneinander vorbeigehende
Personen (Person to Person, P2P) Bluetooth-fähige Geräte eingesteckt haben, die ihre digitalen Auren im
Umkreis von rund 10 m „abstrahlen“. Überdecken sich nun deren Funkbereiche, so können automatisch
kontextbezogene Informationen ausgetauscht werden. Aber auch Person to Object (P2O) ist eine
Möglichkeit: Man kann also an einem Plakat mit einer interessanten Konzertveranstaltung vorbeigehen,
und der PDA vermerkt das Datum automatisch im Terminkalender. [12]
1.2.4 Drahtloses Headset, Audioübertragung
Das wahrscheinlich häufigste Szenario für den Einsatz von Bluetooth-Headsets stellt das mobile
Telefonieren eines Fahrzeugführers während der Fahrt dar. Dies ist zwar auch mit kabelgebundenen
Headsets möglich, welche aber die Bewegungsfreiheit des Anwenders einschränken. Zuhause oder am
Arbeitsplatz bieten drahtlose Headsets den Vorteil, dass man sich – beispielsweise bei Hausarbeiten – frei
im Raum bewegen kann. Ein weiterer Vorteil ist die Tatsache, dass dasselbe Headset für verschiedene
Geräte – unterschiedliche Mobiltelefone, Computer oder jeglicher anderer Sprachzugangspunkt – benutzt
werden kann. [Merk02]
Abbildung 4: Audio-Konfiguration mit Bluetooth [Lule01]
-8-
Auf Baustellen oder in Fabrikshallen ist auch die Verwendung eines Gehörschutzes mit
integriertem Bluetooth-Headset denkbar. [Lule01] Im Heimbereich bietet sich eine drahtlose Verbindung
zwischen HiFi-Anlage und Lautsprechern in Kombination mit einer Bluetooth-Fernbedienung an,
wodurch eine HiFi-Anlage mehrere Räume mit Musik versorgen könnte und man sich die lästigen Kabel
spart.
1.2.5 Zugang zum Internet via Bluetooth
Internetzugang kann auf mehrere Arten erfolgen. Eine Möglichkeit besteht darin, mit Hilfe eines
Bluetooth-fähigen Mobiltelefons einem Notebook, PC oder PDA den Zugang zum Internet zu
ermöglichen. Das Mobiltelefon kann dabei z.B. in der Jackentasche verstaut bleiben, wodurch sich eine
erhöhte Bewegungsfreiheit ergibt.
Eine weitere Zugangsmöglichkeit besteht in der Verwendung von Bluetooth Access-Points, die
ihrerseits beispielsweise mit dem firmeninternen LAN verbunden sind und somit PCs bzw. Notebooks
Internetzugang bieten, wodurch nicht für jeden Arbeitsplatz Kabel verlegt und entsprechende Buchsen
installiert werden müssen. [Lule01]
Einen interessanten Verwendungsbedarf für Bluetooth hat das Computer Science Department der
Universität von Kalifornien ausgemacht: Die Verknüpfung von UMTS mit Bluetooth. Man untersuchte das
Verhalten hybrider IT-Strukturen, bestehend aus Bluetooth-Scatternetzen, die über s.g. Hybrid-Units
jeweils mit einer UMTS-Basisstation verbunden sind. Die Untersuchung hat gezeigt, dass die
Konstellation Bluetooth und UMTS den funktechnischen Begebenheiten – vor allem in Räumlichkeiten –
sehr entgegenkommt. Weiters wird darauf hingewiesen, dass diese Kombination sogar kostengünstiger
sein und mit Roaming sowie einer effizienten Verwendung von Bandbreite zusammen mit den
Weitverkehrseigenschaften von UMTS gewisse Limitierungen von Bluetooth aufhebt. [Kral03]
1.2.6 PC-Peripherie
Die Verbindung von PCs untereinander sowie die Verbindung eines PCs mit Peripheriegeräten
wird heute noch hauptsächlich mit Kabeln hergestellt. Nachteilig an dieser Methode ist nicht nur die
eingeschränkte Bewegungsfreiheit, sondern auch die notwendige Menge an oftmals unterschiedlichen
Kabeln. Weiters führen sie zu einer Vergrößerung der Geräte, die Platz für eine Vielzahl von
Schnittstellen bereitstellen müssen.
-9-
Geht man davon aus, dass im PC sowie in allen Peripheriegeräten ein Bluetooth-Chip integriert ist,
kann der Benutzer häufig benutzte Geräte im PC anmelden („paaren“), sodass diese Geräte automatisch
verbunden werden sobald sie in Reichweite kommen (siehe Abbildung 5). [Lule01]
Abbildung 5: PC-Peripherie per Bluetooth [Lule01]
Problematisch ist allerdings die geringe Datenrate von Bluetooth, wodurch in der aktuellen
Bluetooth-Spezifikation einige Szenarien – beispielsweise eine Bluetooth-fähige externe Festplatte –
zumindest beim Einsatz mit einem Notebook fragwürdig sind, in Kombination mit einem PDA allerdings
wieder Sinn machen.
1.2.7 Haushaltsgeräte
In den letzten Jahren sind einige drahtgebundene, proprietäre Lösungen für die Vernetzung von
Haushaltsgeräten auf den Markt gekommen (z.B. die Siemens InstaBus Technik, die eine zusätzliche
Kabelinstallation im gesamten Wohngebäude erfordert und nur speziell ausgerüstete Siemens Geräte
miteinander verbinden kann). Durch eine Bluetooth-Integration hingegen ist eine umfassendere
Vernetzung möglich, mit den entsprechenden Anwendungen in den einzelnen Geräten entsteht ein
drahtloses Haushaltsnetzwerk welches einfach erweiterbar und veränderbar ist.
So könnte beispielsweise das Betreten des Hauses mit einem intern bekannten Bluetooth Gerät
zur Folge haben, dass das Licht in bestimmten Räumen angeschaltet wird, die Heizung auf einen
eingestellten Wert steigt und der Anrufbeantworter die neuen Nachrichten wiedergibt. Mit neueren
Technologien wie Sprachein- und -ausgabe wäre auf der nächsten Stufe eine Sprachsteuerung aller Geräte
auch aus entfernten Räumen möglich, da die im Haus installierten Bluetooth-Geräte Nachrichten
untereinander weitergeben können. [Lule01]
- 10 -
Abbildung 6: Vernetzter Haushalt [Lule01]
1.2.8 Universalfernbedienung
Mittlerweile existieren viele verschiedene Fernbedienungstypen, die meist auf Infrarot oder Funk
beruhen und i.d.R. proprietäre Algorithmen verwenden. Es gibt zwar s.g. „Universalfernbedienungen“,
die eine Vielzahl unterschiedlicher Fernbedienungen eines physikalischen Mediums (z.B. Infrarot)
emulieren können, häufig aber nur mit eingeschränktem Funktionsumfang. Ein Problem fast aller
Fernbedienungen ist aber die Einschränkung auf die bei der Planung bekannten Funktionen; eine
Erweiterung der Fernsteuerung um neue Funktionen ist selten ohne ein manuelles Software-Update
möglich.
Mit Bluetooth steht erstmals ein – im Vergleich zu bisherigen Funklösungen – relativ günstiger
Standard für die drahtlose Kommunikation zur Verfügung, der verschiedenste Geräte miteinander
kommunizieren lässt. Jedes mit Fernbedienungssoftware ausgerüstete Gerät - z.B. ein Bluetooth-fähiges
Mobiltelefon oder ein PDA – kann alle in Reichweite befindlichen Geräte fernsteuern, egal ob
Videorecorder, Rollladenantrieb oder Heizung. Kommen neue Geräte oder funktionale Erweiterungen
hinzu, so müssen diese lediglich den fernsteuernden Geräten bekannt gemacht werden. [Lule01]
- 11 -
Abbildung 7: Fernbedienung industrieller Geräte [Lule01]
1.2.9 Schlüssel für Zugang und Identifikation
Schlüssel ermöglichen den Zugang zu kontrollierten Bereichen und existieren heute in den
unterschiedlichsten Ausprägungen, vom metallischen Sicherheitsschloss über Karten mit Magnetstreifen
bzw. Chips bis hin zum drahtlosen Schlüssel für Automobile. Den meisten Schlüsselsystemen ist
gemeinsam, dass der Benutzer automatisch zum Zugangsberechtigten wird sobald er den Schlüssel
besitzt, denn eine Identifikation des Benutzers gegenüber dem Schlüssel als autorisierter Besitzer ist
meist nicht vorgesehen.
Ein Bluetooth Gerät, welches zumindest mit einer Zehner-Tastatur oder einem biometrischen
Sensor ausgestattet ist, kann als Universalschlüssel für Bluetooth Zugangskontrollsysteme dienen. Der
Schlüssel kann ausgeschaltet werden und ist erst nach erfolgreicher Authentifizierung wieder benutzbar.
Kommt der Benutzer in Reichweite einer Zugangskontrolle, so aktiviert er per Knopfdruck den
Bluetooth-Schlüssel und nach einem kurzen Moment gewährt das System den Eintritt bzw. die
Benutzung. Ein und derselbe Schlüssel kann für jedes Bluetooth- Zugangskontrollsystem qualifiziert
werden, indem ein weiterer Schlüsselcode und/oder – für erhöhte Sicherheit – ein neuer
Schlüsselwechselalgorithmus hinzugefügt wird. Dieses Szenario soll in Abbildung 8 verdeutlicht werden.
Eine Variante mit geringerer Sicherheit besteht darin, die Verifikation des Schlüssels ohne
Authentifizierung und nur aufgrund der Bluetooth-Geräteadresse vorzunehmen. [Lule01] Weitere
Ausführungen über Sicherheit finden sich in Kapitel 2.4.1 (Sicherheit und Verschlüsselung).
Eine weitere Anwendungsmöglichkeit für Bluetooth-basierte Identifikation ergibt sich bei
Parkhäusern durch ein berührungsloses Öffnen des Schrankens bei entsprechender Berechtigung.
Der Stromverbrauch stellt zwar einen Nachteil von Bluetooth-Schlüsseln dar, [Lule01] schätzt die
Lebenszeit bei einer 600mAh-Batterien aber auf immerhin 8 Wochen. Der Stromverbrauch ist allerdings
- 12 -
kein Nachteil mehr, wenn die Schlüssel-Funktionalität in das Mobiltelefon integriert wird, das ohnehin
regelmäßig geladen werden muss.
Abbildung 8: Bluetooth als Schlüsselersatz [Lule01]
1.2.10 Bluetooth-Geldbörse
Mit Hilfe von Bluetooth können Dinge wie Fahrzeugschlüssel, Mobiltelefon und Geldbörse in ein
Gerät – einem s.g. Personal Trusted Device (PTD) – zusammengefasst werden, z.B. in Form eines
erweiterten Mobiltelefons. Der Vorgang der Bezahlung soll im Folgenden kurz anhand eines Einkaufs bei
einem Einzelhändler beschrieben werden:
Nachdem der Kunde die gewünschten Waren ausgewählt hat, kommt er zur Kasse, wodurch die
Bezahlung via Bluetooth initiiert wird. Der Kunde aktiviert daraufhin sein PTD und das Kassensystem
übermittelt per Bluetooth den zu zahlenden Betrag, wo dieser als elektronische Rechnung auf dem
Display angezeigt wird. Diese Rechnung unterschreibt er mit seiner digitalen Signatur, die in seinem PTD
gespeichert und nur nach Eingabe einer PIN zugänglich ist. Die digital signierte Rechnung wird per
Bluetooth zurück an das Kassensystem gesendet und von dort über ein externes Netz an den Kontoführer
des Kunden, z.B. seine Bank oder sein Kreditkarteninstitut, weitergeleitet. Dort wird seine Liquidität
geprüft und eine entsprechende Zahlungsgarantie zurück an das Kassensystem des Händlers gesendet.
Das Kassensystem sendet dem PTD des Kunden per Bluetooth eine elektronische Quittung und der
Kunde kann die ausgewählten Waren mitnehmen.
Dieses Szenario setzt voraus, dass beide Geräte über eine spezielle Electronic Bill and Payment
(EBPP)- Anwendung [12] miteinander kommunizieren, basierend auf den Sicherheitsfunktionen aus dem
Wireless Application Environment (WAE). Für eine genauere Ausführung wird auf [Lule01] verwiesen.
- 13 -
Die Integration von Fahrzeugschlüssel, Geldbörse und Mobiltelefon in ein Gerät bringt aber auch
einige Nachteile mit sich: Zum einen können die Einzelteile nicht mehr ohne weiteres an
vertrauenswürdige Personen verliehen werden; wollte beispielsweise ein Vater seiner Tochter das
Fahrzeug leihen, so muss diese manuell mit ihrem PTD am Fahrzeug registriert werden, eine einfache
Übergabe der elektronischen Schlüssel ist nicht möglich. Nach der Fahrt kann mangels physikalisch
getrenntem Schlüssel ein Zurücknehmen der Fahrerlaubnis nur durch manuelles Deaktivieren der
Zugangserlaubnis für die Tochter direkt am Fahrzeug geschehen. Dieses Problem ließe sich aber durch
einen separaten Bluetooth-Schlüssel für wechselnde Fahrer abschwächen. Ein weiterer Nachteil besteht
darin, dass bei Verlust des PTD alle integrierten Funktionen auf einmal verloren sind. Andererseits bietet
die elektronische Form der Aufbewahrung die Möglichkeit, in regelmäßigen Abständen die PIN des
Besitzers abzufragen und das PTD somit automatisch zu sperren, falls es nicht mehr im rechtmäßigen
Besitz ist; ein Mobiltelefon als PTD könnte auch die Möglichkeit der Fernsperrung bieten. [Lule01]
1.2.11 Infopunkt an Maschinen und Geräten
Informationen über notwendige Wartungsarbeiten und Statistiken über Verbrauch von Ressourcen
und Verschleiß bei Kraftfahrzeugen werden heute noch häufig manuell aufgenommen.
Beispielsweise könnten Sensoren in rotierenden Teilen, zu denen kein Kabel gelegt werden kann
(z.B. Autoreifen), per Bluetooth Informationen – z.B. „zu niedriger Reifendruck“ – an eine zentrale
Datensammelstelle senden und so dem Benutzer des Fahrzeugs angezeigt werden. Zusammen mit
weiteren Fahrzeug-Sensoren können alle Informationen von außen per Bluetooth abgefragt und
gegebenenfalls Maßnahmen ergriffen werden. An Tankstellen installierte Bluetooth Info-Sammler
können automatisch die Daten von tankenden Fahrzeugen aufnehmen und den Fahrer auf Möglichkeiten
der Problembehebung aufmerksam machen. Für die Aufladung der für das Bluetooth-Modul notwendigen
Batterie könnte im Autoreifen Szenario die kinetische Bewegungsenergie genützt werden. [Lule01]
Aber auch in Aufzügen oder Maschinen ist eine bequeme Ferndiagnose möglich, die es
Mitarbeitern des Wartungsdienstes erlaubt, das Störungsprotokoll der Maschine von außen zu lesen, um
dann erst zu entscheiden, ob die Elektronikeinheit wirklich geöffnet werden muss. [Kral03]
1.2.12 BlueTags für Lokalisation
Bei verlorenen Objekten ist die visuelle Suche häufig die einzige Möglichkeit für das
Wiederfinden; Bluetooth-Technologie kann hier Abhilfe schaffen.
- 14 -
Mit Bluetooth ausgerüstete Anstecker in der Größe von Schlüsselanhängern können Kinder und
Koffer bei entsprechender Bluetooth-Infrastruktur ortbar machen. Der Suchende muss die Bluetooth
Geräteadresse des gesuchten Ansteckers einem zentralen Server melden, der mit den einzelnen
Netzknoten verbunden ist und jeden Knoten nach dieser Geräteadresse abfragen kann. Der Ort kann
dadurch mit einer Bluetooth-bedingten Genauigkeit zwischen 10 und 100 m bestimmt werden, je nach
Reichweite der einzelnen Netzknoten und des Ansteckers. [Lule01] Eine genauere Lokalisation kann
durch Einbeziehung mehrerer Bluetooth-Acces Points beispielsweise via Triangulation oder Trilateration
erreicht werden. [Fers03b]
Eine Beispielimplementierung gibt es vom Edelgepäckspezialisten Samsonite [50] und RFI
Mobile Technologies AG [51] unter dem Begriff „Intelligent Baggage“: Der Schalenkoffer SamsoniteSerie 625 Hardlite“ schützt sich vor Verlorengehen durch eine „virtuelle Handfessel“, indem er via
Bluetooth Kontakt zum Besitzer hält und bei Verbindungsabbruch PDA oder Mobiltelefon Alarm
schlagen. Weiters wäre es denkbar, dass sich der Koffer bei Zoll- und Check-in-Schaltern selbst
deklariert. [Kral03]
1.2.13 Infopad im Krankenhaus
In Krankenhäusern sind bis heute praktisch alle Informationsverbindungen via Kabel realisiert.
Ärzte bekommen die Informationen über Patienten heute häufig von zentral aufgestellten Rechnern oder
sogar aus herkömmlichen Akten auf Papier-Basis. Für die Unterhaltung ist bislang der Fernseher
immerhin zum Standard geworden, ein Internet-Anschluss ist allerdings noch die Ausnahme und bislang
durch die nötige Verkabelung sehr umständlich zu handhaben.
Ein mögliches Szenario wäre nun, dass das Krankenhaus-Personal eine kompakte, mobile
Recheneinheit – beispielsweise einen PDA oder einen Tablet PC – mit sich führt, die mit Bluetooth LAN
Access Points kommuniziert, welche sowohl in den Patienten-Zimmern in direkter Nachbarschaft zum
Bett des Patienten als auch im Gebäude verteilt angebracht sind. Das Personal kann in Reichweite eines
beliebigen Access Points auf die Ressourcen des Zentralrechners zugreifen und so Patientendaten
abfragen, Röntgenaufnahmen ansehen oder Anweisungen zur Medikation auf dem jeweiligen Display
angezeigt bekommen. Bei jeder Visite wird die Anwesenheit des Pflegepersonal automatisch registriert
und der Datensatz des Patienten kann – falls notwendig – direkt vor Ort über die mobile Recheneinheit
aktualisiert werden, so dass immer aktuelle Patienteninformationen zentral vorliegen, wodurch DoppelArbeiten oder falsche Anweisungen aufgrund veralteter Information verhindert werden.
Das ohnehin zur Verfügung stehende Bluetooth-Netzwerk kann auch für Patienten zur Verfügung
stehen, die mittels mobiler Recheneinheit drahtlos auf das Intranet (beispielsweise für Video-OnDemand-Angebote oder Netzwerkspiele) oder sogar Internet zugreifen können. Bluetooth-fähige
- 15 -
Sensoren können auch für die Überwachung von Körperfunktionen (z.B. Blutdruck oder Herzfrequenz)
verwendet werden, welche die Daten permanent an Access Points in ihrer Umgebung weiterleiten und
ggf. das Krankenhauspersonal alarmieren. [Lule01]
1.2.14 Data Access Points
Heute werden Informationen meist auf Papier oder auf stationär angebrachten Monitoren und
Anzeigetafeln angeboten – mit dem Nachteil, dass der Empfänger keine Interaktionsmöglichkeit mit dem
Informationsmedium hat.
Viele bereits lokal vorhandene Gegenstände können – wenn nötig besonders robust oder sogar
wasserdicht – zum Bluetooth Access-Point erweitert werden, ohne dass es einer zusätzlichen
Benutzeroberfläche oder eines Schutzes gegen Vandalismus bedarf. Lediglich das Gerät des Benutzers
setzt die Limits für die Art der zu übertragenden Information.
Im Folgenden sind einige Anwendungsszenarien für Bluetooth-Access Points aus [Lule01]
angeführt, die alle auf dem LAN Access Point Profile (siehe Kapitel 2.5.17, LAN Profile) basieren:
Internet-/Intranet-Zugang an Hot Spots: Überall, wo Menschenmassen auftreten – in
Hotels, Messen, Bahnhöfen oder Flughäfen – macht es Sinn, via Access Points Dienste
wie Internetzgang oder ein spezielles Informationsangebot eines angebundenen Intranets
– anzubieten.
Entertainment-while-you-wait-Point: Für einen Verkehrsknotenpunkt – beispielsweise ein
Bahnhof oder Flughafen – kommen Entertainment-while-you-wait-Points in Frage, die
dem Kunden bei Wartezeiten ein besonderes Informations- und Unterhaltungsangebot in
multimedialer Form (Video, Audio, Text) bieten, ev. in Abhängigkeit der Kundenklasse .
Denkbar ist z.B. ein Musikangebot für die Headsets der Kunden oder aktuelle VideoNews für Geräte mit Display und MPEG-Fähigkeiten.
Bonusprogramme für Handel und Dienstleistung: Z.B. eine kostenlose MP3-Musikdatei
eines aktuellen Interpreten oder Bluetooth LAN Access Points in Schaufenstern zur
Versorgung mit zusätzlichen Informationen. Weiters ließe sich die Speisekarte eines
Restaurants spontan mitnehmen oder ein nach Ladenschluss im Schaufenster entdecktes
Produkt für den nächsten Tag reservieren oder einfach nur näher untersuchen.
Virtueller Museumsguide: In Museen oder Galerien lassen sich Hot-Spots in der Nähe
von Exponaten anbringen, die dem Besucher ausführliche Informationen liefern und sich
im Verbund zur virtuellen Führung eignen.
Straßenschilder
und
Werbeplakate
mit
Stadtinfos/Karten/Werbung:
Durch
die
Kompaktheit eines Bluetooth Moduls lassen sie sich auch in Straßenschilder oder
- 16 -
Werbeplakathalter integrieren. Erstere könnten beispielsweise mit Informationen über die
Gewerbe oder Veranstaltungstipps in näherer Umgebung dienen. Ein Bluetooth Modul
hinter einem Werbeplakat hält zusätzliche Informationen über das beworbene Produkt
bereit.
Hotel-Check In, Flug-Check In: Als Variante des Anwendungsszenarios „Bluetooth
Personal Trusted Device (PTD)“ (siehe 1.2.10, Bluetooth-Geldbörse) dient hier das
eigene Bluetooth PTD Gerät als elektronisches Check-In Terminal am Flughafen oder zur
Identifikation im Hotel.
Message-Server, Warteschlangenserver: Ein Message-Server könnte beispielsweise auf
einem Single-Event verwendet werden, um Nachrichten von Singles für Singles zu
verwalten. Jeder Event-Besucher erhält dabei einen anonymisierten Benutzernamen
sowie ein Kennwort und kann damit Nachrichten an andere Besucher versenden, die
diese daraufhin auf ihr Bluetooth-Gerät bekommen. Der Message Server sorgt dabei für
die Speicherung und richtige Zustellung der Nachrichten, wodurch die Besucher
voneinander abgeschirmt werden, sodass keine persönlichen Daten bekannt gegeben
werden müssen. Warteschlangen- und Parkschein-Server verteilen virtuelle, elektronische
Tickets, indem sie die Bluetooth Geräteadresse des Benutzergerätes speichern und in eine
interne Liste einordnen, die später der Auslösung von zeitabhängigen Maßnahmen dient.
Im Fall des Warteschlangenservers ziehen z.B. Kunden einer Bank ein elektronisches
Ticket und der Server ruft den jeweiligen Benutzer dann auf, wenn dieser an der Reihe
ist. Das dahinter stehende Prinzip ist ein WAP- oder OBEX-Pushvorgang, der bei dem
Event „Kunde X ist an der Reihe“ eine entsprechende Nachricht in den Posteingang des
Benutzergeräts sendet. [Lule01]
1.2.15 Drahtlose Sensornetzwerke
Sensornetzwerke sind ein aktuelles Forschungsgebiet mit z.T. noch schlecht untersuchten
Teilbereichen, und sie ermöglichen viele neue Anwendungsgebiete. Ein drahtloses Sensornetzwerk ist ein
Netz aus vielen s.g. Sensorknoten, die jeweils aus einem autonomen Minicomputer bestehen, einen oder
mehrere Sensoren zur Messung von Luftdruck, Feuchtigkeit, Helligkeit, Beschleunigung, Magnetfeld,
Chemikalien etc. „on board“ haben und drahtlos miteinander kommunizieren. Die drahtlose
Kommunikation ermöglicht ein einfaches Verteilen der Sensoren ohne störende Kabel; so können
beispielsweise Aktuatoren und Sensoren unabhängig vom Controller – etwa auf einem bewegten Objekt –
platziert werden. Drahtlose Kommunikation bringt aber auch einige Probleme mit sich, so z.B. die
gegenüber kabelgebundenen Lösungen deutliche höhere Bitfehlerrate sowie daraus resultierende
unvorhersehbar lange Verzögerungen, die zu Instabilitäten des Systems führen können.
- 17 -
Diese Sensorknoten sind sehr klein, können in der Umgebung verteilt werden, vernetzen sich
spontan (es ist also keine Infrastruktur nötig) und eignen sich beispielsweise zur Beobachtung von
Umweltphänomenen (Tiere, Umweltverschmutzungen, seismische Aktivitäten, militärische Überwachung
unzugänglicher Gebiete etc.). Beispiele für Prototypen solcher Sensorknoten sind der „Berkeley Mote“
oder das „Smart-It“ BTnode [16], der einen Mikrocontroller, diverse Sensorinterfaces sowie ein
Bluetooth-Modul auf einer relativ kleinen Platine enthält (siehe Abbildung 9).
Abbildung 9: Smart-It „BTNode“ [16]
Der typische Ablauf gestaltet sich folgendermaßen:
Installation des Sensornetzes (z.B. Abwurf einer Menge von Sensoren aus einem
Flugzeug)
Initialisierung (Kalibrierung der Sensoren, Vernetzung etc.)
Aufgabenstellung (dem Sensornetzwerk eine Aufgabe, z.B. „Melde Fahrzeuge mit einer
Geschwindigkeit > 50 km/h“, stellen)
Ergebnisse generieren (Sensoren regelmäßig lesen, interessante Ergebnisse herausfiltern,
Nachricht verschicken, Nachrichten verschiedener Sensorknoten auswerten und
zusammenfügen)
Zu den zentralen Herausforderungen bei Sensornetzen zählt neben Skalierbarkeit (tausende bis
Millionen von Knoten), Robustheit (das Netz sollte trotz Ausfall einzelner Knoten noch funktionieren)
und Selbst-Konfiguration (es ist keine manuelle Konfiguration einzelner Knoten möglich) die
Energieeffizienz. Sensorknoten müssen sparsam mit Energie umgehen, da ein Batteriewechsel nicht oder
nur schwer möglich ist. Insbesondere ist Kommunikation sehr „teuer“; die Übertragung eines Bits
benötigt ungefähr soviel Energie wie 1000 Prozessorinstruktionen. Weiters muss ein Sensornetzwerk
ohne Infrastruktur auskommen (Ad-hoc Vernetzung) und die Größe der Sensorknoten muss sich
gegenüber den derzeit realisierten Prototypen noch drastisch reduzieren.
- 18 -
Bei dem Smart-Ist-Projekt [16] wurde Bluetooth u.a. aufgrund seiner hohen Interoperabilität mit
einer Vielzahl von Geräten und der Tatsache, dass es eine Applikationsentwicklung über eine
standardisierte Schnittstelle bietet, als Kommunikationstechnologie gewählt. Auch die vergleichsweise
hohe Bandbreite sowie die umfassenden Features von Bluetooth – ACL/SCO, QoS, FEC,
Verschlüsselung, FHSS etc. – waren ausschlaggebend. Negativ anzumerken ist aber der relativ hohe
Energiebedarf, der deutlich über dem von speziell für drahtlose Sensornetze konzipierten Protokollen
liegt. Weiters hat Bluetooth in der Leistungsklasse 3 (die einzige, die aus energiespartechnischen
Gründen in Frage kommt) eine geringe Reichweite von nur rund 10 m und relativ lange
Verbindungsaufbauzeiten. Aufgrund seiner geringen Leistungsaufnahme bei größerer Reichweite dürfte
sich insbesondere IEEE 802.15.4 (siehe Kapitel 3.5, ZigBee) für drahtlose Sensornetzwerke gut eignen.
[Beut04] [Eker01] [Matt03] [Schi03] [Schm03]
1.2.16 Pervasive Computing
Pervasive bzw. Ubiquitous Computing [14] bezeichnet die Vision des allgegenwärtigen,
verschwindenden Computers; immer mehr Objekte werden „smart“ (intelligente Objekte mit
kontextsensitivem Verhalten) und sind mit dem Internet verbunden. Diese Vision wird sehr gut durch
Mark Weiser’s (1952-1999, XEROX PARC) Zitat „The most profound technologies are those that
disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from
it.” unterstrichen.
Durch immer billigere ( weite Verbreitung) und kleinere ( Mobilität) Hardware sowie die
immer kostengünstiger werdende drahtlose Kommunikation wird diese Vision nach und nach zur Realität,
[Matt03] und bringt damit auch eine Unmenge potentieller Einsatzmöglichkeiten für die BluetoothTechnologie mit sich.
Abbildung 10: The Disappearing Computer [Matt03]
Teilbereiche von Pervasive Computing, in denen Bluetooth Anwendungsmöglichkeiten findet,
sind [Matt03]:
Embedded Systems: Eingebettete informationsverarbeitende Systeme sind Computer, die
in Konsumgütern integriert sind und anwendungsspezifische Funktionen ausführen.
- 19 -
[Fers03a] Anwendungsbeispiele sind Bluetooth-Uhren mit integriertem Bluetooth-Chip
[15] zur Synchronisation von Terminen und Kontakten mit dem PC oder zur
Fernbedienung von Geräten, Barcode-Scanner mit integriertem Bluetooth-Chip etc.
Wearable Computing: Darunter versteht man nach Notebooks und PDAs eine neue
Generation portabler Rechner, die am Körper (am Handgelenk, am Gürtel, in einem
Rucksack, in Kleidungsstücke integriert etc.) getragen werden und typischerweise aus
mehreren Komponenten bestehen. Man erwartet sich davon eine Verbesserung mobiler
Arbeitsprozesse und das Erschließen neuer Anwendungen. [Gell03] Im Bereich Wearable
Computing (Wearables, Smart Clothing) finden WPANs (z.B. Bluetooth) intensive
Verwendung, um in die Kleidung integrierte oder am Körper getragene Geräte zu
verbinden, wobei aber der hohe Stromverbrauch von Bluetooth problematisch ist. Mehr
zu Wearable Computing findet sich beispielsweise unter [19].
Wireless Sensor Networks: Siehe Kapitel 1.2.15 (Drahtlose Sensornetzwerke)
1.2.17 Weitere Szenarien
Unzählige weitere Szenarien sind bereits realisiert oder zumindest vorstellbar, die aber
Ähnlichkeiten zu den bisher vorgestellten haben und deshalb nicht näher ausgeführt werden:
Mobiler Produktscanner für Kaufhaus oder Lager
Scannerstift scannt Text aus Büchern oder auch Handschrift während des Schreibens (
Nokia Digital Pen)
Personal-Agent-Gerät für das automatisierte Sammeln von Werbecoupons und
Angeboten
Ein Bestell-Assistent steht auf dem Tisch eines Restaurants und leitet Bestellwünsche
direkt an die Küche weiter
Fahrzeug-Identifikation an Schranken, Parkhäusern; Flottenmanagement
Spielzeug mit Bluetooth ( Nokia NGage)
DateMan als Talisman für Singles signalisiert andere Singles
Die Bluetooth Armbanduhr ist ein Miniatur-Organizer mit automatischer Synchronisation
(Samsung’s GPRS Wrist Watch Phone)
Ein Silencer-Server schaltet Geräte beim Betreten beruhigter Zonen (Kirchen...)
Bluetooth-Geräte automatisch auf lautlos. [Lule01]
- 20 -
2 Bluetooth Grundlagen
2.1
Systembeschreibung
Ziel dieses Kapitels ist es, die wichtigsten Eigenschaften von Bluetooth anzuführen und eine
Übersicht über Bluetooth als Gesamtsystem zu liefern.
2.1.1 Bluetooth Features
Da das Hauptaugenmerk bei der Entwicklung von Bluetooth auf dem weltweiten Einsatz lag,
einigte man sich auf das ISM (Industrial, Scientific, Medical)- Band bei 2.4 GHz, welches für Geräte aus
Industrie, Wissenschaft und Medizin benutzt wird, die darin mit begrenzter Sendeleistung gebührenfrei
und unlizensiert übertragen dürfen. Dieses Frequenzband ist – abgesehen von gewissen Einschränkungen
in Frankreich – weltweit verfügbar. [Merk02] An dieser Stelle sei noch angemerkt, dass durch
Verwendung einer Funktechnologie vergleichen
kommunizierenden Geräten bestehen muss.
mit
IrDA
keine
Sichtverbindung zwischen
Aufgrund der freien Verfügbarkeit des ISM-Bandes musste man aber mit Störungen rechnen. So
wird dieses Frequenzband u.a. auch von den WLAN-Technologien IEEE 802.11b und 802.11g [10]
verwendet, aber auch Mikrowellenherde nutzen diesen Frequenzbereich. [Fers03b] Aus diesem Grund
verwendet Bluetooth das s.g. Frequenzsprungverfahren (Frequency Hopping), wobei durch einen
pseudozufälligen Frequenzwechsel von 1600 Mal pro Sekunde – das entspricht einem Intervall von 625µs
– die Robustheit gegenüber den meist festfrequenten Störungen erhöht wird. Innerhalb der verfügbaren
Bandbreite von 83,5 MHz sind 79 Kanäle mit einer Bandbreite von 1 MHz vorgesehen (Frankreich: 23
Kanäle).
Bluetooth erreicht eine Datenübertragungsrate von 1MBit/s, wobei das Gaussian Frequency Shift
Keying (GFSK)- Verfahren zum Einsatz kommt. Die maximale Reichweite bei einer Sendeleistung von 1
mW liegt bei 10 m, bei 100 mW beträgt sie rund 100 m.
Aufgrund der Idee, Bluetooth vor allem in mobile Geräte zu integrieren, wurden verschiedene
Stromsparzustände definiert, wodurch ein geringerer Stromverbrauch und somit eine längere Betriebszeit
erreicht wird.
- 21 -
Im Gegensatz zu anderen Funkstandards eignet sich Bluetooth sowohl für Daten- als auch
Sprachübertragung. Bluetooth ist somit die ideale Technologie für den Einsatz in Geräten, die Sprachund Datenübertragung benötigen – beispielsweise in Mobiltelefonen. Dementsprechend unterscheidet
Bluetooth auch zwei Arten physikalischer Verbindungen (Links), die zwischen einem Master und einem
Slave aufgebaut werden können [Merk02]:
Synchronous Connection Oriented (SCO) Link: Hauptsächlich zur Sprachübertragung
verwendet. Sie erlauben durch den Einsatz gleich großer Datenpakete in beide
Richtungen und direkt aufeinander folgenden Zeitschlitzen Vollduplex-Verbindungen.
Maximal drei solcher Verbindungen mit jeweils 64 kBit/s in beide Richtungen sind
möglich.
Asynchronous Connection Less (ACL) Link: Hauptsächlich zur Datenübertragung
verwendet. ACLs erlauben es dem Master – jener Einheit, die den Verbindungsaufbau
mit anderen Bluetooth-Geräten (den s.g. Slaves) initiiert hat – mehrere Slaves gleichzeitig
zu erreichen. Zur Erhöhung der Datenrate kann ein Paket auch drei oder fünf Zeitschlitze
umfassen, wobei zwischen den Zeitschlitzen die Frequenz nicht gewechselt wird. Bei
dieser asymmetrischen Übertragung können maximal 723,2 kBit/s in die eine und 57,6
kBit/s in die andere Richtung erreicht werden. Symmetrisch liegt das Maximum bei 433,9
kBit/s in beide Richtungen. [Schi03]
Bluetooth bietet zudem durch Authentifikation und Verschlüsselung sowie geringer Reichweite
und dem Einsatz von Frequency Hopping Sicherheit vor dem Zugriff Dritter (siehe dazu auch Kapitel
2.4.1 (Sicherheit und Verschlüsselung), die Pakete selbst werden durch fehlererkennende und –
korrigierende Codes gesichert. [Matt03]
2.1.2 Ad-hoc Netzwerke
Eine weitere wichtige Eigenschaft von Bluetooth ist dessen Fähigkeit, spontan, selbstständig und
ohne vorhandener Infrastruktur Netzwerke zu bilden; man spricht dabei von Ad-hoc Netzwerken.
Treten mindestens zwei Bluetooth-Einheiten miteinander in Verbindung, so können sie ein Ad-hoc
Netzwerk bilden, wobei per Definition jene Einheit, welche die Kommunikation initiiert hat, die Rolle
des Masters übernimmt; die restlichen Einheiten im Netzwerk werden als Slaves bezeichnet. Der Master
hat die Aufgabe, die Frequenzsprungfolge (Hopping Sequence) der Übertragung zu koordinieren und ist
für die Synchronisation der verschiedenen Teilnehmer zuständig. Ein Master kann mit bis zu 7 aktiven
und bis zu 255 geparkten Slaves kommunizieren. Ein solches Netzwerk wird bei Bluetooth als Piconetz
bezeichnet (siehe Abbildung 11a und Abbildung 11b). In einem Piconetz gibt es genau einen Master; die
Master-Slave-Beziehung ist auf Anwendungsebene aber meist irrelevant.
- 22 -
Abbildung 11: Piconetz mit einem Master und einem Slave (a), einem Master und mehreren Slaves (b) und
ein Scatternetz bestehend aus drei Piconetzen [BCOR01]
Die Bluetooth-Spezifikation unterscheidet verschiedene Zustände, in denen sich Bluetooth-Geräte
befinden können. Im Wesentlichen werden folgende Hauptzustände unterschieden:
Unconnected: Unterzustand Standby (Einheiten werden nicht zu Teilnehmern des
Piconetzes gezählt)
Connecting: Unterzustände Inquiry (Suche nach Bluetooth-Geräten, mit denen
Verbindung hergestellt werden kann) und Page (Verbindungsaufbau zu bestimmtem
Bluetooth-Gerät)
Connected: Unterzustände Active (Slave wartet auf Übertragungen von Master), Sniff
(Einheit wird nur periodisch aktiv und kann in dabei wie im Zustand Active arbeiten),
Hold (Slave kann für eine einstellbare Zeit seine gesamte Übertragungstätigkeit
einstellen) und Park (Slave hält Synchronisation mit Master aufrecht, ist aber nicht mehr
als aktiv einzustufen)
Die Zustände Sniff und Hold dienen der Reduktion der Stromaufnahme, der Zustand Park erlaubt
es außerdem dem Master, die Anzahl der Teilnehmer in einem Piconetz zu erhöhen. Eine genauere
Beschreibung der verschiedenen Zustände bzw. Zustandsübergänge sowie der Stromspar-Funktionen von
Bluetooth findet sich in den Kapiteln 2.2.2 (Baseband) und 2.4.2 (Stromsparfunktionen).
Möchten mehrere Gerätegruppen gleichzeitig aktiv sein, so kann jede dieser Gruppen ein eigenes
Piconetz aufbauen. In einigen Fällen kann es nötig sein, dass Bluetooth-Geräte aus verschiedenen, sich
überlappenden Piconetzen miteinander kommunizieren müssen. Hierfür wurde das s.g. Scatternetz
definiert, welches eine Kommunikation zwischen Piconetzen erlaubt (siehe Abbildung 11c und
Abbildung 12).
- 23 -
Abbildung 12: Scatternetz (M=Master, S=Slave, P=Parked, SB=Standby) [Schi03]
Dabei ist es Bluetooth-Einheiten möglich, an verschiedenen Piconetzen, die mit ihren
individuellen Frequenzsprungfolgen arbeiten, gleichzeitig teilzunehmen, wobei sie in einem Piconetz
Master oder Slave und in allen anderen Slave sein können. Es ist aber nicht möglich, dass eine Einheit in
mehreren Piconetzen die Rolle des Masters einnimmt.
Scatternetze haben auch den Vorteil, dass der durchschnittliche Gesamtdurchsatz erhöht werden
kann. [Merk02]
2.1.3 Der Bluetooth-Protokollstack
Ein Kernpunkt der Bluetooth-Spezifikation besteht darin, unterschiedlichen Geräten
unterschiedlicher Hersteller die Kommunikation zu ermöglichen. Erreicht wird dies durch die
Spezifikation eines Software-Protokollstacks, der es den Applikationen ermöglicht, andere BluetoothGeräte und Services zu finden und zu benutzen. Hauptaugenmerk bei der Entwicklung lag bei einer
weitestmöglichen Wiederverwendung bestehender Protokolle.
- 24 -
Anwendungen: Browser, Agenten, eMail, Adressbuch, Telefonie
vCard/vCal
WAE
OBEX
WAP
TCP
ATCommands
TCS Bin
SDP
UDP
IP
Software
PPP
Serial Cable Emulation (RFCOMM)
Audio
Logical Link Control & Adaptation (L2CAP)
Host Controller Interface
paketorientiert
Hardware
Link Manager (LMP)
leitungsorientiert
Baseband & Link Control (BB, LC)
Bluetooth Radio
Abbildung 13: Bluetooth Protokoll Stack [Lule01]
Abbildung 13 zeigt den Bluetooth Protokollstack, der folgende Elemente enthält:
Buetooth Radio (Luftschnittstelle): Stellt alle notwendigen Funktionen für die
physikalische Realisierung des Frequency Hoppings und des TDD (Time Division
Duplex; abwechselndes Senden und Empfangen der Geräte im gleichen Frequenzband)
bereit. [Merk02] Die genutzten Frequenzen, Modulationen und Sendeleistungen sind hier
spezifiziert. [Schi03]
Baseband (Basisband): Steuert den Radioteil und bereitet die Daten für die höheren
Schichten auf. Es verwaltet die physischen Kanäle und Verbindungen und ist für
Fehlerkorrektur und Festlegung der Sprungfolge des Piconetzes verantwortlich. [Merk02]
Verbindungsaufbau und Paketformate sind in dieser Schicht spezifiziert. [Schi01]
Link Manager Protocol, LMP (Verbindungsverwaltung): Zuständig für Verbindungsaufund -abbau sowie das Setzen der verschiedenen Stromsparmodi. Zudem übernimmt diese
Schicht Sicherheitsfunktionen wie Schlüsselidentifikation, Schlüsselgenerierung und
Schlüsseltausch.
Wie in Abbildung 13 zu erkennen ist, teilt HCI (Host Controller Interface) den Protokollstack in
zwei Hälften. Es ist ein Transport- und Kommunikationsprotokoll, welches die Schnittstelle zwischen
Bluetooth Controller (Hardware) und Bluetooth Host bildet. [Merk02] Beide Teile kommunizieren über
- 25 -
die einheitliche HCI-Schnittstelle, die eine Grundmenge an Funktionen für die Steuerung des Controllers
durch den Host bereitstellt.
Der Bluetooth-Host umfasst nun folgende Protokolle:
Logical Link Control and Adaption Protocol, L2CAP (Logische Verbindungssteuerung
und Anpassung): Ist für Multiplexen der Protokolle der höheren Schichten auf eine
asynchrone Verbindung (kein SCO erlaubt) zuständig. Es segmentiert und setzt die
Datenpakete (bis zu 64 kByte) wieder zusammen.
Service Discovery Protocol, SDP (Dienstfindung): Stellt einen Dienst zur Verfügung, mit
dessen Hilfe angebotene Dienste der Gegenstelle ermittelt werden können.
Radio Frequency Emulation of the Serial COM Ports, RFCOMM: Dies ist eine
Befehlssteuerung, die das RS-232 Protokoll über einen L2CAP-Kanal emuliert und bis zu
60 simultane Verbindungen zwischen Bluetooth-Modulen erlaubt. RFCOMM liegt der
ETSI-Standard TS 101.369 (GSM 07.10) [6] zugrunde, der bei GSM Verwendung findet.
Audio: Stellt logische Kanäle für die Übertragung von Audio und Sprache bereit.
Telephony Control Specification Binary, TCS BIN: Übernimmt telefonrelevante
Signalisierungsfunktionen für einen Verbindungsaufbau für Sprache und Daten und
basiert auf dem Standard ITU-T [7] Q.931 [8] für Signalisierung von
Telefonverbindungen. TCS BIN enthält eine Reihe von Signalkommandos, von
Gruppenmanagement und Signalisierung bis hin zu Verbindungsauf- und -abbau.
AT Commands: Zur Signalisierung der Telefonsteuerung; sie basieren auf dem ETSIStandard 300.916 (GSM 07.07) [6] für Mobiltelefonie. [Merk02] Telefonanwendungen
können die gewohnten AT-Kommandos wie bei einem herkömmlichen Modem einsetzen.
[Schi03]
Wireless Application Protocol, WAP: Ermöglicht den Mobilfunknetz-unabhängigen
Zugriff auf Informationen und Dienste des Internet mittels Mobiltelefon.
Wireless Application Environment, WAE: Stellt spezielle Umgebung für mobile Geräte
bereit.
UDP/TCP/IP/PPP: Diese Protokolle bilden die Grundlagen für die InternetKommunikation. [Merk02] Statt TCP/IP über PPP kann alternativ das effizientere
Bluetooth Network Encapsulation Protocol (BNEP) benutzt werden. [Schi03]
vCard/vCal: Stellen strukturierte Objekte in Form einer persönlichen Visitenkarte
(vCard) oder eines persönlichen Kalenders (vCal) dar.
OBject EXchange Protocol, OBEX: Ursprünglich von der Infrared Data Assicoation
(IrDA) [9] entwickelt, dient dem Austausch von Objekten wie beispielsweise vCard oder
vCal und unterstützt verschiedene Transportprotokolle und Medien. OBEX setzt vorerst
auf RFCOMM auf, geplant ist aber TCP/IP als spätere Grundlage. [Kral03] [Merk02]
- 26 -
Eine genauere Beschreibung der Protokolle findet sich in Kapitel 2.2 (Protokollstack Teil 1 –
Bluetooth Modul) und 2.3 (Protokollstack Teil 1 – Bluetooth Modul)
2.1.4 Bluetooth Profile
Die Schichten im Protokollstack definieren die exakten technischen Spezifikationen der einzelnen
Komponenten eines Bluetooth Moduls, eine darauf basierende Implementierung wird die grundsätzlichen
technischen Eigenschaften erfüllen. Allerdings bleibt dadurch noch eine Reihe von Fragen zum Verhalten
von Bluetooth-Geräten untereinander offen. So spezifiziert der Bluetooth-Stack beispielsweise nicht,
wann und wie oft ein Gerät den Inquiry-Modus einnimmt, um selbst nach anderen Geräten zu suchen.
Um nun solche Interoperabilitätsprobleme zwischen Geräten unterschiedlicher Hersteller zu
minimieren, wurden zu grob umrissenen Anwendungsszenarien entsprechende Nutzungsanweisungen für
die einzelnen Schichten in den s.g. Profilen beschrieben. [Lule01] Jedes der Profile legt die benötigten
Protokolle für eine bestimmte Art von Anwendung fest [Merk02]; Profile sind gewissermaßen vertikale
Schnitte durch den Bluetooth-Protokollstack. [Matt03]
Diese Bildung von Profilen ist Teil des Interoperabilitäts-Pakets, das von der Bluetooth SIG
geschnürt wurde, um möglichst große Interoperabilität zwischen den Geräten unterschiedlicher Hersteller
weltweit sicherzustellen. Jedes Bluetooth-Gerät unterstützt eine Untermenge der mittlerweile 26 Profile.
[Lule01]
Die Struktur der Profile, ihre Abhängigkeiten untereinander sowie eine genaue Beschreibung der
einzelnen Profile findet sich in Kapitel 2.5 (Bluetooth-Profile).
2.2
Protokollstack Teil 1 – Bluetooth Modul
2.2.1 Bluetooth Radio (Luftschnittstelle)
Bluetooth Radio ist die unterste Schicht im Protokollstack und bezeichnet die Luftschnittstelle,
welche alle notwendigen Funktionen für die physikalische Realisierung des Frequency Hoppings und des
TDDs bereitstellt.
Für den Frequenzbereich von Bluetooth ist das ISM-Band von 2,400 bis 2,4835 GHz vorgesehen,
welches somit eine Bandbreite von 83.5 MHz umfasst. Die Bestimmungen für dieses Frequenzband sind
im ETSI-Dokument ETS 300.328 festgehalten, und werden von Bluetooth besser erfüllt als verlangt.
- 27 -
Bluetooth verwendet 79 Trägerfrequenzen bzw. Kanäle, welche bei 2402 + k MHz liegen (k = 0
bis 78); der erste Kanal sendet also auf der Frequenz 2402 MHz, der nächste Kanal bei 2403 MHz usw.
Um Interferenzen mit benachbarten Funksystemen zu vermeiden, ist sowohl ein unteres (2,400 bis 2,402
GHz) als auch ein oberes Schutzband (2,480 bis 2,4835 GHz) vorgesehen. Aus lizenzrechtlichen Gründen
bildet Frankreich mit 23 Trägerfrequenzen eine Ausnahme, wo nur das ISM-Band von 2,4465 bis 2,4835
GHz verwendet werden kann, wobei das obere und untere Schutzband jeweils 7,5 MHz breit sind.
Bluetooth-Geräte mit unterschiedlichen Hopping-Algorithmen (23 oder 79 Trägerfrequenzen) sind
untereinander nicht kompatibel.
Als Modulationsverfahren kommt GFSK (Gaussian Frequency Shift Keying) zum Einsatz. Dabei
wird – im Gegensatz zum reinen FSK – das binäre (Rechteck)-Signal mittels Tiefpass-Filter mit
gaußförmiger Filtercharakteristik gefiltert bevor es dem Frequenzmodulator zugeführt wird, was zu
weichen Übergängen zwischen den Bits und somit zu einer Bandbreitenreduktion gegenüber FSK führt.
Eine binäre „1“ wird durch eine positive, eine binäre „0“ durch eine negative Frequenzabweichung fd der
Trägerfrequenz fT übertragen, wobei fd zwischen 140 kHz und 175 kHz liegen muss. [Merk02]
Der wesentliche Vorteil, der sich aus der GFSK-Modulation ergibt, liegt vor allem darin, dass sie
relativ unempfindlich gegenüber Rauscheinflüsse ist, da diese die Amplitude und nicht die Frequenz der
elektromagnetischen Welle beeinflussen. [Rech02]
Die Sende- und Empfängereigenschaften sind für die erzielbaren Reichweiten der BluetoothGeräte bei ausreichender Übertragungsqualität ausschlaggebend. Die Sendeleistung ist in folgende drei
Klassen eingeteilt:
Leistungsklasse 1: Max. Ausgangsleistung von 100 mW (20 dBm), max. Reichweite von
100 m
Leistungsklasse 2: Max. Ausgangsleistung von 2,5 mW (4 dBm), max. Reichweite von 20
m
Leistungsklasse 3: Max. Ausgangsleistung von 1 mW (0 dBm) , max. Reichweite von 10
m
Die Leistung L in dBm errechnet sich mit
L 10 log10 P
1mW
, wobei P die
Ausgangsleistung in mW ist. Die Sendeleistung ist zudem regelbar, um die Stromaufnahme zu
reduzieren. Mehr dazu findet sich in Kapitel und 2.4.2 (Stromsparfunktionen).
Die Empfänger-Empfindlichkeit gibt die Leistung des hochfrequenten Signals am Eingang des
Empfängers an, die erforderlich ist, um an dessen Ausgang die Nachricht mit ausreichender Güte einer
Senke zur Verfügung stellen zu können. Bei Bluetooth wird als Gütemaß die Bit Error Rate (BER)
- 28 -
herangezogen, wobei die Spezifikation für eine BER < 0,1% eine Empfänger-Empfindlichkeit von -70
dBm (das entspricht einem Eingangssignal mit 100 pW) erfordert.
Bei Bluetooth wird ein Frequency Hopping Spread Spectrum (FHSS)-Verfahren verwendet, wobei
das Nutzsignal über sich permanent abwechselnde Trägerfrequenzen übertragen wird. [Merk02] Es sind 5
verschiedene Sprungfolgen spezifiziert, wobei die ersten vier für Inquiry und Paging verwendet werden
und aus fest vorgegebene Sequenzen aus jeweils 32 Frequenzen bestehen. Für die eigentliche
Datenübertragung wird aus der Geräteadresse des Masters eine Sprungfolge aus allen 79 Frequenzen
errechnet.
Im normalen Betrieb wechselt die Kanalfrequenz 1600 mal pro Sekunde, im Suchbetrieb (Inquiry
oder
Paging)
doppelt
so
schnell.
Damit
ist
jeder
Zeitabschnitt
im
normalen
Betrieb
1 s 1600 hops/s 625 s lang, nach Ablauf dieser Zeit wechselt die Frequenz wieder. Die
Frequenzfolge wiederholt sich im Datenübertragungsmodus alle 23.302 h von neuem. [Lule01]
Diese Frequenzsprünge wirken wie eine Art Verschlüsselung, da sie das Abhören einer solchen
Übertragung enorm erschweren. Vor allem aber erlaubt das FHSS-Verfahren den gleichzeitigen Betrieb
mehrerer Piconetze im selben räumlichen Überdeckungsbereich; obwohl es zu einzelnen Kollisionen
kommen wird (wenn mehrere Piconetze auf derselben Frequenz kommunizieren), erhöht sich der
durchschnittliche Gesamtdurchsatz. Das FHSS-Verfahren erweist sich bei schmalbandigen Störungen
auch als sehr robust, da der gestörte Frequenzbereich nur kurz benutzt wird (siehe dazu Abbildung 14).
[Merk02]
- 29 -
2480
MHz
2470
HomeRF-Paket: 50 Hops/sec.
2460
Frequenz
2450
2440
2430
2420
Bluetooth-Paket: 1600 Hops/sec.
2410
2400
0
2
4
Zeit
6
8
ms
10
Abbildung 14: Kollision zwischen Bluetooth und HomeRF [Lule01]
Als Vielfachzugriffsverfahren findet bei Bluetooth das Time Division Duplex (TDD)- Verfahren
Verwendung, was bedeutet, dass die Geräte abwechselnd senden und empfangen. Die Übertragung wird
entsprechend der Hopping-Frequenz in Zeitschlitze zu je 625 µs unterteilt. [Merk02] Abbildung 15
veranschaulicht diesen Sachverhalt, wobei zu erkennen ist, dass Master und Slave mit jedem Zeitschlitz
gemeinsam ihre Frequenz ändern.
Abbildung 15: Einteilung der Zeitschlitze [BCOR01]
- 30 -
Die Spezifikation sieht aber auch s.g. Multislot-Pakete vor, die drei oder fünf Zeitschlitze in
Anspruch nehmen. Während dieser Zeit erfolgt kein Frequenzsprung; anschließend wird auf diejenige
Frequenz gesprungen, die aus zeitlicher Sicht folgt.
Abbildung 16: Einteilung der Zeitschlitze bei Multislot-Paketen [BCOR01]
An obigen Grafiken ist auch zu erkennen, dass die effektive Nutzdatenrate deutlich unter der
Brutto-Datenrate von 1 MBit/s liegt, da zeitliche Puffer an den Frequenzübergängen notwendig sind, in
denen keine Daten übertragen werden können, und zudem noch Verwaltungsdaten anfallen. [Lule01]
Für eine bestmögliche Übertragung von Sprache und Daten definiert die Bluetooth-Spezifikation
zwei Arten physikalischer Verbindungen:
Synchronous Connection Oriented (SCO) Link
Asynchronous Connection Less (ACL) Link
Ein SCO-Link stellt eine synchrone verbindungsorientierte Verbindung dar, wobei zwischen
Master und Slave in einer Punkt-zu-Punkt-Verbindung kommuniziert wird. Durch die vom Master
exklusiv reservierten Zeitschlitze sind zeitkritische Übertragungen (meist Sprachübertragungen) möglich,
ein wiederholtes Senden von SCO-Paketen ist nicht vorgesehen. Ein Slave kann maximal drei SCO-Links
zu einem einzigen und zwei SCO-Links zu unterschiedlichen Mastern verwalten.
Ein ACL-Link ist das Gegenstück zum SCO-Link und bietet daher eine asynchrone
verbindungslose Verbindung, wobei zwischen dem Master und allen piconetzbildenden Slaves in einer
Punkt-zu-Multipunkt-Verbindung kommuniziert wird. Dafür verwendet der Master die restlichen
Zeitschlitze, die noch nicht für SCO-Links bestimmt sind. Der Master kann mittels ACL-Links beliebige,
am Piconetz beteiligte Slaves ansprechen, zwischen einem Master und einem Slave kann jedoch nur ein
- 31 -
einziger ACL-Link existieren. Verlorengegangene Pakete werden im Gegensatz zu SCO-Links
wiederholt gesendet.
Ein einziger Master kann mehrere Verbindungen halten, die aus einer ACL- und SCOKombination bestehen. [Merk02] Abbildung 17 zeigt die eine Kombination von SCO- und ACL-Links in
einem Piconetz.
SCO
ACL
SCO
ACL
ACL
SCO
ACL
SCO
Master
Slave 1
Slave 2
625 µs
Zeit
Slave 3
Abbildung 17: Datenübertragung in einem Piconetz [Lule01]
2.2.2 Baseband (Basisband)
Diese Schicht steuert die Hardware und ist für die Weitergabe der Daten an höhere
Systemkomponenten verantwortlich. Es setzt auf der Radio- Schicht auf und ist im Link Controller
implementiert. Diese Schicht ist für die Steuerung der physikalischen Funkverbindung, das Packen und
Entpacken der Datenpakete, Festlegen der Frequenzsprungfolge, Fehlerkorrektur, Datentransfer,
Verwaltung der (logischen) Verbindungen, Adressierung sowie Authentisierung, Authorisation und
Verschlüsselung (siehe dazu Kapitel 2.4.1, Sicherheit und Verschlüsselung) verantwortlich.
2.2.2.1
Paketaufbau und -arten
Die Daten eines Piconetz-Kanals werden zerteilt und in Pakete verpackt, die in drei Bereiche
unterteilt sind (siehe Abbildung 18). Die Bit-Reihenfolge richtet sich nach dem Little-Endian-Format,
was bedeutet, dass das Least Significant Bit (LSB) zuerst gesendet wird.
- 32 -
Abbildung 18: Paket-Format [Schi03]
Zugriffscode und Paketkopf haben feste Größen von 72 (bzw. 68) und 54 Bit, die Nutzlast kann in
der Größe von 0 bis 2745 Bit variieren und somit auch entfallen. [Merk02]
Zugriffscode (Access Code)
Der Zugriffscode (Access Code) ist 72 Bit groß und dient zur Synchronisation und
Gleichspannungskompensation, wird aber hauptsächlich zur Identifikation benutzt. Alle Pakete, die
innerhalb eines Piconetzes gesendet werden, haben den gleichen Access Code; die teilnehmenden
Bluetooth-Geräte überprüfen diesen und ignorieren den Rest des Paketes, falls er für das Gerät ungültig
ist.
Die Präambel besteht aus einer Sequenz von 4 alternierenden Bits und wird zur
Gleichspannungskompensation benutzt. Das Sync-Word ist ein 64 Bit-Wort und wird vom 24 Bit großen
niederwertigen Adressteil einer Bluetooth Device Address (LAP, siehe Kapitel 2.2.2.4) abgeleitet.
Der Trailer besteht wie die Präambel auch aus alternierenden Nullen und Einsen und erfüllt
denselben Nutzen. Ein Trailer wird nur dann angehängt, wenn nach dem Access Code ein Header folgt;
ansonsten ist der Access Code nur 68 Bit groß.
Es gibt verschiedene Arten von Access Codes:
Channel Access Code (CAC): Identifiziert zugehöriges Piconetz
Device Access Code (DAC): Für spezielle Signalisierungen
Inquiry Access Code (IAC): Für die Erkennung von in Reichweite liegenden weiteren
Geräten. Dieser Code splittet sich wiederum in den General Inquiry Access Code (GIAC),
der zur Suche nach allen in Reichweite befindlichen Bluetooth-Geräte benutzt wird, und
den Dedicated Inquiry Access Code (DIAC) auf, der nur für die Suche nach Geräten mit
bestimmten Merkmalen verwendet wird.
[Merk02]
- 33 -
Paketkopf (Header)
Der Header enthält wichtige Steuerinformationen für eine Verbindung und hat zusammen mit der
Fehlerkodierung (HEC) eine Größe von 18 Bit, welche aber durch die 1/3 Rate Forward Error Correction
(FEC) auf 54 Bit verdreifacht wird.
Der Header besteht aus folgenden Feldern:
AM-Adresse: Sie ist 3 Bit groß und wird zur Identifikation und Unterscheidung zwischen
den aktiven Slaves benutzt. Da die Adresse „000“ für Broadcasts verwendet wird, wird
die Anzahl der aktiven Slaves auf 2³-1=7 reduziert.
Typ: Durch dieses 4 Bit große Feld werden die 16 verschiedenen Paketarten
unterschieden.
Fluss: Wirkt als Flusssteuerungsbit bei ACL-Paketen. Der Empfänger signalisiert mit
einem Flow-Bit von „0“, dass sein Empfangspuffer voll ist; nach dem Leeren des Puffers
wird FLOW wieder auf „1“ gesetzt.
ARQN: Dient zur Empfangsbestätigung (ARQN = „1“, wenn Paket erfolgreich
empfangen wurde, „0“ sonst)
SEQN: Liefert sequenzielles Nummernschema zur Ordnung der Daten im Datenstrom
bzw. zur Erkennung verlorener Pakete.
HEC: Jeder Header beinhaltet einen 8 Bit großen CRC-Code, den s.g. Header Error
Check (HEC), womit der fehlerfreie Empfang des Headers festgestellt werden kann.
[Merk02]
Paketarten
Folgende Kontrollpakete – sie belegen jeweils nur maximal einen Zeitschlitz zu 625 µs – werden
unterschieden:
Identifikationspaket (ID-Paket): Enthält nur den Device Access Code (DAC) oder den
Inquiry Access Code (IAC). Das Paket wird in Paging-, Inquiry- und Response-Routinen
benutzt. Seine Länge beträgt 68 Bit.
Nullpaket (NULL Packet): Enthält den Access Code und einen Paketkopf, aber keine
Nutzlast. Seine Länge beträgt 126 Bit und es dient der Übermittlung von
Empfangsbestätigungen (ARQN) oder des Empfangspuffer-Status (FLOW). Nullpakete
erfordern keine Empfangsbestätigung.
Umfragepaket (POLL Packet): Entspricht dem NULL-Paket, erfordert aber eine
Empfangsbestätigung. Es wird vom Master an die Slaves geschickt, um diese
anzusprechen und ihnen die Möglichkeit zu geben, Daten zu versenden.
- 34 -
Frequency Hopping Sequence Paket (FHS Packet): Enthält alle Daten, die für einen
Verbindungsaufbau mit dem Sender benötigt werden. Es wird zur Beantwortung von
Page- oder Inquiry-Paketen, bei einem Master/Slave-Rollentausch sowie zur
Synchronisation der Frequenzsprünge (bevor Piconetz aufgebaut wurde oder ein
bestehendes in ein neues übergeht) verwendet.
Paket für Daten mittlerer Geschwindigkeiten (DM1-Packet): Wird für
Steuerinformationen verwendet, kann aber auch Nutzdaten enthalten. [Merk02] [Lule01]
In SCO-Verbindungen gibt es nur Pakete die maximal einen Zeitschlitz belegen, der dafür fest
reserviert ist ( synchrone Verbindung). [Lule01] Sie enthalten auch keinen CRC-Code; geht ein Paket
verloren oder kommt es fehlerhaft beim Empfänger an, wird es auch nicht neu übertragen, da dies für
Audioübertragung weniger wichtig ist. [Merk02] Von den vier definierten Pakettypen gibt es drei, die nur
synchrone Daten enthalten (High Quality Voice, HV) und einen, der zu einem Drittel aus synchronen
Voice-Daten und zwei Dritteln aus zeitlich flexiblen, aber fehlersensitiven asynchronen Daten besteht
(Data Voice, DV). [Merk02] Abbildung 19 zeigt die vier Pakettypen:
HV1-Paket: Ein HV1-Paket ist mit einem 1/3 FEC geschützt und überträgt 1,25 ms
Sprache bei 64 kBit/s und wird in jedem zweiten Zeitschlitz übertragen.
HV2-Paket: Ein solches Paket ist mit einem 2/3 FEC geschützt und überträgt 2,5 ms
Sprache bei 64 kBit/s und wird in jedem vierten Zeitschlitz übertragen.
HV3-Paket: HV3-Pakete sind durch keinen Code geschützt und können somit 240 Bit
Nutzdaten übertragen. Ein HV3-Paket überträgt 3,75 ms an Sprache bei 64 kBit/s in
jedem sechsten Zeitschlitz.
DV-Paket: Dieses Paket ist eine Kombination aus Daten- (80 Bit) und Sprachpaket (bis
zu 150 Bit). Der Audio-Teil wird mit einer Vorwärtsfehlerkorrektur (2/3 FEC) geschützt,
der Daten-Anteil hingegen wird solange mit jedem neuen DV-Paket mitgeschickt, bis
diese Daten vom Empfänger als fehlerfrei quittiert wurden.
- 35 -
Abbildung 19: SCO-Pakete [Schi03]
Für die Übertragung auf einem asynchronen Link wurden sieben ACL-Pakete spezifiziert, wobei
sechs davon eine CRC-Paritätsprüfung enthalten und bei nicht korrigierbaren Fehlern neu übertragen
werden können. ACL-Pakete unterscheiden sich im Wesentlichen in der Stärke der
Vorwärtsfehlerkorrektur sowie in der Anzahl der belegten Zeitabschnitte pro Paket. [Lule01] Abbildung
20 zeigt die verschiedenen Pakettypen:
DM (Data-Medium Rate)-Pakete: DM-Pakete werden durch eine 2/3 FEC geschützt und
können einen, drei oder fünf Zeitschlitze (DM1, DM3 oder DM5) belegen. Pakete über
mehrere Zeitschlitze profitieren von den eingesparten Verwaltungsdaten (Paketkopf und
Zugriffscode werden nur einmal übertragen) und dem fehlenden Overhead durch einen
Frequenzwechsel, wobei die Frequenz über die volle Paketlänge konstant bleibt.
DH (Data-High Rate)-Pakete: DH-Pakete (DH1, DH3 oder DH5) werden durch keine
Vorwärtsfehlerkorrektur geschützt, können dafür aber in der gleichen Zeit entsprechend
mehr Daten übertragen als DM-Pakete ( High Rate).
AUX1-Paket: Ähnelt dem DH1-Paket, hat aber keinen CRC-Code. [Merk02]
- 36 -
Abbildung 20: ACL-Pakete [Schi03]
2.2.2.2
Logische Kanäle
Der Bluetooth-Stack besteht aus unterschiedlichen Schichten, die miteinander kommunizieren.
Damit beispielsweise der Link Manager eines Bluetooth-Gerätes mit dem eines anderen kommunizieren
kann, bedarf es logischer Kanäle, die aber alle den einzig vorhandenen physischen Kanal als Träger
nutzen. Abbildung 21 verdeutlicht dieses Prinzip.
Folgende fünf logische Kanäle werden unterschieden:
Link Control (LC) Steuerungskanal: Dient der Verbindungssteuerung, unter anderem der
automatischen Paketwiederholung (ARQ), der Datenflusssteuerung (FLOW) und der
Nutzlast-Charakterisierung (Payload Type). Übermittelt werden diese Daten im
Paketkopf.
Link Manager (LM) Steuerungskanal: Trägt Steuerungsinformationen zwischen den
beteiligten Link Managern eines jeden Bluetooth-Gerätes und regelt den Verbindungsaufund -abbau sowie eine eventuelle Verschlüsselung. Übermittelt werden diese Daten i.d.R.
in geschützten DM-Paketen.
- 37 -
User Asynchronous (UA) / User Isochronous (UI) Nutzdatenkanal: Transportiert
asynchrone bzw. isochrone (zeitkritische) Nutzdaten, die von der höheren
Protokollschicht L2CAP gesendet und empfangen werden. Da die von L2CAP
kommenden Pakete größer sein können als der gerade benutzte Datenpaket-Typ, müssen
die Pakete auf der Empfängerseite wieder zusammengesetzt werden.
User Synchronous (US) Nutzdatenkanal: Trägt synchrone Datenpakete einer SCOVerbindung.
[Merk02]
Bluetooth Gerät 1
Bluetooth Gerät 2
L2CAP
L2CAP
Logischer Kanal (UA, UI oder US)
Link Manager
Logischer Kanal (LM)
Link Manager
Link Controller
Logischer Kanal (LC)
Link Controller
Physikalischer
Kanal
Paketbestandteile
Zugriffscode
Paketkopf
Nutzlast
Abbildung 21: Logische (virtuelle) Kanäle zwischen Bluetooth-Geräten [Lule01]
2.2.2.3
Scrambling und Fehlerkorrektur
Da Funkkanäle sehr störungsempfindlich sind, definiert die Bluetooth-Spezifikation folgende
Fehlerkorrekturmechanismen, wobei nur der Paketkopf immer geschützt wird (HEC), da er wichtige
Verbindungsinformationen mit sich führt.
1/3 Rate FEC (Forward Error Correction): Jedes gesendete Bit wird dreimal
hintereinander wiederholt.
2/3 Rate FEC: Jeweils 10 Informationsbits werden mit 5 Bit Fehlerkorrekturcode zu
einem 15 Bit Codewort erweitert, wobei sich eine Hamming-Distanz (minimaler
paarweiser Bitunterschied zwischen allen Nutzworten eines Codes) von 4 ergibt.
- 38 -
ARQ-Schema für Daten: Sicherung, die für eine wiederholte Übertragung fehlerhafter
oder nicht empfangener Pakete sorgt; die Pakete werden solange gesendet, bis der Sender
eine positive Bestätigung vom Empfänger erhält.
HEC (Header Error Control) / CRC (Cyclic Redundancy Check)- Codierung: In der
Bluetooth-Spezifikation werden sowohl eine 8 Bit CRC (im Header, HEC) als auch eine
16 Bit CRC (für Nutzdaten, nach CRC-CCITT) genutzt.
Da die spektrale Leistungsverteilung breitbandiger Datensignale von der Struktur der Daten
abhängt und daher sehr unregelmäßig sein kann, kommen s.g. Scrambler (Verwürfler) zum Einsatz.
Durch eine Modulo-2-Addition der Daten mit einem Pseudorauschcode werden eine
Gleichspannungskompensation sowie eine einfache Verschlüsselung erreicht. Beim Descrambling
(Wiederherstellung der Daten) auf der Empfängerseite werden die verwürfelten Daten erneut mit
demselben Pseudorauschcode addiert. [Merk02]
2.2.2.4
Adressierung
Jedes Bluetooth-Gerät besitzt eine weltweit eindeutige 48 Bit große Geräteadresse, die Bluetooth
Device Address (BD_ADDR), die im ROM-Speicher des Bluetooth-Moduls gespeichert ist und auch als
MAC-Adresse bezeichnet wird. Sie besteht aus einem 24 Bit großen unteren Adressteil (LAP, Lower
Address Part), der eine herstellerspezifische Identifikationsnummer enthält, einem 8 Bit großen oberen
Adressteil (UAP, Upper Address Part), der eine firmeninterne Nummer enthält sowie einem 16 Bit
großen unbedeutenden Adressteil (NAP, Non-significant Address Part). [Merk02] Der LAP wird vom
Bluetooth-Gerätehersteller vergeben, UAP und NAP bilden die Hersteller-Identifikation, die von der
IEEE vergeben wird. [Hand03]
Nicht-signifikanter
Adressteil
Oberer
Adressteil
Unterer Adressteil
16 Bit
8 Bit
24 Bit
Abbildung 22: Bluetooth Geräteadresse (BD_ADDR) [Lule01]
Jeder aktive Slave in einem Piconetz besitzt eine 3 Bit große Active Member Address
(AM_ADDR), die er vom Master bei der Aktivierung zugeordnet bekommt; der Master selbst hat keine
AM_ADDR. Ein Slave akzeptiert nur Pakete, die an seine AM_ADDR oder die vollständig aus Nullen
bestehende Broadcast-AM_ADDR gesendet werden.
- 39 -
Ein Slave im Park-Zustand kann anhand seiner 8 Bit großen Parked Member Address
(PM_ADDR) identifiziert werden. Wechselt er wieder in einen aktiven Zustand, so verliert er die
PM_ADDR und es wird ihm eine AM_ADDR zugewiesen.
Zusätzlich zur PM_ADDR wird einem Slave beim Übergang in den Park-Zustand die Access
Request Address (AR_ADDR) zugewiesen, die aber für einen Slave nicht eindeutig sein muss. Sie wird
benutzt, damit dieser den Zeitschlitz erkennen kann, in dem es ihm erlaubt ist, Access-RequestNachrichten zu senden. [Merk02] [BCOR01]
2.2.2.5
Funkkanal-Management
Der Master, das ist jene Einheit welche die Verbindung zu einem oder mehreren Slaves initiiert,
bestimmt die Frequenzsprungfolge und den Channel Access Code (CAC). Er hat immer die volle
Kontrolle über das Piconetz, da Slaves Daten ausschließlich mit dem Master austauschen können. Da die
Bluetooth-Einheiten identisch sind, kann jedes Gerät selbst ein Piconetz initialisieren; dieses Gerät ist
dann selbst Master und kann die Slaves kontrollieren und die Timer synchronisieren.
Abbildung 23: Slaves in Piconetz synchronisieren sich mit Uhr des Masters [Schi03]
Um die Sprungfolge des Senders bestimmen zu können, hat jede Bluetooth-Einheit eine interne
Systemzeit, die aber keinen Bezug zur Tageszeit hat. Baut ein Master eine Verbindung auf, so addieren
diese einen Offset zu ihrer eigenen Systemzeit, um synchron mit dem Master zu laufen (siehe Abbildung
23).
- 40 -
Für Bluetooth-Geräte sind verschiedene Zustände definiert (siehe dazu auch Kapitel 2.1.2, Ad-hoc
Netzwerke), wobei die Hauptzustände Standby und Connected sind. Die wichtigsten Zustände sind in
Abbildung 24 zu sehen.
Standby: Geräte, die an keinem Piconetz teilnehmen aber eingeschaltet sind, befinden
sich im Bereitschaftszustand Standby. In diesem Zustand wird nur die interne Uhr weiter
betrieben, weshalb die Stromaufnahme sehr gering ist. [Merk02] Es gibt zwei Gründe,
den Parkzustand zu verlassen und in den Erkundigungszustand Inquiry überzugehen:
Entweder das Gerät möchte selbst ein Piconetz gründen oder es möchte erkunden, ob
bereits eine Kommunikation im Gange ist [Schi03] (dafür wird alle 1,28 sec nach ev.
Netznachrichten gesucht).
Inquiry: In diesem Zustand wird nach Bluetooth-Geräten gesucht, mit denen eine
Verbindung hergestellt werden kann. Der Übergang vom Zustand Standby nach Inquiry
dauert ungefähr 2 sec.
Page: Hierbei wird versucht, eine Verbindung zu einem bereits erfassten Bluetooth-Gerät
herzustellen.
Connected: In diesen Zustand geht die Bluetooth-Einheit nach dem erfolgreichen Masterund Slave-seitigen Verbindungsaufbau über. [Merk02] Die Slaves sind an die
Sprungfolge des Piconetzes angepasst [Schi03], überprüfen permanent den Funkkanal auf
Pakete mit passender Zieladresse und antworten gegebenenfalls. Unterzustände sind die
Stromspar-Modi Park, Hold
Stromsparfunktionen). [Lule01]
und
Sniff
(siehe
dazu
auch
Kapitel
2.4.2,
Park: Das Bluetooth-Gerät verliert seine AM_ADDR und bekommt statt dessen eine
PM_ADDR. Es ist damit immer noch Mitglied des Piconetzes, macht aber Platz für ein
anderes aktives Gerät; es kann maximal 7 aktive, aber bis zu 255 passive Mitglieder
geben. Geparkte Geräte sind immer noch bzgl. der Sprungfolge synchronisiert. [Schi03]
Ein geparkter Slave ist passiv, da er nur dem periodischen Funkfeuer des Masters zur
Synchronisation lauscht, mangels eigener AM_ADDR aber nicht sofort an einer
Kommunikation teilnehmen kann. Ein Slave kann sowohl durch den Master durch
Zusenden einer gültigen AM_ADDR an seine PM_ADDR aktiviert werden, aber auch
durch Senden einer Access Request-Nachricht zum Master eine Wiederaufnahme in den
aktiven Zustand beantragen. [Lule01] [Merk02]
Hold: In diesem Zustand behält das Bluetooth-Gerät die AM_ADDR, beendet jedoch
ACL-Übertragungen; SCO-Pakete werden weiterhin übertragen. [Schi03] Nach Ablauf
der Hold-Zeit synchronisiert sich der Slave automatisch wieder mit dem Netzverkehr und
wartet auf an ihn adressierte Pakete des Masters. [Lule01] Der Hold-Modus kann vom
Master erzwungen werden, der Slave kann den Master aber auch auffordern, ihn in diesen
Zustand zu schalten.
- 41 -
Sniff: Im „Schnüffel“-Zustand hört das Gerät in frei wählbaren, periodischen Abständen
in das Piconetz; auch hier läuft der Timer zur Synchronisation weiter.
[Merk02]
Abbildung 24: Bluetooth Basisband Zustände [Schi03]
2.2.2.6
Verbindungsaufbau
Wird ein Bluetooth-Gerät eingeschaltet, befindet es sich im Bereitschaftszustand ( Standby) und
hat damit noch keine Verbindung zu anderen Geräten. In einem ersten Schritt versucht es nun, andere
Geräte in Kommunikationsreichweite zu finden, indem es für eine bestimmte Zeit auf verschiedenen
Frequenzen den Datenverkehr abhört ( Inquiry Scan). Umgekehrt versendet jedes Gerät periodisch
Inquiry-Pakete ( Inquiry), wodurch ein suchendes Gerät eine Liste von Geräteadressen der erreichbaren
Geräte erhält. Für die eigentliche Kontaktaufnahme hört das Gerät wiederum auf verschiedenen
Frequenzen den Datenverkehr ab ( Page Scan) und baut eine Verbindung auf, sobald es von einem
anderen Gerät ein Page-Paket mit der eigenen Geräteadresse erhält ( Page); das Gerät, das die
Nachricht erhält, wird Slave, das andere Gerät wird Master. Ab diesem Zeitpunkt geht die Initiative für
weitere Verbindungsaufnahmen nur noch vom Master aus. Ist ein Gerät nun mit dem Piconetz verbunden,
befindet es sich im aktiven Zustand Connected oder in einem der drei Stromsparzustände Sniff, Hold oder
Park. [Roth02]
Welches Gerät Inquiry und welches den komplementären Inquiry Scan durchführt, muss für jede
Anwendung im jeweils verwendeten Profil geklärt werden. Häufig ist es sinnvoll, dass eher stationär
- 42 -
aufgestellte Geräte periodisch Inquiry Scan und Page Scan durchführen, während die mobilen
Gegenstücke entweder manuell oder auch periodisch Inquiry- bzw. Page- Rufe aussenden, weil damit die
Belastung der Funkschnittstelle mit unnötig vielen Suchsignalen reduziert wird; nachteilig ist aber der
dadurch höhere Strombedarf der mobilen Geräte. [Lule01] Im Folgenden werden die Zustände Page,
Page Scan, Inquiry und Inquiry Scan noch genauer betrachtet.
Standby
Master hat
Geräte Adresse
des Slave
Page
Master hat
Slave
Response
erhalten
Master sucht
nach Slaves
Slave horcht
auf seine
Geräte
Adresse
Page Scan
Fehler
Master
Response
Slave
antwortet
auf Page
Fehler
Slave horcht
auf GIAC
Inquiry Scan
Slave hat
Inquiry
detektiert
Slave
Response
Inquiry
Slave hat
auf Inquiry
geantwortet
Inquiry
Response
Verbindung
hergestellt
Connected
Master sucht
nach Slaves
Abbildung 25: Link Controller Zustandsdiagramm [Lule01]
Das ausgesendete Inquiry Signal besteht aus einem generischen ID-Paket, das den allgemeinen
Zugriffscode (GIAC) enthält, der für alle Bluetooth-Geräte gleich ist; das ID-Paket enthält keinerlei
Information über den Sender, der damit anonym bleibt. [Lule01] Dieser Zugriffscode wird nacheinander
über 32 standardisierte Trägerfrequenzen (Wake-Up Carriers) ausgesendet. Anschließend horcht das
suchende Gerät auf Antworten von in Reichweite befindlichen Geräten.
Im Zustand Inquiry Scan wartet der Empfänger in einem bestimmten Zeitfenster auf ID-Pakete,
die den passenden Zugriffscode enthalten. Wird ein Inquiry entdeckt, so kann – nach Verstreichen einer
zufälligen Zeit, um zu vermeiden, dass viele Geräte gleichzeitig antworten – in den Unterzustand Inquiry
- 43 -
Response gewechselt und nach Erhalt eines weiteren ID-Pakets ein Frequency Hopping Sequence (FHS)Paket mit den eigenen Parametern zurückgeschickt werden. [Merk02] [Schi03].
Der Page-Ruf eines Gerätes dient der Initiierung einer Verbindung (dieses Gerät ist damit
automatisch Master im Piconetz) und er besteht aus einem ID-Paket mit dem Geräte-Zugriffscode (DAC)
der anderen Bluetooth-Einheit, welcher aus deren Geräteadresse berechnet wurde. [Lule01]
Ein Gerät im Zustand Page Scan ( Slave) verhält sich ähnlich wie im Inquiry Scan, mit dem
Unterschied, dass es auf ID-Pakete mit dem eigenen DAC wartet. Nach Erhalten eines solchen Pakets
wird sofort in den Unterzustand Slave Response gewechselt und mit einem Acknowledge geantwortet.
Der Master geht in den Zustand Master Response über und antwortet mit einem FHS-Paket mit allen für
die Verbindung benötigten Daten (Bluetooth Clock, AM_ADDR etc.). Der Slave quittiert dieses Paket
und kann nun die korrekte Sprungfolge ermitteln, weshalb beide Geräte in den Zustand Connected
übergehen. Um sicher zu stellen, dass der Wechsel der Frequenzsprungfolge korrekt vollzogen wurde,
schickt der Master ein POLL-Paket zum Slave, der darauf typischerweise mit einem NULL-Paket
antwortet.
Für das erstmalige Finden mittels Inquiry und Inquiry Scan müssen in der Praxis mehrere
Sekunden (bis zu 10 sec) kalkuliert werden, weshalb der Geschwindigkeit bei der Kommunikation von
aneinander vorbeibewegenden Geräten enge Grenzen gesetzt sind. Stehen die Parameter des gesuchten
Gerätes schon fest, so kann durch Page und Page Scan eine deutlich kürzere Verbindungszeit von unter
einer Sekunde erreicht werden.
Bei der Beschreibung der Verbindungsaufbau-Prozeduren wird klar, dass ein Gerät seine
eindeutige Bluetooth Geräteadresse auch ohne anschließende Verbindung im FHS-Paket preisgeben
muss, diese Eigenschaft lässt sich für die Verfolgung von Spuren einzelner Geräte nutzen (siehe dazu
Kapitel 2.4.1, Sicherheit und Verschlüsselung). [Merk02]
2.2.3 Link Manager (Verbindungsverwaltung)
2.2.3.1
Das Link Manager Protokoll
Die beiden Schichten Radio und Baseband sind für die physische Übertragung der einzelnen Bits
sowie das gesicherte Senden und Empfangen von Datenpaketen verantwortlich. Der Link Manager hat
die Aufgabe, die Übertragung zwischen Bluetooth-Einheiten zu kontrollieren. Das dafür entwickelte Link
Manager Protocol (LMP) – meist am Link Controller als Firmware implementiert – stellt eine Vielzahl
von Befehlen zur Kommunikation zwischen den Link Managern verschiedener Einheiten zur Verfügung;
- 44 -
die dabei ausgetauschten Nachrichten werden Protocol Data Units (PDUs) genannt. Abhängig von
Kontrolldaten, die das LMP von anderen Schichten bekommt, kommuniziert es entweder mit dem Link
Manager einer anderen Bluetooth-Einheit oder es sendet Steuerdaten zu den darunter liegenden Schichten
Baseband oder Radio (siehe Abbildung 26).
Abbildung 26: Link-Manager-Kommunikation [BCOR01]
PDUs werden in den Nutzdaten von ACL-Paketen übertragen, wobei ausschließlich DM1- und
DV-Pakete verwendet werden. Sie haben eine sehr hohe Priorität und können ggf. sogar die für eine
SCO-Verbindung reservierte Bandbreite benutzen. Schickt eine Einheit eine PDU an eine andere, so wird
diese durch eine Antwortnachricht entweder akzeptiert, oder – z.B. im Falle einer nicht unterstützten
Funktion – abgelehnt. Es besteht aber die Möglichkeit, dass der Link Manager des Masters eine PDU an
den eines Slaves schickt, der diese nicht ablehnen darf. [Merk02]
2.2.3.2
LMP-Prozeduren für den Verbindungsaufbau
Die wichtigste Funktion des Link Managers ist die des Verbindungsaufbaus, wofür aber auch
Funktionen anderer Protokollschichten benötigt werden; so muss beispielsweise die Page-Prozedur, für
die das Basisband verantwortlich ist, bereits durchgeführt worden sein. Anschließend können folgende
LMP-Transaktionen zwischen den beiden Einheiten beginnen, um die Verbindung aufzubauen:
1.
Clock Information Request: Der Clock-Offset ist die Differenz zwischen dem Masterund dem Slave-Clock, der bei jedem Empfang eines FHS-Pakets berechnet wird. Der
Master kann den Clock-Offset mit dieser LMP-Prozedur noch vor Aufbau der
Verbindung aus LMP-Sicht abfragen, um das Paging einer Einheit zu beschleunigen,
wenn diese das Piconetz verlassen hat.
- 45 -
2.
LMP-Version Request: Vor einem Verbindungsaufbau wird die LMP-Version durch den
Link-Manager abgefragt; dies ist notwendig, da zwischen den verschiedenen Versionen
Unterschiede bestehen.
3.
Features Request: Da eine Einheit nicht alle Eigenschaften der darunter liegenden
Schichten Radio und Baseband unterstützen muss, kann man mit diesem Request
herausfinden, mit welchen Einschränkungen – beispielsweise die fehlende Unterstützung
von Multislot-Paketen oder den Stromsparzuständen – man zu rechnen hat.
4.
Name Request: Jeder Bluetooth-Einheit wird ein benutzerfreundlicher Name (bis zu 248
Byte groß) zugewiesen, der mit diesem Request abgefragt werden kann.
5.
Einleitung des Verbindungsaufbaus: Nachdem der Sender die angeforderten
Informationen erhalten und ausgewertet hat (Schritt 1 bis 4), kann er den eigentlichen
Verbindungsaufbau einleiten. Hierfür sendet er eine entsprechende Request-PDU an den
Empfänger, der diesen akzeptiert oder ablehnt.
6.
Prozeduren zur Aushandlung der Link-Parameter: Nach erfolgreicher Bestätigung der
Aufforderung für einen Verbindungsaufbau können die Link Manager der beteiligten
Einheiten die Link Parameter (Pairing, Authentifikation, Verschlüsselung und Quality of
Service) aushandeln. Mehr dazu in Kapitel 2.4.1 (Sicherheit und Verschlüsselung) und
7.
2.4.3 (Quality of Service).
Abschluss des Verbindungsaufbaus: Nachdem die Link Manager beider Einheiten die
Verbindungsparameter fertig ausgetauscht haben, kann der Verbindungsaufbau
abgeschlossen werden. Die entsprechende PDU wird von beiden Einheiten unabhängig
8.
generiert, sobald sie mit dem Zustand der Verbindung „zufrieden“ sind.
SCO-Verbindungsaufbau: Beim bisherigen Verbindungsaufbau handelt es sich um eine
ACL-Verbindung, die immer zuerst aufgebaut wird. Anschließend können eine oder
mehrere SCO-Verbindungen aufgebaut werden, wobei das Einleiten eines SCOVerbindungsaufbaus nicht nur dem Master vorbehalten ist. Hierfür sendet die
entsprechende Einheit eine PDU mit den Parametern (SCO-Pakettyp, Audio-Codecs etc.)
der gewünschten Verbindung.
[Merk02]
- 46 -
Abbildung 27: LMP Verbindungsaufbau [BCOR01]
2.2.3.3
Weitere LMP-Prozeduren
Zusätzlich zu den Prozeduren für den Verbindungsaufbau spezifiziert das LMP noch weitere:
Einstellen der Multislot-Pakete: Durch die Verwendung von Multislot-Paketen kann eine
höhere Datenrate erzielt werden. Die Aushandlung der Paketgröße kann zu jedem
Zeitpunkt nach abgeschlossenem Verbindungsaufbau erfolgen.
Stromsparzustände und Leistungsregelung: Um Einheiten in einen der Stromsparzustände
Sniff, Hold oder Park zu versetzen oder dem Empfänger die Möglichkeit zu geben, eine
Erhöhung oder Verringerung der Sendeleistung zu beantragen, stellt LMP spezielle PDUs
zur Verfügung.
Master/Slave-Rollentausch: Ein Master/Slave-Rollentausch wird beispielsweise dann
benötigt, wenn eine Einheit in den Überdeckungsbereich eines Access Points kommt, mit
dem bereits Slaves verbunden sind. Sie versucht sich beim Access Point anzumelden,
initiiert den Verbindungsaufbau und ist damit Master. Der Access Point (im Moment
Slave) kann aber mit einer entsprechenden PDU einen Rollentausch mit dem Master
beantragen, bevor dieser den Verbindungsaufbau bestätigt. Die neue Einheit ist damit
wieder Slave.
Allgemeiner Verbindungsabbau: Will eine Einheit die Verbindung abbauen, so wird das
von ihrem Link Manager durch eine entsprechende PDU veranlasst. Durch eine strenge
- 47 -
Abfolge des Verbindungsabbaus wird garantiert, dass nicht durch einen fehlerhaften
Verbindungsabbau zwei Einheiten dieselbe AM_ADDR erhalten können.
[Merk02]
2.2.4 Host Controller Interface
Das Host Controller Interface ist die Schnittstelle zwischen Host-Software und der eigentlichen
Bluetooth-Hardware und wird für Bluetooth-Systeme benötigt, bei denen die höheren Protokollschichten
(über HCI) auf dem Host-Prozessor und die niedrigen Schichten auf einem physikalisch getrennten
Bluetooth- Gerät laufen. Die Gründe für eine Verwendung des HCI sind vielfältig:
Die i.A. performanteren Hosts können das Bluetooth-Modul entlasten, wodurch dieses
weniger komplex und dadurch kostengünstiger ist und zudem einen geringeren
Energieverbrauch aufweist
Ein deaktiviertes Host-Gerät kann durch das Bluetooth-Modul bei eingehender
Verbindung „aufgeweckt“ („wake on Bluetooth“) werden.
Das HCI ermöglicht ein einfaches Testen von Bluetooth-Modulen
Es wäre nicht möglich, den gesamten Stack auf den Host zu verlagern, da dieser die geforderten
Antwortzeiten aufgrund anderer Tasks nicht garantieren könnte. [Bray02]
Die Bluetooth-Module haben genau diese Schnittstelle, an der sie mit HCI-Kommandos – in der
Bluetooth-Version 1.1 sind 95 definiert – angesprochen werden können. Die physikalische Kopplung der
Host- und Bluetooth-Hardware wird über Universal Serial Bus (USB)-, PC-Card (PCMCIA)- und
Universal Asynchronous Receiver Transmitter (UART)-Schnittstelle unterstützt (siehe Abbildung 28).
Damit können nicht nur Bluetooth Controller Chips von beliebigen Herstellern in ein Gerät mit der
gleichen Host Software integriert, sondern beide Teile auch räumlich voneinander getrennt werden. So
kann z.B. eine Bluetooth PC Card für Notebooks lediglich den Bluetooth Controller enthalten, die Host
Software hingegen läuft direkt auf dem Betriebssystem des Notebooks und beide kommunizieren über
den PC Card Bus.
- 48 -
Abbildung 28: Protokoll-Implementierungen Modul und Host [BCOR01]
Die HCI-Treiber und -Firmware kommunizieren über die darunter liegende Host ControllerTransportschicht, die einen transparenten Datenaustausch ermöglicht (siehe Abbildung 29). Die
Kommunikation vom Host zum Controller erfolgt über HCI-Command-Pakete, die Steuerbefehle
enthalten und vom Host genutzt werden, um dem Bluetooth-Controller Befehle zu senden. Diese Pakete
bestehen aus einem 2 Byte großen Opcode (der eigentliche Befehl) und einer variablen Anzahl von
Parametern. Nach erfolgreicher Ausführung des Befehls antwortet der Controller meist mit einem
Command Complete Event.
In die andere Richtung erfolgt eine Signalisierung von Ereignissen mit Hilfe von HCI-EventPaketen, die vom Host Controller an den Host geschickt werden sofern ein Ereignis auftritt. Diese Pakete
bestehen aus einem Event Code, der das Ereignis identifiziert, und einer bestimmten Anzahl von
Parametern.
- 49 -
Zum Austauschen von Daten für die Applikationen bzw. die höheren Schichten werden HCI-DataPakete verwendet, die sich für SCO- und ACL-Verbindungen kaum unterscheiden. [Merk02]
Abbildung 29: Bluetooth-Übertragung zwischen zwei Host-Systemen [BCOR01]
2.2.5 Audio
Der Bluetooth-Stack in Abbildung 13 zeigt zwar eine Audioschicht, die Bluetooth-Spezifikation
definiert aber nur die möglichen Audioformate für die Umsetzung und Komprimierung der Audiodaten.
Diese werden über SCO-Verbindungen mit einer Datenrate von 64 kBit/s übertragen, von denen
gleichzeitig bis zu drei vollduplex zu einem Slave aufgebaut werden können. Wird mehr als nur ein Slave
bedient, sind maximal zwei Audioverbindungen möglich. Vor dem Aufbau einer SCO-Verbindung ist
allerdings eine ACL-Verbindung nötig, da der Link Manager Steuerinformationen für diese Verbindung
überträgt.
Für die Übertragung von Audio und Sprache werden zwei Verfahren benutzt:
Lineare Continuous Variable Slope Delta (CVSD) Modulation: Hierbei findet die
Quantisierung des Eingangssignals nicht in festen Abständen statt, sondern die
Schrittgröße der Treppenfunktion wird variabel an die eingehende Wellenform angepasst.
- 50 -
Nicht die absolute Wellenhöhe wird festgehalten, sondern nur die Differenz zum
Vorgängerwert. [Lule01] [BCOR03]
Logarithmische 8 Bit Puls Code Modulation (PCM): Dieses Verfahren wurde auf der
ITU-Empfehlung G.711 [22] standardisiert. Dabei werden bei einer Abtastfrequenz von 8
kHz die Abtastwerte über eine logarithmische Kennlinie – A-Law-Kennlinie mit 15
Segmenten oder µ-Law-Kennlinie mit 13 Segmenten – zu 8 Bit-Worten quantisiert,
wodurch sich eine Übertragungsrate von 64 kBit/s ergibt. Durch die logarithmische
Quantisierung
wird
ein
konstanter
relativer
Quantisierungsfehler
(s.g.
Quantisierungsrauschen) und somit ein höherer Dynamikumfang erreicht, der sich
gegenüber der linearen Quantisierung vor allem bei kleinen Signalwerten bemerkbar
macht. [Merk02] [Stef02] Abbildung 30 zeigt das Prinzip der logarithmischen
Quantisierung anhand der A-Law-Kennlinie. Es erfolgt eine Dynamikkompression des
bereits mit 13 Bit linear quantisierten Eingangssignals x mit einem Wertebereich von [4096 .. 4096] anhand der A-Law-Kennlinie auf 8 Bit [-128 .. 128]
[Merk02]
Abbildung 30: A-Law-Kennlinie (positiver Quadrant) [Stef02]
- 51 -
2.3
Protokollstack Teil 2 – Bluetooth Host
2.3.1 Logical Link Control and Adaption (Logische
Verbindungssteuerung und Anpassung)
Das Logical Link Control and Adaption Protocol (L2CAP) ist die erste Schicht des BluetoothStacks, die direkt am Host angesiedelt ist. Sie kommuniziert entweder direkt oder über HCI – falls
implementiert – mit dem Baseband-Protokoll, wobei lediglich ACL-Pakete unterstützt werden. Daraus ist
ersichtlich, dass das L2CAP ausschließlich für den (asynchronen) Datenaustausch und nicht für
(synchrone) Audioübertragung genutzt wird.
Das L2CAP-Protokoll erfüllt mehrere essentielle Aufgaben:
Das Multiplexen von im Stack höher liegenden Protokollen
Das Segmentieren und Reassemblieren von Datenpaketen
Gruppenmanagement und eine Art „Multicast“-Unterstützung
Quality of Service Management
Abbildung 31: L2CAP im Bluetooth-Stack [BCOR01]
Das Multiplexen von höher liegenden Protokollen ist notwendig, um diesen die Verwendung auf
die unter dem HCI liegenden Schichten zu ermöglichen. Das Baseband-Protokoll unterstützt kein wie
auch immer geartetes „Type“-Feld in seinem Paketheader, deshalb muss L2CAP diese Funktionalität
implementieren um in weiterer Folge die empfangenen Daten wieder an die höher liegenden Protokolle
wie SDP oder RFCOMM verteilen zu können. Zu diesem Zweck werden Channels verwendet, die durch
eine im L2CAP-Header eingetragene Nummer eindeutig zugeordnet werden können.
- 52 -
Das Segmentieren und Reassemblieren ist wohl neben dem Multiplexing die wichtigste
Funktionalität von L2CAP. Das Baseband-Protokoll unterstützt wie bereits erwähnt eine maximale
Nutzdatenlänge von 341 Bytes (bei DH5-Paketen), unter Umständen kann auch nur eine Übertragung von
lediglich 18 Byte möglich sein. Um den Protokollen der darüber liegenden Schichten eine höhere
Paketgröße zu ermöglichen, unterstützt L2CAP die Segmentierung und Reassemblierung von Paketen mit
einer maximalen Größe von 64 kByte.
Via Gruppenmanagement können einzelne Geräte eines Netzwerkes zu Gruppen zusammengefasst
und über einen verbindungslosen L2CAP Kanal mit Multicast Nachrichten versorgt werden (eigentlich
gruppenweiter Broadcast). Diese werden allerdings vom Empfänger nicht bestätigt und sind damit nicht
zuverlässig, durch den geringen Overhead aber für unkritische Informationen geeignet.
Mit dem Quality of Service (QoS) Management können Kommunikationsparameter wie maximale
Verzögerung oder minimale Datenrate in Form eines QoS-Vertrages ausgehandelt werden. Weitere
Informationen finden sich in Kapitel 2.4.3 (Quality of Service). [17][Bray01][Lule01]
2.3.1.1
Das L2CAP-Channel-Konzept
Wie bereits erwähnt, verwendet L2CAP zur Unterscheidung verschiedener Verbindungen von
höherschichtigen Protokollen sogenannte Channels. Diesen ist jeweils eine eindeutige 4-Byte-ID
zugeordnet, die weitgehend frei gewählt werden kann (ab 0x0040, darunter befinden sich reservierte
Channels).
L2CAP unterstützt zwei Arten von Channels. Verbindungsorientierte Channels tragen eine
Channel-ID größer 0x0040, sind bidirektional und müssen explizit mittels dem in Kapitel 2.3.1.3
(L2CAP-Verbindungsaufbau für verbindungsorientierte Channels) beschriebenen Ablauf eingerichtet
werden. Ein Spezialfall eines verbindungsorientierten Channels ist auch der Signalisierungskanal 0x0001,
auf den in 2.3.1.2 (Die L2CAP-Signalisierung) genauer eingegangen wird.
- 53 -
Abbildung 32: L2CAP-Verbindungen [BCOR03]
Die zweite Art von Channels ist verbindungslos. Diese Channels müssen nicht explizit eingerichtet
und konfiguriert werden, können aber lediglich unidirektional verwendet werden. Der
Empfängerendpunkt liegt immer auf Channel 0x0002, senderseitig kann die Channel-ID frei gewählt
werden (wiederum >0x0040). Typischerweise könnte ein verbindungsloser Channel für Broadcast- oder
Multicast-Nachrichten verwendet werden.
Abhängig vom Channeltyp wird auch ein unterschiedliches Datenpaket (PDU)-Format verwendet.
Während Pakete für verbindungsorientierte Channels als einzige Identifikation die Channel-ID mitführen,
wird bei verbindungslosen Channels zusätzlich die PSM (Protocol/Service-Multiplexer) übermittelt, um
den Empfänger auf den höheren Schichten zu kennzeichnen. Die PSM-Werte sind zum Teil standardisiert
(1 für SDP, 3 für RFCOMM, 5 für TCS-BIN, …), Werte größer 4096 können dynamisch zugewiesen
werden. [Schi03]
Abbildung 33: Datenpaket-Formate [Schi03]
- 54 -
2.3.1.2
Die L2CAP-Signalisierung
Zwischen zwei Endgeräten besteht wie erwähnt immer genau ein speziell ausgezeichneter
Channel, der als Signalisierungskanal bezeichnet wird. Er trägt die Channelnummer 0x0001, muss nicht
explizit eingerichtet werden und dient im Wesentlichen dem Datenaustausch beim Einrichten, der
Konfiguration und dem Abbau von verbindungsorientierten Channels über L2CAP.
Zum Zwecke dieses Channel-Managements sind im L2CAP spezielle Signalisierungspakete
definiert, die aus mehreren L2CAP-Befehlen bestehen können. Ein L2CAP-Befehl besteht aus einem
OpCode, einem Identifier, einem Längenfeld und dem Befehlsparametern (Data).
Abbildung 34: Signalisierungs-Datenpaket [Schi03]
Beim Absetzen eines Signalisierungspaketes startet intern ein Timer, nach dessen Ablauf das
Paket erneut übertragen wird, wenn die Antwort bis dahin nicht eingetroffen ist. Es wird jedoch das
Identifier-Feld erhöht, was zur Folge hat, dass der Kommunikationspartner erkennen kann, ob der Befehl
bereits ausgeführt wurde und lediglich die Antwort verloren gegangen ist. Ist dies der Fall, so wird
lediglich die Antwort erneut übertragen, der Befehl jedoch ansonsten verworfen.
Für Fehlerfälle, wie zum Beispiel zu lange Pakete oder ungültige Befehle, wurde ein speziellen
Ablehnungspaket definiert, dass neben dem Ablehnungsgrund auch noch Platz für zusätzliche
Informationen – wie z.B. jenen Befehl, der den Fehler verursacht hat – bietet. [Merk02]
2.3.1.3
L2CAP-Verbindungsaufbau für verbindungsorientierte Channels
Der Verbindungsaufbau via L2CAP unterscheidet sich in Abhängigkeit davon, ob das HCI in der
konkreten Implementierung existiert oder direkt mit dem Baseband kommuniziert wird. Der eigentliche
Low-Level-Verbindungsaufbau der notwendigen ACL-Verbindung wird in beiden Fällen vom im
Baseband angesiedelten Link Manager Protokoll übernommen, unterschiedlich ist nur das Ansprechen
des Link Managers entweder direkt oder via HCI.
- 55 -
Steht die ACL-Verbindung, so läuft der L2CAP-Verbindungsaufbau bei beiden Arten (direkt oder
über HCI) äquivalent ab. Der erste L2CAP-Befehl, der gesendet wird, ist L2CAP_ConnectReq, der
einerseits die Channelnummer auf der Seite des Senders und andererseits den PSM-Wert (Protocol
Service Multiplexer) des höherschichtigen Protokolls, das die Verbindung anfordert, beinhaltet.
Die Gegenstelle antwortet mit einem L2CAP_ConnectRspPns-Paket, mit dem sie die
anfordernde Einheit informiert, ob der Verbindungsaufbau akzeptiert wird oder nicht. Ein Result-Feld in
diesem Paket gibt entweder Auskunft über den Erfolg oder den Ablehnungsgrund (Kapazitäts- oder
Sicherheitsgründe, nicht unterstützte PSMs etc.). Weiters wird diejenige Channelnummer der Gegenstelle
übertragen, welche die anfordernde Einheit in weiterer Folge zum Datenaustausch verwenden muss.
Ein positives L2CAP_ConnectRspPns-Paket bedeutet jedoch noch nicht unbedingt einen
erfolgreichen Verbindungsaufbau, da auch die höheren Schichten noch der Verbindung zustimmen
müssen. Erst wenn diese eingetroffen sind, sendet L2CAP das endgültige L2CAP_ConnectRsp-Paket
und erklärt die Verbindung für erfolgreich aufgebaut. [Merk02]
2.3.1.4
Die Konfiguration eines L2CAP-Channels
Ist die Verbindung aufgebaut, muss im Anschluss der Channel entsprechend den Anforderungen
konfiguriert werden. Im Wesentlichen stehen drei Parameter zur Verfügung:
Maximum Transmission Unit (MTU)
Flush-Timeout
Quality of Service (QoS)
Die MTU gibt die maximale Nutzdatenlänge des L2CAP-Paketes in Bytes an. Minimal muss die
MTU 48 Bytes betragen, defaultmäßig sind 672 Bytes (2 DH5-Pakete minus diverse Header) eingetragen,
die maximale Größe ist durch die Länge des MTU-Feldes festgelegt und beträgt 65535 Bytes. Die
eingestellte MTU gilt jeweils nur für eine Kommunikationsrichtung, so dass beide Geräte verschiedene
MTUs einstellen können.
Das Flush-Timeout ist eine Zeitangabe in Millisekungen für die maximale Zeit, die L2CAP für die
Übertragung eines Paketsegmentes benötigen darf. Wenn dieser Wert überschritten wird, wird das
gesamte Paket verworfen. Diese Zeit legt also im Endeffekt fest, wie oft das Baseband die Übertragung
wiederholen darf, bis ein Fehler gemeldet wird (Retransmit). Das Flush-Timeout ist deshalb auch ein
Vielfaches von 1,25 ms (ein Zeitschlitzpaar des Basebands). Ist als Flush-Timeout 1 eingestellt, so wird
kein Retransmit durch das Baseband erlaubt. Defaultmäßig ist 0xFFFF eingestellt, was bedeutet, dass das
Paket so oft wiederholt werden kann, bis es entweder erfolgreich übertragen wurde oder die Verbindung
abbricht. Dieser Wert wird durch die rufende Einheit vorgegeben und gilt für beide Geräte.
- 56 -
Die Einstellungen des QoS unterscheiden zwischen Best-Effort-Übertragungen oder solchen mit
garantiertem QoS. Dazu können verschiedene Parameter eingestellt werden, die u.a. die maximal erlaubte
Verzögerungszeit eines Bits zwischen Verlassen der L2CAP-Schicht und dem tatsächlichen physischen
Senden oder die maximale Datenrate enthalten.
Bei einer Funkübertragung kann natürlich nie eine 100% sichere Übertragung garantiert werden,
daher muss auch der Begriff des QoS relativiert werden. Was im Bluetooth-Kontext unter QoS zu
verstehen ist, ist genauer in Kapitel 2.4.3 (Quality of Service) nachzulesen. [Merk02]
2.3.2 Service Discovery Protocol (Dienstfindung)
Das Service Discovery Protokoll (SDP) bietet die Möglichkeit, die angebotenen Dienste eines
Gerätes abzufragen. Dazu werden in einer angeschlossenen Datenbank die verfügbaren Dienste des
Bluetooth Geräts in s.g. Service Records gespeichert und anderen Geräten auf Anfrage mitgeteilt.
Natürlich sind auch eigene Anfragen möglich, wobei die Kommunikation immer auf einer Client-ServerBeziehung zwischen Anfrager und Auskunftsgeber beruht. Das SDP setzt dabei auf L2CAP auf, basiert
also auf dem verbindungslosen Austausch von ACL-Paketen.
Eine Suche ist nach Dienstklasse und/oder Dienstattribut möglich; zusätzlich lassen sich
Dienstbäume manuell durchsuchen, wozu die Service-Datenbank hierarchisch aufgebaut ist. Wichtig ist,
dass sich Dienste erfragen lassen, ohne eine „vollständige“ Verbindung (z.B. via RFCOMM) aufbauen zu
müssen, so dass erst dann eine Verbindung zu diesem Gerät aufgebaut werden muss, wenn der
gewünschte Dienst gefunden ist. Vielmehr müssen lediglich einige wenige Pakete – die SDP Protocol
Data Units (PDUs) – ausgetauscht werden, um eine Suche zu starten bzw. um die Antwort zu übermitteln.
- 57 -
Abbildung 35: SDP-Architektur [BCOR03]
Dieses Protokoll ist für jedes Anwendungsszenario notwendig, denn es ermöglicht die Entdeckung
von Diensten auf anderen Geräten, mit denen ein Szenario erst realisiert werden kann. Eine Aussage
darüber, wie ein Dienst tatsächlich zu benutzen ist, macht dieses Protokoll nicht, aber es kann Hinweise
darauf geben. Ausführlichere Informationen finden sich direkt im Service Discovery Application Profile
(siehe Kapitel 2.5.3, Service Discovery Application Profile). [17][Bray01][Lule01]
2.3.2.1
Service Records
Die Informationen über jedes Service sind – wie bereits erwähnt – in einem Service Record
abgelegt, der durch einen Service Record Handle auf dem jeweiligen Host eindeutig identifiziert ist. Jeder
Service Record enthält eine beliebige Anzahl von Service-Attributen, wobei zwischen drei Kategorien
unterschieden werden muss:
Standard Service Attribute
Service Discovery Service-Klassen Attribute
Browser Group Descriptor Service-Klassen Attribute
Standard Service Attribute sind jene Attribute, deren Definition in allen Service Records die
gleiche Bedeutung hat, wobei aber nicht jeder Record diese Attribute enthalten muss.
Mit Service Discovery Service-Klasse Attributen können die Eigenschaften des SDP-Servers
ausgelesen werden, sie beschreiben also den SDP-Server.
- 58 -
Die Browser Group Descriptor Service-Klassen Attribute dienen der Hierarchisierung der ServiceKlassen zum komfortableren Browsen der Services.
Abbildung 36: Service Record [BCOR03]
Ein Service-Attribut enthält immer eine 16-Bit-Attribut-ID und einen Attribut-Wert variabler
Länge, die im Wesentlichen durch die ID festgelegt wird. Aus Gründen der Interoperabilität werden zum
Austausch der Attribut-IDs und -Werte Datenelemente verwendet, deren Format festgelegt ist und in
[Merk02] nachgelesen werden kann.
Jedes Service gehört zu einer oder mehreren Kategorien, den s.g. Service-Klassen. Diese legen die
Attribute der einzelnen Services fest, man könnte also sagen, dass jeder Service-Record eine Instanz einer
oder mehrerer Service-Klassen ist. Jede Klasse ist durch einen 128-Bit-Wert weltweit eindeutig
identifiziert (UUID nach ISO/IEC 11578:1996). Es existiert eine Vielzahl an vordefinierten Klassen, es
steht aber auch jedem Hersteller frei, eigene Service-Klassen zu definieren, die auch von bestehenden
Klassen abgeleitet sein können (z.B. könnte PostscriptPrinterService bereits existieren und ein
Hersteller definiert darauf aufbauend eine Klasse ColorPostscriptPrinterService). Diese
abgeleiteten Klassen besitzen dann zusätzlich zu den eigenen Attributen auch die Attribute der
Superklassen. [Merk02]
2.3.2.2
Finden von Services
Services können wie bereits oben erwähnt auf zwei Arten gefunden werden:
Suchen von Services
Browsen nach Services
Beim Suchen nach Services muss die UUID der Service-Klasse, die gesucht wird, bekannt sein. Es
kann dann eine entsprechende Anfrage an den SDP-Server der Gegenstelle gestellt werden, der dann
zurückmeldet, ob ein passender Service-Record gefunden wurde, die Service-Klasse also unterstützt wird.
- 59 -
Beim Browsen nach Services müssen die Service-Klassen nicht bekannt sein, mit Hilfe der
Service-Klasse BrowseGroupDescriptor und der oben vorgestellten Browser Group Descriptor
Service-Klassen Attribute lässt sich unter einem generischen Public Browse Root-Eintrag eine Hierarchie
der angebotenen Services aufbauen, die entsprechend durchsucht werden kann. [Merk02]
2.3.3 RFCOMM
RFCOMM wurde von der Bluetooth SIG analog zum IrCOMM Protokoll der Infrared Data
Association definiert und basiert ebenso auf der ETSI 07.10 Spezifikation. RFCOMM emuliert RS-232
Steuerungs- und Datensignale, so dass es als eine Art „Kabelersatz-Protokoll“ aufgefasst werden kann,
denn höhere Protokollschichten „sehen“ nur eine normale serielle (9-polige) RS-232 Verbindung, als
wären die beiden Geräte mit einem realen Kabel verbunden. Theoretisch können über eine einzige
Bluetooth-Verbindung via Mulitplex-Sitzung bis zu 60 serielle Verbindungen emuliert werden, wenn
man sich jeweils mit einer entsprechend geringen Datenrate zufrieden gibt. Jeder dieser Kanäle wird
durch einen Data Link Connection Identifier (DLCI) identifiziert, wobei der DLCI 0 für die Übertragung
von Kontrollnachrichten reserviert ist.
Die Emulation einer RS232-Schnittstelle ermöglicht allen Applikationen, die eine serielle
Verbindung zur Gegenstelle voraussetzen, die problemlose Benutzung einer Bluetooth Verbindung ohne
weitere Modifikationen. Insbesondere die im Standard integrierten Protokolle OBEX, PPP sowie ATCommands machen von dieser Möglichkeit regen Gebrauch, andere für die serielle Verbindung geeignete
Protokolle können aber ebenfalls benutzt werden; hier ist einiger Spielraum für Spezialanwendungen
vorhanden. [Lule01] [Merk02]
2.3.3.1
Die RFCOMM-Verbindung
Nach erfolgtem L2CAP-Verbindungsaufbau kann eine RFCOMM-Verbindung durch das Senden
von speziellen Rahmen, die im ETSI-Standard definiert sind und auf die hier nicht näher eingegangen
wird, aufgebaut werden.
Steht die RFCOMM-Verbindung, so gilt aufgrund der Funktionalität von L2CAP der Kanal als
zuverlässig; Daten werden nicht wiederholt gesendet. Trifft nach einer Minute keine Antwort auf einen
gesendeten Rahmen ein, so wird die Verbindung unterbrochen.
Die Datenübertragung wird dann wiederum von einem speziellen Rahmen übernommen, der
neben den Nutzdaten auch noch die Statussignale der seriellen Schnittstelle enthält.
- 60 -
Eine Besonderheit, die nicht alle Bluetooth-Geräte unterstützen, ist die Fähigkeit, mehrere serielle
Kanäle gleichzeitig zu unterschiedlichen Geräten offen zu halten. Dazu muss das Gerät mehrere
Multiplex-Sitzungen nach ETSI 07.10 unterstützen, für jede einzelne Multiplex-Sitzung wird ein eigener
L2CAP-Channel benötigt. [Merk02]
2.3.4 Auf RFCOMM aufbauende Protokolle
Auf RFCOMM kann wie erwähnt jedes Protokoll aufbauen, dass ansonsten eine RS232Schnittstelle benötigt. Im Bluetooth-Stack ist eine Reihe von derartigen Protokollen inkludiert, die für
verschiedene Anwendungsszenarien sinnvoll sein können:
OBEX und darauf aufsetzend vCard/vCal
PPP und darauf aufsetzend IP, UDP, TCP sowie WAP und WAE
AT-Kommandos
Das Object Exchange (OBEX)-Protokoll wurde im Zuge der IrDA-Standardisierung definiert und
dient der Übertagung von strukturierten Objekten wie zum Beispiel Kalenderdaten (vCal) oder
Visitenkarten (vCard). Nicht nur um eine Interoperabilität mit IrDA zu gewährleisten sondern auch weil
sich OBEX heute weitgehend durchgesetzt hat und z.B. auch über TCP abgewickelt werden kann, wurde
das Protokoll in den Bluetooth-Stack aufgenommen. [Merk02] OBEX wird von den Profilen Generic
Object Exchange Profile, Object Push Profile, Synchronization Profile, File Transfer Profile, Basic
Imaging Profile und Basic Printing Profile verwendet. Das OBEX-Protokoll beruht auf einer einfachen
Client/Server-Architektur: OBEX Clients laden Objekte von einem OBEX Server herunter (get) und
hinauf (put). Das OBEX-Protokoll kann in zwei Teile gegliedert werden: [Hopk03]
Object Model: Definiert den Aufbau von OBEX-Objekten und wie diese zu transportieren
sind.
Session Protocol: Definiert das Handshaking zwischen Client und Server wenn Objekte
ausgetauscht werden.
Das Point-to-Point-Protocol (PPP) ist ein Standard für die Übertragung von IP-Paketen über
serielle Verbindungen. In dieser Funktion wurde es auch in den Stack aufgenommen und eröffnet
Bluetooth die Möglichkeit, das weite Feld der TCP/IP-basierten Anwendungen zu nutzen. Via UDPVerbindung kann auch noch das Wireless Application Protocol (WAP) verwendet werden, das vom
Einsatz in Mobiltelefonen als Pedant zu HTTP hinlänglich bekannt sein dürfte.
AT-Kommandos sind Modem-Steuerbefehle und werden von Anwendungen benutzt, die
ursprünglich serielle Verbindungen verwendeten. Durch die Integration in den Bluetooth-Stack ist eine
Portierung von derartigen Anwendungen leichter möglich.
- 61 -
Genauere Informationen über die auf RFCOMM aufsetzenden Protokolle können aus den
entsprechenden RFCs [66] sowie den Büchern [Tane00] oder [Roth02] bezogen werden.
2.3.5 TCS-Binary (TCS BIN)
Ein wesentlicher Aspekt von Bluetooth ist die Unterstützung von Sprachverbindungen. Die
Tatsache, dass derartige Verbindungen unterstützt werden, impliziert jedoch noch nicht, dass auch
„klassische“ Telefonverbindungen möglich sind, da ein wesentlicher Teil – die Signalisierung (z.B.
Klingelfunktion) – vorerst außen vor bleibt.
Genau diese Funktionalität leistet das Telephony Control Protocol (TCS-Binary), das auf der ITUT-Empfehlung Q.931 basiert und auch bei ISDN verwendet wird.
Während die eigentliche Sprachübertragung über SCO-Verbindungen abgewickelt wird, basiert
die Signalisierung durch TCS-Binary auf L2CAP und damit auf ACL-Paketen. Im Wesentlichen leistet
TCS-Binary die telefonrelevanten Signalisierungen für Verbindungsauf- und -abbau. Die Funktionen
lassen sich im Wesentlichen in drei Gruppen einteilen:
Call Control
Group Management
Connectionless TCS
Call Control ist dabei für die eigentliche Signalisierung bei Verbindungsauf- und -abbau zwischen
Bluetooth-Geräten zuständig. Dabei arbeitet das Protokoll wie eine Zustandsmachine (State Machine), die
zwischen den einzelnen Zuständen (States), die den wesentlichen Phasen eines Telefonats entsprechen,
wechselt (genauere Aufschlüsselung siehe [BCOR01]).
Group-Management sorgt für einen einfachen Zugriff auf Gruppen von Bluetooth-Geräten.
Zugrunde liegt das Konzept der Wireless User Group, damit wird eine Gruppe von Geräten bezeichnet,
die das TCS-Binary-Protokoll unterstützen. Diese Gruppe kann dann verschiedene definierte GruppenFunktionen nutzen, zum Beispiel ist es möglich, dass ein Gerät die Telefondienste eines anderen Geräts
der Gruppe in Anspruch nimmt, aber auch nahe liegende Funktionen wie Konferenzschaltungen oder
Rufweiterleitung sind hier definiert.
Connectionless TCS sorgt für die Bereitstellung von Signalisierungsinformationen, welche nicht
zur aktuellen Verbindung gehören. Diese Funktionalität wird besonders in Verbindung mit der
Verwaltung von Wireless User Groups benötigt, damit einzelne Mitglieder untereinander Daten
austauschen können, ohne eine Verbindung herzustellen. Dazu gehören unter anderem Mikrofon- und
- 62 -
Lautsprecherparameter sowie Hersteller-spezifische Angaben, i.A. all jene Informationen, die nicht
standardisiert übertragen werden.
TCS-Binary unterstützt einerseits Point-to-Point-Signalisierung, andererseits wird auch Point-toMultipoint-Signalisierung angeboten. Ersteres wird dann eingesetzt, wenn die Bluetooth-Gegenstelle
bekannt ist (z.B. bei einer Headset-Mobiltelefon-Konstellation). Die zweite Signalisierungsvariante
kommt dann zum Einsatz, wenn es mehrere mögliche Gegenstellen gibt. Dies ist zum Beispiel dann der
Fall, wenn bei einer Basisstation ein Anruf eingeht und sich mehrere Bluetooth-Mobilteile in Reichweite
befinden, die den Anruf entgegennehmen können. Dann wird allen Geräten ein Anruf signalisiert, bis der
Erste diesen entgegen nimmt.
TCS-Binary wird nicht nur zur Steuerung von Sprachanrufen sondern auch für Datenanrufe
eingesetzt. Ein typisches Beispiel wäre der Einsatz des Dial-Up Networking Profile (siehe Kapitel
2.5.14). Nachdem mehrere SCO-Verbindungen gleichzeitig existieren können, müssen auch mehrere
TCS-Binary-Instanzen gleichzeitig behandelt werden können. Dazu wird ggf. für jede Instanz ein eigener
L2CAP-Channel geöffnet. [Merk02]
2.4
Schichtenübergreifende Funktionalitäten
2.4.1 Sicherheit und Verschlüsselung
Bei Funktechnologien ist Sicherheit immer ein wichtiges Thema, da relativ leicht ein
unautorisierter Zugriff auf die Luftschnittstelle erfolgen kann. [Schi03] Bluetooth zielt auf die
Realisierung von Ad-hoc-Netzwerken ohne dedizierten, gesicherten Server ab, wobei aber gleichzeitig
Sicherheit vor ungewünschten Zugriffen oder Abhörattacken gewährleistet werden soll. Gerade für die
Realisierung von WPANs muss der Benutzer die Kommunikation der Geräte kontrollieren können;
beispielsweise sollte ein Notebook nicht ein fremdes Mobiltelefon ohne ausdrückliche Einwilligung des
Besitzers als Internet-Gateway benutzen können. [Lule01] Zudem werden bei vielen der anvisierten
Anwendungsszenarien für Bluetooth persönliche oder firmenkritische Daten – z.B. Terminkalender oder
Kontakte – ausgetauscht. [Schi03]
Aus diesem Grund bietet Bluetooth eine Vielzahl von Sicherheitsmechanismen, die im Folgenden
vorgestellt werden. Im Anschluss werden Sicherheitsrisiken und entsprechende Gegenmaßnahmen
diskutiert.
2.4.1.1
Sicherheitsmechanismen
- 63 -
Die wesentlichen Sicherheitsmechanismen in Bluetooth sind eine initiale Paarbildung – auf deren
Basis der Verbindungsschlüssel erzeugt wird – durch Eingabe eines PINs, ein Challenge-ResponseVerfahren für die Authentifizierung und eine Verschlüsselung für Datenströme; die einzelnen Schritte
sind in Abbildung 37 zu sehen). Für jede Verbindung kann eine einfache (nur eine Richtung), zweifache
(beide Richtungen) oder keine Authentifizierung mit Hilfe des Challenge-Response-Verfahrens
angefordert werden. Da alles in einen Bluetooth-Chip integriert werden muss, werden kryptographisch
stärkere und damit auch komplexere Verfahren höheren Schichten überlassen.
Abbildung 37: Bluetooth Sicherheitsarchitektur und -protokolle [Schi03]
Paarung (Pairing) und Verbindungsschlüssel
Wollen zwei Bluetooth-Geräte kryptographische Sicherheitsmechanismen nutzen, müssen sie in
einem ersten Schritt gepaart (pairing) werden; das ist immer dann notwendig, wenn zwei BluetoothGeräte noch nie zuvor miteinander kommuniziert haben. Dafür muss in beiden Geräten die gleiche
geheime Kennung (PIN) eingegeben werden, die bis zu 16 Byte umfassen kann. Verfügt ein Gerät über
eine feste PIN, so muss diese in das andere Gerät eingegeben werden; zwei Geräte mit festen PINs
können nicht gepaart werden. [BSI03] [Schi03] Zusätzlich schreibt die Bluetooth-Spezifikation bei
- 64 -
Fehleingaben eine exponentiell steigende Wartezeit vor, was einen hohen Schutz gegen Brute-ForceAttacken bietet. [Merk02]
Basierend auf dieser PIN, den Geräteadressen sowie zwei von je einem Gerät erzeugte
Zufallszahlen wird i.d.R. ein 128 Bit langer Kombinationsschlüssel (Combination Key) erzeugt und in
jedem Gerät für die zukünftige Nutzung als Verbindungsschlüssel (Link Key) gespeichert; dieser kann für
eine Authentifizierung genutzt werden. Für die gesicherte Übertragung der Zufallszahlen wird ein
Initialisierungsschlüssel (Initialization Key) verwendet, der sich aus einer weiteren (öffentlichen)
Zufallszahl, einer Geräteadresse und einer PIN berechnet. [BSI03] [Schi03] Die Schlüssel werden
typischerweise in einem persistenten Speicher (z.B. Flash ROM) abgelegt.
Neben den Kombinationsschlüsseln, die von Applikationen mit hohen Sicherheitsanforderungen
verwendet werden, gibt es noch weitere Möglichkeiten für Verbindungsschlüssel:
Geräteschlüssel (Unit Key): Wird bei der erstmaligen Verwendung eines BluetoothGerätes erzeugt und normalerweise nicht mehr geändert. Für ein Bluetooth-Gerät ist er
von einem Kombinationsschlüssel nicht zu unterscheiden, der Unterschied besteht
lediglich in der Art der Generierung. Geräteschlüssel werden z.B. dann verwendet, wenn
ein Gerät nicht mehr genügend Speicherplatz für weitere Schlüssel besitzt oder ein Gerät
einer Gruppe von Nutzern zugänglich sein soll.
Master-Schlüssel (Master Key): Er wird auch Temporärschlüssel bezeichnet und ersetzt
den momentanen Verbindungsschlüssel, um dem Master beispielsweise die Möglichkeit
zu geben, zwei Bluetooth-Geräte mit dem gleichen Verbindungsschlüssel zu erreichen.
[BSI03] [Merk02]
Authentifizierung
Die
Authentifizierzung
ist
ein
Challenge-Response-Verfahren,
das
auf
einem
Verbindungsschlüssel, einer Zufallszahl und der Geräteadresse des Anspruchstellers (Claimant) beruht.
[Schi03] Die Authentisierung ist einseitig; das bedeutet, dass sich der Claimant gegenüber einem anderen
(Verifier) authentisiert. Wollen sich beide Geräte gegenseitig authentisieren, so wird die Authentisierung
mit vertauschten Rollen wiederholt.
Die Authentisierung läuft so ab, dass der Verifier eine Zufallszahl an den Claimant schickt. Dieser
berechnet unter Benutzung des Verbindungsschlüssels aus der erhaltenen Zufallszahl und seiner eigenen
Geräteadresse eine Antwort und sendet sie zum Verifier zurück. Damit beweist der Claimant, dass er das
gemeinsame Geheimnis (den Verbindungsschlüssel) kennt und er wird vom Verifier authentifiziert.
[BSI03]
- 65 -
Verschlüsselung
Die Verschlüsselung ist optional, setzt aber voraus, dass sich mindestens eines der beiden
kommunizierenden Geräte gegenüber dem anderen authentifiziert hat. Eine Verschlüsselung wird immer
vom Master gestartet, kann aber auch vom Slave beantragt werden. [BSI03]
Basierend auf dem Verbindungsschlüssel, während der Authentifizierung ausgehandelten
Parametern sowie einer Zufallszahl wird ein Schlüssel zur Verschlüsselung (Chiffrierschlüssel) erzeugt,
der eine maximale Länge von 128 Bit besitzt. Zur Verschlüsselung wird ein Stromchiffre verwendet,
wobei für jedes Datenpaket ein neuer Nutzlastschlüssel für die eigentliche Chiffrierung erzeugt wird, der
auf dem Chiffrierschlüssel sowie der Geräteadresse und dem aktuellen Zeittakt des Master berechnet
wird. Die eigentliche Verschlüsselung ist dann eine einfache XOR-Operation der Nutzdaten mit dem
Nutzdatenschlüssel. [Schi03]
Ein Master kann aber auch einen von ihm erzeugten Verbindungsschlüssel (Master Key) an die
Slaves im Piconetz verteilen und damit Broadcast-Pakete verschlüsseln. [Lule01]
Sicherheitsbetriebsarten
Security Mode 1 (non-secure): Das Bluetooth-Gerät unternimmt selbst keine
Sicherheitsmaßnahmen, weshalb dieser Modus für sicherheitsrelevante Daten nicht zu
empfehlen ist.
Security Mode 2 (service level enforced): In diesem Modus werden erste
Sicherheitsmaßnahmen erst nach erfolgreichem Verbindungsaufbau durchgeführt.
Welche Schritte danach ergriffen werden hängt vom Bluetooth-Gerät („trusted“ oder
„non-trusted“) und vom Dienst auf Anwendungsebene (hierfür können verschiedene
Security-Levels definiert werden) ab.
Security Mode 3 (link level enforced): Beim Verbindungsaufbau ist generell eine
Verschlüsselung notwendig, die Verschlüsselung der übertragenen Daten ist aber
optional.
[BSI03] [Kral03]
Eindeutige 48 Bit-Adresse pro Bluetooth-Gerät
Jedes Bluetooth-Gerät ist eindeutig durch seine 48 Bit große Geräteadresse (BD_ADDR)
identifizierbar, wodurch theoretisch über 281 Billionen Geräte auseinander gehalten werden können.
Damit ist gewährleistet, dass sich alle Bluetooth-Geräte eindeutig ausweisen können. [Kral03] [Lule01]
- 66 -
Zufallszahlengenerator
Für eine kryptographisch sichere Schlüsselverteilung besitzt jedes Bluetooth-Gerät einen „guten“
Zufallszahlengenerator. [Kral03]
Weitere Sicherheitsmechanismen
Frequency Hopping: Es erfolgt 1600 Mal pro Sekunde ein pseudozufälliger Wechsel zwischen den
79 Trägerfrequenzen, wodurch eine gewisse Sicherheit gegeben ist. Allerdings könnte ein Angreifer alle
79 Kanäle parallel abhören („sniffen“).
Geringe Reichweite: Sie beträgt nur rund 10m (Leistungsklasse 3) und schränkt damit den
Aktionsradius eines möglichen Angreifers stark ein. [Merk02] [Matt03]
2.4.1.2
Sicherheitsrisiken
Bluetooth bietet eine deutlich höhere Sicherheit als der Wired Equivalent Privacy (WEP)-Standard
in 802.11. Dennoch zeigen sich auch bei Bluetooth Schwächen, in im Folgenden untersucht werden.
[Schi03]
Schwächen im Sicherheitskonzept
Verschlüsselung nicht grundsätzlich vorgeschrieben: Eine Verschlüsselung der
übertragenen Daten ist unabhängig vom verwendeten Sicherheitsmodus optional und
muss von den Anwendungen explizit gefordert werden.
Unsichere Voreinstellungen nicht grundsätzlich ausgeschlossen: Herstellerseitig
deaktivierte Sicherheitsfunktionen wie Authentisierung und Verschlüsselung oder auf
„0000“ gesetzte PINs stellen das Sicherheitskonzept von Bluetooth in Frage. Bei Geräten
wie beispielsweise Headsets, die über keine Eingabemöglichkeit verfügen, ist eine
Änderung dieser Werte gar nicht oder nur schwer möglich.
Schwache PINs können erraten werden: Werden bei der Gerätepaarung schwache PINs
verwendet, können diese vom Angreifer erraten werden, der daraus den
Verbindungsschlüssel berechnen kann. Als sicherheitskritisch ist hier anzumerken, dass
PINs als einzige geheime Parameter bei der Erzeugung des Verbindungsschlüssels
eingehen.
Geräteschlüssel sind unsicher: Werden Geräteschlüssel als Verbindungsschlüssel
verwendet, so wird bei jeder Verbindung mit diesem Gerät immer der gleiche Schlüssel
verwendet. Gelingt es einem Angreifer, eine Verbindung mit diesem Gerät aufzubauen,
- 67 -
ist er ab sofort in der Lage, sich als diese Gerät auszugeben bzw. jede Kommunikation
mit diesem Gerät abzuhören.
Schwache Integritätssicherung: Der zur Integritätssicherung verwendete Cyclic
Redundancy Check (CRC) bietet keinerlei Schutz gegenüber absichtlicher Manipulation
von Datenpaketen.
Qualität des Zufallszahlengenerators: Der Bluetooth-Standard macht keine Vorgaben
bzgl.
der
Qualität
des
für
den Verschlüsselungsprozess
verwendeten
Zufallszahlengenerators. [BSI03] [Schi03]
Datenschutz-Risiko bei Bluetooth-Geräten: Die Geräte-Adresse ist durch eine einfache
Inquiry-Operation öffentlich zugänglich, was zusammen mit ihrer Eindeutigkeit zu einem
Datenschutzproblem führt. Denn wenn diese Adresse mit einer Person in Verbindung
gebracht werden kann, besteht die Möglichkeit, ihre Aktivitäten mitzuverfolgen und
sogar Bewegungsprofile zu erstellen. [Merk02] [Lule01] (z.B. könnten Kaufhäuser die
Häufigkeit von Besuchen oder die Aufenthaltsdauer vor bestimmten Produkten eruieren)
Sicherheits-Risiko bei SCO-Verbindungen: SCO-Verbindungen bieten keine Möglichkeit
der Stromverschlüsselung und können damit prinzipiell abgehört werden. Durch die
zuvor aufzubauende ACL-Verbindung kann zwar eine gesicherte Authentifizierung
erfolgen, die übertragenen Audiodaten können aber – wenn auch mit großem Aufwand –
abgehört werden. [Lule01]
„Bluejacking“: Dieses Kunstwort setzt sich aus Bluetooth und Hijacked zusammen und
bezeichnet eine Möglichkeit, via Bluetooth anonym und kostenlos im Radius von bis zu
10 m Nachrichten zu versenden. Dieser als eher harmlos einzustufende „Handy-Spam“
funktioniert so: Man legt einfach einen neuen Kontakt an, wobei man in das „Name“-Feld
die gewünschte Nachricht (z.B. „Hallo, du wurdest bluejacked“) einträgt. Wählt man nun
ein Mobiltelefon mit aktiviertem Bluetooth aus und sendet an dieses den Kontakt, so
erscheint auf dessen Display „Hallo, du wurdest bluejacked“. Ermöglicht wird dieser
Angriff dadurch, dass Bluetooth während der Paarung zweier Geräte den Namen des
initiierenden Bluetooth- Gerätes, der bis zu 248 Zeichen lang sein kann, am Zielgerät
anzeigt. [54] [Laur03]
„Snarf-Attacke“: Damit soll es laut [Laur03] möglich sein, über Bluetooth Verbindungen
zu anderen Mobiltelefonen aufzubauen, ohne dass das Gerät des Opfers etwas anzeigt;
dies kann mit entsprechenden Tools sogar dann funktionieren, wenn der Discovery- oder
Visible-Modus des Opfers ausgeschaltet ist. Anschließend könne man Zugriff auf
Adressbuch, Kalender, Uhr etc. erhalten. Diese Attacke sei auf Schwächen in den
Zugriffskontrollen der Mobiltelefone begründet, und wurde erfolgreich auf weit
verbreiteten Modellen wie dem Sony Ericsson T68i und T610 sowie dem Nokia 6310i
und 7650 durchgeführt. [Laur03]
- 68 -
„Backdoor-Attacke“: Hierbei ermögliche der Pairing-Mechanismus das Autorisieren
bestimmter Bluetooth-Geräte auf Dauer, ohne dass dies beispielsweise am Nokia 6310i
angezeigt wird. Dennoch kann eine Verbindung hergestellt und sogar die GPRSVerbindung des Opfers genutzt werden. Da eine solche permanente aber eine zumindest
einmalig gewollte Autorisation des Opfers erfordert, ergibt sich hier eine zusätzliche
Gefahr in Kombination mit Bluejacking: Durch eine verwirrende Anweisung als
Gerätename könnte das Bluejacking-Opfer dazu verleitet werden, mit der erforderlichen
Passwortbestätigung eine Verbindung zu autorisieren. [Laur03]
Man-in-the-Middle-Angriffe
Darunter versteht man, dass sich ein Angreifer, der (unberechtigt) Zugriff auf ein Bluetooth-Gerät
erhalten hat, „mitten zwischen“ zwei berechtigte Geräte schieben kann. Diese beiden Geräte
kommunizieren anschließend über den Angreifer miteinander, der die Datenpakete abhören und sogar
manipulieren kann.
Dafür muss der Angreifer den Slave zu einem Master/Slave-Rollentausch bringen, wodurch er mit
beiden Bluetooth-Geräten, die nun Master sind, kommunizieren kann. Der Angreifer gibt dabei vor, das
jeweils andere Gerät zu sein; Authentisierungsanfragen leitet er einfach an das andere Gerät weiter. Dies
ist allerdings nur möglich, wenn er in Besitz des Verbindungsschlüssels ist, der sich aber bei „0000“-PINs
oder Verwendung von Geräteschlüsseln relativ einfach ermitteln lässt. [BSI03] [Merk02]
Probleme bei der Verschlüsselung
Obwohl Schlüssellängen von bis zu 128 Bit verwendet werden, haben Fluhrer und Lucks in
[Fluh01] gezeigt, dass die erreichbare Sicherheit je nach Stärke des Angriffs 73 bzw. 84 Bit nicht
übersteigt.
Weiters ist der Initialisierungsvektor nicht vom vollständigen Zeittakt des Masters abhängig; das
höchstwertige Bit wird dabei nicht berücksichtigt.
Verschlüsselte Daten sollen – z.B. bei einer Man-in-the-Middle-Attacke – selbst bei starker
Verschlüsselung manipuliert werden können, wenn der verschlüsselte Klartext teilweise bekannt ist.
Unkontrollierte Ausbreitung von Funkwellen
Obwohl die Reichweite relativ begrenz ist, kann – bei Verwendung von Richtantennen – auch über
größere Distanzen der Datenverkehr mitverfolgt werden. Bei SCO- oder nicht verschlüsselten ACLVerbindungen können mit Hilfe von Bluetooth-Protokollanalysatoren [32] übertragene Nutzdaten passiv
mitgelesen und aufgezeichnet werden. [BSI03] [Lule01]
- 69 -
Verfügbarkeitsprobleme
Die Verfügbarkeit kann beispielsweise durch Störungen anderer Nutzer im gleichen ISM-Band
(z.B. 802.11b/g-Access Points), Störung durch gezielt eingesetzte Störsender oder Denial-of-ServiceAttacken (z.B. Angriff auf Energiereserven durch indem vermieden wird, dass ein Gerät in den
Ruhezustand geht) eingeschränkt werden.
Weitere Sicherheitsrisiken
Weiters ist zu bedenken:
Mobile Geräte sind gegenüber stationären einem höheren Diebstahlrisiko ausgesetzt
Nur das Gerät muss sich beim Benutzer authentifizieren und nicht umgekehrt
Bluetooth-Geräteadressen sind
manipulierbar
durch Überschreiben
des Flash-Speichers leicht
Auch in Ad-hoc-Netzwerken können sich Computerviren und Trojanische Pferde
ausbreiten
Das Abhören bzw. Aufzeichnen von Gesprächen unter Verwendung von handelsüblichen
oder entsprechend manipulierten Bluetooth-Geräten ist nicht auszuschließen. [BSI03]
2.4.1.3
Schutzmaßnahmen
Im Folgenden wird beschrieben, welche Maßnahmen zu einer möglichst sicheren BluetoothKommunikation ergriffen werden können und welche Restrisiken bestehen bleiben.
Konfiguration von Bluetooth-Geräten
Bei der Konfiguration von Bluetooth-Geräten sollte Folgendes berücksichtigt werden:
Werden sicherheitsrelevante Daten übertragen, so ist es erforderlich, Kombinations- und
keine Geräteschlüssel zu verwenden
Nur die benötigten Dienste sollten aktiviert sein
Connectability (Reaktion auf Paging-Anfragen), Discoverability (Reaktion auf Inquiry)
und Pairability sollten soweit als möglich eingeschränkt werden
Die Sendeleistung sollte so niedrig wie möglich gehalten werden
Der Default-PIN sollte eine möglichst lange und zufällig gewählte PIN sein (mindestens
12 Stellen, Mischung von Groß- und Kleinbuchstaben sowie Zahlen)
Geräte sollten so konfiguriert werden, dass sie nach erfolgter Authentifizierung
Verschlüsselung verwenden
- 70 -
Die Schlüssellänge sollte mindestens 64 Bit betragen
Absicherung mobiler Geräte
Mobile Geräte sind gegenüber stationären besonderen Risiken ausgesetzt, weshalb folgende
Maßnahmen ergriffen werden sollten:
Die Paarung zweier fremder Geräte solle in einer abhörsicheren Umgebung durchgeführt
werden
Jedes Gerät, das mehrere Dienste mit unterschiedlichen Sicherheitsniveaus anbietet, sollte
in Sicherheitsmodus 2 betrieben werden; dabei ist auch auf eine sorgfältige Auswahl der
Sicherheitspolicies zu achten
Geräte die nur einen Dienst oder mehrere Dienste mit unterschiedlichen
Sicherheitsniveaus betreiben, sollten im Sicherheitsmodus 3 betrieben werden
Falls möglich sollte die PIN nach erfolgter Initialisierung gelöscht werden
Bei Verlust bzw. Diebstahl sollten alle Verbindungsschlüssel in den verbliebenen Geräten
gelöscht werden
Nicht benutzte Geräte sollten ausgeschaltet werden.
Weitere Schutzmaßnahmen
Soweit möglich sollten auf Bluetooth-Geräten weitere Sicherheitsmaßnahmen implementiert sein,
wie beispielsweise Folgende:
Schutz vor Zugriff auf das Gerät (Passworteingabe etc.)
Benutzerauthentisierung beim Einloggen
Virenschutz
Aktive Firewall
Eingeschränkte Datei- und Ressourcenfreigabe auf Betriebssystemebene
[BSI03]
Restrisiko
Das Erstellen von Bewegungsprofilen kann nicht verhindert werden, ebenso wenig die Gefährdung
der Verfügbarkeit. Man-in-the-Middle-Angriffe sind selbst bei optimal konfigurierten Geräten möglich,
Abhilfe kann nur durch Verwendung zusätzlicher Maßnahmen – beispielsweise IPSec oder SSL – erreicht
werden. [BSI03]
2.4.2 Stromsparfunktionen
- 71 -
Da der Hauptanwendungsbereich von Bluetooth bei mobilen Endgeräten liegt, sollte die
Stromaufnahme so gering wie möglich sein. [Merk02]
Für diesen Zweck ist es möglich, die Sende- und Empfangsbereitschaft teilweise einzustellen,
indem das Gerät in den Zustand Hold, Park oder Sniff versetzt wird. Die Geräte bleiben trotz der
geringeren Stromaufnahme im Piconetz synchronisiert und können bei Bedarf relativ schnell wieder an
der Kommunikation teilnehmen.
Im Zustand Hold wird für eine bestimmte Zeit die gesamte Übertragungstätigkeit einer Einheit
eingestellt. Innerhalb dieser, dem Master und dem Slave bekannten Zeit, sendet der Master keine Pakete
an den Slave, wodurch dieser seine Übertragung komplett einstellen und somit Strom sparen kann. Der
Slave hat aber auch die Möglichkeit, aktiv an einer anderen Kommunikation (z.B. in einem anderen
Piconetz) teilzunehmen; nach Verstreichen dieser Zeit nimmt der Slave wieder an der Kommunikation im
(ursprünglichen) Piconetz teil. Die Reaktionszeit ist von der Hold-Zeit abhängig, und kann damit
schlechter als im Zustand Sniff sein, dafür ist aber die durchschnittliche Stromaufnahme geringer.
Abbildung 38: Übertragungstätigkeit im Zustand Hold [Merk02]
Ein weiterer Stromspar-Zustand ist der s.g. Sniff-Zustand. Dabei bleibt der Slave weiterhin
synchronisiert, wird aber nur periodisch sende- und empfangsbereit und kann während dieser Zeit mit
dem Master kommunizieren. Der Master, der das Intervall der aktiven Phase kennt, wird nur während
dieser Zeit den entsprechenden Slave ansprechen. Empfängt ein Slave nun am Anfang seiner aktiven
Phase ein für ihn bestimmtes Paket, so kann er weiterhin aktiv bleiben, ansonsten kann er bis zum
nächsten Intervall im Stromsparzustand verbleiben. Durch flexible Einstellung des Zeitverhältnisses
zwischen „aktiv“ und „abgeschaltet“ kann die Stromaufnahme indirekt beeinflusst werden; eine
- 72 -
Verkürzung der aktiven Phase wirkt sich aber direkt durch eine Verschlechterung der Reaktionszeit der
Bluetooth-Einheit aus.
Abbildung 39: Übertragungstätigkeit im Zustand Sniff [Merk02]
Die niedrigste Stromaufnahme nach dem Standby-Zustand erreicht man im Zustand Park. Im
Gegensatz zu Sniff und Hold ist die Bluetooth-Einheit in diesem Zustand nicht mehr aktiv, die
Synchronisation mit dem Master bleibt aber aufrecht. Dies wird durch ein s.g. Beacon-Verfahren erreicht,
bei dem der Master in garantierten Beacon-Schlitzen Pakete an den Slave senden kann, der seinerseits
kurz in „Empfangsbereitschaft“ wechselt. Diese Zeitschlitze können beispielsweise für eine
Reaktivierung des Slaves oder zum Versenden von Broadcast-Nachrichten genutzt werden.
Abbildung 40: Übertragungstätigkeit im Zustand Park [Merk02]
Weiters sieht die Bluetooth-Spezifikation eine Leistungsregelung vor, mittels derer die
durchschnittliche Stromaufnahme reduziert werden kann. Der Empfänger wertet zu diesem Zweck die
Stärke des empfangenen Signals aus und sendet dementsprechend eine Anforderung zur Reduktion bzw.
Erhöhung der Sendeleistung an den Sender. Vor allem wenn die kommunizierenden Einheiten nahe
- 73 -
beieinander sind, und eine hohe Sendeleistung die Stromaufnahme unnötig in die Höhe treiben würde, ist
diese Regelung sinnvoll. Die Leistungsanpassung führt der Master außerdem für jeden Slave individuell
durch, um unterschiedliche Entfernungen der Geräte berücksichtigen zu können. [Merk02]
Geht man von einer 600mAh-Batterie aus, so reicht die Energieversorgung für ein BluetoothModul im Standby-Zustand 3 Monate, im aktiven Sprachmodus 60h, im aktiven Datenmodus 100h und
im Hold- bzw. Park-Modus 1 Jahr aus. [Matt03]
2.4.3 Quality of Service
Über mehrere Ebenen des Stacks verteilt bietet Bluetooth auch die Möglichkeit eines Quality-ofService-Managements. Die Konfiguration einer QoS-Vereinbarung wird via L2CAP vorgenommen, für
die eigentliche Abwicklung des QoS-Managments ist jedoch der Link Manager zuständig. Genau in
dieser Aufgabentrennung lag bis zur Spezifikation 1.1 auch das Problem des QoS-Management in
Bluetooth, da es in der Spezifiktion Inkonsistenzen zwischen L2CAP- und LM-Handling von QoS gab.
Ab der Spezifikation 1.2 sind diese Inkonsistenzen jedoch beseitigt.
Folgende Parameter können zur Vereinbarung eines QoS eingestellt werden:
Die grundsätzliche Art des QoS: Die Entscheidung, ob der Link ein gewisses QoS
garantiert oder nur versucht dieses zu erreichen. Dritte Option: keine Unterstützung eines
QoS.
Token Rate: Die Datenrate, mit der auf einer Verbindung gesendet werden kann.
Token Rate Bucket Size: Legt den Daten-Puffer im Stack fest. Dieser wird besonders bei
Burst-artigem Verkehr groß zu wählen sein, um die anfallenden Daten zwischenspeichern
zu können, während bei kontinuierlichem Datenfluss die Puffer-Größe eher klein gewählt
werden kann.
Peak Bandwidth: Die maximale Datenraten, mit der Pakete gesendet werden können.
Latency: Die zulässige Verzögerung zwischen der Verfügbarkeit von zu sendenden Daten
und dem eigentlichen Senden.
Delay variation: Die maximal zulässige Änderung der Verzögerungen auf einem Link
über die Zeit.
Nachdem diese Parameter von L2CAP an den Link Manager übermittelt wurden, verhandelt dieser
mit dem Link Manager der Gegenstelle über die Möglichkeit einer Verbindung mit den gewünschten
QoS-Parametern. Stimmt die Gegenstelle zu, so gilt das QoS als vereinbart und das anfordernde L2CAP
wird über den Erfolg informiert. Scheitern die Verhandlungen mit der Gegenstelle wird entsprechend
wiederum L2CAP über das Scheitern informiert, dieses muss dann entscheiden, was weiter zu tun ist.
- 74 -
Der Link Manager hat nun mehrere Möglichkeiten, ein vereinbartes QoS zu erreichen bzw. zu
halten. Um die vereinbarte Token Rate zu erreichen, garantiert der Link Manager ein polling interval,
welches festlegt, wie lange die maximale Dauer zwischen zwei Übertragungen auf einer Verbindung ist.
Dieses Intervall kann sich ändern, wenn sich der verwendete Paket-Typ und damit die Menge der
übertragenen Daten pro Paket ändert.
Da das verwendete polling interval aber auch Einfluss auf die vereinbarte Latency hat, kann es
sein, das es sich auch bei verändertem Paket-Typ nicht ändert, wenn dies zu einer Verletzung der Latency
führen würde.
Der Link Manager kann aber auch das gesamte Systemverhalten beeinflussen, um die QoSVereinbarungen einhalten zu können. So kann er zum Beispiel Verbindungsanforderungen ablehnen,
wenn durch ein vereinbartes QoS die Ressourcen schon vollkommen ausgeschöpft werden. Es ist dem
Link Manager sogar möglich, die periodischen Page- und Inquiry-Scans abzuschalten, um die verfügbare
Bandbreite zu maximieren (was sinnvoll sein kann, wenn aufgrund von Ressourcenmangel sowieso keine
neuen Verbindungen angenommen werden können).
- 75 -
Abbildung 41: Ablauf einer QoS-Vereinbarung [Bray02]
Das grundsätzliche Problem bei der Vereinbarung eines Quality of Service über eine
Funkverbindung ist die Unzuverlässigkeit der Funkstrecke selbst. Bei drahtlosen Übertragungsmedien
wird eine Garantie einer gewissen Bandbreite niemals möglich sein, da eine Störung der Funkverbindung
die erreichbare Datenrate jederzeit unter das notwendige Limit drücken kann. Die einzige Möglichkeit,
einem derartigen Fall zu begegnen, ist die Benachrichtigung der höherliegenden Schichten von der
Verletzung der QoS-Vereinbarungen. In Bluetooth überwacht der Link Manager die Einhaltung der QoSVereinbarungen und sendet ggf. ein QoS-Violation-Event entweder direkt oder via HCI an L2CAP,
- 76 -
welches die Benachrichtigung
[Bray02][BCOR01]
2.5
entsprechend
an
die
höherliegenden
Schichten
weitergibt.
Bluetooth-Profile
In der Spezifikation des gerade beschriebenen Bluetooth-Protokollstacks wird lediglich auf die
exakte technische Spezifikation der einzelnen Protokolle, deren Eigenschaften und deren Schnittstellen
eingegangen. Die eigentliche Verwendung der Protokolle für einen konkreten Anwendungsfall bzw. das
jeweilige Verhalten der beteiligten Geräte bleibt aber in der Core Specification außen vor.
Genau diese „Unspezifiziertheit“ ist aber eine der größten Stärken der Bluetooth-Technologie,
denn damit wird Raum für beliebig viele Anwendungsszenarien geschaffen, die auch erst in ferner
Zukunft auftreten können. Um jedoch keinen Wildwuchs an proprietären Verwendungen des BluetoothStacks zuzulassen und Interoperabilität zwischen den Geräten verschiedener Hersteller zu garantieren,
wurde von der Bluetooth SIG das Instrument der Profile geschaffen.
Ein Profil legt fest, wie Bluetooth-Protokolle mit bestimmten Parametern genutzt werden, damit
zwei Partner herstellerunabhängig kommunizieren können, und zum Beispiel eine InternetWählverbindung aufzubauen. An solchen Aktionen sind in der Regel mehrere Protokollschichten
beteiligt; Nachrichtentechniker sehen die Profile deshalb auch als "vertikale Schnitte" durch den
Bluetooth-Protokollstack.
Profile sind i.A. nicht symmetrisch aufgebaut, das heißt, die Anforderungen des Profils an den
einen Kommunikationspartner sind andere als jene an die Gegenstelle. Konkret wird zum Beispiel beim
Cordless Telephony Profile die Basisstation andere Funktionalitäten zur Verfügung stellen müssen als das
Mobilteil.
- 77 -
Abbildung 42: Vertikale Schnitte [Schi03]
Begleitend zum ersten Release der Core Specification wurden 13 Profile veröffentlicht, später
wurden weitere 13 hinzugefügt, so dass heute die unten dargestellten 26 Profile definiert sind. Es ist zu
erwarten, dass sich die Anzahl der Profile in Zukunft mit der Entwicklung neuer Anwendungsszenarien
weiter erhöhen wird.
2.5.1 Überblick
Die bereits definierten Profile lassen sich in mehrere Kategorien einteilen (siehe Abbildung 43).
Die Grafik ist so zu interpretieren, dass jedes Gerät, das eines der eingebetteten Profile unterstützt, auch
die außen liegenden Profile unterstützen muss. Das Headset Profile muss so zum Beispiel auch das Serial
Port Profile und das Generic Access Profile unterstützen. Sämtliche Profile bauen auf dem Generic
Access Profile auf, das impliziert natürlich, dass alle Bluetooth-Geräte zumindest dieses Profil
unterstützen müssen.
Im weiteren Verlauf lassen sich noch weitere Gruppen von Profilen identifizieren. Die größten
Einheiten sind einerseits jene Profile, die auf dem Serial Port Profile aufbauen und jene, die auf dem
Generic Object Exchange Profile aufsetzen. Eine Sonderrolle nehmen jene beiden Profile ein, die dem
TCS-BIN-Protokoll zuzuordnen sind und zur Daten- (bzw. Sprach-) Übertragung SCO-basierte
Audioverbindungen verwenden.
- 78 -
Abbildung 43: Bluetooth Profile (es fehlt: HID Profile im GAP) [18]
Zweifellos könnten die Profile noch viel ausführlicher behandelt werden, aufgrund des dann
explodierenden Umfangs wurde jedoch nur jeweils eine kurze Darstellung der Funktion des Profils
verfasst und auf eine tiefer gehende Betrachtung verzichtet. Die offiziellen Profil-Spezifikationen sind
trotz ihres Umfangs gut lesbar und bieten bei Interesse in einem speziellen Gebiet eine gute Referenz und
Möglichkeit zur Vertiefung.
2.5.2 Generic Access Profile
Dieses Profil nimmt eine Sonderrolle ein, da hier kein spezielles Anwendungsszenario abgebildet
wird, sondern allgemeingültige Grundsätze für die Kommunikation zwischen Bluetooth Geräten
vereinbart werden. Es liefert Richtlinien unter anderem für das Verhalten von Geräten vor und während
einer Verbindung, sowie für eine begrifflich einheitliche Benutzeroberfläche.
- 79 -
Es stellt sicher, dass Geräte jeglicher Klasse – ob Mobiltelefon oder Drucker – und beliebiger
Hersteller unter allen Umständen zumindest eine simple physikalische Verbindung mit einem logischen
Kanal aufbauen können, um wenigstens Name und andere Eigenschaften des jeweils anderen Geräts zu
ermitteln. Dabei liegt der Schwerpunkt auf der Entdeckung von Geräten in Reichweite (Discovery), dem
Verbindungsaufbau (Link Establishment) und den Sicherheitsfunktionen (Security Procedures), d.h.
insgesamt vor allem auf den Parametern der unteren Protokollschichten Baseband und LMP. [Lule01]
2.5.3 Service Discovery Application Profile
Auch das Service Discovery Application Profile nimmt eine Sonderrolle ein, da auch hier kein
spezielles Szenario abgebildet wird, sondern die allgemeinen Verfahren zur Entdeckung von Diensten auf
anderen Geräten spezifiziert werden. Zwar beschreibt das Service Discovery Protocol (SDP) die
Kommunikation zwischen Geräten zur Entdeckung von Diensten, allerdings ohne genaue Festlegung der
Anwendungsparameter (Einsatzzeitpunkt, Rollen, etc.). Die fehlende Information liefert dieses Profil, das
letztlich nichts anderes ist als ein „Pflichtenheft für eine reale Applikation“ (Service Discovery
Application), die das Service Discovery Protocol benutzt, um Dienste auf anderen Geräten zu finden.
Insbesondere werden Regeln aufgestellt, wie der Benutzer eines Geräts die von anderen Bluetooth
Geräten in Reichweite zur Verfügung gestellten Dienste sichtbar machen und aktiv nach speziellen
Diensten suchen kann. Neben menschlichen Benutzern können aber auch laufende Applikationen diese
Regeln benutzen und entsprechende Dienste finden. Wichtig zu bemerken ist in diesem Zusammenhang,
dass dieses Profil keine Aussage darüber macht, wie ein Dienst letztendlich angesprochen und benutzt
wird, sondern lediglich die Information über verfügbare Dienste in anderen Geräten an den Benutzer oder
die laufende Applikation liefert.
2.5.4 Extended Service Discovery Profile
Das Extended Service Discovery Profile (ESDP) hat das Ziel die UPnP-Technologie (Universal
Plug’n’Play) auf der Bluetooth-Plattform anzubieten. Dazu werden zwei Ansätze zur Verfügung gestellt,
um UPnP via Bluetooth zu implementieren. Der erste Ansatz setzt direkt auf L2CAP auf, der zweite
verwendet eine IP-basierte Lösung, die auf dem LAN- oder dem PAN-Profil aufsetzt. Aus diesem Grund
findet sich das ESDP auch an drei Stellen (basierend auf LANP, PANP oder GAP) in der
Überblicksgrafik (siehe Abbildung 43).
2.5.5 Common ISDN Access Profile
- 80 -
Das Ziel des Common ISDN Access Profiles ist die Bereitstellung eines ISDN-Zugangs via
Bluetooth. Dieser soll möglichst ohne Einschränkungen möglich sein und sicherstellen, dass native
ISDN-Anwendungen ohne Modifikationen über Bluetooth arbeiten können. Das Common ISDN Access
Profile basiert lediglich auf dem Generic Access Profile, es ist klar zum Dial-Up Networking Profile
abgegrenzt, dass ja auf einer seriellen Verbindung basiert. [BCIA03]
2.5.6 PAN Profile
Das Personal-Area-Network-Profile (PANP) ermöglicht es, mit Bluetooth ein PAN aufzubauen.
Grundsätzlich unterscheidet das Profil zwei Arten von PANs, wobei die erste - „Network Access Points“
– ein ausgezeichnetes Gerät – den Network Access Point (NAP) – verwendet, das ein oder mehrere
Bluetooth-Geräte enthält und als Bridge zwischen einem externen Netzwerk (Ethernet, GSM etc.) und
den anderen Geräten im Piconetz (PAN Units) fungiert.
Die zweite Art von PANs, die unterstützt wird, sind „Group Ad-Hoc Networks“, die einem Master
– den Group Ad-Hoc-Network-Point – erlaubt, mit den anderen Bluetooth-Geräten im Piconet (PAN
Units) zu kommunizieren.
Für dieses Profil wurde ein eigenes Protokoll, das Bluetooth Network Encapsulation Protocol
(BNEP) entwickelt, das es erlaubt Ethernet-Traffic in Bluetooth-Piconetze zu übertragen. [17]
2.5.7 Cordless Telephony Profile und Intercom Profile
Ziel der beiden Profile Cordless Telephony und Intercom ist es, eine Audio-Verbindung zwischen
Bluetooth Geräten zu ermöglichen. Folgende Anwendungsfälle sind damit vorgesehen:
Verbindung einer an ein externes Telefonie-Netzwerk angeschlossenen Basisstation
(Gateway) mit mehreren Endgeräten für die Schnurlos-Telefonie, wobei die Endgeräte
nicht nur konventionelle Telefon-Hörer mit Funktechnik sein müssen, sondern auch
Mobiltelefone oder Multimedia PCs mit Mikrofon und Lautsprecher durch eine
Erweiterung mit Bluetooth zum Endgerät avancieren können. Funktional werden
eingehende und ausgehende Anrufe sowie weitere Telefonie-Merkmale des externen
Festnetzes (z.B. DTMF Signalisierung) unterstützt. Die Anbindung von bis zu sieben
Endgeräten ist für dieses Profil verpflichtend, eine größere Anzahl ist optional.
Direktverbindung zweier Endgeräte (Interkom-Funktion); die Interkom-Funktion gehört
verbindlich zum Cordless Telephony Profile, sie kann allerdings auch einzeln in Geräten
verwendet werden (z.B. als Walkie-Talkie).
- 81 -
Die beiden Profile Cordless Telephony und Intercom definieren die Rahmenbedingungen für den
Anwendungsfall „3-in-1-Telefon“. Dieses Szenario stellt eine Zusammenfassung bisher einzelner Geräte
in einem Kombinationsprodukt dar: Mobiltelefonie, Schnurlos-Telefonie und Telefon-Direktverbindung
(Interkom-Verbindung) sind als Funktionen in einem Gerät vorhanden und können kontextabhängig
benutzt werden. Außer Haus kann über Mobiltelefonie (z.B. GPRS) kommuniziert werden, innerhalb der
Reichweite einer Bluetooth Basisstation kann ein daran angeschlossenes Festnetz genutzt werden und bei
kurzen Verbindungen von Gerät zu Gerät (z.B. über zwei Etagen) kann die Interkom-Funktion völlig
ohne Dritt-Netze eingesetzt werden.
Natürlich können auch Untermengen dieser Funktionalität in einem Gerät integriert werden, z.B.
ist ein Schnurlos-Telefon mit Interkom-Funktionalität denkbar.
2.5.8 Hardcopy Cable Replacement Profile
Das Hardcopy Cable Replacement Profile definiert die Connectivity von Hardcopy-Geräten wie
Druckern oder Scannern mit einer datenliefernden oder -empfangenden Gegenstelle via Bluetooth.
Abbildung 44: Protokollstack HCRP [BHCR03]
Obwohl auch andere Profile dieses Anwendungsszenario abdecken könnten, wurde das HCRProfile entwickelt, um eine sehr einfache Flusskontrolle für hohe Datenmengen, wie sie beim Drucken
oder Scannen auftreten, anbieten zu können.
Auch für dieses Profil wurde ein eigenes Protokoll entwickelt, das als Hardcopy Cable
Replacement Protocol (HCRP) bezeichnet wird und direkt auf L2CAP aufsetzt. [BHCR03][17]
- 82 -
2.5.9 Human Interface Device Profile
Das Human Interface Device Profile (HID-Profile) basiert auf dem Generic Access Profile und
legt die Verwendung von Human Interface Devices wie Maus, Tastatur oder Joystick aber auch
Ausgabegeräten mit einem beliebigen Host via Bluetooth fest. Dazu wird eine USB-Schnittstelle via
Bluetooth emuliert, die es erlaubt, sämtliche USB-Treiber für Geräte weiter zu verwenden.
Ein weiterer Vorteil dieses Profils ist auch, dass es ausschließlich auf L2CAP basiert und keine
höher liegenden Protokoll wie z.B. RFCOMM verwendet. Dies ermöglicht eine verhältnismäßig einfache
Implementierung des Bluetooth-Stacks auf dem Human Interface Device (nämlich nur bis L2CAP).
[17][BHID03]
Abbildung 45: Bluetooth-Stack bei Verwendung von HIDP [BHID03]
2.5.10 Generic Audio/Video Distribution Profile
Das Generic Audio/Video Distribution Profile definiert den generischen Teil der Übertragung von
Audio- und/oder Video-Daten über ACL-Verbindungen. Insbesondere wird der Signalisierungsablauf
beim Auf- und Abbau sowie beim Konfigurieren der Übertragungskanäle behandelt. Der konkrete Ablauf
der Übertragung sowie Encoder- und Decoder-Funktionalität ist in den jeweiligen speziellen Profilen
festgelegt.
Von der Bluetooth Audio/Video Working Group wurde bei der Definition dieses und der
aufbauenden Profile explizit darauf hingewiesen, dass Bluetooth in der Spezifikation 1.1 kein
ausreichendes QoS-Management zur Verfügung stellt, um sicherstellen zu können, dass die jeweiligen
- 83 -
Kanäle die entsprechend benötigte Bandbreite erhalten. Daher wurde das Konsortium aufgefordert, in der
nächsten Bluetooth Revision erweiterte QoS-Unterstützung anzubieten, was in der nun veröffentlichten
Spezifikation 1.2 auch umgesetzt wurde. [BAVW03a]
Abbildung 46: Audio/Video-Übertragungsprofile – Abhängigkeiten [BAVW03a]
2.5.11 Adv. Audio Distribution Profile und Video Distribution Profile
Das Advanced Audio Distribution Profile hat das Ziel, Audio-Inhalte in hoher Qualität Mono oder
Stereo über ACL-Verbindungen zu übertragen. Es muss daher klar vom herkömmlichen Bluetooth Audio,
wie es im Cordless Telephony Profile oder im Intercom Profile verwendet wird, abgegrenzt werden,
welches relativ schmalbandig Audio-Daten via SCO-Verbindungen überträgt.
Ein typischer Anwendungsfall für dieses Profil ist die Übertragung von Musik von einem
beliebigen Musikabspielgerät (üblicherweise in Stereo) zu Ausgabegeräten wie Kopfhörern oder
Lautsprechern. Die Audio Daten werden dabei komprimiert, um die verfügbare Bandbreite besser
ausnutzen zu können. Die Übertragung von Surround-Sound ist nicht vorgesehen.
Während sich also das Advanced Audio Distribution Profile auf die Übertragung von Audiodaten
konzentriert, behandelt das Video Distribution Profile die Übertragung von Video-Daten (ohne Audio).
- 84 -
Unterstützen Geräte beide Profile, so können (nach Maßgabe der verfügbaren Bandbreite) Audio- und
Video-Daten in hoher Qualität übertragen werden, wobei das Zusammenspiel dieser beiden Medien im
Video Distribution Profile beschrieben wird.
Werden zusätzlich zur Übertragung von Audio- oder Video-Daten auch Fernsteuerungsfunktionen
gewünscht, so reichen die beiden hier beschriebenen Profile nicht aus. Vielmehr ist für dieses Szenario
das Audio/Video Remote Control Profile zuständig, das die entsprechenden Funktionalitäten zur
Verfügung stellt.
Während das Advanced Audio Distribution Profile bereits in der Version 1.0 vorliegt, befindet sich
das Video Distribution Profile noch in Entwicklung, es existieren derzeit keinerlei öffentliche Dokumente
für dieses Profil. [BAVW03b]
2.5.12 Audio/Video Remote Control Profile
Das Audio/Video Remote Control Profile stellt Funktionalitäten zu Verfügung, die die
Interoperabilität zwischen Bluetooth-Geräten mit Audio- und/oder Video-Fernsteuerungsfähigkeiten
sicherstellt. Das Profil baut auf dem AV/C Digital Interface Command Set (definiert durch die 1394 Trade
Association) auf und spezifiziert ein Format für die Übermittlung von Steuerungs- und KontrollNachrichten.
Nicht festgelegt ist in diesem Profil jedoch die Art der Interaktion mit dem Benutzer. Es können
zwar im einfachsten Falle jene Funktionen implementiert werden, die auch auf einer konventionellen IRFernbedienung zu finden sind, allgemein muss jedoch nur die Aktion des Benutzers (die zum Beispiel
auch aus Gesten bestehen kann) in entsprechende A/V-Kontroll-Signale übersetzt werden. [BAVW03c]
2.5.13 Serial Port Profile
Dieses Profil ermöglicht die Benutzung von Bluetooth-Verbindungen als Ersatz für serielle
RS232-Verbindungen. Ziel dieses Spezifikationsteils ist die Möglichkeit, beliebigen – auch bereits
bestehenden – Applikationen eine serielle Verbindung in Form von virtuellen, seriellen Ports anzubieten,
also eine serielle Verbindung zu emulieren.
Die genaue Implementierung der Ports ist betriebssystemabhängig, die Anbindung der Ports an
Bluetooth dagegen Inhalt dieses Profils. Einerseits ist dieses Profil kurz gehalten, da viele Richtlinien des
Generic Access Profile unverändert gelten, andererseits ist dieses Profil sehr allgemein gehalten, da es die
- 85 -
Basis für weitere Profile bildet, die bestimmte Anwendungsfälle konkreter spezifizieren (z.B. LAN
Access Profile).
2.5.14 Dial up Networking Profile und FAX Profile
Das Dial-up Networking Profile ermöglicht Datenendgeräten wie PCs oder Laptops die Benutzung
von Modems oder Geräten mit integriertem Modem (z.B. entsprechend ausgerüstete Mobiltelefone) die
folgenden Nutzungsszenarien, wobei je nach Netzwerk die Möglichkeit des Audio-Feedbacks beim
Aufbau der Verbindung oder auch später besteht:
Einwahlverbindung des Datenendgerätes über das Modem in ein externes Netzwerk (z.B.
Internet) oder Nutzung anderer Einwahldienste per Datenanruf (Data Call).
Empfang von Datenanrufen über das Modem.
Das Fax Profile ist sehr ähnlich zu dem Dial-up Networking Profile und ermöglicht in der
gleichen Gerätekonfiguration das Senden und Empfangen von Faxen. Es unterscheidet
sich vor allem durch die zusätzlich notwendige Integration von Fax Diensten nach
mindestens einem Standard aus Fax Class 1, Class 2.0 und Service Class 2, sowie der
fehlenden Unterstützung für Datenanrufe nach dem Dial-up Networking Profile.
2.5.15 Headset Profile
Das Headset Profile definiert Rahmenbedingungen für die Bluetooth Verbindung eines Headsets
(Kopfhörer oder Ohrhörer mit Mikrofon) mit anderen elektronischen Geräten (PC, Mobiltelefon etc.) zur
Übermittlung von Audio-Daten. Dabei können Audio-Daten bidirektional und im Vollduplex-Modus
ausgetauscht werden, d.h. das Headset kann nahezu gleichzeitig (Vollduplex) Audiodaten senden und
empfangen (bidirektional), wobei SCO-Verbindungen genutzt werden.
2.5.16 Hands-Free Profile
Das Hands-Free Profile ist dem Headset Profile sehr ähnlich und basiert wie dieses auf dem
Serial Port Profile. Es erlaubt ebenfalls eine bidirektionale Audio-Verbindung einer
Freisprecheinrichtung (Hands-Free-Unit) mit einem Audio-Gateway (typischerweise also einem
Mobiltelefon). Der Hauptunterschied liegt im Anwendungsszenario, da dieses Profil in erster Linie für
Freisprecheinrichtungen in Fahrzeugen konzipiert ist, wo die Freisprecheinrichtung örtlich getrennt von
Mobiltelefon fix im Fahrzeug eingebaut ist.
2.5.17 LAN Profile
- 86 -
Dieses Profil beschreibt verschiedene Möglichkeiten, wie verschiedene Geräte über das Point-toPoint-Protokoll (PPP) miteinander kommunizieren können:
Ein einzelnes Datenendgerät (Laptops ...) verbindet sich mit einem LAN Access Point,
um über diesen auf das angeschlossene LAN zugreifen zu können. Im verbundenen
Zustand arbeitet das Datenendgerät mit den gleichen Möglichkeiten und kann alle
Dienste des LAN benutzen, als wäre es über Dial-up Networking mit diesem Netzwerk
verbunden.
Wie zuvor, es nutzen jedoch mehrere Datenendgeräte einen LAN Access Point zur
Verbindung mit einem LAN. Zusätzlich können die Datenendgeräte jetzt über den LAN
Access Point miteinander kommunizieren.
Die PC-PC-Direktverbindung schließlich ermöglicht den direkten Austausch von Daten
zwischen zwei PCs ohne zusätzlichen LAN Access Point, indem ein PC die Rolle des
LAN Access Point übernimmt.
2.5.18 SIM Access Profile
Das SIM Access Profile definiert wie aus dem Namen ersichtlich jene Operationen, um via
Bluetooth auf SIM-Karten in Mobiltelefonen zuzugreifen, arbeitet also als ein drahtlos zugreifbarer SIMKartenleser. Das Hauptszenario, das diesem Profil zugrunde liegt, ist die Konfiguration eines im Auto
eingebetteten Mobiltelefons bzw. dessen SIM-Karte. Zum Beispiel könnte der Besitzer sein im Auto
eingebautes Telefon via Bluetooth ohne physische Verbindung konfigurieren. [BSIM03]
Abbildung 47: Anwendungsszenario SIM-Profile [17]
2.5.19 Generic Object Exchange Profile
- 87 -
Dieses Profil dient als generisches Basisprofil für alle Anwendungsfälle des OBEX Protokolls, es
basiert auf dem Generic Access Profile und dem Serial Port Profile. Das Anwendungsszenario in diesem
Profil ist daher der allgemeine Austausch von Objekten.
Da OBEX ursprünglich für den Einsatz über die IrDA-Schnittstelle gedacht war, sind
Modifikationen nötig, die in verschiedenen Teilen der Bluetooth Spezifikation zu finden sind: Die
Bluetooth-IrDA Interoperability Specification definiert, wie Applikationen über Bluetooth und IrDA
funktionieren, und beschreibt, wie OBEX über RFCOMM realisiert wird und erläutert schließlich
Application Profiles für OBEX über Bluetooth.
Das hier beschriebene Generic Object Exchange Profile definiert Anforderungen an die unteren
Protokollschichten (Baseband, LMP...) im Zusammenhang mit OBEX. Fünf spezielle Profile definieren
im Anschluss an diese Beschreibung jeweils ein allgemeines Application Profile für eine konkrete
Anwendung:
Object Push Profile (siehe Kapitel 2.5.20)
File Transfer Profile (siehe Kapitel 2.5.21)
Synchronization Profile (siehe Kapitel 2.5.22)
Basic Imaging Profile (siehe Kapitel 2.5.23)
Basic Printing Profile (siehe Kapitel 2.5.24)
2.5.20 Object Push Profile
In diesem Profil werden Richtlinien für den Austausch von standardisierten Objekten zwischen
zwei Bluetooth Geräten festgelegt, folgende Szenarien sind möglich:
Benutzung eines beliebigen Geräts (z.B. Mobiltelefon), um ein Daten-Objekt in den
Eingangsspeicher eines anderen Geräts (z.B. PDA) zu schieben (Push). Das Daten-Objekt
kann eine Business Card (vCard) oder auch ein Termin (vCal) sein.
Ein Gerät holt (Pull) eine Business Card (und nichts anderes) aus dem anderen Gerät.
Zwei Geräte tauschen Business Cards (und nichts anderes) aus, indem zuerst ein Push
und dann ein Pull ausgeführt wird.
2.5.21 File Transfer Profile
Bei Verwendung von OBEX liegt der Austausch und die Manipulation der grundlegendsten
Objekte eines Computersystems – den Files – natürlich nahe. Auf der Basis des GOEP sind folgende
Szenarien durch das File Transfer Profile beschrieben:
- 88 -
Benutzung eines Bluetooth Geräts (z.B. Laptop), um das Dateisystem eines anderen
Geräts zu durchblättern (browsing), indem Dateien und Ordner angezeigt werden und der
Benutzer durch die Ordner-Hierarchie navigieren kann.
Weiters können Objekte (Dateien und Ordner) zwischen zwei Geräten ausgetauscht
werden, entweder durch Kopieren oder durch Verschieben von Objekten vom Quellgerät
auf das Zielgerät.
Schließlich ist es möglich, Objekte (Dateien und Ordner) im jeweils anderen Gerät zu
manipulieren, inklusive dem Löschen von Objekten und der Erstellung neuer Ordner.
2.5.22 Synchronisation Profile
Beim Einsatz dieses Profils, das auf dem Generic Object Exchange Profile basiert, benutzt ein
Bluetooth Gerät (PC, Notebook) ein anderes Bluetooth Gerät (Mobile Phone, PDA), um zu
synchronisierende PIM (Personal Information Management)-Daten per Pull-Befehl zu holen, diese mit
den eigenen Daten zu synchronisieren und anschließend per Push-Befehl wieder zurück zu schreiben.
[17]
2.5.23 Basic Imaging Profile
Das Basic Imaging Profile basiert auf dem Generic Object Exchange Profile und wird eingesetzt,
um die Übertragung von Bildinformationen zu optimieren. Die Kommunikationspartner sind der Image
Initiator, üblicherweise ein PDA oder PC, und der Image Responder, etwa eine Digitalkamera. Der Image
Initiator gibt die Operationen vor, der der Image Responder auszuführen hat. Typischerweise könnte
dieses Profil eingesetzt werden, um Bilder von einer Digitalkamera (Responder) auf einen PC (Initiator)
zu laden. [17]
2.5.24 Basic Printing Profile
Das Basic Printing Profile basiert ebenfalls auf dem Generic Object Exchange Profile und wurde
entwickelt, um drahtloses Drucken zu ermöglichen. Es steht damit in direkter Konkurrenz zu dem
Hardcopy Cable Replacement Protocol, setzt allerdings eine Ebene höher an und ist einfacher aber nicht
so vielseitig einsetzbar. Das Client-Device (Sender), zum Beispiel ein PC, ein PDA oder auch ein
Mobiltelefon, sendet dabei das zu druckende Objekt an das Server-Device (Printer), wo es dann
ausgedruckt wird. [17]
- 89 -
2.6
Bluetooth 1.2
Am 5.11.2003 wurde von der Bluetooth SIG die Spezifikation 1.2 [BCOR03] verabschiedet. Diese
ist abwärtskompatibel mit der Spezifikation 1.1, bringt aber folgende Veränderungen mit sich [32]:
Faster Connections
Adaptive Frequency Hopping
Enhanced SCO
L2CAP Error and Flow Control
Enhanced Quality of Service
LMP & HCI Improvements
Zwei dieser Punkte, nämlich Faster Connections und Adaptive Frequency Hopping, sind
verpflichtend für Geräte, die konform zur Spezifikation 1.2 sein sollen. Alle anderen Punkte sind optional
und können bei Bedarf eingesetzt werden.
Die Gartner Group erwartet, dass ab dem Quartal 1/2004 Geräte nach Spezifikation 1.2 auf den
Markt kommen werden und sich in den nächsten 12-18 Monaten weitgehende durchsetzten werden
können. [26]
2.6.1 Faster Connections
Um die extrem hohen Verbindungszeiten von Bluetooth 1.1, die im schlechtesten Fall bis zu 10
Sekunden betragen können, zu verringern, wurden in Version 1.2 zwei grundlegende Veränderungen
vollzogen. Zum einen wurde die Inquiry-Phase beschleunigt, indem nun das FHS-Paket bereits beim
ersten Erkennen eines Inquiry-Paketes gesendet wird und nicht, wie bisher beim zweiten Mal. Alleine
damit kann die durchschnittliche Antwortzeit um 50% verringert werden.
Zum zweiten wurde sogennantes Interlaced Scanning eingeführt, dass in der Inquiry- und in der
Paging-Phase zum Einsatz kommt und die Antwortzeit nochmals halbiert. Im Wesentlichen damit wurde
die Möglichkeit geschaffen, die beteiligten Frequenzen schneller abzusuchen als in Bluetooth 1.1
(genauere Beschreibung siehe [32] und [BCOR03]).
- 90 -
Abbildung 48: Faster Connections [32]
Bei allen Veränderungen ist die Faster Connection jedoch immer noch abwärtskompatibel zu den
vorhergehenden Bluetooth-Varianten, wobei Geräte nach älterem Standard natürlich die verbesserten
Verbindungszeiten nicht erreichen.
2.6.2 Adaptive Frequency Hopping
Mit der wahrscheinlich größten Innovation, der Einführung von Adaptive Frequency Hopping,
begegnet Bluetooth der Herausforderung, nicht nur selbst störsicher zu sein, sondern auch andere
Technologien nicht über Gebühr zu stören. Insbesondere 802.11-WLANs wurden durch Bluetooth-Geräte
in räumlicher Nähe bisher oft empfindlich gestört.
Dazu wird die Hopping-Sequenz dynamisch verändert; es können Frequenzen, auf denen vermehrt
Störungen aufgetreten sind oder die von anderen Technologien benutzt werden, aus der Hopping-Sequenz
ausgeschlossen werden, wodurch diese von 79 auf bis zu 20 Hops reduziert werden kann. Außerdem
antwortet der Slave dem Master nun immer auf jener Frequenz, auf der auch der Master gesendet hat, was
das Erkennen von gestörten Kanälen erst möglich macht (ansonsten könnte die Hin- oder die RückFrequenz gestört sein).
- 91 -
Die aktuelle Hopping-Sequenz wird mittels LMP-Paketen, die jeweils eine Channel-Map
enthalten, vom Master an die Slaves übermittelt. In diesen Maps sind alle jene Frequenzen maskiert, die
nicht mehr benutzt werden dürfen. [32][26][BCOR03]
Abbildung 49: Frequency-Maps [32]
2.6.3 Enhanced SCO
SCO-Verbindungen wurden dahin gehend erweitert, als dass es nun möglich ist, auch SCO-Pakete
erneut zu senden, wenn sie korrumpiert wurden. Dazu wurden drei neue Pakettypen eingeführt (EV3,
EV4, EV5), die sich von den bekannten HVx-Paketen darin unterscheiden, dass sie zusätzlich ein CRCFeld enthalten, die Fehlererkennung und in weiterer Folge Neuübertragung erst ermöglicht. Damit ist es
nun auch möglich, Daten über SCO-Verbindungen zu übertragen. [32]
2.6.4 L2CAP error and flow control
L2CAP wurde ebenfalls hinsichtlich der Fehlersicherheit erweitert. Dazu wurden auch hier CRCFelder eingeführt, zusätzlich existieren Flow-Control-Bits, die zusammen mit den ebenfalls neuen
Sequence- und Acknowledge-Numbers eine Neuübertragung von fehlerhaften Paketen nun auch auf Ebene
- 92 -
des L2CAP-Protokolls ermöglichen (bisher wurde von L2CAP die Verbindung unterbrochen, wenn es
dem Baseband nicht möglich war, das Paket innerhalb einer vorgegebenen Zeit zu übertragen).
[32][BCOR03]
Abbildung 50: Die neue L2CAP-Architektur [BCOR03]
2.6.5 Enhanced Quality of Service
Mit Enhanced Quality of Service ist es nun möglich, gewissen Verbindungen verbindlich höhere
Prioritäten einzuräumen, um zum Beispiel in einem Piconetz unterbrechungsfrei Musik hören zu können,
während gleichzeitig der Drucker oder die Maus bedient wird. Dies war bei Verwendung der
Spezifikation 1.1 zwar ebenfalls möglich aber schwerer handlebar und unzuverlässiger, da zwischen den
L2CAP und HCI-Definition von QoS Differenzen auftraten. Außerdem ist QoS nun auch bidirektional
nutzbar (bisher galt das konfigurierte QoS nur jeweils unidirektional). [32][26]
2.6.6 LMP & HCI Improvements
Das Link Manager Protocol wurde insofern verbessert, als dass durch die Erhöhung der OpCodeSize von 7 auf 15 Bit die Anzahl der möglichen Befehle erhöht wurde. Weiters wurde die
Vorgehensweise beim Empfang eines ungültigen OpCodes spezifiziert.
- 93 -
Das Host Controller Interface kennt nun zwei neue Befehle, mit denen einerseits der LMP-Handle
für SCO-Verbindungen abgefragt werden kann und anderseits die Bluetooth Clock eines Devices und
deren Genauigkeit abgefragt werden können.
2.6.7 Verworfene Verbesserungen
Bis kurz vor der Veröffentlichung der Spezifikation 1.2 waren noch zwei weitere Verbesserungen
geplant, die aber auf Grund von mehreren ungeklärten technischen Fragen wieder verworfen wurden:
Anonymity Mode
Scatter Mode and Absence Masks
Der Anonymity Mode hätte den Vorteil gebracht, dass Geräte, die sich in ein Piconetz einbinden,
nicht von vorne hinein ihre Adresse preisgeben müssen. Der Verbindungsaufbau mit dem Master erfolgt
mittels einer zufällig gewählten Adresse. Die realen Adressen werden erst ausgetauscht nachdem diese
Verbindung gesichert ist. Die Verbindung wird dann wieder getrennt und mittels der realen Adressen
wieder aufgebaut. Derzeit gibt ein Gerät schon mit der ersten Antwort auf ein Inquiry seine Adresse preis.
Scatter Mode and Absence Masks bringen Vorteile im Management von Scatternets und erhöhen
die Effizienz der Kommunikation in diesen. Der Scatter Mode definiert periodische Pakete, die vom
Master zu Synchronisierungszwecken an die Slaves gesendet werden. Dies erlaubt es den Devices, die die
Schnittstelle in Scatternets bilden, also in zwei Piconets enthalten sind, die Zeiten, in denen in einem
Piconet gehorcht wird, zu optimieren. Mit Absence Masks können Zeitspannen festgelegt werden, in
denen ein Device in einem Piconet nicht aktiv teilnimmt. Absence Masks können also von dem
Scatternet-Device genutzt werden, um einem Master mitzuteilen, dass gerade mit dem anderen Master
kommuniziert wird. [32]
2.7
Performance
Für viele Anwendungsszenarien mit bewegten Bluetooth-Geräten spielt die Performance eine
große Rolle, weshalb in diesem Kapitel auf entsprechende empirische Ergebnisse und
Simulationsmöglichkeiten eingegangen wird.
2.7.1 Performance-Evaluation durch empirische Analyse
Ein wesentlicher Punkt für den Einsatz von Bluetooth in mobilen Umgebungen ist die Dauer des
Verbindungsaufbaus zwischen zwei bewegten Bluetooth-Geräten. Dauert dieser zu lange, kann es
- 94 -
passieren, dass kein Verbindungsaufbau zustande kommt oder nicht mehr genug Zeit bleibt die
gewünschten Daten zu übertragen. Nach der Bluetooth-Spezifikation beträgt die maximale Zeit für den
Verbindungsaufbau 10 sec. Experimente von [Murp02] mit fünf Bluetooth-Geräten – diese befanden sich
in Sichtweite auf offenem Gelände ohne störende Interferenzen – haben nach über 500 Testläufen
ergeben, dass der Median für den Verbindungsaufbau zwischen Master und einem der Slaves unter 2 sec
liegt.
Überraschende Ergebnisse zeigten sich auch bei der Reichweite. Laut Spezifikation liegt sie für
Klasse 1-Geräte bei 100 m und für Klasse 2-Geräte bei 20 m. Die Experimente von [Murp02] haben
allerdings ergeben, dass Klasse 1-Geräte eine Reichweite von bis zu 250 m und Klasse 2-Geräte von bis
zu 122 m haben, wobei die Datenrate über die gesamte Reichweite nahezu konstant hoch bleibt (siehe
Abbildung 51). [Murp02]
Abbildung 51: Reichweite vs. Durchsatz [Murp02]
2.7.2 Performance-Evaluation durch Simulation
Der BlueHoc-Simulator [65] – derzeit in Version 2.0 erhältlich – ist eine Erweiterung für den
Netzwerksimulator ns-2 um Bluetooth-Netzwerke zu simulieren und steht unter der IBM Public License
- 95 -
(IPL) von IBM developerWorks zum Download bereit. BlueHoc simuliert die unteren Schichten Radio
(GFSK-Modulation, Frequency Hopping, statistische Modelle für Paketverluste etc.) und Baseband
(Unterstützung von Inquiry, Paging, Polling, ACL und ARQ, Zustandsmaschine für den Link Controller)
des Bluetooth Protokollstacks sowie LMP und L2CAP (Simulation der Signalisierung für den
Verbindungsaufbau, Unterstützung mehrerer gleichzeitiger L2CAP-Verbindungen, Segmentierung,
Reassemblierung, Protokoll-Multiplexing etc.).
BlueHoc versteht sich als Plattform, um die Leistung von Bluetooth-Systemen zu evaluieren und in
weiterer Folge zu verbessern:
Messung der Leistungsfähigkeit beim Device Discovery
Nachvollziehen des Verbindungsauf- und -abbaus
Betrachtung des Wirkens von QoS-Maßnahmen
Performance von auf TCP/IP basierenden Anwendungen
Erfassung von Daten bei verschiedenen Innenraumverhältnissen
Der Netzwerksimulator ns-2 [64] ist ein objektorientierter diskreter Open Source-EreignisSimulator für die Netzwerkforschung und ist in diesem Bereich ein de-facto-Standard; ein anderer
bekannter Simulator ist OpenNet. ns-2 unterstützt Simulationen von TCP, Routing und MulticastProtokollen über drahtgebundene sowie drahtlose Netzwerke, ist in C++ geschrieben und nutzt OTcl für
graphische Oberflächen zur Erzeugung von Simulationsszenarien. Bzgl. der Verwendung von ns-2 ist
allerdings negativ anzumerken, dass die Dokumentation relativ schlecht und ein hoher
Einarbeitungsaufwand erforderlich ist. Zu ns-2 gibt es noch den Netzwerk-Animator NAM, der ein
Visualisierungstool für ns-2 ist und verwendet werden kann, um die durch ns-2 erzeugten
Simulationsergebnisse darzustellen.
Auf die Installation von ns-2 und BlueHoc wird an dieser Stelle nicht eingegangen, entsprechende
Installationsanleitungen finden sich unter [64] und [65].
Nach erfolgter Installation können Simulationsszenarien via Tcl textuell erstellt werden, BlueHoc
bietet aber auch eine grafische Unterstützung (siehe Abbildung Abbildung 52). Das Setzen der einzelnen
Bluetooth-Geräte erfolgt mit der rechten Maustaste, wobei beim ersten Mal der Master und anschließend
die Slaves gesetzt werden. Durch einen Doppelklick können die Knoten konfiguriert werden:
Konfiguration des Masters: Startzeit in Sekunden, Inquiry TimeOut, Anzahl der
Antworten auf das Inquiry
Konfiguration des Slaves: Startzeit in Sekunden (typischerweise nach dem Master),
Startzeit des Inquiry Scans
- 96 -
Abbildung 52: Konfiguration des Masters [65]
Bei der Konfiguration der Links kann man als Applikation zwischen FTP, Telnet und einer
Sprachverbindung wählen. Die Simulation kann schließlich mit einem run-Kommando über die Konsole
gestartet werden. Beginnend mit dem Master werden die Knoten durchnummeriert und man kann das
Aussenden von Inquiry-Paketen erkennen; durch Farbe und Kennzeichnung kann man die Zustände
(Standby, Inquiry, Parked), in denen sich die Geräte befinden, erkennen. Der Signalisierungsablauf kann
auf der Konsolenausgabe verfolgt werden, die auch zusätzliche Informationen zur grafischen Ausgabe
enthält. Am Ende befinden sich alle Geräte im Zustand Connection, und die eigentliche Übertragung, die
an den visualisierten Paketen erkennbar ist, läuft. Abbildung 53 zeigt die Simulation eines Piconetzes mit
einem Master und drei Slaves, die sich in unterschiedlichen Zuständen (Connected, Standby, Inquiry
Scan und Page) befinden. [Merk02] [65]
- 97 -
Abbildung 53: Visualisierung einer Bluetooth-Simulation mit NAM [70]
BlueWare 1.0 [71] ist eine Weiterentwicklung von BlueHoc zur Performance-Evaluation von
Bluetooth Piconetzen und Scatternetzen, wobei ein Großteil des Codes von BlueHoc überarbeitet und um
viele zusätzliche Funktionen erweitert wurde. Blueware implementiert die meisten Teile des Bluetooth
Protokollstacks der Version 1.1 (siehe Abbildung 54). [Tan02]
- 98 -
Abbildung 54: Gegenüberstellung Bluetooth-Stack und Blueware-Module [Tan02]
2.8
Bewertung
Betrachtet man den aktuellen Entwicklungsstand der Bluetooth-Technologie, so fällt zuerst auf,
dass das Ziel, einen möglichst einfachen und klaren Standard zu definieren, klar verfehlt wurde. Die
Bluetooth-Spezifikation 1.2 ist auf 1200 Seiten angewachsen, dazu kommen nochmals ca. 1000 Seiten an
Profil-Spezifikationen. Diese Komplexität liegt aber vor allem in der ungeheuren Vielseitigkeit von
Bluetooth begründet.
Die Bluetooth-Technologie kann in Anbetracht der spezifizierten Profile und Einsatzszenarien in
annähernd jedem Bereich der Short-Range-Daten- und Audio-Übertragung eingesetzt werden. In den
jeweiligen Einzelbereichen mag es Technologien geben, die performanter als Bluetooth sind und besser
geeignet erscheinen, hinsichtlich der Vielseitigkeit und der Kostengünstigkeit bleibt Bluetooth aber
derzeit unerreicht. Im Bereich der Short-Range-Audio-Übertragung ist Bluetooth sogar die eindeutig
beste Lösung, solange keine HiFi-Qualitätsansprüche gestellt werden (Headset-Szenario). Bluetooth war
auch die erste Technologie, der von der IEEE – unter der Bezeichnung 802.15.1 – standardisiert wurde.
Die Möglichkeit, einerseits synchrone aber unzuverlässige Datenübertragung und andererseits
asynchrone aber verlässliche Datenübertragung „gleichzeitig über den gleichen Funkkanal“ (eigentlich
- 99 -
gemultiplext und unter Einsatz von Frequency Hopping) zu realisieren, ist ein einzigartiges Feature von
Bluetooth und muss an dieser Stelle als großer Pluspunkt vermerkt werden.
Bluetooth zeigt sich aufgrund des eingesetzten Frequenzsprungverfahrens äußerst robust
gegenüber Störungen, so dass es auch im industriellen Umfeld eingesetzt werden kann. Die Ausnutzung
des gesamten verfügbaren Spektrums verursacht aber immer wieder Störungen von anderen im 2,4-GHzBand funkenden Technologien wie 802.11b. Das mit Bluetooth 1.2 eingeführte Adaptive Frequency
Hopping schafft hier Abhilfe und ermöglicht ein „friedliches“ Nebeneinander der verschiedenen
Funktechnologien.
Der Verbindungsaufbau von Bluetooth-Geräten dauert derzeit inakzeptabel lange: Es werden bis
zu 10 Sekunden benötigt, bis neue Geräte gefunden werden. Die Spezifikation 1.2 schafft hier Abhilfe,
die maximale Verzögerung wird auf 25 % Prozent – also 2,5 Sekunden – gesenkt. Je nach
Anwendungsfall kann die hohe Verzögerung zwar unkritisch sein, betrachtet man aber zum Beispiel sich
aneinander vorbeibewegende Geräte, so macht diese Schwäche eine Verbindungsaufnahme im
Normalfall gänzlich unmöglich.
Ein Bluetooth-Piconetz ist auf 8 aktive Geräte beschränkt. Für Standard-Anwendungen wird das
ausreichen, ein komplexeres Sensornetzwerk wird damit aber nur schwer aufgebaut werden können
(außerdem gibt es für diesem Bereich besser geeignete Technologien). Der Standard kennt auch
Scatternetze, bei denen sich ein Gerät in zwei Piconetzen befindet und diese so verbindet. Uns sind
derzeit jedoch keine Consumer-Geräte bekannt, die Scatternetze unterstützen; somit ist die Anwendung
dieser Betriebsart im Moment eher schwierig. Die Anzahl der Geräte in einem Piconetz kann auch erhöht
werden, indem diese passiv warten, bis sie vom Master wieder aktiviert werden. Zwar können bis zu 255
Geräte in diesem Modus verwaltet werden, die Aktivierungszeiten sind jedoch so hoch, das ein ständiges
Switching zu erheblichen Leistungseinbußen führen würde.
Die Quality-of-Service-Unterstützung ist bis Bluetooth 1.1 eher rudimentär und nicht verlässlich.
Der Standard sieht verpflichtend lediglich eine Best-Effort-Unterstützung vor, alle darüber hinaus
gehenden Modi sind optional. Ab Bluetooth 1.2 ist das Quality-of-Service-Management soweit
verbessert, dass bei störungsfreier Funkverbindung die Datenrate einzelner Kanäle garantiert werden
kann.
Das Service-Management von Bluetooth bietet mit dem Service-Discovery-Protocol ein mächtiges
Werkzeug zur Veröffentlichung und Suche von Diensten innerhalb eines Piconetzes. Die Verwendung
von 128-bit-UDDIs zur Service-Identifikation stellt hinsichtlich der Erweiterbarkeit keinerlei Grenzen
auf. Hervorzuheben ist auch die Möglichkeit, die Services eines Gerätes hierarchisch zu durchsuchen um
so einen Überblick über dessen Fähigkeiten zu erhalten.
- 100 -
Eines der wichtigsten Features von Bluetooth ist die Fähigkeit, bestehende drahtgebundene
Schnittstellen wie RS232, USB oder ISDN zu emulieren und so die Möglichkeit zur Wiederverwendung
bestehender Software und Treiber zu ermöglichen. Insbesondere von der Möglichkeit der Emulation einer
oder mehrerer RS232-Schnittstellen über RFCOMM wird schon im Standard selbst ausgiebig Gebrauch
gemacht, setzt doch via PPP der gesamte Internet-Stack auf dieser emulierten seriellen Schnittstelle auf.
Die schon erwähnte Vielseitigkeit von Bluetooth schlägt sich auch in der Spezifikation der Profile
nieder. Während in der ersten Tranche die Anwendungsszenarien der dort spezifizierten Profile noch
weitgehend disjunkt waren, zeigt sich seit der Veröffentlichung der neueren Profile im Mai 2003 ein
gewisser Hang zur Redundanz, was die Anwendbarkeit bestimmter Szenarien betrifft. So unterscheiden
sich die Profile „Headset“ und „Hands-Free“ nur in kleinen Details, Ethernet-Traffic kann jetzt nicht nur
via RFCOMM und PPP sondern auch direkt mittels dem PAN-Profil und dem Bluetooth Network
Encapsulation Protocol via L2CAP in ein Piconetz eingeschleust werden. Ob diese Vielseitigkeit jedoch
ein Vorteil ist, darf bezweifelt werden, da nun die Interoperabilität von mehreren Geräten innerhalb eines
Anwendungsszenarios nicht mehr gegeben ist. Ein nicht zu bestreitender Vorteil ist jedoch, dass die
neuen Profile die Realisierung von Anwendungsszenarien auf einer niedrigeren Ebene im Protokollstack
ermöglich, was eine Vereinfachung der Hardware besonders auf kleinen Endgeräten ermöglicht. So ist es
zum Beispiel möglich, Eingabegeräte wie Mäuse nun via HID-Profil direkt auf L2CAP aufsetzen zu
lassen, wo früher eine Implementierung des Serial Port Profiles mit RFCOMM notwendig war.
Folgende Tabelle sollte noch einmal die Eigenschaften und Einschränkungen von Bluetooth
zusammenfassen:
- 101 -
Tabelle 1: Bluetooth Eigenschaften und Einschränkungen [Bray02]
Eigenschaften
Beschränkungen
Point to Point- und Point to Multipoint-
Beschränkung
Verbindungen
Piconetz, beschränkte Erweiterung via
Scatternetz
Sprach- und Datenverbindungen
Geringe Reichweite
Kompakt und billig
Kein Handover möglich
Geringer Stromverbrauch
Maximale Datenrate von 723,2 kBit/s
Robustes Frequenzsprungverfahren,
Verwendung des überfüllten ISM-
Fehlerkorrektur
Bandes
Profile sichern Interoperabilität auf
Langsamer Verbindungsaufbau
auf
8
Geräte
pro
Anwendungsebene
Hohe Sicherheit durch
Frequenzsprungverfahren,
Verschlüsselung und Authentifizierung
Nutzung des lizenzfreien ISM-Bandes
Viele der noch bestehenden Probleme sollen mit Versionsnummer 2.0, die aber nicht vor 2004
erwartet wird, behoben werden (siehe dazu auch Kapitel 3.6, Bluetooth 2.0).
- 102 -
3 Verwandte Technologien
3.1
IrDA
IrDA (Infra Red Data Association) [67] ist ein Standard zur drahtlosen Datenübertragung mittels
Infrarot-Strahlung. IrDA ist seit 1994 verfügbar und wurde zur drahtlosen Kommunikation mit
Peripheriegeräten und zur Short-Range-Datenübertragung konzipiert. Der Standard steht hinsichtlich
seiner Einsatzgebiete also in direkter Konkurrenz mit Bluetooth.
Es existieren zwei unterschiedliche Standards zur Abdeckung der verschiedenen Einsatzgebiete.
IrDA-DATA wurde zur drahtlosen Übertragung von Daten zwischen zwei Endgeräten konzipiert und
bietet einen maximalen Datendurchsatz von 1,152 MBit/s (SIR, Serial Infrared), 4 MBit/s bei einer
maximalen Reichweite von 2 Metern (FIR, Fast Infrared) oder 16 MBit/s bis maximal 20 cm (VFIR,
Very Fast Infrared). Durch den Einsatz von CRC wird eine fehlerfreie Datenübertragung gewährleistet,
Verschlüsselungsmechanismen sind nicht vorgesehen.
IrDA-CONTROL bietet Funktionalitäten zur drahtlosen Kommunikation mit Endgeräten wie
Tastatur, Maus oder Drucker. Diese Spezifikation bietet einen maximalen Datendurchsatz von 75
kBit/sec bei einer Reichweite von mindestens 5 Metern. Dabei ist ein Multiplexing-Mode vorgesehen, der
eine 1:n-Verbindung mit max. 8 Peripheriegeräten gleichzeitig erlaubt.
IrDA war einige Jahre der Standard zur Lösung des „Last-Meter-Problems“ und steht damit in
direkter Konkurrenz zu Bluetooth: Es bietet zwar höhere Datenraten, benötigt aber eine Sichtverbindung
und hat eine geringere Reichweite als Bluetooth. Auch heute noch kommt fast jedes mobile Endgerät mit
einer IrDA-Schnittstelle. In Bluetooth wurde der weiten Verbreitung von IrDA und der großen Anzahl
von verfügbaren Anwendungen insofern Rechnung getragen, als dass das OBEX-Protokoll, dass aus der
IrDA-Welt kommt, in den Protokollstack mit aufgenommen wurde, um eine reibungslose Transition zu
ermöglichen. [Bray02] [Mobi03]
3.2
WLAN (802.11x)
WLAN (wireless LAN) der IEEE 802.11x-Familie [10] ist eine drahtlose Netzwerkinfrastruktur,
die sich heute weitgehend durchgesetzt hat. Es ist zur Erweiterung oder zum Ersatz von drahtgebundenen
- 103 -
Netzwerken konzipiert. Im Normalfall bestehen WLANs aus mindestens einem Accesspoint, der als
Übersetzer vom drahtgebundene ins drahtlose Netzwerk fungiert, sowie einer Menge von Endgeräten. Es
sind aber auch Peer-to-Peer-Vernetzungen ohne Accesspoint möglich.
Abbildung 55 WLAN-Infrastruktur [Mobi03]
Der aktuelle Standard, der in Europa derzeit zur Anwendung kommt, ist IEEE 802.11b, der eine
Datenübertragung mit bis zu 11 MBit/sec erlaubt. Der kommende Standard IEEE 802.11g ermöglicht
eine Datenrate von bis zu 54 Mit/sec; erste Adapterkarten und Access-Points für diese Technologie sind
bereits verfügbar.
WLAN erlaubt neben der Kommunikation über Access-Points, die untereinander drahtgebunden
vernetzt sind, auch eine Peer2Peer-Vernetzung zum unmittelbaren Datenaustausch zwischen
Endstationen. Optional ist eine Roaming-Funktionalität verfügbar, so dass eine Station, deren Verbindung
schlecht ist, automatisch einen Accesspoint mit besserer Verbindung auffinden und sich mit diesem
verbinden kann.
Problematisch beim IEEE 802.11b-Standard ist die mangelhafte Sicherheit durch den Einsatz der
relativ einfach zu knackenden Wireless Equivalent Privacy (WEP)-Verschlüsselung. Durch ein
ausreichend langes Abhören des Netzwerkverkehres kann mit einfachsten (Software-)Mitteln Zugang zu
einem WLAN erlangt werden. Dies ist umso sicherheitskritischer, als dass der Empfangs- & SendeBereich von WLANs nicht an Gebäudegrenzen endet sondern unter Umständen auch auf angrenzenden
öffentlichen Straßen verfügbar ist.
WLANs sind mittlerweile schon in vielen Unternehmen und Universitäten, aber auch an
öffentlichen Plätzen wie Flughäfen und Bahnhöfen verfügbar. Problematisch ist im Moment noch die
Zugangsregelung zu WLANs, es existiert kein Anbieter-übergreifendes Roaming wie bei GSM-Netzen.
- 104 -
Derzeit ist noch weitgehend eine Registrierung für jedes WLAN notwendig, mit steigender Verbreitung
sollte sich aber auch in diesem Bereich eine Lösung abzeichnen. Technisch gesehen wird sich in den
nächsten Jahren der Standard IEEE-802.11g durchsetzen. [Mobi03]
Bluetooth und 802.11x sind nicht als Konkurrenz zueinander zu sehen, vielmehr ergänzen sie sich
und decken verschiedene Bereiche des Anwendungsspektrums ab.
3.3
DECT
DECT ist eine mittlerweile schon betagte Technologie, die mit niedrigen Kosten, hohem
Datendurchsatz und besonderen technischen Eigenschaften eine interessante Technik für Sprach- und
Daten-Kommunikation darstellt. Das Zugriffsverfahren TDMA (Time Division Multiple Access) erlaubt
sehr viele gleichzeitige Nutzer in einer Zelle. Die Sprach-Codierung ADPCM (Adaptive Differential
Pulse Code Modulation) sorgt für eine hohe Sprachqualität. Das Verfahren, das die Qualität der
Funkkanäle kontrolliert und dafür sorgt, dass diese immer optimal ist, heißt DCS/DCA (Dynamic
Channel Selection / Allocation). Weitere Features sind Verschlüsselung, intelligente Mechanismen, um
die Akku-Lebensdauer mobiler Geräte zu maximieren und Übergänge zu wichtigen anderen Netzen wie
ISDN und GSM. [30]
DECT ist durchaus auch für WPANs zu verwenden, es bietet aber abgesehen von der großen
Verbreitung und der hohen Anzahl verfügbarer Geräte keine Vorteile gegenüber Bluetooth, welches
DECT in beinahe allen Bereichen an Leistung übertrifft. Deshalb ist nicht zu erwarten, dass sich DECT
gegenüber Bluetooth erfolgreich positionieren kann. [DECT02]
3.4
HiperLAN2
HiperLAN2 ist ein 54 Megabit pro Sekunde schneller Standard für WLANs, steht also nicht in
direkter Konkurrenz zu WPAN-Technologien wie Bluetooth oder ZigBee. HiperLAN2 nutzt das 5-GHzBand und wurde von dem ETSI (European Telecommunication Standards Institute) [6] und dem BRAN
(Broadband Radio Access Network) entwickelt. Damit steht HiperLAN2 in direkter Konkurrenz zu IEEE
802.11g, dem Nachfolger des derzeitigen, 11 MBit/s schnellen Standards IEEE 802.11b ("Wi-Fi" [56]).
Anders als z.B. in den USA ist das 5-GHz-Frequenzband in Europa nicht zur allgemeinen Nutzung
freigegeben, sondern für spezielle Kommunikations-Anwendungen wie HiperLAN2 reserviert. Auf diese
Weise kann ein relativ störungsfreier Betrieb gewährleistet werden, da keine anderen Geräte (wie
Funkgeräte oder auch Mikrowellen-Öfen) das Signal stören können. [31]
- 105 -
Trotzdem ist eher nicht zu erwarten, dass sich HiperLAN2 durchsetzen wird, da Netzwerke nach
802.11x heute schon so weit verbreitet sind, dass der Umstieg auf eine vollkommen neue Technologie
eher schwer durchzusetzen sein wird.
3.5
ZigBee
Eine völlig neuartige Technologie zur drahtlosen Datenübertragung ist ZigBee [68]. Sie ist durch
niedrige Übertragungsgeschwindigkeiten, geringe Kosten sowie einen beinahe vernachlässigbaren
Stromverbrauch charakterisiert und eignet sich hauptsächlich für Telemetrie-Applikationen wie
beispielsweise der Fernüberwachung durch automatische Übertragung von Messwerten bzw. Messdaten
und zur Fernsteuerung.
Die Entwicklung des Standards durch die ZigBee Alliance gemeinsam mit dem IEEE (im Rahmen
von 802.15.4) soll noch 2003 abgeschlossen sein; ob dieses Ziel erreicht wird, ist jedoch fraglich. Mit der
Verfügbarkeit des Final-Standards ist eher erst im Laufe des Jahres 2004 zu rechnen, erste Geräte werden
mit Ende 2004 kommerziell erhältlich sein. Das ZigBee-Konzept wurde federführend von Philips,
Motorola, Honeywell und Invensys entworfen. An der Definition des Standards arbeiten mehr als 20
Unternehmen mit, darunter vor allem Halbleiterhersteller und OEMs (Original Equipment
Manufacturers).
Das Netz wird in drei Frequenzbereichen arbeiten können: Im lizenzfreien 2,4 GHz ISM-Band
(Industrial-Scientific-Medical), im europäischen 868 MHz-Band und im US-amerikanischen 915 MHz
ISM. Die Übertragungsgeschwindigkeit erreicht bei 2,4 GHz 250 kBit/s (in den niedrigeren
Frequenzbändern 20 bzw. 40 kBit/s), die Reichweite 10 bis maximal 75 Meter.
Bemerkenswert ist der geringe Energieverbrauch. Bei überwiegendem Stand-by-Betrieb und
jeweils nur kurzen Aktivierungszeiten kann ein ZigBee System mit zwei gewöhnlichen AA-Batterien bis
zu zwei Jahre betrieben werden.
Das mögliche Anwendungsfeld reicht von der Haustechnik mit Steuerung bzw. Regelung von
Heizung / Klima / Lüftung, Beleuchtung und Jalousien, Rauchmeldern und Schadstoffdetektoren über
Türöffner bis zu Alarmanlagen und Notrufsysteme für ältere oder behinderte Menschen. Auch UniversalFernbedienungen für TV-Geräte und HiFi-Anlagen können damit gesteuert werden. Bei entsprechender
Ausstattung von „Weißer Ware“ werden sich auch Waschmaschinen oder Geschirrspüler mit ZigBee
bedienen lassen. ZigBee kennt dabei zwei verschiedene Arten von Devices:
Full Function Devices implementieren die gesamte ZigBee-Funktionalität, können als
Coordinator fungieren und mit jeder der in Abbildung 56 gezeigten Topologien umgehen.
- 106 -
Reduced Function Devices haben eine extrem einfache Architektur und niedrigen
Energiebedarf, können aber nur in Stern-Topologien eingesetzt werden und nur direkt mit
dem Coordinator kommunizieren, der immer ein Full Function Device sein muss.
Abbildung 56: Mögliche Netztopologien in ZigBee [27]
Der niedrige Investitionsaufwand und die mögliche Größe der Netze werden nach den Prognosen
der Initiatoren eine rasche Verbreitung fördern: Die Materialkosten für das Funkmodul werden zunächst
bei 6 USD pro Stück liegen, aber schnell auf 2 bis 3 USD sinken – weniger als jeder andere Prozessor für
Funksysteme kostet. Ein ZigBee Netz kann aus einem Master und bis zu 254 Clients bestehen; am
gleichen Ort können bis zu 100 Netze eingerichtet werden. Die einzelnen Clients – die natürlich von
verschiedenen Herstellern stammen können - lassen sich problemlos anbinden.
Erste Prognosen gehen davon aus, dass in sechs bis sieben Jahren die Haustechnik mit einem
Marktanteil von zwei Drittel das dominierende ZigBee Anwendungsfeld sein wird. Die Zahl der Clients
in einem Haus könnte im Durchschnitt bei 50, nach optimistischen Schätzungen sogar dreimal so hoch
liegen.
Zum Schutz vor unbefugtem Zugriff auf Daten werden vom IEEE gegenwärtig geeignete
Verschlüsselungsmethoden evaluiert, die – abhängig vom konkreten Bedarf – implementiert werden
können.
- 107 -
Die gemeinsame Nutzung des 2,4 GHz Frequenzbandes durch Bluetooth und ZigBee dürfte keine
Probleme verursachen: Da die Arbeitszyklen in ZigBee-Netzen seltener und kürzer sind, ist die
Wahrscheinlichkeit von Störungen einer Bluetooth Übertragung gering. Sollte umgekehrt ein Bluetooth
Datentransfer das konkurrierende ZigBee Netz beeinträchtigen, würden etwa zerstörte Datenpakete
neuerlich gesendet.
Funktechnisch unterscheidet sich ZigBee klar von Bluetooth. Ein Datenpaket ist bei ZigBee mit 28
kByte deutlich kleiner als bei Bluetooth (250 kByte) und die Übertragungsgeschwindigkeit mit 250 kBit/s
gegenüber 1 Mbit/s deutlich niedriger. Hingegen ist ZigBee’s Vernetzungsfähigkeit von insgesamt 250
Geräten (gegenüber acht bei Bluetooth) und die Reichweite mit durchschnittlich 30 m (gegenüber etwa
10 m) höher. Bluetooth ist für die drahtlose Übertragung großer Datenmengen bestimmt, etwa zwischen
Mobiltelefon und Headset. ZigBee kann seine Stärke beim Transport geringer Datenmengen – zum
Beispiel für Steuersignale oder in Sensornetzwerken (Wireless Sensor Networks) – entfalten. In einem
schmalen Segment stehen beide Technologien jedoch durchaus in Konkurrenz zueinander – etwa bei
kabellosen Computertastaturen oder Funk-Mäusen. [FMK02] [27]
3.6
Bluetooth 2.0
Über die Bluetooth-Spezifikation 2.0 ist noch sehr wenig bekannt, es existiert lediglich eine kurze
Stellungnahme des Ericsson-Chefentwicklers Jan Haartsen, die jedoch schon von Mitte 2003 datiert. Es
ist davon auszugehen, dass der Standard zwar schon weitgehend ausgearbeitet ist, da ursprünglich eine
Veröffentlichung schon für Ende 2003 kolportiert wurde; aus der Bluetooth SIG dringen hier jedoch
keine Informationen nach außen. Durch die Veröffentlichung der Spezifikation 1.2 im November 2003 ist
davon auszugehen, dass Bluetooth 2.0 noch einige Zeit auf sich warten lässt.
Dennoch steht wohl schon fest, dass Bluetooth 2.0 mit Bruttotransferraten von 4, 8 und 12 MBit/s
operieren soll. Die Reichweite bleibt jedoch auch weiterhin auf 10 Meter beschränkt. Die höheren
Transferraten erzielt das Verfahren durch die Nutzung eines Schmalbandkanals unter Verzicht auf
Bandspreizung sowie die Nutzung von verteilten MAC-Protokollen, erläuterte Haartsen.
Die
neuen
Protokolle
beseitigen
das
Master/Slave-Problem
derzeitiger
Piconets,
die
zusammenbrechen, sobald der Master das Netz verlässt. Bei Bluetooth 2.0 operiert jedes Device als
"Supervisor" und erhält gegebenenfalls das Piconet aufrecht. Zudem implementieren die Bluetooth 2.0Protokolle die Fähigkeit zu Broad- und Multicasting. [28]
- 108 -
Die neuen Fähigkeiten sind allerdings mit einer gegenüber Bluetooth 1.0 verdoppelten
Stromaufnahme zu bezahlen. Der Chipsatz-Preis soll sich gegenüber den jetzigen Varianten jedoch um
maximal 20 Prozent erhöhen. [28]
3.7
Ultra Wideband
Utra Wideband (UWB) [69] ist ein vollkommen neuer Ansatz für die Übertragung von Daten mit
hoher Geschwindigkeit. Daten werden mittels einer Folge von extrem kurzen Pulsen übertragen, wobei
eine extrem große Bandbreite verwendet wird. Die verwendete Sendeleistung kann dabei jedoch so gering
gehalten werden, dass der Signalanteil auf einzelnen Frequenzen kleiner als das Rauschen in
schmalbandigen Übertragungsverfahren ist und damit keine bestehenden Systeme beeinflussen sollte. In
der Praxis ergeben sich mehr oder weniger große Störungen (je nach untersuchender Stelle).
Abbildung 57: Frequenzspektrum bei Ultra Wideband [29]
UWB wurde im Februar 2003 von der FCC (Federal Communications Commission,
Fernmeldebehörde der USA) zur Verwendung zugelassen, eine weltweite Genehmigung durch die ITU
steht noch aus, auch haben noch keine Staaten außer den USA UWB zur Verwendung freigegeben.
UWB selbst legt nur das Konzept einer breitbandigen Datenübertragung fest, die konkrete
Implementierung wie zum Beispiel auch das eingesetzte Modulationsverfahren bleiben den jeweiligen
Herstellern überlassen. Es existieren jedoch bereits Standardisierungs-Initiativen wie zum Beispiel IEEE
802.15.3a [11], die den Einsatz von UWB für WPANs standardisieren sollen. Dieser Standard soll im 2.
Halbjahr 2004 finalisiert werden.
- 109 -
Allen Varianten von UWB ist jedoch gemein, dass sie zur Übertragung extrem kurze Pulse (<1 ns)
mit hohen Wiederholungsraten (>1 GHz) verwenden, wobei die Codierung von Binärinformationen je
nach eingesetztem Verfahren in verschiedenen Parametern der Pulsfolge liegt.
Theoretisch könnten mit der in den USA genehmigten UWB-Spezifikation bis zu 500 MBit/s auf
eine Distanz von bis zu 100 Metern erreicht werden. Realistisch ist dieses Ziel jedoch mit der heute
verfügbaren Technik noch nicht, es werden im Moment eher 100 MBit/s auf 10 Meter oder bis zu 450
MBit/s auf noch kürzere Distanzen angepeilt.
3.8
WiMedia
WiMedia ist ein Standard, der auf dem IEEE 802.15.3 Standard [11] aufbaut und verwendet
werden soll, um Multimedia-Daten im WPAN-Bereich zu übertragen. Das WiMedia-Konsortium unter
der Mitwirkung von Kodak, HP, Motorola, Philips, Samsung, Sharp und anderen spezifiziert jedoch nicht
die physikalische Übertragungsschicht sondern nur die darauf aufsetzenden Protokolle.
Die Schnittstelle ist das in 802.15.3 spezifizierte MAC-Protokoll, das es in weiterer Folge auch
erlauben wird, WiMedia über UWB nach 802.15.3a zu bertreiben. Im Moment ist jedoch nur die
802.15.3-Spezifikation verfügbar, die wie alle anderen 802.15-Technologien im 2.4 GHz-ISM-Band
operiert und Datenraten von 11, 22, 33, 44 oder 55 MBit/s auf eine Entfernung von bis zu 100 Metern
definiert. Dabei können bis zu 245 Devices in einem ad-hoc-Netzwerk verbunden werden.
Abbildung 58: WiMedia Protokollstack [29]
- 110 -
WiMedia selbst definiert verschiedene Protokolle, die klar für die Übertragung von MultimediaDaten optimiert sind. Die verwendete Topologie ist zentral organisiert und verbindungsorientiert, wobei
eine scheduling media-access TDMA-Technik zum Einsatz kommt, die eine ausgezeichnete Planbarkeit
der zur Verfügung stehenden Ressourcen ermöglicht.
3.9
Zusammenfassung
Zur Zeit konkurrieren mehrere Technologien um die Gunst der Kunden und der Industrie. Dabei
sind die zwei großen Bereiche der WLANs und der WPANs zu unterscheiden, die jeweils verschiedene
Zielsetzungen verfolgen. Lässt man im Folgenden die WLAN-Technologien 802.11x und HiperLAN2
und das betagte DECT außer Acht, so ergibt sich ein klares Bild der konkurrierenden Standards für
drahtlose Datenübertragung über kürzere Distanzen.
Eines scheint sicher zu sein: IrDA wird ob seiner beschränkten Fähigkeiten (max. zwei Geräte,
Sichtverbindung notwendig) in absehbarer Zeit vom Markt verschwinden. Die restlichen drei betrachteten
Technologien sind alle in der Standardisierungsinitiative IEEE 802.15 enthalten und haben durchaus
verschiedene Zielsetzungen, wobei sich die Anwendungsbereiche zum Teil überlappen. Diese
Überlappungen könnten vor allem für das in der „Mitte“ platzierte Bluetooth den Platz reichlich eng
machen.
Von „unten“ greift 802.15.4, also ZigBee die Domäne von Bluetooth an. Es bietet zwar weitaus
geringere Datenraten aber auch einen signifikant geringeren Energieverbrauch, der es vor allem im
Bereich der Haustechnik interessant macht. Aber auch zur kabellosen Anbindung von Peripheriegeräten
an Rechner oder für Sensornetzwerke ist ZigBee wahrscheinlich die bessere Wahl.
Aus der anderen Richtung macht 802.15.3 und das darauf aufsetzende WiMedia Bluetooth die
Anwendungsbereiche streitig. Mit höheren Datenraten, besserem QoS-Management und für Multimedia
optimierten Übertragungsverfahren ist WiMedia die Technik der Wahl, wenn es um die drahtlose
Übertragung von Audio- und besonders Video-Daten geht.
Für Bluetooth selbst bleibt nach dieser Betrachtung nur ein schmales Segment übrig, in dem es
seine Stärken voll ausspielen kann. Doch Bluetooth ist jene Technologie, die am vielseitigsten einsetzbar
ist, von der Mausanbindung bis zur Videoübertragung. Außerdem hat Bluetooth einen nicht zu
vernachlässigenden Vorsprung, was die Markteinführung und die Akzeptanz betrifft. Es bemühen sich
auch alle Konsortien zu betonen, dass die drei genannten Standards nicht in Konkurrenz zu einander
stehen sondern als einander ergänzende Technologien zu sehen sind.
- 111 -
Welche Technologien sich letztendlich durchsetzen werden oder ob alle drei einen Platz auf dem
Markt ergattern werden, ist aus heutiger Sicht schwer abzuschätzen. Der Vorsprung, den Bluetooth hat,
wird jedoch kaum aufzuholen sein, sodass in den nächsten Jahren vieles für den Einsatz von Bluetooth
spricht, auch wenn es für einzelne Bereiche besser geeignete Alternativen geben mag.
In Tabelle 2 ist ein Vergleich der im PAN-Bereich konkurrierenden Technologien zu finden,
wobei jeweils verschiedene Aspekte der Leistungsfähigkeit betrachtet wurden. Es zeigt sich auch in
diesem Vergleich, dass es nicht „den Testsieger“ gibt, sondern dass je nach gewünschtem Einsatzgebiet
verschiedene Technologien Stärken und Schwächen haben, wobei Blueooth als „Multi-Purpose-Lösung“
wohl ungeschlagen bleibt.
Tabelle 2: Vergleich PAN-Technologien
Bluetooth
IrDA
DECT
802.15.1
Technologie
ZigBee
WiMedia
802.15.4
802.15.3(a)
FHSS
Optisch
DSSS
DSSS
?*
max. Reichweite
10/20/100 m
20 cm / 2 m
300 m
30 m
50 – 100 m *
max. Datenrate
1 MBit/s
1-16 MBit/s
128 kBit/s
250 kBit/s
- 55 MBit/s*
max. Teilnehmer
8 aktive
2
8
250
245
Authentifizierung
ja,
gegenseitig
nein
ja, one-way
ja,
gegenseitig
ja,
gegenseitig
Verschlüsselung
bis 128 bit
nein
optional
64 bit
128 bit
(AES)
ja, Stärke
unbekannt
Energiebedarf
eher niedrig
eher niedrig
relativ hoch
sehr niedrig
relativ hoch
sehr gut
sehr gut
gut
noch nicht
noch nicht
ja,
irrelvant, da
nein
nein
ja
Industrieunterstützung
QoS-Support
nur 2 Geräte
* Bei Einsatz von UWB bis zu 480 MBit/s bei Reichweiten von derzeit bis zu 10 m (theoretisch
bis über 100 m bei noch höheren Datenraten)
- 112 -
4 Bluetooth Development
4.1
Open Source-Protokollstacks
4.1.1 BlueZ
BlueZ ist ein Open-Source-Bluetooth-Protokollstack für Linux, der mittlerweile auch in den
Linux-Kernel integriert ist (seit Kernel 2.4.6). Die BlueZ-Distribution wird in mehreren Teilen als
Source-Code ausgeliefert, der vor dem Einsatz auf der Zielplattform compiliert werden muss. Allerdings
werden keine gesteigerten Ansprüche an installierte Bibliotheken gestellt, eine Standardinstallation
inklusive Kernel- und glib-Soucen reicht aus, um das komplette Paket installieren zu können.
BlueZ stellt den gesamten Bluetooth-Stack zur Verfügung, sofern die Protokolle nicht sowieso
schon in Linux verfügbar sind (z.B. PPP, IP, TCP, …). Um die Bluetooth-Funktionalität nutzen zu
können, müssen mehrere Module geladen werden. Im Einzelnen sind dies:
hci_xxx: Die Host-Controller-Interface-Treiber für die Bluetooth-Hardware. Inkludiert
sind:
o
hci_usb: Treiber für USB-Bluetooth-Geräte
o
hci_vhci: Treiber für virtuelle (emulierte) Bluetooth-Geräte
o
hci_uart: Treiber für serielle Bluetooth-Geräte
bluez: Der BlueZ-Core und damit die Basis für alle weiteren Module, die Zugriff auf
die höherschichtigen Bluetooth-Protokolle geben.
l2cap: Stellt die Funktionalität des L2CAP-Protokolls zur Verfügung
sco: Erlaubt den Aufbau von SCO-Verbindungen
rfcomm: Stellt das RFCOMM-Protokoll und somit die Emulation von seriellen
Schnittstellen zur Verfügung.
- 113 -
Abbildung 59: Aufbau von BlueZ [23]
Bei der Installation können diese Module in /etc/module.conf eingetragen werden und
damit bei jedem Systemstart geladen werden. Weiters muss bei der Installation einmalig ein beiliegendes
Script aufgerufen werden, dass die notwendigen Devices unter /dev/ anlegt.
Außerdem stellt BlueZ in den neueren Versionen auch das PAN-Profile und damit das BNEP
(Bluetooth Network Encapsulation Protocol) zur Verfügung, mit dem Ethernet-Traffic direkt (ohne PPP)
in ein Bluetooth-Piconet geroutet werden kann. Will man diese Funktionalität nutzen, so ist es notwendig,
den PAN-Dämon (pand) zu starten.
Bei jedem Systemstart muss auch der ebenfalls beiliegende HCI-Dämon (hcid) gestartet werden,
der Zugriff auf die Bluetooth-Hardware erst ermöglicht.
Ist das System soweit konfiguriert, kann mittels der enthaltenen Tools die Funktionsfähigkeit der
Bluetooth-Geräte getestet werden. Das erste benötigte und auch wichtigste Tool ist hciconfig, dass
entsprechend seinem Netzwerk-Pedant ifconfig für die Konfiguration sowie das Starten und Stoppen
der Bluetooth-Geräte zuständig ist.
- 114 -
Abbildung 60: hciconfig
Sämtliche Kommandos an ein Gerät können mittels hcidump angezeigt werden. Angezeigt
werden auch sämtliche gekapselten Pakete (wie L2CAP oder auch RFCOMM).
Abbildung 61: hcidump
- 115 -
Grundlegende Funktionen des Baseband-Protokolls können mittels hcitool getestet werden.
Neben der Abfrage von diversen Geräteparametern kann auch ein Inquiry bzw. ein Scan gestartet werden
oder eine Verbindung zu einem Remote-Geräte hergestellt werden.
Abbildung 62: hcitool: Anzeige der Connections
Abbildung 63: hcitool: Inquiry
Die nächste zu testende Stufe stellt L2CAP dar, dass rudimentär mit l2ping abgedeckt werden
kann, welches ein Ping auf ein anzugebendes Gerät durchführt dadurch die Latenzzeit ermittelt und wenn
verfügbar auch die erreichte Datenrate ausgibt.
- 116 -
Abbildung 64: l2ping
Auch das SDP kann über die Kommandozeile gesteuert werden, wobei im einfachsten Fall der
Service-Tree eines Remote-Devices abgefragt und ausgegeben werden kann. Es ist jedoch auch möglich,
selbst Services am lokalen Device zu veröffentlichen.
- 117 -
Abbildung 65: SDP Browsing
Neben den gezeigten Kommandozeilen-Tools stellt BlueZ natürlich auch Libraries zum Zugriff
auf den Bluetooth-Stack zur Verfügung, die jedoch nicht getestet wurden. Die zu verwendende
Programmiersprache ist C bzw. C++, wobei der Zugriff auf die Bluetooth-Datenübertragung socketbasiert abgewickelt wird. Von BlueZ werden APIs zum Zugriff auf das HCI, auf L2CAP, auf RFCOMM
sowie auf das SDP zur Verfügung gestellt, die eine Vielzahl von Konstanten und Bibliotheksfunktionen
zum einfacheren und lesbaren Zugriff auf den Bluetooth-Stack bieten. [23]
4.1.2 JBlueZ
JBlueZ ist ein Java-Package, dass mittels Java Native Interface (JNI) die Funktionalität der BlueZBibliotheken in Objekte kapselt und unter Java komfortabel zur Verfügung stellt. Leider ist die
Implementierung bisher nur bis zur HCI-Ebene gediehen und daher nur sehr bedingt einsetzbar. Laut
Auskunft der Entwickler sollte die Portierung der L2CAP-Bibliotheken in den nächsten Monaten
verfügbar sein, doch scheint die Projektaktivität im Moment auf ein Minimum zurückgefahren zu sein.
Selbst wenn L2CAP verfügbar wäre, ist es noch ein weiter Weg zur vollständigen Einsetzbarkeit und so
bleibt ein Open-Source-Java-Bluetooth-Stack auf absehbare Zeit höchstwahrscheinlich noch ein
Wunschtraum. [24]
- 118 -
4.1.3 Weitere Protokollstacks
Neben dem im Linux-Kernel integrierten BlueZ existiert noch eine Reihe weiterer BluetoothStacks für Linux, Windows und andere Plattformen, auf die jedoch nicht weiter eingegangen wird.
Populäre Beispiele sind:
AXIS OpenBT Stack [79]: Open Source Stack für Linux (GNU GPL)
Affix Bluetooth Protocol Stack [80]: Open Source Stack für Linux (GNU GPL)
Altinav Bluetooth Protocol Stack [76]: Kommerzieller Stack für Java ME/SE, Windows
9x, CE und 2K/XP/ME, Linux, ANSI C-API
Rococo Impronto (siehe 4.3.3, Java-Simulator für die Anwendungsentwicklung)
Microsoft Windows XP: Ab Service Pack 1 funktionsfähig, ab Service Pack 2
voraussichtlich integriert
4.2
Bluetooth auf Betriebssystemen für mobile Geräte
4.2.1 Symbian OS 7.0
Symbian OS ist ein Betriebssystem für mobile Endgeräte, das von führenden MobiltelefonHerstellern entwickelt wird und heute auf einer Vielzahl moderner Endgeräte eingesetzt wird. Symbian
OS ist ein 32-bit-Multitasking-System und bietet in der neuesten Version 7.0 neben verbesserten
Multimedia-Fähigkeiten auch Unterstützung für Bluetooth 1.1.
Bis zu den Symbian-Versionen 6.x, die noch auf vielen Mobiltelefonen eingesetzt werden, war der
Bluetooth-Stack kompatibel zur Version 1.0, seit Juni 2003 sind jedoch erste Geräte mit Symbian OS 7.0
verfügbar, dessen Stack wie erwähnt kompatibel zu Bluetooth 1.1 ist.
Der Symbian-Bluetooth-Stack stellt das Generic Access Profile, das Serial Port Profile sowie das
Generic Object Exchange Profile zur Verfügung. Die Stack-Implementierung besteht aus einem
Protokoll-Modul, einem Security-Manager, einem Bluetooth Communication Server und einem SDPServer. Über insgesamt sechs Interfaces ist der Zugriff auf den Stack möglich:
Direkt via HCI (lowest-level)
Bluetooth-Socket-API: Erlaubt Zugriff auf L2CAP oder auf RFCOMM über das
Standard-Socket-Interface des Betriebssystems, bevorzugte und flexibelste Schnittstelle
für „General-Purpose-Verbindungen“
- 119 -
Bluetooth-Serial-Communications-API: Stellt eine emulierte serielle Schnittstelle für
ausgehende Verbindungen zur Verfügung, wird eher selten und nur für spezielle
Anwendungen eingesetzt.
Bluetooth-Manager: Wird eingesetzt, um die Sicherheits-Features von Bluetooth zu
konfigurieren, wobei Security Access Policies eingesetzt werden, um die von diversen
Services benötigten verschiedenen Sicherheitsstufen realisieren zu können.
Bluetooth SDP API: Erlaubt Zugriff auf die Service-Registrierung sowie der ServiceAbfrage
OBEX-API: Bietet Zugriff auf die OBEX-Transport-Layer-Funktionalitäten zum
Austausch von Objekten (nicht nur über Bluetooth sonder auch über IrDA).
Symbian stellt eine Java-Virtual-Machine mit MIDP 2.0 und CLDC zur Verfügung, die
kompatibel zur in Kapitel 4.3.1 beschriebenen Bluetooth-API JSR-82 ist. Somit kann das BluetoothModul eines Symbian-OS-Smartphones aus MIDlets heraus verwendet werden, wobei die
eingeschränkten Möglichkeiten der JSR-82 gelten.
Der
Bluetooth-Stack
kann
natürlich
auch
direkt
nativ
angesprochen
werden,
die
Programmiersprache der Wahl ist unter Symbian OS grundsätzlich C++, wo verhältnismäßig komplexe
aber auch mächtige socket-basierte Libraries zum Einsatz kommen. [77]
4.2.2 Microsoft Windows Mobile 2003
PDA-Hersteller wie HP, Fujitsu-Siemens oder Compaq liefern ihre Produkte mit der neuen
Windows Mobile 2003 Software für Pocket PC (Pocket PC 2003) aus. Dieses Betriebssystem basiert auf
dem Kernel von Windows CE.NET 4.2, das mit dem .NET Compact Framework viele neue
Möglichkeiten bei der Programmierung bietet. Ein SDK kann auf der Microsoft-Website [63]
heruntergeladen werden.
Microsoft bietet einerseits Bluetooth-Support über das Socket-basierte WinSock-Interface an, das
Zugriff auf RFCOMM erlaubt. Andererseits existiert die Möglichkeit, sogenannte „Stack Extension
Layers“ auf der Basis des HCI zu erstellen, mit denen die Funktionalität der Basis-StackImplementierung erweitert werden kann. Zum Beispiel wäre es möglich, selbst SCO-Support für
Windows Mobile 2003 zu implementieren.
- 120 -
Abbildung 66: Bluetooth-Stack in Windows CE 4.2 [78]
Eine Programmierung ist wie bei Microsoft-APIs üblich grundsätzlich mit C bzw. C++ möglich,
das .NET Compact Framework selbst bietet keinen nativen Bluetooth-Support. [78] Mit einer
entsprechenden JVM wäre natürlich auch ein Bluetooth-Zugriff von Java aus möglich, unseres Wissens
stellt jedoch weder Microsoft noch ein anderer Hersteller die dafür benötigt J2ME-Virtual Machine mit
MIDP 2.0 für das aktuelle Windows CE.NET zur Verfügung.
4.3
Bluetooth für Java
Dieses Kapitel soll einen Überblick über die Integration von Bluetooth in Java geben, wobei
insbesondere die Java Bluetooth APIs (JSR-82) behandelt werden. Am Ende des Kapitels wird die
Kombination von Jini und Bluetooth sowie der Einsatz von Bluetooth-Simulatoren bei der
Anwendungsentwicklung diskutiert.
- 121 -
4.3.1 Die Java Bluetooth APIs (JSR-82)
Java Specification Request (JSR)-82 [74] ist der formale Java Community Process (JCP)-Name
der Java APIs für Bluetooth. Die Spezifikation wurde von Motorola geleitet, die zusammen mit der JSR82 Expertengruppe – darunter IBM, Nokia, Sony Ericsson, Sun Microsystems und Symbian – die
offiziellen Bluetooth APIs spezifizierten.
Nach dem JCP ist der Leiter einer Spezifikation für die Entwicklung einer Reference
Implementation (RI) verantwortlich, mit welcher der Nachweis geliefert wird, dass die Spezifikation
implementiert werden kann, sowie eines Technology Compatibility Kits (TCK), das zur Überprüfung der
Kompatibilität von JSR-82-Implementierungen anderer Hersteller verwendet wird. RI und TCK für die
JSR-82 APIs können dementsprechend von der Motorola-Website [75] bezogen werden.
Die JSR-82 Spezifikation besteht aus zwei Teilen, die unabhängig voneinander verwendet werden
können, nämlich javax.bluetooth und javax.obex.
javax.bluetooth
Das Package javax.bluetooth wird für die für die drahtlose Kommunikation über das
Bluetooth-Protokoll benötigt und enthält folgende 13 Klassen bzw. Interfaces:
Interfaces im Package javax.bluetooth:
o
DiscoveryListener: Erlaubt einer Applikation, Device Discovery- und
Service Discovery-Events zu empfangen
o
L2CAPConnection: Repräsentiert einen verbindungsorientierten L2CAPChannel
o
L2CAPConnectionNotifier: Wird serverseitig benötigt, um auf Clients
warten zu können, die sich zu einem L2CAP-Service verbinden wollen
o
ServiceRecord: Beschreibt Eigenschaften eines Bluetooth Service
o
DataElement: Definiert verschiedene Datentypen für Service-Attribute
Klassen im Package javax.bluetooth:
o
DeviceClass: Repräsentiert den Class of Device (CoD)-Record wie er in der
Bluetooth-Spezifikation im Dokument Bluetooth Assigned Numbers definiert
ist, und enthält Informationen über den Typ des Gerätes und der auf diesem
Gerät verfügbaren Dienste.
o
DiscoveryAgent: Stellt Methoden für Device- und Service-Discovery zur
Verfügung
o
LocalDevice: Repräsentiert das lokale Bluetooth-Gerät
- 122 -
o
o
RemoteDevice: Repräsentiert ein entferntes Bluetooth-Gerät
UUID: Definiert 128 Bit große universally unique identifiers (UUIDs); eine
Menge von UUIDs für Protokolle und Service-Klassen sind im Bluetooth
Assigned Numbers-Dokument definiert.
o
BluetoothConnectionException: Diese Exception wird geworfen wenn
eine Bluetooth-Verbindung (L2CAP, RFCOMM oder OBEX) nicht erfolgreich
aufgebaut werden konnte
o
BluetoothStateException: Diese Exception wird geworfen wenn ein
Request an ein Bluetooth-System von diesem im aktuellen Zustand nicht
unterstützt wird
o
ServiceRegistrationException: Diese Exception wird geworfen wenn
beim Hinzufügen eines Service Records zur lokalen Service Discovery Database
(SDDB) oder beim Ändern eines Service Records ein Fehler aufgetreten ist.
javax.obex
Das Package javax.obex wird benötigt um – unabhängig von den darunter liegenden
Transportmechanismen – Objekte zwischen Geräten zu versenden, und enthält folgenden 8 Klassen bzw.
Interfaces:
Interfaces im Package javax.obex:
o
Authentication: Wird benötigt um auf Authentication Challange- und
Response-Headers reagieren zu können
o
ClientSession: Stellt Methoden für OBEX-Requests zur Verfügung
o
Operation: Ermöglicht die Manipulation von OBEX PUT- und GET-
o
HeaderSet: Definiert set- und get-Methoden für OBEX-Headers
Operationen
o
SessionNotifier: Wird serverseitig benötigt um auf Client-Requests
warten zu können
Klassen im Package javax.obex:
o
PasswordAuthentication:
Speichert
Benutzername/Passwort-
Kombinationen
o
ResponseCodes: Enthält eine Liste gültiger Response-Codes, die ein Server
an einen Client schicken kann
o
ServerRequestHandler: Definiert einen Event-Listener für OBEXRequests an den Server
- 123 -
Anwendungsentwicklung
Die Bluetooth-API der JSR-82 ist unabhängig vom darunterliegenden Bluetooth-Stack und der
Hardware, wodurch man Anwendungen ohne Wissen darüber schreiben kann. Zudem ist sie die einzige
standardisierte Bluetooth API, und sie spezifiziert die Schichten HCI, L2CAP, SDP und RFCOMM sowie
die Profile Generic Access Profile, Service Discovery Application Profile, Serial Port Profile und Generic
Object Exchange Profile.
Um nun mit der Bluetooth API arbeiten zu können, benötigt man einen Bluetooth Stack (dieser
muss eine Java-API haben; Stacks, die beispielsweise in C/C++ implementiert sind, müssen ein JavaInterface (JNI) haben) und die Java Bluetooth API (hierbei ist zu beachten, dass JSR-82 nur auf der
J2ME-Plattform implementiert werden kann, da J2SE kein Generic Connection Framework unterstützt;
das wird frühestens für JDK 1.5 erwartet).
Es gibt viele Hersteller für JSR-82-kompatible Java Bluetooth SDKs, wobei nur Atinav [76] und
Rococo [72] beide JSR-82-APIs (javax.bluetooth und javax.obex) sowohl für J2ME als auch
für J2SE unterstützen. Die Stacks beider Hersteller laufen unter Win-32, Linux und Pocket PC; Rococo
unterstützt zudem Palm OS.
Eine Bluetooth-Applikation besteht aus folgenden Teilen:
Stack Initialization: Der erste Schritt bei der Anwendungsentwicklung ist die
Initialisierung des Stacks, um die Bluetooth-Geräte einsatzbereit zu machen. Die
Initialisierung kann in Abhängigkeit vom darunter liegenden Betriebssystem und der
Radio-Schicht stark variieren.
Device Management: Das Gerätemanagement wird durch die Klassen LocalDevice,
RemoteDevice und DeviceClass ermöglicht, mit deren Hilfe man Informationen
über das eigene Gerät sowie entfernte Geräte abfragen kann.
Device
Discovery:
Mit
Hilfe
der
Klassen
DiscoveryAgent
und
DiscoveryListener kann ermittelt werden, welche Bluetooth-Geräte sich in
Reichweite befinden.
Service Discovery: Nachdem die Geräte bekannt sind kann mit Hilfe der Klassen
DiscoveryAgent, DiscoveryListener, ServiceRecord, DataElement
und UUID ermittelt werden, welche Dienste diese anbieten. Die Service Discovery Data
Base (SDBB) ist dabei ein zentrales Repository für alle Service Records auf einem Gerät.
Service Registration: Bevor ein Client die von einem Server zur Verfügung gestellten
Services finden kann, muss dieser seine Services lokal registrieren ( Service
Registration).
- 124 -
Communication: Die Kommunikation via Bluetooth kann beispielsweise über RFCOMM
(streambasiert), L2CAP (paketbasiert) und OBEX (objektbasiert) erfolgen.
Diese Vorgehensweise wird in 4.4 („Ping-Pong“ mit Java unter Symbian OS 7.0) anhand eines
praktischen Beispiels vertieft. [Hopk03]
4.3.2 Bluetooth und Jini
Jini (Java Intelligent Network Infrastructure) [73] ist eine von Sun eingeführte, Java-basierte
Technologie, die dem Benutzer die Möglichkeit geben soll, alle an ein Netzwerk angeschlossenen Dienste
zu nutzen und mit anderen Diensten kombinieren zu können - unabhängig davon, um welche Art von
Diensten es sich handelt und wo diese sich befinden. Dienste können dabei sowohl Software- wie auch
Hardwarekomponenten sein, die über eine gewisse eigene Intelligenz verfügen, damit sie sich
automatisch an einem Netzwerk anmelden (genauer bei einem Lookup Service (LUS) genannten
Zentralregister) und ihre Fähigkeiten den anderen Teilnehmern sofort und ohne spezielle
Treiberinstallation zur Verfügung stellen können.
In der Welt von Jini werden Geräte nicht mehr als solche wahrgenommen. Vielmehr sind die
Dienste die sie zur Verfügung stellen – beispielsweise das Drucken von Dokumenten – von Bedeutung,
die dann in einem Verbund (Föderation) von Jini-Diensten von jedem anderen Dienst genutzt werden
können. Dazu lädt der Benutzer eines Dienstes einen entsprechenden Proxy auf seine JVM und führt den
Code dort aus. Proxy und Dienst kommunizieren dann mittels dem von Java zur Verfügung gestellten
RMI (Remote Method Invocation).
Knoten in einem Jini-Verband verfügen über folgende Mechanismen:
Lookup: Ermöglicht Client das Finden und Aufrufen eines Dienstes
Discovery: Finden eines passenden Lookup Service in einem Jini-Verband
Join: Eintragen eines bereitgestellten Dienstes im Lookup Service
Leasing: Ermöglicht zeitlich begrenzte Allokation und Freigabe von Ressourcen
Transactions: Ermöglicht die Gruppierung von Diensten in Transaktionen
Events: Erweiterung des Event-Modells der JavaBeans-Komponenten
[Fers03a]
- 125 -
Abbildung 67: Bluetooth und Jini im ISO/OSI Referenzmodell [Wang00]
Im Gegensatz zu Bluetooth, das zwar ein komplettes Kommunikationssystem mit Hard- und
Software spezifiziert aber dennoch auf die unteren Schichten des ISO/OSI-Referenzmodells fokussiert ist,
ist Jini auf den höheren Schichten angesiedelt (siehe Abbildung 67).
Jini und Bluetooth sind komplementäre Technologien; Bluetooth ermöglich die spontane, drahtlose
Vernetzung unterschiedlichster Geräte, sobald sich diese in räumlicher Nähe zueinander befinden. Jini
bietet auf der anderen Seite Mechanismen, um eine verteilte Umgebung als einfach zu administrierenden
Pool von Diensten (Hardware und/oder Software) zu betrachten, die durch Clients genutzt werden
können. [Fers03a] [Wang00] Die Kombination von Bluetooth und Jini erlaubt damit die Realisierung
intelligenter Netzwerke, in denen die Geräte flexibler zusammenarbeiten können, ohne durch die
verfügbaren Profile eingeschränkt zu werden. Zudem erlaubt Jini durch Events, Transaktionen und
Leasings die Entwicklung robusterer und fehlertoleranterer Applikationen. [Hopk03]
4.3.3 Java-Simulator für die Anwendungsentwicklung
Bluetooth-Simulatoren abstrahieren von der darunter liegenden Hardware und deren Komplexität,
wodurch sich der Entwickler von Client/Server-Anwendungen nicht um das Konfigurieren und
Administrieren von Bluetooth-Hardware kümmern muss sondern schnell und einfach Algorithmen und
Anwendungen testen kann. In größeren Entwicklungsteams kann ein Simulator aber auch die Kosten
reduzieren, da er die Anschaffung von Bluetooth-Geräten in großen Stückzahlen überflüssig macht.
Ein Bluetooth-Simulator ist aber kein Ersatz für das Testen von Applikationen mit realer
Hardware von verschiedenen Herstellern. Auch reale Umgebungsbedingungen wie Interferenzen mit
IEEE 802.11b/g-Geräten können i.d.R. nicht erfasst werden.
- 126 -
Ein bekannter Simulator ist Impronto von der Firma Rococo [72], der sowohl unter J2SE als auch
unter J2ME läuft. Impronto ist eine 100%ige Java-Anwendung, die es Entwicklern erlaubt, JSR-82kompatiblen Code zu entwickeln, der auf virtuellen Bluetooth-Geräten ausgeführt und die Interaktion
dieser Geräte beobachtet werden kann. Rococo Impronto bietet:
Volle Unterstützung für L2CAP, RFCOMM, OBEX, SDP und HCI
Eine Management-Konsole um das Laufzeitverhalten der simulierten Geräte zu
beobachten (siehe Abbildung 68)
Das Ausführen von JSR-82 Code auf simulierten Bluetooth-Geräten
Umfassende Logging-Funktionalität für Ereignisse
Abbildung 68: Rococo Impronto [72]
Nachdem die Impronto-Umgebung installiert und virtuelle Bluetooth-Geräte („foo“ und „bar“ in
Abbildung
68)
erzeugt
wurden,
kann
mit
dem
- 127 -
Kommandozeilen-Befehl
java
–
Dimprontolocaldevice.friendlyname=<name of the virtual device> <name
of the application> die Java-Applikation mit dem angegebenen virtuellen Gerät (z.B. „foo“)
verknüpft werden. [Hopk03]
4.4
„Ping-Pong“ mit Java unter Symbian OS 7.0
In
Symbian
OS
7.0
ist
wie
bereits
erwähnt
das
JSR-82-Bluetooth-API
integriert
(javax.bluetooth). Dieses API wurde eingesetzt, um eine einfache Beispiel-Applikation zu
erstellen, die über einen L2CAP-Channel Nachrichten austauscht. Im Folgenden wird der Programmcode
erläutert und der Verbindungsablauf anhand von Screenshots erläutert.
4.4.1 Grundlegendes
Die Applikation teilt sich grundsätzlich in einen Client und eine Server auf. Der
Verbindungsaufbau in JSR-82 ist Service-orientiert, d.h. der Client sucht den entsprechenden ServiceRecord am Server, den dieser zuvor veröffentlicht haben muss und erhält von diesem einen ConnectionString, der in Folge zum Verbindungsaufbau verwendet werden kann.
JSR-82 baut wie in Kapitel 4.3 (Bluetooth für Java) erwähnt auf dem Generic Connection
Framework der JME auf und verwendet dieses zum Senden und Empfangen von Daten. Es können
grundsätzlich nur Arrays vom Typ byte ausgetauscht werden.
Um die JSR-82-API nutzen zu können, muss zumindest das Package javax.bluetooth
eingebunden
werden.
Sollen
Verbindungen
aufgebaut
werden,
ist
noch
das
Package
javax.microedition.io, welches das Generic Connection Framework enthält, notwendig. Für
OBEX-Operationen muss das javax.obex-Package verwendet werden, das zwar von der JSR-82-API
stammt, aber nicht unbedingt Bluetooth-spezifisch eingesetzt werden muss.
4.4.2 Vorbereiten des Servers
Die Server-Applikation führt direkt nach dem Starten diverse Initialisierungen durch und verharrt
dann in einem Zustand in dem der Server auf einen Verbindungsrequest des Clients wartet.
Der erste Schritt, um den Bluetooth-Stack eines Gerätes unter Java nutzen zu können, ist das
Erstellen eines LocalDevice-Objektes, das eine Java-API für die grundlegenden Funktionalitäten zur
Konfiguration des Stacks anbietet:
- 128 -
[…]
private LocalDevice myDevice;
[…]
try {
myDevice = LocalDevice.getLocalDevice();
}
catch (BluetoothStateException e) {
System.out.println(e)
}
[…]
Nach dem Holen dieses Objektes kann mit den Vorbereitungen zum Verbindungsaufbau begonnen
werden. Um möglichen Clients das Verbinden zu ermöglichen, muss das Gerät sichtbar gemacht werden.
Dies geschieht durch Setzten eines Geräteflags bzw. durch Aufruf der entsprechenden Methode. Der
Discovery-Mode GIAC (General Inquiry Access Code) legt dabei fest, dass das Gerät für alle anderen
Geräte sichtbar sein soll.
[…]
try {
myDevice.setDiscoverable(DiscoveryAgent.GIAC);
}
catch (BluetoothStateException e) {
System.out.println(e)
}
[…]
Nachdem das Gerät sichtbar ist, muss in weiterer Folge ein L2CAPConnectionNotifier
erstellt werden, mit dem es möglich ist, auf eingehende Verbindungsanforderungen via L2CAP zu
warten. Dieser L2CAPConnectionNotifier wird von der statischen Methode Connector.open
des Generic Connection Framework erstellt, wozu dieser ein Connection-URL übergeben werden muss.
Der Connection-URL spezifiziert das Service, das der Server dem Client anbietet. Mit dem JSR-82-API
kann keine Connection „direkt“ aufgebaut werden (z.B. Verbindung via L2CAP), es muss vielmehr ein
Service definiert werden, das die angebotene Verbindung spezifiziert. Im konkreten Fall ist das
verhältnismäßig einfach, es muss lediglich das verwendete Protokoll (hier: btl2cap) sowie die
gewünschte Service-ID (128 bit) angegeben werden. Diese kann im Wesentlichen frei gewählt werden
(bis
auf
einige
reservierte
Ausnahmen;
00112233445566778899AABBCCDDEEFF
hier
wird
die
Service-ID
gewählt). Um festzulegen, dass die erstellte
Verbindung serverseitig genutzt werden soll, muss im Connection-URL außerdem noch localhost
enthalten sein. :
[…]
try {
list.append("establishing...",null);
L2CAPConnectionNotifier server = (L2CAPConnectionNotifier)
Connector.open
- 129 -
("btl2cap://localhost:00112233445566778899AABBCCDDEEFF");
}
catch (IOException e) {
System.out.println(e)
}
[…]
Ist der L2CAPConnectionNotifier erfolgreich erstellt, so kann mittels der Methode
acceptAndOpen der Klasse L2CAPConnectionNotifier, die von der Klasse Connection des
Generic Connection Framework abgeleitet ist, auf eine Verbindungsanforderung gewartet werden. Diese
Methode ist von der JSR-82-API überschrieben, so dass das spezifizierte Service in die ServiceDatenbank des Geräts eingetragen wird und so via SDP gefunden werden kann.
[…]
try {
list.append("listening...",null);
L2CAPConnection con = server.acceptAndOpen();
}
catch (IOException e) {
System.out.println(e)
}
[…]
Der Server verharrt nun solange in der Methode acceptAndOpen, bis das ein Verbindungsversuch
eines Clients stattfindet. In der Beispielapplikation zeigt sich zu diesem Zeitpunkt der in Abbildung 69
dargestellte Screen.
Abbildung 69: Server erstellt das Service und wartet auf Verbindung via L2CAP
- 130 -
4.4.3 Gerätesuche durch den Client
Die erste Aufgabe des Clients ist es, die verfügbaren Geräte in seiner Umgebung via Inquiry zu
finden. Dazu muss die gleiche Initialisierung wie beim Server durchlaufen werden, bevor ein Inquiry
gestartet werden kann. Dazu ist außerdem ein DiscoveryAgent
notwendig, der vom
LocalDevice-Objekt angefordert wird.
[…]
private LocalDevice myDevice;
private DiscoveryAgent discoveryAgent;
[…]
try {
myDevice = LocalDevice.getLocalDevice();
discoveryAgent = myDevice.getDiscoveryAgent();
}
catch (BluetoothStateException e) {
System.out.println(e)
}
[…]
Das Inquiry wird nun durch das DiscoveryAgent-Objekt gestartet. Der Client wird mittels
Callback-Methode vom Auffinden eines oder mehrer Geräte in Kenntnis gesetzt. Dazu ist es notwendig,
dass der Client das Interface DiscoveryListener implementiert. Dieser Listener (der Client) wird
dem DiscoveryAgent beim Starten des Inquiry übergeben. Außerdem muss noch festgelegt werden,
ob alle Geräte in Reichweite (GIAC) oder nur jene mit einem speziellen Access-Code gefunden werden
sollen.
[…]
try {
discoveryAgent.startInquiry(DiscoveryAgent.GIAC, this);
}
catch (Exception e) {
System.out.println(e);
}
[…]
Wird ein Gerät gefunden, so wird die Callback-Methode deviceDiscovered aufgerufen, die
im konkreten Fall lediglich die Geräte-Adresse in eine Liste am Display einträgt. Ist das Inquiry
abgeschlossen, so wird die Methode inquiryCompleted aufgerufen, die „done“ auf dem Display
ausgibt.
[…]
public void deviceDiscovered(RemoteDevice remoteDevice,
DeviceClass deviceClass) {
list.append(remoteDevice.getBluetoothAddress(),null);
}
- 131 -
[…]
public void inquiryCompleted(int int0) {
list.append("done",null);
}
[…]
Nach Abschluss des Inquirys ergibt sich das in Abbildung 70 gezeigte Displaybild, aus dem nun
ein konkretes Gerät, auf dem nun das entsprechende Service gesucht werden soll. Dies ist mittels eines
CommandListeners implementiert, der auf die Auswahl eines Listenelementes reagiert. Die konkrete
Implementierung ist an dieser Stelle irrelevant.
Abbildung 70: Abgeschlossenes Inquiry auf dem Client
4.4.4 Servicesuche durch den Client
Der Client führt nun auf dem ausgewählten Gerät eine Suche nach dem Service mit der ServiceID
00112233445566778899AABBCCDDEEF durch. Dazu wird wiederum der schon zuvor eingesetzte
DiscoveryAgent verwendet, auch für das Service Discovery gibt es im DiscoveryListenerInterface entsprechende Methoden. Für die Service-Suche werden neben der Service-ID auch noch das
RemoteDevice-Objekt des zu durchsuchenden Gerätes sowie das Callback-Objekt (in konkreten Fall der
Client selbst) benötigt:
[…]
UUID[] uuid = new UUID[1];
uuid[0] = new UUID("00112233445566778899AABBCCDDEEFF",false);
RemoteDevice remote = discoveryAgent.retrieveDevices
(DiscoveryAgent.CACHED)[list.getSelectedIndex()];
try {
- 132 -
discoveryAgent.searchServices(null, uuid, remote, this);
}
catch (BluetoothStateException e) {
System.out.println(e);
}
[…]
Wird das Service gefunden, so wird die Callback-Methode servicesDiscovered aufgerufen,
der auch der entsprechende Service-Record als Parameter übergeben wird. Aus diesem Service-Record
wird später der Connection-URL extrahiert, mit dessen Hilfe die Verbindung zum Server aufgebaut
werden kann. In der konkreten Implementierung wird der Connection-URL beim Aufruf der CallbackMethode abgespeichert, um dann nach Ende der Service-Suche, der durch die Callback-Methode
serviceSearchCompleted signalisiert wird, den Verbindungsaufbau zu ermöglichen.
[…]
private String connectionURL = null;
[…]
public void servicesDiscovered(int int0,
ServiceRecord[] serviceRecordArray) {
connectionURL = serviceRecordArray[0].getConnectionURL
(ServiceRecord.NOAUTHENTICATE_NOENCRYPT, false);
}
[…]
4.4.5 Verbindungsaufbau, Datenaustausch und Verbindungsabbau
Nach Beendigung der Service-Suche stellt der Client – falls das entsprechende Service gefunden
wurde – die Verbindung mit dem Server her, indem mit dem gefundenen Connection-URL eine
L2CAPConnection vom Generic Connection Framework angefordert wird.
[…]
try {
list.append("trying to connect...",null);
L2CAPConnection con = (L2CAPConnection)
Connector.open(connectionURL);
}
catch (IOException e) {
System.out.println(e)
}
[…]
Das Betriebssystem fragt nun – wie in Abbildung 71 zu sehen – beim Benutzer nach, ob der
Anwendung ein Verbindungsaufbau erlaubt werden soll.
- 133 -
Abbildung 71: Verbindungsaufbau (Client)
Wird der Verbindungsaufbau zugelassen, so versucht der Client, eine Verbindung mit dem Server
herzustellen. Serverseitig wird der Benutzer jedoch ebenfalls vom Betriebssystem gefragt, ob er einen
Aufbau der Verbindung wünscht, wie in Abbildung 72 zu sehen ist.
Abbildung 72: Verbindungsaufbau (Server)
- 134 -
Nachdem die Verbindungsanforderung auch serverseitig quittiert ist, wird die Verbindung
aufgebaut und der Datenaustausch kann beginnen. Die Verbindung selbst ist bidirektional und kann über
die Connection-Objekte des Generic Connection Framework (hier durch die Objekte der von
Connection abgeleitete Klasse L2CAPConnection) benutzt werden. Zur Demonstration der Funktion
wurde hier ein trivialer Datenaustausch realisiert, der Server sendet den String „Ping“ worauf der Client
mit dem String „Pong“ antwortet. Nach dem Datenaustausch wird die Verbindung wieder geschlssen
bzw. abgebaut.
Datenaustausch-Code Server:
[…]
try {
// send a few bytes ("Ping")
list.append("connected...",null);
con.send(s.getBytes());
list.append("sending "+s,null);
// receive a few bytes ("Pong").
con.receive(byteArray);
list.append("received "+new String(byteArray),null);
con.close();
list.append("connection closed",null);
}
catch (IOException e) {
System.out.println(e)
}
[…]
Datenaustausch-Code Client:
[…]
try {
// receive a few bytes ("Ping").
con.receive(byteArray);
list.append("received "+new String(byteArray),null);
// send a few bytes ("Pong")
list.append("connected...",null);
con.send(s.getBytes());
list.append("sending "+s,null);
con.close();
list.append("connection closed",null);
}
catch (IOException e) {
System.out.println(e)
}
[…]
Nach erfolgreicher Kommunikation zeigen die Displays beider Telefone folgendes Bild:
- 135 -
Abbildung 73: Ping-Pong
Wichtig ist an dieser Stelle zu bemerken, dass lediglich byte-Arrays übertragen werden können,
was eine Serialisierung der zu übertragenden Daten notwendig macht. Außerdem ist es beim Empfangen
notwendig, die Größe des byte-Arrays im Vorhinein zu kennen, da bei zu kleinem Array eine Exception
auftritt. Zur Übertragung von Objekten wäre das OBEX-Protokoll, das ebenfalls unterstützt wird, besser
geeignet.
- 136 -
5 Bluetooth Markt
Dieses Kapitel hat zum Ziel, die aktuelle Bluetooth-Martksituation zu untersuchen. Hierfür sind
eine Siemens-Studie [Ande03], diverse Bücher [Bray02] [Kral03] [Merk02] [Schi03] sowie eine Vielzahl
von Nachrichtenartikeln [34] - [47], die z.T. auf aktuellen Forrester-, Frost & Sullivan- und GartnerStudien basieren, eingeflossen.
Mitte 1999 waren erstmals Bluetooth-Chips der Version 1.0 in größeren Stückzahlen verfügbar.
Diese hatten aber noch viele Bugs, weshalb ein verbesserter Standard mit der Bezeichnung 1.0b
entwickelt wurde. Seit Februar 2001 ist mit Version 1.1 erstmals ein Bluetooth-Standard verfügbar, der
sogar von der IEEE als gut empfunden wurde, allerdings zu den vorhergegangenen inkompatibel ist; mit
unterschiedlichen Bluetooth-Standards ausgerüstete Geräte sind also nicht in der Lage, miteinander zu
kommunizieren. Daraus resultierte eine vornehme Zurückhaltung potentieller Hersteller Bluetoothkompatibler Geräte, lediglich eine Handvoll davon – vor allem Mobiltelefone und Headsets – war
verfügbar.
Das Anfang 2003 nach wie vor eher spärliche Angebot Bluetooth-fähiger Geräte und die
Kompatibilitätsprobleme, die diese Geräte z.T. miteinander haben, veranlasste Branchenbeobachter schon
zu Spekulationen darüber, dass die Technologie keine große Verbreitung finden würde. Unterstützt
wurden diese Befürchtungen dadurch, dass Anbieter von WLAN-Produkten mit ihren Lösungen
wesentliche schneller auf den Markt gekommen sind und Händler aufgrund der geringen Nachfrage kaum
Bluetooth-Produkte angeboten haben.
Lange wurde auch über die Konkurrenz von Bluetooth und WLAN (IEEE 802.11) diskutiert, ein
aktueller Report von Forrester Research [48] kommt aber zu dem Schluss, dass sich beide Verfahren
ohne Marktrivalität etablieren werden, was nicht zuletzt daran liegt, dass Bluetooth bei seiner Einführung
als Industriestandard im Jahr 1998 als Kabelersatz für die Verbindung unterschiedlicher Geräte und nicht
als Netzwerktechnologie konzipiert wurde. Mehr zur Bluetooth versus WLAN findet sich in Kapitel 3
(Verwandte Technologien).
5.1
Bluetooth kommt langsam, aber stark
Mittlerweile hat sich Bluetooth aber weit von seiner ursprünglichen Funktion entfernt, und der
Markt hat ein beträchtliches Volumen erreicht. Lars Godell von Forrester Research ist sogar der
- 137 -
Auffassung, dass es im Jahr 2006 rund 235 Millionen Bluetooth-Geräte geben wird, im Vergleich zu etwa
22 Millionen WLAN-Produkten.
Auch die internationale Unternehmensberatung Frost & Sullivan [38], welche 1961 gegründet
wurde und seit nunmehr über 40 Jahren verlässliche Marktdaten und Prognosen liefert, sieht in einer
aktuellen Studie vom Oktober 2003, die sich auf der Befragung von über 100 Führungskräften in acht
europäischen Ländern stützt, in Bluetooth einen milliardenschweren Markt für Mobilfunkbetreiber,
Gerätehersteller und Dienstanbieter. Der Studie zufolge hat der Bekanntheitsgrad drahtloser
Technologien zugenommen, und Bluetooth erfreut sich vor allem auf Mobiltelefonen zunehmender
Verbreitung, gefolgt von Computern und Peripheriegeräten. Als Schlüsselanwendung gilt die Verbindung
vom Notebook zum Handy, die den Internetzugang über das Mobilfunknetz ermöglicht. Noch in diesem
Jahr erwartet Forst & Sullivan, dass die Anzahl der produzierten Bluetooth-Chips die 70-MillionenMarke überschreiten wird, 2004 soll sich der Absatz mit 120 Millionen verdoppeln.
Frost & Sullivan sieht ein erhebliches Potenzial vor allem bei Mobiltelefonen und PC-basierten
Anwendungen, Fortschritte bei Sicherheit, Kosten und der Bereitstellung sinnvoller Anwendungen
vorausgesetzt. Zudem werden neue Bereiche wie Industrie- und Automobilanwendungen mit der Zeit
immer mehr an Bedeutung gewinnen (siehe unten) und im Bereich Personal Area Networking (PAN) gibt
es derzeit keine wirkliche Konkurrenz, die Bluetooth in Bezug auf Reichweite und Marktreife das Wasser
reichen könnte. Frost & Sullivan betont auch, dass sich selbst Kritiker schwer tun würden, eine andere
drahtlose Kommunikationstechnologie zu nennen, aus der in nur sechs Jahren eine derartige Vielfalt von
Anwendungen hervorgegangen ist.
Die Nachfrage nach Bluetooth-Geräten im Unternehmensbereich ist allerdings noch ziemlich
niedrig, nur neun Prozent der befragten Unternehmen verwenden es bereits, weitere 22 planen eine
Nutzung in nächster Zeit. Seit der ersten Anwenderanalyse 2001 haben aber der Bekanntheitsgrad und
das Verständnis der Technologie stark zugenommen und immerhin 64 Prozent aller befragten
Unternehmen gaben an, dass drahtlose Datendienste spürbare wirtschaftliche Vorteile bringen.
Das Beratungsunternehmen Gartner [55] sieht für Bluetooth auch die besten Chancen, in
Mobiltelefonen eine Technologie für den Massenmarkt zu werden, rät aber Unternehmen, mit dem
Einsatz von Bluetooth noch abzuwarten, bis de-facto-Standards wie „Wi-Fi“ [56] auftauchen welche die
Interoperabilität zwischen Geräten unterschiedlicher Hersteller sichern.
- 138 -
5.2
Die kritische Masse ist erreicht
Viele Gründe sprechen dafür, dass die kritische Masse für Bluetooth nun erreicht ist. Nach
Angaben der Bluetooth SIG wurde im dritten Quartal 2003 ein Meilenstein gesetzt: Erstmals wurden pro
Woche mehr als eine Million Bluetooth-fähiger Produkte verkauft. Für die SIG ist damit die Marktreife
erreicht, obwohl dieser Erfolg überraschend kommt, zumal die Konsumenten dieser Technologie nach
wie vor eher unbeteiligt gegenüber stehen. [3]
Die Verabschiedung der Bluetooth-Spezifikation v1.1 im März 2001 war eine wesentliche
Voraussetzung für Interoperabilität und Funktionsumfang, um eine breite Akzeptanz bei
den Konsumenten zu schaffen.
Die Übernahme des Bluetooth-Standards v1.1 als IEEE-Norm 802.15.1 im Jänner 2002
dokumentiert den Reifegrad dieser Spezifikation und setzt damit auch ein klares
Marktsignal.
Die Bluetooth-Spezifikation v1.2 vom November 2003 bringt kürzere Verbindungszeiten,
eine höhere Störungssicherheit durch ein adaptives Frequenzsprungverfahren, eine höhere
Fehlersicherheit sowie ein verbessertes Quality of Service (siehe dazu Kapitel 2.6,
Bluetooth 1.2 und Kapitel 2.4.3, Quality of Service) bei gleichzeitiger Kompatibilität zu
Version 1.1. Erste Serienprodukte werden für Mitte 2004 erwartet.
Es existieren bereits Single-Chip-Lösungen, welche die Voraussetzung für ein
platzsparendes Design schaffen. So beispielsweise der „BlueCore2“ genannte Chip der
Firma Cambridge Silicon Radio (CSR) [61], welcher in 0,18 µm Technik gefertigt wird,
Außenmaße von 6 x 6 mm hat und beispielsweise in Fujitsu-Siemens’ PDA Pocket Loox
eingebaut ist; CSR erwartet einen Stückpreis von 6,30 USD bei einer Abnahme von 1
Million Stück. Ein weiteres Beispiel ist der BlueMoon Single PMB8760 von Infineon
[62], der in 0,13 µm-Technik gefertigt ist, einen ARM7-Controller für die Verwaltung
höherer Bluetooth-Protokollschichten, Schnittstellen wie USB und UART sowie einen
Flash-Speicher bereits integriert hat. Der Preis sollte in „hohen Stückzahlen“ unter 4 Euro
liegen. [Kral03]
Die Verfügbarkeit von Bluetooth-Betriebssystemtreibern für MacOS-X, Linux und
Windows XP (mit Service Pack 1 und einer Bluetooth-Erweiterung von Microsoft oder
Service Pack 2, das im ersten Halbjahr 2004 erscheinen sollte) als auch Windows
CE.NET [57] und SymbianOS 7.0 [58] ist für die Akzeptanz von Bluetooth von nicht zu
unterschätzender Bedeutung.
- 139 -
Der angestrebte Preisindex von unter 5 USD für die Bluetooth-Integration für den
Hersteller kommt in Reichweite. Rob Hoeben, Bluetooth Product Manager von Philips
Semiconductors, erwartet langfristig eine Senkung auf rund 3 USD. [Hoeb03]
2001 wurden bereits mehr Bluetooth- als WLAN-Chipsätze verkauft, 2003 wurde die
„Schallmauer“ von einer Million erzeugter Bluetooth-Chips pro Woche durchbrochen.
Im Moment haben unzählige Bluetooth-Geräte ihren Markteintritt, immer mehr Geräte
sind verfügbar. (siehe Kapitel 5.3, Bluetooth im Endgerätemarkt).
Die Entwicklung hocheffizienter SMD-Antennen vermindert zusätzlich den Platzbedarf
bei der Bluetooth-Integration. So bietet beispielsweise Phycomp eine 7,3 x 5,5 x 1,4 mm
große Antenne mit einem Gewicht von nur 0,16 g.
„Bluetooth“ ist zu einem gut bekannten Markennamen geworden, der mit der drahtlosen
Verbindung von Geräten assoziiert wird. Die Allgegenwärtigkeit des Markenzeichens
und die Tatsache, dass nur Geräte die den Standard ordnungsgemäß implementieren
damit gekennzeichnet werden dürfen, verstärkt bei den Konsumenten das Verständnis
dass Bluetooth kein proprietärer Standard ist sondern eine Menge von Firmen Geräte
erzeugt, die untereinander kompatibel sind. Dies ist auch für Herstellerfirmen von
Bedeutung, da das Bluetooth-Markenzeichen andeutet, dass das entsprechende Produkt
einen Mehrwert bietet und mit anderen Bluetooth-Produkten zusammenarbeitet. [Bray02]
5.3
Bluetooth im Endgerätemarkt
Anders als WLAN, das speziell für die Funkvernetzung entwickelt wurde, oder DECT, das
hauptsächlich für Schnurlostelefone genutzt wird, eignet sich Bluetooth mit seiner leicht erweiterbaren
Spezifikation für viele Anwendungen. Derzeit gibt es allein auf dem deutschen Markt hunderte und
weltweit insgesamt über 1200 zertifizierte Bluetooth-Geräte, und die Vielfalt an Produkten ist
mittlerweile kaum mehr zu überblicken. Bluetooth verbindet Mobiltelefone mit Headsets, PDAs und
Freisprecheinrichtungen in Kraftfahrzeugen, Notebooks mit DSL-Modems oder Tastaturen, Mäuse und
Digitalkameras mit dem PC, der mit relativ preiswerten USB-Adaptern Bluetooth-fähig wird. Ericsson
erwartet beispielsweise, dass bereits im kommenden Jahr kaum mehr ein Bluetooth-loses Mobiltelefon
verkauft wird. Es ist aber auch zu erwarten, dass sich aufgrund der Vielseitigkeit von Bluetooth
langfristig zahlreiche neue Anwendungsbereiche ergeben werden.
- 140 -
Gegenüber proprietären Funktechnologien (z.B. Logitech’s „Cordless Desktop“, der eine drahtlose
Verbindung von Tastatur und Maus mit einem PC ermöglicht) kann Bluetooth mit Verschlüsselung,
höherer Reichweite und störungsfreier Kommunikation – auch beim Betrieb mehrer solcher Geräte im
selben Raum – punkten.
Eine Datenbank mit allen derzeit zertifizierten Bluetooth-Produkten ist auf der SIG-Website [60]
zu finden. Auch das Computermagazin c’t [53] hat eine Datenbank [59] gestartet, die sämtliche im
deutschsprachigen Raum erhältlichen Bluetooth-Geräte enthält.
Im Folgenden sind einige aktuelle Produkte mit integriertem Bluetooth-Modul aufgelistet, welche
die zunehmende Verbreitung von Bluetooth untermauern sollen:
Nokia 6600: Tri-Band-Handy, SymbianOS 7.0, Unterstützung der Bluetooth Java API
JSR-82, Videoaufnahmen mit Sound
Nokia 610: Kfz-Einbausatz, der das Bluetooth SIM Access Profile (siehe Kapitel 2.5.18,
SIM Access Profile) unterstützt und damit auf die SIM-Karte eines gekoppelten
Mobiltelefons zugreift, mit dessen Nummer es sich im Mobilfunknetz identifiziert; die
Verbindung wird durch Tastendruck oder das Verlassen des Autos gekappt.
Siemens SX1: Tri-Band-Handy, Symbian OS 7.0, Java J2ME kompatibel
Siemens U10: Dual-Mode GSM/UMTS-Handy, Videostreaming
Nokia NGage: Kombination von Tri-Band-Handy, Spielkonsole und UKW-Radio; Java
J2ME kompatibel
Nokia Digital Pen: Sendet handgeschriebene Nachrichten an ein gepaartes Mobiltelefon,
um sie zu speichern oder per MMS zu verschicken.
HP Deskjet 450WBT: Ermöglicht das Drucken digitaler Fotos, Dokumente,
Telefonbucheinträge, Termine, SMS-Nachrichten etc. via PC, PDA oder Handy. Nokia
stellt für die Smartphones 7650 und 3650 entsprechende Druck-Software zum Download
bereit, die Geschwindigkeit liegt aber mit maximal 723 kBit/s deutlich unter der einer
USB-Verbindung.
Siemens Pocket LOOX 610 / HP iPAQ Pocket-PC H5550: Intel XScale 400MHz
Prozessor, integriertes IEEE 802.11b WLAN, Fast IrDa und USB, Windows Mobile 2003
- 141 -
Fujitsu-Siemens Connect2Air Bluetooth USB Dongle: Sehr kleiner USB Dongle, der zur
Connect2Air-Familie diverser Drahtlosprodukte gehört.
IBM ThinkPad T40p: High-End-Notebook mit integriertem WLAN, Windows XP
Professional
Bluetooth Headset BT2000: 29g leichtes Headset, das sich dank einer speziellen
Basisstation mit einem beliebigen kabelgebundenen Telefon benutzen lässt.
Grundsätzlich eignen sich Headsets auch, um den PC via IP-Telefonie zum Telefonieren
zu benutzen. Stereo-Headsets sind angekündigt, aber noch nicht verfügbar.
AVM BlueFRITZ! AP-DSL: Ermöglicht kabellosen Zugang zu ISDN bzw. DSL via
Bluetooth und eignet sich für die Verwendung mit PC, Scanner, Drucker, BluetoothSchnurlostelefon etc.; alle Geräte haben gemeinsamen Zugriff auf die im Piconetz
freigegebenen Ressourcen.
Logitech diNovo Media Desktop: Kabellose Tastatur, Maus und Multifunktionsblock; das
Ladegerät kann als Bluetooth-Hub verwendet werden.
Allgemein kann man sagen, dass es kaum mehr einen Notebook-, PDA- bzw. Handy-Hersteller,
der kein Modell mit integriertem Bluetooth-Chip anbietet, aber auch im Bereich der PC-Peripherie nimmt
das Angebot an Bluetooth-fähigen Produkten kontinuierlich zu. Weiters fällt auf, dass bei Notebooks und
PDAs Microsoft, bei Smartphones hingegen Symbian die Betriebssystem-Marktführung hat.
Aber auch im industriellen Bereich findet Bluetooth zunehmende Verbreitung. So rüsten derzeit
Firmen wie UPS oder Bofrost ihre Lieferfahrzeuge insofern um, dass die Daten, welche der Fahrer nach
Auslieferung der Ware in seinem mobilen Terminal gespeichert hat, automatisch via Bluetooth und
Mobilfunk an die Zentrale weitergeleitet werden. DaimlerChrysler baut Fahrzeuge, deren
Diagnosesysteme via Bluetooth und Mobilfunk mit dem Service in Verbindung treten, und BMW hat eine
Variante seines Z4 vorgestellt, bei dem es möglich ist, viele Konsolenfunktionen des Autos über ein
Bluetooth-Headset zu steuern, ohne dabei die Hände vom Lenkrad nehmen zu müssen. Auch im Bereich
der Vernetzung von Sensoren, Aktuatoren und Controllern in drahtlosen Netzwerken sowie der
drahtlosen Bedienung und Wartung verteilter Steuerungen sind viele Anwendungsszenarien denkbar.
Für Entwickler hat der zunehmende Erfolg von Bluetooth aber auch die Kehrseite, dass der
Wettbewerb zunimmt, und man für einen längerfristigen Erfolg mittlerweile einen gut durchdachten
Business-Plan braucht. Da die Konsumenten immer besser mit der Technologie zurecht kommen, ist auch
zu erwarten, dass der Kundensupport in den Hintergrund tritt und der Preis wettbewerbsentscheidend
wird. Nach Ansicht von Frost & Sullivan werden sich in den nächsten Jahren die Bluetooth- 142 -
Komponenten immer stärker angleichen, Wachstumschancen sieht man vor allem in der Erschließung
neuer Anwendungsbereiche. Der langfristige Erfolg der Unternehmen wird nach Frost & Sullivan davon
abhängen, ob es gelingt, aus den verschiedenen neuen Anwendungsbereichen genau die richtigen zu
identifizieren, um das Interesse der Kunden zu wecken und einen Kundenstamm aufzubauen.
- 143 -
6 Bluetooth – quo vadis?
Bluetooth-Module, die neben Steuerung und Verschlüsselung auch die komplette Sende- und
Empfangseinheit beinhalten, haben mittlerweile nur noch die Größe einer Zwei-Euro-Münze. In Serie
produziert liegen die Kosten mittlerweile unter 10 Euro, bei der prognostizieren Verbreitung wird der
Preis aber deutlich unter die Fünf-Euro-Marke fallen.
Nach den Vorstellungen der SIG wird Bluetooth zuerst andere schnurlose Techniken im
Nahbereich – allen voran IrDA und DECT – ergänzen, um sie dann mittelfristig abzulösen. [Kral03]
Momentan kämpft Bluetooth aber noch mit einigen Problemen, wobei mit Version 1.2 des BluetoothStandards viele Verbesserungen – vor allem die verbesserte Störungsunempfindlichkeit gegenüber IEEE
802.11b/g – erreicht wurden.
Die Entwicklung des Bluetooth-Standards zeigt mit jeder Version signifikante Verbesserungen,
wodurch seit Version 1.1 Marktreife erreicht ist und sich Bluetooth nun auch am Massenmarkt
explosionsartig verbreitet (siehe Kapitel 5, Bluetooth Markt). Die seit November 2003 veröffentlichte
Version 1.2 schaffte mit durch Verbesserungen bzgl. Störsicherheit und Verbindungsaufbau die
Voraussetzungen für noch breitere Akzeptanz und eine Stärkung der Marktposition.
Eine Herausforderung, der sich die Gerätehersteller und die SIG noch stellen müssen, ist die
mangelhafte Interoperabilität, die darauf zurückzuführen ist, dass die Bluetooth-Spezifikation in den
höheren Schichten des Protokollstack zu viele Implementierungsfreiheiten lässt. Unterstützung bietet hier
beispielsweise die vom Computermagazin c’t betriebene Datenbank [59], die es Käufern ermöglicht, alle
unterstützten Profile eines Bluetooth-Gerätes und dazu kompatible Geräte anzuzeigen. In diese
Datenbank fließen Informationen ein, welche die c’t-Redaktion in ihren Tests sammelt, aber auch
Anwender können ihre Erfahrungen eintragen.
Ein Problem stellen nicht zertifizierte Bluetooth-Artikel dar, vor denen TDK Systems [52] in
einem Presseartikel vom 23. September 2003 warnt. Derzeit würden laut TDK rund 50 Prozent des
Zubehörs entweder den öffentlichen Qualifikations-Prozess nicht durchlaufen oder gegen WarenzeichenVorschriften verstoßen. Das Problem dabei sei, dass diese Produkte oft die Standards für Interoperabilität
und Support nicht erfüllen, was Kunden davor abschrecken könnte, weiterhin Bluetooth-Geräte zu
nutzen. Damit die Benutzer aber Vertrauen in die Technologie fassen, sei es wichtig, dass nur dort
Bluetooth draufsteht, wo wirklich zertifiziertes Bluetooth drin ist. Die Bluetooth SIG hat in diesem
Zusammenhang alle Mitglieds-Unternehmen gebeten, nach gesetzeswidrigen Produkten Ausschau zu
halten.
- 144 -
Auch im Bereich Sicherheit (vor allem in Bezug auf unsichere Konfigurationen und dem
fehlenden Risikobewusstsein der Anwender) sowie den verfügbaren Anwendungen (es gibt noch kaum
überzeugende Anwendungen abseits von Gerätesynchronisation und Internetverbindung via Bluetoothfähige Mobiltelefone) sieht Gartner noch erhebliches Verbesserungspotenzial. Wichtig für den künftigen
Erfolg von Bluetooth wird auch die einfache Bedienung sein, d.h. dass man kein Handbuch für dessen
Verwendung benötigen sollte. Einen wichtigen Schritt in diese Richtung tätigte die Bluetooth SIG
vergangenen Dezember mit dem „Five Minute Ready“- Programm, das eine Herausforderung für alle
Hersteller sein soll, Bluetooth- Produkte zu entwickeln, die innerhalb kürzester Zeit genutzt werden
können. Gartner kritisiert auch die nach wie vor schlechten Benutzerschnittstellen für Verbindungsaufbau
und Sicherheitseinstellungen.
Zudem seien sich die meisten Benutzer über die Möglichkeiten von Bluetooth noch nicht bewusst;
nur ein geringer Prozentsatz davon nutzt derzeit die Bluetooth-Fähigkeiten der gekauften Geräte.
Bluetooth wird in Zukunft mit mehreren Technologien im WPAN-Bereich konkurrieren müssen,
von denen die Wichtigsten voraussichtlich WiMedia und ZigBee sein werden (siehe Kapitel 3,
Verwandte Technologien). Ob Bluetooth den vorhandenen Marktvorsprung wird nutzen können oder ob
sie sich nebeneinander etablieren werden, ist aus heutiger Sicht schwer abzusehen.
Aber was auch immer passiert, eines ist für [Bray02] klar: Bluetooth wird auf jeden Fall sehr groß
werden – entweder als Verbraucher-Flop, oder aber als enormer Erfolg; wir wollen letzteres hoffen 
- 145 -
7 Literaturverzeichnis
Alle Links funktionierten am 2. Dezember 2003.
7.1
Bücher und Publikationen
[And03]
Stephan Anders: “Bluetooth in Enterprises – Gains and Pains”, Siemens CT IRC TIS
Report, 03/2003
[BAVW03a] Bluetooth Audio Video Working Group: “Generic Audio/Video Distribution Profile”,
Revision 1.0, 22.05.2003; Internet:
https://www.bluetooth.org/foundry/specification/docman/
[BAVW03b] Bluetooth Audio Video Working Group: “Advanced Audio Distribution Profile
Specification”, Revision 1.0, 22.05.2003; Internet:
https://www.bluetooth.org/foundry/specification/docman/
[BAVW03c] Bluetooth Audio Video Working Group: “Audio/Video Remote Control Profile”, Revision
1.0, 22.05.2003; Internet: https://www.bluetooth.org/foundry/specification/docman/
[BCIA03]
Bluetooth SIG: “Common ISDN Access Profile”, Revision 1.0, 22.05.03; Internet:
https://www.bluetooth.org/foundry/specification/docman/
[BCOR01]
Bluetooth SIG: “Bluetooth Core Specification”, Revision 1.1, 22.02.2001; Internet:
https://www.bluetooth.org/foundry/specification/docman/
[BCOR03]
Bluetooth SIG: “Bluetooth Core Specification”, Revision 1.2, 05.11.2003; Internet:
https://www.bluetooth.org/spec/
[Beut04]
Jan Beutel, Oliver Kasten et.al.: „Prototyping Sensor Network Applications with
BTnodes“, IEEE European Workshop on Wireless Sensor Networks, Berlin, 01/2004.
Internet: http://www.inf.ethz.ch/vs/publ/papers/prototyping-btnode.pdf
[BHCR03]
Bluetooth SIG: “Hardcopy Cable Replacement Profile”, Revision 1.0a, 22.05.03; Internet:
https://www.bluetooth.org/foundry/specification/docman/
[BPRO01]
Bluetooth SIG: “Bluetooth Profiles Specification”, Revision 1.1, 22.02.2001; Internet:
https://www.bluetooth.org/foundry/specification/docman/
[Bray01]
Jennifer Bray, Charles F Sturman: “Bluetooth – Connect Without Cables”, 2001 Prentice
Hall, ISBN 0-1308-9840-6
- 146 -
[Bray02]
Jennifer Bray, Charles F. Sturman: “Bluetooth 1.1 – Connect Without Cables, Second
Edition”, 2002 Prentice Hall, ISBN 0-13-066106-6
[BSI03]
Bundesamt für Sicherheit in der Informationstechnik (BSI): „Bluetooth – Gefährdungen
und Maßnahmen“, 2003; Internet: http://www.bsi.de/literat/doc/bluetooth/bluetooth.pdf
[BSIM03]
Bluetooth SIG: “SIM Access Profile”, Revision 1.0, 22.05.03; Internet:
https://www.bluetooth.org/foundry/specification/docman/
[DECT02]
DECT Consortium: „Positioning of DECT in relation to other radio access technologies”,
2002; Internet: http://www.dect.org/pdf/dect_positioning_version1.pdf (12.11.2003)
[Eker02]
Johan Eker, Anton Cervin, Andreas Hörjel: “Distributed Wireless Control Using
Bluetooth”, IFAC Conference on New Technologies for Computer Control, Hongkong,
11/2001; Internet: http://www.control.lth.se/documents/2001/eker+01.pdf
[Fers03a]
Alois Ferscha: Vorlesung „Embedded Systems“, Institut für Praktische Informatik –
Abteilung Software, Universität Linz, 2003; Internet: http://www.soft.unilinz.ac.at/Teaching/Lehrangebot/Informatik/
[Fers03b]
Alois Ferscha: Vorlesung „Telekooperation“, Institut für Praktische Informatik – Abteilung
Software, Universität Linz, 2003; Internet: http://www.soft.unilinz.ac.at/Teaching/Lehrangebot/Informatik/
[Fluh01]
Scott R. Fluhrer, Stefan Lucks: „Analysis of the E0 Encryption System”, Selected Areas in
Cryptography – SAC 2001, Las Vegas, USA, 03/2001; Internet: http://th.informatik.unimannheim.de/People/Lucks/ papers/e0.ps.gz
[FMK02]
Forum Mobilkommunikation: „Weißbuch Mobilkommunikation: Bluetooth, ZigBee und
WLAN“, 2003; Internet: http://www.fmk.at
[Gell03]
Hans-Werner Gellersen: „Wearable Computing – Technologie und Anwendungen tragbarer
Rechner“, HMD – Praxis der Wirtschaftsinformatik, 1999, Heft 209; Internet:
http://hmd.dpunkt.de/209/
[Hand03]
Matthias Handy, Marc Haase, Dirk Timmermann: “Der Verlust der informationellen
Selbstbestimmung? Anonymitätsaspekte bei Bluetooth und WLAN“, 4. Informations- und
Kommunikationstechnologie (IuK)- Tage Mecklenburg Vorpommern, 06/2003; Internet:
http://www-md.e-technik.uni-rostock.de/veroeff/20030520_IUK_final.pdf
[Hoeb03]
Rob Hoeben: „Getting Bluetooth Wireless Technology – Below the $4 Dollar Barrier”,
2003; Internet:
http://www.techonline.com/community/tech_topic/bluetooth/tech_paper/29360
[Hopk03]
Bruce Hopkins, Ranjith Antony: “Bluetooth for Java”, 2003 Apress Verlag, ISBN 1-59059078-3
- 147 -
[Kral03]
Arno Kral, Heinz Kreft: „Wireless LANs Networker’s Guide – Bluetooth, HiperLAN,
WLAN & Co.”, 2003 Markt + Technik Verlag, ISBN 3-8272-6329-8
[Laur03]
Adam Laurie, Ben Laurie: “Serious flaws in Bluetooth security lead to disclosure of
personal data”, 2003; Internet: http://bluestumbler.org/
[Lule01]
Martin Luley: Diplomarbeit “Anwendungsszenarien für Bluetooth”, Lehrstuhl für
Informatik IV - RWTH Aachen, 2001
[Matt03]
Friedemann Mattern: Vorlesung „Ubiquitous Computing“, Research Group for Distributed
Systems, ETH Zürich, 2003; Internet:
http://www.inf.ethz.ch/vs/edu/SS2003/UC/index.html
[Merk02]
Andreas Merkle, Anestis Terzis: "Digitale Funkkommunikation mit Bluetooth", 2002
Franzis'-Verlag, ISBN 3-7723-4654-5
[Mill01]
Brent A. Miller, Chatschik Bisdikian: “Bluetooth Revealed – The Insider’s Guide to an
Open Specification for Global Wireless Communications”, 2001 Prentice Hall, ISBN 01309-0294-2
[Mobi03]
MobiLearn Konsortium: “State-of-the-Art Technologietrends & Endgeräte”, 2003; Internet:
http://www.mobilearn.at
[Murp02]
Patrick Murphy, Erik Welsh, Patrick Frantz: “Using Bluetooth for Short-Term Ad-Hoc
Connections Between Moving Vehicles: A Feasibility Study”, IEEE Vehicular Technology
Conference (VTC), Birmingham, 2002; Internet:
http://cmc.rice.edu/docs/docs/Mur2002May5UsingBluet.pdf
[Roth02]
Jürgen Roth: „Mobile Computing“, 2003 Dpunkt Verlag, ISBN 3-8986-4165-1
[Schi03]
Jochen Schiller: "Mobilkommunikation", 2003 Pearson Studium, ISBN 3-8273-7060-4
[Schm03]
Albrecht Schmidt, Frank Siegemund et.al.: „Mobile Ad-hoc Communication Issues in
Ubiquitous Computing – The Smart-Its Experimentation Platform“, Proceedings Personal
Wireless Communication Conference, Venedig, 09/2003; Internet:
http://www.inf.ethz.ch/vs/publ/papers/smart-its-project-presentation.pdf
[Siko01]
Axel Sikora: „Wireless LAN – Protokolle und Anwendungen“, 2001 Addison-Wesley,
ISBN 3-8273-1917-X
[Stef02]
Andreas Steffen: Vorlesung „Signale und Übertragung“, Institut für Technik, Informatik
und Naturwissenschaften, Züricher Hochschule Winterthur, 2002; Internet: http://wwwt.zhwin.ch/it/su/
[Tan02]
Godfrey Tan: “Blueware: Bluetooth Simulator for ns”, MIT Technical Report, MIT-LCSTR-866, Cambridge, 10/2002; Internet: http://nms.lcs.mit.edu/projects/blueware/blueware866.pdf
- 148 -
[Tane00]
Andrew S. Tanenbaum: „Computernetzwerke“, 2003 Pearson Studium, ISBN 3-82737046-9
[Topl02]
Kim Topley: „J2ME in a Nutshell“, 2002 O’Reilly, ISBN 0-596-00253-X
[Wang00]
Zhiyong Wang: „Comparison of Bluetooth and Jini for Use in Wireless Personal Area
Networks”, Individual Project Report, Bradley Department of Electrical and Computer
Engineering, Virginia Polytechnic Institute and State University, Spring 2000; Internet:
http://fiddle.visc.vt.edu/courses/ecpe6504-wireless/projects_spring2000/report_wang.pdf
7.2
Internet
[1]
The Official Bluetooth Wireless Info Site: https://www.bluetooth.com
[2]
Bluetooth Spezifikation: https://www.bluetooth.org/foundry/specification/docman/
[3]
The Official Bluetooth SIG Membership Site: https://www.bluetooth.org/
[4]
Siemens PSE Bluetooth: http://www.siemens.at/bluetooth/
[5]
Siemens SieMo S50037 Bluetooth Modul:
http://www.siemens.at/bluetooth/de/download/bluetooth02v2.pdf
[6]
European Telecommunications Standards Institute (ETSI): http://www.etsi.org
[7]
International Telecommunication Union – Telecommunication Standardization Sector
(ITU-T): http://www.itu.int/ITU-T/
[8]
ITU-T Recommendation Q.931: http://www.itu.int/itudoc/itu-t/com11/implgd/q931.html
[9]
Infrared Data Association (IrDA): http://www.irda.org/
[10]
Institute of Electrical and Electronics Engineers (IEEE) 802.11 Working Group for WLAN:
http://grouper.ieee.org/groups/802/11/
[11]
Institute of Electrical and Electronics Engineers (IEEE) 802.15 Working Group for WPAN:
http://grouper.ieee.org/groups/802/15/
[12]
Digitale Aura … von Menschen und Dingen:
http://www.wissen.jku.at/univationen/0209/ferscha.htm
[13]
Electronic Bill and Payment: http://www.ebpp.at/
[14]
IEEE – Pervasive Computing: http://www.computer.org/pervasive/
- 149 -
[15]
IBM WatchPad 1.5: http://www.trl.ibm.com/projects/ngm/index_e.htm
[16]
The Smart-Its Project: http://www.smart-its.org/
[17]
Palo Wireless Bluetooth Ressource Center: http://www.palowireless.com/bluetooth/
[18]
Heise Online Mobil: http://www.heise.de/mobil
[19]
Wearable Computing at the MIT Laboratory:
http://www.media.mit.edu/wearables/people.html
[20]
Frog Design / Motorola Offspring Wearables Concept (Phone Scoop), 03/2003:
http://www.phonescoop.com/articles/moto_wearables/
[21]
Samsung GPRS Wrist Watch Phone, 03/2003: http://www.samsung.com
[22]
ITU-Recommendation G.711: http://www.itu.int/rec/recommendation.asp
?type=folders&lang=e&parent=T-REC-G.711
[23]
BlueZ: http://bluez.sourceforge.net/
[24]
JBlueZ: http://jbluez.sourceforge.net/
[25]
Verbesserungen der Bluetooth-Version 1.2: https://www.bluetooth.org/spec/?
[26]
Pressemeldung Release Bluetooth-Spezifiaktion 1.2
http://www.bluetooth.com/dev/spec.v12.asp
[27]
ZigBee Ressource Center: http://www.palowireless.com/zigbee/
[28]
tecChannel : Bluetooth 2.0 : http://www.tecchannel.de/news/20020613/thema200206137813.html
[29]
Ultra Wideband and WiMedia : http://www.embedded.com/story/OEG20030319S0019
[30]
DECT: http://www.dect.org
[31]
HiperLAN2-Forum: http://www.hiperlan2.com/
[32]
Tektronix PTW60 Protocol Tester for Bluetooth Solutions; Internet: http://www.tek.com/
Measurement/Products/catalog/2DA_14925/eng/index.html
[33]
TechOnline: „Bluetooth Updates and Changes – V1.2 Illustrated”
http://www.techonline.com/community/tech_topic/bluetooth
[34]
Der Standard Online: http://derstandard.at/
[35]
heise online: http://www.heise.de/
- 150 -
[36]
heise mobil: http://www.heise.de/mobil/
[37]
teltarif.de: http://www.teltarif.net/
[38]
Frost & Sullivan: http://www.wireless.frost.com
[39]
EE Times Online – Weltweiter Industrie-Nachrichtendiens für Elektronikingenieure und
technisches Management: http://www.eetimes.de/
[40]
SYSTEMS-world: http://www.systems-world.de/
[41]
golem.de – IT-News für Profis: http://www.golem.de/
[42]
about IT: http://www.aboutit.de/
[43]
ORF futurezone: http://futurezone.orf.at/
[44]
FMK Forum Mobilkommunikation: http://www.fmk.at/mobilkom/
[45]
Tom’s Hardware Guide: http://www.tomshardware.de/
[46]
Bluetooth World Congress 2003: http://www.ivs.tu-berlin.de/bluetoothWC2003/
[47]
CertificationSuccess.com: http://www.certificationsuccess.com/
[48]
ECIN – Electronic Commerce Info Net: http://www.ecin.de/
[49]
Forrester Research – Technology Research and Advice: http://www.forrester.com/
[50]
Samsonite: http://www.samsonite.com/hardlite/flash/site.html
[51]
RFI Mobile Technologies: http://www.rfi.de/
[52]
TDK Systems Press: http://www.tdksystems.com/corporate/press/
[53]
c’t – magazin für computertechnik: http://www.heise.de/ct/
[54]
Bluejacking Website: http://www.bluejackq.com/
[55]
Gartner: http://www.gartner.com
[56]
Wireless Firelity (Wi-Fi) Alliance: http://www.weca.net/
[57]
Windows CE .NET: http://www.microsoft.com/windows/embedded/ce.net/
[58]
Symbian OS – the mobile operating system:
http://www.tecchannel.de/news/20031021/thema20031021-12204.html
- 151 -
[59]
heise - Bluetooth Datenbank: http://www.heise.de/mobil/bluetooth/db/
[60]
Bluetooth SIG Product Database: http://www.bluetooth.com/tech/products.asp
[61]
Cambridge Silicon Radio (CSR): http://www.csr.com/
[62]
Infineon Technologies AG: http://www.infineon.com/
[63]
MS Windows Embedded: http://www.microsoft.com/windows/embedded/
[64]
Netzwerk-Simulator ns-2: http://www.isi.edu/nsnam/ns/
[65]
BlueHoc – Bluetooth Performance Evaluation Tool: http://oss.software.ibm.com/bluehoc/
[66]
Internet Engineering Task Force (IETF) - RFC Page: http://www.ietf.org/rfc.html
[67]
Infrared Data Association: http://www.irda.org/
[68]
ZigBee Alliance: http://www.zigbee.org/
[69]
Ultra Wideband Working Group: http://www.uwb.org/
[70]
Bluetooth Simulation Project: http://tochna.technion.ac.il/project/bt_sim/html/bt_sim.html
[71]
BlueWare – Support for Self-organizing Scatternets:
http://nms.lcs.mit.edu/projects/blueware/
[72]
Firma Rococo: http://www.rococosoft.com/
[73]
The Community Resource for Jini Technology: http://www.jini.org/
[74]
The Java Community Process Program – JSR 82: http://www.jcp.org/en/jsr/detail?id=82
[75]
Reference Implementation (RI) and Technology Compatibility Kit (TCK) for JSR-82:
http://www.motorola.com/java
[76]
Atinav Inc. – aveLink Bluetooth: http://www.atinav.com/bluetooth/
[77]
Symbian OS: http://www.symbian.com/
[78]
MSDN: http://msdn.microsoft.com/
[79]
AXIS OpenBT Stack: http://sourceforge.net/projects/openbt/
[80]
Affix Bluetooth Protocol Stack: http://affix.sourceforge.net/
- 152 -
8 Abbildungsverzeichnis
Abbildung 1: Bluetooth-Logo [1]................................................................................................................. 4
Abbildung 2: SieMos Bluetooth Modul [5].................................................................................................. 5
Abbildung 3: Telefonie über verschiedene Medien [Lule01]....................................................................... 7
Abbildung 4: Audio-Konfiguration mit Bluetooth [Lule01] ........................................................................ 8
Abbildung 5: PC-Peripherie per Bluetooth [Lule01] ................................................................................. 10
Abbildung 6: Vernetzter Haushalt [Lule01] ............................................................................................... 11
Abbildung 7: Fernbedienung industrieller Geräte [Lule01] ....................................................................... 12
Abbildung 8: Bluetooth als Schlüsselersatz [Lule01] ................................................................................ 13
Abbildung 9: Smart-It „BTNode“ [16] ...................................................................................................... 18
Abbildung 10: The Disappearing Computer [Matt03] ............................................................................... 19
Abbildung 11: Piconetz mit einem Master und einem Slave (a), einem Master und mehreren Slaves (b)
und ein Scatternetz bestehend aus drei Piconetzen [BCOR01] .......................................................... 23
Abbildung 12: Scatternetz (M=Master, S=Slave, P=Parked, SB=Standby) [Schi03] ................................ 24
Abbildung 13: Bluetooth Protokoll Stack [Lule01] ................................................................................... 25
Abbildung 14: Kollision zwischen Bluetooth und HomeRF [Lule01] ....................................................... 30
Abbildung 15: Einteilung der Zeitschlitze [BCOR01] ............................................................................... 30
Abbildung 16: Einteilung der Zeitschlitze bei Multislot-Paketen [BCOR01] ............................................ 31
Abbildung 17: Datenübertragung in einem Piconetz [Lule01]................................................................... 32
Abbildung 18: Paket-Format [Schi03] ....................................................................................................... 33
Abbildung 19: SCO-Pakete [Schi03] ......................................................................................................... 36
Abbildung 20: ACL-Pakete [Schi03] ......................................................................................................... 37
Abbildung 21: Logische (virtuelle) Kanäle zwischen Bluetooth-Geräten [Lule01] ................................... 38
- 153 -
Abbildung 22: Bluetooth Geräteadresse (BD_ADDR) [Lule01] ............................................................... 39
Abbildung 23: Slaves in Piconetz synchronisieren sich mit Uhr des Masters [Schi03] ............................. 40
Abbildung 24: Bluetooth Basisband Zustände [Schi03] ............................................................................ 42
Abbildung 25: Link Controller Zustandsdiagramm [Lule01] .................................................................... 43
Abbildung 26: Link-Manager-Kommunikation [BCOR01] ....................................................................... 45
Abbildung 27: LMP Verbindungsaufbau [BCOR01] ................................................................................. 47
Abbildung 28: Protokoll-Implementierungen Modul und Host [BCOR01] ............................................... 49
Abbildung 29: Bluetooth-Übertragung zwischen zwei Host-Systemen [BCOR01].................................. 50
Abbildung 30: A-Law-Kennlinie (positiver Quadrant) [Stef02] ................................................................ 51
Abbildung 31: L2CAP im Bluetooth-Stack [BCOR01] ............................................................................. 52
Abbildung 32: L2CAP-Verbindungen [BCOR03] ..................................................................................... 54
Abbildung 33: Datenpaket-Formate [Schi03] ............................................................................................ 54
Abbildung 34: Signalisierungs-Datenpaket [Schi03] ................................................................................. 55
Abbildung 35: SDP-Architektur [BCOR03] .............................................................................................. 58
Abbildung 36: Service Record [BCOR03] ................................................................................................. 59
Abbildung 37: Bluetooth Sicherheitsarchitektur und -protokolle [Schi03] ................................................ 64
Abbildung 38: Übertragungstätigkeit im Zustand Hold [Merk02] ............................................................. 72
Abbildung 39: Übertragungstätigkeit im Zustand Sniff [Merk02] ............................................................. 73
Abbildung 40: Übertragungstätigkeit im Zustand Park [Merk02] ............................................................. 73
Abbildung 41: Ablauf einer QoS-Vereinbarung [Bray02] ......................................................................... 76
Abbildung 42: Vertikale Schnitte [Schi03] ................................................................................................ 78
Abbildung 43: Bluetooth Profile (es fehlt: HID Profile im GAP) [18] ...................................................... 79
Abbildung 44: Protokollstack HCRP [BHCR03] ....................................................................................... 82
Abbildung 45: Bluetooth-Stack bei Verwendung von HIDP [BHID03] .................................................... 83
- 154 -
Abbildung 46: Audio/Video-Übertragungsprofile – Abhängigkeiten [BAVW03a] .................................. 84
Abbildung 47: Anwendungsszenario SIM-Profile [17].............................................................................. 87
Abbildung 48: Faster Connections [32] ..................................................................................................... 91
Abbildung 49: Frequency-Maps [32] ......................................................................................................... 92
Abbildung 50: Die neue L2CAP-Architektur [BCOR03] .......................................................................... 93
Abbildung 51: Reichweite vs. Durchsatz [Murp02] ................................................................................... 95
Abbildung 52: Konfiguration des Masters [65].......................................................................................... 97
Abbildung 53: Visualisierung einer Bluetooth-Simulation mit NAM [70] ............................................... 98
Abbildung 54: Gegenüberstellung Bluetooth-Stack und Blueware-Module [Tan02] ................................ 99
Abbildung 55 WLAN-Infrastruktur [Mobi03] ......................................................................................... 104
Abbildung 56: Mögliche Netztopologien in ZigBee [27] ........................................................................ 107
Abbildung 57: Frequenzspektrum bei Ultra Wideband [29] .................................................................... 109
Abbildung 58: WiMedia Protokollstack [29] ........................................................................................... 110
Abbildung 59: Aufbau von BlueZ [23] .................................................................................................... 114
Abbildung 60: hciconfig........................................................................................................................... 115
Abbildung 61: hcidump ............................................................................................................................ 115
Abbildung 62: hcitool: Anzeige der Connections .................................................................................... 116
Abbildung 63: hcitool: Inquiry ................................................................................................................. 116
Abbildung 64: l2ping ............................................................................................................................... 117
Abbildung 65: SDP Browsing .................................................................................................................. 118
Abbildung 66: Bluetooth-Stack in Windows CE 4.2 [78] ........................................................................ 121
Abbildung 67: Bluetooth und Jini im ISO/OSI Referenzmodell [Wang00] ............................................. 126
Abbildung 68: Rococo Impronto [72] ...................................................................................................... 127
Abbildung 69: Server erstellt das Service und wartet auf Verbindung via L2CAP ................................. 130
- 155 -
Abbildung 70: Abgeschlossenes Inquiry auf dem Client ......................................................................... 132
Abbildung 71: Verbindungsaufbau (Client) ............................................................................................. 134
Abbildung 72: Verbindungsaufbau (Server) ............................................................................................ 134
Abbildung 73: Ping-Pong ......................................................................................................................... 136
- 156 -