Studienarbeit

Bluetooth-Anwendungen

„unplug and connect“

Bearbeiter Schwerpunkte

Holger Hildebrandt 1.1, 1.2, 1.3, 2.1, 2.3, 3.1-4 , 4. Kay Pein 1.1, 1.2, 1.4, 2.1-3, 3.1-4

Inhalt KAPITEL 1 - DER FUNKSTANDARD BLUETOOTH 1.1. EINLEITUNG: WAS IST BLUETOOTH?

1.1.1. MOTIVATION 1.1.2. URSPRUNG 1.1.3. EINORDNUNG DES STANDARDS 1.1.4. ABGRENZUNG ZU ANDEREN FUNKÜBERTRAGUNGSSTANDARDS 1.1.5. VERWENDUNG DER BLUETOOTH-TECHNOLOGIE

1.2. GRUNDLAGEN BLUETOOTH 1.2.1. FAST FREQUENCY HOPPING - VERFAHREN 1.2.2. LEISTUNGSKLASSEN 1.2.3. NETZTOPOLOGIEN 1.2.4. ADRESSIERUNG UND STATUSMODI 1.2.5. KANALTYPEN

1.2.5.1. Synchronous Connection-Orientated (SCO): 1.2.5.2. Asynchronous Connection-Less (ACL)

1.2.6. DIE SICHERHEIT BEI VERWENDUNG VON BLUETOOTH 1.3. STANDARDS UND EVOLUTION

1.3.1. EINLEITUNG 1.3.1.1. Wozu sind Standards nötig? 1.3.1.2. Wer macht die Standards bei Bluetooth?

1.3.2. DIE STANDARDS IM ÜBERBLICK 1.3.2.1. Bluetooth 1.0a und 1.0b 1.3.2.2. Bluetooth 1.1 1.3.2.3. Bluetooth 1.2

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 Acknowledge ACL Asynchron Connection-Less AFH Advanced Fequency Hopping AM_ADDR Active Member Address API Application Programming Interface ARQ Automatic Repeat Request ARQN Ackknowledge Request Number AT Attention (in Telephone Control Commands) B BD_ADDR Bluetooth Device Address BT Bluetooth C CAC Channel Access Code CC Channel Classification CCR Channel Classification Report ChM Channel Map in AFH (eigene Abk) CRC Cyclic Redundancy Check CSMA/CD Carrier Sense Multiple Access w/ Collision Detection CTP Cordless Telephony Profile CTS Clear To Send CVSD Continuos Variable Slope Delta D DAC Device Access Code DH Data High-rate (Packettyp in ACL) DM Data Medium-rate (Packettyp in ACL) DSR Data Set Ready DTR Data Terminal Ready DUN-P Dial-Up Networking Profile DV Data Voice (Packettyp in SCO) E eQoS enhanced QoS eSCO enhanced SCO ETSI European Telecommunications Standardisation Institute EV Enhanced Variable (Packettyp in SCO) F FAX-P Fax-Profile FEC Forward Error Correction FFH Fast Frequency Hopping FTP File Transfer Protocol G GFSK Gaussian Frequency Shift Keying GSM Global System for Mobile Communication H HCI Host Controller Interface HEC Header Error Check

HF Hochfrequenz HTTP Hyper Text Transfer protocol HV High quality Voice (Packettyp in SCO) I IAC Inquiry Access Code ID Identification IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol IrDA Infra-red Data Association IrMC Ir Mobile Communication ISDN Integrated Services Digital Network ISM Industrial, Science, Medical ISO International Standardization Organisation ITU-T International Telecommunication Union – Telecom Standardization L L2CAP Logical Link and Control Adaption Protocol LAN Local Area Network LAP Lower Address Part LC Link Controller LCP Link Control Protokol LLC Logical Link Controller LM Link Manager LMANSC LAN/MAN Standards Committee LMP Link Manager Protocol LSB Least Significant Bit M MAC Medium Access Control MAN Metropolitain Area Network MSB Most Significant Bit MSC Message Sequence Chart MTU Maximum Transfer Unit N NAK Negative Acknowledgement NAP Non-significant Address Part O OBEX Object Exchange Protocol OSI Open Systems Interconnection P PAN Personal Area Network PC Personal Computer PCI Peripheral Component Interconnect PCM Pulse Code Modulation PCMCIA Personal Computer Memory Card International Association (PC Card) PDA Personal Digital Assistent PDU Potocol Data Unit PER Packet Error Rate PIN Personal Indetification Number PM_ADDR Parked Member Address PPP Point-to-Point Protocol

Q QoS Quality of Service R RF Radio Frequency RFC Request for Comments RFCOMM Radio Frequency Communication RS232 COM-Schnittstellenstandard RSSI Received Signal Strength Indication RTS Ready To Send Rx Receiver S SAR Segmentation and Reassembly SCO Synchronous Connection-Orientated SDDB Services Discovery Data Base SDP Services Discovery Protocol SDU Service Data Unit SEQN Sequence Number SIG Special Interest Group SIM Subscriber Identy Module T TCP Transport Control Protocol TCS Telephony Control Services TCS-bin Telephony Control Services - binary TDD Time Division Duplex TG Task Group Tx Transmitter U UAP Upper Address Part UDP User Datagram Protocol USB Unversal Serial Bus UUID Universal Unique Identifier W WAE WAP Application Environment WAP Wireless Application protolcol WBMP WAP Bitmap WLAN Wireless LAN WML Wireless Meta Language WPAN Wireless Personal Area Network

1

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.

2

1.1.3. Einordnung des Standards Der Industriestandard Bluetooth wird von der IEEE unter dem Namen IEEE 802.15 in die bestehende Landschaft der IEEE-802-Normen eingereiht. Diese Klasse bezeichnet alle Benutzerszenarien, die durch ad-hoc-Konnektivität gekennzeichnet sind. Die Bluetooth-Technologie zeichnet sich durch die folgenden wesentlichen Designaspekte aus. Weltweite Nutzbarkeit Die drahtlose Bluetooth-Technologie verwendet das weltweit lizenzfrei verfügbare ISM-Funkfrequenzband. In den meisten Nationen liegt dieses Band im Frequenzbereich von 2400 MHz bis 2483,5 MHz. Das ISM-Band (Industrial, Science, Medical) allgemein ist ein Frequenzbereich, der nicht der staatlichen Regulierung unterliegt und lizenzfrei für industrielle, wissenschaftliche und medizinische Anwendungen genutzt werden darf. Lediglich müssen Auflagen bezüglich der Sendeleistung und der Störung benachbarter Frequenzbereiche eingehalten werden. Somit dürfen Bluetooth-Geräte weltweit zulassungsfrei betrieben werden. Es muss aber mit Störungen durch andere Geräte gerechnet werden, die im gleichen Frequenzband arbeiten (z.B.: Mikrowellenherde, 802.11 WLANs, Medizinische Geräte, etc.). Diesen Störfaktoren wirken diverse Verfahren entgegen, sodass ein störungsfreier Betrieb gewährleistet ist bzw. genannte Störungen verkraftet werden. Sprach- und Datenunterstützung Bluetooth ist jeweils speziell für die Übertragung von Sprache und Daten konzipiert. Ad-hoc-Konnektivität Geräte sollen alleine andere Geräte in Reichweite finden und sich mit ihnen verbinden. Außerdem müssen mehrere Verbindungen gleichzeitig möglich sein. Sicherheit Mit Authentifizierung und Verschlüsselung soll derselbe Sicherheitsstandard wie bei Kabelverbindungen realisiert werden. Geringe Größe und kostengünstige Serienfertigung Im Vergleich zu anderen (Daten-) Funktechnologien, wie z.B. GSM, wird bei Bluetooth ein einfaches RF-Design verwendet, vergleichbar mit IrDA. Man ging beim Entwurf davon aus, dass sich ein Bluetooth-Sender/Empfänger fast immer in einem Mikroprozessor gesteuerten Endgerät befindet. Somit wurde die Steuerung und Fehlerkorrektur der Funkübertragung auf nachgeschaltete digitale Komponenten (Hardware und entsprechende Software) verlagert.

Sehr geringe Leistungsaufnahme (und Sendeleistung) Um mobil zu werden, sollte die Leistungsaufnahme einer Bluetooth-Einheit, verglichen mit dem Host-Gerät, sehr klein sein um die Akkulaufzeit nicht unnötigerweise zu verringern. Dies wird durch die sehr geringe Sendeleistung im 2,4GHz-Band realisiert, wodurch der Einsatz in elektro-magnetisch-kritischen Umgebungen, wie z.B. in Kraftwerken, Krankenhäusern, Flugzeugen (Lufthansa), ermöglicht wird.

1.1.4. Abgrenzung zu anderen Funkübertragungsstandards Im Bereich der drahtlosen Datenkommunikation gibt es mittlerweile diverse Standards, welche teilweise ein eigenes Einsatzgebiet besitzen und mit den anderen Standards nicht viel

3

gemeinsam haben. In nachfolgender Tabelle wird eine Gegenüberstellung der vier wichtigsten Technologien Bluetooth, IrDA, IEE 802.11b und Home-RF gegenübergestellt. Bluetooth IrDA IEE802.11b Home RF Verbindungstyp Spread Spectrum

(Frequency Hopping)

Infrarot kleiner Winkel (max 30°)

Spread Spectrum (Freqency Hopping oder Direct Seqence)

Spread Spectrum (Freqency Hopping oder Direct Seqence)

Spektrum

ISM-Band

Optisch, 850 nm

ISM-Band

ISM-Band

Übertragungsleistung

1 mW

100 mW

100 mW

100 mW

max. Datendurchsatz

1 Mb/s

16 Mb/s (VFIR)

11 Mb/s (bald 54 Mb/s bei 802.11g)

2 Mb/s

max. Reichweite (hindernisfrei)

10 m

0,7 m

100 m

300 m

Sichtverbindung nötig

nein ja nein nein

Unterstütze Stationen

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: 128 Bit; (optional) Verschlüsselung: mit 8-128 Bit

keine (enger Winkel, kleine Reichweite)

Authentifizierung: Challenge-Response über WEP; Verschlüsselung: standard 40 Bit, optional 128 Bit.

Blowfish-Verschlüsselungs-algorithmus

Adressierung

MAC-Adresse mit 48 Bit. AM_ADDR mit 3 Bit

Physikalische ID mit 32 Bit.

MAC-Adresse mit 48 Bit.

MAC-Adresse mit 48 Bit.

Bemerkungen in Europa nicht durchgesetzt, in USA verbreitet

Tabelle 1.1 – Vergleich Funkstandards

Wie aus der Tabelle ersichtlich wird, steht der IrDA-Standard konkurrierend zum Bluetooth-Standard, doch hat dieser die „schlechteren Karten“, was durch die deutlich höhere Sendeleistung und den immer notwendigen Sichtkontakt, daraus resultierend nur eine Punkt-zu-Punkt-Verbindung möglich, begründet ist.

4

Im Gegensatz zu Bluetooth hat IEEE 802.11b (WLAN) grundsätzlich ein völlig anderes Einsatzgebiet. Bluetooth-Geräte verbrauchen weniger Strom und sind für die Übertragung geringer Datenmengen über kürzere Distanzen entwickelt worden - Kommunikationskabelersatz. WLAN dagegen bietet Verbindungen bis zu 54 Mb/s für breitbandige Kommunikation über Distanzen von mehreren hundert Metern.

1.1.5. Verwendung der Bluetooth-Technologie Nutzbar ist Bluetooth für eine Vielzahl von Szenarien. So könnten z.B. alle Geräte im Büro ohne Kabelprobleme frei im Raum platziert werden. Sie bilden dann ad hoc ein so genanntes Piko-Netz. Das beschreibt die spontane Interaktion von bis zu 8 aktiven Geräten in der Reichweite eines dieser Geräte (dem Master). Bluetooth ist somit bereits heute eine etablierte Funktechnik für den Nahbereich, die die drahtlose Anbindung mobiler Endgeräte wie Notebooks, Drucker und Mobiltelefone ermöglicht, so dass sie untereinander Daten austauschen können. Aber auch andere Geräte, wie z.B. Headsets, Tastaturen und ähnliches, kann man mit dieser Technik ausstatten. Damit lassen sich künftig zwei der größten Hindernisse beseitigen, die gegenwärtig die Benutzerfreundlichkeit solcher Geräte für Kunden einschränken. Dies wären zum einen die herstellerspezifischen Anschlusskabel und zum anderen die notwendigen Einstellungen und Eingaben, die für den Aufbau der Kommunikation notwendig sind. Dies wird durch so zu nennende anwendungsspezifische Profile realisiert.

1.2. Grundlagen Bluetooth In diesem Kapitel wird ein Überblick über die grundlegende Funktionsweise von Bluetooth anhand des Standard Bluetooth 1.1 gegeben. Auf Änderungen bezüglich des im November 2003 veröffentlichten Standards 1.2 wird in einem späteren, hierauf aufbauenden Kapitel eingegangen.

1.2.1. Fast Frequency Hopping - Verfahren Wie bereits einführend erwähnt wurde, arbeiten Bluetooth-Transceiver im lizenzfreien ISM-Frequenzband, dem ein Frequenzbereich von 2400 MHz bis 2483,5 MHz zugewiesen ist. Bei der Übertragung bedient man sich des Fast Frequency Hopping Verfahrens (FFH). Dabei wird das zur Verfügung stehende Frequenzband in 79 gleich große Kanäle à 1 MHz aufgeteilt, zwischen denen 1600 Mal pro Sekunde gewechselt wird.

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

In wenigen Ländern z.B. Japan, Frankreich oder Spanien ist das verwendbare Band schmaler. Dieser Sonderfall ist im weltweiten Bluetooth-Standard berücksichtigt und führt zur Nutzung von nur 23 Kanälen.

5

* 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.

6

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 Interferenz-Störanfälligkeit nimmt mit jedem Multi-Slot-Paket durch die resultierende Verringerung der Frequenzsprünge weiter zu.

7

Quelle: Bluetooth Core-Specification 1.1

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 High 100 mW (20 dBm) 100 m Class 2 Geräte Medium 2.5 mW (4 dBm) 20 m Class 3 Geräte Low 1 mW (0 dBm) 10 m

Tabelle 1.2 – Sendeleistungsklassen

Die Class1-Version wird auch als „Long-Range-Bluetooth“ bezeichnet, doch die derzeit am meisten verbreitete Leistungsklasse ist die preiswertere und stromsparende Class3.

1.2.3. Netztopologien Interagieren zwei Bluetooth-Systeme, kommunizieren sie in einer Punkt-zu-Punkt-Verbindung miteinander, indem ein Gerät die Rolle des Masters übernimmt. Sobald eine Interaktion von mehr als zwei Geräten erforderlich ist, spricht man von einem Piko-Netz. Dies wird ebenfalls von einem Master verwaltet bzw. kontrolliert, indem sich bis zu sieben aktive Slaves auf ihn synchronisieren (Sprungtakt und Sprungabfolge). Die maximale Anzahl an zusätzlich eingebuchten Slaves, inaktiv im so genannten Parkmodus, ist je Piko-Netz auf 255 technisch beschränkt.

8

Jedes Bluetooth-Gerät hat eine eindeutige Hardware-Adresse von 48 Bit Länge (MAC-Adresse), deren Aufbau nach dem IEEE 802 Standard geregelt ist. Durch die Bluetooth-device-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:

9

