Bluetooth-Grundlagen: Herkunft und Funktionsweise

Seit der Einführung von Bluetooth im Jahr1999 hat sich diese Funktechnologie mittlerweile nicht nur bei Consumern, sondern auch bei vielen industriellen Anwendungen etabliert. Schätzungsweise mehr als 1,5 Milliarden Bluetooth-Chips wurden in den ersten zehn Jahren verbaut.

Mit zahlreichen Aktualisierungen und Erweiterungen des Standards versucht die Bluetooth Special Interest Group (Bluetooth SIG oder BSIG), dem Standard eine erfolgreiche Zukunft im Wettstreit der Funktechnologien zu sichern.

Dieser TecChannel-Beitrag gibt einen Einblick in die bestehenden Komponenten der Technologie und einen Ausblick in neue Entwicklungen. Im zweiten Teil unserer Miniserie zu Bluetooth gehen wir genauer auf die eigentliche Kommunikation sowie die Sicherheit ein.

Hintergründe und Standardisierung

Die Anfänge der Aktivitäten zu Bluetooth gehen bereits auf das Jahr 1994 zurück, als die Mobile Communications Division von Ericsson eine Machbarkeitsstudie zum Ersatz der vielfältigen Kabelverbindungen zwischen Mobiltelefonen und den verschiedenen Peripheriegeräten in Auftrag gab. In der Folge wurde Anfang 1998 die Bluetooth Special Interest Group (BSIG) von den fünf Firmen IBM, Toshiba, Intel, Ericsson und Nokia gegründet. Ziel war es, einen firmenübergreifenden Standard für sogenannte Wireless Personal Area Networks (WPAN) zu erstellen. Als erste finale Spezifikation veröffentlichte die BSIG Version 1.0a im Juli 1999.

Der engere Kreis der BSIG-Gründer wurde bald darauf im Rahmen einer Promoter-Group um die Firmen 3Com, Lucent, Microsoft und Motorola erweitert. Heute umfasst die BSIG mehr als 10.000 Mitglieder.

Der Name der Technologie ist abgeleitet von Harald I Blaatand (Blauzahn), der von 940 bis 981 als König von Dänemark das Land christianisierte und Norwegen und Dänemark vereinigte. Der Name geht auf die beiden Wörter „blå“ für dunkelhäutig und „tan“ für großer Mann zurück, was in diesem Fall gleichbedeutend mit König oder Anführer ist.

Versionen und zeitliche Entwicklung

Vor dem Hintergrund der fast zehnjährigen Geschichte liegen mittlerweile verschiedene Varianten und Erweiterungen des Bluetooth-Standards vor. Die wichtigsten Elemente im Kernstandard (Core-Standard) werden hier im Vorgriff auf die nachfolgende technische Beschreibung genannt:

• Die erste Version 1.0a wurde im Juli 1999 verabschiedet, Version 1.0b folgte im Dezember desselben Jahres.

• Seit Februar 2001 liegt der Standard in der Version 1.1 vor. Dieser galt als die erste solide Basis für marktgerechte Produkte, da die Vorversionen eine Reihe von Ungenauigkeiten und Fehlern aufwiesen. Probleme gab es etwa bei der Kompatibilität, der sauberen Implementierung von Piconetzen sowie einer eindeutigen Master-Slave-Zuweisung.

• Im November 2003 wurde dann mit der Version 1.2 eine grundlegend überarbeitete Spezifikation vorgelegt, die die Bluetooth-Architektur transparenter definierte und um einen schnellen Verbindungsaufbau (Fast Connection Setup) erweiterte. Zusätzlich statteten die Entwickler Bluetooth mit der Adaptive-Frequency-Hopping-(AFHSS)-Technologie aus und erlaubten eine verbesserte Sprachqualität im Rahmen der Extended SCO-Verbindungsart.

