Prof. Dr. W. Kowalk Rechnernetze II Seite 2
BluetoothBluetooth
Von Ericsson initiiertSIG (Special Interest Group) große Hersteller
IBM, Microsoft Siemens AG
Anwender Volkswagen DaimlerChrysler
Prof. Dr. W. Kowalk Rechnernetze II Seite 3
BluetoothBluetooth
In verschiedenen Standards festgelegtURLhttp://www.bluetooth.com/dev/specifications.asphttps://www.bluetooth.org/foundry/adopters/document/Bluetooth_Core_Specification_v1.2
Kernstandard mit über 1000 Seiten Reihe weiterer Standards, u.a.
Network Encapsulation ProtocolIP, IPv6, IPX usw. über Bluetooth
Prof. Dr. W. Kowalk Rechnernetze II Seite 4
BluetoothBluetooth
Core StandardTeil A: FunkspezifikationTeil B: Basisbandspezifikation
Link-ControllerBasisbandprotokolleandere elementare Link-Routinen
Teil C: Linkmanager-Protokoll (LMP)VerbindungsaufbauVerbindungskontroll
Prof. Dr. W. Kowalk Rechnernetze II Seite 5
BluetoothBluetooth
Core StandardTeil D (L2CAP): LOGICAL LINK CONTROL AND ADAPTATION PROTOCOL SPECIFICATION
Multiplexen von höheren ProtokollenPaketsegmentierung und ReassemblierungÜbermittlung der Dienstequalität-InformationZustandsmaschinePaketformate und -aufbauTestschnittstelle
Bluetooth Test- und Zertifizierungsprogramm
Prof. Dr. W. Kowalk Rechnernetze II Seite 6
BluetoothBluetooth
Core StandardTeil E: Service Discovery Protocol (SDP)
Lokalisierung von Diensten von/über Bluetooth-Geräte
Teil F: Schnittstellen zuseriellen BausteinenIrDATelefon WAP-Diensten
Prof. Dr. W. Kowalk Rechnernetze II Seite 7
BluetoothBluetooth
Core StandardTeil H: technische Schnittstellen wie
HCI, USB, UART oder RS232
Teil I: Testumgebungen Übereinstimmungsprüfungen mit Standard (Compliance)
Prof. Dr. W. Kowalk Rechnernetze II Seite 9
BluetoothBluetooth
Radio Specification2,4 GHh ISM-Band (Industrial, Scientific, Medicine)
2.400 MHz bis 2.485,5 Mhzunteres Grenzband von 2 Mhzoberes Grenzband von 3,5 MHz
78 Nutzbänder von 1 MhzFrequenz-Hopping
in einigen Ländernkleinere BandbereichJapan, Frankreich, Spanien
verschiedene SendeleistungsklassenSendeleistung in Klasse 1: 100 mW,anpassbarSendeleistung in Klassen 2 und 3: ca. 1 mW
Prof. Dr. W. Kowalk Rechnernetze II Seite 10
BluetoothBluetooth
BasisbandspezifikationFunkverbindung mit kurzen Reichweiten
Kabel ersetzen zwischen portablen elektronischen Gerätenfest installierten elektronischen Geräten
hohe Zuverlässigkeit hohe geringe Komplexität, hohe Leistung hohe Kosten
Prof. Dr. W. Kowalk Rechnernetze II Seite 11
BluetoothBluetooth
BasisbandspezifikationISM-Band bei 2,4 GhzFrequenzsprung, binäre Frequenzmodulation
sollen Interferenzen und Komplexität verringernSymbolrate: 1 Ms/sSlotted-Channels mit Slot-Länge von 625 µsDuplexverbindungen mit TDD (Time Division Duplex)
Daten in Paketen übertragenJedes Paket mit anderer Hop-Frequenzi.d.R. ein Paket je Slot● bis zu fünf Slots bei langen Paketen
Prof. Dr. W. Kowalk Rechnernetze II Seite 12
BluetoothBluetooth
BasisbandspezifikationKombination aus Leitungs- und Paktvermittlung
synchrone DatenkanalZeitschlitze reservierenbis zu drei synchrone Sprachdatenkanäle64 kb/s Sprachkanal in jeder Richtung
asynchroner Datenkanalbis zu 723,2 kb/s asymmetrisch (bis zu 57,6 kb/s in Gegenrichtung) 433,9 kb/s symmetrisch
Prof. Dr. W. Kowalk Rechnernetze II Seite 13
BluetoothBluetooth
BasisbandspezifikationBluetooth-System besteht aus
einer Funkeinheit, Linkkontrolleinheit Unterstützungseinheit für
Linkmanagement Host-Terminal-Schnittstellenfunktionen
Prof. Dr. W. Kowalk Rechnernetze II Seite 14
BluetoothBluetooth
BasisbandspezifikationPunkt-zu-Punkt-Verbindung
zwei Bluetooth-Geräte involviert
Punkt-zu-Mehrpunkt-VerbindungKanal zwischen mehreren Bluetooth-Einheiten aufgeteiltPiconet
ein Master des Piconetsanderen Einheiten Slavesbis zu sieben Slavesweitere Slaves durch Master in Parkzustand blockiertKanalzugriff durch Master
Prof. Dr. W. Kowalk Rechnernetze II Seite 15
BluetoothBluetooth
BasisbandspezifikationScatternet
mehrere Piconets mit überlappendem Bereichje Piconet genau ein Master Slaves in verschiedenen PiconetsMaster in einem Piconet, Slave in einem anderen Piconet Piconets nicht frequenzsynchronisiert jedes Piconet hat eigenen Hopping-Kanal
Prof. Dr. W. Kowalk Rechnernetze II Seite 16
BluetoothBluetooth
Physikalischer KanalKanaldefinition
Pseudozufallsfreqenzsprungverfahren 79 oder 23 FrequenzenSprungfolge für Piconetz eindeutig durch Bluetooth-Geräteadresse des Masters bestimmtPhase der Sprungfolge durch Bluetooth-Clock des Masters festgelegtKanal in Zeitschlitze unterteiltjeder Zeitschlitz entspricht einer Sprungfrequenzaufeinanderfolgende Sprünge entsprechen verschiedenen Frequenzennominale Sprungrate ist 1600 hops/sEinheiten je Piconet zu Kanal zeit- und sprungsynchronisiert
Prof. Dr. W. Kowalk Rechnernetze II Seite 17
BluetoothBluetooth
Physikalischer KanalZeitschlitze
Zeitschlitze mit jeweils 625 µs LängeZeitschlitze nummeriert nach Clock des Piconetz-Masters
Slot-Nummer reicht von 0 bis 227-1 Zykluslänge von 227 je Zeitschlitz können Master und Slave Pakete übertragen
TDD-Schema Master und Slave senden alternierendMaster sendet nur in gerade nummerierten ZeitschlitzenSlave sendet nur in ungerade nummerierten Zeitschlitzen
Prof. Dr. W. Kowalk Rechnernetze II Seite 18
BluetoothBluetooth
Physikalischer KanalZeitschlitz
TDD-Schema Paketstart beginnt mit ZeitschlitzstartPakete dürfen bis zu fünf Zeitschlitze überdeckenSprungfrequenz während der Dauer einer Übertragung festaus gegenwärtigem Wert der Bluetooth-Clock abgeleitet● mehr als einen Zeitschlitz● Sprungfrequenz aus erstem Zeitschlitz des Pakets berechnet,
während der Übertragung dieses Pakets unverändert● danach Sprungfrequenz wieder nach absoluter Clock
Prof. Dr. W. Kowalk Rechnernetze II Seite 19
BluetoothBluetooth
Physikalische Verbindungen (Links)verschiedene Verbindungstypen
Synchrone verbindungsorientierte Verbindung(Synchronous Connection-Oriented: SCO)Asynchrone verbindungslose Verbindung(Asynchronous Connectionless: ACL)
SCO-VerbindungPunkt-zu-Punkt-Verbindung Master – Slave in Piconetreservierte Slots in regelmäßigen Intervallen
Prof. Dr. W. Kowalk Rechnernetze II Seite 20
BluetoothBluetooth
Physikalische Verbindungen (Links)ACL-Verbindung
Punkt-zu-Mehrpunkt-Verbindung zwischen Master und sämtlichen Slaves im Piconet in nicht für SCO-Verbindungen reservierten SlotsACL-Verbindung auf Pro-Slot-Basis zu jedem Slaveauch mit SCO-Verbindung
Prof. Dr. W. Kowalk Rechnernetze II Seite 21
BluetoothBluetooth
Physikalische Verbindungen (Links)SCO LINK
symmetrische Punkt-zu-Punkt-Verbindungzwischen Master und spezifischem SlaveSCO-Verbindung reserviert Zeitschlitze ● leitungsvermittelte Verbindung zwischen Master und Slave
typischerweise zeitkritische Dienste wie SpracheMaster● bis zu drei SCO-Verbindungen gleichzeitig● zu gleichen oder verschiedenen Slaves
Slave● bis zu drei SCO-Verbindungen zu gleichem Master● zwei SCO-Links zu verschiedenen Mastern
SCO-Pakete werden niemals wiederholt
Prof. Dr. W. Kowalk Rechnernetze II Seite 22
BluetoothBluetooth
Physikalische Verbindungen (Links)SCO LINK
SCO-Intervall TSCO (in Schlitzen gezählt)regelmäßige Abständereservierte Master-zu-Slave-ZeitschlitzenSCO-PaketeSCO-Slave sendet SCO-Packet in folgendem Slave-zu-Master-Slot● außer wenn andere Slave in vorhergehendem Master-zu-Slave-
Zeitschlitzen adressiert● auch wenn Slave-Adresse nicht dekodierbar
Prof. Dr. W. Kowalk Rechnernetze II Seite 23
BluetoothBluetooth
Physikalische Verbindungen (Links)SCO LINK
SCO-Verbindung wird von Master aufgebautSCO-Verbindungsaufbau-Nachricht im LM-Protokoll gesendet● Timing-Paramter wie
● SCO-Interverall TSCO ● Offset-DSCO, spezifiziert reservierte Zeitschlitze ● Initialisierungsprozedur 1 oder 2
● Uhr-Überlaufprobleme
Prof. Dr. W. Kowalk Rechnernetze II Seite 24
BluetoothBluetooth
Physikalische Verbindungen (Links)ACL LINK
nur in nicht für SCO-Verbindungen reservierten Slots Master kann Pakete mit jedem aktiven Slave austauschenpaketvermittelte Verbindungennur eine einzige ACL-Verbindung je Slavesynchrone, isochrone DiensteACL-Pakete wiederholt zur Datenintegrität (ARQ)Slave antwortet nur in FogleschlitzBroadcast-Paketesonst keine Übertragung
Prof. Dr. W. Kowalk Rechnernetze II Seite 25
BluetoothBluetooth
PaketformateStandardformat
72 Bits Zugriffscode (acces code)54 Bits Header0-2745 Bits Nutzdatenmit kleinstem Bit zuerst gesendet
Pakete können bestehen aus(verkürztem) ZugriffscodeZugriffscode plus Headerallen drei Teilen
Prof. Dr. W. Kowalk Rechnernetze II Seite 26
BluetoothBluetooth
PaketformateZugriffscode
Preamble 4 Bits LängeTrailer 4 Bits LängeSYNC-Word
kodiert Adresse
Prof. Dr. W. Kowalk Rechnernetze II Seite 27
BluetoothBluetooth
PaketformateHeader
Verbindungskontrolle (LC: Link Control) AM_ADDR: 3- bit active member address● Identifiziert Slave in Piconet ● beim Senden vom Master und Slave verwendet● 0 ist Broadcastadresse (außer FHS)● geparkter/abgemeldeter Slave verliert Adresse
TYPE: 4-bit type code● Typ eines Pakets● hängt von Verbindungstyp (SCO, ACL) ab
FLOW: 1-bit flow control● Flusskontrolle (FLOW=0: keine weiteren Paketen senden) ● nur für ACL-Verbindungen
Prof. Dr. W. Kowalk Rechnernetze II Seite 28
BluetoothBluetooth
PaketformateHeader
Verbindungskontrolle (LC: Link Control) (ff.)ARQN: 1-bit acknowledge indication● positive (ARQN=1) oder negative Quittung (ARQN=0)
SEQN: 1-bit sequence number● Alternierende Nummerierung von Blöcken● mit CRC-Prüfsumme
HEC: 8-bit header error check● Header Error Correction-Prüfsumme für Header
HEC = 1101001112
Prof. Dr. W. Kowalk Rechnernetze II Seite 29
BluetoothBluetooth
PaketformateHeader
Header besteht aus 18 BitsFehlerkorrekturverfahren (1/3 FEC)● sendet jedes Bit dreimal● insgesamt 54 Bits
nicht kontinuierliches ARQ-Verfahren mit alternierender Paketnummer● Empfänger kann mehrfach gesendete CRC-Blöcke unterscheiden● Sender muss auf ACK warten, ehe weiteres Paket senden
Prof. Dr. W. Kowalk Rechnernetze II Seite 30
BluetoothBluetooth
PaketformateHeader
16 TypfelderVier für SCO- und ACL-VerbindungenNULL- Paket, POLL-Paket● Zustandsinformation
● Quittung (ARQN) ● Flusskontrolle
ID-Paket ● Anfrage ● Antworten
Prof. Dr. W. Kowalk Rechnernetze II Seite 31
BluetoothBluetooth
PaketformateHeader
16 TypfelderFHS-Paket● spezielles Kontrollpaket● Bluetooth-Geräteadresse ● Clock des Senders
Prof. Dr. W. Kowalk Rechnernetze II Seite 32
BluetoothBluetooth
PaketformateHeader
16 TypfelderSCO-Pakete besitzen kein CRC● zeitkritische Dienste wie Sprachübertragung● niemals wiederholt● einzelne Fehler hinnehmbar● unterschiedliche Datenrate
ACL-Pakete besitzen meistens CRC-Feld● wertekritische Daten● zusätzlich FEC (Forward Error Correction)● Daten sehr sicher übertragbar● ohne positive Quittung bei ACL-Paket mit CRC-Feld wird dieses
wiederholt
Prof. Dr. W. Kowalk Rechnernetze II Seite 33
BluetoothBluetooth
Fehlerkorrekturdrei Fehlerkorrekturverfahren:
1/3 rate FECJedes Bit wird dreimal direkt hintereinander gesendetbei allen Headern und bei einem Sprachdienst verwendetbei einem Bitfehler korrekter Wert berechenbar: Entscheider (arbiter)
2/3 rate FEC15 Bit-Hammingverfahren● zu 10 Bits ein 5 Bit-Rest (Generator = 1101012)● Empfänger kann
● 1 Bit-Fehler korrigieren ● 2 Bit-Fehler erkennen
Prof. Dr. W. Kowalk Rechnernetze II Seite 34
BluetoothBluetooth
Fehlerkorrekturdrei Fehlerkorrekturverfahren:
ARQ-Verfahren für Datennur bei gesicherten DatenpaktenSende- und Warte-ARQQuittung direkt im nächsten Slot nach DatenpaketWartezeit in der Regel geringmehrfach gesendete gleiche Pakete vom Empfänger unterscheidbar
Flushingsendet auch im Fehlerfall folgenden Datensatzbei zeitkritischen Daten notwendig● isochrone Daten● Befehle zum Steuern mechanischer Geräte
Prof. Dr. W. Kowalk Rechnernetze II Seite 35
BluetoothBluetooth
FehlerkorrekturBroadcast-Nachrichten
können nicht quittiert werden sämtliche Broadcast-Nachrichten werden mehrfach gesendet
Fehlererkennung mit CRC-Verfahren
CCITT-CRC-Generatorpolynom G(D)=D16+D12+D5+D0==10001000000100001.Register mit speziellem Anfangswert initialisiert(UAP: upper address part)
Prof. Dr. W. Kowalk Rechnernetze II Seite 36
BluetoothBluetooth
Logische KanäleLC control channel
Kontrollinformation ● ARQ● Flusskontrolle ● Nutzdatentyp● im Header der Pakete transportiert● in jedem Paket (außer ID-Paket)
LM control channelKontrollinformation zwischen Linkmanagernin DM-Paketen transportiert
Prof. Dr. W. Kowalk Rechnernetze II Seite 37
BluetoothBluetooth
Logische KanäleUA user channel
asynchrone Nutzdatensichere Datenübertragung durch FEC und ARQPayload-Header● L_CH-Feld auf 102 (Start eines Fragments) ● L_CH-Feld auf 012 (Folgefragment)
UI user channelisochrone Nutzdatenwie UA auf der Baseband-Schichtinnerhalb einer bestimmten Zeit beim Empfänger eintreffen
Prof. Dr. W. Kowalk Rechnernetze II Seite 38
BluetoothBluetooth
Logische KanäleUS user channel
synchrone Nutzdatenkein ARQ-Verfahrenoptional eines von mehreren Fehlerkorrekturverfahren verwendetin SCO-Paketen transportiert
Prof. Dr. W. Kowalk Rechnernetze II Seite 39
BluetoothBluetooth
Senden und EmpfangenSende und Warte-ARQ-Verfahren
Master sendet DatenQuittung im nächsten Slot des SlavesMaster kann nächstes Paket sendenoder das vorherige Paket wiederholenalternierende Zähler unterscheidet gleiche PaketeNULL-Paket, wenn keine Daten gesendet werden● nur Kontrolldaten (ACK, NACK, Flusskontrolle)
Synchrone Datennur in bestimmten Zeitschlitzen gesendetbeim Verbindungsaufbau ausgehandelt nicht durch ARQ-Verfahren geschütztkeine Quittung
Prof. Dr. W. Kowalk Rechnernetze II Seite 40
BluetoothBluetooth
Senden und Empfangenin einem Paket synchrone und asynchrone Daten (DV - data, voice)negative oder keine Quittung ● gleiche asynchrone, neue synchrone Nutzdaten
FlusskontrolleSenden eines STOP-Bits vom EmpfängerSender bewahrt letztes Datenpaket sendet NULL-Pakete, bis GO-Bit eintrifftkein Paket wird implizit als GO interpretiertfür jeden Slave unabhängig
Prof. Dr. W. Kowalk Rechnernetze II Seite 41
BluetoothBluetooth
Senden und EmpfangenStandard empfiehlt
synchrone und asynchrone Daten in unterschiedlichen Puffern speichernfür jeden Link einen Puffer vorsehen● in Hardware umsetzbar
Kontrolldaten zunächst gescrambelt (Whitening)● möglichst zufällige Bitfolgen erzeugen● nach der HEC-Erzeugung ● vor der FEC
Nutzdaten gescrambeltandere Operationen optional ● z.B. Verschlüsselung,
Prof. Dr. W. Kowalk Rechnernetze II Seite 42
BluetoothBluetooth
Timingausschließlich durch Clock des Masters sämtliche Slaves synchronisieren sich an Master
jedes Mal, wenn Master Paket an irgendeinen Slave sendetmaximale Abweichungen
hängen von der Genauigkeit der lokalen Uhren abMaster sendet unter gewissen Umständen eine Zeitlang nichtAbweichungen können teilweise angepasst werden
Prof. Dr. W. Kowalk Rechnernetze II Seite 43
BluetoothBluetooth
ScatternetGruppe von Piconets, zwischen deren Einheiten Verbindungen bestehen
Mehrere Piconets können gleichzeitig existierenSlave kann in mehreren Piconets seinStation kann nur in einem Piconet Master sein
Master bestimmt Hopfolge Timer 'seines' Piconets sämtliche partizipierenden Slaves liegen im gleichen Piconet
jedes Piconet eigene HopfolgeWahrscheinlichkeit einer Kollision relativ geringKollision aber nicht ausgeschlossen
Prof. Dr. W. Kowalk Rechnernetze II Seite 44
BluetoothBluetooth
ScatternetMaster 'paged' Master oder Slave in anderem Piconet
Einheit in einem Piconet keine eine in anderem Piconet pagendiese Station wird zum Master u.U. Vertauschung der Master-Slave-Rollen notwendig
Station will in anderem Piconet teilnehmen wechselt in Hold- oder Parkmodus kann auch im Sniff-Modus sein und entsprechend Zeit partizipierensynchrone Verbindung kann aufgrund Phasenverschiebung nur in der Hälfte der Slots eines anderen Piconets sendenin der Regel für jedes Piconet eigene Clock unterhalten
Prof. Dr. W. Kowalk Rechnernetze II Seite 45
BluetoothBluetooth
Power Managementmöglichst geringe Leistungsaufnahme der Einheiten
Paketbearbeitung minimiert● nur nützliche Daten gesendet
● NULL-Pakete, wenn Quittungen zu senden sind● kein explizites NAK, da implizit ● Daten nur in der notwendigen Länge gesendet● Empfänger liest fremde Daten nicht weiter● ungültiges HEC beendet Empfang
● Daten über mehrere Slots abwarten, ehe Slave wieder liest● verschiedenen Betriebsmodi minimieren Leistungsverbrauch
● Sniff● Hold ● Park
Prof. Dr. W. Kowalk Rechnernetze II Seite 46
BluetoothBluetooth
Kanalkontrolle (Channel Control)baut Piconet auffügt Einheiten hinzu bzw. entfernt diese aus Piconet
eine Station muss als Master ausgewählt werdenerste Station, die Verbindung aufbauen will, wird Masterim Prinzip jede Station als Master auswählbar
alle Stationen identische FunktionalitätenMaster bestimmt durch Polling, welcher Slave senden darf. Piconet durch Bluetooth-Adresse des Masters spezifiziertaus Adresse wird gemeinsame Hopfolge bestimmt
Prof. Dr. W. Kowalk Rechnernetze II Seite 47
BluetoothBluetooth
Kanalkontrolle (Channel Control)Master muss seine Slaves finden
verschiedene Sendefrequenzen abfragen und abhorchen Hopfolge erst starten, wenn sich Slave(s) gemeldet habenClock des Piconets ebenfalls vom Master vorgegebenLink Supervision
mittels spezieller Timer wird überprüft, ob Kanal noch in Betrieb
Prof. Dr. W. Kowalk Rechnernetze II Seite 48
BluetoothBluetooth
Kanalkontrolle (Channel Control)Zustände
2 Hauptzustände (Standby und Connection) 7 Unterzustände (Aufnahme neuer Einheiten in Piconet)
STANDBY STATE● Defaultzustand● nur die Clock läuft● Zustand verlassen
● zum Erlauschen von Page- oder Anfragenachrichten● Page-Anfrage
● Station geht in den Connectionstate als Slave● Page-attempt
● Connectionstate als Master
Prof. Dr. W. Kowalk Rechnernetze II Seite 49
BluetoothBluetooth
Kanalkontrolle (Channel Control)Zustände
PAGE SCAN● Slave versucht auf PAGE-Signal des Master zu reagieren● unterschiedliche Frequenzen (Hop-Frequency)
● komplexes Problem● horcht längere Zeit auf einzelnen Frequenzen, bis Master-
Frequenz gefunden● synchronisieren
PAGE● Master sucht nach Slave, dessen Adresse er kennt● Sendet auf unterschiedlichen Hop-Frequenzen in kurzen
Abständen● jeweiligen Slave möglichst schnell finden und synchronisieren
Prof. Dr. W. Kowalk Rechnernetze II Seite 50
BluetoothBluetooth
Kanalkontrolle (Channel Control)Zustände
Master Response und Slave Response● Master und Slave tauschen Anfangswerte aus ● beginnen mit geordnetem Datenaustausch● wechseln in Connection-Zustand
INQUIRY● sämtlich erreichbaren Einheiten abfragbar● insbesondere deren Funktionalitäten (Drucker, Fax, Telefon etc.)
INQUIRY-SCAN● abfragen, ob Einheit einen INQUIRY-SCAN vollführt ● entsprechend reagieren
Prof. Dr. W. Kowalk Rechnernetze II Seite 51
BluetoothBluetooth
Kanalkontrolle (Channel Control)Zustände
INQUIRY-Response● zu erkanntem Gerät Verbindung aufgebaut ● danach in Connection-Zustand gewechselt
Connection-State ● normale Datenübertragung
● als erstes wird POLL-Paket gesendet● Slave kann sich synchronisieren
● dann Kontrollinformation über Art der Verbindung ● durch Detach- oder Reset-Kommando wieder verlassen
Prof. Dr. W. Kowalk Rechnernetze II Seite 52
BluetoothBluetooth
BetriebsmodiVier Betriebsmodi im Connection-State
Active ModeEinheit sendet DatenMaster teilt Slaves Zeitschlitze zuSlaves horchen, ob Paket für sie bestimmtSlave darf nicht senden, wenn Master längere Datenpakte überträgt ● an Typ des Pakets erkennbar
Prof. Dr. W. Kowalk Rechnernetze II Seite 53
BluetoothBluetooth
BetriebsmodiSniff Mode
Master / Slave überprüfen nur in bestimmten Slots, ob Pakete für sie vorliegenSlave weniger aktiver ZustandAbstände zu Beginn ausgehandeltSlave kann evtl. Verbindung zu einem anderen Piconet aufbauen
Hold ModeSlave kann keine asynchronen (aber synchrone) Daten empfangenin Ruhezustand● beispielsweise anderem Piconet anschließen
Zeit zwischen Master und Slave vereinbartSlave behält dynamische Adresse: Active Member Address (AM_ADDR)
Prof. Dr. W. Kowalk Rechnernetze II Seite 54
BluetoothBluetooth
BetriebsmodiPark Mode
Station kann keine Daten mehr empfangenStation verliert dynamische Adresse
erhält Parkadresse (PM_ADDR)mehr als sieben Slaves von einem Master in Piconet verwaltbarSlave wacht regelmäßig auf und prüft auf Broadcast-MessagesResynchronisation mit Master durch speziellen Beacon-Prozess
Prof. Dr. W. Kowalk Rechnernetze II Seite 55
BluetoothBluetooth
Pollingaktiver ModusMaster hat vollständige Kontrolle über Piconet
Slaves dürfen nur asynchron sendenasynchron: wenn in vorhergehendem (Master-zu-Slave) Slot ihre dynamische Adresse genannt wurdebei der synchronen Übertragung in vorher vereinbarten Slorts● außer in vorhergehendem Zeitschlitz wurde explizit anderer
Slave adressiert.
ParkmodusSlaves dürfen nur nach Broadcastnachricht Zugrifssanforderung senden
Prof. Dr. W. Kowalk Rechnernetze II Seite 56
BluetoothBluetooth
Link Management Protocol LMVerwendung
VerbindungsaufbauSicherheit Überwachung
Nutzdaten in Link Control Protocol reservierter Wert in L_CH-Feld (logischen Kanalfeld) Nachrichten werden ausgefiltertdurch Link Management des Empfängers interpretiertnicht an höhere Schichten weitergeleitet
Prof. Dr. W. Kowalk Rechnernetze II Seite 57
BluetoothBluetooth
Link Management ProtocolLink Management-Nachrichten
höhere Priorität als BenutzerdatenLM-Nachrichten nicht durch Link Control-Protokoll verzögert Verzögert durch wiederholtes Senden individueller Baseband-Pakete
Prof. Dr. W. Kowalk Rechnernetze II Seite 58
BluetoothBluetooth
Link Management ProtocolLink Management-Nachrichten
Link Control-Protokoll garantiert zuverlässigen Übertragungsdienst● keine expliziten Quittungen für LMP-Nachrichten nötig
garantiert keine Übertragungszeit für Nachricht oder QuittungZustandswechsel zwischen Master und Slave synchronisieren● Wiederverwendung der Adresse eines geparkten Slaves● auch Master-Clock (LM von LC)
LC garantiert kommuniziert mit jedem Slave einmal innerhalb eines Tpoll-Zeitschlitzs Zeit zwischen Empfang und Senden einer LMP-PDU und deren Antwort bis zu 30 s
Prof. Dr. W. Kowalk Rechnernetze II Seite 59
BluetoothBluetooth
Logical Link Control and Adaptation Protocol (L2CAP)
oberhalb des Baseband-Protokolls innerhalb der Sicherungsschicht (Data Link Layer)
verbindungsorientierte und verbindungslose DatendiensteMultiplexen höherer Protokolle Segmentierungs- und ReassemblierungsfunktionenDatenpakete bis zu 64 kilobit Länge für höhere Schichten
Prof. Dr. W. Kowalk Rechnernetze II Seite 60
BluetoothBluetooth
Logical Link Control and Adaptation Protocol (L2CAP)
Reassemblierung
Prof. Dr. W. Kowalk Rechnernetze II Seite 61
BluetoothBluetooth
Service Discovery Protocol (SDP)findet verfügbare Dienste
Bestimmt deren Charakteristika
Dienste können wechselndrahtlose Umgebung
sehr schnell und häufig Diensteerkennung qualitativ anspruchsvoller SDP soll diesen Anforderungen genügen
Prof. Dr. W. Kowalk Rechnernetze II Seite 62
BluetoothBluetooth
Service Discovery Protocol (SDP)
ServiceClassIDList Identifies the type of service represented by a service record. In otherwords, the list of classes of which the service is an instance
ServiceID Uniquely identifies a specific instance of a service
ProtocolDescriptorList Specifies the protocol stack(s) that may be used to utilize a service
ProviderName The textual name of the individual or organization that provides a service
IconURL Specifies a URL that refers to an icon image that may be used to representa service
ServiceName A text string containing a human-readable name for the service
ServiceDescription A text string describing the service
Prof. Dr. W. Kowalk Rechnernetze II Seite 63
BluetoothBluetooth
Serial Port Emulation (RFCOMM)emuliert seriellen Port über L2CAP-Protokoll
ETSI-Standard TS 07.10verwendet nur Teilmenge dieses Standards
Bluetooth spezifische Adaptionen und Erweiterungen z.B. kreditbasiertes Flusskontroll-Schema
Prof. Dr. W. Kowalk Rechnernetze II Seite 64
BluetoothBluetooth
Sicherheit in BluetoothBluetooth stellt zur Verfügung
Schutz der Dienstnutzung Vertraulichkeit
sämtliche Authentifizierungs- und Verschlüsselungsroutinen auf gleiche Weise implementiert● Herstellerunabhängigkeit
Für die Sicherheit auf dem Link Layer werden vier Zahlen verwendet:
Prof. Dr. W. Kowalk Rechnernetze II Seite 65
BluetoothBluetooth
Sicherheit in BluetoothFür Sicherheit auf Link Layer 4 Zahlen verwendet
Bezeichnung Größe in Bits Bedeutung
BD_ADDR: Bluetooth device address 48 Bits Eindeutige Benutzerkennung; dieses istkein geschützter Wert
Privater Benutzerschlüssel zurAuthentisierung 128 Bits
Geheimer Schlüssel zur Authentisierungeines Benutzers
Privater Benutzerschlüssel zurVerschlüsselung
8, 16, ..., 128 Bits Geheimer Schlüssel zur Verschlüsselungvon Benutzerdaten
RAND 128 BitsZufallszahl, die für jede Transaktionverschieden ist
Prof. Dr. W. Kowalk Rechnernetze II Seite 66
BluetoothBluetooth
Sicherheit in BluetoothFür Sicherheit auf Link Layer 4 Zahlen verwendet
geheimen Schlüssel werden bei Initialisierung erzeugtVerschlüsselungsschlüssel aus Authentisierungsschlüssel abgeleitet (Linkkey) ● häufiger geändert
Schlüsselgröße zur Authentisierung ist festfür (optionale) Verschlüsselung konfigurierbare Schlüsselgröße● gewisse rechtliche Regelungen ● mögliche Erweiterbarkeit in der Zukunft
Verschlüsselungsschlüssel völlig unabhängig vom Authentisierungsschlüssel● auch wenn aus diesem generiert
Jede neue Aktivierung der Verschlüsselung sollte (optional) neuen Verschlüsselungsschlüssel generieren
Prof. Dr. W. Kowalk Rechnernetze II Seite 67
BluetoothBluetooth
Sicherheit in BluetoothFür Sicherheit auf Link Layer 4 Zahlen verwendet
RAND ist Zufallszahlvon zufälligem Prozess erzeugt odervon Pseudozufallszahlengenerator-Prozess erzeugt ändert sich häufig
Prof. Dr. W. Kowalk Rechnernetze II Seite 68
BluetoothBluetooth
Sicherheit in BluetoothSchlüsselverwaltung
Linkkey zur Authentisierung zwischen zwei oder mehr Stationen
semi-permanenter Linkkey ● über mehrere Sitzungen (d.h. in mehreren Piconetzen) gleich ● in nicht-flüchtigem Speicher gehalten
temporärer Linkkey kann nur in einer Sitzung existieren● häufig benutzt, wenn mehr als zwei Stationen (Punkt-zu-
Mehrpunkt) untereinander Daten austauschen
Prof. Dr. W. Kowalk Rechnernetze II Seite 69
BluetoothBluetoothSicherheit in Bluetooth
Schlüsselverwaltung Es werden vier Linkkeys unterschieden
Der Kombinationsschlüssel KAB
● aus Linkkeys zweier Einheiten A und B berechnet● gleiche Funktionalität wie Einheitenschlüssel
Der Einheitenschlüssel KA
● aus Linkkey der Einheiten A berechnet● gleiche Funktionalität wie Kombinationsschlüssel
temporäre Schlüssel Kmaster
● kurzzeitig als temporärer Linkkey verwendet● z.B. bei Punkt-zu-Mehrpunkt-Verbindungen
Der Initialisierungsschlüssel Kinit
● Wird nur bei der Initialisierung des Linkkeys benutzt.
Prof. Dr. W. Kowalk Rechnernetze II Seite 70
BluetoothBluetooth
Sicherheit in BluetoothSchlüsselverwaltung
Initialisierung ausZufallszahlPIN-Code ● PIN-Code kann
● von Benutzern eingegeben werden oder● fest in Bluetooth-Einheit eingebaut sein
Initialisierungsschlüssel Kinit
Prof. Dr. W. Kowalk Rechnernetze II Seite 71
BluetoothBluetooth
Sicherheit in BluetoothSchlüsselverwaltung
Initialisierung des Linkkeys1. Erzeugung eines Initialisierungsschlüssel Kinit
Der Initialisierungsschlüssel wird mit dem Algorithmus E22(BD_ADDR, PIN, |PIN|, IN_RAND) PIN muss frei gewählt sein (nicht fest installierte)Vertraulichkeit hängt also nur von PIN ab
2. Erzeugung eines Linkkeys Klink
KA (Linkkey für Station A)berechnet aus Zufallszahl RAND und Adresse BD_ADDRA nach Algorithmus E21
Prof. Dr. W. Kowalk Rechnernetze II Seite 72
BluetoothBluetooth
Sicherheit in BluetoothSchlüsselverwaltung
Initialisierung des Linkkeys3. Austausch des Linkkeys
Der Linkkey KA wird an Station B übersandt, indem er zunächst mit Kinit xoder verknüpft wird. B kann, da er Kinit kennt, wieder KA daraus berechnen.Wird ein Kombinationsschlüssel KAB verwendet, so erzeugt jede Station eine eigene Zufallszahl und erhält die der Gegenstelle; dann verknüpft nach E21 jede Station ihre Zufallszahl mit ihrer Adresse und die der anderen mit deren Adresse und verknüpft die Ergebnisse mit xor.
Prof. Dr. W. Kowalk Rechnernetze II Seite 73
BluetoothBluetooth
Sicherheit in BluetoothSchlüsselverwaltung
Initialisierung des Linkkeys4.Authentifizierung
Challenge-Response-VerfahrenA sendet an B eine Zufallszahl RAND (Challenge), B berechnet SRES=E1(RAND, BD_ADDRB,Linkkey) und sendet dieses an A zurück.
5.Optionale Erzeugung eines Verschlüsselungsschlüssel KCVerschlüsselungsschlüssel nach Algorithmus E3 berechnet aus- Linkkey, - Ciphering Offset (COF, 96 Bits) - ZufallszahlCiphering Offset ist entweder die zweimal konkatenierte Stationsadresse BD_ADDR oder eine Zahl (ACO) aus Authentisierung