Zu 1.) In einem Büro sollen mehr als acht Bluetooth-Geräte miteinander kommunizieren (nicht im Parkmodus). Durch die Limitierung von maximal acht aktiven Teilnehmern pro Piko-Netz muss ein Slave für ein neues Piko-Netz, zur Integration der übrigen (maximal wiederum 7) Geräte, als Master bzw. Slave des neuen Netzwerkes fungieren. Zu 2.) Ein Scanner befindet sich außerhalb der maximalen Reichweite eines Piko-Netzes (sendeleistungsabhängige Distanz/Senderadius von Master zu Slaves), doch gibt es einen Slave dieses Netzes welcher in Reichweite zum Scanner liegt. In diesem Falle kann dieser Slave in einem neuen Piko-Netz als Master für den Scanner fungieren. Zu 3.) Zwei Büros, die ihre eigenen Piko-Netze betreiben, möchten auf einen gemeinsamen Drucker zugreifen. Das gemeinsam genutzte Gerät sollte für beide Parteien ein Slave sein, da es nicht zur Kommunikation zwischen zwei Netzen dienen soll, sondern lediglich von beiden Netzten aus verfügbar sein sollte.

1.2.4. Adressierung und Statusmodi Einzelne Bluetooth-Geräte werden, wie in allen IEEE 802 kompatiblen Standards (Ethernet, Token Ring, WLAN), über eine weltweit eindeutige 48 Bit breite Adresse, die Bluetooth-Device Address (BD_ADDR) angesprochen. Weiterhin adressiert ein Master alle aktiven Einheiten eines Piko-Netzes über die Active Member Address (AM_ADDR) der Größe 3 Bit, wobei die „0“ dieses Adressraumes als Broadcast an alle aktiven Slaves verstanden wird. Alle nicht aktiven Geräte in einem Piko-Netz werden mit der 8 Bit breiten Parked Member Address (PM_ADDR) erreicht. Interessant ist noch, dass mehrere Betriebszustände für ein Bluetooth-Gerät existieren. Betriebsmodi Standby-Modus: Das Gerät ist nicht mit einem Piko-Netz verbunden. In diesem Modus

ist der Energiebedarf des Gerätes äußerst gering, da nur der Mastertimer des Gerätes läuft. Der Standby-Modus wird nur durch ein Inquiry oder Paging eines anderen Masters aufgehoben oder durch die Station selber, wenn sie ein Inquiry einleitet, um andere Stationen zu finden.

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

die sich in Reichweite befinden. Dabei sendet es in vorgegebenen Zeitschritten seine Inquiry-Nachrichten aus und wartet auf Antwort.

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

ihm bekannten (Device Access Code) Gerät verbinden. Ist er dann mit diesem Slave oder mehreren verbunden, begibt er sich in den Connected-Modus.

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

eigenem Device Access Code).

10

Zustände im Verbindungsmodus Connected-Modus: Ein Master hat eine Verbindung mit einem bzw. mehreren Slaves

etabliert. Active-Modus: Ein Slave steht aktiv in Verbindung zum Master. Drei weitere Energiesparmodi stehen für den Fall zur Verfügung, dass ein Gerät die Verbindung zu einem Master bereits hergestellt hat, aber nicht mehr als aktives Gerät in der Verbindung benötigt wird. Der Hold-, der Sniff- und der Park-Modus unterscheiden sich beispielsweise hinsichtlich des Arbeitszyklus des Gerätes, d.h. in dem zeitlichen Abstand, in welchem das Gerät auf einen Masteraufruf "horcht". Damit lassen sich Erreichbarkeit und Stromverbrauch individuell beeinflussen. Sniff-Modus: Ein Slave lauscht in regelmäßigen Abständen, ob Aktivität im Piko-

Netz vorhanden ist oder nicht, ob ein Paket für ihn ankommt oder nicht. Dies wird über folgende zwei Parameter kontrolliert: a) Sniff-Attempt (Sniff-Versuch) legt fest, wie viele Zeitschlitze der

Slave belauschen muss, unabhängig davon, ob die Pakete für ihn bestimmt sind oder nicht.

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

belauscht werden müssen, wenn er ein Paket mit seiner Adresse im Header bekommen hat.

Wenn ein Paket an seine Adresse adressiert wurde, dann antwortet das Slave-Gerät dem Master. In diesem Modus wird die zuvor zugewiesene Active Member Address beibehalten und der Stromverbrauch beläuft sich im Durchschnitt auf 300 µA.

Hold-Modus: Eine bestehende ACL-Verbindung zwischen 2 Bluetooth-Einheiten kann für eine bestimmte Zeit auf Hold gesetzt werden, wenn keine Notwendigkeit besteht Daten zu senden bzw. zu empfangen. Während dieser Zeit kann kein Paket empfangen werden. Die Datenübertragung kann bei Bedarf wieder aktiviert werden, indem der Slave von sich aus seinen Zustand wieder verlässt. Auch in diesem Modus bleibt die zuvor zugewiesene Active Member Adress bestehen und der Stromverbrauch liegt bei nur 60µA.

Park-Modus: Ein Slave soll an einem Kanal nicht teilnehmen, aber immer noch über das Frequenzsprungverfahren synchronisiert bleiben. Wird ein Slave allerdings in den Park-Modus versetzt, so gibt er seine Active Member Address auf und eine eindeutige Parked Member Address wird ihm vom Master zugewiesen, die er benutzen wird, um den Slave wieder in den Active-Modus zu versetzen. Der Stromverbrauch liegt bei respektablen 30 µA.

11

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.

12

Abbildung 1.8 – SCO-Paketperioden

Type Audio-

Information (Byte)

Payload (bit)

FEC CRC Zeitschlitz-Periode

HV1 10 240 1/3 no 2 HV2 20 240 2/3 no 4 HV3 30 240 no no 6 DV 80 230 nur Datenfeld nur Datenfeld 16

Tabelle 1.3 – SCO-Pakettypen

Das DV-Paket kombiniert Daten und Sprache. Das Nutzdatenfeld ist in 80bit für Sprache und bis zu 150bit transparente Daten aufgeteilt, welches durch eine 16-bit-CRC und 2/3 FEC gesichert ist.

1.2.5.2. Asynchronous Connection-Less (ACL) Dieser asynchrone verbindungslose Übertragungsmodus setzt auf eine paketorientierte Punkt-zu-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.

13

Abbildung 1.9 – ACL-Pakete bei SCO-Verbindung

Der Zugriff der Slaves auf den besagten Kanal wird vom Master durch ein implizites Polling-Verfahren kontrolliert. Empfängt ein Slave ein an ihn adressiertes Daten-Paket vom Master, dann wird er im nächsten freien Slave-to-Master-Slot das nächste Paket seiner anstehen Daten senden. Wenn ACL-Pakete nicht an einen dedizierten Slave adressiert sind, werden sie als Broadcast-Information für alle Slaves angesehen. Über den ACL-Kanal werden Nutzer- oder Steuerdaten übertragen. Folgende Pakettypen existieren:

Quelle: Bluetooth Core-Specification 1.1

Abbildung 1.10 – ACL-Pakettypen

14

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.

15

Abbildung 1.12 – Gerätepaarung (Schema)

Jedes Bluetooth-Gerät authentifiziert sich mit seiner öffentlich zugänglichen weltweit eindeutigen, aber nicht fälschungssicheren MAC und kann somit immer wieder zugeordnet werden. Weiterhin ist es erforderlich seine Daten gegenüber anderen Teilnehmern auf der aktuell genutzten Frequenz zu verschlüsseln. Dies wird in Bluetooth optional mittels eines nichtstandardisierten Zufallsalgorithmus angeboten, ist aber nur auf die in den ACL-Paketen verpackten Nutzdaten beschränkt. Die Paket-Header müssen aufgrund der Adressierung im Pico- bzw. Scatter-Netz allen Teilnehmern zugänglich sein. Insgesamt werden drei Sicherheitsklassen (low, medium, high) im Bluetooth-Standard genannt. In der Stufe geringster Sicherheit kann jedes Bluetooth-Gerät mit jedem anderen in Verbindung treten und auf die auf dem anderen Gerät bereitgestellten Services zugreifen. BT-Einheiten, die höhere Sicherheitsstufen verwenden, lassen nur spezifizierte Geräte zur Anmeldung respektive autorisierte Zugriffe auf die Dienste zu. Hieraus lassen sich einige Empfehlungen zur besseren Sicherheit beim Einsatz von Bluetooth in der Datenkommunikation ableiten. Neben den allgemeinen Hinweisen, wie keine unsicheren Voreinstellungen oder zu erratende PINs zu verwenden und ähnliche Fehler zu begehen, sollte bei Bluetooth die Sendeleistung sowie die freigegebenen Dienste weitestgehend eingeschränkt werden. Gegen bekannte Sicherheitslücken, wie z.B. Bluejacking, einen Text auf das Display eines gefundenes Geräts in Reichweite senden, oder unbekannte Angriffe, z.B. durch manipulierte Geräteadressen (Spoofing), kann sich der Anwender, neben dem Abschalten der Bluetooth-Funktionen, nur schwer schützen.

16

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

17

Produkt (Hardware bzw. Software) erst nach bestandener Prüfung mit dem geschützten Bluetooth-Logo versehen und als Bluetooth-zertifiziert ausgeben. Für tiefgründigere Informationen über die Bluetooth-SIG, deren Vorgehensweise bei der Standardisierung und die vier Mitgliederkategorien wird auf die Homepage des Konsortiums verwiesen: https://www.bluetooth.org/admin/bluetooth2/faq/search_faq.php

1.3.2. Die Standards im Überblick Vorweg sei angemerkt, dass die Gegenüberstellung der Entwicklungsstufen des Bluetoth-Standards sich trotz ausgedehnter Recherche in Detailfragen als sehr schwierig erwies, da speziell zu den Versionsunterschieden kaum detaillierte Informationen zu finden waren. In themenrelevanten Quellen fanden sich in Abschnitten zu eigentlich vergleichbaren Passagen teils starke Widersprüche. Außerdem war die Glaubwürdigkeit der meisten unabhängigen Ausarbeitungen zum Thema meist fragwürdig. Auch die Inhalte der Archive offizieller Informationsseiten sind in Bezug auf die Darstellung aufgetretener Probleme und deren Lösungen oft unzureichend dokumentiert. Es wird meist nur mit der Einführung des nachfolgenden verbesserten Standards durch Auflisten verkaufsfördernder Begriffe geworben. So konnte z.B. zu den bekannten anfänglichen Kompatibilitätsproblemen zwischen Bluetooth-Geräten unterschiedlicher Hersteller, kein direktes Statement oder gar eine Erörterung gefunden werden. In dem öffentlichen Online-Forum der SIG-Homepage konnte in der Zeit der Recherche leider auch keine Information dazu erworben werden. Nur durch zeitaufwendiges Vergleichen der detailreichen Spezifikationsbeschreibungen könnten spezifische Änderungen identifiziert werden. Erst in der Dokumentation zum Standard 1.2 findet sich ein Abschnitt über die aktuellen technischen Neuerungen.

1.3.2.1. Bluetooth 1.0a und 1.0b Nach der Gründung der Bluetooth Special Interest Group im Februar 1998 folgte im Mai des gleichen Jahres die offizielle Bekanntgabe des Bluetooth-Projekts. Diese viel versprechende Ankündigung führte in ihrer Art und Weise zu entsprechend hohen Erwartungen an den Kabelkiller. Am 26. Juli 1999 wurde auf der Homepage der SIG die Spezifikation des ersten offiziellen Standards, Bluetooth 1.0a, veröffentlicht. Diese Gesamtspezifikation ist in zwei Teilabschnitte unterteilt: „Core Specification (Volume I)“ In der Kernspezifikation werden die Grundfunktionen

der Bluetooth-Geräte und deren Kommunikation über Protokolle, sowie die Anbindung an Hosts und einheitliches Fachvokabular festgelegt.

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

welche in dieser Arbeit nicht näher erläutert werden. Der Bluetooth-Standard 1.0a wird durch folgende Basis-Eigenschaften (Kernspezifikation), auf welche bereits im Kapitel Funktionsweise näher eingegangen wurde, charakterisiert:

• FFH mit 1600 Sprüngen je Sekunde und TDD • Bruttotransferrate von 1 Mbit/s • ACL/ SCO-Übertragungen

18

• Drei Sendeleistungsklassen (1mW, 2,5mW und 100mW) • Piko-Netz- (Master mit bis zu 7 Slaves) und Scatter-Netz-Topologie • zusätzliche Sicherheitsmaßnahmen

Die Erwartungen der Interessenten wurden bei weitem nicht erfüllt, da zum Zeitpunkt der Vermarktung die Entwicklungen noch nicht weit genug gediehen waren. Hauptursachen waren Fehler bei der Kompatibilität, der Implementierung von Piko-Netzen bzw. Scatter-Netzen, sowie einer eindeutigen Master-Slave-Zuweisung zwischen den Geräten. Man konnte nicht von marktreifen Produkten sprechen, da es kaum Geräte verschiedener Hersteller auf dem Markt gab, die miteinander kommunizieren konnten. Nach nur sechs Monaten folgte am 1. Dezember 1999 ein überarbeiteter Bluetooth-Standard der Version 1.0b, welcher leider auch die grundlegenden Probleme der ersten offiziellen Version nicht lösen konnte.

1.3.2.2. Bluetooth 1.1 Durch die teils schwerwiegenden Probleme von Bluetooth 1.0a und 1.0b blieb der ersehnte Durchbruch dieser „short-distance“-Funktechnologie aus. Die ganze Hoffnung der Bluetooth-SIG lag nun auf dem neu überarbeiteten Standard Bluetooth 1.1, welcher genau ein Jahr später, am 1. Dezember 2000 veröffentlicht wurde. Dieser ist nicht abwärtskompatibel zu den Vorgängerversionen 1.0a und 1.0b, obwohl die bereits erwähnten Basis-Eigenschaften beibehalten wurden. Die besagten Probleme der Vorgängerversionen wurden weitestgehend behoben, doch die Implementierung der Scatter-Netze ist noch nicht fehlerfrei bzw. nicht vollständig spezifiziert. Es wurden auch weitere Profile festgelegt. Die Vorgänger-Standards von Bluetooth 1.1 waren, in Bezug auf die Profile, lediglich als Kabelersatz, z.B. zwischen PC und Peripheriegeräten, gedacht. Die erweiterten Profile waren weitestgehend für die Übertragung von Bildern, Video-Clips oder HiFi-Audio-Signalen gedacht, die das Anwendungsspektrum dieser viel versprechenden Übertragungstechnologie deutlich vergrößerten. Durch die von der SIG verbesserte Interoperabilität zwischen Geräten verschiedener Hersteller und die nun erweiterte multimediale Anwendungsvielfalt, konnte sich Bluetooth als Funk-Übertragungstechnologie allmählich etablieren. Auf dem Markt konnte man zunehmend Produkte von Herstellern finden, die nun auf diese Technologie setzten. Ein Meilenstein für die Akzeptanz dieses Funk-Übertragungsstandards war der Ende März 2002 vereinbarte Lizenzvertrag zwischen der Bluetooth-SIG und dem IEEE, welcher auf der Kernspezifikation der Version 1.1 beruht. Die Arbeitsgruppe 802.15 des Institute of Electrical and Electronics Engineers (IEEE) erkannte dieser Technik den Rang eines IEEE-Standards zu, der in so genannten Wireless Personal Area Networks (WPAN) zum Zuge kommen soll. Von diesem Zeitpunkt an kann man von einer Zusammenarbeit der beiden Einrichtungen, bezüglich der Weiterentwicklung des WPAN-Standards, sprechen.