• Der gegenwärtige Standard stammt aus dem Jahr 2004 und bildet die Bluetooth-Spezifikation Version 2.0. Neu ist die Enhanced-Data-Rate-(EDR)-Erweiterung, die eine Erhöhung der Bruttodatenrate auf 2,2 MBit/s vorsieht. Bluetooth 2.0 + EDR ist aktuell in den meisten Endgeräten verbaut.

• Im Juli 2007 wurde zwar bereits Version 2.1 + EDR veröffentlicht, die unter anderem Unterstützung für Near Field Communications bringt und ein schnelleres Pairing ermöglicht. Allerdings ist die Spezifikation auch im August 2008 nur in wenigen Geräten im Einsatz.

• Bluetooth Version 3.0 trägt derzeit noch den Codenamen Seattle und soll die Ultra-Wide-Band-Technologie verwenden. Dadurch sind beispielsweise Datenraten von theoretisch bis zu 480 Mbit/s möglich. Einen zeitlichen Rahmen gibt es für diese Spezifikation noch nicht.

Zukünftige Erweiterungen gehen sowohl in Richtung verlustleistungsarmer Verbindungen als auch in Richtung höherer Datenraten.

• Im Rahmen von WiBree, beziehungsweise Ultra Low Power (ULP) Bluetooth soll eine energiesparende Variante für Sensoranwendungen im Consumer- und Home-Automation-Bereich bereitgestellt werden. Der wesentliche Vorteil bei diesem Ansatz soll sich laut den Bluetooth-Strategen daraus ergeben, dass Geräte wie Handys oder PDAs, die ohnehin über eine Bluetooth-Implementierung verfügen, weite Teile für die Anbindung der einfacheren Sensoren verwenden können.

• Die BSIG hat im März 2006 die Entscheidung getroffen, die OFDM-UWB-Variante der WiMedia Alliance als hochbitratiges „Wireless USB“ zu verwenden.

• Am Rande des Mobile World Congress im Februar 2008 in Barcelona kündigte die BSIG allerdings an, dass in Zukunft auch die WiFi-Protokolle nach IEEE802.11 als alternative MAC/PHY-Implementierungen für den Transport von hochbitratigem Bluetooth-Verkehr genutzt werden sollen. Diese Ankündigung hat vielfach Verwunderung ausgelöst, und es wird derzeit lebhaft darüber diskutiert, welche Auswirkungen das tatsächlich haben wird.

Nicht erwähnt bei dieser Aufstellung sind die Entwicklungen im Bereich der Anwendungsprotokolle, wo mittlerweile eine Vielzahl von anwendungsspezifischen Protokollen zur Verfügung steht.

Aufbau des Protokollstapels

Die Beschreibung der Bluetooth-Kommunikationsprotokolle umfasst alle Ebenen der Protokollschichten. Insbesondere die Steuerprotokolle zum Aufbau der Ad-hoc-Netzwerke, aber auch die Bestandteile zur Übertragung isochroner Verkehrsströme reichen deutlich über die Transportdienste eines reinen Funknetzes hinaus. Bluetooth stellt ein komplettes Funksystem bereit, das bewusst auch Anwendungsprotokolle vorsieht. Denn der Protokollstapel weist nicht nur Bluetooth-spezifische Protokolle auf, sondern greift auch in den höheren anwendungsorientierten Schichten auf bestehende und verbreitete Protokolle zurück. Als Beispiel seien die Transport- und Anwendungsprotokolle aus der TCP/IP-Familie genannt.

Betrachtet man den Umfang der Protokollbestandteile, zeigt sich, dass eine Bluetooth-Station mit komplettem Umfang eine Komplexität erreicht, die der angestrebten einfachen und kostengünstigen Realisierung entgegensteht. Statt einer kompletten und teuren Implementierung können Hersteller nur die notwendigen Bestandteile in den Geräten verbauen. Lediglich die Kernprotokolle müssen in jeder Station enthalten sein. Problematisch ist allerdings, dass damit die Interoperabilität der Geräte nicht immer gegeben ist. Um dieses Problem zu lösen, ist das Service Discovery Protocol (SDP) ein weiteres und verpflichtendes Protokoll. In der Realität führt dieser Sachverhalt dazu, dass sehr viele Anwendungen jenseits des eigentlichen Bluetooth-Protokollstapels über die serielle Schnittstelle RFComm realisiert werden.

