Hintergrund Kapitel Abbildungen Literatur Dialog

13    Bluetooth

Einstieg Elektromagnetische Wellen im Radiofrequenzbereich bieten eine weitere Möglichkeit, ein drahtloses Netzwerk zwischen Rechner und Peripheriegeräten einzurichten, ohne dass jedoch Sichtverbindungen nötig sind. Hemmend wirken ebenfalls höhere Kosten und das nötige Batteriemanagement.
Summary Electromagnetic waves in the radio frequency range offer another possibility for establishing a wireless network among computers and their peripheral devices even without line-of-sight conditions. Costs and battery management are the limiting factors however.

13.1   Bedeutung

Bis zu acht beliebige, nicht allzu schnelle Geräte mit Bluetooth-Funktionalität ("BT") lassen sich zu einem adhoc-Funkdatennetz verbinden. Dabei sind weder Verbindungskabel noch Sichtverbindung nötig. Die einfache und preiswerte Realisierung verspricht ein großes Marktpotential beim Ersatz lokaler verkabelter oder Infrarot-Datennetze und darüber hinaus.
Der größte Vorteil des Systems, dynamische, kabellose und nicht sicht-gebundene Verbindungen, sind zugleich sein größter Nachteil: Die Möglichkeiten für Datenanzapfung und -beeinflussung auch durch Kleider oder Wände hindurch tragen nicht gerade zur Nachtruhe von Datenschützern und Sicherheitsbeauftragten bei.

13.2   Eigenschaften

Neun Beurteilungskriterien können helfen, das System in die Landschaft konkurrierender Produkte einzuordnen:

    Netz-Toplogie

Ein Master und bis zu sieben aktive Slaves (die Rollen werden pro Sitzung neu vergeben) bilden ein dynamisches "Piconetz". Zusätzlich können noch etwa 250 Teilnehmer passiv darauf warten, durch einen "Weckbefehl" aktiv zu werden. Mehrere Piconetze können zu einem übergeordneten Scatternetz zusammengeschlossen werden.

    Flexibilität

Die Vorteile von Bluetooth zeigen sich vor allem bei mobilen Geräten durch die nicht benötigte Kabelverbindung. Physikalische Hindernisse begrenzen lediglich die Reichweite, können die Verbindung aber nicht prinzipiell verhindern.

    Datenrate

1 Mbit/s Brutto-Datenrate sind ausreichend für "langsame" Peripheriegeräte und Sprache. Damit ist Bluetooth z.B. geeignet für Tastaturen, Drucker, Laptops, PDAs und Mobiltelefone.

    Skalierbarkeit, Modularität

Mehrere Einzelfunktionen können zu Funktionsmodulen, den sogenannten "Profilen" zusammengefasst werden. Dadurch, dass nicht alle Bluetooth-Geräte sämtliche Protokolle enthalten müssen, können Hardwareaufwand und vor allem Stromverbrauch für spezielle Anwendungen optimiert werden.

    Kosten

Entwicklungs- und Infrastrukturkosten müssen auf Stückzahlen umgelegt werden. Erst wenn die Herstellkosten pro Einheit plus Umlage eine bestimmte Schwelle unterschreiten (etwa 1 Dollar), ist mit einer breiten Einführung zu rechnen. Eine wesentliche Rolle spielen bei batteriebetriebenen Geräten allerdings auch die Betriebskosten: Bluetooth-Chips sind auf niedrigen Energieverbrauch optimiert.

    Reichweite

Es sind zwei Geräteklassen spezifiziert: 0 dBm-Module ("Pico-Bluetooth") haben eine Mindestreichweite von 10 m, beim Einsatz von 20 dBm-Modulen ("Mega-Bluetooth") sind Abstände bis zu 100 m spezifiziert. In der Praxis werden jedoch bedeutend größere Reichweiten erreicht.

    Konnektivität

Bei kabellosen Anwendungen entfällt die Notwendigkeit einer Steckerkompatibilität. Für sinnvolle Anwendungen ist es jedoch notwendig (und per Spezifikation gefordert), dass alle Geräte, die die Spezifikation erfüllen, auch miteinander kommunizieren können. Dies wird dadurch sichergestellt, dass alle Bluetooth-fähigen Geräte an einer definierten "Testsuite" einen Zulassungstest bestehen müssen, der von einer neutralen Stelle überwacht wird.

    Sicherheit

Jede Bluetooth-Einheit erhält bereits bei der Herstellung eine weltweit eindeutige 48 bit - Geräteadresse zur Identifikation. Diese kann dazu verwendet werden, um z.B. zu protokollieren, welche Geräte wann in einem Piconetz aktiv waren.
Das verwendete Frequenzsprungverfahren erschwert es Geräten, die nicht am Piconetz angemeldet sind, dessen Datenverkehr zu belauschen. Schlüsselverwaltung und verwendbare Verschlüsselungsverfahren entsprechen dem Stand der Technik.

    Energieverbrauch