1.3.2.3. Bluetooth 1.2 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.

19

Folgend aufgeführte neue Merkmale sind prägend für Bluetooth 1.2 und werden anschließend näher erläutert:

• Enhanced Quality of Service (eQoS) • Verbesserter Verbindungsaufbau • Neuer Übertragungsmodus eSCO • Interferenzminimierung durch AFH • Abwärtskompatibilität zu Bluetooth 1.1 • Anlehnung der Wortwahl an IEEE • Grundlegende Umstrukturierung/Umpartitionierung des Inhalts der Spezifikation

(um Übersicht/Änderbarkeit/Protocols and Core) • Zeitgleiche Verabschiedung und Streichung nicht benötigter Profile • Anonymity Mode

1.3.2.3.1. eQoS Mit „Enhanced Quality of Service“ soll, laut der SIG, eine leistungsfähigere Punkt-zu-Multipunkt-Anwendung ermöglicht werden. Im Gegensatz zu dem implementierten QoS der Vorgängerversionen können nun zwischen dem Master und mehreren Geräten Prioritäten zugewiesen werden. Somit wird die gleichzeitige Bedienung mehrerer Clients, durch ein besseres Verkehrs-Management, optimiert. Sind beispielsweise ein Drucker und ein Lautsprechersystem via Bluetooth mit einem PC (Master) verbunden, kann durch eine Prioritätenvergabe eine unterbrechungsfreie Musikwiedergabe erfolgen, während der Drucker kurzfristig auf Daten verzichten muss.

1.3.2.3.2. Verbesserter Verbindungsaufbau Laut der Vorgängerspezifikation v1.1 mussten innerhalb von 4 Sekunden 80 Prozent aller Geräte gefunden werden, die sich in Reichweite des suchenden Geräts befinden. Mit der Version Bluetooth 1.2 sollen nun alle im Umkreis befindlichen Geräte innerhalb von ca. 2 Sekunden entdeckt werden. Weiterhin hat man den Zeitbedarf des Verbindungsaufbaus zwischen zwei Geräten von 1 Sekunde auf eine 1/10-Sekunde reduziert - Enhanced Synchronization Capability. Weiterhin wurden Flusskontrolle und Fehlererkennungsmechanismen durch verschiedene Maßnahmen verbessert. In der Spezifikation werden nur Begriffe wie „Enhanced Error Detection and Flow Control“ sowie „Enhanced Flow Specification“ genannt.

1.3.2.3.3. Neuer Übertragungsmodus eSCO Mit eSCO (Extended Connection Orientated) ist nun, neben dem normalen SCO, ein zweiter verbindungsorientierter Übertragungsmodus spezifiziert worden. Beide Modi zeichnen sich durch eine logische Punkt-zu-Punkt-Verbindung zwischen einem Master und einem bestimmten Slave aus. Die Verbindung kann ebenfalls als leitungsvermittelt angesehen werden, da ähnlich dem SCO-Übertragungsmodus eine Reservierung von Zeitschlitzen erfolgt. Doch im Gegensatz zur normalen SCO-Übertragung bietet eSCO zusätzlich eine begrenzte Retransmission defekter oder nicht angekommener eSCO-Pakete.

20

Ist eine Retransmission erforderlich, findet diese in einem so genannten Retransmissions-Fenster statt (mehrere Zeitschlitze), welches sich unmittelbar hinter den reservierten Zeitschlitzen befindet. Innerhalb des Retransmissions-Fensters wird das gleichartige Polling-Verfahren verwendet, wie es auf dem ACL-Kanal Anwendung findet: ein Slave darf erst auf dem eSCO-Kanal (im Slave-zu-Master-Zeitschlitz) sein Paket senden, wenn er unmittelbar zuvor ein an ihn adressiertes Paket vom Master (Master-zu-Slave-Zeitschlitz) erhalten hat. Sollten Zeitschlitze eines Retransmissions-Fensters nicht für die erneute Versendung von eSCO-Paketen benötigt werden, stehen sie für den anderen Daten-Verkehr zur Verfügung. Darüber hinaus bietet das erweiterte SCO gegenüber dem normalen SCO eine flexiblere Kombination von Pakettypen und Dateninhalten, des Weiteren wählbare Perioden für die reservierten Zeitschlitze, wodurch eine Unterstützung diverser synchroner Bitraten erfolgen kann. Folgende eSCO-Pakete sind definiert und können sowohl für die 64kbit/s-Sprachübertragung als auch für den transparenten Datentransport mit 64kbit/s oder einer anderen Bitrate genutzt werden: EV3 - variable Paketgröße zwischen 1 und 30 Byte und zusätzlich 16 Bit CRC - keine FEC - Paket darf maximal einen Zeitschlitz einnehmen EV4 - variable Paketgröße zwischen 1 und 120 Byte und zusätzlich 16 Bit CRC - 2/3 FEC - Paket darf maximal drei Zeitschlitze einnehmen EV5 - variable Paketgröße zwischen 1 und 180 Byte und zusätzlich 16 Bit CRC - 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

21

Quelle: Bluetooth Core Specification 1.2

Abbildung 1.14 – Asymmetrischer Datenverkehr

Fazit: In der Praxis bedeutet der neu spezifizierte Übertragungsmodus eSCO eine verbesserte und flexiblere Übertragung, welche (begrenzte) Retransmissionen mit einem sehr geringen „Echtzeit-Verlust“ bietet.

1.3.2.3.4. Interferenzminimierung durch AFH Die Zunahme von Funkfrequenztechniken, welche sich des gemeinsam genutzten ISM-Bands (2,4GHz) bedienen, führt zu einem Problem – Interferenzen zwischen parallel eingesetzten Techniken. Bluetooth-Geräte, die das herkömmliche Frequenzsprung-Verfahren (Frequency Hopping) nutzen, merken aufgrund ihrer robusten Modulation wenig vom benachbarten Funkverkehr, aber beeinträchtigen diesen spürbar. In diesem Zusammenhang sollte der Funkstandard WLAN (IEEE 802.11b) genannt sein, welcher teils starke Leistungseinbußen durch Bluetooth hinnehmen muss. Häufig findet dieser seinen Einsatz in Umgebungen, wo auch Bluetooth-Geräte parallel kommunizieren. Ein Beispielszenario wäre ein Laptop, der mittels WLAN eine Internetverbindung herstellt und Druckaufträge via Bluetooth an einen Drucker sendet. Neben dem Aspekt, dass diese Bluetooth-Übertragungen Interferenzen verursachen, werden auch sie durch Interferenzen gestört. Daraus folgt beispielsweise ein Einbruch des Datendurchsatzes im ACL-Modus, verursacht durch die häufige Retransmission von verloren gegangenen oder defekten Datenpaketen. Ein weiteres Beispiel ist die Audio-Übertragung (SCO) über ein Bluetooth-Headset. Hierbei machen sich Interferenzen durch ein teilweise unangenehmes Rauschen im Kopfhörer bemerkbar.

22

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

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

Auf diese Problematik hat das Herstellerkonsortium reagiert und stellte ein Verfahren namens Adaptive Frequency Hopping AFH vor, worauf am Ende dieser Arbeit in einem gesonderten Kapitel eingegangen wird. Mit AFH soll eine Kommunikation von Bluetooth-Geräten erfolgen, welche Rücksicht auf andere benachbarte Funktechnologien nimmt und fest genutzten Frequenzbändern von schmalbandigen Störungen ausweicht.

1.3.2.3.5. Abwärtskompatibilität zu Bluetooth v1.1 Der neue Standard soll abwärtskompatibel zu Bluetooth 1.1 sein, verspricht das Bluetooth-Herstellerkonsortium. Doch kann ein Gerät der Version 1.1 nicht in einem Piko-Netz der neuen Generation als Master agieren. Diese Einschränkung ist durch das neue adaptive Frequenzsprungverfahren begründet.

1.3.2.3.6. Anlehnung der Wortwahl an IEEE Viele Teilabschnitte von vorangegangenen Bluetooth-Spezifikationen erschwerten den Lesern, durch eine unpräzise oder inakkurate Wortwahl, das Herauslesen wichtiger Informationen. Durch die Anlehnung der Wortwahl an die Empfehlungen der IEEE kann nun deutlich vereinfacht zwischen zwingend notwendigen Implementierungsinformationen und Hintergrundinformationen differenziert werden. Nähere Informationen dazu können

- in der Bluetooth 1.2 Core-Specification auf Seite 149

23