Die Bluetooth-Spezifikation umfasst mit dem Host Controller Interface (HCI) auch eine Befehlsschnittstelle zum Baseband Controller und Link Manager sowie zum Hardware-Status und den Befehlsregistern. Die Positionierung des HCI kann angepasst werden. Die Abbildung zeigt das typische Beispiel, das in etwa mit der TCP-Socket-Schnittstelle gleichgesetzt werden kann. Die unteren drei Schichten werden hierbei oft als Bluetooth-Controller bezeichnet. Abbildung 2 zeigt sie mit ihren Signalströmen.

Für die Bluetooth-Standardisierung wurde ein neues Gremium eingerichtet. Das zeigt sich vor allem dadurch, dass nicht auf eine Konformität mit den Schichten der verbreiteten Referenzmodelle (OSI- oder TCP/IP-Referenzmodell) geachtet wurde. Eine Einpassung in andere Standardfamilien, etwa den Standards nach IEEE802.x, wird zwar vor allem vonseiten des IEEE angestrebt, ist aber auf der Grundlage der vorangehend genannten Punkte nur nach umfassenden Anpassungen möglich. Insbesondere wurde mit dem WPAN-Standard IEEE802.15.1 eine sprachlich angepasste Beschreibung der physischen und der Basisband-Schicht vorgelegt.

Physikalische Schicht – Frequenzsprungverfahren

Wie viele Funksysteme arbeitet auch der Bluetooth-Standard im praktisch weltweit lizenzfrei verfügbaren 2,4-GHz-ISM-Band. Auf Grund der potenziell sehr hohen Kanalauslastung (Duty Cycle) muss entsprechend den Vorschriften der Regulierungsbehörden ein Frequenzspreizverfahren eingesetzt werden. Hierbei nutzt Bluetooth ein Frequenzsprung-Spread-Spectrum-Verfahren (Frequency Hopping Spread Spectrum, FHSS).

In einem aufgebauten Piconetz wird die Frequenzfolge vom Master vorgegeben und folgt einer Pseudozufallsfolge, die in Abhängigkeit von der Geräteadresse des Masters und dessen Clock-Zustand nach vergleichsweise aufwendigen Regeln berechnet wird und somit in jedem Piconetz unterschiedlich ist. Auf diese Weise soll der Betrieb von möglichst vielen unabhängigen Piconetzen mit hoher räumlicher Dichte unterstützt werden.

Der Aufbau der Frequenzberechnung ist in den Abbildungen 3 und 4 dargestellt. Die Frequenzen sind im Wesentlichen abhängig von der 28 Bit breiten Master-Clock CLK sowie den unteren 28 Bit der 48 Bit langen Bluetooth-MAC-Adresse. In der Frequenzberechnung finden weitere – hier nicht gezeigte – Verfahren Anwendung, wie etwa in dem PERM5-Block, die zu einer möglichst guten Gleichverteilung der gewählten Frequenzen führen.

Bei der Auswahl der Frequenzen muss natürlich Rücksicht auf die regionalen Restriktionen genommen werden. Der Aufwand wird gering gehalten, indem nur zwei Betriebsmodi unterschieden werden: Ein Modus mit 79 Sprungfrequenzen steht für Nordamerika und Europa zur Verfügung, ein zweiter Modus mit 23 Sprungfrequenzen wurde für Japan und ehemals Frankreich und Spanien definiert.

In dem Frequenzsprungverfahren beträgt die nominale Sprungrate 1600 Hops/s. Hierzu gibt der Master allen Slaves im Piconetz Zeitschlitze mit einer Länge von 625 µs vor, wobei eine Übertragung von allen Teilnehmern nur zu Beginn eines Zeitschlitzes gestartet werden darf. Die Zeitschlitze werden in Abhängigkeit von der Clock des Masters von 0 bis 227-1 durchgezählt, sodass sich eine Zykluszeit der Zählung von etwa 23 h ergibt.

