1     Bluetooth

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
 

[prev]
Inhalt
[next]

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:
 

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



 
 
 
 

[prev]
Inhalt
[next]