- und im IEEE Style Guide ( http://standards.ieee.org/guides/style/ ), welcher als Grundlage für die Verbesserung der Wortwahl diente,

nachgeschlagen werden.

1.3.2.3.7. Grundlegende Umstrukturierung Die grundlegende Umstrukturierung der Gesamtspezifikation besteht aus zwei wesentlichen Punkten:

1. Flexiblere Spezifizierung von Profilen und Protokollen Wie bereits im entsprechenden Abschnitt erwähnt, bestand die Bluetooth-Gesamtspezifikationen der Versionen 1.0x und 1.1 aus zwei Hauptteilen, Core-Specification (Volume I) und Profile Definitions (Volume II), welche immer gleichzeitig und zusammenhängend publiziert wurden. Nach der Veröffentlichung von Bluetooth 1.1 bestand die Notwendigkeit einer flexibleren Spezifizierung und Veröffentlichung neuer bzw. verbesserter Profile und Protokolle, welche zeitlich unabhängig von der Publikation der Core-Specification erfolgen kann. Man beschloss die Profile und die Protokolle (welche nicht Bestandteil der Kernspezifikation sind) als jeweils einzelne Teilspezifikationen zu führen, welche mit einer Versionsnummer versehen sind, die mit jeder Änderung erhöht wird. Mit diesem Schritt ermöglicht die SIG ein Hinzufügen und Abändern von Profilen und Protokollen zu jeder Zeit. 2. Restrukturierung der Bluetooth-Core-Specification 1.2 Der Inhalt dieser derzeit aktuellen Kernspezifikation ist in einer deutlich veränderten Struktur dargestellt, welche eine bessere Folgerichtigkeit und Lesbarkeit sicherstellen soll. Die wichtigsten Umstrukturierungen fanden im Bereich Baseband, LMP, HCI und L2CAP statt, wobei die Information in einer logischeren Reihenfolge präsentiert wird, als es bei den Vorgängerversionen der Fall war. Diese Restrukturierung fiel uns bei unserer Recherche als sehr positiv auf.

1.3.2.3.8. Verabschiedung neuer Profile Zum Zeitpunkt der Veröffentlichung der Bluetooth-1.2-Kernspezifikation wurden fast zeitgleich eine Reihe weiterer Profile definiert, welche der Funktechnik neuen Schub verleihen könnte. Drei neue Profile, darunter das „Advanced Audio Distribution Profile“ (A2DP), gelten der Verbesserung von Audioanwendungen. Damit sowie mit Hilfe von Kompression lassen sich Stereosignale mit hoher Qualität übertragen. Des Weiteren verabschiedete die SIG das „Audio/Video Remote Control Profile“, das für die Fernsteuerung von Audio- und Videogeräten ausgelegt ist. Neu sind auch das „Hands Free Profile“ (HFP) und das „SIM Access Profile (SAP)“, die auf den Automarkt zielen: Damit können Fahrzeug-Freisprecheinrichtungen Handys kontrollieren bzw. Profile und Adressen eines Mobiltelefons an das Autotelefon überwiesen werden, ohne dass hierzu die SIM-Karte gewechselt werden muss.

1.3.2.3.9. Anonymity Mode In der Version 1.2 gibt es die Möglichkeit, ein Bluetooth-Gerät im so genannten Anonymity Mode zu betreiben. Dieser ist ein optionales Sicherheitsmerkmal, welches vom Hersteller angeboten werden kann, und verbirgt die eigentliche MAC-Adresse. Es wird, z.B. zum

24

paarweisen Datenaustausch, eine zufällig ermittelte fiktive Adresse gleichen Formats verwendet, welche dann auch periodisch neu generiert wird. Da die Kern-Spezifikation keine Festlegungen hierzu trifft, ist es den Herstellern überlassen wie diese Möglichkeit implementiert wird.

1.3.2.4. Ausblick auf Bluetooth 2.0 Im Rahmen eines Bluetooth-Kongresses, welcher Mitte Juni 2003 stattfand, sickerten erste Details zu den bislang sorgsam gehüteten Spezifikationen der Bluetooth-Version 2.0 durch. Es wird erwartet, dass Bluetooth 2.0 mit Bruttotransferraten von bis zu 4, 8 und 12 Mb/s, bei gleich bleibender Reichweite, operieren soll, was ihm den Beinamen Highrate einbringt. Die neue Spezifikation 2.0 bietet ebenfalls neue Kommunikationsmodi, welche auf dem derzeit verwendeten System aufbauen. Sie ermöglichen, durch Nutzung eines Schmalbandkanals unter Verzicht auf Bandspreizung sowie von verteilten MAC-Protokollen, schnellere Antwortzeiten und eine integrierte QoS. Dieses neuartige verteilte Protokoll dient der Verminderung derzeit bestehender Probleme hinsichtlich der Master/Slave-basierten Piko-Netze, wobei aus dem Verlust des Masters ein Zusammenbruch des Piko-Netzes resultiert. Bluetooth 2.0 verzichtet auf die Master-Rolle und erhebt jede Einheit zum so genannten Supervisor, wodurch eine kontinuierliche Kommunikation innerhalb des Piko-Netzes ermöglicht wird. Des Weiteren soll es eine Broadcast- bzw. Multicast-Unterstützung bieten. Die neuen Fähigkeiten sind allerdings mit einer gegenüber Bluetooth 1.0 verdoppelten Stromaufnahme zu bezahlen. Bei der Entwicklung wird die Kompatibilität bzw. paralleler Einsatz zu den „low-rate“-Versionen ab 1.1 angestrebt.

1.3.3. Bluetooth in der IEEE Das 1963 gegründete Institute of Electrical and Electronics Engineers (IEEE) ist ein Gremium für Normungen in elektrischen und elektronischen Verfahren, deren weltweit mehr als 360.000 Mitglieder sich in erster Linie ebenfalls aus Herstellern sowie Forschungseinrichtungen rekrutieren. In diversen Arbeitsgruppen ist das IEEE eine der führenden Organisationen bezüglich der Standardisierung auf dem Gebiet der Raumfahrt, Computer und Telekommunikation, biomedizinischen Ingenieurstechnik, elektrischen Energie und elektronischen Geräten. Einer der bekanntesten und wichtigsten Interessenbereiche des IEEE ist das IEEE 802 LAN/MAN Standards Committee, auch LMANSC genannt, welches sich mit der Standardisierung für Kommunikations-Netzwerke beschäftigt. Es wurde um 1980 aus der Notwendigkeit gegründet, die Vielfalt aller möglichen Netzwerk-Systeme, z. B. in der Verkabelung, der Übertragungsgeschwindigkeit und -technik zu standardisieren. Seine Arbeit beschränkt sich zum größten Teil auf die zwei untersten Schichten des bekannten ISO/OSI-Modells. Die IEEE 802 ist hierarchisch in Arbeitsgruppen unterteilt. Einige wichtige seien hier genannt:

• IEEE 802.3 Ethernet / CSMA/CD-Zugriffsverfahren • IEEE 802.11 WLAN – Wireless Local Area Network • IEEE 802.15 WPAN – Wireless Personal Area Network

Letzt genannte Arbeitsgruppe befasst sich mit kabelloser Nahbereichskommunikation, z.B. für portable Geräte wie PDAs. Das Ziel ist auch hier, Standards, Empfehlungen und Anleitungen auszuarbeiten, welche die Gesichtspunkte der Interoperabilität und Koexistenz

25

zu anderen Datenübertragungs-Standards sicherstellen sollen. In den Bereich von WPAN reiht sich neben anderen die Bluetooth-Technologie ein. Sie wurde, aufgrund eines Lizenzabkommens zur Kompatibilität zwischen Bluetooth-SIG und IEEE, im März 2002 mit dem Standard 1.1 in den Rang eines IEEE-Standards erhoben. Diese Zusammenarbeit teilt sich generell in die Aufgabenfelder technische Weiterentwicklung und Integration der Bluetooth-Technologie seitens der Bluetooth-SIG und Prüfung nach eigenen Kriterien und Entwicklung von Änderungsempfehlungen seitens der zuständigen IEEE 802.15 Task Groups (TG). Die TGs bearbeiten jeweils eine spezielle Aufgabe. Die TG IEEE 802.15.1 hat den Bluetooth-Standard 1.1 geprüft und in die IEEE-Spezifizierungen übernommen. Die Übernahme erfolgte auf Basis der Kernspezifikation, welche die physikalische Schicht, in diesem Fall RF, und die MAC-Layer, die das Baseband, das L2CAP sowie das LMP umfasst. Weiterhin wurde ein Satz von allgemeinen SAPs entwickelt, welche das auf die MAC-Schicht aufsetzende ISO/IEC 8802-2 LLC ermöglicht. Der bereits von der Bluetooth-SIG verabschiede Standard 1.2 soll durch die TG IEEE 802.15.1a eingegliedert werden. Mit der Sicherstellung der Koexistenz von IEEE 802.15 WPAN und IEEE 802.11 WLAN befasst sich die TG IEEE 802.15.2. Diese Expertengruppe entwickelt Koexistenz-Mechanismen für Transceiver, wodurch gegenseitige Interferenzen von WLAN und WPAN ausgeschlossen werden sollen. Bei Entwicklung eines Interferenz-minimierenden Übertragungsverfahrens (AFH) für Bluetooth 1.2, durch die Bluetooth-SIG, flossen Empfehlungen von dieser Task-Group mit ein.

1.4. Bluetooth-Protokollstapel

1.4.1. Einleitung Der Aufbau der Protokollarchitektur des Bluetooth-Standards folgt der Grundidee der kabelersetzenden Funkdatenübertragung und orientiert sich auch am bekannten ISO/OSI Schichtenmodell. Daher wurden die verwendeten Protokolle nach der besten Verwendbarkeit für eben diese Aufgabe entworfen bzw. übernommen. Der gesamte Protokollstapel für Bluetooth-Verbindungen kann in vier Hauptgruppen nach ihren allgemeinen Aufgaben eingeteilt werden. Diese sind, wie auch in folgender Tabelle verdeutlicht, die Bluetooth-Kern- das Kabelersatz-, die Telefonie-Steurungs- und weitere aufgesetzte anwendungsspezifische Protokolle.

Schicht Protokoll

Bluetooth Kernprotokolle Baseband, LMP, L2CAP, SDP

Cable Replacement Protocol RFCOMM

Telefonie TCS-bin, AT-Kommandos

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

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

26

Der der komplette Stapel enthält zwei Kategorien von Protokollen. Zum einen die Bluetooth-spezifischen 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

vCard/vCalOBEX

WAEWAP

AT-Commands

TCS-bin SDP

TCP UDPIP

PPP

Kabelersatzprotokoll (RFCOMM)

L2CAP

LMP

Basisband & Link Control

Bluetooth Radio

AudioHCI

Softw

are

Har

dwar

eSCO

ACL

Abbildung 1.16 – Die Protokollarchitektur

27

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.

28

• 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

29

keinen Transport von Audiosignalen, d.h. von Daten synchroner Übertragungskanäle. Weiterhin ist eine Kommunikation mit Gruppen nur mit einem Broadcast möglich, eine Multicast-Verbindung ist hingegen bislang noch nicht verfügbar, wird aber voraussichtlich zum Funktionsumfang von Bluetooth 2.0 gehören.

1.4.2.1.4. Das Host Controller Interface (HCI) Zusätzlich zu den obigen Protokollen existiert noch ein Host Controller Interface (HCI). Dieses Interface entspricht einem Kommando-Interface für den Baseband Controller, Link Manager, und zu den Hardware-Status- und Kontrollregistern. Das Host Controller Interface (HCI) liefert einen gemeinsamen standardisierten Übergang zwischen einem Host und einem Bluetooth-Gerät, spezifiziert für verschiedene Schnittstellen, wie USB, RS232, PCI u.a. . Das bedeutet für den Anwender, wenn eine PC-Card als Bluetooth Adapter-Card verwendet wird, dass er damit auch an entsprechende Sende-/Empfangsmodule dieses Herstellers gebunden ist, da hier die Schnittstelle zwischen Adapter und BT-Modul vom Hersteller spezifiziert werden kann. Entscheidet man sich aber für eine serielle Lösung, so kann man sich dank des standardisierten HCI den Hersteller aussuchen. Die folgende Abbildung zeigt noch einmal die verschiedenen Anschlussarten der Bluetooth-Module. Man sieht deutlich wie vom Betriebsystem des Hosts über die verschiedenen Interfaces (USB, RS232 oder PC-Card) ein Anschluss an die Bluetooth-Module erfolgt.

Abbildung 1.17 – Anschluss an einen Host

30

1.4.2.1.5. Service Discovery Protocol (SDP) Das Service Discovery Protocol (SDP) erlaubt es Anwendungen, die Dienste und Eigenschaften anderer Bluetooth-Geräte zu erkennen. Diese Dienste können dann durch andere Protokolle genutzt werden. Das SDP ist Basis aller Verbindungsmöglichkeiten höherer Verbindungen. Es stellt in einer Services Discovery Datenbank (SDDB) die Dienste-Struktur eines Bluetooth-Gerätes bereit, wodurch Ad-hoc-Netzwerke überhaupt erst ermöglicht werden. Eine zentrale Verwaltung von Dienstleistungsinformationen auf einem oder mehreren Kommunikationseinheiten widerspricht dem Gedanken eines dynamischen Ad-hoc-Netzwerkes. Deshalb geht kein Weg daran vorbei, dass jedes Bluetooth-Gerät selbst Informationen darüber verwaltet, welche Dienste es zur Verfügung stellt. Nachdem das Bluetooth-Gerät die Dienste, welche von anderen (verbundenen) Bluetooth-Geräten in seiner direkten Umgebung angeboten werden, entdeckt hat, kann eine Auswahl der gewünschten Dienste getroffen werden. Danach kommt es zum Verbindungsaufbau mit einem oder mehreren Bluetooth-Geräten, um den ausgewählten Dienst zu nutzen. Die weitere Kommunikation läuft dann ohne Beteiligung des SDPs. Dieser Service stellt die Grundlage aller Bluetooth-Nutzermodelle dar und ist der wichtigste Teil des gesamten Protokoll-Rahmenwerks. Über SDP werden alle für die Datenübertragung nötigen Informationen ausgetauscht, um dann eine Verbindung zwischen zwei oder mehreren Bluetooth-Projekten einzurichten.

1.4.2.1.6. Audio Die Audio-Spezifikation definiert die Sprachübertragung, speziell die Kodierung und Dekodierung. Audiodaten können zwischen mehreren Geräten direkt übertragen werden. Dabei werden die Daten nicht erst durch die L2CAP-Schicht geschickt. Audiotransfers sind im Allgemeinen recht einfach realisierbar. Für Kopfhöreranwendungen gibt es ein PCM-Rohdatenformat, welches im Direktmodus an allen Protokollen vorbeigeführt werden kann (SCO). Diese Audiodaten können parallel zu anderen Daten verschickt werden und mit verschieden Fehlerkorrekturverfahren behandelt werden. Durch Öffnen eines Audio-Links kann jede Station zu einer anderen "Sprache" übertragen. Die resultierenden Paketformate werden später näher vorgestellt.

1.4.2.2. Cable Replacement Protocol

1.4.2.2.1. RFCOMM (Radio Frequency Communication) Als Schnittstelle zur realen Applikation ist das Kabelersatzprotokoll RFCOMM von besonderer Bedeutung. Es stellt der Hostseite virtuelle serielle Verbindungen bereit. Dazu simuliert RFCOMM bis zu 60 virtuelle serielle Schnittstellen nach dem RS-232-Standard mit einer maximalen Geschwindigkeit von 115 kbps, wodurch eine breite Unterstützung beliebiger höherer Protokollschichten erreicht wird. Dabei wird allerdings nur eine Untermenge der möglichen Features des abgewandelten ETSI-Standards TS 07.10 durch Bluetooth verwendet. Die Ablaufsteuerung zur Steuerung der Verbindung erfolgt entweder durch Software in Form von XON/XOFF-Steuerzeichen oder über einen Hardwarehandshake wie RTS/CTS oder DTR/DSR. (RTS: "Ready To Send", CTS: "Clear To Send", DTR: "Data Terminal Ready", DSR: "Data Set Ready") Durch BENP (Bluetooth Encapsulation Network Protocol) um direkt PPP zu ersetzen und HID-Profile zur Emulation von USB-Schnittstellen, sowie der direkten Anbindung von

31

Peripherie-Geräten über Hardcopy Replacement Protocol (HCRP) wird RFCOMM im Standard 1.2 erheblich entlastet. Über den Schnittstellen RFCOMM und L2CAP sitzen dann Protokolle wie IP, WAP oder Kartenterminalanwendungen, um mittels spezieller Anwendungen Daten über die Funkschnittstelle auszutauschen. Dabei laufen die Anwendungen über eine oder mehrere vertikale Kanäle des Protokoll-Stapels. Der Grund-Stapel bis RFCOMM wurde, wie bereits erwähnt, so konzipiert, dass bereits vorhandene und bewährte Protokolle darauf aufsetzen können, um maximale Kompatibilität zu erreichen. Durch die Offenheit des Standards ist vorauszusehen, dass eine Menge verschiedener Anwendungen den Markt erobern werden, welche die Möglichkeiten der Bluetooth-Technologie voll ausnutzen können. In sogenannten Profilen werden die zu verwendenden Protokolle je nach Anwendungsfall empfohlen.

1.4.2.3. Telefonie-Steuerungs-Protokolle Die Telephony-API (Application Programming Interface) ermöglicht die Verwendung der Telefon-Funktionen innerhalb der Bluetooth-Umgebung. Damit konnte der Zielstellung Rechnung getragen werden, dass Bluetooth nicht nur im Bereich der Netzwerk- und Computertechnik sondern auch bei den Telefonanwendungen Anklang finden soll. Die Abwicklung der Telefonie-Dienste wurde durch zwei verschiedene Protokollarten umgesetzt.

1.4.2.3.1. Telephony Control – Binary TCS-BIN stellt ein bitorientiertes Protokoll zum Auf- und Abbau von Sprach- und Datendiensten zwischen zwei Geräten zur Verfügung. TCS-BIN baut auf Q.931 der ITU-T auf und enthält Rufkontrolle, Verbindungsaufbau, Sprachübertragung und Datenübertragung. Q.931 ist auch Grundlage für die Rufsteuerung bei ISDN. Die Telephony Control Protocol Specification (TCS) ermöglicht die Signalisierung für die Herstellung und Unterhaltung von Daten- und Sprachverbindungen (Terminal, Gateway, Lautstärke, Auflegen/Abheben,...).

1.4.2.3.2. Telephony Control – AT Commands AT-Befehle nutzen zu ihrer Übertragung in der Regel eine serielle Port-Emulation über das RFCOMM-Protokoll. Die AT-Befehle, basierend auf V.250 und ETS 300 916 der ITU-T, wurden von der Bluetooth-SIG erweitert und ermöglichen verschiedene Varianten zur Nutzung von Mobiltelefonen und Modems. Ein Beispiel ist die Nutzung eines Faxdienstes.

1.4.2.4. Aufgesetzte Protokolle Eine Vielzahl von Protokollen sind auf die beschriebenen Basisdienste aufgesetzt. Es sei hier eine Auswahl genannt:

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

• TCP/IP wird in Internet-Anwendungen eingesetzt. • Eine Menge von AT-Kommandos ermöglicht die Steuerung über eine Terminal-

Verbindung. • WAP unterstützt mobile Anwendungen

Die so genannten angepassten Protokolle werden unverändert vom Industriestandard übernommen. Sie führen zur eigentlichen Applikation, womit sie die Interoperabilität mit

32

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.

33

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

34

Jedes Paket beginnt mit einem Zugangscode (Access Code) zur Signalisierung, bestehend aus 4-Bit-Preamble zum Gleichstromausgleich, 64-Bit-Synchronisationsword, welches je nach Signalisierungstyp von der verwendeten Bluetooth Device Address abgeleitet wird, und einem 4-Bit-Trailer, ebenfalls zur Gleichstromkompensation, insofern ein Paketheader folgt. Dieser Code insgesamt dient somit der Zuordnung eines Pakettypes, der Synchronisation und der Offset-Kompensation bei der Übertragung eines Pakets zwischen zwei Bluetooth-Transceivern. Ein Paket besteht also immer aus dem Zugangscode (wenn allein, dann als shortened Access Code zur Synchronisation in Paging-, Inquiry- und Park-Modi) und kann weiterhin nur einen Paketheader oder Header und Payload enthalten. Man unterscheidet bei der Signalisierung folgende drei Typen des Access Codes:

• Channel Access Code (CAC) o identifiziert eindeutig ein Pico-Netz o LAP-Teil der Masteradresse verwendet

• Device Access Code (DAC) o Signalisierung für ein bestimmtes Gerät o LAP-Teil der Adresse des angesprochenen Gerätes verwendet

• Inquiry Access Code (IAC) o Ermittlung aller erreichbaren Geräte (Global-IAC) oder o Ansprechen von Gruppen (Dedicated-IAC) o für den globalen Rundruf reservierter Wert als LAP verwendet o bei einem der 63 möglichen dedizierten Aufrufe der dedizierte LAP-Wert

Im Header befindet sich die Information zur Paketnummerierung und -bestätigung, für den Automatic Repeat Request (ARQ) zur erneuten Anforderung bei fehlerhafter Übertragung, sowie die Geräteadressierung, Flusskontrolle und weitere Fehlerkorrekturmaßnahmen wie Forward Error Correction FEC – hier 1/3 FEC wodurch aus den in der Skizze aufgezählten 18Bits 54Bits werden. Die verwendeten Bezeichnungen bedeuten:

• AM_ADDR - Active Member Address • Type - Pakettyp • Flow - Flusskontrolle • ARQN - Acknowledge Indication - Bestätigung • SEQN - Sequenznummer • HEC - Header Error Check – Fehlerkontrolle des Paketkopfes

Die folgenden, bis zu 2745 Bit Payload enthalten die transportierten, vom Pakettyp unabhängigen Nutzdaten. Sie entsprechen entweder Daten oder Sprache und können ebenfalls durch ein 16bit Cycling Redundancy Check CRC gesichert werden.

35

Kapitel 2 - Verbindungsanalyse

2.1 Vorstellung des Bluetooth-Protokolltesters FTS Zur Visualisierung der Kommunikation von Bluetooth-Geräten wurde das Frontline Test System „FTS for Bluetooth“ von Frontline Test Equipment verwendet. Diese weit verbreitete Software wird vorwiegend zur Entwicklung und Zertifizierung von Bluetooth-Anwendungen und -Geräten herangezogen. Es findet daher auch im sogenannten BQB Bluetooth Qualification Process Anwendung. FTS bietet grundsätzlich zwei verschiedene Möglichkeiten des Mitschneidens der Kommunikation zwischen Bluetooth-Transceivern. Es handelt sich dabei immer um Kommunikationspaare bestehend aus Master und Slave.

• Airsniff: Das Monitoring der Luftschnittstelle erfolgt berührungsfrei über eine spezielle Hardware – Comprobe am USB-Port des überwachenden Rechners.

• via HCI: Hierbei findet ein Mitschnitt des Verlaufs aller Informationen durch Überwachung des Host Controllers statt. Dies kann einerseits durch Verbindung beider beteiligter Host mit dem überwachenden Rechner mittels serieller Kabel oder der direkten Erfassung der Kommunikation über Host Controller eines beteiligen Bluetooth-USB-Gerätes. Auf Grund von gravierenden Treiberproblemen für die programmspezifische Ansteuerung der COM-Schnittstellen war die Realisierung des HCI serial sniff nicht möglich. Die Wahl fiel somit auf das erstgenannte Verfahren – Airsniff.

2.1.1. FTS – Airsniff (basic) Tutorial Ein PC überwacht mit Hilfe des Comprobes und des installierten FTS die Luftschnittstelle (Baseband) des Kommunikationspaares. Der Comprobe ist als ein nicht vollwertiges Bluetooth-Gerät zu verstehen. Dieser findet alle aktiven Geräte der Umgebung, wobei er selbst für diese „unsichtbar“ bleibt, synchronisiert sich auf das zu kontrollierende Master-Slave-Paar ein und protokolliert alle empfangenen Pakete. Dabei beteiligt er sich an jeglicher Bluetooth-Kommunikation nicht. Der Comprobe sollte möglichst zwischen den beiden Kommunikationspartnern positioniert werden, um das Problem der Nichtregistrierung von Paketen zu vermeiden.

36

Abbildung 2.1 – Messanordnung Airsniff

Ebenso kann es vorkommen, dass bei ungünstiger Konstellation (Distanz, Interferenzen) eines der überwachten Geräte ein vom Comprobe korrekt empfangenes Paket gestört oder gar nicht empfängt. Ist das Verhalten eines Kommunikationsteilnehmers von speziellem Interesse, so sollte der Comprobe in dessen unmittelbarer Nähe aufgestellt werden. Zur Überwachung mehrerer Gerätepaare ist die Verwendung ebenso vieler Comprobes erforderlich. Dadurch ist ab der FTS for Bluetooth Version 3.20 die Überwachung von Pico- respektive Scatter-Netzen, sowie Mixed Pico-Netzen (v1.1 und v1.2-Geräte mit aktiviertem AFH) möglich. Auch an die gesetzten Systemvoraussetzungen sollte man sich streng halten, da sonst der Mess-PC nicht in einer tolerierbaren Performance oder sogar mit Fehlern arbeitet. Es hat sich ebenso als günstig erwiesen, so weit möglich einen nicht an der zu überwachenden Kommunikation beteiligten PC als Mess-PC einzusetzen. Nach der erfolgreichen Installation der Software FTS for Bluetooth und der folgenden Hardwareinstallation des Comprobe, sollte man sich die Zeit nehmen, sich mit den Bedien- und Ausgabefenstern der Software vertraut zu machen. Folgende kurze Erläuterungen sollen dabei helfen die Produktvariante FTS for Bluetooth air sniffer (basic) und darauf aufbauende schnell effektiv bedienen zu können. FTS wird von einem Hauptfenster aus organisiert und greift auf ein weiteres Fenster mit der Datenquelle (Datasource window), im beschriebenen Fall verwaltet dieses den Comprobe, zu. Vom genannten Hauptfenster aus kontrolliert man die gesamte Datenerfassung und hat Zugriff auf alle Darstellungsvarianten. Die beiden Erfassungsmethoden, in Arbeitsspeicher oder in Datei schreiben, unterscheiden sich nicht wesentlich, da sich bei Wahl der Pufferung im Speicher das Ergebnis auch anschließend noch, sogar beim Schließen der gesamten Anwendung automatisch erfragt, in eine Datei exportieren lässt. Lediglich die Kapazitätseinschränkung seitens des vorhandenen Arbeitsspeichers gegenüber dem sofortigen Schreiben auf Festplatte kann sich bei großen Datenmengen nachteilig auswirken. Die Nutzung der Speichervariante ist daher, bei mehrmaligen kurzen Tests, aufgrund des weit geringeren Datei-Management-Aufwandes zu bevorzugen. Man kann am Ende einer Messung entscheiden, ob sich die Speicherung der Protokollierung lohnt.

37

Bevor man Daten erfassen kann, muss die Datenquelle mit allen möglichen Parametern eingestellt und der Comprobe mit dem überwachten Pico-Netz synchronisiert werden. Dies geschieht natürlich direkt im „Datasource“-Fenster. Der Button „Hardware Settings“ erlaubt die Auswahl eines aus der List aller angesteckten Test-Devices, sollte sich aber im Normalfall auf den eingesteckten Comprobe beschränken. Es kann zu Problemen mit der Erkennung eines Coprobes kommen, sobald dieser seit dem letzten Systembootvorgang neu eingesteckt wurde. Hier empfiehlt sich die manuelle Erkennung mit Hilfe der Listenauswahl. Ist ein Comprobe erkannt, so können über den Button „Set I/O Parameters“ die Einstellungen zur Synchronisationsmethode mit dem Pico-Netz, Filterung bestimmter Elemente des Datenstromes und Entschlüsselung vorgenommen werden. Weiterhin sind hier das Auffinden von aktiven Geräten und die Auswahl des zu überwachenden Mast-Slave-Paares auszuführen. Die Button „Resync“ und „Reset“ sind bei Problemen mit der Synchronisation behilflich. Die Taste „Channel Map“ zeigt die Kanalliste der verwendeten Frequenzkanäle und ist daher nur bei Verwendung von Bluetooth-v1.2-Geräten und Aktivierung von AFH sinnvoll. Zum Starten bzw. Stoppen des Comprobes sind die entsprechend benannten Tasten zu drücken. Der Comprobe wird allerdings noch nicht gestartet, da erst die Erfassung der Daten aktiviert werden sollte. Zur Erfassung von Daten ist nur das Hauptfenster mit seinen Steuerknöpfen und dem darunter befindlichen Statusbereich erforderlich. So wählt man mit [start capture to buffer] oder

[start capture to disk] den Beginn der Erfassung in den Speicher oder in eine gleich darauf neu angelegte Datei. Daraufhin sollte der Comprobe im „Datasource“-Fenster gestartet werden. Das Symbol in diesem Fenster zeigt dabei den Status der Synchronisation mit dem Pico-Netz an. Hierbei bedeutet das durchgestrichene rote das der Comprobe nicht aktiv ist, rot die Initialisierung, gelb einen Resynchronisationsversuch und grün den Stand-by-Zustand des aktiven Comprobe, also die Zeit innerhalb welcher der Start der Bluetooth-Kommunikation erfolgen sollte. Ist dies rechtzeitig geschehen, erkennt man das Mitschneiden einer laufenden Kommunikation des vorher ausgewählten Master-Slave-Paares respektive die korrekte Synchronisierung am blauen Symbol. Das Anhalten der Erfassung und gleichzeitige Löschen des Speicherpuffers geschieht mit [Clear], respektive Schließen der Datei mit [Close]. Zum Anhalten der Datenerfassung, um beispielsweise den Mitschnitt vorläufig zu beenden oder nur den Inhalt des Puffers nun zu speichern, bedient man [Pause/Resume] und setzt sie durch erneutes Drücken fort. Die Anzeige über den Füllstand des Puffers/der Datei im unteren Status-Teil des Hauptfensters sollte man immer im Auge behalten, da bei Überschreiten der Maximalkapazität entweder die ältesten Daten mit den neuen überschrieben werden oder bei Nichtaktivierung dieser Funktion (Options -> System Settings -> Wrap Buffer/File) keine weiteren Daten mehr erfasst werden. Zur Auswertung aktuell erfasster oder aus einer, mit Hilfe von [Open file] geöffneten, existierenden Datei geladenen Daten, stehen mehrere Fenster mit verschiedenen Darstellungsformen zur Verfügung. Bei Bedarf können diese auch live zur Auswertung herangezogen werden, was in gegebenem Fall zur Entscheidung des Abbruchs der Registrierung oder zumindest der Kenntnis über den Verlauf des Tests behilflich sein kann.

Statistics Display – statistische Informationen zu Datenfluss-Parametern Frame Display – textbasierte Informationen einzelner Frames Protocol Navigator – textbasierte Informationen mehrerer Frames Event Display – Analyse auf Byte-Ebene

38

Statistics Display Es gibt eine Übersicht der angefallenen Datenmengen, verwendeten Framegrössen, Kanalnutzung, Übertragunsraten und Frameraten auf Master und Slave aufgeschlüsselt. Des Weiteren ist die Gesamtzahl der fehlerhaften und der erneut übertragenen Pakete ersichtlich.

Abbildung 2.2 – Screenshot FTS-Statistics Display

Die drei verschiedenen Karteikarten haben folgende Verwendung: Session – Statistik über die komplette Sitzung bis Programmende Resetable – manuelles Rücksetzen der Statistik durch [reset] jederzeit möglich Buffer – Statistik über aktuell gepufferten Daten Zusätzlich lassen sich die Frame-Größen auch graphisch in einem extra Fenster darstellen, welches über den Button erreichbar ist. Vor Beginn eines Capturings kann auch Einfluss auf die Frame-Grössen-Bereiche der Statistik genommen werden (Options -> Set Frame Size Ranges). Frame Display Die enthaltene Information eines in der oberen Fensterhälfte ausgewählten Frames, auch nach den enthaltenen Protokollen gefiltert, kann hier eingesehen werden. Es gibt 3 spezielle Anzeige-Filtermöglichkeiten:

39

- 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

40

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.

41

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

42

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 Slave

LMP_name_req(offset=0)

LMP_detach

LMP_name_res(offset=0,Len=20,"TU-Laptop_Expl")LMP_name_req(offset=14)

LMP_name_res(offset=14,Len=20,"orer_B")

Abruf des Gerätenamensmit Überlänge

LM-Verbindungsabbau

BB_retransmitted_LMP_packet123456

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 Master-

43

Host der MAC-Adresse des Slave den Namen zugeordnet so beendet er diese LMP-Verbindung vorerst mit dem LMP-Detach. Es folgt noch die gegenseitige Information über die verwendete Version des LM-Protokolls mit Hilfe von einem Master-Request und dem entsprechenden Slave-Response. Erfolgt nun der Verbindungswunsch durch den Master-Host (Host-Connection-Reqest), sobald der Datentransfer gestartet wird, so sendet der Master dieses als LMP- Host-Connection-Reqest an den Slave. Dieser akzeptiert und bestätigt genau diese Anfrage mit einer LMP-Accepted-Antwort. Hierauf folgt die Abfrage der Zeitmessgenauigkeit des Masters an den Slave, welcher mit dem entsprechenden Response und den erfragten Parametern Abweichung (drift) und Zittern (jitter) antwortet. Der Master sowie der Slave senden sich nun nacheinander die Initialisierungsende-Information zu.

LMP_accepted (LMP_host_connection_req)

LMP_timing_accuracy_reqLMP_timing_accuracy_res(drift=20ppm,jitter=1µs)

LMP_setup_completeLMP_setup_complete

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

Vergleich der Zeitmessung

Ende der Initialisierung

78

910

1112

1314

Abbildung 2.7 – MSC-Frame 7-14 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.

LMP_max_slot_req(5)LMP_accepted (LMP_max_slot_req)

LMP_max_slot(5)

max. Zeitschlitze f. ein Paket151617

Abbildung 2.8 – MSC-Frame 15-17 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

44

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.

L2CAP_connection_req(SDP)L2CAP_connection_res(connection_successful)

SDP Verbindungswunsch1819

L2CAP_cofigure_req(MTU=65535,FlushTimeout=65535)L2CAP_configure_res(success)

L2CAP_cofigure_req(MTU=65535,FlushTimeout=65535)L2CAP_configure_res(success)

2021

2223

L2CAP Init f. SDP

Abbildung 2.9 – MSC-Frame 18-23 Zur optimalen Einstellung des Stromverbrauchs sendet jedes kommunizierende Bluetooth-Gerät – ob mobil oder nicht – , gesteuert durch seinen Link Manager, Anfragen zur Verringerung der Sendeleistung an den Kommunikationspartner. Dies geschieht im Beispiel zum ersten Mal im folgend abgebildeten Frame und wiederholt sich bis beide Seiten ihr Minimum oder eine zur gesicherten Übertragung mindest notwendigen Sendeleistung erreicht haben. Im weiteren Verlauf wird dieses Wissen über die unbestätigten LMP-Power-Decrease-Requests vorausgesetzt.

LMP_power_decr_req24 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.

SDP_SSARequest(OBEXPush)SSA .. ServiceSearchAttributeAbfrage v. OBEX-Diensten25

SDP_SSAResponse(L2CAP,RFCOMM(3),OBEX)SDP_SSARequest(OBEX File Trans)

SDP_SSAResponse(L2CAP,RFCOMM(2),OBEX)

SDP_SSARequest(Imaging Responder)SDP_SSAResponse(L2CAP,RFCOMM(4),OBEX)

2627282930

31LMP_power_decr_reqLMP_power_decr_req

32

Abbildung 2.11 – MSC-Frame 25-32

45

Nachdem die zu verwendenden Services logischen RFCOMM-Kanälen zugewiesen sind, erfolgt der masterseitige Verbindungswunsch nach einem L2CAP-Kanal zum RFCOMM (Kabelersatzprotokoll) erneut mittels eines L2CAP-Connection-Request, welches wieder mit dem zugehörigen Response und der Erfolgsmitteilung beantwortet wird. Hierauf folgt ebenfalls wieder die gegenseitige Initialisierung dieses logischen Kanals durch L2CAP-Configure-Requests & -Responses.

L2CAP Init f. RFCOMMParameter wie SDP (siehe oben)35

LMP_power_decr_req

L2CAP_cofigure_req()L2CAP_configure_res(success)

L2CAP_cofigure_req()L2CAP_configure_res(success)

36

37

3839

L2CAP_connection_req(RFCOMM)L2CAP_connection_res(connection_successful)

3334

RFCOMM Verbdg.-wunsch

Abbildung 2.12 – MSC-Frame 33-39 Der Start des RFCOMM-Multiplexers erfolgt durch Senden eines RFCOMM-Set-Asynchronous-Balanced-Mode-Frames auf dem Kontrollkanal (CH 0), welches von einem RFCOMM-Unnumbered-Acknoledgement für diesen Kanal bestätigt wird. Es folgen weitere Bluetooth-spezifische RFCOMM-Parameter-Einstellungen mittels RFCOMM-Unnumbered-Information-with-Header-Check-Commands. Zu diesen gehören das ausschließliche Nutzen von UI mit Header Check, da die Fehlerkorrektur des ETSI TS 07.10-Protokolls im Bluetooth-RFCOMM nicht verwendet wird, Antwortzeiten für Kontroll- wie Datenkanal, die Unterstützung kreditrahmenbasierter Flusskontrolle (CFC Credit based Flow Control) und Maximale Frame-Größe.

RFCOMM_SABM (CH 0)RFCOMM_UA (CH 0)

RFCOMM_UIH(CMD(Param.Negot.))RFCOMM_UIH(CMD(Param.Negot.))

4041

4243

SABM .. SetAsyncBalanceMode

UA .. UnnumberedACK

UIH .. UnnumberedInfo +HeaderCheck

Abbildung 2.13 – MSC-Frame 40-43 Es folgt nun der Aufbau des RFCOMM-Datenkanals (CH 2) in der selben Art und Weise wie schon der Kontrollkanal erstellt wurde. In den folgenden Frames werden die Modem Status Commands und respektive Responses dazu genutzt die Kontrollsignale sowie das Break-Signal der emulierten RS-232 Schnittstelle durchzureichen. Gefolgt wird dies von einer gegenseitigen Zusendung der ersten Kreditrahmen für CFC und weiteren Modem Status Commands.

46

RS232-Signalemulation

RFCOMM_UIH(CMD(ModemStatus))RFCOMM_UIH(CMD(ModemStatus))

RFCOMM_UIH(RESP(ModemStatus))RFCOMM_UIH(RESP(ModemStatus))

52535455

LMP_power_decr_req56

RFCOMM_SABM (CH 2)RFCOMM_UA (CH 2)

RFCOMM_UIH(CMD(ModemStatus))RFCOMM_UIH(CMD(ModemStatus))

RFCOMM_UIH(RESP(ModemStatus))RFCOMM_UIH(RESP(ModemStatus))

RFCOMM_UIH(Credits(30))RFCOMM_UIH(Credits(30))

4445

46474849

5051

Abbildung 2.14 – MSC-Frame 44-56 Erst nach Abschluss dieser vorbereitenden Protokollverbindungen kann der Master seinen OBEX-Verbindungswunch zum Datentransfer (FTP File Tranfer Protokol) an den Slave mittels OBEX-Connect(FTP) senden. Dies wird durch eine Erfolgsmeldung und Bestätigung des gewählten Protokolls FTP beantwortet. Darauf folgend erfragt der Master den Inhalt des Zielordners auf dem Slave-Host durch OBEX-Get(FolderListing) was ihn aus Sicht des FTP zum anfragenden Client macht. Somit ist der Slave hier FTP-Server welcher den erfragten Inhalt, im Beispiel leerer Ordner, als Erfolgsmeldung OBEX-Success(FTP-Server(Folder Listing) zurücksendet. Nun folgen die eigentlichen Daten. also der Inhalt der 1kB-Datei sowie ihre Attribute und Parameter in den nächsten Multislot-Paketen, was wiederum durch OBEX-Success(FTP) bestätigt wird und nun auf dem Slave-Host als Datei im eingestellten Standard-Datenaustausch-Ordner zu finden ist. Es folgt eine erneute Abfrage des Ordnerinhalts seitens des Masters und die gewohnte Bestätigung das Slave, welche jetzt einen nichtleeren Ordnerinhalt auflistet. Die Datei ist erfolgreich kopiert worden.

OBEX_Conn(FTP)OBEX_Sucess(FTP)

OBEX_Get(FolderListing)OBEX_Sucess(FTP_Server(FolderListing))

57585960

OBEX_Put(FTP_Client(Data))61/6263/64

OBEX_Put(FTP_Client(Data))

OBEX Verbindung m. FTP

OBEX_Sucess(FTP)65

OBEX_Get(FolderListing)OBEX_Sucess(FTP_Server(FolderListing))

6667

Abbildung 2.15 – MSC-Frame 57-67 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.

47

L2CAP_disconnection_req()L2CAP_disconnection_res(success)

6869

L2CAP Verbindungsabbau 1

Abbildung 2.16 – MSC-Frame 68/69 Nun wird das OBEX-Protokoll ebenfalls durch OBEX-Disconnect und bestätigende OBEX-Success-Meldung getrennt.

OBEX_DisconnectOBEX_Sucess

7071

OBEX Verbindungsabbau

Abbildung 2.17 – MSC-Frame 70/71 Auf der RFCOMM-Ebene muss nur der Datenkanal abgebaut werden, was durch RFCOMM-Disconnect(CH 2) und die entsprechende Bestätigung mittels Unnumbered Acknowledgement realisiert wird.

RFCOMM Verbindungsabbau72RFCOMM_Disconnect (CH 2)

RFCOMM_UA (CH 2)73

Abbildung 2.18 – MSC-Frame 72/73 Beim Aufruf zum Abbau des verbliebenen L2CAP-Kanals für RFCOMM ist im Nutzdatenbereich des gesendeten Pakets ein Fehler aufgetreten, wobei allerdings die beinhalteten Informationen nachweislich wiederhergestellt werden konnten. Der L2CAP-Disconnection-Request wurde erneut durch das entsprechende Response vom Slave bestätigt.

L2CAP_disconnection_req() Payload ErrorL2CAP_disconnection_res(success)

7475

L2CAP Verbindungsabbau 2

Abbildung 2.19 – MSC-Frame 74/75 Erst jetzt wurde nach weiteren Anfragen nach Sendeleistungsverminderung seitens des Slaves das Minimum der Leistung erreicht was mit der ebenfalls unbestätigten LMP-Min-Power-Meldung dem Master angezeigt wird. Selber sendet der Slave aber weiterhin noch eine Anfrage seinerseits. Diese Verbindung wird nach Lösen aller Verbindungen der anderen Protokolle auch auf Link Manager-Ebene durch das endgültige LMP-Detach geschlossen.

LMP_decr_power_reqLMP_min_power

LMP_detach

LMP_decr_power_reqSendeleistungsmin. erreicht

LMP Verbindungsende

767778

79

Abbildung 2.20 – MSC-Frame 76-79

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

48

genaue Anzahl verlorener Pakete einer gestörten Übertragung zu bestimmen. Weiterhin sei angemerkt, dass FTS nicht vorrangig zur Visualisierung von überwachten Bluetooth-Verbindungen geeignet ist, sondern zum Testen verschiedenster Geräte oder Kommunikationsprotokolle im Entwurf, sowie zur Bluetooth-Zertifizierung von Neuentwicklungen dient. Dementsprechend umfangreich und somit komplex fällt dieses Programm und dessen Entwicklungsumgebung (freiprogrammierbar) aus. Zum Zwecke der schnellen visuellen Darstellung eignen sich Protocol Analyzer mit der Ausrichtung auf den Endanwender, wie Kontrolle und Monitoring, erheblich besser. Eines dieser Werkzeuge ist der BlueAnalyzer der Firma IVT mit seinen Unter-Varianten BlueTester und BlueUnitTesting. Diese stellen die aufgenommenen Daten in Echtzeit direkt in Message-Sequenz-Charts und ebenfalls detaillierte Informationen in weiteren Fenstern geordnet dar. Daraus lassen sich dann einfach detailreiche, an die eigenen Wünsche angepasste Reporte erstellen. Natürlich sind diese Funktionen im selben Maße wie FTS zum Testen von Protokollen geeignet. Somit sollte ein Vergleich der angebotenen Sniffer-Software hinsichtlich der Hauptverwendung und dem Erfüllen daraus resultierender Anforderungen genau geführt werden. Zur Erstellung eines solchen MSC wäre ein o.g. Monitoring-Programm mit automatischen Visualisierungsfunktionen hilfreich gewesen. Bei Anwendung von FTS for Bluetooth ist dies nur mittels aufwendiger Exportierung und Aufbereitung durch eine weitere Software (Visio und Grafikprogramm) manuell möglich.

2.3 Bluetooth in der Praxis Im folgenden Kapitel soll der Bluetooth-Standard und seine Verwendung in der Praxis näher beleuchtet werden. Hierbei soll im ersten Teil auf die Konfiguration, herstellerspezifische Unterschiede, Probleme bei alltäglichen Anwendungen und Optimierungsempfehlungen eingegangen werden. Darauf folgen die Ermittlung resultierender Reichweiten ausgewählter Sendeleistungsklassen und eine Veranschaulichung der Kanalnutzung einer Beispielverbindung. Folgende Geräte wurden unter Windows 2000/XP getestet: - ACER BT500 USB, Class 2 - ComOne Bluetooth PC-Card MC310, Class 1 - D-Link DBT 120 USB, Class 3 - Sony-Ericsson T-610 Mobiltelefon, Bluetooth Class 3 integriert - Toshiba BT-PC-Card PA3053, Class 1 - Toshiba Portegé3500 Laptop, Bluetooth Class 2 integriert Bluetooth-Anwender-Software: - jeweils im Lieferumfang enthaltene Original-Software - Widcomm Vers 1.4.3.4 (weit verbreitet) - BlueSoleil Vers 1.4.7 (weit verbreitet) - Toshiba Vers 3.00.12 (nur für Toshiba-Geräte)

2.3.1. Konfiguration und Betrieb Bei der Installation, der Einstellung und dem Einsatz der zur Verfügung gestandenen Bluetooth-Endgeräte wurde ein ansehnlicher Erfahrungsschatz zusammengetragen. Aus diesem seien nur einige generelle Resultate vorgestellt.

49

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).

50

Darüber hinaus erschwerten zumeist der Verlust manueller Einstellungen und wenig aussagekräftige Fehlermeldungen seitens der gestesteten Bluetooth-Software die Konfiguration und Verwendung dieser.

2.3.2. Reichweiten Zur Untersuchung der Auswirkungen der bekannten unterschiedlichen Sendeleistungsklassen und die jederzeitige Minimierung der Sendeleistung von Bluetooth-Endgeräten auf die mögliche Reichweite der Übertragung, wurden die bereits erwähnten Geräte-Paare ACER BT500 USB und Toshiba BT-PC-Card PA3053, welche Class 2 respektive Class 1 zuzuordnen sind, verwendet. Dies wurde im Rahmen eines Freifeldversuchs durchgeführt, um etwaigen Störungen und Interferenzen auszuweichen. Hierfür kamen ebenfalls die beiden bereits aufgeführten Laptops HP Omnibook zum Einsatz. Mit Hilfe des Software-Tools „iPerf“ (im folgenden Kaptitel näher vorgestellt), welches in Verkehrsmessungen IP-basierter Netzwerke Anwendung findet, wurde der maximale durchschnittliche Durchsatz in Abhängigkeit von der Entfernung zweier Bluetooth-Tranceiver ermittelt. Als Übertragungsprotokoll wurde UDP verwendet, da es die beste Möglichkeit für einen Rückschluss auf die maximal erreichbare Bandbreite einer Datenübertragung bietet. Als ausreichende Messdauer und somit die Mittlungszeit der Datenrate wurden 20 Sekunden ermittelt und entsprechend angewendet. Je nach verwendeter Literatur werden für die beiden eingesetzten Klassen 10 bis 20 Meter bzw. 100 Meter als erreichbare Distanz unter optimalen Bedingungen dargestellt. Auf Grundlage dieser Erwartungswerte wurden die Schrittweiten der Messung zum besseren Vergleich der Ergebnisse angepasst. So sollten die ersten zehn bis zwanzig Meter in beiden Messungen mit den unterschiedlichen Geräte-Paaren in Ein-Meter-Schritten erfolgen und darüber hinaus für die Klasse 1 aller 10 Meter bzw. ab 100 Meter aller 20 Meter ein Messwert bestimmt werden. Aufgrund der in den folgenden Diagrammen gezeigten Abweichungen von diesen genannten Erwartungen, wurden die Messwertanzahl und auch die Distanz der Einzelmessungen während des Experiments angepasst.

51

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

52

Demgegenüber sehr positiv überraschend war das hier dargestellte Ergebnis der Toshiba PC-Cards. Es wurde nicht nur spielend die angestrebte Distanz erreicht, sie wurde auch mit fast gleich bleibender Übertragungsqualität überschritten. Erstaunlicherweise erst weit nach Überschreiten der doppelten zu erwartenden Reichweite ist die Verbindung endgültig zusammengebrochen. Generell war festzustellen, dass sich eine Sichtverbindung der kommunizierenden Geräte günstig auf die resultierende Reichweite, welche schon durch die geringere Sendeleistungsklasse beider eingesetzten Transceiver begrenzt wird, auswirkt.

2.3.3. Kanalnutzung in FFH Um den Einfluss schmalbandiger Störquellen auf eine Bluetooth-Verbindung so gering wie möglich zu halten, muss sich das bis Version 1.1 alleinig angewandte Fast Frequency Hopping über das gesamte ISM-Band erstrecken. Dieser Aspekt der Frequenzwahl wurde untersucht und im folgenden Kapitel dargestellt. Zur Visualisierung dieser pseudozufälligen Sprungsequenz, wurde eine Beispielkommunikation zweier Geräte in ungestörter Umgebung mit Hilfe der vorgestellten Software FTS for Bluetooth aufgezeichnet. Aus der resultierenden Log-Datei wurden die Pakete mit den zugehörigen Kanalnummern, Paketindex und Zeitstempeln extrahiert. Es bestanden dadurch grundsätzlich zwei Möglichkeiten der Darstellung des Kanalnutzungsverlaufs. Das Auftragen der Kanalnutzung in Abhängigkeit vom Paketindex hätte allgemein für diese Untersuchung ausgereicht, doch wurde die Darstellung über der Zeitachse gewählt, um den zeitlichen Verlauf der Verbindung sichtbar zu machen. Die im Hex-Format vorliegende Zeitangabe wurde mittels eines zuvor bestimmten Korrekturfaktors in Millisekunden umgerechnet. (Das genaue Vorgehen wird im folgenden Kapitel näher beschrieben.)

Abbildung 2.23 – Kanalnutzung, Verlauf

53

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

54

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.

55

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.

56

Somit wurde im betrachteten Fall ein besonderer Messaufbau verwendet, welcher nur eine unidirektionale Überwachung der Master-Slave-Kommunikation zulässt. Durch die entsprechende Positionierung des Comprobe wurden für ihn die geforderten gleichen Empfangsvorrausetzungen wie für den Datei-Empfänger erzielt und es wurde nur die gestörte Empfangssituation für den Datei-Empfänger betrachtet. Die Daten über alle registrierten Pakete mussten dann exportiert und aufbereitet werden. Der Export wurde, ohne Umwege über weitere Dateien, mittels der Kopieren-in-die-Zwischenablage-Funktion von Microsoft Windows zu Microsoft Excel realisiert. Die Datensätze bestanden, auch auf Grund der Unterschiede zwischen deutscher und englischer Zahlennotation, zum größten Teil aus Text. Um die Information in Form von Zahlen zurück zu gewinnen, waren verschiedene Manipulationen und Umrechnungen, z.B. der Zeit von Hex- in dezimales Format, sowie die Korrektur der verwendeten Einheit zu Millisekunden, notwendig. Die gezeigten Darstellungen sind also keine direkten Extrakte von FTS, sondern bauen lediglich auf die mit dieser Software gesammelten Daten auf. In diesen Informationen von FTS ist auch, neben Paketindex und Zeitstempel, die Kanalzahl in Verbindung mit der resultierenden Frequenz enthalten. Es ist bei dieser Basisband-Überwachung wenig von Interesse welche Protokolle verwendet wurden. Um eine Aussage über den Zustand der Verbindung machen zu können, ist lediglich der so genannte Paketstatus – bei Empfang – auszuwerten. Die möglichen Angaben sind dabei OK, Payload Error und Length Error. Die beiden letztgenannten wurden zu „Status: error“ zusammengefasst. Nach diesen Merkmalen und der Senderichtung wurden die Datensätze sortiert und wie auch im folgenden Diagramm in Abhängigkeit von der betrachteten Übertragungsrichtung dargestellt.

3.2.1. Störeinfluss von WLAN Diese Messung des Störeinflusses von WLAN auf eine Bluetooth-Verbindung wurde mit folgenden Geräten realisiert. Für Bluetooth-Kommunikation, Abstand 2m: - Acer BT500 (Class 2) USB an Toshiba Portegé3500 - Acer BT500 (Class 2) USB an Fujitsu Siemens CELSIUS Mobile Für WLAN (IEEE802.11b)-Kommunikation, Abstand 5m: - 3com Airconnect PC-Card an HP OmniBook 4000series - Roamabout PC-Card an HP OmniBook 4000series FTS-Airsniff wurde auf dem Toshiba Portegé3500, an dem somit der Comprobe angeschlossen war, betrieben.

57

Abbildung 3.2 – Messaufbau WLAN-Einfluss Zur Messung wurde auf beiden gekreuzten Kommunikationssystemen gezielt IP-Traffic erzeugt und die gerichtete Bluetooth-Übertragung, wie einleitend beschrieben, am Daten-Empfänger überwacht. In folgendem Diagramm ist ein Verbindungsausschnitt mit 7923 der registrierten Pakete und deren Empfangsstatus, in Abhängigkeit von Frequenz-Kanal und Zeit, aufgetragen.

Abbildung 3.3 – zeitlicher Verlauf der WLAN-Störung

Die Interferenzen im 20MHZ-Band des benutzten WLAN-Kanals sind sehr gut zu erkennen. In diesem Bereich ist ebenfalls das Herausbilden von Lücken, also weniger Pakete, sichtbar.

58

Dies ist im Nichtregistrieren von gesendeten Paketen seitens der beiden Empfänger – überwachtes Bluetooth-Gerät und Comprobe – zu begründen. Zu diesem Paketverlust kommt es aufgrund nichtdetektierbarer verfälschter Signale oder Pakete, die vom Empfänger nicht als an ihn adressiert interpretiert werden. Das anschließende Histogramm soll die Mengen der korrekt oder fehlerhaft empfangenen und nicht registrierten Pakete näher verdeutlichen.

Abbildung 3.4 – Histogramm der WLAN-Störung

Im Interferenzbereich ist ein Verlust je Kanal bis zu 50 Prozent der zu erwartenden Paketmenge deutlich zu erkennen. Die restlichen, registrierten Pakete sind zudem größtenteils fehlerbehaftet. Die Fehler außerhalb des beschriebenen Bereichs sind auf Reflektionen im Raum zurückzuführen.

3.2.2. Störeinfluss einer Mikrowelle Die Mikrowelle ist ein weiterer praktischer Störer, welcher eine Bluetooth-Verbindung beeinträchtigen könnte, da ihr Frequenz-Spektrum ebenfalls im ISM-Band angesiedelt ist. Der Grad der möglichen Beeinflussung soll hier untersucht werden. Umfangreiche Vorversuche haben gezeigt, dass aufgrund der geforderten hochgradigen Schirmung der Mikrowelle, nur in unmittelbarer Nähe messbare Einflüsse auf eine Bluetooth-Kommunikation nachzuweisen waren. Dementsprechend wurde folgender Messaufbau gewählt: Für Bluetooth-Kommunikation, Abstand 4m:

- jeweils ein Acer BT500 (Class 2) USB an HP OmniBook 4000series Mikrowelle: Moulinex B85, 750 Watt, 2,450GHz

59

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

60

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

61

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

62

Die Entscheidung fiel, aufgrund der genannten Beschränkungen, gegen die beiden erstgenannten Programme. Neben dem Aspekt, dass iPerf ein Freeware-Tool ist, spricht die flexible Anwendung als Terminal-Programm sehr für diese Wahl. Zur Messung stand die Version 1.7.0 zur Verfügung. Die Funktionsweise ist erwartungsgemäß einfach. iPerf arbeitet nach dem bekannten Client-Server-Modell. Ein Client erzeugt Traffic in Richtung des Servers, welcher lediglich Empfangsinformationen zurücksendet. Zuvor muss iPerf auf dem Empfangs-Rechner als Serverdienst gestartet werden. Das gesamte Funktionsangebot wird über Kommandozeilen erreicht. Hierbei ist unter anderem die einfache Parametereinstellung, das mögliche Zusammenfassen in Batchdateien, freie Namensgebung für die Aufzeichnungsdateien und optionale direkte Überwachung im Terminalfenster von großem Vorteil. Die hauptsächlich benutzten Einstellungs-Parameter waren:

- gewünschtes Transportprotokoll (TCP/UDP) - Zuweisung der Server-/Client-Rolle - Überwachungsintervall im Log (Bildschirm wie Datei) - Ziel- und bei Bedarf (mehrere Netz-Adapter) Quell-IP - Bandbreite und Dauer des erzeugten Verkehrs

Abbildung 3.8 – Parameter des iPerf-Aufrufs

3.3.3. Vorbereitung des Experiments

63

Folgende Geräte standen unter Windows 2000/XP zur Verfügung: - ACER BT500 USB (Class 2), Bluetooth (v1.1) (2 Stück) - ComOne Bluetooth PC-Card (Class 1), Bluetooth (v1.1) - D-Link DBT120 USB (Class 3), Bluetooth (v1.1) - Toshiba BT-PC-Card PA3053 (Class 1), Bluetooth (v1.1) (2 Stück) - Toshiba Portegé3500 Laptop (Class 2), Bluetooth (v1.1)/WLAN (IEEE802.11b) integr. - 3com Airconnect WLAN PC-Card (IEEE802.11b) - HP OmniBook 4000series (2 Stück)

Bluetooth-Anwender-Software:

- Widcomm Vers 1.4.3.4 (weit verbreitet) - Toshiba Vers 3.00.12 (nur für Toshiba-Geräte) - ComOne Treiber und Zugangssoftware

Ausgehend vom zitierten Beispiel zur parallelen Kommunikation von WLAN und Bluetooth, wurde der als praxisnah angestrebte Aufbau mit drei Laptops festgelegt. Dabei musste der leistungsstärkste (CPU- und Batteriekapazität) der drei zur Verfügung gestandenen Laptops, somit der Toshiba, beide Übertragungen über WLAN und Bluetooth durchführen. Dementsprechend war die Rollenverteilung der Laptops festgelegt, wobei der interne WLAN-Adapter des Toshiba-Laptops problemlos zur Kommunikation mit der 3com-PC-Card eingesetzt werden konnte. Aus den verbliebenen Bluetooth-Geräten mussten die verlässlichsten ausgewählt werden. Von der weiteren Verwendung der Adapter von ComOne und D-Link wurde aufgrund von Kompatibilitätsproblemen und, bereits durch FTS-Messung festgestellten, hohen Fehlerraten, auch bei ungestörter Umgebung, abgesehen. Des Weiteren wurden die Bluetooth-Adapter-Sets aufgrund der durch den selbigen Hersteller und die gleiche Treiberversionen garantierten Interoperabilität favorisiert. Aufbauend auf vorangegangene Tests war die schlechte Performance, hinsichtlich Reichweite und Durchsatz, der ACER BT500 USB bereits bekannt. Somit wurde das Toshiba PA3053 PC-Card-Set für den Versuch verwendet. Nachdem die Festlegung der Aktoren erfolgt war, mussten Überlegungen zu einer aussagekräftigen Konstellation gemacht werden. Für einen praxisnahen Anwendungsfall sollte der Abstand der Bluetooth-Geräte vorwiegend geringer als der der WLAN-Geräte sein. Da hier aber Bluetooth-Class-1-Geräte verwendet wurden, sollte auch die Kommunikation über eine größere Distanz gewählt werden, um überhaupt eine gewisse Signalabschwächung zu erreichen. Es müssen die Senderichtungen in Bezug auf die sich störenden Verbindungen betrachtet werden, da beispielsweise ein sendendes Gerät den gleichzeitigen Empfang mittels der anderen interferierenden Übertragungstechnik stören kann. Demzufolge mussten signifikante Positionen der Geräte für den Freifeldversuch gefunden werden. Die Wahl des Übertragungsprotokolls fiel mit Blick auf den Praxisbezug, entgegen der üblichen Verwendung von UDP in Netzwerkdurchsatzmessungen, schnell auf TCP. Die Messdauer sollte für eine gute Messwertmittlung entsprechend lang sein, da verschieden starke Schwankungen in den umfangreichen Testmessungen zu registrieren waren.

3.3.4. Messaufbau Die aufgeführten Vorüberlegungen bestimmten die folgenden, für das Experiment unter Windows 2000/XP verwendeten Geräte. Für die Bluetooth-Kommunikation:

- HP OmniBook 4000series mit Toshiba PA3053 PC-Card (Bluetooth v1.1, Class 1)

64

- 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

65

In jeder dieser Senderichtungskombinationen müssen jeweils die 6 möglichen Distanz-Kombinationen realisiert werden. Zusätzlich wurde der Messaufbau in der Positionierung der beiden HP-Laptops zueinander verändert. Befanden sich diese beiden Laptops aus Sicht des Toshiba-Laptops in der gleichen Himmelsrichtung, entsprach dies dem eingeführten Winkel α=0 Grad zwischen ihnen. Der umgekehrte Fall mit α=180 Grad entsprach der Anordnung in entgegen gesetzten Himmelsrichtungen. Bei α=0 Grad waren die größten und entsprechend bei α=180 Grad die geringsten Interferenzen zu erwarten. Die aus diesen Vereinbarungen resultierenden Einzelmessungen charakterisieren sich also durch:

- die jeweilige Entfernungsstufe der beiden Übertragungstechnologien, - die Kombination der Senderichtungen und - die Ausrichtung der beiden HP-Laptops zueinander (Winkel α).

Dies entspricht einer Summe von 48 Einzelmessungen. Da weiterhin zum Vergleich jeweils die ungestörten, maximal erreichbaren Durchsatzraten in den 5 jeweiligen Stufen der Reichweiten ermittelt werden müssen, erhöht sich die Gesamtzahl der verschiedenen Einzelmessergebnisse auf 53, die mindestens durchgeführt werden müssen. Entsprechend der vorausgegangenen Tests, fielen die Erwartungen an die erreichbaren Durchsätze unterschiedlich aus. Es hatte sich hierbei schon gezeigt, dass Bluetooth weniger stark von einer parallelen WLAN-Verbindung beeindruckt wird.

3.3.5. Durchführung Zum eigentlichen Experiment wurde sich, entsprechend der o. g. Charakterisierung, auf eine tabellarische Übersicht der Einzelmessungen geeinigt. Diese war ebenfalls Grundlage für eine einheitliche Namensgebung für die Aufzeichnungsdateien. Für die Durchsatzmessung sollte IP-Traffic generiert werden, welcher in Falle von Bluetooth über eine Netzwerkverbindung des Kommunikationspaares (Dienst: Netzwerkzugang) verwirklicht wurde. Dementsprechend lag die weitere Vorbereitung in der Erstellung von Batchdateien. Diese wurden für jedes einzelne Messszenario und jeden der drei Laptops spezifisch vorgefertigt, um am Messort effektiv und mit weniger Fehlerquellen arbeiten zu können. Sie enthielten die iPerf-Kommandozeile mit den charakteristischen Parametern wie Rollenzuweisung (Client/Server), Ziel- sowie bei Bedarf Quelladresse, Transportprotokoll, Wert zu erzeugender Bandbreite, Messintervall von 0,5 Sekunden, den Namen der Log-Datei und Dauer der Messung. Letztere wurde auf 60 Sekunden festgelegt, da dies der Forderung nach repräsentativen Mittelwerten genügt. Beispiel-Kommandozeile Bluetooth-Client:

iperf -c 192.168.81.2 -B 192.168.81.1 -i 0.5 -t 60 > TCP_Bi1_Wi20_bt.txt

Im oben abgebildeten Beispiel ist der iPerf-Aufruf mit der Client-Option und dazugehöriger Zieladresse des Servers (-c 192.168.81.2), Bindung auf einen Ausgangs-Netzwerkadapter (-B 192.168.81.1), Intervall der Darstellung der Messwerte (-i 0.5), Dauer der Verkehrserzeugung und –messung (-t 60) und der Export in eine benannte Aufzeichnungsdatei (>TCP_Bi1_Wi20_bt.txt) zu sehen.

66

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.

67

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.

68

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

69

Der WLAN-Verkehr hat bei dieser direkten Konkurrenz der Signale kaum eine Chance zu bestehen. Im Falle ankommenden Funks beider Standards sind die direkte Abschwächung bei größeren Entfernungen und der geringere Einfluss der Winkelausrichtung klar ersichtlich. Die dennoch besseren Bluetooth-Ergebnisse für α = 0 Grad sind mit öfter aussetzenden WLAN-Funk zu begründen. Bo/Wo:

oder

Abbildung 3.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

70

Diese vierte und letzte betrachtete Konstellation stellt, wie schon in den Gesamtergebnistabellen zu erkennen, den ungünstigsten Fall für die Bluetooth-Übertragung dar. Hier wirkt sich ebenfalls die vor dem jeweiligen Test verringerte Bluetooth-Sendeleistung negativ aus. Das vom gleichzeitigen Bluetooth-Empfänger gesendete WLAN-Signal kann daher bei geringen Abständen der Bluetooth- und WLAN-Geräte das ankommende Signal des Bluetooth-Senders erheblich mehr stören. Hierfür wirkt sich die gleichrichtige Aufstellung der äußeren Laptops in allen Entfernungskombinationen ebenfalls WLAN-günstig aus.

3.3.7. Fazit In erster Linie ist zusammenfassend die erschreckend starke Durchsatzeinbuße von WLAN in allen Tests zu erkennen. Gerade in den Fällen ankommenden WLAN-Verkehrs (Wi) am Bezugs-Laptop ist mit dem nahezu totalen Verlust der hierüber gesendeten Daten zu rechnen. Ebenso leicht ist die erwartungsgemäße Abhängigkeit der Störanfälligkeit der WLAN-Transceiver von ihrer Entfernung zueinander in allen Senderichtungs-Konstellationen ersichtlich. Auch die verwendeten Winkelanordnungen erfüllten mit den erreichten Werten die gesetzten Erwartungen, dass gleiche Ausrichtung zum gemeinsamen Kommunikationspartner, also schlimmste gegenseitige Störung, die „Überlegenheit“ der Bluetooth-Übertragung hervorhebt. Die geringeren Bluetooth-Durchsatzraten bei gleichen Konstellationen und entgegen gesetzter Ausrichtung sind daher durch geringer gestörten WLAN-Verkehr zu begründen. Die Dominanz von Bluetooth verdeutlicht sich auch in dem Aspekt, dass diese Technologie, entgegen WLAN, in nahezu allen Einzelmessungen mindestens halben und sogar in mehr als der Hälfte aller Tests wenigstens drei viertel des möglichen Durchsatzes erreicht hat. Dieses teilweise überraschend extreme Ergebnis unterstreicht die Forderung nach einer für anderen ISM-Funk verträglicheren Bluetooth-Funktechnologie. Folgend soll dieser Zusammenhang noch einmal kurz in einer Gegenüberstellung von Parallelbetrieb gestörtem und ungestörtem Datenverkehr zusammengefasst werden.

3.4 Cross Measurements

3.4.1. Einführung Als kleine eigenständige Verdeutlichung des im obigen, sehr komplexen Versuch dargestellten Zusammenhangs von Durchsatz der beiden ISM-Übertragungstechniken Bluetooth und WLAN und ihrer gegenseitigen Beeinflussung soll in diesem Abschnitt der direkte Vergleich von ungestörtem und parallelen Betrieb dieser kurz gezeigt werden. Es wurden die Konsequenzen für den aktuellen Durchsatz beider Technologien in zwei aus dem Ergebnis des Hauptexperiments ausgewählten Konstellationen untersucht. Hierfür wurden die verwendete Hardware und die weiteren Messparameter beibehalten. Die Entfernungsstufen 1 Meter für Bluetooth und 20 Meter für WLAN, sowie TCP als Transportprotokoll wurden aufgrund des schon erwähnten geforderten Praxisbezugs festgelegt. Es fand die Analyse in zwei unterschiedlichen Senderichtungskonstellationen, wobei je eine die ungünstigste für einen der beiden Funktechnologien darstellt.

71

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-Sekunden-Intervallen überwacht. Hierbei wurde jeweils die am meisten durch eine Parallelübertragung gehinderte Funktechnologie 30 Sekunden vor der anderen, als begünstigt erwarteten, gestartet. Wie in den folgenden Darstellungen gut zu erkennen ist, erfüllte sich hierbei ebenfalls die Aussicht auf den mit Bluetooth verglichen stärkeren Zusammenbruch des WLAN-Durchsatzes.

Abbildung 3.23 – Darstellung Fall 1

72

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 Bluetooth-Transceiver gestörte/belegte Frequenzen. Dies geschieht mittels der Einführung einer Pico-Netz-spezifischen Kanalliste, welche vom Master verwaltet wird und gegebenenfalls durch Anfordung lokaler Statusreporte aller AFH-fähigen aktiven Slaves die von der Sprungsequenz auszuschließenden sowie alle als ungestört erkannten Kanäle mit der entsprechenden Kennzeichnung speichert. Die Konsequenz der Anwendung dieser Kanalliste ist das Ausweichen auf die offensichtlich ungestörten Frequenzen und die Meidung dieser für die Sprungsequenz, welche in Form von gleichem Kanal für Hin- und Rückslot eines Master-Slave-Master-Paketaustauschs – Same-Channel-Method – abgeändert wird. Dieses erweiterte Sprungverfahren ist in der im November 2003 von der Bluetooth-SIG verabschiedeten Version 1.2 enthalten. Zum Zeitpunkt dieser Arbeit waren erstaunlicherweise noch keine entsprechenden Geräte oder Firmwareupdates für weitere Tests verfügbar. Im folgenden, letzten Kapitel wird detailliert auf die Funktionsweise dieses interferenzvermeidenden Verfahrens eingegangen.

73

Kapitel 4 - Die Funktionsweise von AFH

4.1 Einleitung In diesem Kapitel soll die allgemeine Funktionsweise dieses neuen, adaptiven Frequenzsprung-Verfahrens erläutert und am Beispiel der verbesserten Koexistenz von Bluetooth und WLAN verdeutlicht werden.

4.2 Motivation Bluetooth-Geräte der Vorgängerversionen, welche das konventionelle Frequenzsprung-Verfahren (FFH) anwenden, nutzen immer alle 79 festgelegten Kanäle des 2,4GHz-ISM-Bandes (Ausnahme Frankreich, Japan usw.). Dabei wird der Kanal 1600 Mal pro Sekunde in einer zufälligen Sprung-Reihenfolge gewechselt. Sobald ein anderer Funkverkehr, wie WLAN, in der Umgebung vorhanden ist, führt diese Art des Frequenzsprunges unweigerlich zu unregelmäßigen Kollisionen. Ohne AFH war bisher keine Möglichkeit gegeben, sich der Umgebung anzupassen und somit diese Konflikte zu verhindern. Die folgende Illustration offenbart die resultierenden Interferenzen. Hierbei sei kurz angemerkt, dass WLAN (IEEE 802.11b) eine Bandbreite von 20MHz vereinnahmt und kein Frequenzsprung-Verfahren anwendet.

Abbildung 4.1 – Überlagerung BT und WLAN

74

Im Gegensatz zur obigen, findet in der folgenden Illustration eine Bluetooth-Kommunikation der neuen Generation statt. Das in Bluetooth v1.2 verwendete Adaptive Frequency Hopping ermöglicht nun eine Anpassung an die Umgebung. Hierbei werden die Kanäle, welche durch andere Interferenz-Quellen belegt sind, im Frequenzsprung-Verfahren ausgeschlossen. Dieser Prozess des „Re-Mappings“ beinhaltet somit auch eine Reduzierung der Anzahl der vom Kabelkiller nutzbaren Kanäle. Dabei ist die Mindestzahl dieser Kanäle durch die Spezifikation auf 20 beschränkt. Während der Verwendung von AFH ist die Same-Channel-Method, worin ein Slave-to-Master-Slot im selben Frequenzkanal wie der vorangegangene Master-to-Slave-Slot liegt, vorgeschrieben. Es wird am Ende dieses Kapitels näher darauf eingegangen.

Abbildung 4.2 – Ausweichen vor WLAN durch AFH

4.3 Klassifikation der Frequenzkanäle

4.3.1. Channel-Classification Jedes AFH-fähige Bluetooth-Gerät kann individuell eine so genannte Channel-Classification durchführen. Es findet hierbei eine Klassifikation statt, welche jeden einzelnen Kanal als „unknown“, „good“ oder als „bad“ einstuft. Diese Entscheidung wird anhand der lokalen Information möglicher Interferenzen getroffen, welche auf folgende Weise erworben werden kann:

Kanal-Einschätzung (Channel-Assessment): Alle 79 spezifizierten Kanäle (Kanal = 1MHz) werden auf mögliche Interferenz-Quellen abgesucht. Zwei häufig genutzte Detektionsmethoden sind:

- RSSI (Received Signal Strength Indication), aktiv

75

- PER (Packet Error rate), passiv Ausschluss belegter Kanäle durch Host-Controller: Beispielsweise bei einem Laptop mit WLAN und Bluetooth parallel in Betrieb, kann der Host-Controller dieses Gerätes via HCI-Befehl das Auslassen der von WLAN belegten Frequenzen anordnen. (Host-Controller weiß, ob WLAN in Nutzung ist und welche Frequenzen es belegt)

AFH-Host-Channel-Classification

Die bereits erwähnte Klassifikation jedes einzelnen Kanals erfolgt nach bestimmten Kriterien: Unknown: Die Messungen der Kanal-Einschätzung (Channel-Assessment) sind nicht ausreichend, um eine verlässliche Einstufung des Kanals zu gewährleisten. Bad: Das Channel-Assessment detektiert Interferenzquellen oder es erfolgte ein Ausschluss des Kanals durch Host-Controller des Geräts. Good: Der Kanal ist weder als „unknown“ noch als „bad“ eingestuft.

4.3.2. Channel-Map Der Master eines Piko-Netzes, in dem das adaptive Frequenzsprung-Verfahren eingesetzt wird, muss eine AFH-Channel-Map erstellen, welche eine Aufstellung von Kanälen enthält, die bei der adaptierten Sprungsequenz genutzt werden dürfen oder ausgelassen werden müssen. Diese Liste kann er anhand der Kombination folgender Informationsquellen erstellen:

• Lokal, mittels seiner eigenen Channel Classification (Channel-Assessment oder HC) • Von ausgewählten aktiven Slaves, die im verwalteten Netz AFH nutzen, via LMP-

Kommandos angeforderter Channel-Classification-Reports (CCR) Die Anforderung der CCR eines bestimmten AFH-Slaves erfolgt durch die vom Master gesendete LMP_channel_classification_req-PDU, welche folgende drei Parameter beinhaltet:

• AFH_Reporting_Mode Aktivierung fortlaufender CCR oder Deaktivierung CCR • AFH_Min_Interval Wert für die Mindestzeit zwischen zwei CCR • AFH_Max_Interval Wert für die Maximalzeit zwischen zwei CCR

4.3.2.1. Channel-Classification-Report Ein Channel-Classification-Report des Slaves erfolgt in einer LMP_channel_classification-PDU, in der die erworbene Information in folgender Weise dem Master übermittelt wird. Die 79 spezifizierten Frequenzkanäle sind von 0 bis 78 durchnummeriert. Im Rahmen der Channel-Classification wird jedem Kanal n ein binärer Wert zugeordnet, welcher die Kanaleinstufung definiert: „unknown“ 00 „bad“ 11 „good“ 01 (10 ist reserviert) Die besagte PDU verfügt nur über 40 2-Bit-Felder, welche mit 0 bis 39 indexiert sind. Ein Feld mit dem Index n definiert die Klassifikation der Kanäle 2n und 2n+1. Eine Ausnahme

76

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“ (01) und „good“ (01) „good“ (01) „good“ (01) und „unknown“ (00) „good“ (01) „bad“ (11) und „bad“ (11) „bad“ (11) „bad“ (11) und „unknown“ (00) „bad“ (11) „unknown“ (00) und „unknown“ (00) „unknown“ (00) „good“ (01) und „bad“ (11) Implementierungsache

Ein Slave, welcher sich in einem aktivierten AFH-Reporting-Mode befindet, übermittelt fortlaufend dem Master, in seinem vorgegebenen Zeitintervall, seine Channel-Classification (PDU). Dies tut er solange, bis der Master das CC-Reporting deaktiviert.

Abbildung 4.3 – LMP Channel Classification Befehle

Wann und ob ein Master überhaupt die regionalen Kanaleinstufungen von Slaves, bei seiner Erstellung der AFH-Channel-Map, in Anspruch nimmt, ist von der Spezifikation nicht vorgeschrieben und somit ist die Implementierung dem Hersteller überlassen. Darüber hinaus sind auch keine Festlegungen für den Algorithmus der AFH-Channel-Map-Generierung getroffen, doch darf die Mindestzahl von 20 erlaubten Kanälen nicht unterschritten werden.

4.4 Channel-Map-Übermittlung und Aktivierung von AFH Die fertig generierte AFH-Channel-Map (ChM) besteht aus 79 1-Bit-Feldern wobei jedes Feld den Wert „0“ für entsprechender Kanal ist erlaubt (used) oder „1“ für verboten (unused) enthält. Diese wird anschließend vom Master über den LMP-Befehl „LMP_set_AFH“-PDU einzeln an alle AFH-tauglichen Slaves seines Piko-Netzes gesendet. Diese Slave-spezifische PDU enthält folgende Kommandos:

• AFH_Instant: Wert für den Zeitpunkt der Übernahme der neuen ChM (welche zeitgleich im gesamten Piko-Netz erfolgen muss)

77

• AFH_Mode: AFH-Aktivierung oder -Deaktivierung für diesen Slave (Verbindungsaufbau mit v1.1-Frequnzauswahl und anschließende Aktivierung von AFH möglich);

• AFH_Channel_Map: enthält aktuelle ChM; Nachdem alle AFH-aktivierten Transceiver nun über die aktualisierte Kanalliste verfügen, muss jeder einzelne seine Sprungreihenfolge zum vorgegebenen Zeitpunkt so abändern, dass die verbotenen Kanäle ausgelassen werden (Hop Sequence Modification). Diese Modifikation erfolgt nach einem bestimmten Algorithmus, wodurch sichergestellt wird, dass alle Teilnehmer in Zeit und Frequenz synchronisiert bleiben.

4.4.1. Frequenzauswahl Der so genannte Adapted-Hop-Selection-Kernel, welcher die Frequenz (Kanal) für den nächsten Zeitschlitz bestimmt, basiert auf dem bewährten Kernel von Bluetooth 1.1 (unverändert übernommen), welcher durch eine Re-Mapping-Funktion ergänzt wurde. Alle Inputs des adaptiven Sprung-Auswahl-Kernels, mit Ausnahme der hinzugefügten Kanalliste, sind identisch mit dem nicht-adaptiven der Version 1.1. Die folgende Abbildung zeigt den Ablaufplan, wie dieser neue Kernel, unter Berücksichtigung der AFH-Channel-Map, die Auswahl des nächsten zu nutzenden Kanals trifft.

Quelle: Bluetooth 1.2 Core Specification Abbildung 4.4 – Frequenzwahl bei AFH

Der Ablauf der Bestimmung eines Frequenz-Kanals ist wie folgt:

Der grundlegende Hop-Selection-Kernel 1.1 wählt pseudo-zufällig (aus Geräte-Adresse des Masters abgeleitet) einen Kanal fk. Dieser wird anschließend einer Abfrage unterzogen, ob er zu dem gegebenen Satz von nutzbaren Kanälen in der AFH-Channel-Map zählt. Das Ergebnis entscheidet ob die Re-Mapping-Funktion angewendet werden muss:

fk ist ein zulässiger Kanal fk wird für den nächsten Zeitschlitz genutzt

78

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 Host-Controller in die Kanalklassifikation übernommen. Für diesen Zweck existiert der HCI-Befehl HCI_Read_Country_Code. Dieser definiert in welchem Bereich des Frequenzbandes im jeweiligen Land Bluetooth operieren darf. Die bisherige Forderung nach einer 23-Kanal-Sprungsequenz in Ländern wie z.B. Frankreich und Japan konnte somit verworfen werden, wobei Japan zwischenzeitlich (in der Bluetooth-Spezifikation) nicht mehr als Land mit Frequenzbeschränkungen genannt wird.

4.5 Same Channel Method Während des Einsatzes von AFH wird von der Bluetooth-Spezifikation 1.2 eine Gerätekommunikation nach der Same-Channel-Method zwingend vorgeschrieben. Hierbei findet die Übertragung eines Master-zu-Slave-Paketes und dessen unmittelbar folgenden Slave-zu-Master-Paketes auf demselben Kanal (gleiche Frequenz), und nicht wie gewohnt auf verschiedenen Kanälen, statt. Folgende Illustration soll diesen Sachverhalt näher verdeutlichen.

79

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.

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.7 – MSC-FRAME 7-14 ABBILDUNG 2.8 – MSC-FRAME 15-17 ABBILDUNG 2.9 – MSC-FRAME 18-23 ABBILDUNG 2.10 – MSC-FRAME 24 ABBILDUNG 2.11 – MSC-FRAME 25-32 ABBILDUNG 2.12 – MSC-FRAME 33-39 ABBILDUNG 2.13 – MSC-FRAME 40-43 ABBILDUNG 2.14 – MSC-FRAME 44-56 ABBILDUNG 2.15 – MSC-FRAME 57-67 ABBILDUNG 2.16 – MSC-FRAME 68/69 ABBILDUNG 2.17 – MSC-FRAME 70/71 ABBILDUNG 2.18 – MSC-FRAME 72/73 ABBILDUNG 2.19 – MSC-FRAME 74/75 ABBILDUNG 2.20 – MSC-FRAME 76-79 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 www.bluetooth.org/spec/

[3] Specification of the Bluetooth System - Core Specification v1.2 vol 0-3, 11-2003 www.bluetooth.org/spec/

[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