Zur Unterstützung von bidirektionalem Verkehr wird ein Time Division Duplex-(TDD-)-Verfahren eingesetzt, bei dem der Master seine Übertragung nur zu Beginn eines geradzahligen Zeitschlitzes, die Slaves nur zu Beginn von ungeradzahligen Zeitschlitzen beginnen dürfen, wie dies in Abbildung 5 dargestellt ist.

Auf diese Basisfrequenz werden die Nutzinformationen mithilfe eines GFSK (Gaussian Frequency Shift Keying) aufmoduliert. Binäre Einsen werden hierbei durch eine positive, binäre Nullen durch eine negative Abweichung von der Trägerfrequenz repräsentiert. Der Unterschied dieser beiden Frequenzen soll größer als 115 kHz sein. Das Bandbreiten-Zeit-(BT)-Produkt soll 0,5 betragen, der Modulationsindex zwischen 0,28 und 0,35 betragen.

Adaptivität im Frequenzsprungverfahren

Beim 2,4-GHz-Band handelt es sich um ein so-genanntes ISM-Band, das für lizenzfreie industrielle (industrial), wissenschaftliche (scientific) und medizinische (medical) Anwendungen reserviert ist. Die in solchen ISM-Bändern aktiven Funksysteme müssen sich an die regulatorischen Vorgaben halten, sind aber ansonsten sowohl in Bezug auf die Implementierung ihrer Modulationsarten und Rahmenformate als auch in ihrem Einsatz frei.

Eines der Probleme dabei ist die Koexistenz zwischen mehreren Systemen einer Protokollfamilie, aber natürlich – und insbesondere – auch zwischen Systemen unterschiedlicher Protokollfamilien. Diese Koexistenzproblematik ist Gegenstand zahlreicher Untersuchungen. Beim IEEE wurde sogar eine eigene Arbeitsgruppe 802.2 eingerichtet, die Lösungsmöglichkeiten (Recommended Practices) insbesondere für die Koexistenz von IEEE802.11 (WLAN) und Bluetooth erarbeitet und in 2003 veröffentlicht hat. Die Analysen dieser Arbeitsgruppe sind sehr lesenswert. Leider sind die dort beschriebenen Vorgaben aber sehr allgemein. Die Gruppe konnte unter dem Druck der Industrieunternehmen keine tragfähige kooperative Lösung erarbeiten, so-dass sich die Ergebnisse der Arbeitsgruppe auf Analysen beschränken mussten.

Im Laufe der Jahre haben jedoch zwei Aspekte zu einer Veränderung der Situation geführt. Zum einen verschärft sich die Koexistenzproblematik in der Praxis zusehends durch eine zunehmende Nutzung des 2,4-GHz-ISM-Bandes. Zum anderen wurden die Vorschriften der Regulierungsvorgaben in Bezug auf die minimale Anzahl von zu nutzenden Frequenzen bei Frequenzsprungverfahren gelockert, indem die minimale Anzahl der Frequenzen im 2,4-GHz-Band auf 15 reduziert wurde.

Auf dieser Grundlage wurde 2003 das Frequenzsprungverfahren in der Version 2.0 des Bluetooth-Standards um eine adaptive Komponente (adaptive frequency hopping, AFH) erweitert. Hierbei wurde allerdings nur festgelegt, dass der Master in einer Picozelle die zu nutzenden oder die auszublendenen Frequenzen den Slaves vorgeben darf. Es ist jedoch weiterhin der Implementierung überlassen, auf welcher Grundlage diese Entscheidung getroffen wird. Außerdem bleibt die eigentliche Frequenzsprungvorschrift unverändert. Lediglich die Abbildungsfunktion auf konkrete Frequenzen wird angepasst. Der AFH-Ansatz bei Bluetooth setzt sich aus vier Bestandteilen zusammen [104] [103]:

• Die Komponente „Channel Classification” bewertet die einzelnen Frequenzen in Abhängigkeit von ihrer Belastung.

• Es ist die Aufgabe des „Link Management“ (LM), die relevanten AFH-Informationen an alle angemeldeten Bluetooth-Knoten im Netzwerk zu verteilen.

• Mithilfe der „Hop Sequence Modification“ werden die Kanäle selektiv reduziert.

• Die „Channel Maintenance“ ist für die periodische Neubewertung der Kanalqualität zuständig.

Testergebnisse zeigen, dass der AFH-Algorithmus in Koexistenzsituationen eine etwa 30-prozentige Leistungssteigerung für Bluetooth und eine etwa 80-prozentige Leistungssteigerung für WLAN ergibt. Dies entspricht in etwa auch Simulationsergebnissen für ähnliche Frequenzsprungverfahren.

Data Link Layer

Auf der Ebene des Data Link Layer (Sicherungsschicht) sind vor allem die Basistopologie, die Zugriffsmechanismen und die Adressierung beschrieben. Im Bluetooth-Protokoll sind diese Aufgaben besonders in den beiden folgenden Teilschichten umgesetzt:

• Link Manager Protocol (LMP): Das LMP erfüllt Aufgaben der Netzverwaltung. Diese umfassen insbesondere den Verbindungsaufbau zwischen Stationen, die Authentifizierung und Verschlüsselung sowie die Steuerung der Energiesparmodi und der Gerätezustände in einem Piconetz.

• Logical Link Control and Adaptation Protocol (L2CAP): Das L2CAP verbindet die Protokolle der höheren Schichten mit den Aufgaben des Basisbands. Es ist in der Weise parallel zu LMP angeordnet, dass L2CAP die Übertragung der Nutzdaten übernimmt. L2CAP stellt sowohl verbindungsorientierte als auch verbindungslose Dienste zur Verfügung, greift selbst aber nur auf die verbindungslosen asymmetrischen ACL-Verbindungen des Basisbandprotokolls zu.

Ein Bluetooth-Netzwerk ist grundsätzlich nach dem Master-Slave-Prinzip aufgebaut, wobei der Master die Steuerung des Verkehrsflusses übernimmt. Auf diese Art sind vergleichsweise einfach isochrone Verkehrsströme abzuwickeln, wie sie etwa im Rahmen des Audiomoduls benötigt werden.

Grundsätzlich sind folgende Arten von Bluetooth-Netzwerken zu unterscheiden (vgl. Abbildung 6):

• Wenn nur ein Master in einem Netzwerk vorhanden ist, handelt es sich um ein Piconetz.

• Wenn der eine Master ausschließlich mit einem Slave im Rahmen einer Punkt-zu-Punkt-Verbindung (Point-to-Point) kommuniziert, wird das Netzwerk im Mono-Slave-Modus betrieben.

• Der eine Master kann aber auch im Multi-Slave-Modus Punkt-zu-Multipunkt-Verbindungen (Point-to-Multipoint) mit bis zu sieben aktiven Slaves etablieren, wobei weitere Slaves im geparkten Zustand passiv teilnehmen können.

• Ein Scatternetz setzt sich aus mehreren Piconetzen zusammen. Da jedes Piconetz von einem Master verwaltet wird, gibt es im Scatternetz-Modus folgerichtig mehrere Master. Dabei kann eine Station als Slave in mehreren Piconetzen angemeldet sein und nacheinander in diesen Netzen auch aktiv sein. Darüber hinaus kann ein Master eines Piconetzes gleichzeitig auch Slave in einem anderen Piconetz sein.

Scatternetze haben sich in den heutigen Realisierungen der Bluetooth-Protokollstapel nicht durchgesetzt. Gleiches gilt für viele Routing-Algorithmen, die für umfassendere Netzwerkverwaltung entwickelt wurden. In einem solchen Piconetz wird der Kommunikationsablauf durch den Master vorgegeben. Dieser gibt, wie bereits beschrieben, allen Slaves im Piconetz Zeitschlitze mit einer Länge von 625 µs vor, wobei eine Übertragung von allen Teilnehmern nur zu Beginn eines Zeitschlitzes gestartet werden darf.

