Studienarbeit - Bluetooth-Anwendungen

Studienarbeit 

Bluetooth-Anwendungen 

„unplug and connect“ 

Bearbeiter Schwerpunkte 

Holger Hildebrandt 1.1, 1.2, 1.3, 2.1, 2.3, 3.1-4 , 4. 

Kay Pein 1.1, 1.2, 1.4, 2.1-3, 3.1-4

Inhalt 

KAPITEL 1 - DER FUNKSTANDARD BLUETOOTH 

1.1. EINLEITUNG: WAS IST BLUETOOTH? 

1.1.1. MOTIVATION 

1.1.2. URSPRUNG 

1.1.3. EINORDNUNG DES STANDARDS 

1.1.4. ABGRENZUNG ZU ANDEREN FUNKÜBERTRAGUNGSSTANDARDS 

1.1.5. VERWENDUNG DER BLUETOOTH-TECHNOLOGIE 

1.2. GRUNDLAGEN BLUETOOTH 

1.2.1. FAST FREQUENCY HOPPING - VERFAHREN 

1.2.2. LEISTUNGSKLASSEN 

1.2.3. NETZTOPOLOGIEN 

1.2.4. ADRESSIERUNG UND STATUSMODI 

1.2.5. KANALTYPEN 

1.2.5.1. Synchronous Connection-Orientated (SCO): 

1.2.5.2. Asynchronous Connection-Less (ACL) 

1.2.6. DIE SICHERHEIT BEI VERWENDUNG VON BLUETOOTH 

1.3. STANDARDS UND EVOLUTION 

1.3.1. EINLEITUNG 

1.3.1.1. Wozu sind Standards nötig? 

1.3.1.2. Wer macht die Standards bei Bluetooth? 

1.3.2. DIE STANDARDS IM ÜBERBLICK 

1.3.2.1. Bluetooth 1.0a und 1.0b 

1.3.2.2. Bluetooth 1.1 


1.3.2.3.1. eQoS 

1.3.2.3.2. Verbesserter Verbindungsaufbau 

1.3.2.3.3. Neuer Übertragungsmodus eSCO 

1.3.2.3.4. Interferenzminimierung durch AFH 

1.3.2.3.5. Abwärtskompatibilität zu Bluetooth 1.1 

1.3.2.3.6. Anlehnung der Wortwahl an IEEE 

1.3.2.3.7. Grundlegende Umstrukturierung 

1.3.2.3.8. Verabschiedung neuer Profile 

1.3.2.3.9. Anonymity Mode 

1.3.2.4. Ausblick auf Bluetooth 2.0 

1.3.3. BLUETOOTH IN DER IEEE 

1.4. BLUETOOTH-PROTOKOLLSTAPEL 

1.4.1. EINLEITUNG 

1.4.2. DIE PROTOKOLLE DER BLUETOOTH-ARCHITEKTUR 

1.4.2.1. Bluetooth Kernprotokolle 

1.4.2.1.1. Bluetooth Radio / Baseband 

1.4.2.1.2. Link Manager Protocol (LMP) 

1.4.2.1.3. Logical Link Control and Adaptation Protocol (L2CAP) 

1.4.2.1.4. Das Host Controller Interface (HCI) 

1.4.2.1.5. Service Discovery Protocol (SDP) 

1.4.2.1.6. Audio 

1.4.2.2. Cable Replacement Protocol 

1.4.2.2.1. RFCOMM (Radio Frequency Communication) 

1.4.2.3. Telefonie-Steuerungs-Protokolle 

1.4.2.3.1. Telephony Control – Binary 

1.4.2.3.2. Telephony Control – AT Commands 

1.4.2.4. Aufgesetzte Protokolle 

1.4.2.4.1. OBEX Protocol 

1.4.2.4.2. Content Formats vCard und vCalendar 

1.4.2.4.3. Internetprotokolle 

1.4.2.4.4. PPP (Point to Point Protocol) 

1.4.2.4.5. TCP/UDP/IP 

1.4.2.4.6. Wireless Application Protocol WAP

1.4.3. PAKETAUFBAU 

1.4.3.1. Adressierung 

1.4.3.2. Pakete 

KAPITEL 2 - VERBINDUNGSANALYSE 

2.1 VORSTELLUNG DES BLUETOOTH-PROTOKOLLTESTERS FTS 

2.1.1. FTS – AIRSNIFF (BASIC) TUTORIAL 

2.1.2. ANMERKUNG 

2.2 MSC EINER OBEX DATENÜBERTRAGUNG 

2.2.1. DARSTELLUNG 


2.3 BLUETOOTH IN DER PRAXIS 

2.3.1. KONFIGURATION UND BETRIEB 

2.3.2. REICHWEITEN 

2.3.3. KANALNUTZUNG IN FFH 

KAPITEL 3 - KOEXISTENZ IM ISM-BAND 

3.1 EINLEITUNG 

3.2 FTS-PAKETANALYSE 

3.2.1. STÖREINFLUSS VON WLAN 

3.2.2. STÖREINFLUSS EINER MIKROWELLE 

3.2.3. FAZIT 

3.3 DURCHSATZMESSUNGEN 

3.3.1. MOTIVATION 

3.3.2. WAHL EINES GEEIGNETEN PROGRAMMS 

3.3.3. VORBEREITUNG DES EXPERIMENTS 

3.3.4. MESSAUFBAU 

3.3.5. DURCHFÜHRUNG 

3.3.6. AUSWERTUNG 

3.3.7. FAZIT 

3.4 CROSS MEASUREMENTS 

3.4.1. EINFÜHRUNG 

3.4.2. VISUALISIERUNG 

3.4.3. FAZIT 

KAPITEL 4 - DIE FUNKTIONSWEISE VON AFH 

4.1 EINLEITUNG 

4.2 MOTIVATION 

4.3 KLASSIFIKATION DER FREQUENZKANÄLE 

4.3.1. CHANNEL-CLASSIFICATION 

4.3.2. CHANNEL-MAP 

4.3.2.1. Channel-Classification-Report 

4.4 CHANNEL-MAP-ÜBERMITTLUNG UND AKTIVIERUNG VON AFH 

4.4.1. FREQUENZAUSWAHL 

4.4.2. NICHT-ADAPTIVE SLAVES 


4.5 SAME CHANNEL METHOD 

4.6 ABWÄRTSKOMPATIBILITÄT ZU BLUETOOTH 1.1

Abkürzungen 

A 

ACK Acknowledge 

ACL Asynchron Connection-Less 

AFH Advanced Fequency Hopping 

AM_ADDR Active Member Address 

API Application Programming Interface 

ARQ Automatic Repeat Request 

ARQN Ackknowledge Request Number 

AT Attention (in Telephone Control Commands) 

B 

BD_ADDR Bluetooth Device Address 

BT Bluetooth 

C 

CAC Channel Access Code 

CC Channel Classification 

CCR Channel Classification Report 

ChM Channel Map in AFH (eigene Abk) 

CRC Cyclic Redundancy Check 

CSMA/CD Carrier Sense Multiple Access w/ Collision Detection 

CTP Cordless Telephony Profile 

CTS Clear To Send 

CVSD Continuos Variable Slope Delta 

D 

DAC Device Access Code 

DH Data High-rate (Packettyp in ACL) 

DM Data Medium-rate (Packettyp in ACL) 

DSR Data Set Ready 

DTR Data Terminal Ready 

DUN-P Dial-Up Networking Profile 

DV Data Voice (Packettyp in SCO) 

E 

eQoS enhanced QoS 

eSCO enhanced SCO 

ETSI European Telecommunications Standardisation Institute 

EV Enhanced Variable (Packettyp in SCO) 

F 

FAX-P Fax-Profile 

FEC Forward Error Correction 

FFH Fast Frequency Hopping 

FTP File Transfer Protocol 

G 

GFSK Gaussian Frequency Shift Keying 

GSM Global System for Mobile Communication 

H 

HCI Host Controller Interface 

HEC Header Error Check

HF Hochfrequenz 

HTTP Hyper Text Transfer protocol 

HV High quality Voice (Packettyp in SCO) 

I 

IAC Inquiry Access Code 

ID Identification 

IEC International Electrotechnical Commission 

IEEE Institute of Electrical and Electronics Engineers 

IP Internet Protocol 

IrDA Infra-red Data Association 

IrMC Ir Mobile Communication 

ISDN Integrated Services Digital Network 

ISM Industrial, Science, Medical 

ISO International Standardization Organisation 

ITU-T International Telecommunication Union – Telecom Standardization 

L 

L2CAP Logical Link and Control Adaption Protocol 

LAN Local Area Network 

LAP Lower Address Part 

LC Link Controller 

LCP Link Control Protokol 

LLC Logical Link Controller 

LM Link Manager 

LMANSC LAN/MAN Standards Committee 

LMP Link Manager Protocol 

LSB Least Significant Bit 

M 

MAC Medium Access Control 

MAN Metropolitain Area Network 

MSB Most Significant Bit 

MSC Message Sequence Chart 

MTU Maximum Transfer Unit 

N 

NAK Negative Acknowledgement 

NAP Non-significant Address Part 

O 

OBEX Object Exchange Protocol 

OSI Open Systems Interconnection 

P 

PAN Personal Area Network 

PC Personal Computer 

PCI Peripheral Component Interconnect 

PCM Pulse Code Modulation 

PCMCIA Personal Computer Memory Card International Association (PC Card) 

PDA Personal Digital Assistent 

PDU Potocol Data Unit 

PER Packet Error Rate 

PIN Personal Indetification Number 

PM_ADDR Parked Member Address 

PPP Point-to-Point Protocol

Q 

QoS Quality of Service 

R 

RF Radio Frequency 

RFC Request for Comments 

RFCOMM Radio Frequency Communication 

RS232 COM-Schnittstellenstandard 

RSSI Received Signal Strength Indication 

RTS Ready To Send 

Rx Receiver 

S 

SAR Segmentation and Reassembly 

SCO Synchronous Connection-Orientated 

SDDB Services Discovery Data Base 

SDP Services Discovery Protocol 

SDU Service Data Unit 

SEQN Sequence Number 

SIG Special Interest Group 

SIM Subscriber Identy Module 

T 

TCP Transport Control Protocol 

TCS Telephony Control Services 

TCS-bin Telephony Control Services - binary 

TDD Time Division Duplex 

TG Task Group 

Tx Transmitter 

U 

UAP Upper Address Part 

UDP User Datagram Protocol 

USB Unversal Serial Bus 

UUID Universal Unique Identifier 

W 

WAE WAP Application Environment 

WAP Wireless Application protolcol 

WBMP WAP Bitmap 

WLAN Wireless LAN 

WML Wireless Meta Language 

WPAN Wireless Personal Area Network

Kapitel 1 - Der Funkstandard Bluetooth 

1.1. Einleitung: Was ist Bluetooth? 

1.1.1. Motivation 

Ein hohes Kommunikationsaufkommen führt letztendlich zu einem größeren Verlangen nach 

Informationsaustausch zwischen verschiedenen Geräten. Dafür notwendige 

Kommunikationskanäle werden durch mechanisch anfällige und oft wenig komfortable 

Kabelverbindungen realisiert. Doch ist dieser auftretende „Kabelsalat“ für moderne mobile 

Anwendungen und auch bei anderen interagierenden Geräten teilweise überaus lästig. Eine 

der aufstrebenden Funkkommunikationslösungen, die dies im Nahbereich ohne Kabel 

möglich machen, ist Bluetooth. 

Weg und Ziel dieses Standards soll hier kurz beschreiben werden. Die inhaltlichen Fakten 

stützen ich dabei, bis auf wenige gekennzeichnete Ausnahmen, vollständig auf die 

Spezifikationen des Bluetooth-Standards [1, 2, 3]. Begründet ist diese Beschränkung der 

verwendeten Literatur durch sehr häufige und oft gravierende Widersprüche in verschiedenen 

Lektüren zum generellen Thema Bluetooth. Für Illustrationsmöglichkeiten und 

weiterführende Informationen wurden sehr begrenzt die unter [4] bis [19] aufgeführten 

Quellen als Vorlage verwendet. Bezogen auf Erfahrungsberichte, Marktneuheiten, Ausblicke 

und Interoperabilitätsprobleme, flossen zum Bearbeitungszeitpunkt aktuelle Informationen 

aus verfügbaren technischen Newstickern mit in die Ausarbeitung ein. 

1.1.2. Ursprung 

Die Bluetooth-Technologie geht zurück auf einen Entwurf, der bereits 1994 von der Firma 

Ericsson entwickelt wurde. Ericsson trat nach der grundsätzlichen Konzeption dieser 

Technologie an andere Hersteller von vorrangig tragbaren elektronischen Geräten heran. Ziel 

war dabei eine weltweite Standardisierung durchzusetzen. 

Im Jahr 1998 wurde von Ericsson gemeinsam mit Nokia, IBM, Toshiba und Intel die 

Bluetooth Special Interest Group (SIG) gegründet, die im Mai 1998 erstmals an die 

Öffentlichkeit trat und der sich mittlerweile weltweit mehr als 2100 Unternehmen durch eine 

Bluetooth-Anwender-Übereinkunft angeschlossen haben und aktiv die Entwicklung und 

Anpassung vorantreiben. 

Aufgrund der Vielzahl von Möglichkeiten, die dieser Standard zu verbinden versucht, wurde 

der Name Bluetooth (Blauzahn) gewählt. Dieser soll an den Dänischen König erinnern, der 

im zehnten Jahrhundert erstmals alle dänischen Provinzen unter seiner Krone vereinte. Dieser 

Vereinigungsgedanke soll in diesem Konzept des Datenaustausches weitergetragen werden. 

Um von Umgebungs- und Betriebsbedingungen möglichst unabhängig zu sein, wurde die 

Funktechnologie gegenüber der zu diesem Zeitpunkt bereits populäreren Infrarotübertragung 

favorisiert. Dadurch wurden Kurzstreckenfunkverbindungen auch ohne direkten Sichtkontakt 

möglich. Ferner ist dieser Standard eher anwendungsspezifisch gestaltet. Man kann ihn daher 

aus reiner Vermarktungssicht zwischen IrDA und WLAN ansiedeln. 

1

1.1.3. Einordnung des Standards 

Der Industriestandard Bluetooth wird von der IEEE unter dem Namen IEEE 802.15 in die 

bestehende Landschaft der IEEE-802-Normen eingereiht. Diese Klasse bezeichnet alle 

Benutzerszenarien, die durch ad-hoc-Konnektivität gekennzeichnet sind. 

Die Bluetooth-Technologie zeichnet sich durch die folgenden wesentlichen Designaspekte 

aus. 

Weltweite Nutzbarkeit 

Die drahtlose Bluetooth-Technologie verwendet das weltweit lizenzfrei verfügbare ISM- 

Funkfrequenzband. In den meisten Nationen liegt dieses Band im Frequenzbereich von 2400 

MHz bis 2483,5 MHz. Das ISM-Band (Industrial, Science, Medical) allgemein ist ein 

Frequenzbereich, der nicht der staatlichen Regulierung unterliegt und lizenzfrei für 

industrielle, wissenschaftliche und medizinische Anwendungen genutzt werden darf. 

Lediglich müssen Auflagen bezüglich der Sendeleistung und der Störung benachbarter 

Frequenzbereiche eingehalten werden. Somit dürfen Bluetooth-Geräte weltweit zulassungsfrei 

betrieben werden. Es muss aber mit Störungen durch andere Geräte gerechnet werden, die im 

gleichen Frequenzband arbeiten (z.B.: Mikrowellenherde, 802.11 WLANs, Medizinische 

Geräte, etc.). Diesen Störfaktoren wirken diverse Verfahren entgegen, sodass ein 

störungsfreier Betrieb gewährleistet ist bzw. genannte Störungen verkraftet werden. 

Sprach- und Datenunterstützung 

Bluetooth ist jeweils speziell für die Übertragung von Sprache und Daten konzipiert. 

Ad-hoc-Konnektivität 

Geräte sollen alleine andere Geräte in Reichweite finden und sich mit ihnen verbinden. 

Außerdem müssen mehrere Verbindungen gleichzeitig möglich sein. 

Sicherheit 

Mit Authentifizierung und Verschlüsselung soll derselbe Sicherheitsstandard wie bei 

Kabelverbindungen realisiert werden. 

Geringe Größe und kostengünstige Serienfertigung 

Im Vergleich zu anderen (Daten-) Funktechnologien, wie z.B. GSM, wird bei Bluetooth ein 

einfaches RF-Design verwendet, vergleichbar mit IrDA. Man ging beim Entwurf davon aus, 

dass sich ein Bluetooth-Sender/Empfänger fast immer in einem Mikroprozessor gesteuerten 

Endgerät befindet. Somit wurde die Steuerung und Fehlerkorrektur der Funkübertragung auf 

nachgeschaltete digitale Komponenten (Hardware und entsprechende Software) verlagert. 

Sehr geringe Leistungsaufnahme (und Sendeleistung) 

Um mobil zu werden, sollte die Leistungsaufnahme einer Bluetooth-Einheit, verglichen mit 

dem Host-Gerät, sehr klein sein um die Akkulaufzeit nicht unnötigerweise zu verringern. Dies 

wird durch die sehr geringe Sendeleistung im 2,4GHz-Band realisiert, wodurch der Einsatz in 

elektro-magnetisch-kritischen Umgebungen, wie z.B. in Kraftwerken, Krankenhäusern, 

Flugzeugen (Lufthansa), ermöglicht wird. 

1.1.4. Abgrenzung zu anderen Funkübertragungsstandards 

Im Bereich der drahtlosen Datenkommunikation gibt es mittlerweile diverse Standards, 

welche teilweise ein eigenes Einsatzgebiet besitzen und mit den anderen Standards nicht viel 

2

gemeinsam haben. In nachfolgender Tabelle wird eine Gegenüberstellung der vier wichtigsten 

Technologien Bluetooth, IrDA, IEE 802.11b und Home-RF gegenübergestellt. 

Bluetooth IrDA IEE802.11b Home RF 

Verbindungstyp Spread Spectrum Infrarot Spread Spectrum Spread Spectrum 

(Frequency 

(Freqency (Freqency 

Hopping) kleiner Hopping Hopping 

Winkel oder Direct oder Direct 

(max 30°) Seqence) Seqence) 

Spektrum 

Übertragungsleistung 

max. Datendurchsatz 

max. Reichweite 

(hindernisfrei) 

Sichtverbindung 

nötig 

Unterstütze 

Stationen 

Sprachkanäle 

Datensicherheit 

Adressierung 

ISM-Band 

1 mW 

1 Mb/s 

10 m 

Optisch, 850 

nm 

100 mW 

16 Mb/s 

(VFIR) 

0,7 m 

3 

ISM-Band 

100 mW 

11 Mb/s 

(bald 54 Mb/s bei 

802.11g) 

100 m 

ISM-Band 

100 mW 

2 Mb/s 

300 m 

nein ja nein nein 

8 pro Piko-Netz 

3 

Authentifizierung: 

128 Bit; 

(optional) 

Verschlüsselung: 

mit 8-128 Bit 

MAC-Adresse 

mit 48 Bit. 

AM_ADDR 

mit 3 Bit 

2 

1 

keine 

(enger 

Winkel, 

kleine 

Reichweite) 

Physikalische 

ID 

mit 32 Bit. 

Mehrere Geräte 

pro Access-Point; 

mehrere AP’s 

Netzwerk 

nur Voice over IP 

Authentifizierung: 

Challenge- 

Response 

über WEP; 

Verschlüsselung: 

standard 40 Bit, 

optional 128 Bit. 

MAC-Adresse 

mit 48 Bit. 

127 pro Netzwerk 

6 

Blowfish- 

Verschlüsselungsalgorithmus 

MAC-Adresse 

mit 48 Bit. 

Bemerkungen in Europa nicht 

durchgesetzt, 

in USA verbreitet 

Tabelle 1.1 – Vergleich Funkstandards 

Wie aus der Tabelle ersichtlich wird, steht der IrDA-Standard konkurrierend zum Bluetooth- 

Standard, doch hat dieser die „schlechteren Karten“, was durch die deutlich höhere 

Sendeleistung und den immer notwendigen Sichtkontakt, daraus resultierend nur eine Punktzu-Punkt-Verbindung 

möglich, begründet ist.

Im Gegensatz zu Bluetooth hat IEEE 802.11b (WLAN) grundsätzlich ein völlig anderes 

Einsatzgebiet. Bluetooth-Geräte verbrauchen weniger Strom und sind für die Übertragung 

geringer Datenmengen über kürzere Distanzen entwickelt worden - 

Kommunikationskabelersatz. WLAN dagegen bietet Verbindungen bis zu 54 Mb/s für 

breitbandige Kommunikation über Distanzen von mehreren hundert Metern. 

1.1.5. Verwendung der Bluetooth-Technologie 

Nutzbar ist Bluetooth für eine Vielzahl von Szenarien. So könnten z.B. alle Geräte im Büro 

ohne Kabelprobleme frei im Raum platziert werden. Sie bilden dann ad hoc ein so genanntes 

Piko-Netz. Das beschreibt die spontane Interaktion von bis zu 8 aktiven Geräten in der 

Reichweite eines dieser Geräte (dem Master). 

Bluetooth ist somit bereits heute eine etablierte Funktechnik für den Nahbereich, die die 

drahtlose Anbindung mobiler Endgeräte wie Notebooks, Drucker und Mobiltelefone 

ermöglicht, so dass sie untereinander Daten austauschen können. Aber auch andere Geräte, 

wie z.B. Headsets, Tastaturen und ähnliches, kann man mit dieser Technik ausstatten. 

Damit lassen sich künftig zwei der größten Hindernisse beseitigen, die gegenwärtig die 

Benutzerfreundlichkeit solcher Geräte für Kunden einschränken. Dies wären zum einen die 

herstellerspezifischen Anschlusskabel und zum anderen die notwendigen Einstellungen und 

Eingaben, die für den Aufbau der Kommunikation notwendig sind. Dies wird durch so zu 

nennende anwendungsspezifische Profile realisiert. 

1.2. Grundlagen Bluetooth 

In diesem Kapitel wird ein Überblick über die grundlegende Funktionsweise von Bluetooth 

anhand des Standard Bluetooth 1.1 gegeben. Auf Änderungen bezüglich des im November 

2003 veröffentlichten Standards 1.2 wird in einem späteren, hierauf aufbauenden Kapitel 

eingegangen. 

1.2.1. Fast Frequency Hopping - Verfahren 

Wie bereits einführend erwähnt wurde, arbeiten Bluetooth-Transceiver im lizenzfreien ISM- 

Frequenzband, dem ein Frequenzbereich von 2400 MHz bis 2483,5 MHz zugewiesen ist. 

Bei der Übertragung bedient man sich des Fast Frequency Hopping Verfahrens (FFH). Dabei 

wird das zur Verfügung stehende Frequenzband in 79 gleich große Kanäle à 1 MHz 

aufgeteilt, zwischen denen 1600 Mal pro Sekunde gewechselt wird. 

Abbildung 1.1 – Bluetooth-Kanäle im ISM-Band 

In wenigen Ländern z.B. Japan, Frankreich oder Spanien ist das verwendbare Band schmaler. 

Dieser Sonderfall ist im weltweiten Bluetooth-Standard berücksichtigt und führt zur Nutzung 

von nur 23 Kanälen. 

4

* with exceptions / mit Ausnahmen - Quelle: Bluetooth Core-Specification 1.1 

Abbildung 1.2 – nationale Frequenzbeschränkungen 

FFH bietet gegenüber anderen Verfahren drei entscheidende Vorteile: 

1. Größere Unempfindlichkeit gegenüber schmalbandiger Störstrahlung: 

Idealisiertes Beispielszenario: Ein Mikrowellenherd strahlt mit einer bestimmten Frequenz 

im 2,45Ghz-Bereich ab. Somit ist der Kanal mit dem entsprechenden Frequenzbereich 

durch die Mikrowelle gestört. Bei Bluetooth würde die Daten- oder Sprach-Übertragung 

nur für eine 1/1600 Sekunde (625µs) gestört bzw. unterbrochen sein, da es in 79 Kanälen 

das gesamte zur Verfügung stehende ISM-Band nutzt. 

Abbildung 1.3 – Schmalbandige Störung 

2. Höhere Datensicherheit: 

Die schnellen Frequenzwechsel und der dahinter stehende Algorithmus sind nur mit sehr 

aufwendiger Technik zu erfassen und schwer zu decodieren. 

3. Dominant gegenüber anderen Funkverbindungen: 

Da Bluetooth 1600 Mal pro Sekunde den Frequenzkanal wechselt, ist auch die 

Wahrscheinlichkeit, dass Bluetooth eine WLAN-Übertragung blockiert höher, als dass 

WLAN Bluetooth stört. Im praktischen Teil dieser Arbeit detailliert gezeigt. 

5

Als Modulationsverfahren kommt das Gaussian-Frequency-Shift-Keying (GFSK) zum 

Einsatz. Diese weiche, nebenwellenarme Frequenzumtastung erreicht durch das 

Zwischenschalten Gauss'scher Filter eine höhere spektrale Effizienz. 

Bluetooth unterstützt Voll-Duplex-Verbindungen durch Anwendung von Time Division 

Duplex (TDD). Die entstehenden Zeitfenster werden zyklisch von 0 bis 2 27 (Festlegung) 

durchnummeriert. 

Dabei ist festgelegt, dass der Master immer in den geraden (Master-to-Slave-Slot) und ein 

Slave in den ungeraden Zeitfenstern (Slave-to-Master-Slot) sendet. 

Der Informationsaustausch findet in Paketform statt, wobei jedes Paket hauptsächlich in 

einem eigenen Zeitschlitz, welcher genau zwischen zwei Frequenzsprüngen liegt, gesendet 

wird (single-slot packet). 

Abbildung 1.4 – Time Slots 

6 

Quelle: Bluetooth Core-Specification 1.1 

Große Pakete, zum Beispiel zum Datentransfer, können im ACL-Modus auch 3 oder 5 solcher 

Zeitschlitze einnehmen (multi-slot packet). In diesem Fall wird für das komplette Paket die im 

ersten Zeit-Slot festgelegte Frequenz zur Übertragung genutzt. Die Interferenz- 

Störanfälligkeit nimmt mit jedem Multi-Slot-Paket durch die resultierende Verringerung der 

Frequenzsprünge weiter zu.

1.2.2. Leistungsklassen 

Abbildung 1.5 – Multislot-Pakete 

7 

Quelle: Bluetooth Core-Specification 1.1 

Um unterschiedliche Senderadien für räumliche Netzstrukturen zu erzielen, wurden für 

Bluetooth-Geräte drei Leistungsklassen bezüglich ihrer Sendeleistung spezifiziert. Die für 

eine Verbindung zur Verfügung stehende maximale Senderate (von 1Mb/s) ist bei allen drei 

Leistungsklassen jedoch identisch. 

Folgende Übersicht stellt die drei spezifizierten Leistungsklassen, bezüglich der 

Sendeleistung und maximalen Reichweite, gegenüber: 