Bei Verwendung handelsüblicher NiCd-Zellen ergeben sich folgende Betriebszeiten (nur für die Bluetooth-Chips, ohne Berücksichtigung der übrigen Gerätefunktionen:
  • 3 Monate im Standby-Betrieb
  • 75 Stunden bei Sprachübertragung
  • 120 Stunden bei Datenübertragung

13.3   Übersicht

13.3.1 Prinzip

Zum Einstieg führt Tab. 13-1 einige wichtige Begriffe und kurze Erläuterungen dazu auf.
Bluetooth ist ein universeller Standard für drahtlose Kommunikation über Funkverbindungen. Es dient als Ersatz für Kabelverbindungen zwischen ortsfesten und/oder tragbaren Geräten. Seine Hauptmerkmale sind Robustheit, Einfachheit, niedriger Energiebedarf und niedrige Kosten. Beschränkungen gibt es bei der Reichweite mit maximal 100 m und bei der Datenrate, die eine maximale Übertragung von ca. 760 kbit/s erlaubt. Mehrere Bluetooth-Teilnehmer im selben Wirkungsbereich können virtuelle adhoc-Netzwerke bilden, die sich selbst konfigurieren.
Bluetooth verwendet das lizenzfreie ISM-Band (Industry, Science, Medicine) bei 2.4 GHz. Ein Frequenzsprung-Transceiver (Sender/Empfänger) wird eingesetzt, um Störungsbeeinflussung und Fading zu reduzieren. Eine binäre FM-Modulation soll den Transceiver einfach halten. Der Übertragungskanal hat eine (Brutto-)Symbolrate von 1 Ms/s und ist in Zeitschlitze von 625 µs unterteilt. Damit wechselt die Trägerfrequenz 1600 mal pro Sekunde. Um Full-Duplex-Betrieb zu ermöglichen, wird die Übertragungsrichtung abgewechselt (TDD: Time Division Duplex). Die Information wird in Paketen übertragen. Jedes Paket benutzt eine unterschiedliche Sprungfrequenz ("Hop Frequency"). Normalerweise belegt ein Paket einen Zeitschlitz, kann aber bei Bedarf auch auf 3 oder 5 aufeinanderfolgende Zeitschlitze verteilt werden.

13.3.2 Netzaufbau

Kommen potentielle Netzwerkteilnehmer in den gegenseitigen Funktionsbereich, werden sie automatisch identifiziert und in die Struktur eingebunden.
Bluetooth unterstützt 1:1-Verbindungen (Point-to-point) und 1:n-Verbindungen (Point-to-multipoint). Diese beiden Fälle werden begrifflich nicht unterschieden und bilden ein "Piconetz" aus einem "Master" und einem oder mehreren "Slaves" (Abb. 13-2). In einem Piconetz kann es bis zu sieben aktive Slaves (adressierbar über eine 3 bit-Adresse AM_ADDR) geben und viele weitere in einem sogenannten Park-Zustand (adressierbar über eine 8 bit-Adresse PM_ADDR) . Diese können nicht aktiv an der Datenübertragung teilnehmen, bleiben aber synchronisiert und werden wie die aktiven vom Master verwaltet.
Mehrere Piconetze können mit überlappenden Wirkungsbereichen existieren, ohne sich wesentlich zu stören. Sie benutzen nämlich normalerweise verschiedene Sprungfrequenzfolgen und verschiedene Channel Access Codes. Zwischen Piconetzen kann Datenaustausch stattfinden, wenn ein Gerät des einen Piconetzes (Master oder Slave) gleichzeitig (d.h. im Zeitmultiplex) Slave in einem oder mehreren weiteren Piconetzen ist. So verbundene Piconetze bilden ein Scatternetz.

13.3.3 Protokoll

Das Bluetooth-Protokoll benutzt eine Kombination aus Kanal- und Paketvermittlung. Zeitschlitze können für synchrone Pakete reserviert werden. Bluetooth kann folgende Kanäle unterstützen:
  • Asynchroner Datenkanal (ACL)
  • Bis zu drei gleichzeitige synchrone Sprachkanäle (SCO)
  • Asynchroner Daten- und synchroner Sprachkanal gleichzeitig
Jeder Sprachkanal bietet 64 kb/s in beide Richtungen. Ein Asynchronkanal kann asymmetrisch mit 721 kb/s + 57.6 kb/s oder symmetrisch mit 2* 432.6 kb/s betrieben werden. Um Echtzeitübertragung zu gewährleisten, erhalten Sprachkanäle höhere Priorität bei der Belegung von Zeitschlitzen.
Eine Bluetooth-Einheit besteht aus drei Funktionsblöcken:
  • Funkeinheit
  • Verbindungsüberwachung (Link Controller)
  • Verbindungsverwaltung (Link Manager)
Zur Steuerung der Bluetooth-Einheit enthält der Host-Rechner weitere Software-Protokolle.

13.4   Schichtenmodell

Auch bei Bluetooth lassen sich die diversen Aktivitäten in Schichten einteilen, die jeweils ein oder mehrere Protokolle enthalten. Abb. 13-3 zeigt einen ersten Überblick, eine erweiterte Darstellung folgt im Abschnitt 13.10: HCI. Dünne Linien stellen direkte Datenverbindungen (Hardware oder Software) innerhalb eines Kommunikationspartners dar, breite Pfeile zeigen logische (d.h. physikalisch nicht existierende) Verbindungen zwischen gleichen Protokollen mehrerer Geräte. Dargestellt ist jedoch nur ein Gerät als eine Seite der Verbindung. Die Gegenstationen sind prinzipiell gleich aufgebaut. Alle Geräte haben Sende- und Empfangsfunktionen.
In der Bitübertragungsschicht (auch Basisband-Protokoll genannt) als unterster Schicht wird von RF ("Radio Frequency"; "Bluetooth-Radio") die Funktionalität zur Bedienung des Piconetzes bereitgestellt.
Der Link Controller (LC) verwaltet die ACL- und SCO-Kanäle, die teilweise von ihm selbst und teilweise von der nächsthöheren Schicht eingerichtet werden.
Darauf aufgesetzt wird das "Link Manager Protokoll" (LMP, LM). Seine Hauptaufgaben sind die Bestimmung der Basisband-Paketlängen, der Betriebsarten (Connection, Hold, Sniff, Park) und die Gewährleistung der Datensicherheit durch Verschlüsselung der Daten zwischen vorher gegenseitig authentifizierten Geräten. LMP hat keine Verbindung zu Protokollen höherer Schichten.
Das "Logical Link Control and Adaptation Protokoll" (L2CAP) stellt die Verbindung her zur Anwendungsschicht. Durch Multiplexen ermöglicht es mehreren Anwendungen die quasi-gleichzeitige Benutzung der Verbindungen. Anwendungsprotokolle können größere Datenblöcke "am Stück" übertragen, die von L2CAP zum Senden segmentiert und beim Empfang wieder zusammengesetzt werden. L2CAP benutzt die gleiche Schicht wie LMP und steuert beispielsweise auch den Aufbau von Verbindungen zwischen Endpunkten.
In den meisten Fällen ist die Bluetooth-Einheit vom Host-Rechner abgesetzt. Dabei kann sie in Form einer PC-Karte im selben Gehäuse oder als eigenständiges Gerät in einem externen Gehäuse untergebracht sein. In allen diesen Fällen ist eine zusätzliche Transportschicht zwischen L2CAP und LC erforderlich, die als "Host Controller Interface" (HCI) bezeichnet wird und in vier verschiedenen Ausführungen definiert ist:
  • PC-Card wird benutzt, wenn die Bluetooth-Einheit im Host-Gehäuse auf einer PC-Karte untergebracht ist und den internen Bus benutzt.

  • USB benutzt einen externen kabelgeführten Bus zwischen Host-Rechner und abgesetztem Bluetooth-Gerät.

  • RS232 und UART werden verwendet, wenn Host-Rechner und Bluetooth-Gerät über serielle Standard-Verbindungen verbunden sind.

In der Anwenderschicht sind vier Protokolle exemplarisch dargestellt:
  • Auf AUDIO und TCS ("Telephony Control Protocol") wird nicht weiter eingegangen.

  • RFCOMM ("Cable Replacement Protocol") stellt den höheren Schichten, die eigentlich eine RS232-Verbindung benötigen, eine entsprechende Emulation zur Verfügung.

  • Das "Service Discovery Protocol" (SDP) bildet die Basis für die Usage Modelle. Mit SDP können Eigenschaften der Geräte sowie Typen und Charakteristika vorhandener Dienste ("Services") ausgetauscht werden. Mit diesen Informationen können dann die Verbindungen passend eingerichtet werden.

    Verbindungsaufbau

Der Link Controller baut zunächst mit den Prozeduren "Inquiry" und "Paging" die Verbindungen der untersten Schicht auf und stellt damit einen ACL-Kanal von LC zu LC zur Verfügung.
Dieser ACL-Kanal kann vom Link Manager zum Aufbau und zur Verwaltung von SCO-Verbindungen benutzt werden.
L2CAP verwendet ein System von "Endpunkten", durch das mehrere logische Verbindungen zwischen zwei Geräten ermöglicht werden. Zusätzlich zu einem über ACL bereits vorhandenen "Signalling Channel" und einem "Connectionless Channel" (beide benutzen fest vorgegebene Endpunkt-Nummern) kann L2CAP durch entsprechende Signalling Kommandos bei Bedarf verbindungsorientierte Kanäle zwischen weiteren Endpunkten einrichten.

13.5   Physikalischer Kanal

Bluetooth benutzt das weltweit verfügbare, lizenzfreie 2.4 GHz ISM- Band. In den meisten Ländern bietet der Frequenzbereich von 2400 bis 2483.5 MHz Platz für 79 Kanäle in Abständen von 1.0 MHz, die von 0 bis 78 durchnummeriert sind:

k=0 2402 MHz
k=1 2403 MHz
...
k=78 2480 MHz

(In Frankreich stehen derzeit nur 23 Kanäle zur Verfügung. Da eine Harmonisierung beabsichtigt ist, wird auf diesen Sonderfall nicht weiter eingegangen.)
Ein Piconetz besteht aus einem Master und bis zu sieben aktiven Slaves. Da alle Bluetooth Stationen ("Transceiver") gleichartig funktionieren, kann die Master-Rolle innerhalb eines Piconetzes bei Bedarf auch an eine andere Station übergeben werden. Mehrere Piconetze mit überlappendem physikalischen Wirkungsbereich bilden ein Scatternetz. Ein Slave kann zu mehreren Piconetzen gehören, der Master eines Piconetzes kann Slave in einem anderen sein. Die Piconetze eines Scatternetzes sind nicht synchronisiert.
Der Piconetz-Kanal ist unterteilt in Zeitschlitze ("Slots") der Länge 625 µs (Abb. 13-4). Diese werden vom Master von 0 bis 227-1 durchnummeriert (Zeitschlitztakt). Nach ca. 23.5 h läuft der Zähler über und beginnt wieder bei 0. Für jeden Zeitschlitz wird eine Trägerfrequenz nach einem festgelegten Verfahren bestimmt. Sie wird aus dem Vorrat der 79 Frequenzkanäle entnommen und hängt von der Adresse des Masters und dem Zählerstand des Zeitschlitztakts ab. Alle aktiven Slaves erfahren bei der Einrichtung der Verbindung die Master-Adresse und synchronisieren sich auf den Zeitschlitztakt des Masters. Damit haben sie alle Informationen, um die gleiche Sequenz von Trägerfrequenzen zu erzeugen. Die Kanal-Nummern aufeinanderfolgender Trägerfrequenzen bilden eine Pseudozufallsfolge. In einem Segment von 79 Zeitschlitzen wird jeder Frequenzkanal einmal benutzt, im nächsten Segment jedoch in anderer Reihenfolge.
(Für Inquiry und Paging (Abschnitt 13.7: Link Control) wird eine vereinfachte Sprungfrequenzauswahl mit wesentlich geringerer Periodenlänge verwendet.)
Die Informationsübertragung zwischen Master und Slaves erfolgt durch Datenpakete. Ein Paket kann 1, 3 oder 5 Zeitschlitze belegen. Jedes Paket in Master-Slave-Richtung beginnt in einem Zeitschlitz mit gerader Nummer, jedes Slave-Master-Paket in einem Zeitschlitz mit ungerader Nummer. Die Pakete wechseln sich in der Richtung ab. Die Daten werden mit einem Bit-Takt von 1.0 Mb/s übertragen. Ein Paket der Länge 1 kann bis zu 366 bit lang sein. Die restliche Zeit wird zum Umschalten der Trägerfrequenz benötigt. Bei der Übertragung längerer Pakete (Länge 3 oder 5) wird die Trägerfrequenz "eingefroren", bis das Paket übertragen ist. Danach wird die ursprüngliche Träger-Sequenz fortgesetzt, wobei die ausgeblendeten Träger verlorengehen. Da die Umschaltzeit in diesem Fall nur einmal pro Paket benötigt wird, können längere Pakete überproportional mehr Daten enthalten.
Zur Codierung der Daten wird Frequenzmodulation benutzt, wobei logisch 1 durch eine Erhöhung, logisch 0 durch eine Erniedrigung der nominalen Trägerfrequenz realisiert wird.
Abb. 13-4 zeigt die Aufteilung des physikalischen Kanals in Zeitschlitze von je 625 µs. Zur Verdeutlichung sind geradzahlige Zeitschlitze weiß, ungeradzahlige grau hinterlegt. Die Zeit-Duplex-Struktur ist so ausgelegt, dass Master und Slave normalerweise abwechselnd in aufeinanderfolgenden Zeitschlitzen je ein Paket senden können, wobei der Master seine Sendung immer in geradzahligen startet.
Die Gegenseite kann die Länge des Pakets (1, 3 oder 5) aus dem Anfang des Paketinhalts entnehmen und wartet entsprechend lange mit ihren Reaktionen.
Ausnahme: ID-Pakete (Abschnitt 13.6: Physikalische Verbindung) belegen nur einen halben Zeitschlitz und werden hauptsächlich bei der Paging-Prozedur eingesetzt. Der Master kann damit in einem Zeitschlitz einen Slave mit bekannter Adresse mit zwei verschiedenen Sprungfrequenzen auffordern, (wieder) aktiv zu werden. Außerdem enthält die Abbildung Beispiele für Paging und Nutzdatenverkehr. In der oberen Hälfte ist exemplarisch eine Paging-Prozedur für zwei Slaves dargestellt. Master und Slave sind jeweils durch eine horizontale Linie symbolisiert. Sendeaktivitäten werden angezeigt durch Rechtecke oberhalb dieser Linien, Empfangsaktivitäten unterhalb.
Im Paging-Betrieb versucht der Master im Zeitschlitz 0 mit zwei Sprungfrequenzen einen Slave anzusprechen, dessen Adresse ihm aus einem vorausgegangenen Inquiry bekannt ist. Er verwendet dazu ID-Pakete. Der Slave hat eine konstante Sprungfrequenz eingestellt. Stimmt sie zufällig mit der des Masters überein, kann er dessen Paging-Anfrage 625 µs später im Zeitschlitz 1 beantworten, und zwar ebenfalls durch ein ID-Paket. Die Antwort-Sprungfrequenzen sind den Kommando-Sprungfrequenzen nach einer bestimmten Regel zugeordnet. Der Master erwartet also in der ersten Hälfte von Zeitschlitz 1 eine Antwort auf der Sprungfrequenz, die der Sprungfrequenz der ersten Hälfte von Zeitschlitz 0 entspricht, in der zweiten Hälfte entsprechend der zweiten Kommando-Sprungfrequenz.
Anschließend erwartet der Slave ein FHS-Paket in Zeitschlitz 2. Er beantwortet dieses wieder mit einem ID-Paket. Danach synchronisiert er sich auf die "Nutz"-Sprungfrequenzfolge des Masters; der Datenaustausch kann beginnen Die Prozedur ist insgesamt zweimal, also für zwei Slaves dargestellt.
Im "Connection"-Betrieb sind beide Slaves auf die Sprungfrequenzfolge des Masters synchronisiert. Sie gehen in geradzahligen Zeitschlitzen auf Empfang und analysieren das empfangene Paket. Nur der angesprochene Slave darf im nächsten Zeitschlitz antworten. Belegt ein Master-Paket z.B. drei Zeitschlitze, blendet sich der nicht angesprochene Slave entsprechend länger aus.
Durch Rückmeldung der Empfangsfeldstärke kann die Sendeleistung optimiert und somit weitere Energie eingespart werden.

13.6   Physikalische Verbindung

Es gibt zwei Typen von Verbindungen zwischen Master und Slave:
SCO ("Synchronous Connection-Oriented") ist eine Punkt-zu-Punkt-Verbindung zwischen Master und einem Slave. Sie benutzt Zeitschlitze in regelmäßigen reservierten Abständen. Anfangsnummer und Abstand werden bei Einrichtung der Verbindung vereinbart (s. Abschnitt 13.8: Link Manager). Es handelt sich um eine symmetrische Verbindung, d.h. für beide Richtungen steht die gleiche Übertragungsrate zur Verfügung. Typische Anwendungsfälle sind zeitkritische Vorgänge wie Sprache.
Ein Master kann bis zu drei SCO Verbindungen zu einem oder mehreren Slaves bereitstellen. Ein Slave kann drei SCO-Verbindungen von einem Master bedienen, aber nur zwei, wenn die Verbindungen mit verschiedenen Mastern (in verschiedenen Piconetzen) bestehen. SCO Pakete werden grundsätzlich nicht wiederholt.
Bei SCO belegt jedes Paket genau einen Zeitschlitz.
Hat der Slave ein Paket erhalten, kann er im unmittelbar folgenden Zeitschlitz antworten.
ACL ("Asynchronous Connection-Less") ist eine Busverbindung ("Point-to-Multipoint") zwischen Master und allen aktiven Slaves, mögliche SCO-Slaves eingeschlossen. Der Master benutzt für seine Nachrichten Zeitschlitze, die noch nicht für SCO belegt sind. Im ersten Zeitschlitz ist die Adresse eines Slave und die Paketlänge enthalten. Der angesprochene Slave empfängt die Nachricht in 1, 3 oder 5 Zeitschlitzen und kann unmittelbar darauf antworten. Alle anderen Slaves entnehmen der Nachricht nur die Paketlänge und wissen damit, wieviele Zeitschlitze sie ignorieren müssen.
Da jeder Slave nur eine Ansprechadresse hat, kann es auch nur eine ACL Verbindung zwischen Master und Slave geben. Die meisten Anwendungsfälle benutzen ein Verfahren mit Wiederholung falsch empfangener Pakete, um die Übertragungssicherheit zu erhöhen.
ACL Pakete mit Adresse 0 sind Broadcast-Pakete und werden von allen Slaves empfangen.

13.6.1 Pakete

Es gibt 15 verschiedene Pakettypen (Übersicht in Tab. 13-5). Man kann sie nach mehreren Kriterien einteilen.
Nach der Art der Information

Steuerung (Control) 5 Typen ID, NULL, POLL, FHS, DM1
Daten (Data) 8 Typen DM1, DH1, DM3, DH3, DM5, DH5,AUX1, DV
Sprache (Voice) 4 Typen DV, HV1, HV2, HV3

Bei dieser Einteilung nehmen DM1 und DV Sonderstellungen ein:
  • DM1 kann Daten übertragen oder steuernd bei beiden Verbindungstypen eingreifen.

  • DV enthält eine Kombination von Sprache und Daten.

Nach benutztem Verbindungstyp:

SCO 4 Typen HV1, HV2, HV3, DV
ACL 6 Typen DH1, DM3, DH3, DM5, DH5, AUX1
SCO/ACL 5 Typen ID, NULL, POLL, FHS, DM1

    ID Paket

Es wird hauptsächlich für Inquiry und Paging benutzt. Es besteht aus dem Device Access Code (DAC) oder dem Inquiry Access Code (IAC) und ist genau 68 bit lang. Es hat weder Header noch Payload.

    NULL Paket

Es besteht aus dem vollen Access Code und einem Header und hat damit eine Länge von genau 126 bit. Es wird zur Bestätigung eines empfangenen Pakets und zur Datenflusssteuerung benutzt. Ein empfangenes NULL wird nicht bestätigt.

    POLL Paket

Es ist aufgebaut wie NULL und somit ebenfalls 126 bit lang. Es wird normalerweise vom Master verwendet und muss vom Empfänger beantwortet werden.

    FHS Paket (Frequency Hop Synchronisation)

Eine Nutzinformation von 144 bit und ein 16 bit Datensicherungscode werden durch eine weitere Fehlersicherung auf 240 bit übertragene Daten aufgebläht. Das Paket belegt einen Zeitschlitz. Es enthält die Adresse des sendenden Masters und den Stand seines Zeitschlitzzählers. Es kann vor Aufbau des Piconetzes gesendet werden und enthält dann die Slave-Adresse 0. Bei Verwendung zum Wechseln des Masters enthält es eine aktuelle Slave-Adresse.

    HVx Pakete (High-Quality Voice)

Die drei Pakettypen HV1, HV2 und HV3 werden hauptsächlich zur Übertragung von Sprache verwendet. Sie enthalten alle genau 240 bit Nutzinformation. HV1 verwendet den besten Fehlersicherungsmechanismus und kann deshalb nur 10 Byte Nutzinformation enthalten. HV2 ist etwas schwächer gesichert und überträgt 20 Byte pro Paket und Zeitschlitz. HV3 enthält bei einer Übertragungskapazität von 30 Byte keine Fehlersicherung. HVx Pakete benutzen einen SCO Kanal und werden nie wiederholt. Auch enthalten sie weder Payload Header noch eine CRC Sicherung.

    DMx Pakete (Data Medium rate)

Die drei Pakettypen DM1, DM3 und DM5 werden zur Übertragung von Daten auf dem ACL-Kanal benutzt. DM1 kann alternativ auch Steuerinformation auf ACL oder SCO übertragen.
Sie belegen 1, 3 oder 5 aufeinanderfolgende Zeitschlitze. Innerhalb eines Pakets wird die Trägerfrequenz nicht umgeschaltet. Die unterdrückten Frequenzen werden nicht nachgeholt, sondern fallen aus. Die Payload besteht aus 18 Byte (bzw. 123, 226) einschließlich Payload Header und zuzüglich 2 Byte CRC. Die ganze Payload erhält dann noch eine Fehlersicherung, indem zu je 10 bit weitere 5 Sicherungsbits erzeugt werden. Meldet der Empfänger Übertragungsfehler, wird das Paket wiederholt.

    DHx Pakete (Data High rate)

Die drei Pakettypen DH1, DH3 und DH5 sind den DMx-Typen sehr ähnlich. Der Hauptunterschied besteht in der fehlenden Fehlersicherung. Dadurch ergibt sich eine höhere mögliche Payload von 28 (185, 341) Byte. Wiederholt wird ein Paket nur bei falschem CRC. DH1 ist auf ACL-Kanäle beschränkt und kann keine Steuerinformation enthalten.

    DV Paket

Dieses Paket belegt einen Zeitschlitz und enthält eine Kombination von Sprache und Daten. Der Sprachteil mit 80 bit ist nicht fehlergesichert. Der Datenteil enthält maximal 10 Byte Information, davon 1 Byte Header und 2 Byte CRC. Pro 10 bit Nutzinformation werden 5 bit Fehlersicherung angefügt. Wegen des Sprachteils wird der SCO-Kanal benutzt. Ist nach einem erkannten Fehler eine Wiederholung des Datenteils nötig, wird der Sprachteil trotzdem mit neuer Information gefüllt.

    AUX1 Paket

Bei diesem Paket fällt gegenüber DH1 auch noch die CRC-Sicherung weg. Man erhält damit maximal 30 Byte pro Paket. Eine Fehlererkennung ist dadurch nicht mehr möglich und deswegen auch keine Paketwiederholung.
Tab. 13-5 und Tab. 13-6 zeigen die verfügbaren Pakettypen und ihre Struktur.
  • Durch "Code" werden die Typen eindeutig unterschieden. Es stellt den Inhalt des Feldes PACKET HEADER_TYPE dar.

  • "Typ" wird in Beschreibungen als Abkürzung verwendet,

  • "Bezeichnung" deutet die Verwendung an.

  • "Schlitze" gibt an, wieviele Zeitschlitze der entsprechende Pakettyp belegt.

  • Die letzten drei Spalten enthalten den prinzipiellen Aufbau aus Feldern. Wiederkehrende Feldtypen sind mit Symbolen gekennzeichnet und in Tab. 13-6 genauer aufgeschlüsselt:

    • ACCESS CODE besteht aus PREAMBLE P (4 bit), SYNC WORD SY (64 bit) und TRAILER T (4 bit) (Nur bei ID entfällt der Trailer).

    • PACKET HEADER besteht aus AM_ADDR, TYPE, FLOW, ARQN, SEQN, HEC und FEC

  • PAYLOAD ist bei allen Typen unterschiedlich aufgebaut und kann folgende Anteile enthalten:

    • C Steuerinformation

    • D Daten

    • V Sprache

    • H Payload Header

    • CRC Cyclic Redundancy Check

    • FEC Forward Error Correction

13.7   Link Control

13.7.1 Betriebszustände

Abb. 13-7 zeigt in einer vereinfachten Darstellung die Hauptzustände der Link Control Schicht. Dieser Teil des Zustandsdiagramms ist allen Bluetooth-Geräten gemeinsam. Daneben gibt es noch einige Zwischenzustände, die davon abhängen, welche Rolle das Gerät übernimmt: Initiator oder Beantworter, Master oder Slave.
Im folgenden werden die wichtigsten Zustände kurz beschrieben, daran anschließend folgen Anmelde- (Inquiry) und Verbindungsprozedur (Paging) (Abb. 13-8).

STANDBY Ein stromsparender Grundzustand, der nach dem Einschalten, aber auch im Betrieb bei längerer Inaktivität eingenommen wird. Mögliche Folgezustände sind INQUIRY, INQUIRY SCAN, PAGE oder PAGE SCAN.
INQUIRY Ein Gerät (meist, aber nicht zwangsläufig der spätere Master) geht auf die Suche nach weiteren Bluetooth-Geräten in seinem Bereich. Dazu sendet er Anfragen aus und sammelt Antworten ein
INQUIRY SCAN Ein Gerät (meist ein späterer Slave) ist bereit, auf Anfragen zu antworten.
INQUIRY RESPONSE Zwischenzustand eines antwortenden Geräts. Wird benötigt, um mögliche Konflikte bei gleichzeitigen Antworten aufzulösen.
PAGE Ein Gerät macht sich zum Master, indem es verbindungsbereite Geräte gezielt mit einer Page message anspricht, die dadurch zu Slaves werden. Im Zustand PAGE wartet der Master auf Antwort (Page response).
PAGE SCAN Ein Slave kann die Verbindungsanfrage (Page message) annehmen und mit Page Response beantworten. Anschließend geht er in den Zustand SLAVE RESPONSE.
MASTER RESPONSE Der Master hat Page Response erhalten und mit Master Response bestätigt. Er wartet auf Slave Response und geht nach Erhalt in den Zustand CONNECTION.
SLAVE RESPONSE Der Slave wartet auf die Bestätigung des Masters durch Master Response. Er antwortet darauf mit Slave Response und geht anschließend in den Zustand CONNECTION.
CONNECTION Existiert in jedem Slave einmal, im Master n-mal (für n Slaves). Beide Verbindungspartner benutzen zum Datenaustausch den Channel Access Code und den Takt des Masters. Die Folgen der Sprungfrequenzen für Senden und Empfangen sind verschieden, aber synchronisiert, d.h. jeder Partner kann vorhersehen, auf welcher Trägerfrequenz das nächste Paket zu erwarten ist. Der Master startet Sendepakete in geradzahligen Zeitschlitzen, die Slaves starten in ungeradzahligen. Unmittelbar nach Aufbau der Verbindung sendet der Master ein POLL-Paket. Zur Bestätigung des Verbindungsaufbaus und der Synchronisation erhält er ein beliebiges Paket zurück. Danach tauschen die Link Manager der beteiligten Partner weitere Steuerinformationen aus, bevor die Übertragung der eigentlichen Nutzinformation beginnen kann. CONNECTION hat vier Unterbetriebsarten: ACTIVE, SNIFF, HOLD, PARK.
ACTIVE MODE Das Gerät nimmt aktiv am Datenverkehr teil. Der Master verwaltet Meldungen an die verschiedenen Slaves und ihre Antworten. Auch Slaves, für die keine Informationen vorliegen, müssen von Zeit zu Zeit angesprochen werden, um die Synchronisation aufrechtzuerhalten.
SNIFF MODE Dies ist ein Zustand reduzierter Aktivität. Der Slave geht nicht mehr in allen, sondern nur noch in vorher vereinbarten Zeitscheiben auf Empfangsbereitschaft für ACL-Pakete. Empfängt er dabei ein Paket, bleibt er solange empfangsbereit für weitere Pakete, bis diese eine gewisse Zeit lang ausbleiben. SCO-Pakete sind nicht betroffen, sondern können immer empfangen werden.
HOLD MODE Um Kanalkapazität für andere Aktivitäten (z.B. Paging, Inquiry oder Datenaustausch mit anderen Piconetzen) frei zu bekommen, kann der Master einzelne Slaves für einen vereinbarten Zeitraum in den HOLD MODE versetzen. Der Slave behält seine AM_ADDR und synchronisiert sich nach Ablauf der vereinbarten Zeit selbständig auf. SCO-Pakete sind nicht betroffen.
PARK MODE Dieser Zustand dient zwei Zwecken. Zum einen kann ein Slave damit Strom sparen, wenn er längere Zeit keine Verbindung benötigt. Zum anderen muss der Master Slaves in PARK MODE bringen, wenn er mehr als sieben Geräte in einem Piconetz verwalten will. Geht ein Slave in den PARK MODE, gibt er seine 3 bit AM_ADDR auf und erhält stattdessen zwei 8 bit Adressen zugeteilt:
  • PM_ADDR (Parked member), mit der der Master das Verlassen des PARK MODE veranlassen kann

  • AR_ADDR (Access Request), mit der sich der Slave zurückmelden kann.

Ein "geparkter" Slave wacht von Zeit zu Zeit auf, um sich zu synchronisieren und auf Broadcast-Meldungen zu hören. Zur Aufrechterhaltung der Verbindung zu geparkten Slaves verwendet der Master einen "Beacon Channel", auf den hier nicht weiter eingegangen wird.
Scatternetz: Ein Gerät, das nur eine ACL-Verbindung im ersten Piconetz benutzt, geht zweckmäßigerweise in den HOLD- oder PARK-Mode, um genügend Zeit zu gewinnen für Datenaustausch in einem zweiten Piconetz. Auch der SNIFF-Mode lässt sich dafür ausnutzen, wenn auch schon etwas zeitkritischer.
Gerade noch realisierbar ist ein Scatternetz für den Fall, dass in einem beteiligten Piconetz eine SCO-Verbindung besteht. Die Pakete müssen hier vom Typ HV3 sein, und zwischen den Paketen stehen dann gerade zwei Zeitscheiben für das zweite Piconetz zur Verfügung.

13.7.2 Inquiry Prozedur

Im Bluetooth-System ist eine Inquiry-Prozedur definiert für Fälle, bei denen die Quelle die Geräteadresse des Ziels nicht kennt. Sie kann zur Abfrage dienen, welche anderen Bluetooth-Geräte erreichbar sind (Abb. 13-8).
Im Zustand INQUIRY sammelt das abfragende Gerät die Bluetooth-Geräteadressen und Takte aller Einheiten, die auf die Anfrage antworten. Es kann dann bei Bedarf eine Paging-Prozedur anschließen.
Die Inquiry-Anfrage als Rundruf enthält keinerlei Information über die Quelle. Sie kann jedoch die Klasse der gesuchten Geräte einschränken. Bei allgemeiner Suche wird der "General inquiry access code" (GIAC), bei eingeschränkter Suche ein "Dedicated inquiry access code" (DIAC) verwendet.
Ein Gerät, das nach anderen Geräten suchen möchte, geht in den Zustand INQUIRY und sendet wiederholt ID-Pakete als INQUIRY-Anfragen ("Inquiry messages") auf wechselnden Sprungfrequenzen. Bluetooth-Geräte, die sich als Verbindungspartner anbieten, gehen von Zeit zu Zeit in den Zustand INQUIRY SCAN und warten auf einer festen Sprungfrequenz auf ankommende Anfragen. Haben sie eine erkannt, antworten sie mit einem FHS-Paket als "Inquiry response".
Das suchende Gerät gibt sich nicht mit einer Antwort zufrieden, sondern sucht nach weiteren Partnern, insgesamt etwa 10 s lang. Diese Zeit genügt, um in störungsarmer Umgebung alle Partner zu sammeln, in gestörter Umgebung sollte sie entsprechend verlängert werden. Die Inquiry-Prozedur wird etwa einmal pro Minute wiederholt, allerdings in unregelmäßigen Abständen, um eine "Anti-Synchronisation" zu vermeiden.

13.7.3 Paging Prozedur

Auch nach einer Inquiry Prozedur existiert noch kein Piconetz. Die unverbundenen Geräte sind nach wie vor unabhängig und gleichberechtigt. Erst wenn ein Gerät die Initiative ergreift und durch eine Paging Prozedur eine erste Verbindung zu einem weiteren Gerät aufbaut, wird es dadurch zum Master des neu gegründeten Piconetzes. Der Verbindungsaufbau zu weiteren Slaves wird ebenfalls vom Master gesteuert.
Zum Einleiten der Paging Prozedur geht der Master in den Zustand PAGE. Er sendet laufend ID Pakete ("Page messages") und spricht damit die einzelnen Slaves über ihre Geräteadressen an. Da zu diesem Zeitpunkt weder Takt noch Sprungfrequenzfolge synchronisiert sind, sendet der Master auf ständig wechselnden Frequenzen, während die Slaves auf jeweils einer konstanten Frequenz empfangsbereit sind. Die Slaves gehen von Zeit zu Zeit in den Zustand PAGE SCAN und warten auf Paging-Anfragen. Erkennen sie eine solche Anfrage, senden sie eine Antwort ("Page response") auf einer Sendefrequenz, die definiert von der Empfangsfrequenz abhängt.
Für den Master können etliche Versuche nötig sein, bevor er eine Antwort erhält. Dann jedoch geht er in den Zustand MASTER RESPONSE und sendet ein FHS-Paket als "Master response". Durch die Antwort des Slaves ("Slave response") wird der eigentliche Verbindungsvorgang eingeleitet, bei dem wichtige Informationen zum Aufbau der Verbindung ausgetauscht werden: Gemeinsamer Channel Access Code, gemeinsame Sprungfrequenzfolge und Synchronisation der Takte.

13.8   Link Manager

Bei Bluetooth setzen auf der physikalischen Schicht zwei höhere Protokolle auf, die nebeneinander existieren und verschiedene Aufgaben haben: Link Manager und Logical Link Control (L2CAP) (s. Abschnitt 13.9: L2CAP).
Das Link Manager Protokoll (LMP) kümmert sich mehr um die interne Verwaltung des Piconetzes und seiner Verbindungen.
Bei abgesetzten Bluetooth-Einheiten ist es im Gerät selbst angesiedelt und hat keine Verbindung zu Anwendungsprotokollen. Zum Informationsaustausch mit Link Managern anderer Teilnehmer benutzt der Link Manager LM-PDUs ("Protocol Data Units"), die als DM1- oder DV-Pakete und damit immer in einem Zeitschlitz übertragen werden. Da Link Manager auf dem fehlergesicherten LC-Protokoll aufsetzt, verwendet es selbst keine weiteren Sicherungsmaßnahmen: Der Empfang von LM-PDUs wird nicht bestätigt. Der angesprochene Partner kann zwar Antwort-PDUs senden, jedoch nicht notwendigerweise im unmittelbar folgenden Zeitschlitz.
Durch den Inhalt des Payload-Headers L_CH=11 (s. Tab. 13-6) lassen sich LM-PDUs von den übrigen Datenpaketen unterscheiden, die von L2CAP mit L_CH=01 und L_CH=10 übertragen werden. LM-PDU Pakete haben höhere Priorität als L2CAP und haben folgenden prinzipiellen Aufbau:

Payload Header L_CH 2 bit 11 LM-Kennung
FLOW 1 bit 0 Flusskontrolle (wird ignoriert)
LENGTH 5 bit Paketlänge
Payload ID 1 bit 0 Übertragungsrichtung vom Master
1 Übertragungsrichtung vom Slave
OPCODE 7 bit PDU-Typ: unterscheidet 55 PDUs
(Param) 16 bit Parameter: Länge und Inhalt kommandoabhängig

In der Bluetooth-Spezifikation sind 23 Prozeduren und ihre Varianten beschrieben.
Jede Prozedur-Variante besteht aus einer bestimmten Abfolge von PDUs, die abwechselnd von Master und Slave gesendet werden.
Tab. 13-9 zeigt Prozeduren, Varianten und enthaltene PDUs als Übersicht.
Tab. 13-10 zeigt die 55 definierten PDUs im Detail, ohne allerdings auf den Inhalt der Parameter einzugehen. Diese Tabelle ist nach Funktionsbereichen gegliedert und zeigt von links nach rechts den OpCode, den symbolischen Namen, die verwendeten Pakettypen, mögliche Übertragungsrichtungen und die Länge des Parameterblocks.

13.9   Logical Link Control and Adaptation Layer Protocol (L2CAP)

13.9.1 Überblick

L2CAP ist in der gleichen Schicht angesiedelt wie LMP. Es stellt die Verbindung her zwischen Link Control und höheren Protokollschichten (im folgenden "Anwendungen" genannt). Diesen stellt es verbindungsorientierte und verbindungslose Datendienste zur Verfügung. Jede Anwendung kann einen oder mehrere logische L2CAP-Kanäle benutzen, auf die sie über Endpunkte zugreifen kann.
L2CAP verkehrt mit der übergeordneten Anwendungsschicht über L2CA-Nachrichten, die Übergabe an die untergeordnete LC-Schicht erfolgt mit LP-Nachrichten. Zwischen den L2CAP-Schichten zweier Bluetooth-Einheiten werden L2CAP-Pakete ausgetauscht, die wesentlich länger sein können als LC-Pakete.
Die Anwendungs-Endpunkte werden von L2CAP im Multiplex bedient. Die L2CAP-Pakete werden zur Übertragung im Sender segmentiert und im Empfänger wieder zusammengesetzt. LC-seitig benutzt L2CAP ausschließlich CRC-gesicherte ACL-Pakete, also DMx- und DHx-Typen.

13.9.2 Multiplex und Segmentierung

Meist setzen mehrere Anwendungen auf L2CAP auf. Um diesen einen gleichberechtigten und quasi-gleichzeitigen Zugriff auf das Übertragungsmedium zu gewähren, werden die Sendeanforderungen der verschiedenen Anwendungen gemultiplext und im Empfänger auf die Zielanwendungen verteilt. Als Herkunftskennzeichen dient während der Übertragung ein "Channel Identifier" (CID), die Adresse des L2CAP-Kanals.
L2CAP tauscht mit den Anwendungen Datenblöcke mit einer maximalen Länge von 64 kByte aus. Für die Übertragung werden diese im Sender in kürzere Blöcke zerlegt (max. 341 Byte), die in ACL-Paketen untergebracht werden können. Im Empfänger werden sie dann wieder zusammengesetzt. Im ACL-Paket wird im L_CH-Feld ein Bit gesetzt, das angibt, ob es sich um ein Start- oder ein Folgepaket handelt. Der Empfänger kann damit prüfen, ob sein L2CAP-Paket die richtige Anzahl ACL-Pakete enthält.

13.9.3 Kanäle und Endpunkte

L2CAP bietet den höheren Protokollschichten Datendienste an. Dafür werden bei Bedarf für jede Anwendung einer oder mehrere Logische Kanäle ("Channels") zwischen Endpunkten ("Endpoints") eingerichtet. Über diese Endpunkte werden L2CAP-Daten-Pakete ausgetauscht. Identifiziert werden Kanäle und Endpunkte über "Channel Identifier" (CID)
Folgende Kanaltypen stehen zur Verfügung:

CID Kanaltyp Beschreibung
0000 "Null Identifier" [nicht verwendet]
0001 "Signalling Channel" Dient zur Einrichtung und Überwachung weiterer Kanäle; kann auch Daten übertragen
0002 Verbindungsloser Kanal Nur Empfang von "Multicast"-Nachrichten
0003 .. 003F [Reserviert] [für zukünftige Verwendung]
0040 .. FFFF Verbindungsorientierte Kanäle Normalfall für die Übertragung von Daten; CID wird dynamisch zugewiesen

13.9.4 Signalisierung und Pakete

Der Signalisierungskanal (Signalling Channel, mit CID=0001) existiert bereits unmittelbar nachdem ACL vom Link Manager für andere Schichten freigegeben wurde. Über ihn können weitere, verbindungsorientierte Kanäle (mit CID=0040..FFFF) eingerichtet, überwacht und wieder abgemeldet werden.
Abb. 13-11 zeigt das Sitzungsdiagramm für einen bidirektionalen, verbindungsorientierten Kanal. Es gliedert sich in vier Phasen:

Bezeichnung Zweck Startzustand Endzustand Kommando- Kaskade Antwort- Kaskade
Connecting Anmelden des Kanals CLOSED CONFIG Connect_ Request, Connect_ Indication Connect_ Response, Connect_ Confirm
Configuration Aushandeln der Kanaleigen- schaften CONFIG OPEN Config_ Request, Config_ Indication Config_ Response, Config_ Confirm
Transmission Austausch von Nutzdaten OPEN OPEN Data_Write, Data_Read Data_Write, Data_Read
Disconnect Abmelden des Kanals OPEN CLOSED Disconnect_ Request, Disconnect_ Indication Disconnect_ Response, Disconnect_ Confirm

Zum Austausch von Informationen zwischen L2CAP-Schichten mehrerer Bluetooth-Einheiten werden L2CAP-Pakete verwendet. Tab. 13-12 zeigt eine Übersicht.
Alle L2CAP-Pakete sind gleich aufgebaut:
  • L2CAP-Header besteht aus 2 Feldern:

    • Länge (16 bit) enthält eine Angabe über die Anzahl der Bytes im Informationsteil

    • CID (16 bit) enthält die Identifikation des verwendeten Kanals


    0001 Signalisierungskanal
    0002 verbindungslos, Broadcast
    0040..FFFF Verbindungsorientierter Datenkanal

  • Informationsteil ("Payload") kann folgende Felder enthalten:

    • Daten (=Nutzdaten), verbindungsorientiert oder verbindungslos

    • PSM ("Protocol/Service Multiplexor") enthält den Typ der Anwendung. Es ist zunächst 16 bit lang, kann aber für spätere Anwendungen erweitert werden. Bisher sind definiert:


    • 0001 SFD Service Discovery Protocol
      0003 RFCOMM Cable Replacement Protocol
      0005 TCP Telephony Control Protocol

    • Kommando: nur im Signalisierungskanal;
      mehrere Kommandos können in einem Paket zusammengefasst werden. Die möglichen Signalisierungskommandos und ihren Aufbau zeigt der untere Teil der Tab. 13-12.
      Das erste Feld (8 bit) enthält den Kommandotyp, das zweite Feld "ID" wird bei _request mit einer "Anforderungsnummer" versehen. Die Antwort enthält die gleiche ID und kann dadurch eindeutig zugeordnet werden.
      Auch bei Signalisierungskommandos muss klar sein, von wem die Kommandos kommen und für wen sie bestimmt sind. Dafür bezeichnet das Feld Source-CID immer den Initiator, Dest-CID immer den Akzeptor der Prozedur, unabhängig von der Übertragungsrichtung der einzelnen PDU.


Die Signalisierungskommandos 0A und 0B können zum Austausch von Informationen verwendet werden, wenn (noch) kein eigener Datenkanal eingerichtet ist.

13.10   Host Controller Interface (HCI)

Die gesamte Funktionalität eines Bluetooth-Geräts besteht aus mehreren Modulen, die typischerweise auf zwei Prozessoren aufgeteilt werden.
Sind die beiden Teile räumlich getrennt, werden sie als "Host" und "Host Controller" bezeichnet und physikalisch über eine zusätzliche Transportschicht, das "Host Controller Interface" (HCI), miteinander verbunden (Abb. 13-13).
Der Host enthält im wesentlichen
  • Höhere Protokollschichten (z.B. AUDIO, RFCOMM, SDP, TCS)
  • VOICE
  • L2CAP
Im Host Controller befinden sich unter anderem
  • LMP
  • LC (Baseband)
  • RF (Physikalische Schicht)
HCI besteht aus drei Teilen:
  • Der "HCI-Treiber" im Host produziert auf Anforderung höherer Schichten Kommandos ("Commands"), die an den Host Controller geschickt werden und dort LMP, LC und Hardware-Register steuern. Vom Host Controller werden Ereignisse ("Events") gemeldet, die der HCI-Treiber entsprechend verarbeitet.

  • Die "HCI-Firmware" im Host Controller ist das Gegenstück zum HCI-Treiber. Sie empfängt die Kommandos, mit denen sie die Module im Host Controller steuert und produziert Ereignismeldungen an den Host.

  • Die HCI-Transportschicht bereitet Daten, die transportiert werden sollen, in vier verschiedenen Pakettypen auf und stellt sie dem leitungsgebundenen Transportprotokoll (USB, RS232, UART) im geeigneten Format zur Verfügung:

    • Kommando-Pakete ("Commands") vom Host (HCI-Treiber) zum Host Controller (HCI-Firmware)
      Jedes Kommando beginnt mit einem 16 bit OpCode, aufgeteilt in OpCode Group Field (OGF: 6 bit) und OpCode Command Field (OCF: 10 bit). Es folgen die Längenangabe der Parameter in Byte (8 bit) und die eigentlichen Parameter.


    • Ereignis-Pakete ("Events") vom Host Controller (HCI-Firmware) zum Host (HCI-Treiber)
      Ereignisse sind ähnlich aufgebaut wie Kommandos. Der OpCode wird allerdings ersetzt durch einen 8 bit langen EventCode.


    • ACL-Daten-Pakete im Auftrag von L2CAP in beiden Richtungen

    • SCO-Daten-Pakete im Auftrag von VOICE in beiden Richtungen

Die Transportschicht ist transparent für HCI-Pakete. Unterschieden werden die Pakettypen nur in der Transportschicht. Bei Verwendung von USB werden dazu z.B. 4 USB-Endpunkte (mit 4 verschiedenen Typen) verwendet. RS232 schaltet einen zusätzlichen 2 bit Transport-Header vor die HCI-Pakete, mit dem die 4 Typen unterschiedlich codiert werden.
Abb. 13-13 zeigt das erweiterte Schichtenmodell und die Struktur der verschiedenen Pakettypen.
Tab. 13-14 enthält eine Übersicht der möglichen Kommandos (dunkle Zeilen) und der zugehörigen Ereignisse (helle Zeilen). Die Tabelle ist gruppiert nach den OGFs und sortiert nach OGF und OCF. Rechts neben der Kurzbeschreibung sind noch die Parameter nach Anzahl und Länge aufgeführt, aber nicht im Detail beschrieben.