Aufeinanderfolgende Pakete werden auf verschiedenen Frequenzen übertragen. Im normalen Modus wird mit dem Beginn eines jeden neuen Zeitschlitzes ein Frequenzsprung durchgeführt. Bei der Übertragung von Paketen, die drei oder fünf Zeitschlitze einnehmen, wird die Frequenz bis zur vollständigen Übertragung des Pakets festgehalten. Das folgende Paket wird danach mit der Frequenz übertragen, die dem Zustand der Clock entspricht.

Adressierung und Anmeldung

Die Bluetooth-Geräte folgen einer Adressierung nach den 48 Bit langen IEEE-Adressen. Die Adressen werden sowohl zur eindeutigen Identifizierung der Geräte während der Anmeldung in ein Netzwerk verwendet, als auch im Fall eines Masters, zur Berechnung der Sprungfolgen.

Nach der Anmeldung wird den aktiven Slaves eine drei Bit lange Kurzadresse (active member address, AM_ADDR) zugewiesen, die diese für die Kommunikation in ihrem Piconetz verwenden. Die geringe Länge dieser Kurzadresse limitiert die Anzahl der aktiven Slaves in einem Piconetz auf sieben.

Jedoch müssen bei der Anmeldung in einem solchen Piconetz eine Reihe von Arbeitsschritten durchgeführt werden. Insbesondere aufgrund der notwendigen Aufsynchronisation von Slaves auf die Frequenzsprungfolge des Masters benötigt die Anmeldung eine gewisse Zeit. Diese unterteilt sich dann im Wesentlichen in zwei Phasen:

• Mithilfe des Inquiry können die Stationen herausfinden, welche anderen Stationen mit welchen Adressen und Clock-Zuständen sich im Umkreis ihrer Funkreichweite befinden.

• Das Paging dient dazu, eine Verbindung zwischen den Geräten zu etablieren.

Um eine spontane (ad-hoc) Anmeldung zu ermöglichen, versendet jede eingeschaltete Station in regelmäßigen Zeitabständen Anfragen (inquiry) an die Umgebung und hört den Kanal in den Zeiten zwischen zwei eigenen Anfragen auf Anfragen anderer Stationen ab.

Die synchrone Kommunikation

Der Bluetooth-Standard sieht in den bisherigen Versionen zwei grundsätzliche Kommunikationsarten vor, die für die unterschiedlichen in Abbildung 7 gezeigten Verbindungsarten genutzt werden können:

Die synchrone verbindungsorientierte Kommunikation (Synchronous Connection-Oriented Link – SCO) realisiert eine symmetrische Punkt-zu-Punkt-Kommunikation zwischen dem Master und genau einem Slave. SCO entspricht funktional einer leitungsvermittelten Übertragung, da der Master in regelmäßigen Abständen Zeitschlitze reserviert. Dies bedeutet, dass der Master in festgelegten Zeitschlitzen Daten an den Slave sendet, wobei der Slave berechtigt ist, in dem jeweils folgenden Zeitschlitz seine Daten abzusetzen. Ein Master kann bis zu drei SCO-Verbindungen zu einem oder mehreren Slaves unterhalten. Ein Slave kann seinerseits bis zu drei SCO-Verbindungen mit einem Master oder maximal zwei SCO-Verbindungen von verschiedenen Mastern unterstützen.

Die SCO-Verbindungen sind darauf ausgelegt, eine effiziente Sprachübertragung zu gewährleisten. Hierbei ist von Bedeutung, dass bei der Übertragung von Sprachinformation ein Datenverlust in einem gewissen Umfang sehr viel unkritischer ist, als eine Verzögerung der Informationen. Deswegen findet bei SCO-Verbindungen keine Überprüfung der Datenintegrität statt. Für den Fall, dass Daten bei der Übertragung verloren gehen, findet folglich keine erneute Übermittlung statt, weil dies auch eine Verzögerung der folgenden Sprachinformationen bedeuten würde.