Bluetooth-Typ Sendeleistung max. Reichweite 

(optimale Bedingungen) 

Class 1 Geräte High 100 mW (20 dBm) 100 m 

Class 2 Geräte Medium 2.5 mW (4 dBm) 20 m 

Class 3 Geräte Low 1 mW (0 dBm) 10 m 

Tabelle 1.2 – Sendeleistungsklassen 

Die Class1-Version wird auch als „Long-Range-Bluetooth“ bezeichnet, doch die derzeit am 

meisten verbreitete Leistungsklasse ist die preiswertere und stromsparende Class3. 

1.2.3. Netztopologien 

Interagieren zwei Bluetooth-Systeme, kommunizieren sie in einer Punkt-zu-Punkt- 

Verbindung miteinander, indem ein Gerät die Rolle des Masters übernimmt. 

Sobald eine Interaktion von mehr als zwei Geräten erforderlich ist, spricht man von einem 

Piko-Netz. Dies wird ebenfalls von einem Master verwaltet bzw. kontrolliert, indem sich bis 

zu sieben aktive Slaves auf ihn synchronisieren (Sprungtakt und Sprungabfolge). 

Die maximale Anzahl an zusätzlich eingebuchten Slaves, inaktiv im so genannten Parkmodus, 

ist je Piko-Netz auf 255 technisch beschränkt.

Jedes Bluetooth-Gerät hat eine eindeutige Hardware-Adresse von 48 Bit Länge (MAC- 

Adresse), deren Aufbau nach dem IEEE 802 Standard geregelt ist. Durch die Bluetoothdevice-adress 

(BD_ADDR) des Masters wird die Frquenzsprung-Reihenfolge (frequency 

hopping sequence) und der channel access code abgeleitet, welcher ein Piko-Netz eindeutig 

identifiziert. Darüber hinaus bestimmt der Master anhand seiner hardwareinternen Systemuhr 

das Timing der Frequenzänderungen für die Sprungsequenz und kontrolliert den 

Datenverkehr auf dem Kanal mittels eines Polling-Verfahrens. 

Unbedingt erwähnt werden sollte, dass alle Bluetooth-Geräte identisch aufgebaut sind und 

lediglich ein Gerät als „Master“ bezeichnet wird, dass den Verbindungsaufbau zu einem bzw. 

mehreren anderen Geräten (dann Slaves genannt) initiiert hat. Im späteren Verlauf einer 

Kommunikation ist der Tausch der Master-Slave-Rollen theoretisch möglich, um zum 

Beispiel eine weggefallene Master-Einheit zu ersetzen und dessen Aufgaben zu übernehmen. 

Abbildung 1.6 – Vernetzungstopologien 

Ein Piko-Netz ist durch ein individuelles Hopping-Schema geprägt und stellt daher 

theoretisch die Möglichkeit der lokalen Überdeckung mehrerer Piko-Netze dar. Zwei 

wenigstens partiell überlagerte Piko-Netze können durch mindestens ein gemeinsam 

genutztes Gerät zu einem so genannten Scatter-Netz verbunden werden. Der Master eines 

Piko-Netzes kann also auch Slave eines anderen Masters des anderen Piko-Netzes. In diesem 

Falle muss er sich aber in Reichweite des anderen Masters befinden. Wiederum gibt es auch 

die Möglichkeit eines gemeinsamen Slaves beider Netze, wodurch es nicht zwingend 

notwendig ist, dass die beiden Master der zu verknüpfenden Netze direkt kommunizieren 

können. Es ist jedoch nicht ausführbar, dass ein Gerät die Master-Rolle mehrerer Piko-Netze 

übernimmt. 

Somit ist es unter anderem möglich: 

1. ein ausgelastetes Piko-Netz durch ein weiteres Teilnetz zu erweitern, 

2. zur Überbrückung von räumlichen Distanzen mehrere Netze zu kaskadieren, sowie 

3. mindestens ein Gerät von mehreren Netzen aus (mit deren Mastern in Reichweite) 

gemeinsam zu nutzen. 

Anwendungsszenarien zu den oben genannten möglichen Ausprägungen eines Scatter-Netzes 

wären: 

8

Zu 1.) In einem Büro sollen mehr als acht Bluetooth-Geräte miteinander 

kommunizieren (nicht im Parkmodus). Durch die Limitierung von maximal acht 

aktiven Teilnehmern pro Piko-Netz muss ein Slave für ein neues Piko-Netz, zur 

Integration der übrigen (maximal wiederum 7) Geräte, als Master bzw. Slave des 

neuen Netzwerkes fungieren. 

Zu 2.) Ein Scanner befindet sich außerhalb der maximalen Reichweite eines Piko- 

Netzes (sendeleistungsabhängige Distanz/Senderadius von Master zu Slaves), doch 

gibt es einen Slave dieses Netzes welcher in Reichweite zum Scanner liegt. In diesem 

Falle kann dieser Slave in einem neuen Piko-Netz als Master für den Scanner 

fungieren. 

Zu 3.) Zwei Büros, die ihre eigenen Piko-Netze betreiben, möchten auf einen 

gemeinsamen Drucker zugreifen. Das gemeinsam genutzte Gerät sollte für beide 

Parteien ein Slave sein, da es nicht zur Kommunikation zwischen zwei Netzen dienen 

soll, sondern lediglich von beiden Netzten aus verfügbar sein sollte. 

1.2.4. Adressierung und Statusmodi 

Einzelne Bluetooth-Geräte werden, wie in allen IEEE 802 kompatiblen Standards (Ethernet, 

Token Ring, WLAN), über eine weltweit eindeutige 48 Bit breite Adresse, die Bluetooth- 

Device Address (BD_ADDR) angesprochen. Weiterhin adressiert ein Master alle aktiven 

Einheiten eines Piko-Netzes über die Active Member Address (AM_ADDR) der Größe 3 Bit, 

wobei die „0“ dieses Adressraumes als Broadcast an alle aktiven Slaves verstanden wird. Alle 

nicht aktiven Geräte in einem Piko-Netz werden mit der 8 Bit breiten Parked Member 

Address (PM_ADDR) erreicht. 

Interessant ist noch, dass mehrere Betriebszustände für ein Bluetooth-Gerät existieren. 

Betriebsmodi 

Standby-Modus: Das Gerät ist nicht mit einem Piko-Netz verbunden. In diesem Modus 

ist der Energiebedarf des Gerätes äußerst gering, da nur der 

Mastertimer des Gerätes läuft. Der Standby-Modus wird nur durch ein 

Inquiry oder Paging eines anderen Masters aufgehoben oder durch die 

Station selber, wenn sie ein Inquiry einleitet, um andere Stationen zu 

finden. 

Inquire-Modus: Ein bisher nicht verbundenes Gerät ermittelt alle Bluetooth-Einheiten, 

die sich in Reichweite befinden. Dabei sendet es in vorgegebenen 

Zeitschritten seine Inquiry-Nachrichten aus und wartet auf Antwort. 

Page-Modus: In diesem Zustand befindliche Master will sich mit einem bestimmten, 

ihm bekannten (Device Access Code) Gerät verbinden. Ist er dann mit 

diesem Slave oder mehreren verbunden, begibt er sich in den 

Connected-Modus. 

Page Scan: Gerät horcht auf Paging eines Masters (in einem Scan Window nach 

eigenem Device Access Code). 

9

Zustände im Verbindungsmodus 

Connected-Modus: Ein Master hat eine Verbindung mit einem bzw. mehreren Slaves 

etabliert. 

Active-Modus: Ein Slave steht aktiv in Verbindung zum Master. 

Drei weitere Energiesparmodi stehen für den Fall zur Verfügung, dass ein Gerät die 

Verbindung zu einem Master bereits hergestellt hat, aber nicht mehr als aktives Gerät in der 

Verbindung benötigt wird. Der Hold-, der Sniff- und der Park-Modus unterscheiden sich 

beispielsweise hinsichtlich des Arbeitszyklus des Gerätes, d.h. in dem zeitlichen Abstand, in 

welchem das Gerät auf einen Masteraufruf "horcht". Damit lassen sich Erreichbarkeit und 

Stromverbrauch individuell beeinflussen. 

Sniff-Modus: Ein Slave lauscht in regelmäßigen Abständen, ob Aktivität im Piko- 

Netz vorhanden ist oder nicht, ob ein Paket für ihn ankommt oder nicht. 

Dies wird über folgende zwei Parameter kontrolliert: 

a) Sniff-Attempt (Sniff-Versuch) legt fest, wie viele Zeitschlitze der 

Slave belauschen muss, unabhängig davon, ob die Pakete für ihn 

bestimmt sind oder nicht. 

b) Sniff-Timeout bestimmt, wie viele Zeitschlitze noch zusätzlich 

belauscht werden müssen, wenn er ein Paket mit seiner Adresse 

im Header bekommen hat. 

Wenn ein Paket an seine Adresse adressiert wurde, dann antwortet das 

Slave-Gerät dem Master. 

In diesem Modus wird die zuvor zugewiesene Active Member Address 

beibehalten und der Stromverbrauch beläuft sich im Durchschnitt auf 

300 µA. 

Hold-Modus: Eine bestehende ACL-Verbindung zwischen 2 Bluetooth-Einheiten 

kann für eine bestimmte Zeit auf Hold gesetzt werden, wenn keine 

Notwendigkeit besteht Daten zu senden bzw. zu empfangen. Während 

dieser Zeit kann kein Paket empfangen werden. Die Datenübertragung 

kann bei Bedarf wieder aktiviert werden, indem der Slave von sich aus 

seinen Zustand wieder verlässt. Auch in diesem Modus bleibt die zuvor 

zugewiesene Active Member Adress bestehen und der Stromverbrauch 

liegt bei nur 60µA. 

Park-Modus: Ein Slave soll an einem Kanal nicht teilnehmen, aber immer noch über 

das Frequenzsprungverfahren synchronisiert bleiben. Wird ein Slave 

allerdings in den Park-Modus versetzt, so gibt er seine Active Member 

Address auf und eine eindeutige Parked Member Address wird ihm 

vom Master zugewiesen, die er benutzen wird, um den Slave wieder in 

den Active-Modus zu versetzen. Der Stromverbrauch liegt bei 

respektablen 30 µA. 

10

Die folgende Abbildung liefert einen zusammenfassenden Überblick über die bestehenden 

Betriebs-Modi eines Slaves, respektive Masters. 

Abbildung 1.7 – Betriebszustände 

Angemerkt sei, dass bis zum Inquiry noch keine Rollenvergabe stattgefunden hat. Wird ein 

aktiviertes Gerät Master, bleibt es immer im so genannten Connected Mode. 

1.2.5. Kanaltypen 

Die Verbindung zwischen dem Master und den Slaves kann, je nach Anwendung, in zwei 

verschiedenen Kanaltypen realisiert werden. Somit kann die mögliche Datenrate von 1 Mbit/s 

einer Verbindung zum Master auf bis zu 3 synchrone verbindungsorientierte Kanäle und 

einen asynchronen verbindungslosen Kommunikationskanal aufgeteilt werden: 

1.2.5.1. Synchronous Connection-Orientated (SCO): 

Dieser Übertragungs-Modus bietet eine symmetrische Punkt-zu-Punkt-Verbindung zwischen 

dem Master und einem ausgewählten Slave im Piko-Netz. Es erfolgt eine Reservierung von 

zwei Zeitschlitzen in regulären Zeitintervallen (einer für Vorwärts-, einer für Rückrichtung), 

wodurch eine leitungsvermittelte Verbindung zwischen Master und Slave ermöglicht wird. 

Die Spezifikation legt maximal 3 synchrone Kanäle mit je 64 kbit/s fest. Die Bandbreite für 

jeden Kanal ist fest reserviert und jeweils in Sende- und Empfangsrichtung gleich groß. 

SCO dient typischerweise der zeitkritischen Übertragung von isochronen Datenströmen wie 

zum Beispiel Sprache. Daher wird auf die Verwendung von Prüfsummen verzichtet. Es ist 

nicht sinnvoll verlorene oder fehlerbehaftete Segmente eines kontinuierlichen 

Sprachdatenstroms erneut zu senden. 

Bluetooth verwendet hierbei zwei verschiedene Arten von Sprachkodierung, mit denen es 

möglich ist, die menschliche Stimme zu digitalisieren: PCM (Pulse Code Modulation) und 

CVSD (Continuous Variable Slope Delta). 

Um die fixe Datenrate von 64kbit/s zu realisieren, werden unterschiedlich viel Information 

enthaltende Pakete in unterschiedlichen Zeitschlitz-Perioden gesendet. 

11

Type Audio- 

Information 

(Byte) 

Abbildung 1.8 – SCO-Paketperioden 

Payload 

(bit) 

FEC CRC Zeitschlitz- 

Periode 

HV1 10 240 1/3 no 2 

HV2 20 240 2/3 no 4 

HV3 30 240 no no 6 

DV 80 230 nur Datenfeld nur Datenfeld 16 

Tabelle 1.3 – SCO-Pakettypen 

Das DV-Paket kombiniert Daten und Sprache. Das Nutzdatenfeld ist in 80bit für Sprache und 

bis zu 150bit transparente Daten aufgeteilt, welches durch eine 16-bit-CRC und 2/3 FEC 

gesichert ist. 

1.2.5.2. Asynchronous Connection-Less (ACL) 

Dieser asynchrone verbindungslose Übertragungsmodus setzt auf eine paketorientierte Punktzu-Mehrpunkt-Verbindung 

auf. Dabei verfügt der ACL-Kanal über die Datenrate, die nach 

Abzug der maximal drei reservierbaren SCO-Datenraten von je 64 kbit/s verbleibt. Somit 

findet die ACL-Datenübertragung nur in den nicht für SCO reservierten Zeitschlitzen statt. 

12

Abbildung 1.9 – ACL-Pakete bei SCO-Verbindung 

Der Zugriff der Slaves auf den besagten Kanal wird vom Master durch ein implizites Polling- 

Verfahren kontrolliert. Empfängt ein Slave ein an ihn adressiertes Daten-Paket vom Master, 

dann wird er im nächsten freien Slave-to-Master-Slot das nächste Paket seiner anstehen Daten 

senden. Wenn ACL-Pakete nicht an einen dedizierten Slave adressiert sind, werden sie als 

Broadcast-Information für alle Slaves angesehen. Über den ACL-Kanal werden Nutzer- oder 

Steuerdaten übertragen. Folgende Pakettypen existieren: 

Abbildung 1.10 – ACL-Pakettypen 

13 

Quelle: Bluetooth Core-Specification 1.1

Abbildung 1.11 – ACL-Paketperioden 

1.2.6. Die Sicherheit bei Verwendung von Bluetooth 

Wie bei allen Funktechnologien ist es auch bei diesem Verfahren möglich den Datenstrom 

zwischen den kommunizierenden Einheiten abzuhören oder gar zu stören. Allein schon um 

eine Zulassung für das ISM-Band zu bekommen, muss jede Funktechnik von ihrer 

Konzeption her eine Abdeckung dieses gesamten Frequenzbands sicherstellen. Dies hat den 

Vorteil, dass Störungen von anderen ISM-Funkstandards (wie WLAN) nicht zur einer 

Nichtverwendbarkeit bei Überlagerung führen. Bei Bluetooth ermöglicht das genannte 

Frequenzsprungverfahren einen Wechsel zwischen allen national möglichen Frequenzkanälen 

und ist somit unanfällig gegen schmalbandige Störer, wie z.B. Mikrowellenöfen. 

Diese Robustheit ist auch zur Abwehr von nicht autorisierten Zugriffen auf den Datenverkehr 

hilfreich, da nur auf den Master synchronisierte Geräte der eindeutigen und einmaligen 

Sprungsequenz durch das gesamte Frequenzband folgen. Dies erfordert natürlich eine 

Anmeldung über eine nur den beiden Kommunikationspartnern bekannte ausreichend sichere 

PIN bei jedem Verbindungswunsch zu einem bisher noch nicht autorisierten Partner – 

Gerätepaarung oder Pairing. 

14

Abbildung 1.12 – Gerätepaarung (Schema) 

Jedes Bluetooth-Gerät authentifiziert sich mit seiner öffentlich zugänglichen weltweit 

eindeutigen, aber nicht fälschungssicheren MAC und kann somit immer wieder zugeordnet 

werden. 

Weiterhin ist es erforderlich seine Daten gegenüber anderen Teilnehmern auf der aktuell 

genutzten Frequenz zu verschlüsseln. Dies wird in Bluetooth optional mittels eines 

nichtstandardisierten Zufallsalgorithmus angeboten, ist aber nur auf die in den ACL-Paketen 

verpackten Nutzdaten beschränkt. Die Paket-Header müssen aufgrund der Adressierung im 

Pico- bzw. Scatter-Netz allen Teilnehmern zugänglich sein. 

Insgesamt werden drei Sicherheitsklassen (low, medium, high) im Bluetooth-Standard 

genannt. In der Stufe geringster Sicherheit kann jedes Bluetooth-Gerät mit jedem anderen in 

Verbindung treten und auf die auf dem anderen Gerät bereitgestellten Services zugreifen. BT- 

Einheiten, die höhere Sicherheitsstufen verwenden, lassen nur spezifizierte Geräte zur 

Anmeldung respektive autorisierte Zugriffe auf die Dienste zu. 

Hieraus lassen sich einige Empfehlungen zur besseren Sicherheit beim Einsatz von Bluetooth 

in der Datenkommunikation ableiten. Neben den allgemeinen Hinweisen, wie keine 

unsicheren Voreinstellungen oder zu erratende PINs zu verwenden und ähnliche Fehler zu 

begehen, sollte bei Bluetooth die Sendeleistung sowie die freigegebenen Dienste 

weitestgehend eingeschränkt werden. Gegen bekannte Sicherheitslücken, wie z.B. 

Bluejacking, einen Text auf das Display eines gefundenes Geräts in Reichweite senden, oder 

unbekannte Angriffe, z.B. durch manipulierte Geräteadressen (Spoofing), kann sich der 

Anwender, neben dem Abschalten der Bluetooth-Funktionen, nur schwer schützen. 

15

1.3. Standards und Evolution 

1.3.1. Einleitung 

In diesem Kapitel soll auf die allgemeine Standardisierung der Bluetooth-Technologie näher 

eingegangen werden. Dabei steht die Entwicklung der verschiedenen aufeinander folgenden 

Bluetooth-Kernspezifikationen im Mittelpunkt der Betrachtungen. Es sollen grundlegende 

Eigenschaften und Verbesserungen bzw. Anpassungen an neue Aufgaben vorgestellt werden. 

1.3.1.1. Wozu sind Standards nötig? 

Standards sind zwingend notwendig um eine Kompatibilität zwischen Produkten 

verschiedener Hersteller für einen sehr langen Zeitraum, und dies möglichst weltweit, 

herzustellen. Aus der Sicht der Käufer von standardisierten Produkten bedeuten diese 

Festlegungen eine Ungebundenheit an einen bestimmten Hersteller und somit die freie 

Auswahl von gleichartigen Produkten anderer Hersteller auf dem Markt. 

Kurz gesagt: Nur in einer standardisierten Form kann sich die Bluetooth-Technologie als ein 

drahtloser Kabelkiller etablieren bzw. gegenüber anderen „short-distance“-Funktechnologien 

durchsetzen. 

1.3.1.2. Wer macht die Standards bei Bluetooth? 

Allgemein werden folgende Typen von Standards unterschieden: 

• Internationale Standards 

• Nationale Standards 

• Empfehlungen (Recommendations) 

• Request for Comments (RFC) 

• Industriestandards (durch Herstellervereinigung) 

Der lizenzfreie Bluetooth-Standard reiht sich in die Gruppe der Industriestandards ein, da 

dessen Festlegungen in einem Zusammenschluss zahlreicher interessierter Firmen, in der 

sogenannten „Bluetooth Special Interest Group“ (Bluetooth SIG), getroffen werden. 

Diese Spezifikation schreibt nur vor, wie sich Bluetooth-Geräte verhalten sollen, wobei die 

konkrete Realisierung den Herstellern selbst überlassen ist. 

Die 1998 gegründete SIG hat inzwischen in vier Kategorien insgesamt über 2000 Mitglieder, 

darunter die fünf Initiatoren: Ericsson, Nokia, Toshiba, Intel und IBM. 

Im Rahmen der einheitlichen Entwicklung des Funkverbindungssystems und Bildung eines 

breiten Produktspektrums umfasst der Aufgabenbereich des Bluetooth-Konsortiums: 

• die Spezifizierung des Protocol-Stacks und der Anwendungsprofile, 

• die Veranstaltung von Entwicklertreffen, 

• das Marketing und 

• die Sicherstellung der Interaktion von Geräten verschiedener Hersteller (Certification) 

Letzterer Punkt wir durch eine Konformitätsprüfung, nach Kriterien der Bluetooth-SIG 

erzielt. Die so genannte Bluetooth-Qualification kann bei berechtigten Dienstleistern, wie 

beispielsweise in Deutschland der Firma 7layers, erfolgen. Somit darf ein Hersteller sein 

16

Produkt (Hardware bzw. Software) erst nach bestandener Prüfung mit dem geschützten 

Bluetooth-Logo versehen und als Bluetooth-zertifiziert ausgeben. 

Für tiefgründigere Informationen über die Bluetooth-SIG, deren Vorgehensweise bei der 

Standardisierung und die vier Mitgliederkategorien wird auf die Homepage des Konsortiums 

verwiesen: � https://www.bluetooth.org/admin/bluetooth2/faq/search_faq.php 

1.3.2. Die Standards im Überblick 

Vorweg sei angemerkt, dass die Gegenüberstellung der Entwicklungsstufen des Bluetoth- 

Standards sich trotz ausgedehnter Recherche in Detailfragen als sehr schwierig erwies, da 

speziell zu den Versionsunterschieden kaum detaillierte Informationen zu finden waren. In 

themenrelevanten Quellen fanden sich in Abschnitten zu eigentlich vergleichbaren Passagen 

teils starke Widersprüche. Außerdem war die Glaubwürdigkeit der meisten unabhängigen 

Ausarbeitungen zum Thema meist fragwürdig. 

Auch die Inhalte der Archive offizieller Informationsseiten sind in Bezug auf die Darstellung 

aufgetretener Probleme und deren Lösungen oft unzureichend dokumentiert. Es wird meist 

nur mit der Einführung des nachfolgenden verbesserten Standards durch Auflisten 

verkaufsfördernder Begriffe geworben. So konnte z.B. zu den bekannten anfänglichen 

Kompatibilitätsproblemen zwischen Bluetooth-Geräten unterschiedlicher Hersteller, kein 

direktes Statement oder gar eine Erörterung gefunden werden. In dem öffentlichen Online- 

Forum der SIG-Homepage konnte in der Zeit der Recherche leider auch keine Information 

dazu erworben werden. Nur durch zeitaufwendiges Vergleichen der detailreichen 

Spezifikationsbeschreibungen könnten spezifische Änderungen identifiziert werden. Erst in 

der Dokumentation zum Standard 1.2 findet sich ein Abschnitt über die aktuellen technischen 

Neuerungen. 

1.3.2.1. Bluetooth 1.0a und 1.0b 

Nach der Gründung der Bluetooth Special Interest Group im Februar 1998 folgte im Mai des 

gleichen Jahres die offizielle Bekanntgabe des Bluetooth-Projekts. Diese viel versprechende 

Ankündigung führte in ihrer Art und Weise zu entsprechend hohen Erwartungen an den 

Kabelkiller. Am 26. Juli 1999 wurde auf der Homepage der SIG die Spezifikation des ersten 

offiziellen Standards, Bluetooth 1.0a, veröffentlicht. 

Diese Gesamtspezifikation ist in zwei Teilabschnitte unterteilt: 

„Core Specification (Volume I)“ In der Kernspezifikation werden die Grundfunktionen 

der Bluetooth-Geräte und deren Kommunikation über 

Protokolle, sowie die Anbindung an Hosts und 

einheitliches Fachvokabular festgelegt. 

„Profile Definitions (Volume II)“ Hier werden Festlegungen für die Profile getroffen, 

welche in dieser Arbeit nicht näher erläutert werden. 

Der Bluetooth-Standard 1.0a wird durch folgende Basis-Eigenschaften (Kernspezifikation), 

auf welche bereits im Kapitel Funktionsweise näher eingegangen wurde, charakterisiert: 

• FFH mit 1600 Sprüngen je Sekunde und TDD 

• Bruttotransferrate von 1 Mbit/s 

• ACL/ SCO-Übertragungen 

17

• Drei Sendeleistungsklassen (1mW, 2,5mW und 100mW) 

• Piko-Netz- (Master mit bis zu 7 Slaves) und Scatter-Netz-Topologie 

• zusätzliche Sicherheitsmaßnahmen 

Die Erwartungen der Interessenten wurden bei weitem nicht erfüllt, da zum Zeitpunkt der 

Vermarktung die Entwicklungen noch nicht weit genug gediehen waren. Hauptursachen 

waren Fehler bei der Kompatibilität, der Implementierung von Piko-Netzen bzw. Scatter- 

Netzen, sowie einer eindeutigen Master-Slave-Zuweisung zwischen den Geräten. 

Man konnte nicht von marktreifen Produkten sprechen, da es kaum Geräte verschiedener 

Hersteller auf dem Markt gab, die miteinander kommunizieren konnten. 

Nach nur sechs Monaten folgte am 1. Dezember 1999 ein überarbeiteter Bluetooth-Standard 

der Version 1.0b, welcher leider auch die grundlegenden Probleme der ersten offiziellen 

Version nicht lösen konnte. 


Durch die teils schwerwiegenden Probleme von Bluetooth 1.0a und 1.0b blieb der ersehnte 

Durchbruch dieser „short-distance“-Funktechnologie aus. Die ganze Hoffnung der Bluetooth- 

SIG lag nun auf dem neu überarbeiteten Standard Bluetooth 1.1, welcher genau ein Jahr 

später, am 1. Dezember 2000 veröffentlicht wurde. Dieser ist nicht abwärtskompatibel zu den 

Vorgängerversionen 1.0a und 1.0b, obwohl die bereits erwähnten Basis-Eigenschaften 

beibehalten wurden. Die besagten Probleme der Vorgängerversionen wurden weitestgehend 

behoben, doch die Implementierung der Scatter-Netze ist noch nicht fehlerfrei bzw. nicht 

vollständig spezifiziert. 

Es wurden auch weitere Profile festgelegt. Die Vorgänger-Standards von Bluetooth 1.1 

waren, in Bezug auf die Profile, lediglich als Kabelersatz, z.B. zwischen PC und 

Peripheriegeräten, gedacht. Die erweiterten Profile waren weitestgehend für die Übertragung 

von Bildern, Video-Clips oder HiFi-Audio-Signalen gedacht, die das Anwendungsspektrum 

dieser viel versprechenden Übertragungstechnologie deutlich vergrößerten. 

Durch die von der SIG verbesserte Interoperabilität zwischen Geräten verschiedener 

