1.1 EINFÜHRUNG
1.2 DIE BLUETOOTH PROTOKOLL-ARCHITEKTUR
1.2.1
Transport protocol group
1.2.2
Middleware Protocol Group
1.2.3
Application group
1.3 ZUSAMMENFASSUNG
1.1 Einführung
Bei Bluetooth handelt es sich um eine Kurzstreckenfunk-Technologie,
die im weltweit nicht lizenzierten Industrial-, Scientific- and Medical
2,4 GHz Band (ISM-Band) die problemlose Verbindung von elektronischen Geräten
untereinander ermöglichen soll. Die Reichweite beträgt i.d.R.
zehn Meter, mit speziellen Funkmodulen sind auch bis zu 100 Meter möglich.
In einem sogenannten Pico-Netz können bis zu acht Geräte miteinander
kommunizieren. Ein Piconetz bildet ein Master, der mit bis zu 7 Slaves
verbunden sein kann. Die einzelnen Geräte können außerdem
Teilnehmer in mehreren Pico-Netzen sein, so dass diese wiederum zu einem
sogenannten Scatter-Netz verbunden sein können.
Abbildung 1
Die Brutto-Übertragungsrate von Bluetooth beträgt
maximal 1 Mbit/s und ist von der jeweiligen Betriebsart abhängig (siehe
Tabelle 1).
Betriebsart
|
Datenrate
|
Beispielanwendung
|
Synchron
|
3*2*64 kBit/s
|
Sprachübertragung
|
Asynchron
asymmetrisch
|
721/57,6 kBit/s
|
Surfen
|
Asynchron asymmetrisch
|
2*432,6 kBit/s
|
Netzwerkankopplung
|
Tabelle 1
Bluetooth Sende- und Empfängermodule verhindern
Funkinterferenzen, indem sie 1600 mal pro Sekunde nach einer Pseudo-Zufallsfolge
ihre Frequenz ändern. Für dieses Frequency Hopping sind 79 1
MHz-Kanäle im Bereich zwischen 2,402 und 2,480 GHz vorgesehen. Da
Bluetooth-Module somit "schneller" als die anderen Geräte in diesem
Band sind und nur sehr kurze Datenpakete verschicken, können von außen
kommende Störungen die Verbindung kaum behindern. Speziell der Einfluß
von Mikrowellenöfen, die auch in diesem Frequenzband arbeiten, wird
minimiert.
Entwickelt wurde die Bluetooth-Spezifikation von der
SIG (Special Interest Group) - ein internationales Unternehmens-Konsortium.
Gegründet wurde die SIG ursprünglich von fünf großen
Unternehmen (Ericsson, IBM, Intel, Nokia und Thosiba) und erfreut sich
seitdem regen Zulaufs, so ist Fraunhofer ESK ebenfalls der SIG beigetreten.
Der Name „Bluetooth“ geht auf den dänischen König
Harald Bluetooth (910-987 n.Chr) zurück, der einst das Land vereinte.
Ganz ähnlich soll Bluetooth nun Ordnung schaffen und mittels einer
einheitlichen Schnittstelle Ordnung in das Kabelwirrwar bringen. Bluetooth
soll überall dort eingesetzt werden, wo bisher Kabel für
den Datentransport im Nahbereich eingesetzt wurden. Beispiele hierfür
sind drahtlose Anbindung von Tastatur, Maus, Drucker usw. an den PC bzw.
die Vernetzung von PCs, Notebooks, PDAs usw. untereinander.
Ein weiteres mögliches Anwendungsszenario ist
der Einsatz von Bluetooth in Mobiltelefonen. Befindet man sich außerhalb
seines Bluetooth Versorgungsgebietes, so bindet sich das Telefon in das
Mobilnetz ein, kommt man wieder in den Versorgungsbereich seines Bluetooth-Systems
zurück, so kann man wieder über Bluetooth telefonieren und Daten
austauschen. Das gleiche Modul kann aber auch unterwegs den mobilen Internetzugang
über das Handy ermöglichen. Ein Notebook oder PDA kann über
Bluetooth mit dem Handy kommunizieren und einen Internetserver anwählen.
Im einem Kfz wiederum kann das Mobiltelefon mittels Bluetooth mit einem
Headset oder einer Freisprecheinrichtung Sprachdaten austauschen.
1.2 Die Bluetooth Protokoll-Architektur
Der Aufbau der Bluetooth-Protokollarchitektur ist
in Abbildung 2 dargestellt. Es ist zu sehen, dass verschiedene Applikationen,
die durch Bluetooth unterstützt werden nicht den kompletten Protokoll-Stack
benötigen, sondern jeweils eine durchgängige vertikale Einheit
bilden. Alle höheren Schichten bauen auf den grundlegenden Bluetooth-Protokollen
wie z.B. L2CAP, LMP, Baseband und Bluetooth Radio auf. Diese Architektur
umfaßt sowohl Bluetooth-spezifische Protokolle wie Baseband, LMP,
SDP usw., als auch bereits existierende Protokolle, wie UDP, TCP, IP usw.
Bei der Entwicklung der Architektur wurde auf eine größtmögliche
„Wiederverwendung“ bereits existierender Protokolle geachtet, z.B. wurde
OBEX von IrDA übernommen. Bluetooth ist eine offene Spezifikation,
d.h. es können eigene, auf Bluetooth basierende, propietäre Protokolle
entwickelt werden. Das ermöglicht zukünftigen Anwendungen den
unkomplizierten Zugriff auf Bluetooth.
Abbildung 2a
Der Protokoll-Stack aus Abb.2a lässt sich grob
in drei Gruppen Einteilen /2/:
Abbildung 2b
1.2.1 Transport protocol group
Die „Transport protocol group“ ermöglicht es
Bluetooth Geräten sich gegenseitig zu erkennen, logische und physikalische
Verbindungen zu erstellen, konfigurieren und zu verwalten um somit die
Verbindung zwischen höheren Schichten zu erlauben. Diese Protokollschicht
beinhaltet radio, baseband, link manager, locical link and adaption und
auch das host controller interface, welche im folgenden etwas genauer erläutert
werden sollen.
Radio
Bluetooth Geräte arbeiten bei einer Frequenz
von 2.4 GHz im lizenzfreien ISM Band. Dazu stehen 79 Kanäle mit je
1 MHz zur Verfügung. Um die Daten nun über diesen Kanal übertragen
zu können werden diese mit Hilfe der relativ einfach und damit kostengünstig
zu realisierenden GFSK auf den Träger moduliert. Um eine geringe Störanfälligkeit
zu gewährleisten wird hier außerdem ein Frequency Hopping mit
einer Hopping Rate von 1600 Hops/s über alle 79 Kanäle verwendet.
Bluetooth-Geräte sind in drei verschiedenen in Leistungsklassen
(Tabelle 2) spezifiziert.
Leistungsklasse
|
Sendeleistung
|
Reichweite
|
1
|
100 mW (20 dBm)
|
ca. 100 m
|
2
|
2.5 mW ( 4 dBm)
|
ca. 10 m
|
3
|
1 mW ( 0 dBm)
|
ca. 0,1 m
|
Tabelle 2
Baseband
Das Baseband ist verantwortlich für die Kanalkodierung
und –dekodierung und für die Bereitstellung der Zeitschlitze und Frequenzen.
Des weiteren stellt es paging und inquiry Funktionen zur Verfügung
und ist für die Synchronisation der einzelnen Bluetooth Einheiten
auf Zeit- und Frequenzbasis zuständig. Es fügt an die zu übertragenden
Daten Adressierungsinformationen sowie Link-control Felder an um Fehlererkennung
bzw. Fehlerkorrektur zu ermöglichen.
Es stehen zwei verschiedene Arten von Links zur
Verfügung:
ACL
Links: ACL Links (Asynchronous Connection Less) bestehen sofort
nach dem Aufbau einer Verbindung zwischen Master und Slave und verfügen
über einen Fehlerkontrollmechanismus. Die Kommunikation verläuft
wie in Abbildung 3a zu sehen immer abwechselnd zwischen Master und Slave.
Will man größere Datenmengen verschicken, so verwendet man mulitslot-Pakete
(Abbildung 3b), die 3 (DH3/DM3) oder 5 (DH5/DM5) Slots lang sein können
um ein möglichst gutes Verhältnis zwischen Nutzdaten und Gesamtpaketlänge
zu erhalten. Es ist nicht immer wie in Abbildung 3 zu sehen, dass sowohl
Master als auch Slave Pakete mit der gleichen Slotlänge verwenden.
Vielmehr ist es für viele Anwendungen wie z.B. beim Surfen im Internet
sinnvoll eine unsymmetrische Datenrate zwischen Up- und Download zu benutzen,
was durch Verwendung unterschiedlicher Paketlängen von Master und
Slave erreicht wird.
Abbildung 3a
|
Abbildung 3b
|
Tabelle
3 zeigt die für ACL Links zur Verfügung stehenden Datenpakete.
DMx (Data Medium) bietet im Vergleich zu DHx (Data High) eine bessere Fehlercodierung
und kann deshalb bei gleicher Gesamtlänge nur weniger Nutzdaten aufnehmen.
Paket
|
DM1
|
DM3
|
DM5
|
DH1
|
DH3
|
DH5
|
Slots
|
1
|
3
|
5
|
1
|
3
|
5
|
Max. Nutzdaten in Bytes
|
17
|
121
|
224
|
27
|
183
|
339
|
Tabelle 3
SCO
Links: SCO Links (Synchronus Connection Oriented) werden überwiegend
für die Übertragung von Audiodaten eingesetzt. Dazu werden Slots
so reserviert, dass ein kontinuierlicher Datenstrom von 64 kbit/s in beide
Richtungen garantiert ist. Im Gegensatz zu ACL Links ist es bei SCO Links
nicht sinnvoll einen Fehlerkorrekturmechanismus in Form von Wiederholen
fehlerhafter Pakete zu benutzen. Abbildung 3c zeigt einen SCO Link
bei gleichzeitiger Benutzung von ACL Links.
Abbildung 3c
LMP (Link Manager Protocol)
Das Link Manager Protokoll ist im wesentlichen für
den Verbindungsaufbau zwischen Bluetooth-Einheiten, aber auch für
Sicherheitsfunktionen wie Authentifizierung verantwortlich. Dazu kann das
Gerät zunächst z.B. aus Standby in verschiedene Zustände
gebracht werden:
Inquiry:
In diesem Zustand wird nach Geräten gesucht, die sich in Reichweite
befinden
Inquiry
Scan: Bildet das Gegenstück zu Inquiry, indem das Gerät
auf verschiedenen Frequenzen auf eine Inquiry-Nachricht wartet und diese
beantwortet.
Page:
Ein Gerät, das eine Verbindung aufbauen will befindet sich im Page-Zustand
Page
scan: Ähnlich wie bei Inquiry Inquiry scan bildet Page das
Gegenstück, indem es auf eine Page-Nachricht antwortet und so signalisiert,
das es bereit ist eine Verbindung aufzubauen.
Besteht eine Verbindung, so befindet sich das Gerät
im Connection-Zustand. In Standby ist der Funk nicht eingeschaltet
und das Gerät befindet sich in einem energiesparenden Zustand. Abbildung
3c zeigt nun die Zustandsmaschine des Link Controllers.
Abbildung 3c
HCI Layer (Host Controller Interface)
Das Host Controller Interface HCI stellt die Schnittstelle
zwischen Bluetooth-Modul (z.B. USB Adapter) und dem Host dar. Dazu ist
das Host Controller Interface in zwei Teilstücke aufgeteilt, nämlich
einerseits dem HCI-Treiber, der auf dem Host installiert ist und andererseits
der HCI-Firmware auf dem Bluetooth-Modul. Die Kommunikation zwischen den
beiden Teilen erfolgt über eine physikalische Schnittstelle (z.B.
USB).
Über HCI lassen sich nun sowohl das Bluetooth-Modul
steuern, als auch Daten übertragen. Dazu stehen drei verschiedene
Pakettypen zur Verfügung:
HCI
Events: Diese werden vom Bluetooth-Modul an den Host gesendet.
Auslösen für Events können entweder die Reaktion auf eine
Anfrage des Hosts oder ein anderes bestimmtes Ereignis sein. Bekommt ein
Bluetooth-Modul z.B. eine Verbindungsanfrage von einem anderen Grät,
so sendet es ein „Connection Request Event“ an den Host.
HCI
Commands: Mittels HCI Commands können Befehle an das Bluetooth-Modul
geschickt werden. So startet z.B. das HCI_INQUIRY command einen inquiry
Scan. Das Bluetooth-Modul antwortet seinerseits mit einem HCI_Command_Complete
bzw. mit einem HCI_Command_Status Event.
HCI
Daten Pakete: Mit diesen Paketen können ACL- und SCO-Daten
gesendet und empfangen werden.
L2CAP (logical link control and adaptation protocol)
L2CAP bietet die Dienste, die höhere Schichten
benötigen um über eine Bluetooth-Verbindung kommunizieren zu
können. Diese Dienste sind:
-
Verbindungen über ACL-Kanäle mit Hilfe von L2CAP Signalen erstellen
-
Multiplexen zwischen verschiedenen höheren Protokollen durch Vergabe
einer eigenen ID
-
Zerlegen und zusammensetzen von großen Datenpaketen um diese über
eine Bluetooth-Verbindung übertragen zu können
Alle Anwendungsprogramme sowie höhere Protokollschichten
wie RFCOMM oder BNEP die Daten über eine Bluetooth-Verbindung übertragen
wollen (asynchron) müssen L2CAP verwenden, so dass L2CAP ein sehr
wichtiger Teil der Protokollarchitektur ist.
1.2.2 Middleware Protocol Group
Das Basisband ist meist in Form eines Controllers
als Hardware realisiert und bildet zusammen mit dem Hochfrequenzteil das
Bluetoothgerät, das über das Host Controller Interface (HCI)
mit höheren Protokollschichten welche in Form von Software realisiert
sind und letztlich mit einem Anwendungsprogramm in Verbindung steht. Ziel
der mittleren Protokollschichten ist es eine Vollständige Trennung
zwischen Hardware und Anwendung zu erreichen, was letztlich eine Abstraktion
und Unabhängigkeit von der Hardware bedeutet.
Hierzu stehen die im folgenden beschriebenen Protokollschichten
zur Verfügung.
RFCOMM
RFCOMM emuliert eine serielle Schnittstelle (nach
ETSI TS 07.10) und wird für viele Profile verwendet. So kann RFCOMM
z.B. dazu verwendet werden um eine TCP/IP Verbindung über PPP aufzubauen.
Es können theoretisch gleichzeitig bis zu 30 Verbindungen aufgebaut
werden. RFCOMM setzt auf L2CAP d.h. gibt seine Daten an L2CAP weiter, wo
sie in Form des Payloads eines oder mehrerer L2CAP Paketen an das Basisband
weitergegeben werden bzw. umgekehrt erhält RFCOMM empfangene Daten
von L2CAP.
SDP (Service Discovery Protocol)
Das Service Discovery Protocol ermöglicht die
Abfrage anderer Bluetooth-Geräte bezüglich Geräteinformationen,
Diensten und Charakteristika die angeboten werden. SDP ist die Grundlage
für die meisten Anwendungsfälle und Szenarien bei denen unterschiedliche
Geräte miteinander kommunizieren.
Audio
Grundsätzlich gibt es zwei verschiedene Arten
der Datenübertragung über Bluetooth:
*
synchron
*
asynchron
Die synchrone Datenübertragung ist zur Übertragung
von Audiodaten, speziell von Sprachdaten, mit einer Datenrate von 64 kBit/s
gedacht. Um eine solche Sprachübertragung zu gewährleisten sind
relativ kleine Datenpakete bei fester Bandbreite und geringem Protokolloverhead
nötig. Um dies zu erreichen, gelangen Audiodaten im Gegensatz zu allen
anderen Daten direkt zum Baseband, ohne vorher L2CAP durchlaufen zu haben.
TCS BIN (Telephony Control – Binary)
Wie der Name schon sagt spezifiziert TCS die Signalisierung
zum Aufbau, Abbau und zur Aufrechterhaltung von Telefongesprächen
über Bluetooth. TCS orientiert sich dabei an die ITU-T Recommendation
Q.931 (ISDN Layer 3).
Telephony Control -AT Commands
Definition einer Anzahl von AT-Kommandos mit denen
ein Mobiltelefon oder ein Modem gesteuert werden kann. Die Bluetooth AT-Kommandos
orientieren sich an die ITU-T Recommendation V.250 und ETS 30 916.
BNEP (Bluetooth Network Encapsulation Protocol)
BNEP ermöglicht eine effiziente IP-basierte
Kommunikation innerhalb eines Bluetooth Pico-Netzes. Das zugehörige
PAN Profile bietet die Möglichkeit, IP Pakete zu und von Bluetooth
Teilnehmern über eine Zwischenstation weiterzuleiten. Das Forwarding
dieser Pakete erfolgt in Anlehnung an IEEE 802.1D (MAC Bridging). Um die
eingeschränkte Bandbreite besser nutzen zu können bietet BNEP
zusätzlich die Möglichkeit, bestimmte Filter zu setzen, um unnötigen
Datenverkehr auf ein Minimum zu reduzieren.
1.2.3 Application group
Die Anwendungsgruppe bietet Anwendungen, um eine
Verbindung zwischen zwei oder mehreren Bluetooth-Geräten z.B. in verschiedenen
Szenarien zu erstellen und zu verwalten. Auf der Anwendungsebene definiert
die Bluetooth-Spezifikation sogenannte Anwendungsprofile.
Hier einige Beispiele:
-
Generic Access Profile
-
Serial Port Profile
-
FAX Profile
-
Headset Profile
-
PAN Profile (PAN Personal Aera Networking)
-
LAN Access Profile
usw.
1.3 Zusammenfassung
Die nachfolgende Tabelle (Tabelle 4) soll noch einmal
zusammenfassend verdeutlichen, welche Protokolle benutzt werden und wie
sich der Protokollstack in 4 Bereiche einteilen läßt.
Protocol layer
|
Protocols in the stack
|
Bluetooth Core Protocols
|
Baseband
LPM –
Link Manager Protocol
L2CAP –
Logical Link Control and Adaption Protocol
SDP –
Service Discovery Protocol
|
Cable Replacement Protocol
|
RFCOMM (Serial Port Emulation)
BNEP – Bluetooth Network Encapsulation Protocol
|
Telephony Control Protocols
|
TCS Bin – Telephony Control Protocol – Binary
AT-commands
|
Adoped Protocols
|
PPP – Point-to-Point Protocol
UDP – User Datagram Protocol
TCP – Transport Control Protocol
IP – Internet Protocol
OBEX – Object Exchange Protocol
WAP – Wireless Application Protocol
VCARD (electronic Buisness Card Exchange
Format)
VCAL (electronic Calendaring Exchange Format)
IrMC – Ir Mobile Communications
WAE – Wireless Application Environement
|
Tabelle 4