Studienarbeit - Bluetooth-Anwendungen

Transcription

Studienarbeit
Bluetooth-Anwendungen
„unplug and connect“
Bearbeiter
Schwerpunkte
Holger Hildebrandt
Kay Pein
1.1, 1.2, 1.3, 2.1, 2.3, 3.1-4 , 4.
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.2.2. ANMERKUNG
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.4.3. ANMERKUNG
4.5 SAME CHANNEL METHOD
4.6 ABWÄRTSKOMPATIBILITÄT ZU BLUETOOTH 1.1
Abkürzungen
A
ACK
ACL
AFH
AM_ADDR
API
ARQ
ARQN
AT
Acknowledge
Asynchron Connection-Less
Advanced Fequency Hopping
Active Member Address
Application Programming Interface
Automatic Repeat Request
Ackknowledge Request Number
Attention (in Telephone Control Commands)
B
BD_ADDR
BT
Bluetooth Device Address
Bluetooth
C
CAC
CC
CCR
ChM
CRC
CSMA/CD
CTP
CTS
CVSD
Channel Access Code
Channel Classification
Channel Classification Report
Channel Map in AFH (eigene Abk)
Cyclic Redundancy Check
Carrier Sense Multiple Access w/ Collision Detection
Cordless Telephony Profile
Clear To Send
Continuos Variable Slope Delta
D
DAC
DH
DM
DSR
DTR
DUN-P
DV
Device Access Code
Data High-rate (Packettyp in ACL)
Data Medium-rate (Packettyp in ACL)
Data Set Ready
Data Terminal Ready
Dial-Up Networking Profile
Data Voice (Packettyp in SCO)
E
eQoS
eSCO
ETSI
EV
enhanced QoS
enhanced SCO
European Telecommunications Standardisation Institute
Enhanced Variable (Packettyp in SCO)
F
FAX-P
FEC
FFH
FTP
Fax-Profile
Forward Error Correction
Fast Frequency Hopping
File Transfer Protocol
G
GFSK
GSM
Gaussian Frequency Shift Keying
Global System for Mobile Communication
H
HCI
HEC
Host Controller Interface
Header Error Check
HF
HTTP
HV
Hochfrequenz
Hyper Text Transfer protocol
High quality Voice (Packettyp in SCO)
I
IAC
ID
IEC
IEEE
IP
IrDA
IrMC
ISDN
ISM
ISO
ITU-T
Inquiry Access Code
Identification
International Electrotechnical Commission
Institute of Electrical and Electronics Engineers
Internet Protocol
Infra-red Data Association
Ir Mobile Communication
Integrated Services Digital Network
Industrial, Science, Medical
International Standardization Organisation
International Telecommunication Union – Telecom Standardization
L
L2CAP
LAN
LAP
LC
LCP
LLC
LM
LMANSC
LMP
LSB
Logical Link and Control Adaption Protocol
Local Area Network
Lower Address Part
Link Controller
Link Control Protokol
Logical Link Controller
Link Manager
LAN/MAN Standards Committee
Link Manager Protocol
Least Significant Bit
M
MAC
MAN
MSB
MSC
MTU
Medium Access Control
Metropolitain Area Network
Most Significant Bit
Message Sequence Chart
Maximum Transfer Unit
N
NAK
NAP
Negative Acknowledgement
Non-significant Address Part
O
OBEX
OSI
Object Exchange Protocol
Open Systems Interconnection
P
PAN
PC
PCI
PCM
PCMCIA
PDA
PDU
PER
PIN
PM_ADDR
PPP
Personal Area Network
Personal Computer
Peripheral Component Interconnect
Pulse Code Modulation
Personal Computer Memory Card International Association (PC Card)
Personal Digital Assistent
Potocol Data Unit
Packet Error Rate
Personal Indetification Number
Parked Member Address
Point-to-Point Protocol
Q
QoS
Quality of Service
R
RF
RFC
RFCOMM
RS232
RSSI
RTS
Rx
Radio Frequency
Request for Comments
Radio Frequency Communication
COM-Schnittstellenstandard
Received Signal Strength Indication
Ready To Send
Receiver
S
SAR
SCO
SDDB
SDP
SDU
SEQN
SIG
SIM
Segmentation and Reassembly
Synchronous Connection-Orientated
Services Discovery Data Base
Services Discovery Protocol
Service Data Unit
Sequence Number
Special Interest Group
Subscriber Identy Module
T
TCP
TCS
TCS-bin
TDD
TG
Tx
Transport Control Protocol
Telephony Control Services
Telephony Control Services - binary
Time Division Duplex
Task Group
Transmitter
U
UAP
UDP
USB
UUID
Upper Address Part
User Datagram Protocol
Unversal Serial Bus
Universal Unique Identifier
W
WAE
WAP
WBMP
WLAN
WML
WPAN
WAP Application Environment
Wireless Application protolcol
WAP Bitmap
Wireless LAN
Wireless Meta Language
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 ISMFunkfrequenzband. 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
Spread Spectrum
(Frequency
Hopping)
Infrarot
Spread Spectrum
(Freqency
Hopping
oder Direct
Seqence)
Spread Spectrum
(Freqency
Hopping
oder Direct
Seqence)
ISM-Band
Optisch, 850
nm
ISM-Band
ISM-Band
Übertragungsleistung 1 mW
100 mW
100 mW
100 mW
max. Datendurchsatz
16 Mb/s
(VFIR)
11 Mb/s
2 Mb/s
300 m
Verbindungstyp
Spektrum
1 Mb/s
kleiner
Winkel
(max 30°)
max. Reichweite
(hindernisfrei)
Sichtverbindung
nötig
Unterstütze
Stationen
10 m
0,7 m
(bald 54 Mb/s bei
802.11g)
100 m
nein
ja
nein
nein
8 pro Piko-Netz
2
Mehrere Geräte
pro Access-Point;
mehrere AP’s
Netzwerk
127 pro Netzwerk
Sprachkanäle
3
1
nur Voice over IP
6
Datensicherheit
Authentifizierung: keine
128 Bit;
(enger
Winkel,
(optional)
Verschlüsselung: kleine
Reichweite)
mit 8-128 Bit
Adressierung
MAC-Adresse
mit 48 Bit.
AM_ADDR
mit 3 Bit
Authentifizierung: BlowfishVerschlüsselungsChallengealgorithmus
Response
über WEP;
Verschlüsselung:
standard 40 Bit,
optional 128 Bit.
Physikalische MAC-Adresse
ID
mit 48 Bit.
mit 32 Bit.
Bemerkungen
MAC-Adresse
mit 48 Bit.
in Europa nicht
durchgesetzt,
in USA verbreitet
Tabelle 1.1 – Vergleich Funkstandards
Wie aus der Tabelle ersichtlich wird, steht der IrDA-Standard konkurrierend zum BluetoothStandard, 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.
3
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 ISMFrequenzband, 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 227 (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).
Quelle: Bluetooth Core-Specification 1.1
Abbildung 1.4 – Time Slots
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 InterferenzStöranfälligkeit nimmt mit jedem Multi-Slot-Paket durch die resultierende Verringerung der
Frequenzsprünge weiter zu.
6
Abbildung 1.5 – Multislot-Pakete
1.2.2. Leistungsklassen
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
Class 2 Geräte
Class 3 Geräte
High
Medium
Low
100 mW (20 dBm)
2.5 mW (4 dBm)
1 mW (0 dBm)
100 m
20 m
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-PunktVerbindung 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.
7
Jedes Bluetooth-Gerät hat eine eindeutige Hardware-Adresse von 48 Bit Länge (MACAdresse), 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 PikoNetzes (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 BluetoothDevice 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 PikoNetz 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
Abbildung 1.8 – SCO-Paketperioden
Type
HV1
HV2
HV3
DV
AudioInformation
(Byte)
10
20
30
80
Payload
(bit)
FEC
CRC
ZeitschlitzPeriode
240
240
240
230
1/3
2/3
no
nur Datenfeld
no
no
no
nur Datenfeld
2
4
6
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 PollingVerfahren 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
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. BTEinheiten, 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 BluetothStandards 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 OnlineForum 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. ScatterNetzen, 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 BluetoothSIG 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-zuMultipunkt-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 RetransmissionsFenster statt (mehrere Zeitschlitze), welches sich unmittelbar hinter den reservierten
Zeitschlitzen befindet. Innerhalb des Retransmissions-Fensters wird das gleichartige PollingVerfahren 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
EV4
- 2/3 FEC
- Paket darf maximal drei Zeitschlitze einnehmen
EV5
- 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.
Quelle: Bluetooth Core Specification 1.2
Abbildung 1.13 – Symmetrischer Datenverkehr
20
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 BluetoothGerä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.
21
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 BluetoothHerstellerkonsortium. 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 BluetoothGesamtspezifikationen der Versionen 1.0x und 1.1 aus zwei Hauptteilen, CoreSpecification (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 PikoNetze, 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/OSIModells.
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 IEEESpezifizierungen ü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 KoexistenzMechanismen 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-Kerndas 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.
Anwendungen
WAE
WAP
ATCommands
TCS-bin
SDP
Software
vCard/vCal
OBEX
TCP UDP
IP
PPP
Kabelersatzprotokoll (RFCOMM)
HCI
LMP
Basisband & Link Control
Bluetooth Radio
Abbildung 1.16 – Die Protokollarchitektur
26
Hardware
L2CAP
ACL
SCO
Audio
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 BluetoothModule. 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) BluetoothGerä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 TerminalVerbindung.
• 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
bisherigen 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 BluetoothTransceivern.
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 MasterSlave-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 Picorespektive 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 Bedienund 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
[Close]. Zum Anhalten der Datenerfassung,
[Clear], respektive Schließen der Datei mit
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.
[Open file] geöffneten,
Zur Auswertung aktuell erfasster oder aus einer, mit Hilfe von
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
Frame Display
Protocol Navigator
Event Display
– statistische Informationen zu Datenfluss-Parametern
– textbasierte Informationen einzelner Frames
– textbasierte Informationen mehrerer Frames
– 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
Frame-Grössen-Bereiche der Statistik genommen werden (Options -> Set Frame
auf die
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.
Abbildung 2.4 – Screenshot FTS-Protocol Navigator
Event Display
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.
Master
1
2
3
4
5
Slave
LMP_name_req(offset=0)
BB_retransmitted_LMP_packet
Abruf des Gerätenamens
mit Überlänge
LMP_name_res(offset=0,Len=20,"TU-Laptop_Expl")
LMP_name_req(offset=14)
LMP_name_res(offset=14,Len=20,"orer_B")
6
LMP_detach
LM-Verbindungsabbau
Abbildung 2.6 – MSC-Frame 1-6
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 Master42
Host der MAC-Adresse des Slave den Namen zugeordnet so beendet er diese LMPVerbindung 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- HostConnection-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-Versionsaustausch
Host-Verbindungsaufbau
LMP_accepted (LMP_host_connection_req)
LMP_timing_accuracy_req
LMP_timing_accuracy_res(drift=20ppm,jitter=1µs)
LMP_setup_complete
Vergleich der Zeitmessung
Ende der Initialisierung
LMP_setup_complete
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)
max. Zeitschlitze f. ein Paket
LMP_accepted (LMP_max_slot_req)
LMP_max_slot(5)
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
43
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
L2CAP_connection_req(SDP)
L2CAP_connection_res(connection_successful)
20
L2CAP_cofigure_req(MTU=65535,FlushTimeout=65535)
21
L2CAP_configure_res(success)
22
L2CAP_cofigure_req(MTU=65535,FlushTimeout=65535)
23
SDP Verbindungswunsch
L2CAP Init f. SDP
Zur optimalen Einstellung des Stromverbrauchs sendet jedes kommunizierende BluetoothGerä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-DecreaseRequests vorausgesetzt.
24
LMP_power_decr_req
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
31
32
SDP_SSARequest(OBEXPush)
SDP_SSAResponse(L2CAP,RFCOMM(2),OBEX)
SDP_SSARequest(OBEX File Trans)
SDP_SSARequest(Imaging Responder)
LMP_power_decr_req
LMP_power_decr_req
44
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 L2CAPConfigure-Requests & -Responses.
33
34
35
36
37
38
39
L2CAP_connection_req(RFCOMM)
L2CAP_connection_res(connection_successful)
L2CAP_cofigure_req()
RFCOMM Verbdg.-wunsch
L2CAP Init f. RFCOMM
Parameter wie SDP (siehe oben)
LMP_power_decr_req
L2CAP_cofigure_req()
Der Start des RFCOMM-Multiplexers erfolgt durch Senden eines RFCOMM-SetAsynchronous-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-UnnumberedInformation-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)
SABM .. SetAsyncBalanceMode
RFCOMM_UIH(CMD(Param.Negot.))
UA .. UnnumberedACK
RFCOMM_UIH(CMD(Param.Negot.))
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 BreakSignal der emulierten RS-232 Schnittstelle durchzureichen. Gefolgt wird dies von einer
gegenseitigen Zusendung der ersten Kreditrahmen für CFC und weiteren Modem Status
Commands.
45
44
45
46
47
48
49
50
51
52
53
54
55
56
RFCOMM_SABM (CH 2)
RFCOMM_UA (CH 2)
RFCOMM_UIH(CMD(ModemStatus))
RS232-Signalemulation
RFCOMM_UIH(RESP(ModemStatus))
RFCOMM_UIH(Credits(30))
RFCOMM_UIH(Credits(30))
LMP_power_decr_req
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 OBEXSuccess(FTP) bestätigt wird und nun auf dem Slave-Host als Datei im eingestellten StandardDatenaustausch-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.
57
58
59
60
61/62
63/64
65
66
67
OBEX_Conn(FTP)
OBEX Verbindung m. FTP
OBEX_Sucess(FTP)
OBEX_Get(FolderListing)
OBEX_Sucess(FTP_Server(FolderListing))
OBEX_Put(FTP_Client(Data))
OBEX_Put(FTP_Client(Data))
OBEX_Sucess(FTP)
OBEX_Get(FolderListing)
OBEX_Sucess(FTP_Server(FolderListing))
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.
46
68
69
L2CAP_disconnection_req()
L2CAP_disconnection_res(success)
L2CAP Verbindungsabbau 1
Abbildung 2.16 – MSC-Frame 68/69
Nun wird das OBEX-Protokoll ebenfalls durch OBEX-Disconnect und bestätigende OBEXSuccess-Meldung getrennt.
OBEX_Disconnect
70
71
OBEX Verbindungsabbau
OBEX_Sucess
Auf der RFCOMM-Ebene muss nur der Datenkanal abgebaut werden, was durch RFCOMMDisconnect(CH 2) und die entsprechende Bestätigung mittels Unnumbered Acknowledgement
realisiert wird.
72
73
RFCOMM_Disconnect (CH 2)
RFCOMM_UA (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 L2CAPDisconnection-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-PowerMeldung 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
79
LMP_decr_power_req
LMP_min_power
LMP_decr_power_req
Sendeleistungsmin. erreicht
LMP_detach
LMP Verbindungsende
2.2.2. Anmerkung
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
47
genaue Anzahl verlorener Pakete einer gestörten Übertragung zu bestimmen. Weiterhin sei
angemerkt, dass FTS nicht vorrangig zur Visualisierung von überwachten BluetoothVerbindungen 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 MessageSequenz-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 BluetoothTranceiver 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 PCCards. 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-dieZwischenablage-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 Hexin 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 DatenEmpfä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 BluetoothKommunikation 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 ClientServer-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 WLANAdapter 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 DistanzKombinationen 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.13 – Konstellation Bo/Wi
Abbildung 3.14 – Messwerte in 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.15 – Konstellation Bi/Wi
Abbildung 3.16 – Messwerte Bi/Wi
68
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 WLANFunk zu begründen.
Bo/Wo:
oder
Abbildung 3.17 – Konstellation Bo/Wo
Abbildung 3.18 – Messwerte 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.19 – Konstellation Bi/Wo
Abbildung 3.20 – Messwerte Bi/Wo
69
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 BluetoothSendeleistung negativ aus. Das vom gleichzeitigen Bluetooth-Empfänger gesendete WLANSignal 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 WLANTransceiver 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.
Abbildung 3.22 – Anordnung Cross Measurement 2
3.4.2. Visualisierung
Ü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-SekundenIntervallen ü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 WLANDurchsatzes.
Abbildung 3.23 – Darstellung Fall 1
71
Abbildung 3.24 – Darstellung Fall 2
3.4.3. Fazit
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 BluetoothTransceiver gestörte/belegte Frequenzen. Dies geschieht mittels der Einführung einer PicoNetz-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 – SameChannel-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 FrequenzsprungVerfahren (FFH) anwenden, nutzen immer alle 79 festgelegten Kanäle des 2,4GHz-ISMBandes (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-ChannelMethod, 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 HostController 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 LMPKommandos 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
AFH_Min_Interval
AFH_Max_Interval
Aktivierung fortlaufender CCR oder Deaktivierung CCR
Wert für die Mindestzeit zwischen zwei CCR
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_classificationPDU, 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“
„good“
Æ 00
Æ 01
Æ 11
(10 ist reserviert)
„bad“
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
bildet 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“
„good“
„bad“
„bad“
„unknown“
(01)
(01)
(11)
(11)
(00)
und
und
und
und
und
„good“
„unknown“
„bad“
„unknown“
„unknown“
(01)
(00)
(11)
(00)
(00)
Æ „good“ (01)
Æ „good“ (01)
Æ „bad“ (11)
Æ „bad“ (11)
Æ „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_Channel_Map:
AFH-Aktivierung oder -Deaktivierung für diesen Slave
(Verbindungsaufbau mit v1.1-Frequnzauswahl und
anschließende Aktivierung von AFH möglich);
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äteAdresse 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.)
4.4.3. Anmerkung
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 HostController 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-KanalSprungsequenz 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

Transcription

Similar documents

LIFEBOOK C Series - Medienzentrum Marburg

Nachbar Fuchs – ein etwas anderer

Unsere Zukunft ist drahtlos

µ¶ÀÏ¾î LG-600 - Handytreff.de

Erkennen und Abwehren von Angriffen im Mobilfunknetz auf

6/2015 - Modellflugsport CH

Manual germana anul I

Exportbericht Georgien - Außenwirtschaftsportal Bayern

Der Index des Buches als PDF-Datei - PC

RFID - Radio Frequency Identification

1. Aufgabenstellung

3 in 1 WLAN-Hotspot