Um auch in schwierigen Umgebungsbedingungen die Bitfehlerrate in einem erträglichen Maß zu halten, werden Fehlerkorrektur-(Forward Error Correction, FEC)-Verfahren eingesetzt. Hierbei finden Faltungscodierung und Viterbi-Decodierung Einsatz. Da FEC-Verfahren zusätzliche Redundanz in den Datenstrom einfügen, lässt sich auf diese Weise die Übertragungsqualität gegen die Nettodatenrate abgleichen.

Die asynchrone Kommunikation

Die asynchrone verbindungslose Kommunikation (Asynchronous Connectionless Link – ACL) hingegen stellt eine Verbindung zwischen dem Master und einem oder mehreren Slaves dar, die nur dann erfolgen darf, wenn der Kanal nicht für einen SCO reserviert ist. Eine ACL-Verbindung entspricht einer paketvermittelten Übertragung. Zwischen einem Master und einem Slave darf zu einem Zeitpunkt nur eine ACL-Verbindung aufgebaut sein. Im Rahmen der ACL-Verbindungen kann der Master auch Pakete an alle Slaves in seinem Piconetz versenden, indem er keine Zieladresse angibt. Dies wird dann als Broadcast interpretiert. Eine Broadcast-Übertragung von einem Slave wird nicht unterstützt.

Die ACL-Verbindungen sind im Gegensatz zu den SCO-Verbindungen für eine effiziente Datenübertragung ausgelegt. Bei Übermittlung von Daten spielt die Verzögerung eine meist untergeordnete Rolle, während die Datenintegrität von zentraler Bedeutung ist. Deswegen werden im Rahmen von ACL-Verbindungen fehlerhafte oder fehlende Informationsbestandteile erneut angefordert.

In jeder dieser Verbindungsarten stehen verschiedene Pakettypen zur Verfügung, die versendet werden dürfen. Diese sind in Abbildung 8 mit den wichtigsten Eigenschaften aufgeführt.

• Gemeinsame Pakettypen: Sowohl für asymmetrische als auch für symmetrische Verbindungen stehen mit ID-, NULL-, POLL- und FHS-Paket gemeinsame Pakettypen zur Verfügung, die im Wesentlichen zur Verwaltung der Teilnehmerstationen dienen.

• DM-Pakete tragen Daten mittlerer Geschwindigkeitsanforderung (Data – Medium Rate). Wie bei den folgenden Pakettypen auch, repräsentieren die Zahlen 1, 3 oder 5 die Anzahl der Zeitschlitze, die das Paket einnimmt (vgl. Abschnitt ?5). Das DM1-Paket kann in beiden Verbindungstypen (SCO & ACL) versendet werden und stellt eine Art Basisverbindung dar.

Insbesondere besteht hierdurch auch die Möglichkeit, während der synchronen Verbindung Steuerinformationen zu übertragen.

• DH-Pakete tragen Daten hoher Geschwindigkeitsanforderung (Data – High Rate). Sie unterscheiden sich von den DM-Paketen lediglich durch den Wegfall der FEC-Redundanz.

• HV-Pakete sind vorgesehen für die Übertragung von Sprache (High Quality Voice) und anderen synchronen und transparenten Diensten.

• DV-Pakete setzen sich aus einem Daten- und einem Sprachblock zusammen (Data Voice Combined). Die beiden Bestandteile werden vollständig unabhängig voneinander bearbeitet. Dies bezieht sich auch auf die Fehlerbehandlung durch Codierung und Redundanzübertragung.

Damit endet der erste Teil unserer Bluetooth-Miniserie. In Folge zwei erfahren Sie mehr über Bluetooth-Sicherheit sowie die eigentliche Kommunikation der Geräte. (mja)