Hersteller und die nun erweiterte multimediale Anwendungsvielfalt, konnte sich Bluetooth als 

Funk-Übertragungstechnologie allmählich etablieren. Auf dem Markt konnte man zunehmend 

Produkte von Herstellern finden, die nun auf diese Technologie setzten. 

Ein Meilenstein für die Akzeptanz dieses Funk-Übertragungsstandards war der Ende März 

2002 vereinbarte Lizenzvertrag zwischen der Bluetooth-SIG und dem IEEE, welcher auf der 

Kernspezifikation der Version 1.1 beruht. Die Arbeitsgruppe 802.15 des Institute of Electrical 

and Electronics Engineers (IEEE) erkannte dieser Technik den Rang eines IEEE-Standards 

zu, der in so genannten Wireless Personal Area Networks (WPAN) zum Zuge kommen soll. 

Von diesem Zeitpunkt an kann man von einer Zusammenarbeit der beiden Einrichtungen, 

bezüglich der Weiterentwicklung des WPAN-Standards, sprechen. 


Am 5. November 2003 ist nun der durchaus als robust zu bezeichnende Standard Bluetooth 

v1.1 durch die derzeit aktuelle Version 1.2 abgelöst worden. Die neue Spezifikation führt 

vorwiegend neue Features bzw. Verbesserungen vorhandener mit sich, welche den Betrieb in 

der Praxis reibungsloser gestalten. Bei der Entwicklung dieser Nachfolgergeneration flossen 

etliche Empfehlungen des Institute of Electrical and Electronics Engineers (IEEE) ein. 

18

Folgend aufgeführte neue Merkmale sind prägend für Bluetooth 1.2 und werden anschließend 

näher erläutert: 

• Enhanced Quality of Service (eQoS) 

• Verbesserter Verbindungsaufbau 

• Neuer Übertragungsmodus eSCO 

• Interferenzminimierung durch AFH 

• Abwärtskompatibilität zu Bluetooth 1.1 

• Anlehnung der Wortwahl an IEEE 

• Grundlegende Umstrukturierung/Umpartitionierung des Inhalts der Spezifikation 

(um Übersicht/Änderbarkeit/Protocols and Core) 

• Zeitgleiche Verabschiedung und Streichung nicht benötigter Profile 

• Anonymity Mode 

1.3.2.3.1. eQoS 

Mit „Enhanced Quality of Service“ soll, laut der SIG, eine leistungsfähigere Punkt-zu- 

Multipunkt-Anwendung ermöglicht werden. 

Im Gegensatz zu dem implementierten QoS der Vorgängerversionen können nun zwischen 

dem Master und mehreren Geräten Prioritäten zugewiesen werden. Somit wird die 

gleichzeitige Bedienung mehrerer Clients, durch ein besseres Verkehrs-Management, 

optimiert. 

Sind beispielsweise ein Drucker und ein Lautsprechersystem via Bluetooth mit einem PC 

(Master) verbunden, kann durch eine Prioritätenvergabe eine unterbrechungsfreie 

Musikwiedergabe erfolgen, während der Drucker kurzfristig auf Daten verzichten muss. 

1.3.2.3.2. Verbesserter Verbindungsaufbau 

Laut der Vorgängerspezifikation v1.1 mussten innerhalb von 4 Sekunden 80 Prozent aller 

Geräte gefunden werden, die sich in Reichweite des suchenden Geräts befinden. Mit der 

Version Bluetooth 1.2 sollen nun alle im Umkreis befindlichen Geräte innerhalb von ca. 2 

Sekunden entdeckt werden. 

Weiterhin hat man den Zeitbedarf des Verbindungsaufbaus zwischen zwei Geräten von 1 

Sekunde auf eine 1/10-Sekunde reduziert - Enhanced Synchronization Capability. 

Weiterhin wurden Flusskontrolle und Fehlererkennungsmechanismen durch verschiedene 

Maßnahmen verbessert. In der Spezifikation werden nur Begriffe wie „Enhanced Error 

Detection and Flow Control“ sowie „Enhanced Flow Specification“ genannt. 

1.3.2.3.3. Neuer Übertragungsmodus eSCO 

Mit eSCO (Extended Connection Orientated) ist nun, neben dem normalen SCO, ein zweiter 

verbindungsorientierter Übertragungsmodus spezifiziert worden. Beide Modi zeichnen sich 

durch eine logische Punkt-zu-Punkt-Verbindung zwischen einem Master und einem 

bestimmten Slave aus. 

Die Verbindung kann ebenfalls als leitungsvermittelt angesehen werden, da ähnlich dem 

SCO-Übertragungsmodus eine Reservierung von Zeitschlitzen erfolgt. Doch im Gegensatz 

zur normalen SCO-Übertragung bietet eSCO zusätzlich eine begrenzte Retransmission 

defekter oder nicht angekommener eSCO-Pakete. 

19

Ist eine Retransmission erforderlich, findet diese in einem so genannten Retransmissions- 

Fenster statt (mehrere Zeitschlitze), welches sich unmittelbar hinter den reservierten 

Zeitschlitzen befindet. Innerhalb des Retransmissions-Fensters wird das gleichartige Polling- 

Verfahren verwendet, wie es auf dem ACL-Kanal Anwendung findet: ein Slave darf erst auf 

dem eSCO-Kanal (im Slave-zu-Master-Zeitschlitz) sein Paket senden, wenn er unmittelbar 

zuvor ein an ihn adressiertes Paket vom Master (Master-zu-Slave-Zeitschlitz) erhalten hat. 

Sollten Zeitschlitze eines Retransmissions-Fensters nicht für die erneute Versendung von 

eSCO-Paketen benötigt werden, stehen sie für den anderen Daten-Verkehr zur Verfügung. 

Darüber hinaus bietet das erweiterte SCO gegenüber dem normalen SCO eine flexiblere 

Kombination von Pakettypen und Dateninhalten, des Weiteren wählbare Perioden für die 

reservierten Zeitschlitze, wodurch eine Unterstützung diverser synchroner Bitraten erfolgen 

kann. 

Folgende eSCO-Pakete sind definiert und können sowohl für die 64kbit/s-Sprachübertragung 

als auch für den transparenten Datentransport mit 64kbit/s oder einer anderen Bitrate genutzt 

werden: 

EV3 - variable Paketgröße zwischen 1 und 30 Byte und zusätzlich 16 Bit CRC 

- keine FEC 

- Paket darf maximal einen Zeitschlitz einnehmen 


- 2/3 FEC 

- Paket darf maximal drei Zeitschlitze einnehmen 


- keine FEC 

- Paket darf maximal drei Zeitschlitze einnehmen 

Angemerkt sei, dass bei den herkömmlichen SCO Datenpaketen grundsätzlich fixe 

Paketgrößen definiert sind, welche auch nur einen Zeitschlitz einnehmen dürfen und auch 

keine CRC-Fehlererkennung beinhalten. 

Die beim Verbindungsaufbau ausgehandelte Bandbreite eines eSCO-Kanals ist fest reserviert 

und kann in Sende- und Empfangsrichtung entweder gleich groß (symmetrisch) oder 

unterschiedlich groß (asymmetrisch) ausfallen. Letzteres wird vom bekannten SCO nicht 

unterstützt. 

20 

Quelle: Bluetooth Core Specification 1.2 

Abbildung 1.13 – Symmetrischer Datenverkehr

21 

Quelle: Bluetooth Core Specification 1.2 

Abbildung 1.14 – Asymmetrischer Datenverkehr 

Fazit: 

In der Praxis bedeutet der neu spezifizierte Übertragungsmodus eSCO eine verbesserte und 

flexiblere Übertragung, welche (begrenzte) Retransmissionen mit einem sehr geringen 

„Echtzeit-Verlust“ bietet. 

1.3.2.3.4. Interferenzminimierung durch AFH 

Die Zunahme von Funkfrequenztechniken, welche sich des gemeinsam genutzten ISM-Bands 

(2,4GHz) bedienen, führt zu einem Problem – Interferenzen zwischen parallel eingesetzten 

Techniken. 

Bluetooth-Geräte, die das herkömmliche Frequenzsprung-Verfahren (Frequency Hopping) 

nutzen, merken aufgrund ihrer robusten Modulation wenig vom benachbarten Funkverkehr, 

aber beeinträchtigen diesen spürbar. In diesem Zusammenhang sollte der Funkstandard 

WLAN (IEEE 802.11b) genannt sein, welcher teils starke Leistungseinbußen durch Bluetooth 

hinnehmen muss. Häufig findet dieser seinen Einsatz in Umgebungen, wo auch Bluetooth- 

Geräte parallel kommunizieren. Ein Beispielszenario wäre ein Laptop, der mittels WLAN 

eine Internetverbindung herstellt und Druckaufträge via Bluetooth an einen Drucker sendet. 

Neben dem Aspekt, dass diese Bluetooth-Übertragungen Interferenzen verursachen, werden 

auch sie durch Interferenzen gestört. Daraus folgt beispielsweise ein Einbruch des 

Datendurchsatzes im ACL-Modus, verursacht durch die häufige Retransmission von verloren 

gegangenen oder defekten Datenpaketen. Ein weiteres Beispiel ist die Audio-Übertragung 

(SCO) über ein Bluetooth-Headset. Hierbei machen sich Interferenzen durch ein teilweise 

unangenehmes Rauschen im Kopfhörer bemerkbar.

Quelle: „carmeq - Introduction to Bluetooth“ 12.06.2003 [19] 

Abbildung 1.15 – Beispiel: WLAN und BT v1.1 Interferenzen 

Auf diese Problematik hat das Herstellerkonsortium reagiert und stellte ein Verfahren namens 

Adaptive Frequency Hopping AFH vor, worauf am Ende dieser Arbeit in einem gesonderten 

Kapitel eingegangen wird. Mit AFH soll eine Kommunikation von Bluetooth-Geräten 

erfolgen, welche Rücksicht auf andere benachbarte Funktechnologien nimmt und fest 

genutzten Frequenzbändern von schmalbandigen Störungen ausweicht. 

1.3.2.3.5. Abwärtskompatibilität zu Bluetooth v1.1 

Der neue Standard soll abwärtskompatibel zu Bluetooth 1.1 sein, verspricht das Bluetooth- 

Herstellerkonsortium. Doch kann ein Gerät der Version 1.1 nicht in einem Piko-Netz der 

neuen Generation als Master agieren. Diese Einschränkung ist durch das neue adaptive 

Frequenzsprungverfahren begründet. 

1.3.2.3.6. Anlehnung der Wortwahl an IEEE 

Viele Teilabschnitte von vorangegangenen Bluetooth-Spezifikationen erschwerten den 

Lesern, durch eine unpräzise oder inakkurate Wortwahl, das Herauslesen wichtiger 

Informationen. Durch die Anlehnung der Wortwahl an die Empfehlungen der IEEE kann nun 

deutlich vereinfacht zwischen zwingend notwendigen Implementierungsinformationen und 

Hintergrundinformationen differenziert werden. 

Nähere Informationen dazu können 

- in der Bluetooth 1.2 Core-Specification auf Seite 149 

22

- und im IEEE Style Guide ( http://standards.ieee.org/guides/style/ ), welcher als 

Grundlage für die Verbesserung der Wortwahl diente, 

nachgeschlagen werden. 

1.3.2.3.7. Grundlegende Umstrukturierung 

Die grundlegende Umstrukturierung der Gesamtspezifikation besteht aus zwei wesentlichen 

Punkten: 

1. Flexiblere Spezifizierung von Profilen und Protokollen 

Wie bereits im entsprechenden Abschnitt erwähnt, bestand die Bluetooth- 

Gesamtspezifikationen der Versionen 1.0x und 1.1 aus zwei Hauptteilen, Core- 

Specification (Volume I) und Profile Definitions (Volume II), welche immer gleichzeitig 

und zusammenhängend publiziert wurden. 

Nach der Veröffentlichung von Bluetooth 1.1 bestand die Notwendigkeit einer flexibleren 

Spezifizierung und Veröffentlichung neuer bzw. verbesserter Profile und Protokolle, 

welche zeitlich unabhängig von der Publikation der Core-Specification erfolgen kann. 

Man beschloss die Profile und die Protokolle (welche nicht Bestandteil der 

Kernspezifikation sind) als jeweils einzelne Teilspezifikationen zu führen, welche mit 

einer Versionsnummer versehen sind, die mit jeder Änderung erhöht wird. Mit diesem 

Schritt ermöglicht die SIG ein Hinzufügen und Abändern von Profilen und Protokollen zu 

jeder Zeit. 

2. Restrukturierung der Bluetooth-Core-Specification 1.2 

Der Inhalt dieser derzeit aktuellen Kernspezifikation ist in einer deutlich veränderten 

Struktur dargestellt, welche eine bessere Folgerichtigkeit und Lesbarkeit sicherstellen soll. 

Die wichtigsten Umstrukturierungen fanden im Bereich Baseband, LMP, HCI und L2CAP 

statt, wobei die Information in einer logischeren Reihenfolge präsentiert wird, als es bei 

den Vorgängerversionen der Fall war. Diese Restrukturierung fiel uns bei unserer 

Recherche als sehr positiv auf. 

1.3.2.3.8. Verabschiedung neuer Profile 

Zum Zeitpunkt der Veröffentlichung der Bluetooth-1.2-Kernspezifikation wurden fast 

zeitgleich eine Reihe weiterer Profile definiert, welche der Funktechnik neuen Schub 

verleihen könnte. Drei neue Profile, darunter das „Advanced Audio Distribution Profile“ 

(A2DP), gelten der Verbesserung von Audioanwendungen. Damit sowie mit Hilfe von 

Kompression lassen sich Stereosignale mit hoher Qualität übertragen. Des Weiteren 

verabschiedete die SIG das „Audio/Video Remote Control Profile“, das für die 

Fernsteuerung von Audio- und Videogeräten ausgelegt ist. 

Neu sind auch das „Hands Free Profile“ (HFP) und das „SIM Access Profile (SAP)“, die auf 

den Automarkt zielen: Damit können Fahrzeug-Freisprecheinrichtungen Handys kontrollieren 

bzw. Profile und Adressen eines Mobiltelefons an das Autotelefon überwiesen werden, ohne 

dass hierzu die SIM-Karte gewechselt werden muss. 

1.3.2.3.9. Anonymity Mode 

In der Version 1.2 gibt es die Möglichkeit, ein Bluetooth-Gerät im so genannten Anonymity 

Mode zu betreiben. Dieser ist ein optionales Sicherheitsmerkmal, welches vom Hersteller 

angeboten werden kann, und verbirgt die eigentliche MAC-Adresse. Es wird, z.B. zum 

23

paarweisen Datenaustausch, eine zufällig ermittelte fiktive Adresse gleichen Formats 

verwendet, welche dann auch periodisch neu generiert wird. Da die Kern-Spezifikation keine 

Festlegungen hierzu trifft, ist es den Herstellern überlassen wie diese Möglichkeit 

implementiert wird. 

1.3.2.4. Ausblick auf Bluetooth 2.0 

Im Rahmen eines Bluetooth-Kongresses, welcher Mitte Juni 2003 stattfand, sickerten erste 

Details zu den bislang sorgsam gehüteten Spezifikationen der Bluetooth-Version 2.0 durch. 

Es wird erwartet, dass Bluetooth 2.0 mit Bruttotransferraten von bis zu 4, 8 und 12 Mb/s, bei 

gleich bleibender Reichweite, operieren soll, was ihm den Beinamen Highrate einbringt. 

Die neue Spezifikation 2.0 bietet ebenfalls neue Kommunikationsmodi, welche auf dem 

derzeit verwendeten System aufbauen. Sie ermöglichen, durch Nutzung eines 

Schmalbandkanals unter Verzicht auf Bandspreizung sowie von verteilten MAC-Protokollen, 

schnellere Antwortzeiten und eine integrierte QoS. Dieses neuartige verteilte Protokoll dient 

der Verminderung derzeit bestehender Probleme hinsichtlich der Master/Slave-basierten Piko- 

Netze, wobei aus dem Verlust des Masters ein Zusammenbruch des Piko-Netzes resultiert. 

Bluetooth 2.0 verzichtet auf die Master-Rolle und erhebt jede Einheit zum so genannten 

Supervisor, wodurch eine kontinuierliche Kommunikation innerhalb des Piko-Netzes 

ermöglicht wird. Des Weiteren soll es eine Broadcast- bzw. Multicast-Unterstützung bieten. 

Die neuen Fähigkeiten sind allerdings mit einer gegenüber Bluetooth 1.0 verdoppelten 

Stromaufnahme zu bezahlen. Bei der Entwicklung wird die Kompatibilität bzw. paralleler 

Einsatz zu den „low-rate“-Versionen ab 1.1 angestrebt. 

1.3.3. Bluetooth in der IEEE 

Das 1963 gegründete Institute of Electrical and Electronics Engineers (IEEE) ist ein Gremium 

für Normungen in elektrischen und elektronischen Verfahren, deren weltweit mehr als 

360.000 Mitglieder sich in erster Linie ebenfalls aus Herstellern sowie 

Forschungseinrichtungen rekrutieren. 

In diversen Arbeitsgruppen ist das IEEE eine der führenden Organisationen bezüglich der 

Standardisierung auf dem Gebiet der Raumfahrt, Computer und Telekommunikation, 

biomedizinischen Ingenieurstechnik, elektrischen Energie und elektronischen Geräten. 

Einer der bekanntesten und wichtigsten Interessenbereiche des IEEE ist das IEEE 802 

LAN/MAN Standards Committee, auch LMANSC genannt, welches sich mit der 

Standardisierung für Kommunikations-Netzwerke beschäftigt. Es wurde um 1980 aus der 

Notwendigkeit gegründet, die Vielfalt aller möglichen Netzwerk-Systeme, z. B. in der 

Verkabelung, der Übertragungsgeschwindigkeit und -technik zu standardisieren. Seine Arbeit 

beschränkt sich zum größten Teil auf die zwei untersten Schichten des bekannten ISO/OSI- 

Modells. 

Die IEEE 802 ist hierarchisch in Arbeitsgruppen unterteilt. Einige wichtige seien hier 

genannt: 

• IEEE 802.3 Ethernet / CSMA/CD-Zugriffsverfahren 

• IEEE 802.11 WLAN – Wireless Local Area Network 

• IEEE 802.15 WPAN – Wireless Personal Area Network 

Letzt genannte Arbeitsgruppe befasst sich mit kabelloser Nahbereichskommunikation, z.B. 

für portable Geräte wie PDAs. Das Ziel ist auch hier, Standards, Empfehlungen und 

Anleitungen auszuarbeiten, welche die Gesichtspunkte der Interoperabilität und Koexistenz 

24

zu anderen Datenübertragungs-Standards sicherstellen sollen. In den Bereich von WPAN 

reiht sich neben anderen die Bluetooth-Technologie ein. Sie wurde, aufgrund eines 

Lizenzabkommens zur Kompatibilität zwischen Bluetooth-SIG und IEEE, im März 2002 mit 

dem Standard 1.1 in den Rang eines IEEE-Standards erhoben. Diese Zusammenarbeit teilt 

sich generell in die Aufgabenfelder technische Weiterentwicklung und Integration der 

Bluetooth-Technologie seitens der Bluetooth-SIG und Prüfung nach eigenen Kriterien und 

Entwicklung von Änderungsempfehlungen seitens der zuständigen IEEE 802.15 Task Groups 

(TG). Die TGs bearbeiten jeweils eine spezielle Aufgabe. 

Die TG IEEE 802.15.1 hat den Bluetooth-Standard 1.1 geprüft und in die IEEE- 

Spezifizierungen übernommen. Die Übernahme erfolgte auf Basis der Kernspezifikation, 

welche die physikalische Schicht, in diesem Fall RF, und die MAC-Layer, die das Baseband, 

das L2CAP sowie das LMP umfasst. Weiterhin wurde ein Satz von allgemeinen SAPs 

entwickelt, welche das auf die MAC-Schicht aufsetzende ISO/IEC 8802-2 LLC ermöglicht. 

Der bereits von der Bluetooth-SIG verabschiede Standard 1.2 soll durch die TG IEEE 

802.15.1a eingegliedert werden. 

Mit der Sicherstellung der Koexistenz von IEEE 802.15 WPAN und IEEE 802.11 WLAN 

befasst sich die TG IEEE 802.15.2. Diese Expertengruppe entwickelt Koexistenz- 

Mechanismen für Transceiver, wodurch gegenseitige Interferenzen von WLAN und WPAN 

ausgeschlossen werden sollen. Bei Entwicklung eines Interferenz-minimierenden 

Übertragungsverfahrens (AFH) für Bluetooth 1.2, durch die Bluetooth-SIG, flossen 

Empfehlungen von dieser Task-Group mit ein. 

1.4. Bluetooth-Protokollstapel 

1.4.1. Einleitung 

Der Aufbau der Protokollarchitektur des Bluetooth-Standards folgt der Grundidee der 

kabelersetzenden Funkdatenübertragung und orientiert sich auch am bekannten ISO/OSI 

Schichtenmodell. Daher wurden die verwendeten Protokolle nach der besten Verwendbarkeit 

für eben diese Aufgabe entworfen bzw. übernommen. Der gesamte Protokollstapel für 

Bluetooth-Verbindungen kann in vier Hauptgruppen nach ihren allgemeinen Aufgaben 

eingeteilt werden. Diese sind, wie auch in folgender Tabelle verdeutlicht, die Bluetooth-Kern- 

das Kabelersatz-, die Telefonie-Steurungs- und weitere aufgesetzte anwendungsspezifische 

Protokolle. 

Schicht Protokoll 

Bluetooth Kernprotokolle Baseband, LMP, L2CAP, SDP 

Cable Replacement 

Protocol 

RFCOMM 

Telefonie TCS-bin, AT-Kommandos 

Aufgesetzte Protokolle PPP, UDP/TCP/IP, OBEX, WAP, vCard, vCal, IrMC, WAE 

Tabelle 1.4 – Die Protokolle und Schichten im Bluetooth-Protokoll-Stapel 

25

Der der komplette Stapel enthält zwei Kategorien von Protokollen. Zum einen die Bluetoothspezifischen 

wie LMP (Link Manager Protocol) und L2CAP (Logical Link and Control 

Adaption Protocol), und zum anderen die nichtspezifischen wie OBEX (Object Exchange 

Protocol) und UDP (User Datagram Protocol). Um einen einfachen und wenig aufwendigen 

Standard zu schaffen, wurden für die höheren Schichten bereits vorhandene und erprobte 

Protokolllösungen verwendet. Diese Wiederverwendung existierender Protokolle hilft vor 

allen Dingen den bereits existierenden Applikationen die Bluetooth-Technologie einzubinden. 

Der Integrationsaufwand wird damit erheblich verringert. Da die Spezifiktion von Bluetooth 

offen und allen frei zugänglich ist, steht es allen Entwicklern frei, sie zu verwenden. 

1.4.2. Die Protokolle der Bluetooth-Architektur 

Die Bluetooth-Kernprotokolle (Core) umfassen alle Bluetooth-spezifischen Protokolle, die 

von der Bluetooth SIG entwickelt wurden. RFCOMM und TCS wurden auch von dieser SIG 

entwickelt, basieren aber auf ETSI TS 07.10 und der ITU-T Recommendation Q.931. Diese 

Protokolle und Bluetooth-Radio, als physikaliche Realisierung, sind die wichtigsten und somit 

der Kern des Standards. Sie sind in allen Bluetooth Geräten gleichermaßen integriert. Der 

Rest der Protokolle wird nur verwendet, wenn die Verwendung für bestimmte Anwendungen 

dies verlangt. Wie schon vorhin erwähnt, ist die Bluetoothtechnologie eine offene 

Technologie. Somit ist es den Entwicklern möglich eigene Zusatzprotokolle zu entwerfen 

(wie etwa HTTP oder FTP). Diese werden dann hierarchisch gesehen auf den Stapel 

aufgesetzt. Entsprechende typische Kombinationen werden in den Bluetooth-Profilen 

vorgeschlagen. 

vCard/vCal 

OBEX 

WAE 

WAP 

TCP UDP 

IP 

PPP 

Anwendungen 

AT- 

Commands 

Kabelersatzprotokoll (RFCOMM) 

Audio 

SCO 

L2CAP 

HCI 

LMP 

Basisband & Link Control 

Bluetooth Radio 

26 

TCS-bin SDP 

ACL 

Abbildung 1.16 – Die Protokollarchitektur 

Software 

Hardware

1.4.2.1. Bluetooth Kernprotokolle 

1.4.2.1.1. Bluetooth Radio / Baseband 

Die physikalische Schicht repräsentiert sich durch die Hardware (Bluetooth RF - 

Funktechnik) und das darauf aufsetzende Basisband (Baseband/Link Control). Die zu 

nutzenden Funkfrequenzen werden zur Verfügung gestellt und alle physikalischen Kanäle 

sowie Verbindungen hiermit verwaltet. 

Die Funktechnik stellt die Kompatibilität zwischen allen Bluetooth-Transceivern sicher, da 

der Aufbau aller Geräte einer Standardversion gleich ist. Sie realisiert die 79 bzw. 23 

möglichen Funkkanäle im vorgegebenen Frequenzband, die Modulation und Übertragung des 

eigentlichen Signals, sowie die erforderliche Signalstärke in den bereits genannten 

Sendeleistungsklassen. Bei dem verwendeten sehr einfachen und somit preisgünstigen 

Gaussian Frequency Shift Keying (GFSK)-Verfahren wird eine negative 

Frequenzabweichung von der jeweiligen Trägerfrequenz als eine "0" und demnach eine 

positive Frequenzabweichung als eine "1" interpretiert. 

Die Baseband-Spezifikation definiert die Paketformate, die physikalischen und logischen 

Kanäle, die Fehlerkorrektur, die Synchronisation zwischen Sender und Empfänger, die 

unterschiedlichen Operationsmodi und Zustände, die den Daten- und Sprachtransport 

ermöglichen. 

Es ist Aufgabe des Basisbandes, die zu verwendende Frequenz für die aktuelle Übertragung 

einzustellen und die quasi-zufällige Frequenzsprungfolge (Pseudo Random Frequency 

Hopping) im Zeitfenster-Duplex-Betrieb (Time Division Duplex TDD) über das spezifizierte 

Master-Gerät zu steuern. So wird es ermöglicht, die Verbindung in dedizierte Zeitschlitze von 

625 Mikrosekunden und einer bis zu 1600mal pro Sekunde wechselnden 

Übertragungsfrequenz einzuteilen und abwechselnd dem Master selbst oder einem der 

verbundenen Slave zum Senden zur Verfügung zu stellen. Die so genannten timeslots werden 

zur synchronisierten Übermittlung von leitungs- sowie paketvermittelten 

Übertragungskanälen genutzt. Dies kann unter Einbeziehung der möglichen 

Vorwärtsfehlerkorrektur (Forward Error Correction FEC) und Prüfsummen (CRC) geschehen. 

Somit ist die unterste Schicht des Standards in ihrer Gesamtheit für die Bereitstellung sowie 

Sicherung und Sicherheit der Verbindung zuständig. 

Es können daraus resultierend nur bis zu fünf Kanäle in einer aktiven Verbindung seitens 

eines Bluetooth-Gerätes bestehen. Die Verbindungssteuerung (Link Control LC) belegt einen 

Kanal zum L2CAP und das Verbindungsmanagement (Link Management) mit bis zu drei 

Sprachkanälen und dem Datenkanal, zum Link Manager Protocol (LMP), die restlichen vier 

möglich. 

Die folgenden Protokolle arbeiten parallel: 

• LMP, das Link Manager Protocol koordiniert Verbindungsauf- und -abbau, 

Sicherheitsfunktionen, Packetgrößensteuerung. 

• L2CAP - Logical Link Control and Adaptation Protocol - eigentliche 

Datenübertragung, außer bei reinen Sprachanwendungen. 

• Audio - reine Sprachübertragung wird direkt implementiert 

• HCI ist Schnittstelle zwischen Host und Bluetooth-Gerät. 

• RFCOMM emuliert serielles Kabel nach RS-232-Standard und dient der 

modemähnlichen Datenübertragung. 

• TCS, Steuerungsschicht für Telefonieanwendungen. 

• SDP, Service Discovery Protocol, fragt die von anderen Geräten angebotenen Dienste 

ab. 

27

• OBEX ist ein Modell zum Austausch digitaler Objekte (z.B. virtuelle Visitenkarten). 

• AT-Befehle werden von Applikationen benutzt, die Telefon- oder Faxfunktionen 

bieten. 

• PPP ermöglicht den Internetzugriff über das Bluetooth-Interface. 

1.4.2.1.2. Link Manager Protocol (LMP) 

Das LMP kann auch als im L2CAP integriert betrachtet werden, jedoch sind die Aufgaben 

beider Protokolle trennbar. Der Link Manager (LM) ist verantwortlich für den 

Verbindungsaufbau und die Sicherheit von Bluetooth-Links. Es wird eine Authentifizierung 

und Verschlüsselung mittels Sicherheitscodes durchgeführt. Ebenso ist er verantwortlich für 

die Kontrolle und Aushandlung der Basisband-Paketgröße. Weiterhin regelt das LMP die 

benötigte Sendeleistung der HF und verwaltet die angemeldeten Stationen eines Piconetzes. 

Das Link-Manager-Protocol koordiniert die zur Verfügung gestellten Dateneinheiten und 

verwaltet die Links. Sämtliche Aktivitäten zum Verbindungsaufbau und zur Verwaltung des 

Piconets werden durch das LMP behandelt. Zur Verwaltung des Piconets gehören das 

Einstellen der Verbindungsgüte, der mögliche Tausch der Master/Slave-Rollen sowie der 

Uhrenabgleich. Weitere Aufgaben des LMPs sind die Authentifizierung und die 

Verschlüsselung zur Gewährleitung der Sicherheit. LMP-Daten haben eine höhere Priorität 

als Nutzerdaten und erreichen niemals höhere Schichten auf Empfängerseite. 

Der LM behandelt die Autentifizierung einer Verbindung und die Verschlüsselung, das 

Management eines Piconetzes (synchrone/asynchrone Verbindung, Steuerung der 

Übertragungsqualität), das Aufsetzen einer Verbindung (asynchrone/synchrone Pakettypen, 

Namen/ID-Austausch), den Einsatz von Multislot-Paketen und die Zustands- und 

Moduswechsel eines Gerätes (active/hold/sniff/park). 

1.4.2.1.3. Logical Link Control and Adaptation Protocol (L2CAP) 

L2CAP unterstützt sowohl verbindungsorientierte als auch verbindungslose (loopback) 

Datendienste für die höheren aufsetzbaren Protokollschichten. Zum weiteren 

Funktionsumfang dieser Protokollschicht gehören die Segmentierung und das 

Zusammensetzen von Telegrammen. Es zerlegt Pakete von bis zu 64kByte und fügt sie am 

Empfänger wieder zusammen. Weiterhin ermöglicht sie das Multiplexen von Verbindungen 

(gleichzeitige Benutzung mehrere Protokolle und Verbindungen) und erlaubt den Austausch 

von Qualitätsinformationen zwischen zwei Geräten. 

L2CAP kann bis zu 64 kByte große Datenpakete entgegennehmen und diese in geeignete 

kleinere Datenpakete für die Basisband-Schicht umsetzen. Die Größe der Datenpakete ist 

dahingehend von Bedeutung, dass sich unmittelbar oberhalb der L2CAP-Schicht die 

Netzwerk-Schicht befindet. Hier werden 64 kByte große Datenpakete verwendet, um die 

Kompatibilität zu IP-Paketen zu gewährleisten. 

Das L2CAP bietet eine abstrakte Schnittstelle für die Datenkommunikation. Es ist für 

aufgesetzte Protokolle irrelevant, wie die übergeben Daten übertragen werden bzw. wurden. 

Dieses Protokoll verbindet die höher liegenden Schichten des Stapels mit dem darunter 

liegenden Basisband. Es arbeitet wenn nötig parallel zum LMP und stellt den aufgesetzten 

Schichten Dienste zur Verfügung, die nicht durch LMP-Nachrichten realisiert werden können. 

Weitere wesentliche Aufgaben dieser Schicht sind die Bereitstellung definierter Dienstgüten 

(Paketrate, Paketgröße, Latenz, Verzögerungsschwankungen, maximale Verbindungsrate), 

sowie die Verwaltung von Nutzergruppen. Ein paar Einschränkungen des Funktionsumfanges 

dieser Schicht sollen allerdings nicht ungenannt bleiben. Die L2CAP-Schicht ermöglicht 

28

keinen Transport von Audiosignalen, d.h. von Daten synchroner Übertragungskanäle. 

Weiterhin ist eine Kommunikation mit Gruppen nur mit einem Broadcast möglich, eine 

Multicast-Verbindung ist hingegen bislang noch nicht verfügbar, wird aber voraussichtlich 

zum Funktionsumfang von Bluetooth 2.0 gehören. 

1.4.2.1.4. Das Host Controller Interface (HCI) 

Zusätzlich zu den obigen Protokollen existiert noch ein Host Controller Interface (HCI). 

Dieses Interface entspricht einem Kommando-Interface für den Baseband Controller, Link 

Manager, und zu den Hardware-Status- und Kontrollregistern. 

Das Host Controller Interface (HCI) liefert einen gemeinsamen standardisierten Übergang 

zwischen einem Host und einem Bluetooth-Gerät, spezifiziert für verschiedene Schnittstellen, 

wie USB, RS232, PCI u.a. . 

Das bedeutet für den Anwender, wenn eine PC-Card als Bluetooth Adapter-Card verwendet 

wird, dass er damit auch an entsprechende Sende-/Empfangsmodule dieses Herstellers 

gebunden ist, da hier die Schnittstelle zwischen Adapter und BT-Modul vom Hersteller 

spezifiziert werden kann. Entscheidet man sich aber für eine serielle Lösung, so kann man 

sich dank des standardisierten HCI den Hersteller aussuchen. 

Die folgende Abbildung zeigt noch einmal die verschiedenen Anschlussarten der Bluetooth- 

Module. Man sieht deutlich wie vom Betriebsystem des Hosts über die verschiedenen 

Interfaces (USB, RS232 oder PC-Card) ein Anschluss an die Bluetooth-Module erfolgt. 

Abbildung 1.17 – Anschluss an einen Host 

29

1.4.2.1.5. Service Discovery Protocol (SDP) 

Das Service Discovery Protocol (SDP) erlaubt es Anwendungen, die Dienste und 

Eigenschaften anderer Bluetooth-Geräte zu erkennen. Diese Dienste können dann durch 

andere Protokolle genutzt werden. 

Das SDP ist Basis aller Verbindungsmöglichkeiten höherer Verbindungen. Es stellt in einer 

Services Discovery Datenbank (SDDB) die Dienste-Struktur eines Bluetooth-Gerätes bereit, 

wodurch Ad-hoc-Netzwerke überhaupt erst ermöglicht werden. Eine zentrale Verwaltung von 

Dienstleistungsinformationen auf einem oder mehreren Kommunikationseinheiten 

widerspricht dem Gedanken eines dynamischen Ad-hoc-Netzwerkes. Deshalb geht kein Weg 

daran vorbei, dass jedes Bluetooth-Gerät selbst Informationen darüber verwaltet, welche 

Dienste es zur Verfügung stellt. 

Nachdem das Bluetooth-Gerät die Dienste, welche von anderen (verbundenen) Bluetooth- 

Geräten in seiner direkten Umgebung angeboten werden, entdeckt hat, kann eine Auswahl der 

gewünschten Dienste getroffen werden. Danach kommt es zum Verbindungsaufbau mit einem 

oder mehreren Bluetooth-Geräten, um den ausgewählten Dienst zu nutzen. Die weitere 

Kommunikation läuft dann ohne Beteiligung des SDPs. 

Dieser Service stellt die Grundlage aller Bluetooth-Nutzermodelle dar und ist der wichtigste 

Teil des gesamten Protokoll-Rahmenwerks. Über SDP werden alle für die Datenübertragung 

nötigen Informationen ausgetauscht, um dann eine Verbindung zwischen zwei oder mehreren 

Bluetooth-Projekten einzurichten. 

1.4.2.1.6. Audio 

Die Audio-Spezifikation definiert die Sprachübertragung, speziell die Kodierung und 

Dekodierung. Audiodaten können zwischen mehreren Geräten direkt übertragen werden. 

Dabei werden die Daten nicht erst durch die L2CAP-Schicht geschickt. Audiotransfers sind 

im Allgemeinen recht einfach realisierbar. 

Für Kopfhöreranwendungen gibt es ein PCM-Rohdatenformat, welches im Direktmodus an 

allen Protokollen vorbeigeführt werden kann (SCO). Diese Audiodaten können parallel zu 

anderen Daten verschickt werden und mit verschieden Fehlerkorrekturverfahren behandelt 

werden. Durch Öffnen eines Audio-Links kann jede Station zu einer anderen "Sprache" 

übertragen. Die resultierenden Paketformate werden später näher vorgestellt. 

1.4.2.2. Cable Replacement Protocol 

1.4.2.2.1. RFCOMM (Radio Frequency Communication) 

Als Schnittstelle zur realen Applikation ist das Kabelersatzprotokoll RFCOMM von 

besonderer Bedeutung. Es stellt der Hostseite virtuelle serielle Verbindungen bereit. Dazu 

simuliert RFCOMM bis zu 60 virtuelle serielle Schnittstellen nach dem RS-232-Standard mit 

einer maximalen Geschwindigkeit von 115 kbps, wodurch eine breite Unterstützung 

beliebiger höherer Protokollschichten erreicht wird. Dabei wird allerdings nur eine 

Untermenge der möglichen Features des abgewandelten ETSI-Standards TS 07.10 durch 

Bluetooth verwendet. 

Die Ablaufsteuerung zur Steuerung der Verbindung erfolgt entweder durch Software in Form 

von XON/XOFF-Steuerzeichen oder über einen Hardwarehandshake wie RTS/CTS oder 

DTR/DSR. (RTS: "Ready To Send", CTS: "Clear To Send", DTR: "Data Terminal Ready", 

DSR: "Data Set Ready") 

Durch BENP (Bluetooth Encapsulation Network Protocol) um direkt PPP zu ersetzen und 

HID-Profile zur Emulation von USB-Schnittstellen, sowie der direkten Anbindung von 

30

Peripherie-Geräten über Hardcopy Replacement Protocol (HCRP) wird RFCOMM im 

Standard 1.2 erheblich entlastet. 

Über den Schnittstellen RFCOMM und L2CAP sitzen dann Protokolle wie IP, WAP oder 

Kartenterminalanwendungen, um mittels spezieller Anwendungen Daten über die 

Funkschnittstelle auszutauschen. Dabei laufen die Anwendungen über eine oder mehrere 

vertikale Kanäle des Protokoll-Stapels. Der Grund-Stapel bis RFCOMM wurde, wie bereits 

erwähnt, so konzipiert, dass bereits vorhandene und bewährte Protokolle darauf aufsetzen 

können, um maximale Kompatibilität zu erreichen. Durch die Offenheit des Standards ist 

vorauszusehen, dass eine Menge verschiedener Anwendungen den Markt erobern werden, 

welche die Möglichkeiten der Bluetooth-Technologie voll ausnutzen können. In sogenannten 

Profilen werden die zu verwendenden Protokolle je nach Anwendungsfall empfohlen. 

1.4.2.3. Telefonie-Steuerungs-Protokolle 

Die Telephony-API (Application Programming Interface) ermöglicht die Verwendung der 

Telefon-Funktionen innerhalb der Bluetooth-Umgebung. Damit konnte der Zielstellung 

Rechnung getragen werden, dass Bluetooth nicht nur im Bereich der Netzwerk- und 

Computertechnik sondern auch bei den Telefonanwendungen Anklang finden soll. Die 

Abwicklung der Telefonie-Dienste wurde durch zwei verschiedene Protokollarten umgesetzt. 

1.4.2.3.1. Telephony Control – Binary 

TCS-BIN stellt ein bitorientiertes Protokoll zum Auf- und Abbau von Sprach- und 

Datendiensten zwischen zwei Geräten zur Verfügung. TCS-BIN baut auf Q.931 der ITU-T 

auf und enthält Rufkontrolle, Verbindungsaufbau, Sprachübertragung und Datenübertragung. 

Q.931 ist auch Grundlage für die Rufsteuerung bei ISDN. Die Telephony Control Protocol 

Specification (TCS) ermöglicht die Signalisierung für die Herstellung und Unterhaltung von 

Daten- und Sprachverbindungen (Terminal, Gateway, Lautstärke, Auflegen/Abheben,...). 

1.4.2.3.2. Telephony Control – AT Commands 

AT-Befehle nutzen zu ihrer Übertragung in der Regel eine serielle Port-Emulation über das 

RFCOMM-Protokoll. Die AT-Befehle, basierend auf V.250 und ETS 300 916 der ITU-T, 

wurden von der Bluetooth-SIG erweitert und ermöglichen verschiedene Varianten zur 

Nutzung von Mobiltelefonen und Modems. Ein Beispiel ist die Nutzung eines Faxdienstes. 

1.4.2.4. Aufgesetzte Protokolle 

Eine Vielzahl von Protokollen sind auf die beschriebenen Basisdienste aufgesetzt. Es sei hier 

eine Auswahl genannt: 

• OBEX (Object Exchange Protocol) wird zum Dateitransfer und zur 

Datensynchronisation benutzt. 

• TCP/IP wird in Internet-Anwendungen eingesetzt. 

• Eine Menge von AT-Kommandos ermöglicht die Steuerung über eine Terminal- 

Verbindung. 

• WAP unterstützt mobile Anwendungen 

Die so genannten angepassten Protokolle werden unverändert vom Industriestandard 

übernommen. Sie führen zur eigentlichen Applikation, womit sie die Interoperabilität mit 

31

isherigen Systemen sicherstellen. Dabei lassen sich prinzipiell zwei Gruppen dieser 

Anwendungsprotokolle unterscheiden. Die erste Gruppe umfasst die Internet-Welt, die zweite 

Gruppe die Anwendungsprotokolle für den (direkten) Datei- und Objektaustausch. 

1.4.2.4.1. OBEX Protocol 

OBEX ist das Object Exchange Protocol und spielt für den Datei- und Objektaustausch bei 

Bluetooth eine wichtige Rolle. Es handelt sich dabei um eine Sitzungsschicht ähnlich dem 

HTTP (HyperText Transfer Protocol) nach dem Client-Server Modell, unabhängig von der 

Transportart und der Transport-API, die umfangreich und effizient zugleich ist. Es ermöglicht 

Objekte und Verzeichnisse mit anderen Objekten darin auszutauschen, und auch 

Verzeichnislistings sind möglich, um alle Objekte zu erreichen. Da OBEX bereits im 

Zusammenhang mit der IrDA-Schnittstelle verwendet wurde, greift Bluetooth zum einen auf 

bisherige Erfahrungen zurück und kann zum anderen OBEX-basierte Applikationen aus dem 

IrDA-Umfeld direkt integrieren. 

Aktuell wird OBEX im Protokollstapel oberhalb von RFCOMM verwendet. Zukünftig sollen 

OBEX-Dienste aber auch direkt auf TCP aufsetzen können. 

1.4.2.4.2. Content Formats vCard und vCalendar 

vCard und vCalendar sind offene Spezifikationen von Internet Mail Consortium und 

definieren nicht den Transportmechanismus, sondern das Format, welches übertragen wird. 

Andere über OBEX laufende Formate sind vMessage und vNote. Diese sind offene 

Spezifikationen und bereits in der IrMC Spezifikation definiert. IrMC definert auch eine Art 

Log-File-Format. 

1.4.2.4.3. Internetprotokolle 

Unter Internetprotokollen versteht man heute eigentlich eine große Vielfalt von 

unterschiedlichen Protokollen auf diversen Kommunikationsebenen. Die folgenden 

Ausführungen sollen einen kurzen Überblick geben. 

1.4.2.4.4. PPP (Point to Point Protocol) 

Das PPP ist ein im Internet benutztes Sicherungsprotokoll. Es wird beispielsweise implizit 

verwendet, wenn man sich mit dem Computer oder dem PDA per Modem ins Internet 

einwählt. Hierbei wird über die serielle Modemverbindung eine Punkt-zu-Punkt-Verbindung 

aufgebaut. Es setzt ebenfalls auf der RFCOMM auf und ist für die Tunnelung von IP Packeten 

gedacht (wie auch bei Modems üblich). 

1.4.2.4.5. TCP/UDP/IP 

Die weit verbreitete Protokoll-Kombination TCP/IP wird oft in Verbindung mit PPP zur 

Kommunikation im Internet verwendet und ermöglicht Einbindung von Bluetooth-Geräten in 

LANs oder WANs. Mit dem IP werden Datagramme zwischen verschiedenen Endsystemen 

transportiert, wobei die Vermittlung durch IP-Router erfolgt. Das TCP gewährleistet die 

Datenintegrität und die Korrektheit der Reihenfolge der IP-Datenpakete. Das TCP ist ein 

verbindungsorientiertes, zuverlässiges Ende-zu-Ende-Protokoll. Das User Datagramm 

Protocol UDP realisiert die IP-Kommunikation verbindungslos und als transaktionsorientierte 

Datagramme. 

32

1.4.2.4.6. Wireless Application Protocol WAP 

Das WAP wurde für verschiedene kabellose WANs entwickelt und stellt eine 

Anwendungsumgebung für Kleinstgeräte wie beispielsweise Mobiltelefone oder PDAs dar. 

Dabei wird innerhalb von WAP frei definiert, wie Informationen aus dem Internet (von Server 

abgerufen) auf den Kleinstgeräten angezeigt werden und somit sind auch versteckte 

Funktionen wie z.B. remote control möglich. WML wird als universelles Software Kit 

verwendet. Weitere direkt unterstützte Formate sind WAP-BitMaP WBMP, vCard, vCal. 

Spezielle Eigenschaften der Kleinstgeräte wie ein eingeschränktes Display, geringe 

Verarbeitungsleistung und Kanalbandbreite werden bei der Umsetzung in besonderem Maße 

berücksichtigt. Alle Erweiterungen und Subformate zusammen sind das WAP Application 

Environment (WAE) 

1.4.3. Paketaufbau 

1.4.3.1. Adressierung 

Abbildung 1.18 – Aufbau Bluetooth Device Adresse 

Die Bluetooth Device Address (BD_ADDR) ist in die folgenden 3 Bereiche eingeteilt: 

• LAP lower address part – unterer Adressbereich (Herstellerimplementation) 

UAP upper address part – oberer Adressbereich (1.Teil Herstellerkennung) 

• NAP non-significant address part – nichtsignifikanter Adressbereich (2.Teil 

Herstellerkennung) 

1.4.3.2. Pakete 

Abbildung 1.19 – allgemeiner Aufbau der Pakete in Bluetooth 

33

Jedes Paket beginnt mit einem Zugangscode (Access Code) zur Signalisierung, bestehend aus 

4-Bit-Preamble zum Gleichstromausgleich, 64-Bit-Synchronisationsword, welches je nach 

Signalisierungstyp von der verwendeten Bluetooth Device Address abgeleitet wird, und 

einem 4-Bit-Trailer, ebenfalls zur Gleichstromkompensation, insofern ein Paketheader folgt. 

Dieser Code insgesamt dient somit der Zuordnung eines Pakettypes, der Synchronisation und 

der Offset-Kompensation bei der Übertragung eines Pakets zwischen zwei Bluetooth- 

Transceivern. 

Ein Paket besteht also immer aus dem Zugangscode (wenn allein, dann als shortened Access 

Code zur Synchronisation in Paging-, Inquiry- und Park-Modi) und kann weiterhin nur einen 

Paketheader oder Header und Payload enthalten. 

Man unterscheidet bei der Signalisierung folgende drei Typen des Access Codes: 

• Channel Access Code (CAC) 

o identifiziert eindeutig ein Pico-Netz 

o LAP-Teil der Masteradresse verwendet 

• Device Access Code (DAC) 

o Signalisierung für ein bestimmtes Gerät 

o LAP-Teil der Adresse des angesprochenen Gerätes verwendet 

• Inquiry Access Code (IAC) 

o Ermittlung aller erreichbaren Geräte (Global-IAC) oder 

o Ansprechen von Gruppen (Dedicated-IAC) 

o für den globalen Rundruf reservierter Wert als LAP verwendet 

o bei einem der 63 möglichen dedizierten Aufrufe der dedizierte LAP-Wert 

Im Header befindet sich die Information zur Paketnummerierung und -bestätigung, für den 

Automatic Repeat Request (ARQ) zur erneuten Anforderung bei fehlerhafter Übertragung, 

sowie die Geräteadressierung, Flusskontrolle und weitere Fehlerkorrekturmaßnahmen wie 

Forward Error Correction FEC – hier 1/3 FEC wodurch aus den in der Skizze aufgezählten 

18Bits 54Bits werden. 

Die verwendeten Bezeichnungen bedeuten: 

• AM_ADDR - Active Member Address 

• Type - Pakettyp 

• Flow - Flusskontrolle 

• ARQN - Acknowledge Indication - Bestätigung 

• SEQN - Sequenznummer 

• HEC - Header Error Check – Fehlerkontrolle des Paketkopfes 

Die folgenden, bis zu 2745 Bit Payload enthalten die transportierten, vom Pakettyp 

unabhängigen Nutzdaten. Sie entsprechen entweder Daten oder Sprache und können ebenfalls 

durch ein 16bit Cycling Redundancy Check CRC gesichert werden. 

34

Kapitel 2 - Verbindungsanalyse 

2.1 Vorstellung des Bluetooth-Protokolltesters FTS 

Zur Visualisierung der Kommunikation von Bluetooth-Geräten wurde das Frontline Test 

System „FTS for Bluetooth“ von Frontline Test Equipment verwendet. Diese weit verbreitete 

Software wird vorwiegend zur Entwicklung und Zertifizierung von Bluetooth-Anwendungen 

und -Geräten herangezogen. Es findet daher auch im sogenannten BQB Bluetooth 

Qualification Process Anwendung. 

FTS bietet grundsätzlich zwei verschiedene Möglichkeiten des Mitschneidens der 

Kommunikation zwischen Bluetooth-Transceivern. Es handelt sich dabei immer um 

Kommunikationspaare bestehend aus Master und Slave. 

• Airsniff: 

Das Monitoring der Luftschnittstelle erfolgt berührungsfrei über eine spezielle Hardware – 

Comprobe am USB-Port des überwachenden Rechners. 

• via HCI: 

Hierbei findet ein Mitschnitt des Verlaufs aller Informationen durch Überwachung des Host 

Controllers statt. Dies kann einerseits durch Verbindung beider beteiligter Host mit dem 

überwachenden Rechner mittels serieller Kabel oder der direkten Erfassung der 

Kommunikation über Host Controller eines beteiligen Bluetooth-USB-Gerätes. 

Auf Grund von gravierenden Treiberproblemen für die programmspezifische Ansteuerung der 

COM-Schnittstellen war die Realisierung des HCI serial sniff nicht möglich. Die Wahl fiel 

somit auf das erstgenannte Verfahren – Airsniff. 

2.1.1. FTS – Airsniff (basic) Tutorial 

Ein PC überwacht mit Hilfe des Comprobes und des installierten FTS die Luftschnittstelle 

(Baseband) des Kommunikationspaares. Der Comprobe ist als ein nicht vollwertiges 

Bluetooth-Gerät zu verstehen. Dieser findet alle aktiven Geräte der Umgebung, wobei er 

selbst für diese „unsichtbar“ bleibt, synchronisiert sich auf das zu kontrollierende Master- 

Slave-Paar ein und protokolliert alle empfangenen Pakete. Dabei beteiligt er sich an jeglicher 

Bluetooth-Kommunikation nicht. 

Der Comprobe sollte möglichst zwischen den beiden Kommunikationspartnern positioniert 

werden, um das Problem der Nichtregistrierung von Paketen zu vermeiden. 

35

Abbildung 2.1 – Messanordnung Airsniff 

Ebenso kann es vorkommen, dass bei ungünstiger Konstellation (Distanz, Interferenzen) eines 

der überwachten Geräte ein vom Comprobe korrekt empfangenes Paket gestört oder gar nicht 

empfängt. 

Ist das Verhalten eines Kommunikationsteilnehmers von speziellem Interesse, so sollte der 

Comprobe in dessen unmittelbarer Nähe aufgestellt werden. 

Zur Überwachung mehrerer Gerätepaare ist die Verwendung ebenso vieler Comprobes 

erforderlich. Dadurch ist ab der FTS for Bluetooth Version 3.20 die Überwachung von Pico- 

respektive Scatter-Netzen, sowie Mixed Pico-Netzen (v1.1 und v1.2-Geräte mit aktiviertem 

AFH) möglich. 

Auch an die gesetzten Systemvoraussetzungen sollte man sich streng halten, da sonst der 

Mess-PC nicht in einer tolerierbaren Performance oder sogar mit Fehlern arbeitet. Es hat sich 

ebenso als günstig erwiesen, so weit möglich einen nicht an der zu überwachenden 

Kommunikation beteiligten PC als Mess-PC einzusetzen. 

Nach der erfolgreichen Installation der Software FTS for Bluetooth und der folgenden 

Hardwareinstallation des Comprobe, sollte man sich die Zeit nehmen, sich mit den Bedien- 

und Ausgabefenstern der Software vertraut zu machen. Folgende kurze Erläuterungen sollen 

dabei helfen die Produktvariante FTS for Bluetooth air sniffer (basic) und darauf aufbauende 

schnell effektiv bedienen zu können. 

FTS wird von einem Hauptfenster aus organisiert und greift auf ein weiteres Fenster mit der 

Datenquelle (Datasource window), im beschriebenen Fall verwaltet dieses den Comprobe, zu. 

Vom genannten Hauptfenster aus kontrolliert man die gesamte Datenerfassung und hat 

Zugriff auf alle Darstellungsvarianten. Die beiden Erfassungsmethoden, in Arbeitsspeicher 

oder in Datei schreiben, unterscheiden sich nicht wesentlich, da sich bei Wahl der Pufferung 

im Speicher das Ergebnis auch anschließend noch, sogar beim Schließen der gesamten 

Anwendung automatisch erfragt, in eine Datei exportieren lässt. Lediglich die 

Kapazitätseinschränkung seitens des vorhandenen Arbeitsspeichers gegenüber dem sofortigen 

Schreiben auf Festplatte kann sich bei großen Datenmengen nachteilig auswirken. Die 

Nutzung der Speichervariante ist daher, bei mehrmaligen kurzen Tests, aufgrund des weit 

geringeren Datei-Management-Aufwandes zu bevorzugen. Man kann am Ende einer Messung 

entscheiden, ob sich die Speicherung der Protokollierung lohnt. 

36

Bevor man Daten erfassen kann, muss die Datenquelle mit allen möglichen Parametern 

eingestellt und der Comprobe mit dem überwachten Pico-Netz synchronisiert werden. Dies 

geschieht natürlich direkt im „Datasource“-Fenster. Der Button „Hardware Settings“ erlaubt 

die Auswahl eines aus der List aller angesteckten Test-Devices, sollte sich aber im Normalfall 

auf den eingesteckten Comprobe beschränken. Es kann zu Problemen mit der Erkennung 

eines Coprobes kommen, sobald dieser seit dem letzten Systembootvorgang neu eingesteckt 

wurde. Hier empfiehlt sich die manuelle Erkennung mit Hilfe der Listenauswahl. Ist ein 

Comprobe erkannt, so können über den Button „Set I/O Parameters“ die Einstellungen zur 

Synchronisationsmethode mit dem Pico-Netz, Filterung bestimmter Elemente des 

Datenstromes und Entschlüsselung vorgenommen werden. Weiterhin sind hier das Auffinden 

von aktiven Geräten und die Auswahl des zu überwachenden Mast-Slave-Paares auszuführen. 

Die Button „Resync“ und „Reset“ sind bei Problemen mit der Synchronisation behilflich. Die 

Taste „Channel Map“ zeigt die Kanalliste der verwendeten Frequenzkanäle und ist daher nur 

bei Verwendung von Bluetooth-v1.2-Geräten und Aktivierung von AFH sinnvoll. Zum 

Starten bzw. Stoppen des Comprobes sind die entsprechend benannten Tasten zu drücken. 

Der Comprobe wird allerdings noch nicht gestartet, da erst die Erfassung der Daten aktiviert 

werden sollte. 

Zur Erfassung von Daten ist nur das Hauptfenster mit seinen Steuerknöpfen und dem darunter 

befindlichen Statusbereich erforderlich. So wählt man mit [start capture to buffer] oder 

[start capture to disk] den Beginn der Erfassung in den Speicher oder in eine gleich darauf 

neu angelegte Datei. Daraufhin sollte der Comprobe im „Datasource“-Fenster gestartet 

werden. Das Symbol in diesem Fenster zeigt dabei den Status der Synchronisation mit dem 

Pico-Netz an. Hierbei bedeutet das durchgestrichene rote das der Comprobe nicht aktiv ist, rot 

die Initialisierung, gelb einen Resynchronisationsversuch und grün den Stand-by-Zustand des 

aktiven Comprobe, also die Zeit innerhalb welcher der Start der Bluetooth-Kommunikation 

erfolgen sollte. Ist dies rechtzeitig geschehen, erkennt man das Mitschneiden einer laufenden 

Kommunikation des vorher ausgewählten Master-Slave-Paares respektive die korrekte 

Synchronisierung am blauen Symbol. 

Das Anhalten der Erfassung und gleichzeitige Löschen des Speicherpuffers geschieht mit 

[Clear], respektive Schließen der Datei mit [Close]. Zum Anhalten der Datenerfassung, 

um beispielsweise den Mitschnitt vorläufig zu beenden oder nur den Inhalt des Puffers nun zu 

speichern, bedient man [Pause/Resume] und setzt sie durch erneutes Drücken fort. Die 

Anzeige über den Füllstand des Puffers/der Datei im unteren Status-Teil des Hauptfensters 

sollte man immer im Auge behalten, da bei Überschreiten der Maximalkapazität entweder die 

ältesten Daten mit den neuen überschrieben werden oder bei Nichtaktivierung dieser Funktion 

(Options -> System Settings -> Wrap Buffer/File) keine weiteren Daten mehr erfasst werden. 

Zur Auswertung aktuell erfasster oder aus einer, mit Hilfe von [Open file] geöffneten, 

existierenden Datei geladenen Daten, stehen mehrere Fenster mit verschiedenen 

Darstellungsformen zur Verfügung. Bei Bedarf können diese auch live zur Auswertung 

herangezogen werden, was in gegebenem Fall zur Entscheidung des Abbruchs der 

Registrierung oder zumindest der Kenntnis über den Verlauf des Tests behilflich sein kann. 

Statistics Display – statistische Informationen zu Datenfluss-Parametern 

Frame Display – textbasierte Informationen einzelner Frames 

Protocol Navigator – textbasierte Informationen mehrerer Frames 

Event Display – Analyse auf Byte-Ebene 

37

Statistics Display 

Es gibt eine Übersicht der angefallenen Datenmengen, verwendeten Framegrössen, 

Kanalnutzung, Übertragunsraten und Frameraten auf Master und Slave aufgeschlüsselt. Des 

Weiteren ist die Gesamtzahl der fehlerhaften und der erneut übertragenen Pakete ersichtlich. 

Abbildung 2.2 – Screenshot FTS-Statistics Display 

Die drei verschiedenen Karteikarten haben folgende Verwendung: 

Session – Statistik über die komplette Sitzung bis Programmende 

Resetable – manuelles Rücksetzen der Statistik durch [reset] jederzeit möglich 

Buffer – Statistik über aktuell gepufferten Daten 

Zusätzlich lassen sich die Frame-Größen auch graphisch in einem extra Fenster darstellen, 

welches über den Button erreichbar ist. Vor Beginn eines Capturings kann auch Einfluss 

auf die Frame-Grössen-Bereiche der Statistik genommen werden (Options -> Set Frame 

Size Ranges). 

Frame Display 

Die enthaltene Information eines in der oberen Fensterhälfte ausgewählten Frames, auch nach 

den enthaltenen Protokollen gefiltert, kann hier eingesehen werden. Es gibt 3 spezielle 

Anzeige-Filtermöglichkeiten: 

38

- alle Pakete mit generellen Informationen anzuzeigen, 

- in der Menge aller nur die relevanten eines Protokolls markiert und ausgewertet zu 

haben (Summary Layer) 

- nur die Frames eines Protokolls über die Karteikarten auszuwählen 

Es hat sich als vorteilhaft erwiesen, im Bereich der dekodierten Information (Decode Pane) 

entsprechende Teilbäume mit Details zu Protokollen, welche nicht von Interesse sind, einfach 

zu reduzieren und nicht unbedingt über die fensteransichtspezifische Filterfunktion 

auszublenden. 

Abbildung 2.3 – Screenshot FTS-Frame Display 

Die optional im unteren Fensterbereich gezeigten Informationen lassen sich beliebig aus 

mehren Ansichtsbereichen (Panes), z.B. die dekodierte Information in Textform oder die 

Ausgabe des Frame-Inhalts in binär, hex oder ASCII-Format, zusammenstellen und 

einblenden. 

Protocol Navigator 

39

Der Vergleich protokollbezogener Information kompletter Frames oder auf der Ebene eines 

gemeinsam verwendeten Protokolls ist hier effizient möglich. Eine spezielle Filterung wird 

ebenfalls durch gleichzeitige Auswahl anzuzeigender und zu verbergender Protokolle oder 

Verwendung der Liste vordefinierter Filter (Named Filters), welche durch eigene Filter 

beliebig erweitert werden kann, unterstützt. 

Event Display 

Abbildung 2.4 – Screenshot FTS-Protocol Navigator 

Der in einem Fenster der anderen beiden Darstellungsformen ausgewählte Frame(-Ausschnitt) 

kann in nicht decodierter Form unter anderem in hex oder ASCII angezeigt werden. Hier sind 

ebenfalls die Zuordnung der fortlaufenden Frame-Nummerierung und die Rollenverteilung 

klar ersichtlich. Eine Zusammenfassung des Ausgewählten Bytes ist in der Statuszeile 

dargestellt. 

40

Abbildung 2.5 – Screenshot FTS-Event Display 

Die Suchoption erleichtert in allen drei genannten Darstellungsfenstern das gezielte 

Auffinden spezifischer Informationen. Die Live-Betrachtung der Daten eines aktuellen 

Capturings wird durch die Einfriersteuerung von lästigem Zurückscrollen zur 

gewünschten Stelle im Fenster befreit. 

Filteregeln bezüglich des Protokolls und der allgemeinen [Apply Filters] Liste 

vordefinierter Filter werden nur in den Fenstern des Frame Displays und Protocol Navigator 

der ersten Instanz fensterübergreifend zugewiesen. Dies gilt nicht für das jeweils 

fenstereigene Verbergen von Detailinformationen (Protocol to Hide / Hidden From View). 

Weitere Instanzen der drei Darstellungsfenster können mit [Duplicate] erzeugt und 

beliebig zur Anzeige spezifischer Informationen gefiltert werden. Eine neue Fensterinstanz 

mit abweichender Filterung kann auf Wunsch („Apply to: New Frame Display“ – verwirrend, 

denn auch auf Protocol Navigator anwendbar!) auch bei direktem Zuweisen eines 

vordefinierten Filters erstellt werden. 

FTS bietet Window Synchronisation. Dies bedeutet, dass die zu der in einem der drei 

Darstellungsfenster - ebenfalls erster Instanz - markierten Information die zugehörigen 

Informationen in den beiden anderen gleichzeitig angezeigt werden. 

2.1.2. Anmerkung 

Es ist zu empfehlen, schon vor der Installation von FTS for Bluetooth oder SerialBlue sich 

mit dem „Quick Start Guide“ von FTS vertraut zu machen. Dies erleichtert den Umgang mit 

41

Fragen hinsichtlich der Zuordnung von Bezeichnungen der verschiedenen Produktvarianten 

und den entsprechenden Verwendungen, sowie den Ablauf des Installationsvorganges selbst. 

Weiterhin bietet sich der Besuch der Homepage von FTE (fte.com/blu01.asp) an, um einige 

nützliche Hintergrundinformationen zu Änderungen und vor allem die neuste Version der 

Software oder Updates zu erhalten und zur Installation zu nutzen. 

Neue Produkte wie Bluetooth-Geräte oder Software auf dem Mess-PC können auch nur von 

einer neuen Version von FTS und dementsprechend der neuesten Firmware des Comprobe 

unterstützt werden. 

Bei der Änderung der seriellen Treiber zur Anwendung von HCI serial sniff oder SerialBlue 

ist auf jeden Fall die aktuellste Version dieser FTS-eigenen Treiber zu verwenden, da mit den 

bis zum Testzeitpunkt verfügbaren keine erfolgreiche Ersetzung der MS Windows-eigenen 

seriellen Treiber bei verschiedenen MS Windows-Versionen (ohne weiteren Aufwand) 

erreicht werden konnten. 

2.2 MSC einer OBEX Datenübertragung 

2.2.1. Darstellung 

Für den Transfer von digitalen Daten zwischen zwei Bluetooth-fähigen Hosts ist eine 

Verbindung der Bluetooth-Geräte und der Aufbau der Kommunikation aller verwendeten 

Protokolle notwendig. Im folgenden Kapitel soll der Ablauf einer Bluetooth-Verbindung zum 

Versand einer 1kB-Datei gezeigt werden. 

Wie schon genannt, sucht der Dateisender – folgend Master – in seiner Umgebung nach 

aktiven Bluetooth-Geräten. Es erfolgt bei diesem Inquiry im Link Manager Protocol die 

Anfrage nach dem zugewiesenen Gerätenamen an alle gefundenen Geräte unter Verwendung 

der MAC-Adressen. In der folgenden Abbildung ist dieser Abruf am späteren Dateiempfänger 

– folgend Slave genannt – dargestellt. 

1 

2 

3 

4 

5 

6 

Master Slave 

LMP_name_req(offset=0) 

LMP_name_res(offset=0,Len=20,"TU-Laptop_Expl") 

Abbildung 2.6 – MSC-Frame 1-6 

BB_retransmitted_LMP_packet 

LMP_name_req(offset=14) 

LMP_name_res(offset=14,Len=20,"orer_B") 

LMP_detach 

42 

Abruf des Gerätenamens 

mit Überlänge 

LM-Verbindungsabbau 

Die Aufzeichnung der Kommunikation beginnt mit dem LMP-Request nach dem Namen des 

Slaves. Es folgt eine Wiederholung desselben Paketinhaltes bevor der adressierte Slave mit 

einem LMP-Name-Response, welches den Beginn des Namens (Offset=0) kennzeichnet, 

seine gesamte Länge und die ersten maximal möglichen 14Byte dieses angibt. Wie ersichtlich 

wird handelt es sich im verwendeten Beispiel um einen Namen, der aufgeteilt werden muss. 

Folglich sendet der Master erneut einen LMP-Name-Request mit dem einzigen Unterschied 

des Name-Offset, notwendigerweise 14, da ab hier der Name fortgesetzt werden soll. Unter 

Berücksichtigung dieses Offset sendet der Slave erneut ein Response mit den Parametern 

Beginn (Offset=14), selber Gesamtlänge und dem zweiten Teil des Namens. Hat der Master-

Host der MAC-Adresse des Slave den Namen zugeordnet so beendet er diese LMP- 

Verbindung vorerst mit dem LMP-Detach. Es folgt noch die gegenseitige Information über 

die verwendete Version des LM-Protokolls mit Hilfe von einem Master-Request und dem 

entsprechenden Slave-Response. 

Erfolgt nun der Verbindungswunsch durch den Master-Host (Host-Connection-Reqest), 

sobald der Datentransfer gestartet wird, so sendet der Master dieses als LMP- Host- 

Connection-Reqest an den Slave. Dieser akzeptiert und bestätigt genau diese Anfrage mit 

einer LMP-Accepted-Antwort. Hierauf folgt die Abfrage der Zeitmessgenauigkeit des 

Masters an den Slave, welcher mit dem entsprechenden Response und den erfragten 

Parametern Abweichung (drift) und Zittern (jitter) antwortet. Der Master sowie der Slave 

senden sich nun nacheinander die Initialisierungsende-Information zu. 

7 

8 

9 

10 

11 

12 

13 

14 

LMP_version_req(vers=1.1-215,compID="Digianswer A/S") 

LMP_version_res(vers=1.1-215,compID="Digianswer A/S") 

LMP_host_connection_req 

LMP_accepted (LMP_host_connection_req) 

LMP_timing_accuracy_req 

LMP_timing_accuracy_res(drift=20ppm,jitter=1µs) 


LMP_setup_complete 

LMP_setup_complete 

43 

LMP-Versionsaustausch 

Host-Verbindungsaufbau 

Vergleich der Zeitmessung 

Ende der Initialisierung 

Da die Verwendung von mehreren Zeitschlitzen für ein Paket von der restlichen 

Kommunikation und der Verwendung von möglichen SCO-Kanälen abhängig ist, muss der 

Master seinen hieraus resultierenden Maximalwert – hier 5 da keine weitere Kommunikation 

mit anderen Slaves oder SCO-Verbindungen existierten – als gewünschte Einstellung mittels 

eines LMP-Max-Slot-Request(5) an den Slave senden. Dieser bestätigt nur den Erhalt dieses 

Requests erneut mit einem LMP-Accepted, woraufhin der Master den LMP-Befehl, dass die 

Maximalzahl an Slots ist für beide Kommunikationspartner bis zur nächsten Änderung 5 ist, 

sendet. Die LM-Einstellungen sind damit auf beiden Seiten gleich und abgeschlossen. 

15 

16 

17 


LMP_max_slot_req(5) 

LMP_accepted (LMP_max_slot_req) 

LMP_max_slot(5) 

max. Zeitschlitze f. ein Paket 

Für einen OBEX-Datentransfer benötigt man nun eine Verbindung der OBEX-Dienste beider 

Seiten. Dies erfolgt, wie aus dem Protokollstapel von Bluetooth ersichtlich wird, unter 

Verwendung mehrerer untergeordneter Protokolle angefangen beim Logical Link Control & 

Adaption Protocol (L2CAP). Dieses baut für jedes aufsetzende Protokoll einen eigen 

logischen Kanal auf. 

Bevor die für den Dateiversand erforderlichen Dienste des verbundenen Geräts genutzt 

werden können, müssen sie dem versendenden Gerät auch als angebotene Dienste bekannt 

sein. Dieser Vorgang des Dienstauffindens ist bekanntlich durch das Service Discovery 

Protocol (SDP) realisiert. 

Durch ein L2CAP-Connection-Request(SDP) wird dem Slave der Wunsch nach einer L2CAP 

Verbindung für eine folgende SDP-Verbindung angezeigt, worauf dieser mit dem 

zugehörigen L2CAP-Connection-Response und einer Verbindung-erfolgreich-Meldung

antwortet. Für diesen entstandenen logischen Kanal zu SDP wird in den folgenden 4 Paketen 

zuerst masterseitig dann slaveseitig die Einstellung der Parameter Maximal Transfer Unit 

(MTU) und Puffer-Verwurf-Zeit (Flush Timeout) mit L2CAP-Configure-Requests gesendet 

und jeweils durch L2CAP-Configure-Responses bestätigt. 

18 

19 

20 

21 

22 

23 

L2CAP_connection_req(SDP) 

L2CAP_connection_res(connection_successful) 

L2CAP_cofigure_req(MTU=65535,FlushTimeout=65535) 

L2CAP_configure_res(success) 

L2CAP_cofigure_req(MTU=65535,FlushTimeout=65535) 



44 

SDP Verbindungswunsch 

L2CAP Init f. SDP 

Zur optimalen Einstellung des Stromverbrauchs sendet jedes kommunizierende Bluetooth- 

Gerät – ob mobil oder nicht – , gesteuert durch seinen Link Manager, Anfragen zur 

Verringerung der Sendeleistung an den Kommunikationspartner. Dies geschieht im Beispiel 

zum ersten Mal im folgend abgebildeten Frame und wiederholt sich bis beide Seiten ihr 

Minimum oder eine zur gesicherten Übertragung mindest notwendigen Sendeleistung erreicht 

haben. Im weiteren Verlauf wird dieses Wissen über die unbestätigten LMP-Power-Decrease- 

Requests vorausgesetzt. 

LMP_power_decr_req 

24 Sendeleistungverminderung 

Abbildung 2.10 – MSC-Frame 24 

Die zuvor über einen logischen L2CAP-Kanal aufgebaute SDP-Verbindung wird nun zur 

Abfrage der notwendigen Dienste genutzt. Dies geschieht bei unterschiedlichen Herstellern zu 

unterschiedlichen Zeitpunkten. In Frage kommen dabei zu Beispiel zum Ersten der Moment 

nach dem Auffinden eines aktiven und bisher unbekannten Geräts, zum Zweiten erst bei 

manueller Auswahl aus der Host-Liste aller bekannten und aktiven Bluetooth-Geräte im 

Umfeld zur Verwendung eines unterstützten Dienstes oder zum Dritten wie hier auch 

dargestellt bei Verwendung einer dienstspezifischen Software (hier nur OBEX) beim Zugriff 

auf diese Dienste. Unter Verwendung von SDP-Service-Search-Attribute-Requests nach den 

Diensten OBEX-Push, OBEX File Transfer und Imaging Responder seitens des Masters und 

SDP-Service-Search-Attribute-Responses seitens des Slaves werden die jeweiligen 

Protokollreihenfolgen und der zugeordnete logische RFCOMM-Kanal zugewiesen. 

25 

26 

27 

28 

29 

30 

SDP_SSARequest(OBEXPush) 

SDP_SSAResponse(L2CAP,RFCOMM(2),OBEX) 

SDP_SSARequest(OBEX File Trans) 


SDP_SSARequest(Imaging Responder) 


31 

32 




Abfrage v. OBEX-Diensten 

SSA .. ServiceSearchAttribute

Nachdem die zu verwendenden Services logischen RFCOMM-Kanälen zugewiesen sind, 

erfolgt der masterseitige Verbindungswunsch nach einem L2CAP-Kanal zum RFCOMM 

(Kabelersatzprotokoll) erneut mittels eines L2CAP-Connection-Request, welches wieder mit 

dem zugehörigen Response und der Erfolgsmitteilung beantwortet wird. Hierauf folgt 

ebenfalls wieder die gegenseitige Initialisierung dieses logischen Kanals durch L2CAP- 

Configure-Requests & -Responses. 

33 

34 

35 

36 

37 

38 

39 

L2CAP_connection_req(RFCOMM) 

L2CAP_connection_res(connection_successful) 

L2CAP_cofigure_req() 




L2CAP_cofigure_req() 


45 

RFCOMM Verbdg.-wunsch 

L2CAP Init f. RFCOMM 

Parameter wie SDP (siehe oben) 

Der Start des RFCOMM-Multiplexers erfolgt durch Senden eines RFCOMM-Set- 

Asynchronous-Balanced-Mode-Frames auf dem Kontrollkanal (CH 0), welches von einem 

RFCOMM-Unnumbered-Acknoledgement für diesen Kanal bestätigt wird. Es folgen weitere 

Bluetooth-spezifische RFCOMM-Parameter-Einstellungen mittels RFCOMM-Unnumbered- 

Information-with-Header-Check-Commands. Zu diesen gehören das ausschließliche Nutzen 

von UI mit Header Check, da die Fehlerkorrektur des ETSI TS 07.10-Protokolls im 

Bluetooth-RFCOMM nicht verwendet wird, Antwortzeiten für Kontroll- wie Datenkanal, die 

Unterstützung kreditrahmenbasierter Flusskontrolle (CFC Credit based Flow Control) und 

Maximale Frame-Größe. 

40 

41 

42 

43 


RFCOMM_SABM (CH 0) 

RFCOMM_UA (CH 0) 

RFCOMM_UIH(CMD(Param.Negot.)) 

RFCOMM_UIH(CMD(Param.Negot.)) 

SABM .. SetAsyncBalanceMode 

UA .. UnnumberedACK 

UIH .. UnnumberedInfo + 

HeaderCheck 

Es folgt nun der Aufbau des RFCOMM-Datenkanals (CH 2) in der selben Art und Weise wie 

schon der Kontrollkanal erstellt wurde. In den folgenden Frames werden die Modem Status 

Commands und respektive Responses dazu genutzt die Kontrollsignale sowie das Break- 

Signal der emulierten RS-232 Schnittstelle durchzureichen. Gefolgt wird dies von einer 

gegenseitigen Zusendung der ersten Kreditrahmen für CFC und weiteren Modem Status 

Commands.

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 


RFCOMM_SABM (CH 2) 


RFCOMM_UIH(CMD(ModemStatus)) 


RFCOMM_UIH(RESP(ModemStatus)) 


RFCOMM_UIH(Credits(30)) 

RFCOMM_UIH(Credits(30)) 






46 

RS232-Signalemulation 

Erst nach Abschluss dieser vorbereitenden Protokollverbindungen kann der Master seinen 

OBEX-Verbindungswunch zum Datentransfer (FTP File Tranfer Protokol) an den Slave 

mittels OBEX-Connect(FTP) senden. Dies wird durch eine Erfolgsmeldung und Bestätigung 

des gewählten Protokolls FTP beantwortet. Darauf folgend erfragt der Master den Inhalt des 

Zielordners auf dem Slave-Host durch OBEX-Get(FolderListing) was ihn aus Sicht des FTP 

zum anfragenden Client macht. Somit ist der Slave hier FTP-Server welcher den erfragten 

Inhalt, im Beispiel leerer Ordner, als Erfolgsmeldung OBEX-Success(FTP-Server(Folder 

Listing) zurücksendet. Nun folgen die eigentlichen Daten. also der Inhalt der 1kB-Datei sowie 

ihre Attribute und Parameter in den nächsten Multislot-Paketen, was wiederum durch OBEX- 

Success(FTP) bestätigt wird und nun auf dem Slave-Host als Datei im eingestellten Standard- 

Datenaustausch-Ordner zu finden ist. Es folgt eine erneute Abfrage des Ordnerinhalts seitens 

des Masters und die gewohnte Bestätigung das Slave, welche jetzt einen nichtleeren 

Ordnerinhalt auflistet. Die Datei ist erfolgreich kopiert worden. 

OBEX_Conn(FTP) 

57 

OBEX_Sucess(FTP) 

58 

OBEX_Get(FolderListing) 

59 

OBEX_Sucess(FTP_Server(FolderListing)) 

60 

OBEX_Put(FTP_Client(Data)) 

61/62 

OBEX_Put(FTP_Client(Data)) 

63/64 

OBEX_Sucess(FTP) 

65 

OBEX_Get(FolderListing) 

66 

OBEX_Sucess(FTP_Server(FolderListing)) 

67 


OBEX Verbindung m. FTP 

Auf der Masterseite wird nun kein Zugriff mehr auf das SDP benötigt, was sich im Abbau des 

zugehörigen L2CAP-Kanals mittels L2CAP-Disconnection-Request und –Response 

wiederspiegelt.

68 

69 

Abbildung 2.16 – MSC-Frame 68/69 

L2CAP_disconnection_req() 

L2CAP_disconnection_res(success) 

47 

L2CAP Verbindungsabbau 1 

Nun wird das OBEX-Protokoll ebenfalls durch OBEX-Disconnect und bestätigende OBEX- 

Success-Meldung getrennt. 

70 

71 


OBEX_Disconnect 

OBEX_Sucess 

OBEX Verbindungsabbau 

Auf der RFCOMM-Ebene muss nur der Datenkanal abgebaut werden, was durch RFCOMM- 

Disconnect(CH 2) und die entsprechende Bestätigung mittels Unnumbered Acknowledgement 

realisiert wird. 

72 

73 


RFCOMM_Disconnect (CH 2) 


RFCOMM Verbindungsabbau 

Beim Aufruf zum Abbau des verbliebenen L2CAP-Kanals für RFCOMM ist im 

Nutzdatenbereich des gesendeten Pakets ein Fehler aufgetreten, wobei allerdings die 

beinhalteten Informationen nachweislich wiederhergestellt werden konnten. Der L2CAP- 

Disconnection-Request wurde erneut durch das entsprechende Response vom Slave bestätigt. 

74 

75 

L2CAP_disconnection_req() Payload Error 

L2CAP_disconnection_res(success) 


L2CAP Verbindungsabbau 2 

Erst jetzt wurde nach weiteren Anfragen nach Sendeleistungsverminderung seitens des Slaves 

das Minimum der Leistung erreicht was mit der ebenfalls unbestätigten LMP-Min-Power- 

Meldung dem Master angezeigt wird. Selber sendet der Slave aber weiterhin noch eine 

Anfrage seinerseits. Diese Verbindung wird nach Lösen aller Verbindungen der anderen 

Protokolle auch auf Link Manager-Ebene durch das endgültige LMP-Detach geschlossen. 

76 

77 

78 

LMP_decr_power_req 

LMP_min_power 

LMP_decr_power_req 

79 

LMP_detach 



Sendeleistungsmin. erreicht 

LMP Verbindungsende 

Aufgrund der bereits genannten Schwierigkeiten mit dem Einsatz der seriellen Sniff-Variante 

und den daraus resultierenden Beschränken auf die Luftschnittstelle, konnten nur korrekt oder 

fehlerhaft empfangene Pakete in die Auswertung einfließen. Daher ist es nicht möglich, die

genaue Anzahl verlorener Pakete einer gestörten Übertragung zu bestimmen. Weiterhin sei 

angemerkt, dass FTS nicht vorrangig zur Visualisierung von überwachten Bluetooth- 

Verbindungen geeignet ist, sondern zum Testen verschiedenster Geräte oder 

Kommunikationsprotokolle im Entwurf, sowie zur Bluetooth-Zertifizierung von 

Neuentwicklungen dient. Dementsprechend umfangreich und somit komplex fällt dieses 

Programm und dessen Entwicklungsumgebung (freiprogrammierbar) aus. 

Zum Zwecke der schnellen visuellen Darstellung eignen sich Protocol Analyzer mit der 

Ausrichtung auf den Endanwender, wie Kontrolle und Monitoring, erheblich besser. Eines 

dieser Werkzeuge ist der BlueAnalyzer der Firma IVT mit seinen Unter-Varianten BlueTester 

und BlueUnitTesting. Diese stellen die aufgenommenen Daten in Echtzeit direkt in Message- 

Sequenz-Charts und ebenfalls detaillierte Informationen in weiteren Fenstern geordnet dar. 

Daraus lassen sich dann einfach detailreiche, an die eigenen Wünsche angepasste Reporte 

erstellen. Natürlich sind diese Funktionen im selben Maße wie FTS zum Testen von 

Protokollen geeignet. Somit sollte ein Vergleich der angebotenen Sniffer-Software 

hinsichtlich der Hauptverwendung und dem Erfüllen daraus resultierender Anforderungen 

genau geführt werden. 

Zur Erstellung eines solchen MSC wäre ein o.g. Monitoring-Programm mit automatischen 

Visualisierungsfunktionen hilfreich gewesen. Bei Anwendung von FTS for Bluetooth ist dies 

nur mittels aufwendiger Exportierung und Aufbereitung durch eine weitere Software (Visio 

und Grafikprogramm) manuell möglich. 

2.3 Bluetooth in der Praxis 

Im folgenden Kapitel soll der Bluetooth-Standard und seine Verwendung in der Praxis näher 

beleuchtet werden. Hierbei soll im ersten Teil auf die Konfiguration, herstellerspezifische 

Unterschiede, Probleme bei alltäglichen Anwendungen und Optimierungsempfehlungen 

eingegangen werden. Darauf folgen die Ermittlung resultierender Reichweiten ausgewählter 

Sendeleistungsklassen und eine Veranschaulichung der Kanalnutzung einer 

Beispielverbindung. 

Folgende Geräte wurden unter Windows 2000/XP getestet: 

- ACER BT500 USB, Class 2 

- ComOne Bluetooth PC-Card MC310, Class 1 

- D-Link DBT 120 USB, Class 3 

- Sony-Ericsson T-610 Mobiltelefon, Bluetooth Class 3 integriert 

- Toshiba BT-PC-Card PA3053, Class 1 

- Toshiba Portegé3500 Laptop, Bluetooth Class 2 integriert 

Bluetooth-Anwender-Software: 

- jeweils im Lieferumfang enthaltene Original-Software 

- Widcomm Vers 1.4.3.4 (weit verbreitet) 

- BlueSoleil Vers 1.4.7 (weit verbreitet) 

- Toshiba Vers 3.00.12 (nur für Toshiba-Geräte) 

2.3.1. Konfiguration und Betrieb 

Bei der Installation, der Einstellung und dem Einsatz der zur Verfügung gestandenen 

Bluetooth-Endgeräte wurde ein ansehnlicher Erfahrungsschatz zusammengetragen. Aus 

diesem seien nur einige generelle Resultate vorgestellt. 

48

Um einen störungsfreien Betrieb der Funk-Hardware zu gewährleisten, sollten nach 

Möglichkeit folgende Punkt beachtet werden: 

- Störung durch interferierenden Funk (Im folgenden Kapitel näher untersucht) 

- kein gleichzeitiges Inquiry der beiden Kommunikationspartner 

- unnötige USB-Geräte vom Laptop trennen (Problem der Stromversorgung) 

- ungeschirmte USB-Verlängerung 

- Abschirmungen und Reflexionen verringern Reichweite (Signalleistung) 

Ist mit Vermeidung dieser physikalischen Fehlerquellen die Interaktion der Geräte auch dann 

noch nicht einwandfrei möglich, so ist die Ursache meist in der eingesetzten Software (inkl. 

Treiber) zu suchen. 

In erster Linie ist das spürbare Problem der Interoperabilität verschiedener Bluetooth-Geräte 

zu nennen. Obwohl alle eingesetzten Geräte dem derzeit neuesten generell verfügbaren 

Standard v1.1 entsprechen, kam es jeweils in mindestens einem Fall zu Inkompatibilitäten, 

sobald diese Produkte verschiedener Hersteller waren. Beispielsweise waren beidseitig 

unterstützte Dienste nicht oder nur in eine Richtung verwendbar, da sie entweder nicht 

gefunden oder zur Verbindung gebracht werden konnten. Dies kann u. a. auch auf gravierende 

Unterschiede in der Realisierung der eigentlichen Dienste zwischen den Herstellern 

entsprechender Komplettpakete (Treiber, Anwendersoftware) zurückgeführt werden. 

Ähnliche Probleme waren auch bei der Verwendung identischer Hardware desselben 

Herstellers, aber unterschiedlicher Original-Treiber- bzw. -Software-Versionen zu 

beobachten. 

Darüber hinaus kam es häufig während Treiber-Tests zu Systemabstürzen. 

Für all die oben aufgeführten Probleme sind vorrangig alte Versionen der eingesetzten 

Treiber, Soft- und Firmware verantwortlich zu machen. Es empfiehlt sich daher, die 

Bluetooth-Geräte immer mit den aktuellsten Treibern zu betreiben und die gleiche 

Anwendersoftware zu verwenden. Leider kann teilweise ein einfaches Update dieser 

Versionen durch fehlende produktspezifische Lizenzvereinbarungen verhindert werden. Dies 

war bei einem Aktualisierungsversuch der Widcomm-Software für den ACER BT500 der 

Fall. Durch Ausweichen auf eine herstellerunabhängige Software, wie beispielsweise die 

lizenzfreien BlueSoleil (IVT Systems) sowie die für spezifische Produkte lizenzierte 

Widcomm-Software, oder nach Möglichkeit ein Upgrade auf die neueste Firmware kann eine 

Lösung herbeigeführt werden. Ein Firmwareupgrade kann das Problem einer fehlenden 

Lizenz, zur Nutzung der aktualisierten Software, beheben. Leider wurde im Falle des ACER 

BT500 keine neue Firmware angeboten und BlueSoleil unterstützte den Chipsatz nicht. 

Eine uneinheitliche Bedienbarkeit der Anwendungssoftware begründet sich aus sehr 

unterschiedlicher Strukturierung ihrer Komponenten und Darstellung der 

Anwendermöglichkeiten. So realisiert die Software von Toshiba jeden Dienst in einzelnen 

Graphical User Interfaces (GUIs), die genannte lizenzfreie Software BlueSoleil alles in einem 

Applikationsfenster und die ebenfalls getestete Widcomm-Software die unterstützten Dienste 

durch direkte Einbindung ins Betriebssystem. 

Es wurde festgestellt, dass bei allen getesteten Anwendungen nur die Änderung elementarer 

Verbindungseinstellungen, wie zum Beispiel Sicherheitslevel, Com-Ports, sowie IP-Adresse, 

möglich war. Doch es konnte keine Einflussnahme auf weiterführende 

Übertragungsparameter getätigt werden. Wünschenswert wäre u. a. die Wahl zu 

verwendender Pakettypen, und somit die direkte Beeinflussung der ACL Datenraten 

(symmetrisch/asymmetrisch). 

49

Darüber hinaus erschwerten zumeist der Verlust manueller Einstellungen und wenig 

aussagekräftige Fehlermeldungen seitens der gestesteten Bluetooth-Software die 

Konfiguration und Verwendung dieser. 

2.3.2. Reichweiten 

Zur Untersuchung der Auswirkungen der bekannten unterschiedlichen Sendeleistungsklassen 

und die jederzeitige Minimierung der Sendeleistung von Bluetooth-Endgeräten auf die 

mögliche Reichweite der Übertragung, wurden die bereits erwähnten Geräte-Paare ACER 

BT500 USB und Toshiba BT-PC-Card PA3053, welche Class 2 respektive Class 1 

zuzuordnen sind, verwendet. Dies wurde im Rahmen eines Freifeldversuchs durchgeführt, um 

etwaigen Störungen und Interferenzen auszuweichen. Hierfür kamen ebenfalls die beiden 

bereits aufgeführten Laptops HP Omnibook zum Einsatz. 

Mit Hilfe des Software-Tools „iPerf“ (im folgenden Kaptitel näher vorgestellt), welches in 

Verkehrsmessungen IP-basierter Netzwerke Anwendung findet, wurde der maximale 

durchschnittliche Durchsatz in Abhängigkeit von der Entfernung zweier Bluetooth- 

Tranceiver ermittelt. Als Übertragungsprotokoll wurde UDP verwendet, da es die beste 

Möglichkeit für einen Rückschluss auf die maximal erreichbare Bandbreite einer 

Datenübertragung bietet. Als ausreichende Messdauer und somit die Mittlungszeit der 

Datenrate wurden 20 Sekunden ermittelt und entsprechend angewendet. 

Je nach verwendeter Literatur werden für die beiden eingesetzten Klassen 10 bis 20 Meter 

bzw. 100 Meter als erreichbare Distanz unter optimalen Bedingungen dargestellt. Auf 

Grundlage dieser Erwartungswerte wurden die Schrittweiten der Messung zum besseren 

Vergleich der Ergebnisse angepasst. So sollten die ersten zehn bis zwanzig Meter in beiden 

Messungen mit den unterschiedlichen Geräte-Paaren in Ein-Meter-Schritten erfolgen und 

darüber hinaus für die Klasse 1 aller 10 Meter bzw. ab 100 Meter aller 20 Meter ein Messwert 

bestimmt werden. Aufgrund der in den folgenden Diagrammen gezeigten Abweichungen von 

diesen genannten Erwartungen, wurden die Messwertanzahl und auch die Distanz der 

Einzelmessungen während des Experiments angepasst. 

50

Abbildung 2.21 – Reichweitenvergleich 1 

Bei Betrachtung des Vergleichs auf den ersten 10 Metern des Übertragungsweges fällt leicht 

die Konstanz der Durchsatz-Beträge der Class-1-Toshiba PC-Cards auf. Unerwarteter Weise 

hat das ACER USB-Paar schon bei den geringeren Distanzen mit starken 

Durchsatzeinbrüchen zu kämpfen und bereits bei 9 Meter konnte keine Verbindung mehr 

aufrecht erhalten werden. Dabei wurden die Erwatungen bei Weitem unterschritten, da nicht 

einmal das Kriterium für Class-3-Geräte mit geforderter Optimal-Reichweite von bis zu 10 

Meter erfüllt wurde. 

Abbildung 2.22 – Reichweitenvergleich 2 

51

Demgegenüber sehr positiv überraschend war das hier dargestellte Ergebnis der Toshiba PC- 

Cards. Es wurde nicht nur spielend die angestrebte Distanz erreicht, sie wurde auch mit fast 

gleich bleibender Übertragungsqualität überschritten. Erstaunlicherweise erst weit nach 

Überschreiten der doppelten zu erwartenden Reichweite ist die Verbindung endgültig 

zusammengebrochen. 

Generell war festzustellen, dass sich eine Sichtverbindung der kommunizierenden Geräte 

günstig auf die resultierende Reichweite, welche schon durch die geringere 

Sendeleistungsklasse beider eingesetzten Transceiver begrenzt wird, auswirkt. 

2.3.3. Kanalnutzung in FFH 

Um den Einfluss schmalbandiger Störquellen auf eine Bluetooth-Verbindung so gering wie 

möglich zu halten, muss sich das bis Version 1.1 alleinig angewandte Fast Frequency 

Hopping über das gesamte ISM-Band erstrecken. Dieser Aspekt der Frequenzwahl wurde 

untersucht und im folgenden Kapitel dargestellt. 

Zur Visualisierung dieser pseudozufälligen Sprungsequenz, wurde eine 

Beispielkommunikation zweier Geräte in ungestörter Umgebung mit Hilfe der vorgestellten 

Software FTS for Bluetooth aufgezeichnet. Aus der resultierenden Log-Datei wurden die 

Pakete mit den zugehörigen Kanalnummern, Paketindex und Zeitstempeln extrahiert. Es 

bestanden dadurch grundsätzlich zwei Möglichkeiten der Darstellung des 

Kanalnutzungsverlaufs. Das Auftragen der Kanalnutzung in Abhängigkeit vom Paketindex 

hätte allgemein für diese Untersuchung ausgereicht, doch wurde die Darstellung über der 

Zeitachse gewählt, um den zeitlichen Verlauf der Verbindung sichtbar zu machen. 

Die im Hex-Format vorliegende Zeitangabe wurde mittels eines zuvor bestimmten 

Korrekturfaktors in Millisekunden umgerechnet. (Das genaue Vorgehen wird im folgenden 

Kapitel näher beschrieben.) 

Abbildung 2.23 – Kanalnutzung, Verlauf 

52

In diesem Diagramm wird die Verteilung über das gesamte Band zu jedem Zeitpunkt deutlich. 

Somit ist die Wahrscheinlichkeit der Interferenz mit einem potentiellen Störer fast so gering 

wie mit der Nutzung von 79 Kanälen möglich. Es besteht also für jedes Paket immer wieder 

nahezu die gleiche Chance auf einem bestimmten Kanal gesendet zu werden. 

Ausgehend von der Kanalsprungsequenz, wurden, zur näheren Untersuchung der 

resultierenden Häufigkeiten der Verwendung jedes Frequenzkanals, diese in folgendem 

Histogramm aufgetragen, welches allerdings nicht den Zeitpunkt der Nutzung der Kanäle 

widerspiegelt. Es kann annähernd eine Gleichverteilung interpretiert werden, welche bei 

größeren Paketzahlen deutlicher wird. Hier wurde jedoch zum Zwecke einer überschaubaren 

Sprungsequenz darauf verzichtet. 

Abbildung 2.24 – Kanalnutzung, Histogramm 

53

Kapitel 3 - Koexistenz im ISM-Band 

3.1 Einleitung 

Bluetooth agiert bekanntermaßen im lizenzfreien ISM-Band. Somit wird es gestört und ist 

gleichzeitig auch ein Störer für andere Funktechnologien, welche die gleichen Frequenzen 

beanspruchen. 

Die Beeinflussung durch Interferenzen äußert sich grundsätzlich in mehr oder weniger starken 

Durchsatzeinbrüchen und höheren Latenzzeiten, respektive bei Audio-Übertragungen in der 

Tonqualität durch ein unangenehmes Knacken und Rauschen. Diese Auswirkungen werden in 

der Bluetooth-Technologie bis Version 1.1, im Falle schmalbandiger Störung, durch Fast 

Frequency Hopping weitest möglich minimiert. Dabei wird das komplette, zur Verfügung 

stehende Frequenzband nahezu gleichmäßig für die pseudo-zufällige Kanalsprungreihenfolge 

ausgenutzt. 

In diesem Kapitel sollen die Konsequenzen gegenseitiger Interferenzen für Bluetooth und 

anderen schmalbandigen ISM-Funk aufgezeigt werden. Vorrangig soll dabei der gleichzeitige 

Betrieb von WLAN (IEEE 802.11b) und Bluetooth als Beispiel betrachtet werden. 

Für die Visualisierung der gegenseitigen Einflüsse wurden zwei verschiedene Ansätze 

gewählt: 

1. Paketanalyse mittels „FTS for Bluetooth“ 

2. Durchsatzmessungen unter Zuhilfenahme von iPerf 

3.2 FTS-Paketanalyse 

Aufgrund von Interferenzen mit anderem Funk kommt es zur Verfälschung oder gar zum 

Verlust der im empfangenen Signal enthaltenen Information. Dies hat das fehlerhafte Erfassen 

oder Nichterkennen von gesendeten Paketen am Empfänger zur Folge. 

Als Beispiel für diese Tatsache sei die nachstehende Darstellung paralleler Bluetooth- und 

WLAN-Kommunikation gezeigt. 

54

Quelle: „carmeq - Introduction to Bluetooth“ 12.06.2003 

Abbildung 3.1 – Beispiel: WLAN und BT v1.1 Interferenzen 

Während auf der Abszisse die laufende Nummer eines Pakets aufgetragen ist, zeigt die 

Ordinate den Frequenz-Kanal, auf dem das Paket gesendet wurde. Dabei stellen ein grünes 

Kreuz ein korrekt empfangenes und ein blauer Stern respektive ein rotes Dreieck ein defektes 

Paket dar. Es ist der Interferenz-Bereich der beiden konkurrierenden 

Funkübertragungstechnologien in diesem Mitschnitt auf der Ebene des Basisbandes sehr gut 

ersichtlich. 

Mittels des bereits vorgestellten Protokollanalysators FTS for Bluetooth wurde versucht, den 

oben dargestellten Zusammenhang in einem eigenen Versuch nachzustellen. Es wurde dafür 

eine durch WLAN, respektive eine Mikrowelle gestörte Bluetooth-Datenübertragung 

aufgezeichnet. 

Aufbauend auf umfangreiche Tests im Vorfeld sind folgende Anforderungen an 

Messanordnung und –umgebung ermittelt worden, um aussagekräftige Ergebnisse zu erzielen: 

- Positionierung der Geräte für einen gut sichtbaren Effekt der gewünschten Einflüsse 

- Sichtkontakt und Vermeidung von Reflektion zwischen Sendern und Empfängern 

- weitestgehend anderen Funk vermeiden 

- statischer Aufbau (keine Bewegung der Aktoren während Messung) 

Im Falle von Interferenzen besteht ein Problem, sobald ein Comprobe einen räumlichen 

Abstand zu einem überwachten Gerät hat, da er empfangene bzw. gesendete Pakete 

abweichend von diesem registriert. Um ein möglichst unverändertes Aufzeichnen der 

empfangen Pakete eines Gerätes zu gewährleisten, muss der Comprobe unmittelbar neben 

dem überwachten Bluetooth-Gerät positioniert werden. Doch umgekehrt vergrößert sich die 

Wahrscheinlichkeit der Abweichung zu den vom anderen Gerät des Kommunikationspaares 

empfangenen Paketen. 

55

Somit wurde im betrachteten Fall ein besonderer Messaufbau verwendet, welcher nur eine 

unidirektionale Überwachung der Master-Slave-Kommunikation zulässt. Durch die 

entsprechende Positionierung des Comprobe wurden für ihn die geforderten gleichen 

Empfangsvorrausetzungen wie für den Datei-Empfänger erzielt und es wurde nur die gestörte 

Empfangssituation für den Datei-Empfänger betrachtet. 

Die Daten über alle registrierten Pakete mussten dann exportiert und aufbereitet werden. Der 

Export wurde, ohne Umwege über weitere Dateien, mittels der Kopieren-in-die- 

Zwischenablage-Funktion von Microsoft Windows zu Microsoft Excel realisiert. Die 

Datensätze bestanden, auch auf Grund der Unterschiede zwischen deutscher und englischer 

Zahlennotation, zum größten Teil aus Text. Um die Information in Form von Zahlen zurück 

zu gewinnen, waren verschiedene Manipulationen und Umrechnungen, z.B. der Zeit von Hex- 

in dezimales Format, sowie die Korrektur der verwendeten Einheit zu Millisekunden, 

notwendig. 

Die gezeigten Darstellungen sind also keine direkten Extrakte von FTS, sondern bauen 

lediglich auf die mit dieser Software gesammelten Daten auf. 

In diesen Informationen von FTS ist auch, neben Paketindex und Zeitstempel, die Kanalzahl 

in Verbindung mit der resultierenden Frequenz enthalten. Es ist bei dieser Basisband- 

Überwachung wenig von Interesse welche Protokolle verwendet wurden. Um eine Aussage 

über den Zustand der Verbindung machen zu können, ist lediglich der so genannte Paketstatus 

– bei Empfang – auszuwerten. Die möglichen Angaben sind dabei OK, Payload Error und 

Length Error. Die beiden letztgenannten wurden zu „Status: error“ zusammengefasst. Nach 

diesen Merkmalen und der Senderichtung wurden die Datensätze sortiert und wie auch im 

folgenden Diagramm in Abhängigkeit von der betrachteten Übertragungsrichtung dargestellt. 

3.2.1. Störeinfluss von WLAN 

Diese Messung des Störeinflusses von WLAN auf eine Bluetooth-Verbindung wurde mit 

folgenden Geräten realisiert. 

Für Bluetooth-Kommunikation, Abstand 2m: 

- Acer BT500 (Class 2) USB an Toshiba Portegé3500 

- Acer BT500 (Class 2) USB an Fujitsu Siemens CELSIUS Mobile 

Für WLAN (IEEE802.11b)-Kommunikation, Abstand 5m: 

- 3com Airconnect PC-Card an HP OmniBook 4000series 

- Roamabout PC-Card an HP OmniBook 4000series 

FTS-Airsniff wurde auf dem Toshiba Portegé3500, an dem somit der Comprobe 

angeschlossen war, betrieben. 

56

Abbildung 3.2 – Messaufbau WLAN-Einfluss 

Zur Messung wurde auf beiden gekreuzten Kommunikationssystemen gezielt IP-Traffic 

erzeugt und die gerichtete Bluetooth-Übertragung, wie einleitend beschrieben, am Daten- 

Empfänger überwacht. 

In folgendem Diagramm ist ein Verbindungsausschnitt mit 7923 der registrierten Pakete und 

deren Empfangsstatus, in Abhängigkeit von Frequenz-Kanal und Zeit, aufgetragen. 

Abbildung 3.3 – zeitlicher Verlauf der WLAN-Störung 

Die Interferenzen im 20MHZ-Band des benutzten WLAN-Kanals sind sehr gut zu erkennen. 

In diesem Bereich ist ebenfalls das Herausbilden von Lücken, also weniger Pakete, sichtbar. 

57

Dies ist im Nichtregistrieren von gesendeten Paketen seitens der beiden Empfänger – 

überwachtes Bluetooth-Gerät und Comprobe – zu begründen. Zu diesem Paketverlust kommt 

es aufgrund nichtdetektierbarer verfälschter Signale oder Pakete, die vom Empfänger nicht als 

an ihn adressiert interpretiert werden. 

Das anschließende Histogramm soll die Mengen der korrekt oder fehlerhaft empfangenen und 

nicht registrierten Pakete näher verdeutlichen. 

Abbildung 3.4 – Histogramm der WLAN-Störung 

Im Interferenzbereich ist ein Verlust je Kanal bis zu 50 Prozent der zu erwartenden 

Paketmenge deutlich zu erkennen. Die restlichen, registrierten Pakete sind zudem größtenteils 

fehlerbehaftet. Die Fehler außerhalb des beschriebenen Bereichs sind auf Reflektionen im 

Raum zurückzuführen. 

3.2.2. Störeinfluss einer Mikrowelle 

Die Mikrowelle ist ein weiterer praktischer Störer, welcher eine Bluetooth-Verbindung 

beeinträchtigen könnte, da ihr Frequenz-Spektrum ebenfalls im ISM-Band angesiedelt ist. 

Der Grad der möglichen Beeinflussung soll hier untersucht werden. 

Umfangreiche Vorversuche haben gezeigt, dass aufgrund der geforderten hochgradigen 

Schirmung der Mikrowelle, nur in unmittelbarer Nähe messbare Einflüsse auf eine Bluetooth- 

Kommunikation nachzuweisen waren. Dementsprechend wurde folgender Messaufbau 

gewählt: 

Für Bluetooth-Kommunikation, Abstand 4m: 

- jeweils ein Acer BT500 (Class 2) USB an HP OmniBook 4000series 

Mikrowelle: Moulinex B85, 750 Watt, 2,450GHz 

58

FTS-Airsniff wurde weiterhin auf dem nun eigenständigen Toshiba Portegé3500 

durchgeführt. 

Abbildung 3.5 – Messaufbau Mikrowelle 

Die in einen Meter Abstand platzierte Mikrowelle wurde für die Dauer der OBEX- 

Übertragung einer 512kB großen Datei auf maximaler Leistungsstufe betrieben. Der 

Sichtkontakt der Bluetooth-Transceiver war jederzeit gewährleistet. 

Wie bereits aus dem WLAN-Versuch bekannt, ist der jeweilige Paketstatus in Abhängigkeit 

von Zeit respektive Häufigkeit auf dem zugehörigen Kanal dargestellt. 

Abbildung 3.6 – zeitlicher Verlauf Mikrowellenstörung 

59

Wiederum ist der beschriebene Paketverlust durch den Volllastbetrieb bis ca. 9.000ms gut 

sichtbar. Anschließend wurde die Bluetooth-Verbindung weniger behindert. Unerwarteter 

Weise ist die registrierte Störung verteilt und verschoben. Wie sehr gut im folgenden 

Histogramm ersichtlich, ist die maximale Paketauslöschung etwa bei Kanal 8 (2,410GHz), die 

größte Zahl fehlerhaft empfangener Pakete um Kanal 28 (2,430GHz) und ein geringeres 

lokales Extremum beim erwarteten Kanal 48 (2,450GHz) angesiedelt, welcher vom Hersteller 

der Mikrowelle als Arbeitsfrequenz angegeben wird. 

Abbildung 3.7 – Histogramm Mikrowellenstörung 

Die Verteilung der Störeinflüsse ist auf eine schlechte Frequenzfiltercharakteristik und die 

20MHz-Abstände der Störungsmaxima auf die Frequenzquelle der Mikrowelle 

zurückzuführen. 

3.2.3. Fazit 

Die Interferenz-Störeinflüsse wurden mittels Paketanalyse gut visualisiert, doch konnte durch 

die Anwendung der einzig verfügbaren Monitoring-Methode Airsniffing auftretenden 

Paketverluste kein eindeutiger Zusammenhang zwischen den Anzahlen der gesendeten und 

empfangenen Pakete dargestellt werden. 

Der einleitend beschriebene Weg der Datenaufbereitung kann durch Verwendung einer 

Scriptsprache, wie Perl, für große Datenmengen optimiert werden, da eine begrenzte 

Datensatzkapazität von 65536 je Mappe in Microsoft Excel besteht und gegebenenfalls 

umfangreiche Datenmanipulationen große Rechenzeiten verursachen können. 

3.3 Durchsatzmessungen 

60

3.3.1. Motivation 

Aufgrund von Störungen durch Interferenzen, wie im vorangegangenen Kapitel 

veranschaulicht, kommt es generell bei einer Funkübertragung zur Verringerung der effektiv 

nutzbaren Bandbreite, da Information in verfälschten oder verlorenen Paketen nicht verwertet 

werden kann. Somit ist der unter gegebenen Bedingungen erreichbare Durchsatz ein 

Nachweis und Maß des Störeinflusses. Die nähere Untersuchung dieses Zusammenhangs 

stellt einen wichtigen Teil dieser Arbeit dar. 

Als interferierende Funktechnologie zu Bluetooth wurde WLAN gewählt, da eine Zunahme 

der parallelen Verwendung beider Standards in der Praxis zu verzeichnen ist. Die Wahl 

dieses, mindestens ebenso weit verbreiteten, Vertreters begründet sich im praktischen Bezug 

dieser Ausarbeitung. Ein oft zu findendes Beispielszenario ist hierfür ein Laptop mit 

Internetzugang mittels WLAN und gleichzeitige Datensynchronisation mit einem Handheld 

oder Versenden eines Druckauftrages an den kabellosen Office-Drucker über Bluetooth. 

Es soll in diesem Kapitel der Grad der gegenseitigen Beeinflussung beider 

Übertragungsverfahren betrachtet werden. 

3.3.2. Wahl eines geeigneten Programms 

Für die Durchsatzmessung ist ein spezielles Programm nötig, welches folgenden Ansprüchen 

genügt: 

- Darstellung des aktuellen Datendurchsatzes 

- Unterstützung der Transportprotokolle TCP und UDP 

- Festlegung von Durchsatzraten bei Verkehrserzeugung 

- Unterstützung der verwendeten Betriebssysteme 

- effektive Bedienbarkeit 

Eine Recherche nach diesen genannten Kriterien lieferte drei Programme in der näheren 

Auswahl, wobei die Wahl auf das letztgenannte fiel: 

- Qcheck von IXIA, http://www.ixiacom.com 

- Shareware-Version, somit erheblich eingeschränkte Funktionen (einige Funktionen 

komplett gesperrt, zeitlich begrenzter Stream, wertbegrenzte Traffic-Erzeugung) 

- keine direkte Erzeugung von Logfiles 

- primitive Bedienung 

- IPTraffic von ZTI, http://www.zti-telecom.com 

- Shareware-Version, begrenzte, zu kurze Nutzungsdauer von 14 Tagen 

- umfangreiches Funktionsspektrum mit vielen Einstellmöglichkeiten 

- übersichtliche Bedienung 

- Grafische Auswertung möglich 

- iPerf von NLANR, http://dast.nlanr.net/Projects/Iperf 

- Freeware 

- MS-DOS-Anwendung 

- sehr umfangreiches Funktionsangebot 

- sehr gute Dokumentation 

- einfache und effektive Bedienung 

61

Die Entscheidung fiel, aufgrund der genannten Beschränkungen, gegen die beiden 

erstgenannten Programme. Neben dem Aspekt, dass iPerf ein Freeware-Tool ist, spricht die 

flexible Anwendung als Terminal-Programm sehr für diese Wahl. Zur Messung stand die 

Version 1.7.0 zur Verfügung. 

Die Funktionsweise ist erwartungsgemäß einfach. iPerf arbeitet nach dem bekannten Client- 

Server-Modell. Ein Client erzeugt Traffic in Richtung des Servers, welcher lediglich 

Empfangsinformationen zurücksendet. Zuvor muss iPerf auf dem Empfangs-Rechner als 

Serverdienst gestartet werden. 

Das gesamte Funktionsangebot wird über Kommandozeilen erreicht. Hierbei ist unter 

anderem die einfache Parametereinstellung, das mögliche Zusammenfassen in Batchdateien, 

freie Namensgebung für die Aufzeichnungsdateien und optionale direkte Überwachung im 

Terminalfenster von großem Vorteil. Die hauptsächlich benutzten Einstellungs-Parameter 

waren: 

- gewünschtes Transportprotokoll (TCP/UDP) 

- Zuweisung der Server-/Client-Rolle 

- Überwachungsintervall im Log (Bildschirm wie Datei) 

- Ziel- und bei Bedarf (mehrere Netz-Adapter) Quell-IP 

- Bandbreite und Dauer des erzeugten Verkehrs 

Abbildung 3.8 – Parameter des iPerf-Aufrufs 

3.3.3. Vorbereitung des Experiments 

62

Folgende Geräte standen unter Windows 2000/XP zur Verfügung: 

- ACER BT500 USB (Class 2), Bluetooth (v1.1) (2 Stück) 

- ComOne Bluetooth PC-Card (Class 1), Bluetooth (v1.1) 

- D-Link DBT120 USB (Class 3), Bluetooth (v1.1) 

- Toshiba BT-PC-Card PA3053 (Class 1), Bluetooth (v1.1) (2 Stück) 

- Toshiba Portegé3500 Laptop (Class 2), Bluetooth (v1.1)/WLAN (IEEE802.11b) integr. 

- 3com Airconnect WLAN PC-Card (IEEE802.11b) 

- HP OmniBook 4000series (2 Stück) 

Bluetooth-Anwender-Software: 

- Widcomm Vers 1.4.3.4 (weit verbreitet) 

- Toshiba Vers 3.00.12 (nur für Toshiba-Geräte) 

- ComOne Treiber und Zugangssoftware 

Ausgehend vom zitierten Beispiel zur parallelen Kommunikation von WLAN und Bluetooth, 

wurde der als praxisnah angestrebte Aufbau mit drei Laptops festgelegt. Dabei musste der 

leistungsstärkste (CPU- und Batteriekapazität) der drei zur Verfügung gestandenen Laptops, 

somit der Toshiba, beide Übertragungen über WLAN und Bluetooth durchführen. 

Dementsprechend war die Rollenverteilung der Laptops festgelegt, wobei der interne WLAN- 

Adapter des Toshiba-Laptops problemlos zur Kommunikation mit der 3com-PC-Card 

eingesetzt werden konnte. Aus den verbliebenen Bluetooth-Geräten mussten die 

verlässlichsten ausgewählt werden. Von der weiteren Verwendung der Adapter von ComOne 

und D-Link wurde aufgrund von Kompatibilitätsproblemen und, bereits durch FTS-Messung 

festgestellten, hohen Fehlerraten, auch bei ungestörter Umgebung, abgesehen. Des Weiteren 

wurden die Bluetooth-Adapter-Sets aufgrund der durch den selbigen Hersteller und die 

gleiche Treiberversionen garantierten Interoperabilität favorisiert. Aufbauend auf 

vorangegangene Tests war die schlechte Performance, hinsichtlich Reichweite und Durchsatz, 

der ACER BT500 USB bereits bekannt. Somit wurde das Toshiba PA3053 PC-Card-Set für 

den Versuch verwendet. 

Nachdem die Festlegung der Aktoren erfolgt war, mussten Überlegungen zu einer 

aussagekräftigen Konstellation gemacht werden. Für einen praxisnahen Anwendungsfall 

sollte der Abstand der Bluetooth-Geräte vorwiegend geringer als der der WLAN-Geräte sein. 

Da hier aber Bluetooth-Class-1-Geräte verwendet wurden, sollte auch die Kommunikation 

über eine größere Distanz gewählt werden, um überhaupt eine gewisse Signalabschwächung 

zu erreichen. Es müssen die Senderichtungen in Bezug auf die sich störenden Verbindungen 

betrachtet werden, da beispielsweise ein sendendes Gerät den gleichzeitigen Empfang mittels 

der anderen interferierenden Übertragungstechnik stören kann. Demzufolge mussten 

signifikante Positionen der Geräte für den Freifeldversuch gefunden werden. 

Die Wahl des Übertragungsprotokolls fiel mit Blick auf den Praxisbezug, entgegen der 

üblichen Verwendung von UDP in Netzwerkdurchsatzmessungen, schnell auf TCP. Die 

Messdauer sollte für eine gute Messwertmittlung entsprechend lang sein, da verschieden 

starke Schwankungen in den umfangreichen Testmessungen zu registrieren waren. 

3.3.4. Messaufbau 

Die aufgeführten Vorüberlegungen bestimmten die folgenden, für das Experiment unter 

Windows 2000/XP verwendeten Geräte. 

Für die Bluetooth-Kommunikation: 

- HP OmniBook 4000series mit Toshiba PA3053 PC-Card (Bluetooth v1.1, Class 1) 

63

- Toshiba Portegé3500 mit Toshiba PA3053 PC-Card (Bluetooth v1.1, Class 1) 

- Toshiba Bluetooth-Software Vers 3.00.12 

Für die WLAN-Kommunikation: 

- Toshiba Portegé3500 mit integriertem WLAN-Adapter (IEEE 802.11b) 

- HP OmniBook 4000series mit 3com AirConnect PC-Card WLAN (IEEE 802.11b) 

Abbildung 3.9 – Anordnung (Schema) 

Repräsentative Distanzen, welche von den beiden Tranceivern der jeweiligen 

Übertragungstechnologie im gestörten Fall überbrückt werden müssen, wurden in den 

Vorraustests ermittelt. Bei WLAN handelt es sich um die beiden Entfernungsstufen 20 und 40 

Meter, welche in den vorbereitenden Tests zu den Störeinflüssen kaum überschritten wurden. 

Für Bluetooth sind drei praxisnahe Stufen mit 1, 20 und 40 Meter festgelegt worden. Da es 

sich beim Bluetooth-Kommunikationspaar um die sendeleistungsstärkste Geräteklasse 

handelt, stellt dies die ungünstigste Störung von WLAN dar. 

Die beiden Übertragungstechniken sind richtungsabhängig zu betrachten und somit ergeben 

sich mit je zwei Richtungen vier Kombinationen. 

Der Richtungssinn des erzeugten Datenverkehrs wurde dabei auf den Toshiba-Laptop, 

welcher beide Technologien nutzt, bezogen. Somit stellt dieser für alle weiteren 

Betrachtungen den einzigen Bezugspunkt dar, woraus folgendes Bezeichnungsformat 

resultiert: 

- Bluetooth in – Bluetooth-Verkehr zum Toshiba-Laptop hin, kurz: Bi 

- Bluetooth out – Bluetooth-Verkehr vom Toshiba-Laptop weg, kurz: Bo 

- WLAN in – WLAN-Verkehr zum Toshiba-Laptop hin, kurz: Wi 

- WLAN out – WLAN-Verkehr vom Toshiba-Laptop weg, kurz: Wo 

Abbildung 3.10 – Konstellationen bei Durchsatzmessung 

Zusammengefasst ergaben sich aus daraus folgende Bezeichnungen der vier Kombinationen 

gleichzeitiger Kommunikation: 

- Bi/Wi 

- Bi/Wo 

- Bo/Wi (Toshiba-Laptop sendet über Bluetooth und empfängt mittels WLAN) 

- Bo/Wo 

64

In jeder dieser Senderichtungskombinationen müssen jeweils die 6 möglichen Distanz- 

Kombinationen realisiert werden. Zusätzlich wurde der Messaufbau in der Positionierung der 

beiden HP-Laptops zueinander verändert. Befanden sich diese beiden Laptops aus Sicht des 

Toshiba-Laptops in der gleichen Himmelsrichtung, entsprach dies dem eingeführten Winkel 

α=0 Grad zwischen ihnen. Der umgekehrte Fall mit α=180 Grad entsprach der Anordnung in 

entgegen gesetzten Himmelsrichtungen. Bei α=0 Grad waren die größten und entsprechend 

bei α=180 Grad die geringsten Interferenzen zu erwarten. 

Die aus diesen Vereinbarungen resultierenden Einzelmessungen charakterisieren sich also 

durch: 

- die jeweilige Entfernungsstufe der beiden Übertragungstechnologien, 

- die Kombination der Senderichtungen und 

- die Ausrichtung der beiden HP-Laptops zueinander (Winkel α). 

Dies entspricht einer Summe von 48 Einzelmessungen. Da weiterhin zum Vergleich jeweils 

die ungestörten, maximal erreichbaren Durchsatzraten in den 5 jeweiligen Stufen der 

Reichweiten ermittelt werden müssen, erhöht sich die Gesamtzahl der verschiedenen 

Einzelmessergebnisse auf 53, die mindestens durchgeführt werden müssen. 

Entsprechend der vorausgegangenen Tests, fielen die Erwartungen an die erreichbaren 

Durchsätze unterschiedlich aus. Es hatte sich hierbei schon gezeigt, dass Bluetooth weniger 

stark von einer parallelen WLAN-Verbindung beeindruckt wird. 

3.3.5. Durchführung 

Zum eigentlichen Experiment wurde sich, entsprechend der o. g. Charakterisierung, auf eine 

tabellarische Übersicht der Einzelmessungen geeinigt. Diese war ebenfalls Grundlage für eine 

einheitliche Namensgebung für die Aufzeichnungsdateien. 

Für die Durchsatzmessung sollte IP-Traffic generiert werden, welcher in Falle von Bluetooth 

über eine Netzwerkverbindung des Kommunikationspaares (Dienst: Netzwerkzugang) 

verwirklicht wurde. 

Dementsprechend lag die weitere Vorbereitung in der Erstellung von Batchdateien. Diese 

wurden für jedes einzelne Messszenario und jeden der drei Laptops spezifisch vorgefertigt, 

um am Messort effektiv und mit weniger Fehlerquellen arbeiten zu können. Sie enthielten die 

iPerf-Kommandozeile mit den charakteristischen Parametern wie Rollenzuweisung 

(Client/Server), Ziel- sowie bei Bedarf Quelladresse, Transportprotokoll, Wert zu erzeugender 

Bandbreite, Messintervall von 0,5 Sekunden, den Namen der Log-Datei und Dauer der 

Messung. Letztere wurde auf 60 Sekunden festgelegt, da dies der Forderung nach 

repräsentativen Mittelwerten genügt. 

Beispiel-Kommandozeile Bluetooth-Client: 

iperf -c 192.168.81.2 -B 192.168.81.1 -i 0.5 -t 60 > TCP_Bi1_Wi20_bt.txt 

Im oben abgebildeten Beispiel ist der iPerf-Aufruf mit der Client-Option und dazugehöriger 

Zieladresse des Servers (-c 192.168.81.2), Bindung auf einen Ausgangs-Netzwerkadapter (-B 

192.168.81.1), Intervall der Darstellung der Messwerte (-i 0.5), Dauer der Verkehrserzeugung 

und –messung (-t 60) und der Export in eine benannte Aufzeichnungsdatei 

(>TCP_Bi1_Wi20_bt.txt) zu sehen. 

65

Beispiel-Kommandozeile Bluetooth-Server: 

iperf -s -B 192.168.81.2 

Auf der Gegenseite wird der entsprechende Server, wie gezeigt, durch die Server-Option (-s) 

und der Bindung an den überwachten Ausgangs-Netzwerkadapter (-B 192.168.81.2) initiiert. 

Die möglichen Störeinflüsse der Umgebung, wie z.B. anderer ISM-Funk, wurden bei der 

Ortswahl für die Freifeldmessung weitestgehend minimiert. Um die Affinität der Ergebnisse 

zu gewährleisten wurden die Messbedingungen so weit durchführbar konstant gehalten. So 

blieb z.B. der Bodenabstand der kommunizierenden Komponenten bei einem Meter und die 

Aufstellung der Geräte wurde jeweils auf den, immer an selbiger Position aufgestellten, 

Bezugslaptop ausgerichtet. 

Jede, etwa 2 Minuten durch Umpositionierung und Messzeit in Anspruch nehmende, 

Einzelmessung wurde mindestens dreimal, aber auch bis zu zehnmal durchgeführt, was die 

Anzahl der gesamt durchgeführten einzelnen Messungen auf wenigstens 159 brachte, damit 

immer mehrfach bestätigte Ergebnisse verwendet werden konnten. Durch den 

ausschließlichen Batterie-Betrieb der Laptops im Freifeld war ein Messzyklus auf etwa 2 

Stunden beschränkt. Hierdurch erklärt sich die Verteilung auf mehrere Messtage. Somit 

mussten die Tageszeit und Wetterbedingungen zum Messzeitpunkt für alle einzelnen 

Messungen ähnlich realisiert werden. 

3.3.6. Auswertung 

Nachdem alle Messungen abgeschlossen waren, wurde mit der Auswertung der Ergebnisse 

begonnen. Aus den entsprechenden Log-Dateien wurden, mit jeweils 5 Sekunden Toleranz an 

Anfang und Ende, nur 50 Sekunden der Aufzeichnung aufbereitet, um den nicht immer 

gleichzeitigen Start der parallelen Kommunikationen zu berücksichtigen. Die von der 

jeweiligen Übertragungstechnik erreichten Durchsätze sind anteilmäßig an der ungestörten 

Verbindung aufgetragen worden. Diese Darstellung wurde zweckmäßig für eine 

übersichtliche und prägnante Präsentation der Ergebnisse bestimmt. 

Es gab zur Darstellung der Resultate natürlich alternative Wege, welche allerdings unter 

anderem aufgrund von eingeschränkten Vergleichsmöglichkeiten einzelner Zusammenhänge 

und zu aufwendigem Gesamtvolumen nicht zur Anwendung kamen. 

66

Abbildung 3.11 – Auswertungstabelle zu α = 180° 

Abbildung 3.12 – Auswertungstabelle zu α = 0° 

Hier dargestellt ist der relative Durchsatz beider Übertragungstechniken in Bezug auf die 

distanzabhängig jeweils ermittelte maximal erreichbare ungestörte Datenrate in kbit/s. Die 

Messergebnisse sind aufgrund des verwendeten Überwachungstools iPerf in gewisser Weise 

quantisiert und wurden bei Werten größer als 1000kbit/s in Mbit/s ausgegeben und 

entsprechend gerundet. Eine erzwungene Ausgabe in kbit/s hätte keine größere Genauigkeit 

erzielt, da im Programm nur nachträglich in die entsprechende Einheit umgewandelt worden 

wäre. Eine ausreichende Messgenauigkeit für die Darstellung der gefundenen 

Zusammenhänge ist durch diesen Fakt nicht gefährdet. 

67

Zur besseren Veranschaulichung der einzelnen Spalten der tabellarischen Darstellung der 

Messergebnisse in Abhängigkeit der beiden Ausrichtungen der äußeren Laptops seien hier 

noch einmal die vier Senderichtungskonstellationen mit den jeweils eingenommenen 

Entfernungsstufen und Ausrichtungswinkeln schematisch illustriert. 

Bo/Wi: 

oder 

Abbildung 3.14 – Messwerte in Bo/Wi 

68 

Abbildung 3.13 – Konstellation Bo/Wi 

Wie den obigen Tabellen zu entnehmen, ist in dieser Konstellation der Senderichtungen der 

ungünstigste Fall für die WLAN-Kommunikation eingetreten, da der Bezugs-Laptop WLAN 

empfängt und gleichzeitig Bluetooth sendet. Sobald WLAN zusammenbrach, konnte 

Bluetooth nahezu ungestört senden. Gerade in der gleichrichtigen Anordnung der äußeren 

Laptops ist die Unterdrückung durch das robuste Bluetoth-Sprungverfahren sehr gut zu 

erkennen. Die Bluetooth-Durchsatzeinbrüche bei geringerer oder gleicher Weite mit WLAN 

sind einerseits durch größere Störanfälligkeit bei größerer Weite und andererseits bei α = 180 

Grad mit dem weiteren Abstand zum sonst stärker unterdrückten WLAN zu erklären. 

Bi/Wi: 

oder 

Abbildung 3.16 – Messwerte Bi/Wi 

Abbildung 3.15 – Konstellation Bi/Wi

Der WLAN-Verkehr hat bei dieser direkten Konkurrenz der Signale kaum eine Chance zu 

bestehen. Im Falle ankommenden Funks beider Standards sind die direkte Abschwächung bei 

größeren Entfernungen und der geringere Einfluss der Winkelausrichtung klar ersichtlich. Die 

dennoch besseren Bluetooth-Ergebnisse für α = 0 Grad sind mit öfter aussetzenden WLAN- 

Funk zu begründen. 

Bo/Wo: 

oder 

Abbildung 3.18 – Messwerte Bo/Wo 

69 

Abbildung 3.17 – Konstellation Bo/Wo 

In dieser Konstellation ebenfalls übereinstimmender Senderichtungen ist die, gegenüber den 

beiden anderen genannten stärkere Schwächung von Bluetooth sichtbar. Dies ist darin 

begründet, dass beide Bluetooth-Transceiver vor dem Beginn der Taffic-Generierung und - 

Messung die bei geringem Abstand minimal mögliche Sendeleistung, zum Zwecke der 

Stromverbrauchsoptimierung, ausgehandelt haben, da weit weniger störender WLAN-Einfluss 

bestand. Nichtsdestoweniger war der Anteil an den möglichen Durchsätzen bei Bluetooth in 

allen entsprechenden Einzelmessungen (teilweise noch erheblich) größer als beim 

konkurrierenden WLAN. 

Bi/Wo: 

oder 

Abbildung 3.20 – Messwerte Bi/Wo 

Abbildung 3.19 – Konstellation Bi/Wo

Diese vierte und letzte betrachtete Konstellation stellt, wie schon in den 

Gesamtergebnistabellen zu erkennen, den ungünstigsten Fall für die Bluetooth-Übertragung 

dar. Hier wirkt sich ebenfalls die vor dem jeweiligen Test verringerte Bluetooth- 

Sendeleistung negativ aus. Das vom gleichzeitigen Bluetooth-Empfänger gesendete WLAN- 

Signal kann daher bei geringen Abständen der Bluetooth- und WLAN-Geräte das 

ankommende Signal des Bluetooth-Senders erheblich mehr stören. Hierfür wirkt sich die 

gleichrichtige Aufstellung der äußeren Laptops in allen Entfernungskombinationen ebenfalls 

WLAN-günstig aus. 

3.3.7. Fazit 

In erster Linie ist zusammenfassend die erschreckend starke Durchsatzeinbuße von WLAN in 

allen Tests zu erkennen. Gerade in den Fällen ankommenden WLAN-Verkehrs (Wi) am 

Bezugs-Laptop ist mit dem nahezu totalen Verlust der hierüber gesendeten Daten zu rechnen. 

Ebenso leicht ist die erwartungsgemäße Abhängigkeit der Störanfälligkeit der WLAN- 

Transceiver von ihrer Entfernung zueinander in allen Senderichtungs-Konstellationen 

ersichtlich. Auch die verwendeten Winkelanordnungen erfüllten mit den erreichten Werten 

die gesetzten Erwartungen, dass gleiche Ausrichtung zum gemeinsamen 

Kommunikationspartner, also schlimmste gegenseitige Störung, die „Überlegenheit“ der 

Bluetooth-Übertragung hervorhebt. Die geringeren Bluetooth-Durchsatzraten bei gleichen 

Konstellationen und entgegen gesetzter Ausrichtung sind daher durch geringer gestörten 

WLAN-Verkehr zu begründen. Die Dominanz von Bluetooth verdeutlicht sich auch in dem 

Aspekt, dass diese Technologie, entgegen WLAN, in nahezu allen Einzelmessungen 

mindestens halben und sogar in mehr als der Hälfte aller Tests wenigstens drei viertel des 

möglichen Durchsatzes erreicht hat. 

Dieses teilweise überraschend extreme Ergebnis unterstreicht die Forderung nach einer für 

anderen ISM-Funk verträglicheren Bluetooth-Funktechnologie. Folgend soll dieser 

Zusammenhang noch einmal kurz in einer Gegenüberstellung von Parallelbetrieb gestörtem 

und ungestörtem Datenverkehr zusammengefasst werden. 

3.4 Cross Measurements 

3.4.1. Einführung 

Als kleine eigenständige Verdeutlichung des im obigen, sehr komplexen Versuch 

dargestellten Zusammenhangs von Durchsatz der beiden ISM-Übertragungstechniken 

Bluetooth und WLAN und ihrer gegenseitigen Beeinflussung soll in diesem Abschnitt der 

direkte Vergleich von ungestörtem und parallelen Betrieb dieser kurz gezeigt werden. 

Es wurden die Konsequenzen für den aktuellen Durchsatz beider Technologien in zwei aus 

dem Ergebnis des Hauptexperiments ausgewählten Konstellationen untersucht. Hierfür 

wurden die verwendete Hardware und die weiteren Messparameter beibehalten. 

Die Entfernungsstufen 1 Meter für Bluetooth und 20 Meter für WLAN, sowie TCP als 

Transportprotokoll wurden aufgrund des schon erwähnten geforderten Praxisbezugs 

festgelegt. Es fand die Analyse in zwei unterschiedlichen Senderichtungskonstellationen, 

wobei je eine die ungünstigste für einen der beiden Funktechnologien darstellt. 

70

1. Fall - ungünstigste Senderichtungskonstellation für Bluetooth: 

Über Bluetooth wird vom Bezugs-Laptop empfangen und über WLAN gesendet. 

Abbildung 3.21 – Anordnung Cross Measurement 1 

2. Fall - ungünstigste Senderichtungskonstellation für WLAN: 

Der Bezug-Laptop sendet Bluetooth und empfängt WLAN. 

3.4.2. Visualisierung 

Abbildung 3.22 – Anordnung Cross Measurement 2 

Über eine Gesamtmesszeit von 90 Sekunden wurde in beiden Messungen erneut über beide 

Verbindungen 60 Sekunden lang Datenverkehr erzeugt und der Durchsatz in 0,5-Sekunden- 

Intervallen überwacht. Hierbei wurde jeweils die am meisten durch eine Parallelübertragung 

gehinderte Funktechnologie 30 Sekunden vor der anderen, als begünstigt erwarteten, gestartet. 

Wie in den folgenden Darstellungen gut zu erkennen ist, erfüllte sich hierbei ebenfalls die 

Aussicht auf den mit Bluetooth verglichen stärkeren Zusammenbruch des WLAN- 

Durchsatzes. 

Abbildung 3.23 – Darstellung Fall 1 

71

3.4.3. Fazit 

Abbildung 3.24 – Darstellung Fall 2 

Bluetooth hatte erwartungsgemäß erheblich geringeren Einbruch der Datenrate aufgrund 

seines robusten Übertragungsverfahrens zu verzeichnen. Dagegen ist der WLAN-Durchsatz 

überraschend deutlicherer als erwartet eingebrochen, sowie ein Verbindungsverlust auch in 

der für Bluetooth ungünstigeren Anordnung eingetreten. Dies bestätigt die Aussage zum 

generellen Problem der Koexistenz von BT mit anderen ISM-Funkstandards, welche kein 

ähnliches Frequenzsprungverfahren anwenden. 

Eine Lösung bietet das AFH (Adaptive Frequency Hopping). Hierbei erkennen die Bluetooth- 

Transceiver gestörte/belegte Frequenzen. Dies geschieht mittels der Einführung einer Pico- 

Netz-spezifischen Kanalliste, welche vom Master verwaltet wird und gegebenenfalls durch 

Anfordung lokaler Statusreporte aller AFH-fähigen aktiven Slaves die von der Sprungsequenz 

auszuschließenden sowie alle als ungestört erkannten Kanäle mit der entsprechenden 

Kennzeichnung speichert. 

Die Konsequenz der Anwendung dieser Kanalliste ist das Ausweichen auf die offensichtlich 

ungestörten Frequenzen und die Meidung dieser für die Sprungsequenz, welche in Form von 

gleichem Kanal für Hin- und Rückslot eines Master-Slave-Master-Paketaustauschs – Same- 

Channel-Method – abgeändert wird. 

Dieses erweiterte Sprungverfahren ist in der im November 2003 von der Bluetooth-SIG 

verabschiedeten Version 1.2 enthalten. Zum Zeitpunkt dieser Arbeit waren erstaunlicherweise 

noch keine entsprechenden Geräte oder Firmwareupdates für weitere Tests verfügbar. 

Im folgenden, letzten Kapitel wird detailliert auf die Funktionsweise dieses 

interferenzvermeidenden Verfahrens eingegangen. 

72

Kapitel 4 - Die Funktionsweise von AFH 

4.1 Einleitung 

In diesem Kapitel soll die allgemeine Funktionsweise dieses neuen, adaptiven 

Frequenzsprung-Verfahrens erläutert und am Beispiel der verbesserten Koexistenz von 

Bluetooth und WLAN verdeutlicht werden. 

4.2 Motivation 

Bluetooth-Geräte der Vorgängerversionen, welche das konventionelle Frequenzsprung- 

Verfahren (FFH) anwenden, nutzen immer alle 79 festgelegten Kanäle des 2,4GHz-ISM- 

Bandes (Ausnahme Frankreich, Japan usw.). Dabei wird der Kanal 1600 Mal pro Sekunde in 

einer zufälligen Sprung-Reihenfolge gewechselt. 

Sobald ein anderer Funkverkehr, wie WLAN, in der Umgebung vorhanden ist, führt diese Art 

des Frequenzsprunges unweigerlich zu unregelmäßigen Kollisionen. Ohne AFH war bisher 

keine Möglichkeit gegeben, sich der Umgebung anzupassen und somit diese Konflikte zu 

verhindern. Die folgende Illustration offenbart die resultierenden Interferenzen. Hierbei sei 

kurz angemerkt, dass WLAN (IEEE 802.11b) eine Bandbreite von 20MHz vereinnahmt und 

kein Frequenzsprung-Verfahren anwendet. 

Abbildung 4.1 – Überlagerung BT und WLAN 

73

Im Gegensatz zur obigen, findet in der folgenden Illustration eine Bluetooth-Kommunikation 

der neuen Generation statt. Das in Bluetooth v1.2 verwendete Adaptive Frequency Hopping 

ermöglicht nun eine Anpassung an die Umgebung. Hierbei werden die Kanäle, welche durch 

andere Interferenz-Quellen belegt sind, im Frequenzsprung-Verfahren ausgeschlossen. Dieser 

Prozess des „Re-Mappings“ beinhaltet somit auch eine Reduzierung der Anzahl der vom 

Kabelkiller nutzbaren Kanäle. Dabei ist die Mindestzahl dieser Kanäle durch die 

Spezifikation auf 20 beschränkt. Während der Verwendung von AFH ist die Same-Channel- 

Method, worin ein Slave-to-Master-Slot im selben Frequenzkanal wie der vorangegangene 

Master-to-Slave-Slot liegt, vorgeschrieben. Es wird am Ende dieses Kapitels näher darauf 

eingegangen. 

Abbildung 4.2 – Ausweichen vor WLAN durch AFH 

4.3 Klassifikation der Frequenzkanäle 

4.3.1. Channel-Classification 

Jedes AFH-fähige Bluetooth-Gerät kann individuell eine so genannte Channel-Classification 

durchführen. Es findet hierbei eine Klassifikation statt, welche jeden einzelnen Kanal als 

„unknown“, „good“ oder als „bad“ einstuft. Diese Entscheidung wird anhand der lokalen 

Information möglicher Interferenzen getroffen, welche auf folgende Weise erworben werden 

kann: 

Kanal-Einschätzung (Channel-Assessment): 

Alle 79 spezifizierten Kanäle (Kanal = 1MHz) werden auf mögliche Interferenz-Quellen 

abgesucht. Zwei häufig genutzte Detektionsmethoden sind: 

- RSSI (Received Signal Strength Indication), aktiv 

74

- PER (Packet Error rate), passiv 

Ausschluss belegter Kanäle durch Host-Controller: 

Beispielsweise bei einem Laptop mit WLAN und Bluetooth parallel in Betrieb, kann der Host- 

Controller dieses Gerätes via HCI-Befehl das Auslassen der von WLAN belegten Frequenzen 

anordnen. (Host-Controller weiß, ob WLAN in Nutzung ist und welche Frequenzen es belegt) 

� AFH-Host-Channel-Classification 

Die bereits erwähnte Klassifikation jedes einzelnen Kanals erfolgt nach bestimmten Kriterien: 

Unknown: Die Messungen der Kanal-Einschätzung (Channel-Assessment) sind nicht 

ausreichend, um eine verlässliche Einstufung des Kanals zu gewährleisten. 

Bad: Das Channel-Assessment detektiert Interferenzquellen oder es erfolgte ein 

Ausschluss des Kanals durch Host-Controller des Geräts. 

Good: Der Kanal ist weder als „unknown“ noch als „bad“ eingestuft. 

4.3.2. Channel-Map 

Der Master eines Piko-Netzes, in dem das adaptive Frequenzsprung-Verfahren eingesetzt 

wird, muss eine AFH-Channel-Map erstellen, welche eine Aufstellung von Kanälen enthält, 

die bei der adaptierten Sprungsequenz genutzt werden dürfen oder ausgelassen werden 

müssen. Diese Liste kann er anhand der Kombination folgender Informationsquellen erstellen: 

• Lokal, mittels seiner eigenen Channel Classification (Channel-Assessment oder HC) 

• Von ausgewählten aktiven Slaves, die im verwalteten Netz AFH nutzen, via LMP- 

Kommandos angeforderter Channel-Classification-Reports (CCR) 

Die Anforderung der CCR eines bestimmten AFH-Slaves erfolgt durch die vom Master 

gesendete LMP_channel_classification_req-PDU, welche folgende drei Parameter beinhaltet: 

• AFH_Reporting_Mode Aktivierung fortlaufender CCR oder Deaktivierung CCR 

• AFH_Min_Interval Wert für die Mindestzeit zwischen zwei CCR 

• AFH_Max_Interval Wert für die Maximalzeit zwischen zwei CCR 

4.3.2.1. Channel-Classification-Report 

Ein Channel-Classification-Report des Slaves erfolgt in einer LMP_channel_classification- 

PDU, in der die erworbene Information in folgender Weise dem Master übermittelt wird. 

Die 79 spezifizierten Frequenzkanäle sind von 0 bis 78 durchnummeriert. Im Rahmen der 

Channel-Classification wird jedem Kanal n ein binärer Wert zugeordnet, welcher die 

Kanaleinstufung definiert: 

„unknown“ � 00 „bad“ � 11 

„good“ � 01 (10 ist reserviert) 

Die besagte PDU verfügt nur über 40 2-Bit-Felder, welche mit 0 bis 39 indexiert sind. Ein 

Feld mit dem Index n definiert die Klassifikation der Kanäle 2n und 2n+1. Eine Ausnahme 

75

ildet das Feld 39, welches nur die Einstufung des Kanals Nr.78 beinhaltet. Dies bedeutet (mit 

Ausnahme Feld 39) eine Kombinierung der Kanaleinstufungen eines „geraden“ und dem 

unmittelbar folgenden „ungeraden“ Kanals. Dabei sind folgende Festlegungen getroffen: 

„good“ (01) und „good“ (01) � „good“ (01) 

„good“ (01) und „unknown“ (00) � „good“ (01) 

„bad“ (11) und „bad“ (11) � „bad“ (11) 

„bad“ (11) und „unknown“ (00) � „bad“ (11) 

„unknown“ (00) und „unknown“ (00) � „unknown“ (00) 

„good“ (01) und „bad“ (11) � Implementierungsache 

Ein Slave, welcher sich in einem aktivierten AFH-Reporting-Mode befindet, übermittelt 

fortlaufend dem Master, in seinem vorgegebenen Zeitintervall, seine Channel-Classification 

(PDU). Dies tut er solange, bis der Master das CC-Reporting deaktiviert. 

Abbildung 4.3 – LMP Channel Classification Befehle 

Wann und ob ein Master überhaupt die regionalen Kanaleinstufungen von Slaves, bei seiner 

Erstellung der AFH-Channel-Map, in Anspruch nimmt, ist von der Spezifikation nicht 

vorgeschrieben und somit ist die Implementierung dem Hersteller überlassen. Darüber hinaus 

sind auch keine Festlegungen für den Algorithmus der AFH-Channel-Map-Generierung 

getroffen, doch darf die Mindestzahl von 20 erlaubten Kanälen nicht unterschritten werden. 

4.4 Channel-Map-Übermittlung und Aktivierung von AFH 

Die fertig generierte AFH-Channel-Map (ChM) besteht aus 79 1-Bit-Feldern wobei jedes Feld 

den Wert „0“ für entsprechender Kanal ist erlaubt (used) oder „1“ für verboten (unused) 

enthält. Diese wird anschließend vom Master über den LMP-Befehl „LMP_set_AFH“-PDU 

einzeln an alle AFH-tauglichen Slaves seines Piko-Netzes gesendet. Diese Slave-spezifische 

PDU enthält folgende Kommandos: 

• AFH_Instant: Wert für den Zeitpunkt der Übernahme der neuen ChM 

(welche zeitgleich im gesamten Piko-Netz erfolgen muss) 

76

• AFH_Mode: AFH-Aktivierung oder -Deaktivierung für diesen Slave 

(Verbindungsaufbau mit v1.1-Frequnzauswahl und 

anschließende Aktivierung von AFH möglich); 

• AFH_Channel_Map: enthält aktuelle ChM; 

Nachdem alle AFH-aktivierten Transceiver nun über die aktualisierte Kanalliste verfügen, 

muss jeder einzelne seine Sprungreihenfolge zum vorgegebenen Zeitpunkt so abändern, dass 

die verbotenen Kanäle ausgelassen werden (Hop Sequence Modification). 

Diese Modifikation erfolgt nach einem bestimmten Algorithmus, wodurch sichergestellt wird, 

dass alle Teilnehmer in Zeit und Frequenz synchronisiert bleiben. 

4.4.1. Frequenzauswahl 

Der so genannte Adapted-Hop-Selection-Kernel, welcher die Frequenz (Kanal) für den 

nächsten Zeitschlitz bestimmt, basiert auf dem bewährten Kernel von Bluetooth 1.1 

(unverändert übernommen), welcher durch eine Re-Mapping-Funktion ergänzt wurde. Alle 

Inputs des adaptiven Sprung-Auswahl-Kernels, mit Ausnahme der hinzugefügten Kanalliste, 

sind identisch mit dem nicht-adaptiven der Version 1.1. Die folgende Abbildung zeigt den 

Ablaufplan, wie dieser neue Kernel, unter Berücksichtigung der AFH-Channel-Map, die 

Auswahl des nächsten zu nutzenden Kanals trifft. 

Quelle: Bluetooth 1.2 Core Specification 

Abbildung 4.4 – Frequenzwahl bei AFH 

Der Ablauf der Bestimmung eines Frequenz-Kanals ist wie folgt: 

Der grundlegende Hop-Selection-Kernel 1.1 wählt pseudo-zufällig (aus Geräte- 

Adresse des Masters abgeleitet) einen Kanal fk. Dieser wird anschließend einer 

Abfrage unterzogen, ob er zu dem gegebenen Satz von nutzbaren Kanälen in der 

AFH-Channel-Map zählt. Das Ergebnis entscheidet ob die Re-Mapping-Funktion 

angewendet werden muss: 

fk ist ein zulässiger Kanal � fk wird für den nächsten Zeitschlitz genutzt 

77

fk ist ein verbotener Kanal� durch einen bestimmten Algorithmus (Bluetooth 

1.2 Core Specification Vol 2 Part B Seite 78) 

wird aus dem gegebenen Satz erlaubter Kanäle 

ein alternativer Kanal fk’ gewählt, der für den 

nächsten Zeitschlitz verwendet wird. 

4.4.2. Nicht-adaptive Slaves 

Aus den vorangegangenen Ausführungen wird ersichtlich, dass die nicht-adaptive 

Sprungsequenz immer mit der adaptiven identisch ist, sobald erlaubte Kanäle durch den 1.1er 

Hopping-Kernel generiert werden. Diese Eigenschaft ermöglicht es nicht-adaptiven Slaves 

eines Piko-Netzes synchronisiert zu bleiben, wobei die restlichen Slaves die adaptive 

Sprungsequenz nutzen. (Das Piko-Netz ist nun durch eine adaptive und eine nichtadaptive 

Sprungsequenz charakterisiert.) 


Es ist von bedeutender Notwendigkeit, dass ein Master die Channel-Map in bestimmten 

Zeitabständen aktualisiert. Dadurch wird erst eine adaptive Abänderung der Sprungsequenz 

eines Piko-Netzes, als Reaktion auf Veränderungen in dessen Einsatzumgebung 

(Interferenzquellen hinzu oder weg), möglich. 

Nationale Restriktionen bezüglich des ISM-Frequenzbandes werden bereits über den Host- 

Controller in die Kanalklassifikation übernommen. Für diesen Zweck existiert der HCI-Befehl 

HCI_Read_Country_Code. Dieser definiert in welchem Bereich des Frequenzbandes im 

jeweiligen Land Bluetooth operieren darf. Die bisherige Forderung nach einer 23-Kanal- 

Sprungsequenz in Ländern wie z.B. Frankreich und Japan konnte somit verworfen werden, 

wobei Japan zwischenzeitlich (in der Bluetooth-Spezifikation) nicht mehr als Land mit 

Frequenzbeschränkungen genannt wird. 

4.5 Same Channel Method 

Während des Einsatzes von AFH wird von der Bluetooth-Spezifikation 1.2 eine 

Gerätekommunikation nach der Same-Channel-Method zwingend vorgeschrieben. 

Hierbei findet die Übertragung eines Master-zu-Slave-Paketes und dessen unmittelbar 

folgenden Slave-zu-Master-Paketes auf demselben Kanal (gleiche Frequenz), und nicht wie 

gewohnt auf verschiedenen Kanälen, statt. Folgende Illustration soll diesen Sachverhalt näher 

verdeutlichen. 

78

Quelle: Bluetooth 1.2 Core Specification 

Abbildung 4.5 – Paketsequenz mit gleichen Frequenzen 

Durch Anwendung der Same-Channel-Methode reduzieren sich die Frequenzsprünge um 50 

Prozent in Bezug auf Single-Slot-Pakete, von ehemals 1600 auf 800 pro Sekunde. Bei 

Verwendung von Multi-Slot-Paketen verringert sich die Sprunganzahl je Zeiteinheit noch 

zusätzlich. Durch diese Abnahme der Frequenzwechsel wird die Anfälligkeit gegenüber 

zufälligen Störern erhöht, wobei der Gewinn dieses Verfahrens zum Ausweichen vor 

schmalbandigen permanenten Störungen diesen kleinen Nachteil überwiegt. 

Diverse Quellen begründen den Einsatz dieser Kommunikations-Methode mit: „Es soll der 

Fall vermieden werden, in dem der Master auf einer ‚guten’ Frequenz gesendet hat und die 

Antwort des Slaves auf einer gestörten Frequenz erfolgt, da dies zu zahlreichen 

Retransmissionen führt“, was allerdings bereits bei der Kanalauswahl auf Basis der ChM 

vermieden werden sollte. Diese Methode kann zur Klassifizirung der Kanäle genutzt werden. 

Erhält ein Slave kein oder ein fehlerhaftes Paket auf der ihm (durch die Sprungsequenz) 

bekannten Frequenz, kann er diese als gestört in seiner Channel-Classification einordnen 

(Packet-Error-Rate). Ebenso verhält es sich mit dem Master, welcher bei einem fehlenden 

oder fehlerhaften Antwortpaket des Slaves die verwendete Frequenz ebenfalls als gestört 

einstuften und gegebenenfalls auf Channel-Classification-Reports durch die Slaves verzichten 

kann. 

4.6 Abwärtskompatibilität zu Bluetooth 1.1 

Der neue Standard soll zu Bluetooth 1.1 abwärtskompatibel sein. Beispielsweise kann auch 

ein Bluetooth-1.1-Gerät, mit seiner nichtadaptiven Sprungsequenz, in einem Piko-Netz 

eingebucht sein, wo das rücksichtsvolle Adaptive Frequenzsprung-Verfahren in Benutzung 

ist, doch kann es darin nur als Slave agieren. Dies ist dadurch begründet, dass AFH zwingend 

einen AFH-fähigen Master voraussetzt, welcher die erlaubten bzw. verbotenen Frequenzen 

für die adaptive Sprungsequenz festlegt. Soll ein Bluetooth-1.1-Transceiver als Master eins 

Piko-Netzes agieren, kann kein AFH aktiviert werden und Slaves, die AFH unterstützen 

könnten, müssen das nichtadaptive Frequenzsprungverfahren anwenden. 

79

Abbildungen 

ABBILDUNG 1.1 – BLUETOOTH-KANÄLE IM ISM-BAND 

ABBILDUNG 1.2 – NATIONALE FREQUENZBESCHRÄNKUNGEN 

ABBILDUNG 1.3 – SCHMALBANDIGE STÖRUNG 

ABBILDUNG 1.4 – TIME SLOTS 

ABBILDUNG 1.5 – MULTISLOT-PAKETE 

ABBILDUNG 1.6 – VERNETZUNGSTOPOLOGIEN 

ABBILDUNG 1.7 – BETRIEBSMODI 

ABBILDUNG 1.8 – SCO-PAKETPERIODEN 

ABBILDUNG 1.9 – ACL-PAKETE BEI SCO-VERBINDUNG 

ABBILDUNG 1.10 – ACL-PAKETTYPEN 

ABBILDUNG 1.11 – ACL-PAKETPERIODEN 

ABBILDUNG 1.12 – GERÄTEPAARUNG (SCHEMA) 

ABBILDUNG 1.13 – SYMMETRISCHER DATENVERKEHR 

ABBILDUNG 1.14 – ASYMMETRISCHER DATENVERKEHR 

ABBILDUNG 1.15 – BEISPIEL: WLAN UND BT V1.1 INTERFERENZEN 

ABBILDUNG 1.16 – DIE PROTOKOLLARCHITEKTUR 

ABBILDUNG 1.17 – ANSCHLUSS AN EINEN HOST 

ABBILDUNG 1.18 – AUFBAU BLUETOOTH DEVICE ADRESSE 

ABBILDUNG 1.19 – ALLGEMEINER AUFBAU DER PAKETE IN BLUETOOTH 

ABBILDUNG 2.1 – MESSANORDNUNG AIRSNIFF 

ABBILDUNG 2.2 – SCREENSHOT FTS-STATISTICS DISPLAY 

ABBILDUNG 2.3 – SCREENSHOT FTS-FRAME DISPLAY 

ABBILDUNG 2.4 – SCREENSHOT FTS-PROTOCOL NAVIGATOR 

ABBILDUNG 2.5 – SCREENSHOT FTS-EVENT DISPLAY 

ABBILDUNG 2.6 – MSC-FRAME 1-6 




ABBILDUNG 2.10 – MSC-FRAME 24 






ABBILDUNG 2.16 – MSC-FRAME 68/69 





ABBILDUNG 2.21 – REICHWEITENVERGLEICH 1 

ABBILDUNG 2.22 – REICHWEITENVERGLEICH 2 

ABBILDUNG 2.23 – KANALNUTZUNG, VERLAUF 

ABBILDUNG 2.24 – KANALNUTZUNG, HISTOGRAMM 

ABBILDUNG 3.1 – BEISPIEL: WLAN UND BT V1.1 INTERFERENZEN 

ABBILDUNG 3.2 – MESSAUFBAU WLAN-EINFLUSS 

ABBILDUNG 3.3 – ZEITLICHER VERLAUF DER WLAN-STÖRUNG 

ABBILDUNG 3.4 – HISTOGRAMM DER WLAN-STÖRUNG 

ABBILDUNG 3.5 – MESSAUFBAU MIKROWELLE 

ABBILDUNG 3.6 – ZEITLICHER VERLAUF MIKROWELLENSTÖRUNG 

ABBILDUNG 3.7 – HISTOGRAMM MIKROWELLENSTÖRUNG 

ABBILDUNG 3.8 – PARAMETER DES IPERF-AUFRUFS 

ABBILDUNG 3.9 – ANORDNUNG (SCHEMA) 

ABBILDUNG 3.10 – KONSTELLATIONEN BEI DURCHSATZMESSUNG 

ABBILDUNG 3.11 – AUSWERTUNGSTABELLE ZU α = 180° 

ABBILDUNG 3.12 – AUSWERTUNGSTABELLE ZU α = 0° 

ABBILDUNG 3.13 – KONSTELLATION BO/WI 

ABBILDUNG 3.14 – MESSWERTE IN BO/WI 

ABBILDUNG 3.15 – KONSTELLATION BI/WI 

ABBILDUNG 3.16 – MESSWERTE BI/WI

ABBILDUNG 3.17 – KONSTELLATION BO/WO 

ABBILDUNG 3.18 – MESSWERTE BO/WO 

ABBILDUNG 3.19 – KONSTELLATION BI/WO 

ABBILDUNG 3.20 – MESSWERTE BI/WO 

ABBILDUNG 3.21 – ANORDNUNG CROSS MEASUREMENT 1 

ABBILDUNG 3.22 – ANORDNUNG CROSS MEASUREMENT 2 

ABBILDUNG 3.23 – DARSTELLUNG FALL 1 

ABBILDUNG 3.24 – DARSTELLUNG FALL 2 

ABBILDUNG 4.1 – ÜBERLAGERUNG BT UND WLAN 

ABBILDUNG 4.2 – AUSWEICHEN VOR WLAN DURCH AFH 

ABBILDUNG 4.3 – LMP CHANNEL CLASSIFICATION BEFEHLE 

ABBILDUNG 4.4 – FREQUENZWAHL BEI AFH 

ABBILDUNG 4.5 – PAKETSEQUENZ MIT GLEICHEN FREQUENZEN

QUELLEN 

[1] Bluetooth Specification - Core Specification v1.0B, 12-1999 

www.bluetooth.org/spec/ 

[2] Bluetooth Specification - Core Specification v1.1 vol 1, 02-2001 


[3] Specification of the Bluetooth System - Core Specification v1.2 vol 0-3, 11-2003 


[4] Vertiefungsarbeit Bluetooth, Tobias Stumpp 

wi.ba-loerrach.de/~karguti/Arbeiten/Vertiefung/4_VT_Bluetooth_Stumpp.pdf 

[5] „Eingebettete Systeme – Bluetooth“ - Lothar Thiele, Jan Beutel 

www.tik.ee.ethz.ch/tik/education/lectures/ES/WS00/Bluetooth.pdf 

[6] „Bluetooth”, Martin Pradella 

www.uni-weimar.de/~pradella/mymobile/mm_bluetooth.htm 

[7] „Was ist Bluetooth?“ Jörn Stuphorn 

www.holtmann.org/lecture/bluetooth/ 

[8] Bluetooth - Universelle Funktechnologie zur Kommunikation 

www.avm.de 

[9] „Enhancing ISM Band Performance Using AFH”, Eric Meihofer 

www.motorola.com/semiconductors/ 

[10] „Adaptive Frequency Hopping for Reduced Interference between Bluetooth® and 

Wireless LAN” – white paper, Charles Hodgdon, Fa. Ericsson 

[11] The Bluetooth Special Interest Group (SIG): BLUETOOTH SPECIFICATIONS 

www.bluetooth.com 

[12] „Bluetooth - Connect Without Cables”, Jennifer Bray, Charles F. Sturman 

[13] „Bluetooth - Überblick über Techniken, Gerätespektrum, Zukunftsaussichten“, 

Ayhan Cil 

[14] „Bluetooth Protocol Architecture”, Sachin Garg – VLSI-EDA 

[15] „Mobile Systeme und drahtlose Netzwerke“, Frank Golatowki – Vorlesung an 

Universität Rostock 

wiss.informatik.uni-rostock.de/standard/ieee802.15.html 

[16] „Bluetooth - Gefährdungen und Sicherheitsmaßnahmen“, Bundesamt für Sicherheit 

in der Informationstechnik, Projektgruppe "Local Wireless Communication" 

www.bsi.de/literat/doc/bluetooth/

[17] Ausarbeitung zum Proseminar IBM-PC (SS 2000), Martin Kirst - Technische 

Universität Chemnitz, Fakultät für Informatik 

www-user.tu-chemnitz.de/~kirst/prosem/docs/main.htm 

[18] Informationen zum Standard Bluetooth und der Arbeit der IEEE802.15-Taskgroups 

grouper.ieee.org/groups/802/15/ 

[19] Carmeq Software & Systems – Introduction to Bluetooth, Kirsten Metheus, 06-2003 

www.dcl.hpi.uni-potsdam.de/teaching/ mobilitySem03/slides/BluetoothTutorial.pdf 

Weiterführende Informationen rund um den Standard Bluetooth und seine Auswirkungen: 

http://www.tecchannel.de/hardware/724/index.html 

http://www.de.tomshardware.com/network/20030319/bluetooth-ueberblick-01.html 

http://www.allesklar.de/l.php?xref_path=100-532-1014-28316-84135 

http://www.tecchannel.de/hardware/477/index.html 

http://www.tecchannel.de/netzwerk/networkworld/technologyupdate/174/ 

http://www.embeddedstar.com/press/content/2003/6/embedded9078.html 

http://www.eetimesnetwork.com/ 

http://www.bluetooth.com/news/releases.asp?A=2&PID=995&ARC=1 

http://www.bluetooth.com/news/releases.asp?A=2&PID=870&ARC=1&ofs= 

http://www.dslweb.de/Bluetooth-1-20-gestartet--news.htm 

http://www.heise.de/mobil/newsticker/meldung/print/37364 

http://www.tecchannel.de/news/20020613/thema20020613-7813.html 

http://www.geek.com/news/geeknews/2002Jul/bpd20020708015276.htm 

http://www.mwee.com/printableArticle/?doc_id=OEG20020611S0033 

http://internet.motlabs.com/pipermail/bluetooth/2001-February/000031.html 

http://www.802wirelessworld.com/index.jsp

Studienarbeit - Bluetooth-Anwendungen

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?