Funktionsübersicht zu Bluetooth® Core 7.0

Version:	1.0
Erscheinungsdatum:	3. November 2026
Autor:	Gongyu Lu

1. Einleitung

Bluetooth® Core 7.0 führt eine Reihe von Verbesserungen ein, die die Funktionen von Bluetooth® LE in den Bereichen Datendurchsatz, isochroner Datentransport, Sicherheit und Implementierungsunterstützung erweitern. Diese Verbesserungen tragen den sich wandelnden Anforderungen nach höherem Durchsatz, flexiblerem Transportverhalten, neuen Sicherheitsmodellen und verbesserter Transparenz bei der Entwicklung und bei Interoperabilitätstests Rechnung. Zusammen bauen sie auf der bestehenden Bluetooth-Architektur auf und führen gleichzeitig neue Funktionen ein, die es Bluetooth-Geräten ermöglichen, sich an immer anspruchsvollere Anwendungen und Betriebsumgebungen anzupassen.

Dieser Artikel bietet einen technischen Überblick über die wichtigsten Funktionen, die mit Bluetooth® Core 7.0 eingeführt wurden. Er befasst sich mit Bluetooth® High Data Throughput (HDT), Bluetooth® LE Isochronous Parameter Update (IPU), Bluetooth® Encryption Key Schedule (EKS), Bluetooth® Transient Application Key (TAK) und Bluetooth® Encryption Product Debugging (EPD). Für jede Funktion beschreibt das Dokument die zugrunde liegenden Beweggründe, Architekturkonzepte und wichtigsten Protokollmechanismen und liefert damit eine Grundlage für das Verständnis, wie diese Änderungen die Bluetooth-Technologie erweitern und weiterentwickeln.

Hinweis: Bei diesem Dokument handelt es sich um ein Marketingdokument, das in keiner Weise dazu bestimmt ist, die Bluetooth®-Kernspezifikation zu ersetzen oder außer Kraft zu setzen. Jede Funktionserweiterung wird in einem eigenen Abschnitt beschrieben, der mit den entsprechenden Hintergrundinformationen beginnt. Dies soll Lesern helfen, die mit bestimmten Aspekten von Bluetooth® LE möglicherweise nicht vertraut sind. Die Abschnitte mit den Hintergrundinformationen sind jedoch nicht vollständig umfassend. Lesern, die auf unbekannte Begriffe oder Konzepte stoßen, wird empfohlen, die Bluetooth® LE-Einführung herunterzuladen und zu lesen .

2. Auf einen Blick

2.1 Bluetooth® mit hohem Datendurchsatz

Bluetooth® High Data Throughput (HDT) führt eine neue physikalische Schicht für Bluetooth LE ein, die die maximale Bluetooth-Bitrate auf 7,5 Mbit/s erhöht und gleichzeitig die Effizienz und Robustheit der drahtlosen Übertragung verbessert. Durch eine Kombination aus Modulation höherer Ordnung, konvolutioneller Vorwärtsfehlerkorrektur, Synchronisationsverbesserungen, adaptiver Ratenauswahl und optimierten Paketarchitekturen ermöglicht HDT Bluetooth-Geräten, größere Datenmengen effizienter und zuverlässiger zu übertragen. Die Funktion bietet eine skalierbare Grundlage für zukünftige Bluetooth-Anwendungen mit höheren Datenraten, darunter hochauflösendes und verlustfreies Audio-Streaming, und gewährleistet gleichzeitig die Abwärtskompatibilität mit der bestehenden Bluetooth LE-Architektur.

2.2 Isochrones Parameter-Update über Bluetooth® LE

Bluetooth® LE Isochronous Parameter Update (IPU) führt einen standardisierten Mechanismus ein, der es ermöglicht, die Parameter eines aktiven Connected Isochronous Stream (CIS) zu aktualisieren, nachdem der Stream aufgebaut wurde. Anstatt eine „Connected Isochronous Group“ (CIG) zu entfernen und neu zu erstellen, wenn sich Anforderungen hinsichtlich Bandbreite, Latenz, Transport oder Zeitplanung ändern, ermöglicht IPU den Geräten den Wechsel zwischen alternativen Stream-Konfigurationen unter Beibehaltung der bestehenden Verbindung. Diese Funktion verbessert die Flexibilität für Bluetooth LE Audio und andere isochrone Anwendungen, reduziert Dienstunterbrechungen und ermöglicht es Bluetooth®-Geräten, die Transporteigenschaften dynamisch an sich ändernde Anwendungsanforderungen anzupassen.

2.3 Bluetooth®-Verschlüsselungsschlüsselschema

Bluetooth® Encryption Key Schedule (EKS) führt ein neues Rahmenwerk für die Einrichtung und Verwaltung von Verschlüsselungsschlüsseln ein, die bei Bluetooth® LE-Verbindungen verwendet werden. Anstatt Verschlüsselungsmaterial direkt aus einem Langzeitschlüssel (LTK) abzuleiten, kombiniert EKS die ECDH-basierte Schlüsseleinrichtung mit einer CMAC-basierten Schlüsselableitungshierarchie, um sitzungsspezifisches Verschlüsselungsmaterial zu generieren. Diese Architektur ermöglicht es Geräten, Verschlüsselungsschlüssel zu aktualisieren, separate Sicherheitskontexte für verschiedene Transportarten zu verwalten und einen erweiterten Schutz durch den Message Integrity Code (MIC) zu unterstützen. EKS dient als Sicherheitsgrundlage für Bluetooth® High Data Throughput (HDT) und bleibt gleichzeitig als eigenständige Bluetooth-Funktion definiert, die auch zusätzliche Bluetooth-Anwendungsfälle unterstützen kann.

2.4 Bluetooth®-Schlüssel für vorübergehende Nutzung

Der Bluetooth® Transient Application Key (TAK) führt einen neuen Ansatz zur Sicherung von Bluetooth® LE-Verbindungen ein, indem er eine Verschlüsselung ermöglicht, ohne auf Pairing oder Bonding angewiesen zu sein. In diesem Modell werden die Authentifizierung und der Schlüsselaufbau von einer Anwendung auf einer höheren Ebene übernommen, die ein gemeinsames, 128-Bit-Sicherheitsniveau aufweisendes Geheimnis festlegt und dieses dem Bluetooth-Host zur Verfügung stellt. Der TAK wird anschließend zum Aufbau einer Verschlüsselung auf der Verbindungsebene verwendet, wodurch Geräte sichere Verbindungen herstellen können, ohne eine langfristige Vertrauensbeziehung aufzubauen. Der Host verwirft den TAK nach dem Einleiten des Verschlüsselungsstartvorgangs, während die Anwendung einer höheren Schicht festlegt, wie ihre Kopie des Schlüssels verwaltet wird.

2.5 Fehlerbehebung bei Bluetooth®-Verschlüsselungsprodukten

Bluetooth® Encryption Product Debugging (EPD) führt einen standardisierten Mechanismus ein, der es einem Bluetooth®-Host ermöglicht, die aktiven Verschlüsselungszugangsdaten zu empfangen, die von einer verschlüsselten Verbindung verwendet werden. Indem EPD autorisierten Debugging-Tools Einblick in die vom Controller generierten und verwalteten Zugangsdaten gewährt, trägt es dazu bei, die Protokollanalyse und das Debugging im Hinblick auf die Interoperabilität aufrechtzuerhalten, während sich die Bluetooth-Verschlüsselung über den herkömmlichen, auf Langzeitschlüsseln basierenden Betrieb hinaus weiterentwickelt.

3. Bluetooth® High Data Throughput (HDT)

Bluetooth® High Data Throughput (HDT) führt eine neue physikalische Schicht für Bluetooth® LE ein, die die maximale Bluetooth-Bitrate auf 7,5 Mbit/s erhöht und gleichzeitig die Effizienz und Robustheit der drahtlosen Übertragung verbessert. Durch eine Kombination aus Modulation höherer Ordnung, konvolutiver Vorwärtsfehlerkorrektur, Synchronisationsverbesserungen, adaptiver Ratenauswahl und verbesserten Paketarchitekturen ermöglicht HDT Bluetooth-Geräten, größere Datenmengen effizienter und zuverlässiger zu übertragen. Die Funktion bietet eine skalierbare Grundlage für zukünftige Bluetooth-Anwendungen mit höheren Datenraten, darunter hochauflösendes und verlustfreies Audio-Streaming, und gewährleistet gleichzeitig die Kompatibilität mit der bestehenden Bluetooth® LE-Architektur.

3.1 Hintergrund

3.1.1 Entwicklung des Durchsatzes von Bluetooth® LE

Bluetooth LE hat sich durch die Einführung neuer physikalischer Schichten weiterentwickelt, die auf unterschiedliche Leistungsziele ausgerichtet sind. Nach der ursprünglichen LE 1M-PHY-Schicht führte die Bluetooth-Technologie LE 2M ein, um den Durchsatz zu erhöhen, sowie LE Coded, um die Reichweite und Robustheit in schwierigen Funkumgebungen zu verbessern. Diese Verbesserungen erweiterten die Vielseitigkeit von Bluetooth® LE für ein breites Spektrum an Anwendungen, wobei die Interoperabilität und Energieeffizienz gewahrt blieben.

Obwohl sich Bluetooth LE kontinuierlich weiterentwickelt hat, ist die maximal unterstützte Bitrate jedoch weiterhin auf 2 Mbit/s begrenzt. Da Bluetooth-Geräte zunehmend größere Datenmengen austauschen und anspruchsvollere Anwendungen unterstützen, wächst der Bedarf an höherem Durchsatz stetig weiter.

3.1.2 Einschränkungen bestehender Bluetooth® LE-PHYs

Die Steigerung des Durchsatzes über 2 Mbit/s hinaus stellt eine grundlegendere Herausforderung dar. Bluetooth LE arbeitet innerhalb der Grenzen des weltweit verfügbaren 2,4-GHz-ISM-Bands, wobei die Verfügbarkeit von Frequenzen, regulatorische Anforderungen, die Komplexität der Implementierung und die Energieeffizienz sorgfältig gegeneinander abgewogen werden müssen.

Die bestehenden physikalischen Schichten von Bluetooth LE basieren auf der Gaußschen Frequenzumtastung (GFSK), einem Modulationsverfahren, das durch seine Einfachheit, Robustheit und geringe Implementierungskomplexität maßgeblich zum Erfolg der Bluetooth-Technologie beigetragen hat. Allerdings schränken genau diese Eigenschaften die Möglichkeiten ein, den Durchsatz mit herkömmlichen Ansätzen zu steigern.

3.2 Technischer Überblick

3.2.1 HDT-Architektur

Bluetooth® High Data Throughput (HDT) überwindet diese Einschränkungen durch die Einführung einer neuen physikalischen Schicht für Bluetooth® LE, die auf eine deutlich höhere Spektraleffizienz optimiert ist und gleichzeitig vollständig in die Bluetooth® LE-Architektur integriert bleibt. Anstatt eine separate Funktechnologie einzuführen, baut HDT auf dem bestehenden Bluetooth® LE-Framework auf und erweitert es um neue Funktionen, die einen wesentlich höheren Durchsatz ermöglichen.

Auf der physikalischen Ebene führt HDT neue Modulations- und Codierungsverfahren ein, die deutlich höhere Datenraten innerhalb der bestehenden Bluetooth-Kanalstruktur ermöglichen. Um diese Funktionen zu unterstützen, führt HDT außerdem Verbesserungen an den Paketformaten, den Verfahren der Verbindungsschicht, den Sicherheitsmechanismen und der Funktionalität der Host-Controller-Schnittstelle (HCI) ein. Zusammen ermöglichen diese Verbesserungen es Bluetooth-Geräten, mehr Daten effizienter zu übertragen und dabei die von der Bluetooth-Technologie erwartete Interoperabilität und Zuverlässigkeit aufrechtzuerhalten.

Abbildung 3.2.1 veranschaulicht den Bluetooth-LE-Protokollstapel und hebt die wichtigsten Protokollschichten hervor, die zur Unterstützung von HDT erweitert wurden. Obwohl HDT wesentliche neue Funktionen einführt, bleibt es vollständig in die Bluetooth-LE-Architektur integriert und arbeitet weiterhin im gleichen 2,4-GHz-ISM-Frequenzband wie bestehende Bluetooth-LE-Geräte.

In den folgenden Abschnitten werden diese architektonischen Verbesserungen im Einzelnen näher beleuchtet, beginnend mit dem HDT-PHY über die Paketarchitektur und die Verbesserungen auf der Verbindungsschicht bis hin zum Sicherheitsrahmen, die gemeinsam eine Bluetooth-Kommunikation mit hohem Durchsatz ermöglichen.

3.2.2 HDT-PHY

Der HDT-PHY bildet die Grundlage für Bluetooth® High Data Throughput und ermöglicht deutlich höhere Bitraten als bestehende Bluetooth® LE-PHYs. Erreicht wird dies durch Verbesserungen bei den Modulations-, Codierungs- und Synchronisationsmechanismen, die gemeinsam die Spektraleffizienz steigern und gleichzeitig eine zuverlässige drahtlose Kommunikation gewährleisten.

3.2.2.1 Modulation, Codierung und HDT-Raten

Herkömmliche Bluetooth®-LE-PHYs basieren auf der Gaußschen Frequenzumtastung (GFSK), bei der jedes Symbol ein einzelnes Informationsbit darstellt. Dieser Ansatz bietet zwar eine hervorragende Robustheit und einfache Implementierung, schränkt jedoch die Informationsmenge ein, die innerhalb einer gegebenen Kanalbandbreite übertragen werden kann. HDT überwindet diese Einschränkung durch die Einführung kohärenter Modulationsverfahren höherer Ordnung und einer Vorwärtsfehlerkorrektur (FEC), wodurch eine deutlich verbesserte spektrale Effizienz ermöglicht wird.

Der HDT-PHY nutzt in allen Betriebsmodi ein einheitliches FEC-Framework auf Basis von Faltungscodes. Unterschiedliche HDT-Raten werden durch eine Kombination aus Modulationseffizienz und Codierungseffizienz erreicht. Im Anschluss an die FEC-Codierung kann durch Puncturing selektiv codierte Bits entfernt werden, wodurch die effektive Coderate erhöht wird und unterschiedliche Kompromisse zwischen Durchsatz und Robustheit möglich werden.

Der LE-HDT-PHY arbeitet mit einer festen Symbolrate von 2 Msym/s (Symbolperiode = 0,5 μs). Die effektive Bitrate hängt von drei Faktoren ab:

• Symbolrate
• Bits pro Symbol
• Effektive Codierrate

Konzeptionell lässt sich die effektive Bitrate wie folgt ausdrücken:

Effektive Bitrate = Symbolrate × Bits pro Symbol × effektive Coderate

Das Modulationsschema legt fest, wie viele Bits durch jedes gesendete Symbol dargestellt werden, während die effektive Coderate den Anteil der gesendeten Bits widerspiegelt, die nach Anwendung der FEC-Codierung und der Punkterung Nutzdaten enthalten. Modulationsverfahren höherer Ordnung erhöhen die spektrale Effizienz, indem sie mehr Bits pro Symbol übertragen, während höhere Coderaten den Codierungsaufwand reduzieren und den Anteil an Nutzdaten erhöhen. Zusammen ermöglichen diese Mechanismen es HDT, mehrere Betriebsraten zu unterstützen und dabei eine gemeinsame PHY-Architektur beizubehalten, wie in Tabelle 3.2.2.1 zusammengefasst.

HDT-Rate	Effektive Bitrate	Modulationsschema	Bits pro Symbol	Effektive Codierrate	Verfügbarkeit
HDT2	2 Mb/s	π/4-QPSK	2	1/2	Obligatorisch
HDT3	3 Mb/s	π/4-QPSK	2	3/4	Obligatorisch
HDT4	4 Mb/s	8PSK	3	2/3	Obligatorisch
HDT6	6 Mb/s	16QAM	4	3/4	Optional
HDT7.5	7,5 Mb/s	16QAM	4	15/16	Optional*

*Für die Unterstützung von HDT7.5 ist die Unterstützung von HDT6 erforderlich.

So kombiniert beispielsweise HDT2 eine Symbolrate von 2 Msym/s, eine π/4-QPSK-Modulation (2 Bit pro Symbol) und eine effektive Coderate von 1/2, um eine effektive Bitrate von 2 Mb/s zu erreichen. In ähnlicher Weise kombiniert HDT7,5 eine 16QAM-Modulation (4 Bit pro Symbol) mit einer effektiven Coderate von 15/16, um eine effektive Bitrate von 7,5 Mb/s zu erreichen. Diese flexible Kombination aus Modulations- und Codierungseffizienz ermöglicht es HDT-Geräten, Durchsatz und Robustheit entsprechend den Betriebsanforderungen und Kanalbedingungen aufeinander abzustimmen.

Die verbindlich vorgeschriebenen Übertragungsraten HDT2, HDT3 und HDT4 bilden eine gemeinsame Interoperabilitätsgrundlage für HDT-fähige Geräte. Modi mit höheren Übertragungsraten steigern den Durchsatz durch den Einsatz der 16QAM-Modulation und einen reduzierten Codierungs-Overhead noch weiter, sodass die Bluetooth-Technologie Bitraten von bis zu 7,5 Mb/s unterstützen kann.

3.2.2.2 Synchronisation und Robustheit

Modulationsverfahren höherer Ordnung erfordern im Allgemeinen eine genauere Synchronisation und Kanalschätzung als herkömmliche GFSK-basierte Kommunikation. Um einen zuverlässigen Betrieb bei höheren Bitraten zu gewährleisten, führt HDT mehrere Mechanismen auf PHY-Ebene ein, die die Paketerfassung, Kanalschätzung, Empfängerverfolgung und periodische Resynchronisation während des gesamten Empfangsprozesses unterstützen. Tabelle 3.2.2.2 fasst die wichtigsten von HDT eingeführten Synchronisations- und Robustheitsmechanismen zusammen.

Mechanismus	Zusammenfassung
Kurze Trainingssequenz (STS)	• Ermöglicht eine schnelle Erkennung des ersten Pakets, eine grobe zeitliche Abstimmung und das Einpendeln der AGC • Erscheint in der Präambel, ganz am Anfang jedes HDT-Pakets, und wird mehrmals hintereinander wiederholt • Stellt einen zuverlässigen Einstiegspunkt in das Paket her
Lange Trainingssequenz (LTS)	• Ermöglicht die Feinabstimmung der Zeit, die Schätzung und Korrektur des Frequenzversatzes sowie die anfängliche Kanalschätzung • Erscheint auch in der Präambel von HDT-Paketen nach „STS“ und wird mehrmals hintereinander wiederholt • Bereitet den Empfänger auf die kohärente Demodulation vor
Guard-Intervall (GI)	• Zeitpuffer zum Ausgleich transienter Effekte, die durch den Wechsel zwischen Trainingssequenzen, Symbolströmen sowie Modulations- oder Codierungsgrenzen entstehen • Erscheint explizit in der Präambel zwischen STS und LTS sowie implizit im gesamten Paket durch Abschlusssymbole • Ermöglicht es Empfängerfiltern und Timing-Schleifen, sich vor der feinen LTS-Synchronisation einzupendeln, und gewährleistet saubere Übergänge zwischen Symbolströmen
Abschlusszeichen	• Schafft explizite Grenzen zwischen Symbolströmen und dämpft transiente Effekte bei Übergängen zwischen Symbolströmen • Erscheint am Ende jedes unabhängig verarbeiteten Symbolstroms in einem Paket (z. B. nach dem Control-Header, nach der PDU-Header-Zone, nach jedem PHY-Intervall im Paketformat 1 usw.) • Ermöglicht es dem FEC-Decoder, den Zustand zu löschen und zurückzusetzen, bevor das nächste Segment/der nächste Strom beginnt • Besonders wichtig für das Paketformat 1, um die Fehlerausbreitung zu begrenzen, eine teilweise Paketwiederherstellung zu ermöglichen und den Aufwand für Wiederholungsübertragungen zu reduzieren, wenn Fehler auf ein einzelnes PHY-Intervall beschränkt sind
PHY-Intervalle	• Ermöglicht die Aufteilung langer Nutzdaten in kleinere und leichter zu verarbeitende Dekodierungseinheiten • Kommt ausschließlich in der Nutzdatenzone von HDT-Paketen im Paketformat 1 (PF1) vor • Aktiviert adaptive Modulation und dynamische Ratenauswahl
PHY-Intervalltrainingssequenz (PITS)	• Aktiviert das Retraining während des Pakets, um die Phasen- und Kanalschätzung zu aktualisieren und so einen robusten Empfang von Nutzdaten zu gewährleisten, die in mehrere PHY-Intervalle segmentiert sind • Tritt ausschließlich in der Nutzdatenzone von HDT-Paketen im Paketformat 1 (PF1) auf • Wichtig für lange Nutzdaten, die mit hohen Bitraten übertragen werden, bei denen sich die Kanalbedingungen über die Dauer des Pakets hinweg ändern können; die kontinuierliche Kanalverfolgung verbessert die Widerstandsfähigkeit gegenüber Fading, Phasendrift und Mehrwegausbreitung

Zusammen bilden diese Mechanismen ein mehrschichtiges Synchronisationsframework. STS und LTS unterstützen die anfängliche Paketerfassung und Kanalschätzung, während PHY-Intervalle und PITS die periodische Kanalverfolgung und die Aktualisierung der Synchronisation während längerer Übertragungen mit hohem Durchsatz ermöglichen. Terminierungssymbole unterstützen die zuverlässige Vervollständigung von Paketen und Zustandsübergänge des Empfängers.

Durch die Integration dieser Mechanismen kann HDT auch unter wechselnden Funkbedingungen eine zuverlässige Kommunikation gewährleisten und gleichzeitig einen deutlich höheren Durchsatz als bisherige Bluetooth® LE-PHYs bieten.

3.2.3 HDT-Paket

Die HDT-PHY bildet die Grundlage für einen deutlich höheren Datendurchsatz. Um jedoch einen zuverlässigen und effizienten Betrieb bei diesen Bitraten zu gewährleisten, sind auch entsprechende Verbesserungen an der Bluetooth-Paketarchitektur erforderlich. Bluetooth® High Data Throughput (HDT) führt ein neues Paket-Framework ein, das adaptive Bitraten, die Übertragung großer Nutzdatenmengen, selektive Wiederholungsübertragungen und eine verbesserte Robustheit unter wechselnden Funkbedingungen unterstützt. Im Gegensatz zu herkömmlichen Bluetooth® LE-Paketen verfügen HDT-Pakete über zusätzliche strukturelle Ebenen, die eine unabhängige Verarbeitung von Steuerinformationen, Protokoll-Metadaten und Nutzdaten ermöglichen und gleichzeitig erweiterte Funktionen für Durchsatz und Zuverlässigkeit bieten.

3.2.3.1 Aufbau eines HDT-Pakets

Wie in Abbildung 3.2.3.1 dargestellt, besteht die HDT-Paketstruktur aus vier Hauptbereichen: einer Präambel, einem Steuerheader, einem optionalen PDU-Header-Bereich und einem optionalen Nutzdatenbereich. Die Präambel und der Steuerheader sind in allen HDT-Paketformaten vorhanden, während der PDU-Header-Bereich und der Nutzdatenbereich je nach verwendetem Paketformat vorhanden sind.

Im Großen und Ganzen erfüllt jede Zone einen bestimmten Zweck:

Präambel

Bietet Funktionen zur Paketerkennung, Synchronisation, Zeitmessung, Frequenzversatzkorrektur und Kanalschätzung, die für einen zuverlässigen HDT-Empfang erforderlich sind. Diese Funktionen werden in Abschnitt 3.2.2 näher beschrieben.

Steuerkopf

Enthält wichtige Informationen, die zur Identifizierung des Pakets und zur Festlegung der weiteren Verarbeitung des Paketinhaltes erforderlich sind. Durch die Trennung dieser Informationen von den Hochgeschwindigkeits-Nutzdaten wird eine zuverlässige Paketauswertung ermöglicht, noch bevor die Demodulation der Nutzdaten beginnt.

PDU-Kopfzeilenbereich

Enthält Metadaten auf Protokollebene, die zur Interpretation und Verwaltung von Nutzdaten dienen. Diese Metadaten unterstützen Funktionen wie die Aggregation von Nutzdaten, die Verarbeitung von Bestätigungen, die selektive Neuübertragung, Rückmeldungen zur Verbindungsqualität, die Flusskontrolle sowie die zukünftige Erweiterbarkeit des Protokolls.

Nutzlastzone

Enthält Benutzerdaten, die in einem oder mehreren Blöcken organisiert sind. Das Paketformat 0 enthält nur einen einzigen Block. Im Paketformat 1 können Nutzdaten in logische Blöcke unterteilt werden, um eine effiziente Fehlerbehebung und selektive Neuübertragung zu ermöglichen.

3.2.3.2 HDT-Paketformate

Um ein breites Spektrum an Bluetooth-Anwendungen und Datenverkehrsmustern zu unterstützen, definiert HDT drei Paketformate. Jedes Format ist auf ein anderes Gleichgewicht zwischen Durchsatz, Robustheit und Protokoll-Overhead optimiert.

Kurzform

Das Kurzformat ist eine minimalistische Paketstruktur, die verwendet wird, wenn keine Nutzdaten übertragen werden. Es ist in erster Linie für Bestätigungen, Synchronisation und Steuersignale vorgesehen und minimiert so den Sendezeitverbrauch und den Protokoll-Overhead. Die Struktur des Kurzformat-Pakets ist in Abbildung 3.2.3.2a dargestellt.

Paketformat 0 (PF0)

Das Paketformat 0 ist für die Übertragung eines einzelnen Nutzdatenblocks mit minimalem Overhead optimiert. Es eignet sich gut für kleine und mittelgroße Datenübertragungen, bei denen keine Segmentierung der Nutzdaten und keine erweiterten Wiederholungsmechanismen erforderlich sind. Die Struktur des Paketformats 0 ist in Abbildung 3.2.3.2b dargestellt.

Paketformat 1 (PF1)

Das Paketformat 1 ist das leistungsfähigste HDT-Paketformat und wurde für maximalen Durchsatz und die Übertragung großer Nutzdatenmengen entwickelt. Neben der Unterstützung wesentlich größerer Datenübertragungen bietet PF1 Funktionen wie Nutzdatenaggregation, blockbasierte Übertragung, selektive Neuübertragung, verbesserten Header-Schutz sowie Robustheitsmechanismen auf PHY-Ebene. Die Struktur des Paketformats 1 ist in Abbildung 3.2.3.2c dargestellt.

Tabelle 3.2.3.2 enthält einen Vergleich und eine Zusammenfassung der drei Paketformate.

	Kurz	PF0	PF1
Maximale Nutzlast	K.A.	494 Oktette	8175 Oktette
Nützlich für		Höherer Durchsatz	Höchster Durchsatz, höchste Effizienz und/oder höchste Robustheit
Vorteile Vorteile	• Reduziert die Sendezeit, wenn keine Nutzdaten zum Senden vorhanden sind und wenn nur aufeinanderfolgende vollständige Nutzdatenbestätigungen erforderlich sind	• Einfachere Implementierung • Geringerer Overhead • Ein einziger Payload-Block mit MIC	• Bis zu vier Nutzdaten in einem Paket • Aufteilung der Nutzdaten in Blöcke • Selektive (Block-)Bestätigung • Nutzdatenblöcke können sich über mehrere Pakete erstrecken • PHY-Intervalle, Phasenverfolgung mittels PITS

3.2.3.3 Aggregation und Zuverlässigkeit von Nutzdaten

Eine der wichtigsten Innovationen des Paketformats 1 (PF1) ist seine Fähigkeit, große Datenmengen effizient zu übertragen und dabei eine robuste Funkleistung aufrechtzuerhalten. Um dies zu erreichen, führt PF1 die Nutzdatenaggregation, blockbasierte Übertragung, selektive Neuübertragung und verbesserte Fehlerschutzmechanismen ein. Zusammen ermöglichen diese Funktionen HDT eine deutliche Verbesserung des Durchsatzes bei gleichzeitiger Minimierung der Auswirkungen von Paketverlusten und sich ändernden Funkbedingungen. Abbildung 3.2.3.3 veranschaulicht die PDU-Komponenten, die diese Funktionen innerhalb eines HDT-Pakets unterstützen.

Während das Paketformat 0 einen einzelnen Nutzdatenblock enthält, können beim Paketformat 1 bis zu vier unabhängige Nutzdatenblöcke in einer einzigen Paketübertragung zusammengefasst werden. Diese Funktion reduziert den Protokoll-Overhead und verbessert die Kanalauslastung, da mehrere Nutzdatenblöcke gemeinsam übertragen werden können.

Um die Effizienz weiter zu steigern, führt PF1 ein blockbasiertes Nutzdatenmodell ein. Anstatt die gesamte Nutzdatenmenge als eine einzige Übertragungseinheit zu behandeln, kann jede Nutzdatenmenge in ein bis sechzehn logische Blöcke unterteilt werden. Diese Blöcke können unabhängig voneinander beschrieben, übertragen und nachverfolgt werden, wodurch große Nutzdatenmengen effizienter verwaltet werden können.

Die blockbasierte Übertragung ermöglicht eine selektive Wiederholung. Anhand zusätzlicher Paket-Metadaten können Sender und Empfänger feststellen, welche Nutzdatenblöcke erfolgreich empfangen wurden und welche erneut gesendet werden müssen. Treten Übertragungsfehler auf, müssen nur die betroffenen Blöcke erneut gesendet werden, während korrekt empfangene Blöcke beibehalten werden können. Dieser Ansatz reduziert den Aufwand für die Wiederholung im Vergleich zur erneuten Übertragung der gesamten Nutzdaten erheblich.

PF1 erhöht zudem die Zuverlässigkeit durch zusätzliche Schutzmechanismen. Jeder übertragene Block umfasst eine unabhängige Integritätsprüfung, wodurch einzelne Blöcke verifiziert werden können, ohne dass eine Validierung der gesamten Nutzlast erforderlich ist. Darüber hinaus bietet das Paketformat 1 einen speziellen Schutz für Protokoll-Metadaten durch die Header-Fehlerprüfung für die PDU-Header-Zone (HEC-P), wodurch eine zuverlässige Interpretation der Informationen zur Nutzlastverwaltung gewährleistet wird.

Die Paketarchitektur unterstützt zudem erweiterte Funktionen zur Verbindungsverwaltung durch optionale Protokollmetadaten. Informationen zur Verbindungsqualität, darunter Kennzahlen wie Signalstärke, Signal-Rausch-Verhältnis (SNR) und Empfehlungen zur bevorzugten Übertragungsrate, können ausgetauscht werden, um einen besseren Einblick in die aktuellen Kanalbedingungen zu ermöglichen. Die Architektur unterstützt darüber hinaus die Signalisierung zur Flusssteuerung, wodurch Geräte das Übertragungsverhalten der Nutzdaten dynamisch steuern können, wenn Puffer- oder Verarbeitungsressourcen knapp werden.

Schließlich ist PF1 so konzipiert, dass es mit Mechanismen auf PHY-Ebene wie PHY-Intervallen und PHY-Intervall-Trainingssequenzen (PITS) zusammenarbeitet, die in Abschnitt 3.2.2 beschrieben werden. Diese Mechanismen ermöglichen eine periodische Neusynchronisierung des Empfängers während langer Übertragungen und tragen dazu bei, eine robuste Kommunikation unter Bedingungen wie Fading, Phasendrift und anderen zeitabhängigen Kanalbedingungen aufrechtzuerhalten.

Durch die Kombination von Nutzdatenaggregation, logischen Blöcken, selektiver Neuübertragung, verbessertem Metadatenschutz und Robustheitsmechanismen auf PHY-Ebene bildet das Paketformat 1 die Grundlage für eine effiziente und zuverlässige Bluetooth-Kommunikation mit hohem Durchsatz.

3.2.4 Bluetooth®-HDT-Verbindungsschicht

Zwar bilden die HDT-PHY- und die Paketarchitektur die Grundlage für einen deutlich höheren Durchsatz, doch erfordert die Gewährleistung eines zuverlässigen Betriebs bei diesen Bitraten auch entsprechende Erweiterungen der Bluetooth® LE-Verbindungsschicht. Anstatt eine separate Protokollarchitektur einzuführen, erweitert HDT die bestehende Bluetooth® LE-Verbindungsschicht um neue Verfahren, Funktionen und Steuerungsmechanismen, die eine Kommunikation mit hohem Durchsatz innerhalb des etablierten Bluetooth® LE-Rahmens ermöglichen.

Zusammen unterstützen diese Erweiterungen die Aushandlung von HDT-Fähigkeiten, das PHY-Management, den Nutzlasttransport, die Ratenanpassung, die Sicherheit, die Zuverlässigkeit und die isochrone Kommunikation. Die Verbindungsschicht bietet den operativen Rahmen, der das Durchsatzpotenzial der HDT-PHY in praktische Verbesserungen hinsichtlich Effizienz, Robustheit und Anwendungsleistung umsetzt.

Tabelle 3.2.4 fasst die wichtigsten Funktionsbereiche der Link-Schicht zusammen, die zur Unterstützung von HDT eingeführt wurden.

Fähigkeit	Beschreibung
HDT-Initiierung und PHY-Verwaltung	Ermöglicht die Aktivierung von HDT, die Aushandlung der Funktionsfähigkeit sowie den Wechsel zwischen GFSK- und HDT-Betrieb
Verwaltung der HDT-Datenlänge und -Planung	Unterstützt größere Nutzdatenmengen unter Einhaltung der zeitlichen und planerischen Anforderungen von Bluetooth® LE
HDT-Verbindungsqualität	Bietet Funktionen zur dynamischen Erfassung und Anpassung der Verbindungsqualität
HDT und isochrone Kanäle	Erweitert die Unterstützung für CIS- und BIS-Transport im HDT-Betrieb
HDT-Sicherheit und Verschlüsselung	Integriert EKS, längere MICs und koordinierte Schlüsselverwaltung
Zuverlässigkeit und Durchflussregelung bei HDT	Aktiviert Zuverlässigkeitsmechanismen auf Blockebene und eine verbesserte Flusssteuerung

Die folgenden Abschnitte bieten einen allgemeinen Überblick über die wichtigsten Funktionen der Link-Schicht, die durch diese Verfahren ermöglicht werden.

3.2.4.1 Einleitung einer Bluetooth®-HDT-Verbindung und PHY-Verwaltung

Bluetooth® HDT wird über Verfahren der Verbindungsschicht initiiert und verwaltet, die über Bluetooth® LE-Verbindungen ablaufen. Sobald die HDT-Fähigkeiten zwischen den Geräten eingerichtet sind, kann der HDT-Betrieb für ACL-Verbindungen, Connected Isochronous Streams (CIS) und Broadcast Isochronous Streams (BIS) genutzt werden. Die HDT-PHY wird nicht für die Bekanntgabe verwendet und muss stets über spezielle Verfahren der Verbindungsschicht aktiviert werden.

Der Prozess beginnt mit dem HDT-Konfigurationsaustauschverfahren, bei dem die neuen Steuer-PDUs „LL_HDT_CONFIG_REQ“ und „LL_HDT_CONFIG_RSP“ zum Einsatz kommen. Im Rahmen dieses Verfahrens tauschen die Geräte HDT-spezifische Funktionen und Betriebsparameter aus, darunter unterstützte HDT-Raten, Payload-Fenster-Funktionen, sicherheitsrelevante Parameter sowie weitere Informationen, die für die Einrichtung des HDT-Betriebs erforderlich sind.

Anstatt eine einzelne Betriebsrate auszuhandeln, legen die Geräte einen Bereich unterstützter HDT-Raten fest. Während des Betriebs kann der Controller je nach aktuellen Kanalbedingungen, Implementierungsrichtlinien und Anwendungsanforderungen dynamisch eine beliebige Rate innerhalb des ausgehandelten Bereichs auswählen. Dieses Modell mit adaptiver Rate ermöglicht es, Durchsatz und Robustheit in Einklang zu bringen, ohne dass eine zusätzliche Neukonfiguration der Verbindung erforderlich ist.

Sobald die Funktionen ausgetauscht wurden, können Geräte mithilfe des Verfahrens „PHY-Update und Verschlüsselungsaktualisierung“ zwischen GFSK-PHYs und dem HDT-PHY wechseln. Dieses Verfahren erweitert die bestehenden Steuer-PDUs LL_PHY_REQ, LL_PHY_RSP und LL_PHY_UPDATE_IND. Dadurch können HDT-fähige Geräte dynamisch in den HDT-Betrieb wechseln, diesen ändern oder verlassen, während eine aktive Bluetooth® LE-Verbindung aufrechterhalten bleibt.

Der Übergang vom GFSK-PHY- zum HDT-Betrieb erfordert zudem die Einrichtung von HDT-spezifischen Adressierungsinformationen für den physikalischen Kanal. Während dieses Vorgangs tauschen die Geräte Informationen zur physikalischen Kanaladresse (PCA) aus, die den HDT-Datenverkehr auf dem physikalischen Kanal eindeutig identifiziert. Die PCA unterstützt die Paketfilterung, die Synchronisation und den Empfang von HDT-Übertragungen und ist dabei weiterhin mit der bestehenden Bluetooth® LE-Verbindungsarchitektur abgestimmt.

Im Normalbetrieb werden in beiden Richtungen einer Verbindung entweder GFSK-PHYs oder der HDT-PHY verwendet. Die HDT-Übertragungsraten können jedoch in jeder Richtung unabhängig voneinander ausgewählt werden, wodurch sich der Durchsatz dynamisch an wechselnde Kanalbedingungen und Anwendungsanforderungen anpassen lässt. Sollte der HDT-Betrieb nicht verfügbar oder nicht mehr wünschenswert sein, kann die Kommunikation unter Verwendung herkömmlicher Bluetooth-LE-PHYs fortgesetzt werden.

3.2.4.2 Verwaltung und Planung der Datenlänge bei Bluetooth® HDT

Bluetooth HDT bietet erweiterte Funktionen zur Verwaltung der Datenlänge, um Nutzdaten zu unterstützen, die wesentlich größer sind als die im herkömmlichen Bluetooth® LE-Betrieb verwendeten, und dabei gleichzeitig die für Bluetooth-Verbindungen und isochrone Datenströme erforderlichen Zeitsteuerungseigenschaften beizubehalten.

Um dies zu erreichen, verwaltet die Link-Schicht separate Parameter für die Übertragungslänge und das Timing für den HDT- und den GFSK-Betrieb. Dadurch kann jede PHY-Familie entsprechend ihren jeweiligen Nutzdaten- und Sendezeitbeschränkungen arbeiten und gleichzeitig nahtlose Übergänge zwischen HDT und älteren Bluetooth-LE-Modi unterstützen.

HDT führt außerdem Funktionen zur Verwaltung von Nutzdatenfenstern ein, die es ermöglichen, mehrere Nutzdaten innerhalb einer einzigen HDT-Übertragung zu bündeln. Im Rahmen der HDT-Konfigurationsverfahren tauschen Geräte Informationen über die Funktionen der Nutzdatenfenster aus, die festlegen, wie Nutzdaten gruppiert und übertragen werden können. Diese Funktionen wirken zusammen mit den in Abschnitt 3.2.3 beschriebenen Mechanismen zur Nutzdatenbündelung und blockbasierten Übertragung, um die Kanalauslastung und die Übertragungseffizienz zu verbessern.

Da HDT-Pakete erheblich größere Datenmengen transportieren können als herkömmliche Bluetooth-LE-Pakete, werden zusätzliche Planungsbeschränkungen eingeführt, um die Sendezeit der Pakete zu begrenzen und die Koexistenz mit ACL-Verbindungen, CISs, BISs und anderen gleichzeitig stattfindenden Bluetooth-Aktivitäten zu gewährleisten. Diese Planungsmechanismen stellen sicher, dass ein höherer Durchsatz erzielt werden kann, ohne das vorhersehbare Zeitverhalten von Bluetooth LE zu beeinträchtigen.

Das erweiterte Verfahren zur Aktualisierung der Datenlänge unter Verwendung von LL_LENGTH_REQ [v2] und LL_LENGTH_RSP [v2] ermöglicht es Geräten, die maximalen Längen der Sende- und Empfangsnutzdaten zusammen mit den zugehörigen Zeitparametern zu übermitteln. Durch die Einhaltung PHY-spezifischer Grenzwerte ermöglicht HDT den Controllern, den Durchsatz zu maximieren und gleichzeitig die Kompatibilität mit der Verbindungsereignis-Planung, dem isochronen Betrieb und Multi-Link-Aktivitäten zu gewährleisten.

3.2.4.3 Verbindungsqualität bei Bluetooth®-HDT

HDT führt eine optionale Funktion zur Rückmeldung der Verbindungsqualität (Link Quality Feedback, LQF) ein, die es Geräten ermöglicht, während des Betriebs Echtzeitinformationen über die Kanalbedingungen auszutauschen. Ist diese Funktion aktiviert, können Informationen zur Verbindungsqualität kontinuierlich zwischen den Geräten ausgetauscht werden, wodurch die Controller einen besseren Einblick in die aktuellen Funkbedingungen erhalten.

Diese Berichte können sowohl Messungen der Signalqualität als auch Empfehlungen zur bevorzugten Betriebsrate enthalten, wodurch die Steuerungen fundiertere Anpassungsentscheidungen treffen können. Je nach Implementierungsrichtlinie und den gemessenen Kanalbedingungen können die Steuerungen die HDT-Betriebsraten anpassen, das Übertragungsverhalten ändern oder zwischen HDT- und GFSK-Betrieb umschalten.

Das Verfahren „HDT Link Quality Enable“ nutzt die neue Steuer-PDU „LL_HDT_LQF_REPORTING_IND“, um die Berichterstattung zur Verbindungsqualität (Link Quality Feedback, LQF) zu aktivieren oder zu deaktivieren. LQF kann für ACL- und CIS-Transporte unabhängig voneinander konfiguriert werden, sodass verschiedene Verkehrstypen bei Bedarf von der Berücksichtigung der Kanalqualität profitieren können.

Durch die direkte Einblicke in die aktuellen Kanalbedingungen ermöglicht LQF eine effizientere Nutzung des Betriebs mit adaptiver Übertragungsrate und trägt dazu bei, die Leistungsvorteile von HDT in einer Vielzahl von Funkumgebungen optimal zu nutzen.

3.2.4.4 Zuverlässigkeit und Flusssteuerung bei Bluetooth®-HDT

HDT führt verbesserte Zuverlässigkeitsmechanismen ein, die darauf ausgelegt sind, die Übertragung großer Nutzdatenmengen effizient zu unterstützen. Aufbauend auf der blockbasierten Nutzdatenarchitektur von Packet Format 1 (PF1) ergänzt HDT das herkömmliche Bestätigungsverhalten von Bluetooth® LE durch Wiederherstellungsmechanismen auf Blockebene.

Die herkömmlichen Bluetooth-LE-Verfahren zur Sequenznummerierung und Bestätigung gewährleisten weiterhin die Reihenfolge der Pakete und die kumulative Bestätigung. HDT erweitert dieses Modell durch die selektive Bestätigung von Nutzdatenblöcken. Dies reduziert den Overhead bei der erneuten Übertragung erheblich, wenn große Datenmengen übertragen werden.

HDT bietet zudem erweiterte Funktionen zur Flusssteuerung. Anhand der in den HDT-Paket-Headern enthaltenen Informationen kann ein Empfangsgerät die Übertragung neuer Nutzdaten vorübergehend unterbrechen, wenn zusätzliche Puffer- oder Verarbeitungsressourcen benötigt werden. Die Wiederholungsübertragung kann während dieses Zeitraums fortgesetzt werden, sodass Zuverlässigkeitsmaßnahmen weiterlaufen können, während gleichzeitig eine Überlastung des Empfängers verhindert wird.

Sobald Ressourcen verfügbar werden, wird die normale Übertragung der Nutzdaten wieder aufgenommen, ohne dass ein Eingriff auf einer höheren Schicht oder eine Neukonfiguration der Verbindung erforderlich ist. Zusammen tragen diese Mechanismen zur Steigerung der Effizienz und zur Aufrechterhaltung der Zuverlässigkeit bei und helfen HDT dabei, unter anspruchsvollen Betriebsbedingungen einen hohen Durchsatz aufrechtzuerhalten.

3.2.4.5 Typische Verfahren und Steuerungsnachrichten der Bluetooth®-HDT-Verbindungsschicht

Die oben beschriebenen Funktionen der Verbindungsschicht werden durch eine Reihe neuer und erweiterter Prozeduren und Steuerungsnachrichten umgesetzt. Tabelle 3.2.4.5 fasst repräsentative Prozeduren der Verbindungsschicht und die zugehörigen LL-Steuerungs-PDUs zusammen, die zum Aufbau, zur Verwaltung, zur Sicherung und zur Optimierung des HDT-Betriebs verwendet werden.

Vorgehensweise	Wichtigste Funktionen	Typische LL-Control-PDUs
HDT-Konfigurationsaustausch	Nutzdatenfenster, Übertragungsraten, ACL/CIS-HDT-Parameter	LL_HDT_CONFIG_REQ / LL_HDT_CONFIG_RSP
HDT-Verbindungsqualität aktivieren	Berichterstattung zu ACL/CIS-Rückmeldungen	LL_HDT_LQF_REPORTING_IND
Verschlüsselung – Beginn mit dem Schlüsselplan	Einrichtung von EKS	LL_ENC_ECDH_REQ / LL_ENC_ECDH_RSP
Aktualisierung der Datenlänge	PHY-spezifische Nutzdaten- und Sendezeitbeschränkungen	LL_LENGTH_REQ [v2] / LL_LENGTH_RSP [v2]
PHY-Aktualisierung und Verschlüsselungsaktualisierung	PHY-Übergänge, PCA-Zuweisung, MIC-Aktualisierung, Schlüsselaktualisierung	LL_PHY_REQ [v2], LL_PHY_RSP [v2], LL_PHY_UPDATE_IND [v2]
Erstellung eines vernetzten isochronen Streams	Einrichtung eines HDT-fähigen CIS	LL_CIS_REQ [v2], LL_CIS_IND [v2]

Zusammen bilden diese Verfahren den erforderlichen Signalrahmen, um den HDT-Betrieb zu aktivieren, zu verwalten, zu sichern und zu optimieren, wobei die Kompatibilität mit der bestehenden Bluetooth-LE-Link-Layer-Architektur gewahrt bleibt. Sie veranschaulichen zudem, wie HDT etablierte Bluetooth-LE-Verfahren erweitert, anstatt sie zu ersetzen, wodurch ein höherer Durchsatz in das Bluetooth-Ökosystem integriert werden kann, während die architektonische Konsistenz und Interoperabilität erhalten bleiben.

3.2.5 Bluetooth®-HDT-HCI-Schicht

Die Host-Controller-Schnittstelle (HCI) dient als primäre Steuerungs- und Statusschnittstelle zwischen dem Host und dem Controller. Zur Unterstützung des HDT-Betriebs führt Bluetooth® LE neue HCI-Befehle und -Ereignisse ein und erweitert gleichzeitig mehrere bestehende Mechanismen. Diese Erweiterungen ermöglichen es Hosts, HDT-Fähigkeiten zu erkennen, Betriebseinstellungen zu konfigurieren, PHY-Übergänge zu überwachen, Sicherheitsfunktionen zu verwalten und HDT-fähige isochrone Transporte zu steuern.

Entsprechend der Bluetooth-Architektur verbleiben die meisten HDT-spezifischen Funktionen im Controller. Zeitkritische Funktionen wie PHY-Übergänge, Ratenanpassung, Wiederholungsübertragung und Paketplanung werden weiterhin autonom vom Controller ausgeführt, während die HCI die Informationen und Steuerungsmöglichkeiten bereitstellt, die für die Konfiguration von Richtlinien, die Diagnose und die Anwendungserkennung erforderlich sind. Dadurch bleibt die traditionelle Trennung zwischen der Entscheidungsfindung durch den Host und der Ausführung durch den Controller erhalten, während Anwendungen gleichzeitig von den HDT-Funktionen profitieren können.

Die für HDT erforderlichen HCI-Erweiterungen lassen sich in sechs Kategorien einteilen: Erkennung und Konfiguration von Funktionen, PHY-Verwaltung, Durchsatzverwaltung, Sicherheitsverwaltung, Verwaltung des isochronen Transports sowie Test und Diagnose. Tabelle 3.2.5 fasst die wichtigsten HCI-Funktionsbereiche im Zusammenhang mit der HDT-Unterstützung zusammen.

Fähigkeit	Beschreibung
Ermittlung und Konfiguration von Funktionen	Entdecken Sie die Funktionen von HDT und passen Sie die Einstellungen an
Auswahl der PHY-Schicht und Koordination des Übergangs	HDT-PHY-Betrieb anfordern und überwachen
Verwaltung von Datenlänge und Durchsatz	Nutzdaten-Limits und durchsatzbezogene Parameter konfigurieren
Sicherheits- und Verschlüsselungsmanagement	EKS-bezogene Funktionen verwalten und den Verschlüsselungsstatus überwachen
Isochrones Transportmanagement	HDT-fähige CIS- und BIS-Transporte konfigurieren und überwachen
Prüfung und Diagnose	Unterstützung bei der Validierung, Fehlerbehebung und Analyse der Verbindungsqualität

Die folgenden Abschnitte bieten einen allgemeinen Überblick über die wichtigsten HCI-Funktionen, die zur Unterstützung von HDT eingeführt wurden.

3.2.5.1 Ermittlung und Konfiguration von Funktionen

Bevor Bluetooth® HDT genutzt werden kann, muss der Host die vom lokalen und vom entfernten Controller unterstützten Funktionen ermitteln und die Betriebseinstellungen konfigurieren, die für zukünftige Verbindungen gelten sollen. HDT-fähige Controller stellen Informationen zu unterstützten PHY-Modi, HDT-Übertragungsraten, maximalen Nutzlastgrößen, zeitlichen Einschränkungen und HDT-bezogenen Sicherheitsfunktionen bereit. Anhand dieser Informationen können Anwendungen feststellen, ob der HDT-Betrieb für einen bestimmten Anwendungsfall geeignet ist, und entsprechende Betriebsrichtlinien festlegen.

Über die HCI kann der Host außerdem Standard-HDT-Betriebseinstellungen festlegen. Zu diesen Einstellungen können bevorzugte HDT-Raten, unterstützte Paketformate, Nutzdatenfenster-Fähigkeiten und sicherheitsrelevante Parameter gehören. Zu den typischen Schnittstellen gehören der Befehl „LE Set HDT Default Parameters “ sowie erweiterte Verfahren zur Meldung von Fähigkeiten wie beispielsweise „LE Read Maximum Data Length“.

Anstatt den Betrieb auf Paketebene direkt zu steuern, gibt der Host das gewünschte Betriebsverhalten vor, während er Echtzeitentscheidungen dem Controller überlässt. So können Hosts beispielsweise bevorzugte HDT-Ratenbereiche für ACL- und isochrone Übertragungen angeben oder eine Präferenz für ein bestimmtes Paketformat äußern. Im tatsächlichen Betrieb bleibt der Controller für die Ratenanpassung, die Paketschedulierung und andere zeitkritische Entscheidungen verantwortlich. Dieser Ansatz bietet Flexibilität und vermeidet gleichzeitig eine unnötige Einbindung des Hosts in die Ausführung auf der Verbindungsschicht.

3.2.5.2 Auswahl der PHY-Schicht und Koordination des Übergangs

Die PHY-Auswahl und PHY-Übergänge stellen einen der sichtbarsten Aspekte des Bluetooth®-HDT-Betriebs auf der HCI-Schicht dar. Hosts können über bestehende Mechanismen zur PHY-Auswahl angeben, ob sie den Betrieb über den HDT-PHY unterstützen oder diesem den Vorzug geben. Solche Anfragen vermitteln das gewünschte Betriebsverhalten, während der Controller weiterhin dafür verantwortlich ist, zu bestimmen, ob der HDT-Betrieb erfolgreich hergestellt werden kann.

Wenn ein PHY-Wechsel stattfindet – sei es beim Eintritt in den HDT-Betrieb oder beim Verlassen desselben –, meldet der Controller das Ergebnis über HCI-Ereignisse. Diese Benachrichtigungen ermöglichen es den Hosts, die Auswahl des aktiven PHY zu überwachen, das Anwendungsverhalten anzupassen und die Erwartungen hinsichtlich des Durchsatzes zu steuern, ohne dass detaillierte Kenntnisse über die Ausführung auf der Verbindungsschicht erforderlich sind. Zu den repräsentativen Schnittstellen gehören der Befehl „LE Set PHY“ und das erweiterte Ereignis „LE PHY Update Complete“, die Einblick in den nach einem PHY-Wechsel resultierenden Betriebsmodus bieten.

Da die Auswahl der HDT-Rate weiterhin unter der Kontrolle des Controllers steht, konzentriert sich die HCI-Berichterstattung auf das Ergebnis der PHY-Auswahl und des PHY-Betriebs und nicht auf die von der Verbindungsschicht getroffenen Entscheidungen auf Paketebene. Dadurch bleibt die traditionelle Trennung zwischen den Richtlinien des Hosts und der Ausführung durch den Controller gewahrt.

3.2.5.3 Verwaltung von Datenlänge und Durchsatz

Die durch Bluetooth® HDT ermöglichten größeren Nutzdatenmengen und höheren Durchsätze erfordern entsprechende Verbesserungen der Konfigurations- und Überwachungsfunktionen auf HCI-Ebene. Hosts können nutzdatenbezogene Betriebsparameter konfigurieren und die Fähigkeiten des Controllers abfragen, um den Durchsatz zu optimieren und dabei die Koexistenz- und Zeitbeschränkungen der Implementierung einzuhalten.

Zusätzlich zu den herkömmlichen Informationen zur Nutzdatenlänge werden in den HDT-Fähigkeitsberichten die Fähigkeiten des Nutzdatenfensters, die maximale Kapazität für Empfangspakete sowie weitere durchsatzbezogene Betriebsparameter offengelegt. Diese Informationen bieten einen besseren Einblick in das Durchsatzpotenzial eines Controllers und helfen Anwendungen dabei, fundierte Entscheidungen hinsichtlich Pufferung, Zeitplanung und Ressourcenzuweisung für Datenübertragungen mit hoher Bandbreite zu treffen.

HDT trennt weiterhin politische Entscheidungen von der Ausführung auf der Link-Schicht. Der Host kann bevorzugte Betriebsgrenzen konfigurieren und ausgehandelte Fähigkeiten überwachen, während der Controller weiterhin für die Paketaggregation, die Segmentierung der Nutzdaten, das Wiederholungsmanagement und die Scheduling-Entscheidungen während des aktiven Betriebs verantwortlich ist. Dieser Ansatz ermöglicht es Anwendungen, von größeren Nutzdatenmengen und einem höheren Durchsatz zu profitieren, ohne dass dabei zusätzliche Protokollkomplexität auf Host-Ebene entsteht.

Änderungen an den ausgehandelten Nutzlastkapazitäten können über das erweiterte LE-Ereignis „Data Length Change“ gemeldet werden, wodurch der Host stets über die tatsächlichen Betriebsgrenzen aktiver Verbindungen informiert bleibt. Zusammen mit „LE Set Data Length“ und „LE Read Maximum Data Length“ bilden diese Schnittstellen das primäre HCI-Framework für das Durchsatzmanagement in HDT-fähigen Systemen.

3.2.5.4 Sicherheits- und Verschlüsselungsmanagement

Die in Abschnitt 3.2.6 beschriebenen Sicherheitsverbesserungen für Bluetooth® HDT werden über eine Reihe von HCI-Steuerelementen und Statusmechanismen bereitgestellt, die es Hosts ermöglichen, Funktionen im Zusammenhang mit dem Encryption Key Schedule (EKS) zu konfigurieren und zu überwachen, wobei die Kompatibilität mit der bestehenden Bluetooth® LE-Sicherheitsarchitektur gewahrt bleibt.

Zu den typischen Schnittstellen gehören die Befehle „LE Read Encryption Key Schedule Debug Mode “ und „LE Write Encryption Key Schedule Debug Mode “. Diese Befehle sind in erster Linie für Entwicklungs-, Test- und Interoperabilitätsprüfungsumgebungen vorgesehen und wirken sich auf nachfolgende Verbindungen aus, ohne den Sicherheitsstatus aktiver verschlüsselter Sitzungen zu ändern.

Weitere HCI-Verbesserungen bieten Einblick in die Auswahl der MIC-Länge, die EKS-Nutzung und die Verfahren zur Aktualisierung der Verschlüsselung. Befehle wie „LE Enable Encryption [v2]“ und „Refresh Encryption Key [v2]“ ermöglichen es Hosts in Verbindung mit Ereignissen wie „Encryption Change [v3]“ und „Encryption Key Refresh Complete [v2]“, sicherheitsrelevante Zustandsübergänge im Zusammenhang mit dem HDT-Betrieb zu überwachen.

Diese Schnittstellen stellen sicher, dass Anwendungen stets über den Sicherheitsstatus und Konfigurationsänderungen informiert sind, ohne dass eine direkte Einbindung in die zugrunde liegenden Sicherheitsverfahren der Link-Schicht erforderlich ist. Wie bei anderen HDT-Funktionen verwaltet der Controller weiterhin zeitkritische Sicherheitsvorgänge, während der Host den Überblick über deren Ergebnis und Betriebsstatus behält.

3.2.5.5 Isochrones Transportmanagement

Bluetooth® HDT erweitert die isochrone Kommunikation von Bluetooth LE und erfordert daher eine entsprechende HCI-Unterstützung für Connected Isochronous Groups (CIGs), Connected Isochronous Streams (CISs) und Broadcast Isochronous Streams (BISs). Die zugehörigen HCI-Schnittstellen ermöglichen es Hosts, HDT-fähige Transporte zu konfigurieren und dabei das etablierte isochrone Verwaltungsmodell von Bluetooth LE beizubehalten.

Diese Schnittstellen unterstützen HDT-spezifische Betriebseinstellungen, darunter HDT-Raten, die Auswahl des Paketformats, Nutzdatenkapazitäten und die Konfiguration der MIC-Länge. Mithilfe dieser Mechanismen können Anwendungen das Transportverhalten an Anforderungen hinsichtlich Durchsatz, Latenz, Zuverlässigkeit und Sicherheit anpassen und gleichzeitig die Kompatibilität mit bestehenden Bluetooth-LE-Verfahren gewährleisten. Zu den repräsentativen Konfigurationsschnittstellen gehören „LE Set CIG Parameters“ [v2] und „LE Create BIG“ [v2].

Sobald die Verfahren zur Einrichtung des Transports abgeschlossen sind, meldet der Controller die daraus resultierenden Betriebsmerkmale über erweiterte Statusereignisse. Schnittstellen wie „LE CIS Established [v3]“ und „LE Create BIG Complete [v2]“ bieten Einblick in die HDT-gestützte Transporterstellung und ermöglichen es den Hosts, die Konfigurationsergebnisse zu überprüfen und das Anwendungsverhalten entsprechend anzupassen.

Anstatt ein völlig neues Steuerungsmodell einzuführen, erweitert HDT die bestehenden Mechanismen zur isochronen Verwaltung und ermöglicht es Anwendungen so, von einem deutlich höheren Durchsatz zu profitieren, während das den Bluetooth-Entwicklern bereits vertraute Betriebsumfeld beibehalten wird.

3.2.5.6 Prüfung und Diagnose

Neben den betrieblichen Kontrollfunktionen bietet Bluetooth® HDT HCI-Funktionen, die der Validierung, Leistungsmessung, Interoperabilitätsanalyse und Fehlerbehebung bei der Implementierung dienen. Diese Funktionen ermöglichen Einblicke in die HDT-spezifischen Betriebseigenschaften und vereinfachen die Bewertung der Controller-Leistung unter verschiedenen Funkbedingungen und Datenverkehrsmustern.

Über Test- und Diagnoseschnittstellen lassen sich Controller mit HDT-spezifischen Testparametern konfigurieren und es stehen Mechanismen zur Erstellung von Berichten über die erfassten Messwerte zur Verfügung, einschließlich Informationen zur HDT-Verbindungsqualität und zum PHY-Betrieb. Diese Funktionen unterstützen die Produktentwicklung, Zertifizierungstests, die Leistungscharakterisierung und die Überprüfung der Interoperabilität zwischen verschiedenen Implementierungen.

Zu den repräsentativen Schnittstellen, die mit dieser Funktion verbunden sind, gehören der Befehl „LE Set HDT Parameters Test “ und das Ereignis „LE Test Report HDT Link Quality “. Zusammen bieten diese Mechanismen Entwicklern und Testingenieuren Zugriff auf die Informationen, die zur Bewertung und Optimierung von HDT-Implementierungen erforderlich sind.

3.2.5.7 Typische Bluetooth®-HDT-HCI-Befehle und -Ereignisse

Die oben beschriebenen HCI-Erweiterungen werden durch eine Kombination aus neuen und erweiterten Befehlen und Ereignissen realisiert. Tabelle 3.2.5.7 fasst repräsentative Schnittstellen zusammen, die den einzelnen HDT-Funktionsbereichen zugeordnet sind, und veranschaulicht, wie Hosts mit HDT-fähigen Controllern interagieren.

Fähigkeit	Typische Befehle und Ereignisse
Ermittlung und Konfiguration von Funktionen	LE: HDT-Standardparameter festlegen, LE: Maximale Datenlänge auslesen
Auswahl der PHY-Schicht und Koordination des Übergangs	LE-Set-PHY, LE-PHY-Aktualisierung abgeschlossen
Verwaltung von Datenlänge und Durchsatz	LE-Datensatzlänge festlegen, Änderung der LE-Datenlänge
Sicherheits- und Verschlüsselungsmanagement	LE-Verschlüsselung aktivieren [v2], Verschlüsselungsschlüssel aktualisieren [v2], Verschlüsselungsänderung [v3], Aktualisierung des Verschlüsselungsschlüssels abgeschlossen [v2], Debug-Modus für den Zeitplan zum Lesen/Schreiben des LE-Verschlüsselungsschlüssels
Isochrones Transportmanagement	LE CIG-Parameter festlegen [v2], LE BIG erstellen [v2], LE CIS eingerichtet [v3], LE BIG-Erstellung abgeschlossen [v2]
Prüfung und Diagnose	LE-Test zur Einstellung der HDT-Parameter, LE-Testbericht: Ereignis zur HDT-Verbindungsqualität

Zusammen bilden diese Befehle und Ereignisse die primäre Verwaltungsschnittstelle zwischen dem Host und dem Controller für den HDT-Betrieb. Sie ermöglichen es Anwendungen, die Funktionen des Controllers zu ermitteln, Betriebseinstellungen zu konfigurieren, den Systemstatus zu überwachen und HDT-fähige Transporte zu verwalten, wobei die etablierte architektonische Trennung zwischen den Richtlinien des Hosts und der Ausführung durch den Controller gewahrt bleibt.

3.2.6 Sicherheit bei Bluetooth®-HDT

Bluetooth HDT baut auf der bestehenden Bluetooth® LE-Sicherheitsarchitektur auf und führt gleichzeitig mehrere Verbesserungen ein, die darauf ausgelegt sind, eine Kommunikation mit hohem Durchsatz zu unterstützen. Diese Verbesserungen stärken die Schlüsselverwaltung, verbessern den Integritätsschutz und stimmen die Sicherheitsverfahren enger auf den PHY-Betrieb ab.

Anstatt eine eigenständige Sicherheitsarchitektur zu definieren, erweitert HDT die etablierten Bluetooth-LE-Sicherheitsmechanismen durch die Einführung des „Encryption Key Schedule“ (EKS), die Unterstützung längerer „Message Integrity Check“ (MIC)-Längen sowie koordinierte Sicherheitsverfahren im Zusammenhang mit dem PHY-Betrieb. Zusammen bieten diese Verbesserungen die von HDT geforderten Sicherheitsfunktionen und bauen gleichzeitig auf Mechanismen auf, die auch von anderen Bluetooth-Funktionen und Anwendungsfällen genutzt werden können.

3.2.6.1 Verbesserter Schutz der Nachrichtenintegrität

Bei der herkömmlichen Bluetooth® LE-Kommunikation kommt eine 32-Bit-Nachrichtenintegritätsprüfung (MIC) zum Einsatz. HDT unterstützt zusätzlich MIC-Längen von 64 Bit und 128 Bit und bietet damit einen stärkeren Schutz vor Paketmanipulationen, Fälschungen und Übertragungsfehlern bei der Übertragung größerer Datenmengen.

3.2.6.2 Sicherheitsbewusste PHY-Übergänge

Bluetooth® HDT integriert das Sicherheitsmanagement durch das Verfahren „PHY Update and Encryption Refresh“ enger in den PHY-Betrieb. Anstatt PHY-Übergänge und Verschlüsselungsaktualisierungen als unabhängige Vorgänge zu behandeln, ermöglicht dieses Verfahren den Geräten, PHY-Änderungen bei Bedarf mit den entsprechenden Sicherheitsaktualisierungen zu koordinieren.

Dieser koordinierte Ansatz ermöglicht es den Geräten, zwischen dem GFSK- und dem HDT-Betrieb zu wechseln, wobei die sichere Kommunikation aufrechterhalten und Betriebsunterbrechungen auf ein Minimum reduziert werden. Durch die Synchronisierung der PHY- und der Sicherheitszustandsverwaltung können sich die Geräte an veränderte Betriebsanforderungen anpassen, ohne dass eine erneute Verbindungsherstellung oder eine Unterbrechung der Dienste höherer Schichten erforderlich ist.

Änderungen der MIC-Länge erfordern eine entsprechende Schlüsselaktualisierung, um sicherzustellen, dass der Sicherheitsstatus weiterhin mit der gewählten Schutzstufe übereinstimmt. Gleichzeitig können Schlüsselaktualisierungen unabhängig von PHY-Übergängen erfolgen, was Flexibilität bietet und gleichzeitig einen hohen Sicherheitsschutz gewährleistet.

Das Verfahren wird durch erweiterte Versionen von LL_PHY_REQ, LL_PHY_RSP und LL_PHY_UPDATE_IND unterstützt, die die für die Koordination des PHY-Betriebs und die Verwaltung des Sicherheitszustands erforderlichen Signale bereitstellen.

3.2.6.3 Kompatibilität der Sicherheitsarchitektur

Da Bluetooth® HDT die bestehenden Bluetooth® LE-Sicherheitsmechanismen erweitert, anstatt sie zu ersetzen, ermöglicht es Herstellern, verbesserte Sicherheitsfunktionen zu nutzen und gleichzeitig die Interoperabilität mit dem gesamten Bluetooth-Ökosystem zu wahren. Dieser Ansatz vereinfacht die Einführung und ermöglicht es Produkten, von den HDT-Funktionen zu profitieren, ohne dass ein grundlegend anderes Sicherheitsmodell erforderlich ist.

3.3 Zusammenfassung

Bluetooth® High Data Throughput (HDT) erweitert Bluetooth® LE um eine neue, hocheffiziente physikalische Schicht, die Datenraten von bis zu 7,5 Mb/s unterstützt und dabei vollständig in die bestehende Bluetooth-Architektur integriert bleibt. Durch Verbesserungen an der PHY, der Paketarchitektur, der Verbindungsschicht, der HCI und dem Sicherheitsframework ermöglicht HDT einen deutlich höheren Durchsatz, wobei die Interoperabilität, Effizienz und Flexibilität bei der Bereitstellung von Bluetooth LE erhalten bleiben.

Zusammen bilden diese Verbesserungen eine skalierbare Grundlage für zukünftige Bluetooth-Anwendungen, die eine deutlich höhere Datenkapazität erfordern, darunter Audiosysteme der nächsten Generation, Wearables, industrielle Lösungen und andere neue Anwendungsfälle. HDT zeigt, wie sich Bluetooth LE weiterentwickeln kann, um den wachsenden Anforderungen an die Bandbreite gerecht zu werden und gleichzeitig die Kompatibilität mit dem bestehenden Bluetooth-Ökosystem zu gewährleisten.

4. Bluetooth® LE – Isochrones Parameter-Update (IPU)

4.1 Hintergrund

4.1.1 Statische CIS-Konfigurationen und Einschränkungen

Bluetooth® LE Audio führte Connected Isochronous Streams (CIS) als Transportmechanismus für zeitkritische Anwendungen ein. Während des Aufbaus eines CIS werden Transportparameter wie PHY-Auswahl, ISO_Interval, Burst-Nummer (BN), Flush-Timeout (FT), maximale SDU-Größe (Max_SDU) und Transportlatenz zwischen den Geräten ausgehandelt und bleiben für die gesamte Lebensdauer des Streams unverändert. Dieses Modell vereinfacht die Zeitplanung und sorgt für ein vorhersehbares Zeitverhalten bei der isochronen Kommunikation.

In der Praxis ändern sich die Betriebsbedingungen jedoch häufig, während ein Datenstrom aktiv ist. Die Funkqualität kann aufgrund von Störungen, Mobilität oder sich ändernden Umgebungsbedingungen schwanken, und Anwendungen können zwischen Betriebsmodi mit unterschiedlichen Anforderungen an Latenz, Zuverlässigkeit, Durchsatz oder Stromverbrauch wechseln. Daher lässt sich das Transportverhalten nicht immer effizient mithilfe einer einzigen statischen CIS-Konfiguration optimieren.

Vor der Einführung des Bluetooth® LE Isochronous Parameter Update (IPU) erforderte die Anpassung an diese sich ändernden Anforderungen in der Regel die Beendigung des bestehenden CIS und die Einrichtung eines neuen Datenstroms mit aktualisierten Parametern. Dieser Ansatz ist zwar funktional wirksam, kann jedoch zu Dienstunterbrechungen führen, zusätzliche Systemneukonfigurationen erfordern und nahtlose Übergänge zwischen den Betriebsmodi erschweren.

4.1.2 Einführung in die Laufzeitanpassung

Bluetooth® LE Isochronous Parameter Update (IPU) behebt diese Einschränkungen, indem es die Aktualisierung von Transportparametern ermöglicht, während ein CIS aktiv bleibt. Anstatt die CIS-Konfiguration als einmalige Einstellungsentscheidung zu betrachten, ermöglicht IPU den Geräten, während der gesamten Laufzeit eines Datenstroms zwischen alternativen Betriebskonfigurationen zu wechseln.

Diese Funktion ermöglicht es Bluetooth®-Systemen, das Übertragungsverhalten an sich ändernde Funkbedingungen, Anwendungsanforderungen und Betriebsmodi anzupassen, ohne dass eine erneute Herstellung der Datenverbindung erforderlich ist. Durch die Unterstützung koordinierter Übergänge bei der Laufzeitkonfiguration verbessert die IPU die Flexibilität und gewährleistet gleichzeitig die Kontinuität und Synchronisation, die für isochrone Anwendungen erforderlich sind.

In den folgenden Abschnitten werden die Entwurfsprinzipien, die Konfigurationsarchitektur und die Laufzeitmechanismen beschrieben, die dieses neue Transportanpassungsmodell ermöglichen.

4.2 Bluetooth®-IPU-Entwicklungskonzept

4.2.1 Von statischen Streams zur Laufzeitkonfigurationsverwaltung

Traditionell bleiben die Transportparameter eines Connected Isochronous Stream (CIS) nach dessen Einrichtung unverändert. Wenn sich die Betriebsanforderungen erheblich ändern, kann die Anpassung des Transports daher erfordern, den aktiven CIS zu beenden und einen neuen CIS mit anderen Parametern einzurichten. Dieser Ansatz gewährleistet zwar die erforderlichen Transporteigenschaften, kann jedoch zu Dienstunterbrechungen und einer zusätzlichen Neukonfiguration des Systems führen.

Die IPU führt ein alternatives Modell ein, bei dem die Transportparameter eines aktiven CIS aktualisiert werden können, ohne den Datenstrom zu ersetzen. Wenn sich die Funkbedingungen, Anwendungsanforderungen oder Systemrichtlinien ändern, können Geräte eine geeignete vordefinierte Konfiguration auswählen und eine koordinierte Aktualisierung durchführen, während das CIS aktiv bleibt. Dadurch wird die Transportanpassung vom Aufbau des Datenstroms getrennt, und Geräte können auf sich ändernde Anforderungen reagieren, ohne den Datenstrom neu aufbauen zu müssen.

Abbildung 4.2.1 vergleicht die Wiederherstellung von Streams mit dem durch die IPU ermöglichten Laufzeit-Aktualisierungsmodell.

4.2.2 Ein konfigurationsorientiertes Anpassungsmodell

Die Bluetooth®-IPU unterstützt die Laufzeitanpassung mithilfe einer Reihe vordefinierter CIG-Konfigurationen. Jede Konfiguration stellt einen definierten Betriebspunkt für die CISs innerhalb der CIG dar und enthält die für diesen Betriebspunkt erforderlichen Transportparameter. Eine Implementierung kann mehrere Konfigurationen bereitstellen, um unterschiedlichen Anwendungsanforderungen, Funkbedingungen oder Systemrichtlinien gerecht zu werden.

Während des Betriebs wird eine dieser Konfigurationen ausgewählt, um das Transportverhalten der aktiven CIS zu definieren. Wenn sich die Bedingungen ändern, kann eine andere Konfiguration ausgewählt und über das IPU-Verfahren angewendet werden. Die Konfigurationen stellen somit verfügbare Transport-Betriebspunkte dar, während die aktive CIS der permanente Transport bleibt, auf den die ausgewählte Konfiguration angewendet wird.

Abbildung 4.2.2 veranschaulicht den Zusammenhang zwischen Laufzeit-Treibern, vordefinierten Konfigurationen, der ausgewählten Konfiguration und dem aktiven CIS.

4.2.3 Auslegung mehrerer Betriebspunkte

Die für ein CIG bereitgestellten Konfigurationen können so ausgelegt sein, dass sie unterschiedliche Transportziele erfüllen. So kann beispielsweise eine Konfiguration den Durchsatz in den Vordergrund stellen, eine andere die Transportlatenz verringern und eine weitere unter schwierigen Funkbedingungen für höhere Robustheit sorgen. Welcher Konfigurationssatz geeignet ist, hängt von den Betriebsmodi und den Anpassungsanforderungen ab, die das Produkt unterstützt.

Anstatt für jeden Parameter oder Anwendungsfall ein eigenes Aktualisierungsverfahren zu definieren, bietet die IPU einen einheitlichen Mechanismus für den Übergang zwischen diesen vordefinierten Betriebspunkten. Die Parameter, die sich zwischen den Konfigurationen unterscheiden, bestimmen die von einer Aktualisierung betroffenen Transportaspekte, während das IPU-Verfahren koordiniert, wann und wie die ausgewählte Konfiguration aktiv wird.

In den folgenden Abschnitten wird beschrieben, wie diese Konfigurationen identifiziert und organisiert werden, wie die Zuständigkeiten für Aktualisierungen zwischen Host und Controller aufgeteilt sind und wie sich verschiedene Parameteränderungen auf den Betrieb des CIS auswirken.

4.3 Bluetooth®-IPU-Architektur und Schlüsselkonzepte

4.3.1 Warum es mehrere Konfigurationen gibt

Moderne Bluetooth®-Geräte werden häufig unter Bedingungen betrieben, die unterschiedliche Übertragungseigenschaften erfordern. Schwankungen in der Funkqualität, im Anwendungsverhalten, bei den Leistungsbeschränkungen oder bei den Latenzanforderungen können jeweils einen anderen Betriebspunkt für die Übertragung begünstigen.

Anstatt einzelne Transportparameter bei jeder Änderung der Bedingungen anzupassen, fasst IPU das Transportverhalten in einer Reihe vordefinierter Konfigurationen zusammen. Jede Konfiguration stellt einen vollständigen Betriebspunkt dar, der ausgewählt und auf einen aktiven Connected Isochronous Stream (CIS) angewendet werden kann.

Dieser Ansatz vereinfacht die Anpassung zur Laufzeit, indem Aktualisierungen als Übergänge zwischen vordefinierten Konfigurationen behandelt werden und nicht als eigenständige Änderungen einzelner Transportparameter.

Tabelle 4.3.1 enthält Beispiele für Betriebsanforderungen, die unterschiedliche Transportkonfigurationen erfordern können, und veranschaulicht, warum eine einzige statische CIS-Konfiguration unter Umständen nicht unter allen Betriebsbedingungen optimal ist.

Betriebsanforderung	Beispiel für ein Transportziel
Musikwiedergabe	Höherer Durchsatz und bessere Audioqualität
Sprachkommunikation	Geringere Übertragungslatenz
Wiederherstellung der HF-Leistung nach Leistungsabfall	Erhöhte Zuverlässigkeit
Betrieb mit Leistungsbeschränkung	Verminderte Radioaktivität

4.3.2 Organisation von Laufzeitkonfigurationen

Die Unterstützung mehrerer Betriebskonfigurationen macht ein Konfigurationsmanagement erforderlich. IPU organisiert Konfigurationen anhand eines hierarchischen Modells, das verwandte Betriebspunkte zusammenfasst. Jede Konfiguration wird durch eine „Config_ID“ identifiziert, wobei Konfigurationen auch anhand von „Config_Group_ID“- und „Transport Latency Group (TL_Group)“-Kennungen organisiert werden können.

Auf der obersten Ebene sind Konfigurationen einer „Connected Isochronous Group“ (CIG) zugeordnet. Innerhalb einer CIG können Konfigurationen entsprechend ihrer Transportlatenz-Eigenschaften in TL_Groups organisiert werden. Innerhalb einer TL_Group bieten Config_Groups die Möglichkeit, Konfigurationen zu gruppieren, die verwandte Transport-Betriebspunkte unterstützen. Einzelne Konfigurationen innerhalb einer Config_Group werden anhand ihrer Config_ID identifiziert.

Diese Struktur ermöglicht es einem Gerät, mehrere vordefinierte Betriebspunkte beizubehalten und bietet gleichzeitig einen strukturierten Mechanismus zur Auswahl von Konfigurationen während der Laufzeitanpassung. Sowohl vom Host erstellte als auch vom Controller autonom erstellte Konfigurationen können innerhalb dieses Rahmens verwaltet werden.

Wie in Abbildung 4.3.2 dargestellt, führt IPU ein mehrschichtiges Organisationsmodell ein, bei dem die latenzbezogene Gruppierung von den einzelnen Transportkonfigurationen getrennt ist. Anstatt Konfigurationen als voneinander unabhängige Parametersätze zu betrachten, ist es oft sinnvoll, sie als Elemente eines größeren Konfigurationsraums zu betrachten, der die möglichen Betriebsmodi einer CIG definiert.

4.3.3 Warum Transport-Latenzgruppen wichtig sind

Die Übertragungslatenz ist ein wichtiges Merkmal der isochronen Übertragung, da sich Änderungen der Übertragungslatenz auf das Pufferverhalten, den Zeitablauf der Darstellung und die Verarbeitungsanforderungen auf Anwendungsebene auswirken können.

IPU organisiert Konfigurationen daher mithilfe von Transport-Latenz-Gruppen (TL_Groups). Konfigurationen innerhalb derselben TL_Group weisen dieselben Transport-Latenz-Eigenschaften auf, während Konfigurationen, die verschiedenen TL_Groups zugeordnet sind, unterschiedliche Transport-Latenz-Modelle darstellen.

Diese Organisation ist bei Laufzeitübergängen von Bedeutung, da die Behandlung von Nutzdaten während eines Updates zum Teil davon abhängt, ob der Übergang innerhalb derselben TL_Group bleibt oder eine TL_Group-Grenze überschreitet.

4.3.4 Verantwortlichkeiten des Hosts und des Verantwortlichen

Nicht alle Konfigurationsänderungen haben denselben Umfang oder dieselben Auswirkungen. Manche Aktualisierungen wirken sich nur auf den Betrieb der Verbindungsschicht aus, während andere die Transportlatenz, die Pufferungsannahmen oder das Verhalten auf Anwendungsebene beeinflussen können.

IPU trägt dieser Unterscheidung Rechnung, indem es die Zuständigkeiten zwischen dem Host und dem Controller trennt.

Der Host ist für Anpassungsentscheidungen auf Anwendungsebene zuständig, einschließlich der Auswahl oder Anforderung einer Transportkonfiguration auf der Grundlage von Anwendungsanforderungen, Betriebsmodus, Qualitätszielen oder Systemrichtlinien. Der Controller ist für die Ausführung des entsprechenden Aktualisierungsvorgangs und die Koordination des Transportwechsels verantwortlich.

Durch diese Trennung kann die IPU sowohl anwendungsgesteuerte als auch controller-gesteuerte Anpassungen unterstützen. So kann beispielsweise der Host eine Konfigurationsänderung einleiten, wenn eine Anwendung den Betriebsmodus wechselt, während der Controller die Transportparameter autonom an sich ändernde Funkbedingungen oder andere Bedingungen auf der Verbindungsschicht anpassen kann.

Wie in Abbildung 4.3.4 dargestellt, entscheidet der Host, warum und wann ein Transportwechsel stattfinden soll, während der Controller für die Koordination und Durchführung des Wechsels zuständig ist.

4.3.5 Dimensionen der Anpassung

Eines der charakteristischen Merkmale von Bluetooth® IPU ist, dass die Laufzeitanpassung nicht auf einen einzigen Transportparameter beschränkt ist. Verschiedene Konfigurationen können unterschiedliche Aspekte des CIS-Verhaltens beeinflussen, darunter die Funkleistung, die Übertragungsfrequenz, die Zuverlässigkeit, die Latenz und die Ereignisplanung.

Aus architektonischer Sicht lassen sich diese Veränderungen anhand einer kleinen Reihe von Anpassungsdimensionen verstehen.

Anpassungsziel	Beispielparameter
PHY / Link-Anpassung	PHY, Übertragungsrate, Wiederholungsparameter
Bitrate-Anpassung	Max_SDU
Flexibilität bei der Terminplanung	Ankerpunkt, ISO_Intervall
Latenzanpassung	Transportlatenz, TL_Group
Anpassung der Betriebsart	Konfigurationsänderungen im Zusammenhang mit unterschiedlichen Anwendungsanforderungen

Wie aus Tabelle 4.3.5 hervorgeht, können IPU-Konfigurationen die Anpassung an verschiedene Transportziele unterstützen. Eine Konfigurationsänderung kann sich je nach gewähltem Betriebspunkt auf einen oder mehrere Parameter gleichzeitig auswirken. Dies bietet einen gemeinsamen Rahmen für die Anpassung des Funkverhaltens, der Bitrate, der Zeitplanung, der Latenz und der Anwendungsbetriebsmodi.

Obwohl in der Spezifikation zahlreiche Aktualisierungsszenarien definiert sind, lassen sich die meisten davon als Variationen innerhalb dieser Anpassungsdimensionen verstehen. Diese Perspektive bietet einen nützlichen Rahmen, um zu verstehen, wie sich unterschiedliche Parameteränderungen auf den Betrieb des CIS auswirken, ohne jede mögliche Aktualisierungskombination einzeln untersuchen zu müssen.

In den folgenden Abschnitten wird beschrieben, wie IPU Übergänge zwischen diesen Dimensionen koordiniert und dabei die Synchronisation sowie die Kontinuität der Nutzdaten gewährleistet.

4.4 Konfigurationslebenszyklus und Laufzeitkoordination

4.4.1 Konfigurationslebenszyklus

Eines der zentralen Konzepte, das mit der Bluetooth®-IPU eingeführt wurde, ist die Trennung der Konfigurationsdefinition von der Konfigurationsaktivierung. Konfigurationen werden nicht erst bei der Herstellung einer CIS erstellt, sondern können unabhängig vom aktiven Transport definiert, bereitgestellt und verwaltet werden.

Jede bereitgestellte Konfiguration stellt einen vollständigen Transport-Betriebspunkt für eine Connected Isochronous Group (CIG) dar. Eine Konfiguration kann PHY-Auswahlen, ISO-Timing-Eigenschaften, das Scheduling-Verhalten, Wiederholungsparameter, Transport-Latenz-Eigenschaften sowie zugehörige Synchronisationsinformationen definieren. Konfigurationen werden durch eindeutige Config_ID-Werte identifiziert und können vor dem Aufbau einer CIS bereitgestellt werden.

Um sowohl die vom Host als auch die vom Controller verwaltete Konfigurationsbereitstellung zu unterstützen, werden die Config_ID-Werte in separate Zuweisungsbereiche unterteilt. Die Konfigurationsdefinition ist vom Laufzeit-Aktualisierungsverfahren getrennt. Konfigurationen können im Voraus definiert und bereitgestellt werden, sodass bei einer erforderlichen Änderung des Betriebspunkts das Aktualisierungsverfahren eine vorhandene Konfiguration aktivieren kann, anstatt im Rahmen des Übergangs eine neue Konfiguration zu definieren. Config_ID-Werte von 0x01 bis 0x7F werden vom Host zugewiesen, während Werte von 0x80 bis 0xFF vom Controller eigenständig zugewiesen werden können. Diese Trennung verhindert Konflikte und ermöglicht gleichzeitig sowohl anwendungsgesteuerte als auch controllergesteuerte Anpassungsmodelle.

Sobald eine Konfiguration bereitgestellt wurde, steht sie zur Auswahl während der Laufzeit zur Verfügung und kann später aktiviert werden, wenn sich die betrieblichen Anforderungen ändern. Da die Konfigurationsdefinition von der Stream-Erstellung entkoppelt ist, können innerhalb eines CIG mehrere Konfigurationen nebeneinander bestehen und bleiben während der gesamten Lebensdauer des Streams verfügbar.

Diese Trennung zwischen Konfigurationsmanagement und Verbindungsaufbau ist ein grundlegendes architektonisches Merkmal der IPU. Im Gegensatz zu früheren CIS-Implementierungen, bei denen die Transportparameter nach Abschluss des Verbindungsaufbaus praktisch feststanden, ermöglicht die IPU eine Anpassung des Transportverhaltens durch die Auswahl aus vordefinierten Betriebspunkten.

Infolgedessen wird die Anpassung des Transports zu einem Prozess der Konfigurationsauswahl und -aktivierung statt der Konfigurationserstellung, wodurch sich das CIS an veränderte Anforderungen anpassen kann, ohne neu eingerichtet werden zu müssen.

4.4.2 Koordinierte Aktualisierungen der Laufzeitkonfiguration

Obwohl sich Konfigurationsänderungen letztlich auf einzelne CIS-Transportparameter auswirken, wird die Durchführung der Aktualisierung auf CIG-Ebene koordiniert. Dadurch können mehrere CIS, die zur selben CIG gehören, einen einheitlichen Übergang vollziehen und während des gesamten Aktualisierungsprozesses synchronisiert bleiben.

Die Laufzeitanpassung beginnt, sobald ein Gerät feststellt, dass ein anderer Transport-Betriebspunkt für die aktuellen Betriebsbedingungen besser geeignet ist. Der Anlass für eine Konfigurationsänderung kann in Übergängen zwischen verschiedenen Anwendungsbetriebsmodi, Änderungen der Funkbedingungen, Latenzanforderungen, Zuverlässigkeitszielen oder Anpassungsrichtlinien auf Systemebene liegen.

Die Festlegung einer Zielkonfiguration führt nicht sofort zu einer Änderung des aktiven CIS. Bevor die neue Konfiguration wirksam werden kann, müssen beide Geräte den Übergang über das Bluetooth®-IPU-Aktualisierungsverfahren koordinieren.

Diese Koordination stellt sicher, dass sich die beteiligten Geräte vor der Aktivierung des Updates über die Zielkonfiguration und die damit verbundenen Transporteigenschaften einigen. Durch die Trennung der Konfigurationsauswahl von der Aktivierung ermöglicht IPU, dass Anpassungsentscheidungen unabhängig von den zeitlichen Vorgaben getroffen werden können, die für einen sicheren Transportübergang erforderlich sind.

Im gängigsten Einsatzmodell wählt die Zentrale eine Zielkonfiguration aus und leitet einen CIS-Aktualisierungsvorgang ein. IPU unterstützt auch von Peripheriegeräten ausgehende Aktualisierungsanforderungen, wodurch ein Peripheriegerät signalisieren kann, dass ein anderer Transport-Betriebspunkt wünschenswert sein könnte, wobei die Zentrale weiterhin die endgültige Entscheidung über die Aktualisierung trifft.

Unabhängig vom Initiator folgen Aktualisierungen demselben Koordinationsmodell und werden letztendlich an einer synchronisierten Aktualisierungsgrenze aktiviert. Während dieses gesamten Prozesses bleibt das CIS bestehen und steht für den weiteren Betrieb zur Verfügung. Dadurch kann sich das Transportverhalten weiterentwickeln, ohne dass bei Änderungen der Betriebsanforderungen eine Beendigung und erneute Herstellung des Datenstroms erforderlich ist.

4.4.3 Aktivierung und Synchronisierung auf Instant-Basis

Eine Konfigurationsaktualisierung wird nicht sofort nach ihrer Anforderung wirksam. Stattdessen wird die neue Konfiguration zu einem vordefinierten Aktivierungspunkt, der als „Instant“ bezeichnet wird, aktiv.

„The Instant“ bietet eine gemeinsame Synchronisationsgrenze, die es beiden Geräten ermöglicht, gleichzeitig auf die aktualisierte Konfiguration umzustellen. Ohne eine koordinierte Aktivierung könnte ein Gerät bereits mit den aktualisierten Transportparametern arbeiten, bevor das andere Gerät dazu bereit ist, was möglicherweise zu Inkonsistenzen bei der Zeitplanung, einer Fehlausrichtung der Nutzdaten oder einem vorübergehenden Synchronisationsverlust führen könnte.

Aus diesem Grund wird im Rahmen des Aktualisierungsvorgangs zunächst eine Einigung über die Zielkonfiguration und den Zeitpunkt ihrer Aktivierung erzielt, bevor die Umstellung vorgenommen wird. Beide Geräte arbeiten bis zum vereinbarten Zeitpunkt mit der aktuellen Konfiguration weiter; zu diesem Zeitpunkt wird die ausgewählte Konfiguration aktiv.

Der gleiche auf „Instant“ basierende Ansatz wird auch dann verwendet, wenn Aktualisierungen durch Anpassungen des Anker-Offsets Auswirkungen auf die zeitliche Platzierung von CIS-Ereignissen haben. In diesen Szenarien verändert die Aktualisierung nicht nur die Transportmerkmale, sondern auch die zeitliche Position zukünftiger CIS-Ereignisse. Durch die Planung der Änderung zu einem vordefinierten „Instant“ behalten beide Controller eine konsistente Sicht auf die Zeitachse der Ereignisse nach der Aktualisierung.

Anpassungen der Ankerpunkte können auch ohne Änderung der aktiven Config_ID vorgenommen werden. In diesen Fällen ändert die Aktualisierung die Platzierung zukünftiger CIS-Ereignisse, während die zugrunde liegende Transportkonfiguration unverändert bleibt. Dies ermöglicht eine Optimierung der Zeitplanung und eine zeitliche Neuausrichtung unabhängig von etwaigen Änderungen der Transportparameter.

Durch die Kopplung der Konfigurationsaktivierung an eine gemeinsame CIS-Ereignisgrenze stellt die Bluetooth®-IPU sicher, dass beide Controller deterministisch auf das neue Zeitmodell umstellen, unabhängig davon, welche Transportparameter aktualisiert werden. Unabhängig davon, ob sich die Änderung auf den Durchsatz, das Wiederholungsverhalten, die Transportlatenz oder die zukünftige Ereignispositionierung auswirkt, gilt stets dasselbe Synchronisationsprinzip.

Obwohl mit dem Erreichen des „Instant“-Zustands der Aktivierungsprozess der Konfiguration abgeschlossen ist, sind zusätzliche Mechanismen erforderlich, um die Kontinuität der Nutzdaten und die zeitliche Konsistenz während des Übergangs zu gewährleisten. Diese Mechanismen gewinnen besonders dann an Bedeutung, wenn sich die aktualisierte Konfiguration auf das Transporttiming, die Latenzcharakteristika, das Scheduling-Verhalten oder die Übermittlung der Nutzdaten auswirkt.

4.5 Gewährleistung der Kontinuität bei Konfigurationswechseln

4.5.1 Laufzeitübergang und Kontinuität

Die Aktivierung einer neuen Konfiguration zum Zeitpunkt der Aktualisierung bedeutet nicht zwangsläufig, dass alle mit der vorherigen Konfiguration verbundenen Transportvorgänge bereits abgeschlossen sind. Je nach den aktualisierten Parametern können mit der vorherigen Konfiguration verbundene Nutzdaten auch nach dem Zeitpunkt der Aktualisierung noch in der Übertragung sein.

Bluetooth® IPU bietet daher Mechanismen zur Koordinierung der Nutzdatenverarbeitung über den Konfigurationswechsel hinweg. Mithilfe von „Transition Payloads“ und „Flush Points“ kann der Controller die Synchronisation aufrechterhalten und feststellen, wann der mit der vorherigen Konfiguration verbundene Transportstatus aufgehoben werden kann. Die Aktivierung einer neuen Konfiguration ist nur ein Schritt bei einer IPU-Aktualisierung.

4.5.2 Verwaltung von Nutzlasten während des Übergangs

Ein CIS-Update kann stattfinden, während die mit der vorherigen Konfiguration verbundenen Nutzdaten noch verarbeitet werden. Die Bluetooth® IPU definiert „Transition Payloads“ und „Post-Transition Payloads“, um die Verarbeitung der Nutzdaten während des Update-Zeitpunkts zu steuern.

Übergangs-Nutzdaten sind dem CIS-Referenzankerteilpunkt vor dem Aktualisierungszeitpunkt zugeordnet. Ihre Behandlung hängt von den Eigenschaften der Aktualisierung ab und davon, ob die Aktualisierung die Transportlatenzgruppe ändert oder die maximale Paketnutzdatengröße verringert.

Wenn durch das Update die TL_Group_ID geändert oder der Wert von Max_Packet_Payload verringert wird, werden die Übergangs-Nutzdaten zum Zeitpunkt des Updates geleert. Dadurch wird sichergestellt, dass Nutzdaten, die der vorherigen Transportkonfiguration zugeordnet sind, nicht weiterhin ein Transportmodell verwenden, das nach dem Übergang nicht mehr gültig ist.

Bei anderen Aktualisierungsszenarien wird der Flush-Punkt gemäß den geltenden CIS-Aktualisierungsregeln bestimmt. Dadurch können Übergangs-Payloads über den Aktualisierungszeitpunkt hinweg weiterverarbeitet werden, während die SDU-Synchronisation aufrechterhalten bleibt.

„Post-Transition“-Nutzdaten verwenden den „Update Instant“ als Referenzankepunkt für das CIS. Ihre Behandlung ist besonders dann von Bedeutung, wenn das ISO_Interval verkürzt wird, da Nutzdaten, die mit der neuen Konfiguration verbunden sind, möglicherweise anhand des aktualisierten Ereigniszeitpunkts eingeplant werden müssen.

Zusammen ermöglichen diese Mechanismen es der IPU, zwischen Konfigurationen zu wechseln und dabei die Synchronisation aufrechtzuerhalten sowie die mit beiden Seiten des Update-Zeitpunkts verbundenen Nutzdaten angemessen zu verwalten.

4.6 Protokollerweiterungen

4.6.1 Erweiterungen der Host-Controller-Schnittstelle

Obwohl Bluetooth® IPU bedeutende neue Laufzeitfunktionen einführt, sind die daraus resultierenden Protokolländerungen relativ überschaubar. Der Großteil der zusätzlichen Funktionen konzentriert sich auf eine kleine Gruppe von HCI-Befehlen und -Ereignissen, die die Konfigurationsverwaltung und Laufzeitaktualisierungen unterstützen.

Auf der Ebene der Host-Controller-Schnittstelle (HCI) ermöglichen neue Befehle den Hosts, CIG-Konfigurationen zu definieren, zuvor definierte Konfigurationen zu entfernen, Konfigurationsaktualisierungen zu initiieren und an Entscheidungen bezüglich Aktualisierungen mitzuwirken. Entsprechende HCI-Ereignisse ermöglichen es den Controllern, den Abschluss von Aktualisierungen zu melden und Aktualisierungsanforderungen weiterzuleiten, die von der Peripherie-Seite stammen.

Die wichtigsten von IPU eingeführten HCI-Ergänzungen sind in Tabelle 4.6.1 zusammengefasst.

Mechanismus	Zweck
LE CIG-Konfiguration hinzufügen	Eine zusätzliche Laufzeitkonfiguration definieren
LE CIG-Konfiguration entfernen	Eine zuvor definierte Konfiguration entfernen
LE-Update CIG	Konfigurationsübergang einleiten
LE-Update: CIG-Peripherieanfrage – Antwort	Auf eine von einem Peripheriegerät ausgehende Aktualisierungsanforderung reagieren
LE CIS-Update-Veranstaltung	Den Host über den Abschluss des Updates benachrichtigen
LE-Update: CIG-Peripherie-Anforderungsereignis	Den Host über eine Anforderung zur Aktualisierung eines Peripheriegeräts benachrichtigen

Gemeinsam ermöglichen diese Befehle und Ereignisse dem Host, mehrere Transport-Betriebspunkte über die gesamte Lebensdauer einer CIG hinweg zu verwalten und nicht nur während des Aufbaus der Verbindung.

4.6.2 Erweiterungen der Verbindungsschicht

Auf der Link-Schicht führt die Bluetooth®-IPU neue Steuerungsverfahren ein, die die Definition und das Entfernen von Konfigurationen sowie von der Zentrale initiierte Aktualisierungen und von Peripheriegeräten initiierte Aktualisierungsanforderungen unterstützen. Diese Verfahren bieten den erforderlichen Signalisierungsrahmen, um die Transportanpassung zu koordinieren, solange eine aktive CIS besteht.

Die wichtigsten durch IPU eingeführten Ergänzungen auf der Link-Schicht sind in Tabelle 4.6.2 zusammengefasst.

Mechanismus	Zweck
LL_CIG_CONFIG_REQ / RSP	Konfigurationsdefinitionen erstellen
LL_CIG_CONFIG_REMOVE_IND	Konfigurationsdefinitionen entfernen
LL_CIS_UPDATE_REQ / RSP	Konfigurationsaktualisierungen durchführen
LL_CIS_PERIPHERAL_UPDATE_REQ	Ein Update von der Peripherie anfordern

Diese Verfahren erweitern den Lebenszyklus eines CIS über dessen Erstellung und Beendigung hinaus, indem sie eine Weiterentwicklung des Konfigurationszustands während des Betriebs ermöglichen. In Kombination mit den in den vorangegangenen Abschnitten beschriebenen Aktivierungs- und Kontinuitätsmechanismen bilden sie die protokollarische Grundlage für die Transportanpassung zur Laufzeit.

Obwohl Aktualisierungen auf das Transportverhalten der CIS angewendet werden, wird die Ausführung der Aktualisierungen auf CIG-Ebene koordiniert, um sicherzustellen, dass mehrere CIS, die zur selben CIG gehören, während des gesamten Übergangs synchronisiert bleiben.

4.7 Typische Aktualisierungsszenarien

In den vorangegangenen Abschnitten wurde beschrieben, wie die Bluetooth®-IPU die Anpassung des Transports zur Laufzeit durch Konfigurationsbereitstellung, koordinierte Aktivierung und Kontinuitätsmanagement ermöglicht. In diesem Abschnitt wird veranschaulicht, wie diese Funktionen auf verschiedenen Schichten eines Systems angewendet werden können.

Die Beispiele wurden bewusst so ausgewählt, dass sie drei häufige Auslöser für Anpassungen veranschaulichen:

• Veränderungen der Funkbedingungen
• Veränderungen bei den Transportanforderungen
• Änderungen im Anwendungsverhalten

Gemeinsam zeigen sie, wie sich ein CIS während des Betriebs weiterentwickeln kann, ohne dass eine erneute Herstellung der Verbindung erforderlich ist.

4.7.1 Dynamische HF-Anpassung

Einer der Hauptgründe für den Einsatz von Bluetooth® IPU ist die Möglichkeit, die Übertragungseigenschaften an sich ändernde Funkbedingungen anzupassen.

Abbildung 4.7.1 veranschaulicht ein Beispiel, bei dem mehrere Konfigurationen innerhalb derselben CIG bereitgestellt werden. Eine Konfiguration kann unter günstigen Funkbedingungen der Übertragungseffizienz Vorrang einräumen, während eine andere bei zunehmendem Paketverlust für größere Robustheit sorgt.

Während des Betriebs überwacht der Controller Funkqualitätskennzahlen wie die Paketfehlerrate (PER) und ermittelt, wann ein anderer Betriebspunkt wünschenswert ist. Sobald eine Ziel-Config_ID identifiziert wurde, leitet der Host mithilfe des Befehls „LE Update CIG“ einen Übergang ein. Die Controller koordinieren daraufhin die Aktualisierung über das CIS-Update-Verfahren und aktivieren die neue Konfiguration zum vereinbarten Zeitpunkt.

Sollten sich die Kanalbedingungen später verschlechtern, kann dasselbe Verfahren angewendet werden, um wieder zu einer robusteren Konfiguration zurückzukehren. Aus Sicht der Anwendung bleibt der Audiostream während des gesamten Vorgangs aktiv. Es ändert sich lediglich die zugrunde liegende Transportkonfiguration.

Dieses Beispiel veranschaulicht, wie IPU die Transportkonfiguration an sich ändernde Funkbedingungen anpassen kann, während das CIS aktiv bleibt.

Das gleiche Anpassungsframework gilt für LE 1M, LE 2M und LE Coded PHYs sowie für neuere Transporttechnologien wie LE High Data Throughput (HDT). So können beispielsweise Konfigurationen für verschiedene Sätze von HDT-Raten definiert werden, wodurch jede Konfiguration ein geeignetes Teilintervall nutzen kann. Eine Konfiguration mit niedrigerer Rate könnte HDT2, HDT3 und HDT4 unterstützen, während eine Konfiguration mit höherer Rate HDT6 und HDT7,5 unterstützen könnte. Die Trennung dieser Betriebspunkte kann eine größere Flexibilität bei der Planung von Wiederholungsübertragungen innerhalb der verfügbaren Sendezeit bieten.

Dadurch kann IPU ein einheitliches Rahmenwerk für die Konfiguration und Aktualisierung bereitstellen, sobald neue Transportfunktionen eingeführt werden.

4.7.2 Adaptive Bitrate

Bluetooth® IPU unterstützt zudem die adaptive Bitrate, indem es die Einrichtung mehrerer Konfigurationen mit unterschiedlichen maximalen SDU-Größen (Max_SDU) für denselben CIS ermöglicht. Da Max_SDU direkten Einfluss auf die Menge der während jedes SDU-Intervalls übertragenen Anwendungsdaten hat, können unterschiedliche Konfigurationen unterschiedliche Bitrate-Betriebspunkte darstellen.

Beispielsweise kann ein Gerät mehrere Konfigurationen definieren, die unterschiedlichen Audioqualitätsstufen entsprechen. Unter günstigen Verbindungsbedingungen kann eine Konfiguration mit einem größeren Max_SDU-Wert ausgewählt werden, um die Übertragung von Audio mit höherer Bitrate zu unterstützen. Wenn sich die Verbindungsbedingungen verschlechtern, kann das System auf eine Konfiguration mit einem kleineren Max_SDU-Wert umschalten, wodurch die Übertragungsbitrate reduziert wird, während das aktive CIS beibehalten wird.

Abbildung 4.7.2 veranschaulicht ein Beispiel, bei dem mehrere Konfigurationen mit unterschiedlichen Max_SDU-Werten im Voraus bereitgestellt werden. Bei sich ändernden Betriebsbedingungen ermöglicht die IPU dem aktiven CIS den Wechsel zwischen diesen Konfigurationen, wodurch eine Anpassung der Bitrate möglich ist, ohne dass der Stream neu aufgebaut werden muss.

Dieser Ansatz ermöglicht eine dynamische Anpassung der Audioqualität und der Übertragungskapazität, wobei die Dienstkontinuität gewahrt bleibt und die CIS-Verbindung während des gesamten Übergangs aktiv bleibt.

4.7.3 Wechsel zwischen Audiomodi

Während die vorangegangenen Beispiele in erster Linie durch die Transportbedingungen bedingt sind, sind manche Aktualisierungen auf Änderungen im Anwendungsverhalten zurückzuführen.

LE-Audio-Geräte arbeiten häufig in mehreren Anwendungsmodi. Musikwiedergabe, Sprachkommunikation, Anwendungen zur Hörunterstützung und interaktive Audiodienste können unterschiedliche Übertragungseigenschaften priorisieren, darunter Latenz, Bitrate und Zuverlässigkeit.

Mit der Bluetooth®-IPU können für diese verschiedenen Betriebsmodi optimierte Konfigurationen im Voraus bereitgestellt und aktiviert werden, während das CIS aktiv bleibt. So kann beispielsweise ein Gerät bei Beginn eines Sprachanrufs von einer musikorientierten Konfiguration zu einer sprachorientierten Konfiguration wechseln. Der Host ermittelt die für den neuen Betriebsmodus geeignete Konfiguration und leitet die Aktualisierung über die Host-Controller-Schnittstelle ein. Die Controller koordinieren dann den Übergang über das CIS-Update-Verfahren und aktivieren die neue Konfiguration zum vereinbarten Zeitpunkt.

Der gleiche Ansatz kann für den umgekehrten Übergang verwendet werden, wenn das Gespräch endet und die Musikwiedergabe fortgesetzt wird. Da die erforderlichen Konfigurationen im Voraus festgelegt werden können, kann der Übergang die Transportcharakteristik ändern, ohne dass eine erneute CIS-Einrichtung erforderlich ist.

4.7.4 Koexistenz und Flexibilität bei der Zeitplanung

Die Bluetooth®-IPU bietet zudem Flexibilität bei der Zeitplanung, um die Koexistenz mit anderem drahtlosen Datenverkehr und die Synchronisation mit anderen isochronen Bluetooth®-Datenströmen zu unterstützen.

Beispielsweise kann durch ein IPU-Update der Ankerpunkt eines CIS angepasst werden, um die zeitliche Beziehung zwischen dem CIS und einem isochronen Broadcast-Stream (BIS), wie beispielsweise einem Auracast®-Stream, zu ändern. Dadurch lässt sich die zeitliche Abstimmung des CIS besser an andere isochrone Aktivitäten anpassen.

IPU kann außerdem den Wert von ISO_Interval ändern, um größere Lücken zwischen CIS-Ereignissen zu schaffen. Diese Lücken können zusätzliche Sendezeit für anderen drahtlosen Datenverkehr, einschließlich größerer WLAN-Pakete, bereitstellen und so die Koexistenz zwischen Bluetooth® und anderen Funktechnologien verbessern.

Diese Änderungen an der Zeitplanung können über denselben koordinierten Aktualisierungsmechanismus vorgenommen werden, der auch für andere IPU-Konfigurationsänderungen verwendet wird, sodass sich das Zeitverhalten weiterentwickeln kann, während das CIS aktiv bleibt.

4.8 Zusammenfassung

Bluetooth® LE Isochronous Parameter Update (IPU) erweitert Connected Isochronous Streams über ein festes Transportmodell hinaus und ermöglicht es, das Transportverhalten anzupassen, während ein CIS aktiv bleibt.

Anstatt die Transportparameter als einmaliges Ergebnis der Stream-Einrichtung zu betrachten, führt IPU ein konfigurationsorientiertes Framework ein, in dem während der gesamten Lebensdauer eines CIG mehrere Betriebspunkte bereitgestellt, ausgewählt und aktiviert werden können.

Laufzeitaktualisierungen werden über eine Instant-basierte Aktivierung koordiniert, wodurch beide Geräte an einer gemeinsamen Synchronisationsgrenze auf eine neue Konfiguration umgestellt werden können. Zusätzliche Kontinuitätsmechanismen, darunter die Verarbeitung von Übergangs-Nutzdaten und die Koordination von Flush-Punkten, gewährleisten die Aufrechterhaltung der Nutzdatenverarbeitung, während sich der Transportzustand weiterentwickelt.

Zur Unterstützung dieser Funktionen führt IPU eine kompakte Reihe von Erweiterungen für die Host-Controller-Schnittstelle und die Verbindungsschicht ein, die Konfigurationsmanagement, Laufzeitanpassung und die koordinierte Ausführung von Updates ermöglichen.

Zusammen verwandeln diese Mechanismen die Transportanpassung von einem Vorgang zum Aufbau eines Datenstroms in eine Laufzeitfunktion. Die IPU kann die Anpassung an sich ändernde Funkbedingungen, adaptive Bitraten, Übergänge zwischen Anwendungsmodi sowie Anforderungen an die Planung oder Koexistenz unterstützen, während ein aktives CIS aufrechterhalten wird. Durch die Bereitstellung eines gemeinsamen Mechanismus zur Definition und Aktivierung alternativer Konfigurationen ermöglicht die IPU eine Weiterentwicklung des Transportverhaltens, ohne dass ein erneuter Aufbau des Datenstroms erforderlich ist.

5. Bluetooth®-Verschlüsselungsschlüsselplan (EKS)

5.1 Hintergrund

5.1.1 Entwicklung der Bluetooth® LE-Verschlüsselung

Bluetooth® LE baut verschlüsselte Verbindungen üblicherweise mithilfe des Verfahrens „Encryption Start with Diversifiers“ auf. Bei diesem Modell tauschen die Geräte Initialisierungsvektoren und Sitzungsschlüssel-Diversifikatoren aus, bevor sie den Sitzungsschlüssel ableiten, der für die Verschlüsselung auf der Bluetooth-Verbindungsschicht verwendet wird. Dieser Ansatz hat eine sichere und interoperable Grundlage für die Bluetooth-LE-Kommunikation in einer Vielzahl von Anwendungen geschaffen.

Da sich die Bluetooth-Technologie in Richtung leistungsfähigerer Übertragungsprotokolle und fortschrittlicherer Sicherheitsarchitekturen weiterentwickelt, ist zusätzliche Flexibilität beim Aufbau, der Verwaltung und der Aktualisierung von Verschlüsselungsmaterial erforderlich. Insbesondere besteht ein zunehmender Bedarf an einer stärkeren kryptografischen Trennung zwischen den Übertragungsprotokollen, der Unterstützung sich weiterentwickelnder Verschlüsselungskontexte und einer flexibleren Verwaltung des Schlüssellebenszyklus.

Um diesen Anforderungen gerecht zu werden, führt Bluetooth den „Encryption Key Schedule“ (EKS) ein, ein neues Rahmenwerk, das den ECDH-basierten Schlüsselaustausch mit einer hierarchischen Schlüsselableitung und integrierten Funktionen zur Schlüsselaktualisierung kombiniert.

5.1.2 Warum ein neues Rahmenwerk für die Schlüsselverwaltung erforderlich war

Bei der herkömmlichen Bluetooth® LE-Verschlüsselung werden Sitzungsschlüssel direkt aus einem Langzeitschlüssel (LTK) in Verbindung mit den ausgetauschten Sitzungsparametern abgeleitet. Dieses Modell ist zwar effektiv, bietet jedoch nur begrenzte Flexibilität bei der Verwaltung des Verschlüsselungsmaterials, nachdem eine Verbindung hergestellt wurde.

Bluetooth® EKS verfolgt einen anderen Ansatz. Anstatt Verschlüsselungsmaterial direkt aus einer einzigen Schlüsselquelle abzuleiten, schafft EKS eine kryptografische Grundlage, die auf mehreren Eingaben basiert, und leitet anschließend das Sitzungsverschlüsselungsmaterial über eine strukturierte Hierarchie ab. Diese Trennung zwischen Schlüsselaufbau, transportspezifischer Schlüsselableitung und nachfolgenden Schlüsselaktualisierungen ermöglicht einen flexibleren Lebenszyklus für das Bluetooth-LE-Verschlüsselungsmaterial.

5.2 Technischer Überblick

Der „Bluetooth® Encryption Key Schedule“ legt einen strukturierten Lebenszyklus für Bluetooth® LE-Verschlüsselungsmaterial fest. Zunächst wird die kryptografische Grundlage für eine Verbindung geschaffen, anschließend wird mithilfe eines hierarchischen Ableitungsrahmens transportspezifisches Verschlüsselungsmaterial generiert. Da die Schaffung der kryptografischen Grundlage von der Generierung der Sitzungsschlüssel getrennt ist, kann dieselbe Architektur auch alternative Betriebsmodi und nachfolgende Schlüsselaktualisierungen unterstützen, darunter opportunistische Verschlüsselung und die Aktualisierung von Schlüsseln während der Verbindung.

5.2.1 Schaffung der kryptografischen Grundlagen

In der ersten Phase von Bluetooth® EKS wird die kryptografische Grundlage geschaffen, auf der die nachfolgenden Schlüsselableitungsverfahren basieren.

Bei der herkömmlichen Bluetooth® LE-Verschlüsselung kommt das Verfahren „Encryption Start with Diversifiers“ zum Einsatz. Dabei tauschen Central und Peripheral über die PDUs „LL_ENC_REQ“ und „LL_ENC_RSP“ die Werte für den Session Key Diversifier (SKD) und den Initialisierungsvektor (IV) aus. Die ausgetauschten Werte werden mit einem Langzeitschlüssel (LTK) kombiniert, um den Sitzungsschlüssel zu generieren, der für die Verschlüsselung auf der Verbindungsschicht verwendet wird.

EKS verfolgt einen anderen Ansatz. Anstatt SKD- und IV-Werte auszutauschen, tauschen die Geräte mithilfe der PDUs „LL_ENC_ECDH_REQ“ und „LL_ENC_ECDH_RSP“ öffentliche ECDH-Schlüssel, Zufallswerte und verschlüsselungsbezogene Parameter aus. Diese Nachrichten enthalten:

• Öffentliche ECDH-Schlüssel (PubKey_C und PubKey_P)
• Zufallswerte (Rand_C und Rand_P)
• Verschlüsselungsflags (Flags_C und Flags_P)
• Informationen zum Typ des öffentlichen Schlüssels
• MIC-bezogene Betriebspräferenzen

Anhand der ausgetauschten öffentlichen Schlüssel berechnen beide Geräte unabhängig voneinander dasselbe ECDH-Gemeinschaftsgeheimnis unter Verwendung der elliptischen Kurve Bluetooth P-256.

Wie in Abbildung 5.2.1 dargestellt, stellt das Verfahren „Encryption Start with Key Schedule“ mehr als nur eine verschlüsselte Verbindung her. Neben der Generierung eines gemeinsamen ECDH-Geheimnisses werden im Rahmen dieses Verfahrens auch Steuerinformationen ausgetauscht, die später in den EKS-Ableitungsprozess einfließen. Diese ausgetauschten Daten werden anschließend in die EKS-Schlüsselhierarchie integriert.

Das ECDH-Gemeinschaftsgeheimnis wird nicht direkt als Sitzungsschlüssel verwendet. Stattdessen werden im Rahmen des Verfahrens die kryptografischen Eingaben und der Verhandlungskontext festgelegt, die zur Initialisierung der EKS-Schlüsselhierarchie erforderlich sind. Sobald das erforderliche Verschlüsselungsmaterial abgeleitet wurde, schließen die Geräte den bestehenden Drei-Wege-Verschlüsselungs-Handshake mithilfe von LL_START_ENC_REQ und LL_START_ENC_RSP ab.

Das gemeinsame ECDH-Geheimnis und der Verbindungskontext, die durch das in Abbildung 5.2.1 dargestellte Verfahren hergestellt wurden, dienen somit als Eingaben für die im folgenden Abschnitt beschriebene CMAC-basierte Schlüsselhierarchie.

5.2.2 Aufbau der Bluetooth®-EKS-Schlüsselhierarchie

Sobald die kryptografische Grundlage geschaffen ist, verwendet EKS ein CMAC-basiertes Schlüsselableitungs-Framework, um die während des Verfahrens „Encryption Start with Key Schedule“ ausgetauschten Informationen in das Verschlüsselungsmaterial umzuwandeln, das von der Bluetooth® LE-Link-Layer-Verschlüsselung verwendet wird. Abbildung 5.2.2 veranschaulicht die Schlüsselhierarchie, die zur Durchführung dieser Umwandlung verwendet wird.

Wie in Abbildung 5.2.2 dargestellt, leitet EKS Verschlüsselungsmaterial über eine strukturierte Hierarchie ab und verwaltet es, anstatt einen Sitzungsschlüssel direkt aus einem Langzeitschlüssel zu generieren. Die Bezeichnungen wie k2, ee12, kv12 und k3 stehen für CMAC-basierte Ableitungsfunktionen, die in verschiedenen Stufen dieser Hierarchie angewendet werden. Rechtecke in der Abbildung stellen kryptografische Funktionen dar, abgerundete Kästchen stehen für kryptografische Werte und schraffierte Kästchen symbolisieren Ereignisse im EKS-Lebenszyklus.

Ausführliche Definitionen der in Abbildung 5.2.2 dargestellten Funktionen und Tags finden sich in der Bluetooth® Core Specification, Band 6, Teil E, Abschnitt 4. Diese Übersicht konzentriert sich daher eher auf den Zweck der Hierarchie und die Rolle des daraus resultierenden kryptografischen Materials als auf die mathematische Funktionsweise der einzelnen Ableitungsfunktionen.

Bluetooth®-Kernspezifikation, Band 6, Teil E, Abschnitt 4, Abbildung 4.1.

Zur Initialisierung der Hierarchie kombiniert EKS mehrere kryptografische Eingaben, die mit dem Verfahren „Encryption Start with Key Schedule“ verbunden sind:

• ECDH-Gemeinsames Geheimnis: Wird von beiden Geräten unabhängig voneinander aus den in LL_ENC_ECDH_REQ und LL_ENC_ECDH_RSP ausgetauschten öffentlichen Schlüsseln berechnet
• Langzeitschlüssel: Wird vom Host bereitgestellt, wenn eine bestehende Bluetooth-Sicherheitsverbindung besteht
• AA: Die Zugangsadresse der ACL-Verbindung
• HPA: Die HDT-Paketadresse der ACL-Verbindung, sofern vorhanden, andernfalls der Ein-Oktett-Wert 0x00
• PDU_C: Das Feld „CtrData“ der PDU „LL_ENC_ECDH_REQ“, die von der Zentrale gesendet wird
• PDU_P: Das Feld „CtrData“ der vom Peripheriegerät übertragenen PDU „LL_ENC_ECDH_RSP“

Zusammen liefern AA, HPA, PDU_C und PDU_P den verbindungsspezifischen Kontext für den Ableitungsprozess. PDU_C und PDU_P enthalten die Verschlüsselungsflags, Zufallswerte, Typen öffentlicher Schlüssel und öffentliche Schlüssel, die während des Verschlüsselungsaufbaus ausgetauscht wurden. Die Bluetooth®-Kernspezifikation definiert außerdem die Oktettreihenfolge, die verwendet wird, wenn PDU_C und PDU_P in die AES-CMAC-Berechnung einfließen, wodurch sichergestellt wird, dass beide Controller identische Ableitungseingaben erstellen.

Durch die Kombination des gemeinsamen ECDH-Geheimnisses, des entsprechenden LTK und des verbindungsspezifischen Kontexts bindet EKS das resultierende Verschlüsselungsmaterial an die ACL-Verbindung und die EKS-Aushandlung. EKS leistet somit mehr, als nur ein ECDH-Ergebnis in einen Sitzungsschlüssel umzuwandeln. Es kombiniert neues, aus ECDH abgeleitetes Material, eine vorhandene Bluetooth-Anmeldeinformation (sofern verfügbar) und den Kontext der aktuellen Verbindung im Rahmen eines strukturierten Ableitungsprozesses.

Der erste durch diesen Prozess erzeugte Zwischenwert ist das „Derived Secret“, das die sich weiterentwickelnde Wurzel der EKS-Hierarchie bildet. Das „Derived Secret“ wird zur Erstellung eines oder mehrerer „Traffic Secrets“ verwendet, und jedes „Traffic Secret“ wird anschließend zur Generierung des Sitzungsschlüssels und des Initialisierungsvektors verwendet, die für die AES-CCM-Verschlüsselung erforderlich sind.

Diese mehrschichtige Struktur trennt die kryptografische Grundlage auf Verbindungsebene von den Verschlüsselungsmechanismen, die von den einzelnen Transportprotokollen verwendet werden. Wie im folgenden Abschnitt beschrieben, ermöglicht sie es EKS, unabhängige Verschlüsselungskontexte für die ACL-Verbindung und die zugehörigen CIS-Transporte zu erstellen und bildet gleichzeitig die Grundlage für spätere Schlüsselaktualisierungen.

5.2.3 Verwaltung von ACL- und CIS-Verschlüsselungsmaterial

Die in Abbildung 5.2.2 dargestellte Schichtstruktur ermöglicht es Bluetooth® EKS, Verschlüsselungsmaterial für verschiedene Transportarten unabhängig voneinander zu verwalten und dabei eine gemeinsame kryptografische Grundlage beizubehalten. Anstatt einen einzigen Sitzungsschlüssel für den gesamten mit einer Verbindung verbundenen Datenverkehr zu generieren, nutzt EKS „Traffic Secrets“, um transportspezifische Verschlüsselungskontexte zu erstellen.

Wenn eine ACL-Verschlüsselung eingerichtet wird, generiert EKS aus dem mit der Verbindung verknüpften abgeleiteten Geheimnis ein ACL-Datenverkehrsgeheimnis. Dieses ACL-Datenverkehrsgeheimnis wird dann verwendet, um den Sitzungsschlüssel und den Initialisierungsvektor (IV) abzuleiten, die von AES-CCM zum Schutz des Datenverkehrs auf der verschlüsselten ACL-Verbindung verwendet werden. Das abgeleitete Geheimnis und das Datenverkehrsgeheimnis verbleiben innerhalb des Controllers und werden nicht außerhalb des EKS-Frameworks offengelegt.

Wenn ein neuer „Connected Isochronous Stream“ (CIS) erstellt wird, erweitert EKS die Hierarchie, indem es zusätzliches kryptografisches Material für den neuen Transport generiert. Unter Verwendung des aktuellen „Derived Secret“ zusammen mit den entsprechenden CIG_ID- und CIS_ID-Werten generieren beide Geräte ein neues „Derived Secret“ und ein erstes „CIS Traffic Secret“, das diesem Stream zugeordnet ist. Der CIS-Sitzungsschlüssel und der Initialisierungsvektor werden dann aus dem „CIS Traffic Secret“ abgeleitet.

Abbildung 5.2.2 sollte daher eher als verzweigte Hierarchie denn als einzelne lineare Kette betrachtet werden. Die ACL-Verbindung verwaltet ihr eigenes ACL-Verkehrsgeheimnis und das entsprechende Sitzungsschlüsselmaterial, während jedes zugehörige CIS ein eigenständiges CIS-Verkehrsgeheimnis und einen eigenen Sitzungsschlüssel verwaltet. Durch die Erstellung eines neuen CIS wird zudem das von der Hierarchie verwendete abgeleitete Geheimnis weiterentwickelt.

Diese transportspezifische Verzweigung ist einer der Hauptgründe dafür, dass EKS die Ebenen „Derived Secret“ und „Traffic Secret“ einführt. Durch die Verwendung separater „Traffic Secrets“ für ACL- und CIS-Transporte sorgt EKS für eine kryptografische Trennung zwischen den Kommunikationsströmen und bewahrt gleichzeitig eine gemeinsame Vertrauensbasis auf Verbindungsebene. So können mehrere Transportkontexte nebeneinander bestehen, ohne dieselben Sitzungsschlüssel zu teilen, auch wenn sie aus derselben EKS-Hierarchie stammen.

5.2.4 Opportunistische Verschlüsselung

Die im vorigen Abschnitt beschriebenen transportbezogenen Verschlüsselungskontexte werden über die Bluetooth®-EKS-Hierarchie erstellt und verwaltet, unabhängig davon, wie die kryptografische Grundlage hergestellt wird. Im häufigsten Fall wird EKS mithilfe eines vom Host bereitgestellten Langzeitschlüssels (LTK) initialisiert. Die gleiche Architektur kann jedoch auch dann funktionieren, wenn keine zuvor hergestellte Bluetooth-Sicherheitsbeziehung besteht. Dieser Betriebsmodus wird als opportunistische Verschlüsselung bezeichnet.

Die opportunistische Verschlüsselung ermöglicht es zwei Geräten, eine verschlüsselte Kommunikation herzustellen, ohne dass zuvor eine Kopplung oder Bindung erforderlich ist. Anstatt sich auf einen gebundenen Langzeitschlüssel (LTK) zu stützen, verwenden die Geräte das gemeinsame ECDH-Geheimnis, das während des Verfahrens „Encryption Start with Key Schedule“ festgelegt wurde, zusammen mit einem festen LTK-Wert, der ausschließlich aus Nullen besteht und in der Bluetooth®-Kernspezifikation definiert ist.

Die Zentrale fordert eine opportunistische Verschlüsselung über das entsprechende Flag in LL_ENC_ECDH_REQ an. Das Peripheriegerät akzeptiert diesen Modus nur, wenn die Funktion „Opportunistic Encryption Host Support“ verfügbar ist. Andernfalls lehnt das Peripheriegerät die Anforderung mit dem Fehler „Verschlüsselungsmodus nicht akzeptabel “ ab.

Im Gegensatz zum herkömmlichen EKS-Betrieb, bei dem ein vom Host bereitgestellter LTK verwendet wird, kommt bei der opportunistischen Verschlüsselung ein LTK-Wert zum Einsatz, der ausschließlich aus Nullen besteht. Abgesehen von diesem Unterschied werden dieselben Verfahren zur Einrichtung, Ableitung und Schlüsselverwaltung verwendet, um das Verschlüsselungsmaterial für die Verbindung zu erstellen und zu verwalten.

Da die opportunistische Verschlüsselung eine verschlüsselte Kommunikation ermöglicht, ohne dass zuvor eine Kopplung oder Bindung erforderlich ist, erweitert sie das Spektrum der Anwendungsszenarien, in denen die Bluetooth® LE-Verschlüsselung eingesetzt werden kann. Da jedoch keine zuvor hergestellte Bluetooth-Vertrauensbeziehung vorliegt, bietet die opportunistische Verschlüsselung keinen Schutz vor Man-in-the-Middle-Angriffen. In der Bluetooth® Core Specification werden ihre Vertraulichkeits- und Integritätseigenschaften als gleichwertig mit denen von Geräten beschrieben, die über das Assoziationsmodell „LE Secure Connections Just Works“ gekoppelt sind.

5.2.5 Aktualisierung des Verschlüsselungsmaterials

Die in den vorangegangenen Abschnitten beschriebenen transportspezifischen Verschlüsselungskontexte basieren auf den von der EKS-Hierarchie verwalteten „Traffic Secrets“. Da die im vorangegangenen Abschnitt beschriebenen ACL- und CIS-Sitzungsschlüssel aus den „Traffic Secrets“ abgeleitet werden und nicht direkt aus der ursprünglichen kryptografischen Grundlage, kann Bluetooth® EKS das Verschlüsselungsmaterial während der gesamten Lebensdauer einer Verbindung weiterentwickeln, ohne dass die gesamte Hierarchie neu aufgebaut werden muss.

EKS unterstützt zwei Ansätze zur Aktualisierung von Verschlüsselungsmaterial: das Neustarten der Verschlüsselung und das Aktualisieren der Verschlüsselung.

Verschlüsselung neu starten

In bestimmten Situationen muss die Verschlüsselung unter Verwendung eines neuen Verschlüsselungskontexts neu eingerichtet werden. Um diese Funktion zu unterstützen, nutzt Bluetooth® LE das Verfahren „Encryption Pause“.

Während des „Encryption Pause“-Vorgangs wird die Verschlüsselung vorübergehend ausgesetzt, und bevor die Verschlüsselung wieder aktiviert wird, wird ein eingekapselter „Encryption Start“-Vorgang ausgeführt. Daten-PDUs werden während der Pause nicht unverschlüsselt übertragen.

Wurde EKS ursprünglich zum Aufbau der Verbindung verwendet, kommt beim Neustart dasselbe Verfahren „Encryption Start with Key Schedule“ zum Einsatz. Dieser Vorgang wiederholt im Wesentlichen die in Abschnitt 5.2.1 beschriebene Schlüsselaufbauphase, wobei eine neue kryptografische Grundlage geschaffen und die EKS-Hierarchie neu aufgebaut wird, bevor neues Sitzungsschlüsselmaterial generiert wird. Die bestehende Verbindung bleibt während des gesamten Vorgangs erhalten. Eine opportunistische Verschlüsselung ist während eines gekapselten Neustartvorgangs nicht zulässig.

Verschlüsselung aktualisieren

EKS unterstützt zudem die Aktualisierung von Verschlüsselungsmaterial, ohne dass der gesamte Verschlüsselungskontext neu aufgebaut werden muss.

Im Gegensatz zum Neustart der Verschlüsselung finden Aktualisierungsvorgänge vollständig innerhalb der bestehenden EKS-Hierarchie statt. Anstatt den ECDH-Austausch zu wiederholen und die kryptografische Grundlage neu aufzubauen, aktualisieren beide Geräte das bestehende ACL-Traffic-Secret und leiten aus dem aktualisierten Wert einen neuen Sitzungsschlüssel und einen neuen Initialisierungsvektor ab. Das ursprüngliche gemeinsame ECDH-Geheimnis, das abgeleitete Geheimnis und der verbindungsspezifische Kontext bleiben unverändert.

Durch das Aktualisieren des ACL-Sitzungsschlüssels werden weder der Paketzähler noch die Nutzdaten-Nummer zurückgesetzt. Wenn ein Nutzdatensatz vor der Schlüsseländerung übertragen wurde und anschließend erneut übertragen werden muss, wird der Nutzdatensatz erneut verschlüsselt und sein MIC unter Verwendung des neuen Sitzungsschlüssels neu berechnet.

Obwohl sowohl der Neustart als auch die Aktualisierung letztendlich neues Sitzungsschlüsselmaterial erzeugen, finden sie auf unterschiedlichen Ebenen der EKS-Hierarchie statt. Beim Neustart der Verschlüsselung wird der Verschlüsselungskontext durch eine neue „Encryption Start“-Prozedur neu aufgebaut, während bei der Aktualisierung der Verschlüsselung der bestehende Verschlüsselungskontext weiterentwickelt wird, indem das ACL-Traffic-Secret aktualisiert und aus diesem aktualisierten Wert neue Sitzungsschlüssel abgeleitet werden. In der Praxis ermöglichen Aktualisierungsvorgänge die Einführung von neuem Sitzungsschlüsselmaterial, ohne den ECDH-Austausch zu wiederholen, durch den die Verbindung ursprünglich hergestellt wurde.

Diese Unterscheidung verdeutlicht einen der Hauptvorteile der Einbindung von „Traffic Secrets“ in die EKS-Architektur: Das Verschlüsselungsmaterial kann sich unabhängig vom ursprünglichen Schlüsselaufbauprozess weiterentwickeln.

5.2.6 Auswahl des MIC und Betrieb des HDT

Neben der Einrichtung und Verwaltung von Verschlüsselungsschlüsseln legt das Verfahren „Verschlüsselung mit Schlüsselplan starten“ auch fest, wie der Integritätsschutz auf die Verbindung angewendet wird.

Die Verschlüsselungsflags, die während des Verfahrens „Encryption Start with Key Schedule“ ausgetauscht werden, bestimmen das Verhalten des Message Integrity Code (MIC) der Verbindung.

Verbindungen, die mit einem GFSK-PHY betrieben werden, verwenden einen 32-Bit-MIC. Beim Betrieb mit einem LE-HDT-PHY wird ein 64-Bit-MIC verwendet, wenn sowohl die Zentrale als auch das Peripheriegerät angeben, dass ein 64-Bit-MIC zulässig ist. Andernfalls wird ein 128-Bit-MIC verwendet.

Die MIC-Länge wird daher im Rahmen der EKS-Verschlüsselungskonfiguration festgelegt und nicht erst nach Beginn der Verschlüsselung separat gewählt. Das gewählte MIC-Verhalten wird Teil des Verbindungskontexts, der in die Bluetooth®-EKS-Hierarchie integriert ist.

Die im LE HDT PHY verwendete MIC-Länge kann anschließend im Rahmen des Verfahrens zur PHY-Aktualisierung und Verschlüsselungsaktualisierung geändert werden, wodurch eine Anpassung der PHY-Eigenschaften und der zugehörigen Integritätsschutzparameter innerhalb des EKS-Rahmens koordiniert werden kann.

Obwohl EKS ursprünglich zusammen mit Bluetooth® HDT eingeführt wurde, ist es als eigenständige Controller-Funktion definiert. HDT sollte daher eher als eine Anwendung des EKS-Frameworks betrachtet werden und nicht als der einzige Grund für dessen Existenz.

Die in diesem Abschnitt beschriebenen Funktionen, darunter die hierarchische Schlüsselableitung, transportspezifische „Traffic Secrets“, opportunistische Verschlüsselung, Verschlüsselungsneustart und Schlüsselaktualisierung, bilden eine wiederverwendbare Sicherheitsgrundlage, die Bluetooth-Technologien über HDT hinaus unterstützen kann.

5.2.7 Vergleich mit der Verschlüsselung unter Verwendung von Diversifikatoren

Nachdem untersucht wurde, wie Bluetooth® EKS Verschlüsselungsmaterial erstellt, ableitet und verwaltet, ist es sinnvoll, die Architektur mit dem herkömmlichen Verfahren „Encryption Start with Diversifiers“ zu vergleichen. Beide Ansätze nutzen letztendlich den Handshake „LL_START_ENC_REQ“ und „LL_START_ENC_RSP“, um die Verbindung in den verschlüsselten Betrieb zu überführen. Die wesentlichen Unterschiede liegen in den Informationen, die vor diesem Handshake ausgetauscht werden, sowie darin, wie das resultierende Verschlüsselungsmaterial abgeleitet und anschließend verwaltet wird.

Tabelle 5.2.7 fasst die wesentlichen architektonischen Unterschiede zwischen dem herkömmlichen Verfahren „Encryption Start with Diversifiers“ und dem EKS-Framework zusammen.

Aspekt	Verschlüsselung mit Diversifikatoren	EKS
Grundlagen der Kryptografie	LTK + SKD/IV	ECDH-gemeinsames Geheimnis + LTK + Verbindungskontext
Schlüsselstruktur	Sitzungsschlüssel	Abgeleitetes Geheimnis → Verkehrsgeheimnis → Sitzungsschlüssel
Trennung der Transportwege	Nicht definiert	Geheimnisse des separaten ACL- und CIS-Datenverkehrs
Wichtiges Update	Verschlüsselung neu starten	Verschlüsselung neu starten oder aktualisieren
Opportunistische Verschlüsselung	Wird nicht unterstützt	Unterstützt

5.3 Zusammenfassung

Der Bluetooth®-Verschlüsselungsschlüsselplan führt ein hierarchisches Rahmenwerk für die Erstellung und Verwaltung von Bluetooth® LE-Verschlüsselungsmaterial ein. Er kombiniert ein gemeinsames ECDH-Geheimnis, den entsprechenden Langzeitschlüssel und verbindungsspezifische Kontextdaten, um unabhängiges Verschlüsselungsmaterial für ACL- und CIS-Transporte abzuleiten.

EKS unterstützt zudem opportunistische Verschlüsselung, den Neustart der Verschlüsselung, die Aktualisierung des Schlüssels während der Verbindung sowie einen erweiterten MIC-Betrieb. Zusammen bilden diese Funktionen die von HDT geforderte Sicherheitsgrundlage und ermöglichen es EKS gleichzeitig, eine eigenständige und wiederverwendbare Bluetooth-Funktion zu bleiben.

6. Bluetooth®-Transient Application Key (TAK)

6.1 Hintergrund

6.1.1 Entwicklung der Bluetooth-Sicherheitsarchitektur

Bluetooth bietet schon seit langem Mechanismen zum Aufbau von Vertrauen und zum Schutz der Kommunikation zwischen Geräten. Diese Mechanismen basieren auf mehreren zentralen Sicherheitsfunktionen:

• Kopplung, bei der gemeinsame geheime Schlüssel zwischen Geräten eingerichtet werden
• Bonding, bei dem diese Schlüssel für die spätere Verwendung gespeichert werden
• Geräteauthentifizierung, bei der der Besitz von gemeinsam genutztem Schlüsselmaterial überprüft wird

• Verschlüsselung, die die Vertraulichkeit von Daten während der Übertragung gewährleistet
• Datenintegrität, die vor unbefugten Änderungen an Daten schützt

Im Laufe der Zeit hat sich die Bluetooth-Sicherheitsarchitektur von den älteren BR/EDR-Mechanismen hin zu fortschrittlicheren Ansätzen wie „LE Secure Connections“ weiterentwickelt. Während sich die zugrunde liegende Kryptografie erheblich verbessert hat, ist das Betriebsmodell weitgehend unverändert geblieben.

In den meisten Fällen geht die Bluetooth-Sicherheit davon aus, dass Geräte durch das Pairing eine Vertrauensbeziehung aufbauen und diese dann durch das Bonding aufrechterhalten. Dadurch bleibt der Sicherheitsstatus über mehrere Verbindungen und Interaktionen hinweg erhalten.

Dieses Modell eignet sich gut für Geräte, die im Laufe der Zeit wiederholt kommunizieren, wie beispielsweise Smartphones, Wearables, Kopfhörer und Eingabegeräte. Es geht jedoch davon aus, dass Vertrauensbeziehungen langfristig bestehen bleiben und es sich lohnt, sie aufrechtzuerhalten.

6.1.2 Einschränkungen der zustandsabhängigen Paarbildung bei kurzlebigen Wechselwirkungen

Da Bluetooth® LE in neue Anwendungsbereiche vordringt, werden immer mehr Interaktionen kurzlebig und transaktionsorientiert statt dauerhaft. Bluetooth wird mittlerweile häufig in Szenarien wie digitalen Schlüsseln, Zugangskontrollsystemen, Ticketverkauf, zugangsberechtigungsbasiertem Zugang, gemeinsam genutzter Infrastruktur und temporärer Gerätebereitstellung eingesetzt, in denen Geräte möglicherweise nur einmal oder für einen begrenzten Zeitraum miteinander interagieren, bevor die Verbindung endet.

In solchen Situationen kann das herkömmliche, auf Pairing basierende Sicherheitsmodell zu unnötiger Komplexität führen. Pairing und Bonding dienen dazu, eine langfristige Vertrauensbeziehung zwischen Geräten aufzubauen und aufrechtzuerhalten, sodass Schlüssel und Sicherheitsmaßnahmen bei zukünftigen Verbindungen wiederverwendet werden können. Wenn die Interaktion jedoch nur vorübergehend ist, bietet die Aufrechterhaltung einer dauerhaften Sicherheit möglicherweise nur geringen Nutzen.

Dies kann zu verschiedenen Herausforderungen führen. Auch kurzlebige Interaktionen können langfristige Verbindungsdaten erzeugen und so die begrenzten Speicherressourcen der Geräte beanspruchen. Zudem kann das Vertrauen bereits durch Mechanismen außerhalb des Bluetooth-Stacks hergestellt worden sein, wie beispielsweise cloudbasierte Identitätsdienste, digitale Zugangsdaten, Zertifikate oder andere anwendungsspezifische Authentifizierungssysteme. Eine Kopplung ausschließlich zum Zweck der Erlangung eines Verschlüsselungsschlüssels kann daher bereits durchgeführte Authentifizierungsprozesse doppelt ausführen.

Diese Trends spiegeln einen umfassenderen Wandel in der Systemgestaltung wider. Moderne Anwendungen trennen das Identitätsmanagement zunehmend von den Übertragungstechnologien, sodass Authentifizierungs- und Vertrauensentscheidungen auf Anwendungsebene getroffen werden können, während sich die Kommunikationstechnologien auf den Schutz der ausgetauschten Daten konzentrieren.

Zur Unterstützung dieses Modells führt Bluetooth eine Sicherheitsarchitektur ohne Kopplung ein, die eine Verschlüsselung auf Link-Ebene ermöglicht, ohne dass eine Kopplung oder ein Bonding erforderlich ist. Bei diesem Ansatz werden die Authentifizierung und der Schlüsselaufbau von einer Anwendung auf einer höheren Ebene durchgeführt, während Bluetooth weiterhin einen standardisierten Transportschutz für die über die drahtlose Verbindung ausgetauschten Daten bereitstellt.

Dieser Ansatz ersetzt nicht das bestehende, auf Pairing basierende Modell, sondern erweitert die Bluetooth-Sicherheitsarchitektur um die Unterstützung vorübergehender, sitzungsbasierter Interaktionen, bei denen die Aufrechterhaltung einer langfristigen Vertrauensbeziehung weder notwendig noch wünschenswert ist.

6.2 Technischer Überblick

6.2.1 Was ist ein temporärer Anwendungsschlüssel (TAK)?

Ein Transient Application Key (TAK) ist ein 128-Bit-Geheimnis, das von einer Anwendung einer höheren Schicht bereitgestellt wird und zum Aufbau der Verschlüsselung auf der Verbindungsschicht für eine Bluetooth® LE-Verbindung dient. Funktional erfüllt er während des Verschlüsselungsvorgangs denselben Zweck wie ein Long-Term Key (LTK), unterscheidet sich jedoch grundlegend in der Art und Weise, wie er generiert und verwaltet wird.

Bei der herkömmlichen Bluetooth® LE-Sicherheit werden Verschlüsselungsschlüssel im Rahmen von Kopplungsvorgängen abgeleitet, die vom Security Manager Protocol (SMP) verwaltet werden. Im Gegensatz dazu wird ein TAK im Rahmen eines Authentifizierungs- und Schlüsselaufbauprozesses generiert, der durch eine Anwendung oder Spezifikation einer höheren Schicht definiert ist. Der Bluetooth Security Manager ist an der Erstellung des Schlüssels nicht beteiligt.

Dadurch wird der Aufbau einer Vertrauensbeziehung vom Transportschutz getrennt. Die Authentifizierung erfolgt durch die Anwendung auf höherer Ebene, während Bluetooth eine standardisierte Verschlüsselung auf der Verbindungsschicht bereitstellt, sobald ein gemeinsamer Schlüssel festgelegt wurde.

Der Lebenszyklus eines TAK ist bewusst kurzlebig. Der TAK wird dem Bluetooth-Host zur Verwendung während des Verschlüsselungsstartvorgangs bereitgestellt und vom Host nach Einleitung des Vorgangs verworfen. Es wird keine Bindungsbeziehung hergestellt, und es wird kein langfristiger Bluetooth-Sicherheitsstatus beibehalten.

6.2.2 Architektur mit ungepaarten Sicherheitselementen

Bluetooth® TAK führt eine neue Sicherheitsarchitektur für Bluetooth® LE ein, die als „Non-Paired Security Model“ (Sicherheitsmodell ohne Kopplung) bezeichnet wird. Im Gegensatz zur herkömmlichen Bluetooth-Sicherheit, bei der das Vertrauensverhältnis durch Kopplung und Bindung hergestellt wird, ermöglicht dieses Modell den Aufbau verschlüsselter Verbindungen ohne Einsatz des Security Managers.

Bei dieser Architektur authentifiziert eine Anwendung einer höheren Schicht das Gegenstückgerät und richtet ein gemeinsames Geheimnis ein. Der daraus resultierende TAK wird anschließend dem Bluetooth-Host übermittelt und zur Einleitung der Verschlüsselung auf der Verbindungsschicht verwendet. Der übrige Teil des Bluetooth-Protokollstacks, einschließlich GAP, ATT, L2CAP und des Controllers, arbeitet weiterhin normal.

Wie in Abbildung 6.2.2 dargestellt, arbeitet die für die Authentifizierung zuständige Anwendung außerhalb des Bluetooth-Sicherheitsmanagers. Anstatt an den Bluetooth-Kopplungsverfahren teilzunehmen, baut die Anwendung direkt eine Vertrauensbeziehung auf und übermittelt dem Host einen temporären Anwendungsschlüssel. Der Bluetooth-Stack nutzt diesen Schlüssel dann, um für die Dauer der Verbindung eine Verschlüsselung auf Verbindungsebene herzustellen und aufrechtzuerhalten.

Der wesentliche architektonische Unterschied besteht darin, dass das Security Manager Protocol (SMP) bei TAK-gesicherten Verbindungen nicht zum Einsatz kommt. Das Pairing, die Schlüsselgenerierung und das Bonding werden umgangen, sodass die Vertrauensbildung an eine Anwendung einer höheren Schicht delegiert werden kann, während Bluetooth weiterhin für Vertraulichkeit und Integrität auf der Verbindungsschicht sorgt. Geräte, die nach diesem Modell betrieben werden, sind daher verschlüsselt, jedoch weder gepaart noch verbunden.

Das Ergebnis ist eine Architektur, in der Verbindungen verschlüsselt werden können, ohne dass eine dauerhafte Vertrauensbeziehung hergestellt wird. Die Authentifizierung und der Schlüsselaustausch erfolgen außerhalb des Bluetooth-Sicherheitsrahmens, während die bestehenden Bluetooth® LE-Verschlüsselungsmechanismen unverändert bleiben.

Während das Modell für nicht gekoppelte Geräte festlegt, wie TAK in die Bluetooth® LE-Architektur integriert wird, wird die Unterstützung für dieses Modell durch die Einführung eines neuen Bluetooth® LE-Sicherheitsmodus formalisiert. Im folgenden Abschnitt wird beschrieben, wie der Sicherheitsmodus 4 das bestehende Bluetooth® LE-Sicherheitsframework erweitert.

6.2.3 LE-Sicherheitsmodi und die Einführung von Modus 4

Bluetooth® LE definiert mehrere Sicherheitsmodi, um unterschiedlichen Kommunikationsanforderungen gerecht zu werden. Vor der Einführung von Bluetooth® TAK unterstützte Bluetooth LE den Sicherheitsmodus 1 zur Sicherung von Punkt-zu-Punkt-LE-Verbindungen und den Sicherheitsmodus 3 zur Sicherung verschlüsselter Broadcast-Kommunikation. Zusammen boten diese Modi Mechanismen zum Schutz sowohl verbindungsorientierter als auch broadcast-basierter Kommunikationsszenarien.

Die Einführung des Modells für nicht gekoppelte Geräte erweitert dieses Rahmenwerk um einen neuen Sicherheitsmodus: den LE-Sicherheitsmodus 4. Im Gegensatz zu den bestehenden Sicherheitsmodi, die auf von Bluetooth verwalteten Sicherheitsverfahren wie dem Koppeln oder der Verteilung von Broadcast-Schlüsseln basieren, ermöglicht der Sicherheitsmodus 4 verschlüsselte Verbindungen unter Verwendung eines temporären Anwendungsschlüssels, der von einer Anwendung einer höheren Schicht bereitgestellt wird.

Sicherheitsmodus	Sicherheitsstufen	Beschreibung
Modus 1	Stufe 1	Keine Authentifizierung und keine Verschlüsselung
Stufe 2	Nicht authentifizierte Kopplung mit Verschlüsselung
Stufe 3	Authentifizierte Kopplung mit Verschlüsselung
Stufe 4	Authentifizierte LE Secure Connections-Verbindungen mit Verschlüsselung unter Verwendung eines 128-Bit-Verschlüsselungsschlüssels
Modus 3	Stufe 1	Keine Sicherheit
Stufe 2	Verwendung eines nicht authentifizierten Broadcast_Code
Stufe 3	Verwendung eines authentifizierten Broadcast_Code
Modus 4 (neu)	Stufe 2	Verschlüsselte temporäre Verbindung unter Verwendung eines temporären Anwendungsschlüssels (TAK)

Wie aus Tabelle 6.2.3 hervorgeht, ist der Sicherheitsmodus 1 nach wie vor der wichtigste Mechanismus zur Sicherung von Punkt-zu-Punkt-LE-Verbindungen. Die Sicherheit wird durch Bluetooth-Kopplungsverfahren gewährleistet, die vom Security Manager Protocol (SMP) verwaltet werden, wobei höhere Sicherheitsstufen strengere Anforderungen an die Authentifizierung und Verschlüsselung stellen. Die meisten Bluetooth®-LE-Geräte arbeiten heute im Sicherheitsmodus 1.

Der Sicherheitsmodus 3 befasst sich mit einer anderen Kategorie der Kommunikation, indem er isochrone Broadcast-Streams (BIS) absichert. Anstatt Verschlüsselungsschlüssel durch Pairing abzuleiten, verwendet Modus 3 einen Broadcast_Code, um den Zugriff auf verschlüsselte Broadcast-Inhalte zu steuern. Die Sicherheitsstufe bestimmt, ob der Broadcast_Code über einen authentifizierten oder einen nicht authentifizierten Mechanismus verteilt wird.

Die Einführung des Sicherheitsmodus 4 bringt einen grundlegend anderen Ansatz für die Sicherheit von Bluetooth® LE mit sich. Während im Sicherheitsmodus 1 das Vertrauensverhältnis durch Bluetooth-Kopplungsverfahren hergestellt und durch eine Bindung aufrechterhalten wird, geht Modus 4 davon aus, dass die Authentifizierung und der Schlüsselaufbau extern durch eine Spezifikation einer höheren Schicht durchgeführt werden. Bluetooth nutzt dann den daraus resultierenden „Transient Application Key“, um eine Verschlüsselung auf Verbindungsebene herzustellen, ohne eine Bindung einzurichten oder einen langfristigen Sicherheitszustand aufrechtzuerhalten. Dadurch eignet sich Modus 4 besonders gut für vorübergehende Interaktionen, bei denen eine sichere Kommunikation erforderlich ist, eine dauerhafte Vertrauensbeziehung jedoch nicht notwendig ist.

Zusammenfassend lässt sich sagen, dass der Sicherheitsmodus 4 nur dann verwendet werden soll, wenn die beteiligten Geräte durch eine Spezifikation einer höheren Schicht authentifiziert wurden, die in der Lage ist, ein gemeinsames Geheimnis mit einer Sicherheitsstärke von 128 Bit zu etablieren.

6.2.4 Aufbau einer TAK-gesicherten Verbindung

Sobald ein Gerät, das im Sicherheitsmodus 4 betrieben wird, einen Transient Application Key (TAK) von einer Anwendung einer höheren Schicht erhalten hat, kann dieser Schlüssel zum Aufbau einer verschlüsselten Bluetooth® LE-Verbindung verwendet werden. Im Gegensatz zu herkömmlichen Bluetooth-Sicherheitsverfahren erfolgen die Authentifizierung und der Schlüsselaufbau außerhalb des Bluetooth-Stacks. Bluetooth ist lediglich für die Anwendung der Verschlüsselung auf der Verbindungsschicht unter Verwendung des bereitgestellten Schlüssels zuständig.

Abbildung 6.2.4 veranschaulicht die Trennung zwischen der Authentifizierung auf höherer Ebene und dem Schutz auf der Bluetooth-Verbindungsschicht. Im Gegensatz zur auf dem Pairing basierenden Sicherheit wird das Vertrauensverhältnis außerhalb des Bluetooth-Stacks hergestellt, und ein gemeinsames Geheimnis wird abgeleitet, bevor die Bluetooth® LE-Verschlüsselungsstartprozedur eingeleitet wird. Wie in der Abbildung dargestellt, wird eine TAK-gesicherte Verbindung durch die folgende Abfolge von Vorgängen hergestellt:

Schritt 1: Verbindungsaufbau

Die beteiligten Geräte bauen zunächst eine standardmäßige Bluetooth® LE-ACL-Verbindung auf. Zu diesem Zeitpunkt ist die Verbindung noch nicht verschlüsselt.

Schritt 2: Authentifizierung auf höherer Ebene

Eine Anwendung einer höheren Schicht authentifiziert das Gegenstückgerät anhand von Verfahren, die in ihrer eigenen Spezifikation definiert sind. Je nach Anwendung kann der Authentifizierungsprozess inband oder über einen Out-of-Band-Mechanismus erfolgen. Dieser Authentifizierungsprozess ist unabhängig vom Bluetooth-Sicherheitsmanager und findet außerhalb des Bluetooth-Sicherheitsrahmens statt.

Schritt 3: TAK-Ableitung und Bereitstellung

Nach erfolgreicher Authentifizierung leiten beide Geräte ein gemeinsames, 128-Bit-Sicherheitsniveau aufweisendes Geheimnis ab oder ermitteln es. Dieses Geheimnis wird zum „Transient Application Key“ (TAK) und wird dem Bluetooth-Host zur Verwendung während des Verschlüsselungsaufbaus bereitgestellt. Funktional erfüllt der TAK während des Verschlüsselungsvorgangs denselben Zweck wie ein „Long Term Key“ (LTK).

Schritt 4: Start des Verschlüsselungsvorgangs

Der Host leitet mithilfe des TAK den standardmäßigen Startvorgang für die Bluetooth® LE-Verschlüsselung ein. Während dieses Vorgangs wird der TAK der Verbindungsschicht als Verschlüsselungsschlüssel übergeben, während die EDIV- und Rand-Werte auf Null gesetzt werden, da der Schlüssel nicht im Rahmen eines Bluetooth-Kopplungsvorgangs generiert wurde. Der Controller baut anschließend mithilfe des bestehenden Bluetooth® LE-Verschlüsselungsframeworks eine verschlüsselte Sitzung auf.

Schritt 5: Entsorgung von TAK

Nach dem Start des Verschlüsselungsvorgangs verwirft der Host den TAK. Der Controller verwendet den TAK zum Aufbau des Verschlüsselungskontexts und behält den TAK nach dem Aufbau des Verschlüsselungskontexts nicht bei. Die Anwendung auf höherer Ebene kann ihre Kopie des Schlüssels entsprechend ihrer eigenen Sicherheitsrichtlinie beibehalten oder verwerfen. Es werden keine Verbindungsinformationen erstellt und kein langfristiger Bluetooth-Sicherheitsstatus gespeichert.

6.2.5 Laufzeitverhalten und Sitzungsverwaltung

Sobald eine TAK-gesicherte Verbindung hergestellt wurde, unterscheidet sich ihr Laufzeitverhalten von dem einer herkömmlichen, auf Pairing basierenden Verbindung. Der wesentliche Unterschied besteht darin, dass Geräte, die im Sicherheitsmodus 4 betrieben werden, zur Aufrechterhaltung des Sicherheitsstatus weder auf Pairing noch auf Bonding noch auf das Security Manager Protocol (SMP) zurückgreifen. Stattdessen erfolgt der Betrieb der Verbindung auf der Grundlage einer von der Anwendung der höheren Schicht definierten Sicherheitsrichtlinie in Verbindung mit dem während der Authentifizierung festgelegten Transient Application Key.

Bei der Festlegung, wie eine Verbindung gesichert werden soll, berücksichtigt das Gerät den Bonding-Status des Gegenstücks sowie die Anforderungen der Anwendung auf höherer Ebene. Ist das Gegenstück bereits gebondet, nutzt die Verbindung das bestehende, auf der Paarung basierende Sicherheitsmodell und den gebondeten Langzeitschlüssel (LTK). Ein TAK wird für eine gekoppelte Verbindung nicht verwendet. Ist das Gegenstückgerät nicht gekoppelt und ist die Anwendung der höheren Schicht so konfiguriert, dass sie das nicht gekoppelte Sicherheitsmodell verwendet, läuft die Verbindung im Sicherheitsmodus 4.

Im Gegensatz zum Sicherheitsmodus 1 leiten Geräte, die im Sicherheitsmodus 4 betrieben werden, keine Bluetooth-Kopplungsvorgänge ein, um die Sicherheitsanforderungen zu erfüllen. Wenn eine Verschlüsselung erforderlich ist und ein gültiger TAK verfügbar ist, aktiviert der Host die Verschlüsselung der Verbindungsschicht unter Verwendung des TAK, bevor der Zugriff auf den angeforderten Dienst gewährt wird. Ist kein TAK verfügbar, wird die Dienstanforderung abgebrochen, anstatt auf die Kopplung zurückzugreifen.

Ebenso wird bei einer Verbindung, die im Sicherheitsmodus 4 betrieben wird, keine Kopplung zur Herstellung der Sicherheit verwendet. Ist eine Verschlüsselung erforderlich, muss ein gültiger TAK vorliegen, um die Verschlüsselung auf der Verbindungsschicht herzustellen. Die Kopplung wird nicht als alternativer Mechanismus zur Herstellung der Sicherheit bei einer Verbindung verwendet, die im Sicherheitsmodus 4 betrieben wird.

Entscheidungen über den Zugriff auf Dienste basieren sowohl auf dem aktuellen Status der Verbindung als auch auf den in der Spezifikation der höheren Schicht festgelegten Richtlinien. Wenn ein Dienst eine Verschlüsselung erfordert, muss die Verbindung verschlüsselt sein, bevor der Zugriff gewährt wird. Bei Authentifizierungsanforderungen wird eine TAK-gesicherte Verbindung nur dann akzeptiert, wenn diese Anforderungen gemäß den Richtlinien der höheren Schicht, die für den Aufbau von Vertrauen zuständig ist, erfüllt sind.

Das Laufzeitverhalten des Sicherheitsmodus 4 unterscheidet sich grundlegend von dem des Sicherheitsmodus 1 und lässt sich wie in Tabelle 6.2.5 zusammengefasst darstellen.

Szenario	Verhalten im Sicherheitsmodus 4
Keine Verschlüsselung erforderlich	Die Serviceanfrage wird wie gewohnt bearbeitet
Verschlüsselung erforderlich und TAK verfügbar	Die Verschlüsselung auf der Link-Schicht wird mithilfe des TAK aktiviert
Verschlüsselung erforderlich, aber kein TAK verfügbar	Die Serviceanfrage wurde abgebrochen
Authentifizierung erforderlich	Entscheidung unterliegt einer übergeordneten Richtlinie
Anfrage zur Kopplung erhalten	Antrag abgelehnt
Sicherheitsupdate durch Kopplung	Nicht zulässig

Daher fungiert der Sicherheitsmodus 4 als eigenständiges Sicherheitsmodell und nicht als Variante der paarungsbasierten Sicherheit. Das Vertrauensverhältnis wird extern durch die Anwendung auf einer höheren Ebene hergestellt, während Bluetooth lediglich dafür zuständig ist, den Schutz auf der Verbindungsschicht während der gesamten Dauer der Verbindung sicherzustellen.

6.2.6 GATT-Aspekte bei TAK-gesicherten Verbindungen

Der sitzungsorientierte Charakter von TAK wirkt sich auf das Verhalten von Anwendungen auf der GATT-Ebene aus. Da Geräte, die im Sicherheitsmodus 4 betrieben werden, keine Verbindungen herstellen, behält der Bluetooth-Stack den Status auf Dienstebene zwischen den Verbindungen nicht bei. Jede durch TAK gesicherte Verbindung wird daher als eigenständige Sitzung behandelt.

Dieses Verhalten zeigt sich insbesondere bei der Handhabung der Einstellungen für die Client-Merkmalskonfiguration (CCC). Im Sicherheitsmodus 4 gelten CCC-Konfigurationen als vorübergehend und werden bei Beendigung der Verbindung verworfen. Anwendungen, die Benachrichtigungen oder Anzeigen benötigen, müssen daher die entsprechenden CCC-Werte bei jedem Aufbau einer neuen TAK-gesicherten Verbindung neu konfigurieren.

Der Sicherheitsmodus 4 erfordert zudem die Verwendung der Eigenschaft „LE GATT Security Levels“, um die Sicherheitsanforderungen des GATT-Servers zu übermitteln. Diese Eigenschaft ermöglicht es dem GATT-Server, die für den Zugriff auf seine Dienste und Attribute erforderliche Sicherheitsstufe anzugeben, wenn er über eine TAK-gesicherte Verbindung betrieben wird.

Daher führt die TAK-basierte Sicherheit ein vollständig sitzungsorientiertes Betriebsmodell ein, bei dem sowohl der Sicherheitsstatus als auch die zugehörige Dienstkonfiguration nur für die Dauer einer Verbindung bestehen. Wenn die Verbindung beendet wird, werden sowohl der TAK als auch jeglicher sitzungsspezifische Dienststatus verworfen.

6.2.7 Sicherheitsaspekte

Ein TAK wird verwendet, um die Verschlüsselung auf der Link-Schicht für eine Bluetooth® LE-Verbindung herzustellen und aufrechtzuerhalten. Sobald die Verschlüsselung hergestellt ist, profitiert die Verbindung von den Schutzmaßnahmen hinsichtlich Vertraulichkeit und Integrität, die das Bluetooth® LE-Verschlüsselungsframework bietet.

Die Spezifikation der höheren Schicht unter Verwendung von TAK ist dafür zuständig, die Vertrauensbeziehung herzustellen und festzulegen, wie der TAK generiert, bezogen und dem Bluetooth-Host bereitgestellt wird. Dazu gehören auch die Authentifizierungs- und Sicherheitsverfahren, die zum Schutz des Schlüsselaufbauprozesses erforderlich sind.

Daher ist eine Spezifikation auf höherer Ebene unter Verwendung von TAK für Folgendes zuständig:

• Authentifizierung des Gegen geräts
• Ableitung oder Ermittlung des gemeinsamen Geheimnisses, das als TAK verwendet wird
• Schutz vor Man-in-the-Middle-Angriffen
• Festlegung der Richtlinie, die regelt, wann und wie ein TAK an den Bluetooth-Host übermittelt wird

Eine wesentliche Auswirkung der TAK-Architektur besteht darin, dass die Authentifizierung und der Schutz vor Man-in-the-Middle-Angriffen nicht durch die Bluetooth-Kopplungsverfahren, sondern durch die Spezifikation der höheren Schicht gewährleistet werden. Die Sicherheitseigenschaften einer TAK-gesicherten Verbindung hängen daher von den Authentifizierungs- und Schlüsselaufbauverfahren ab, die in der Spezifikation der höheren Schicht verwendet werden.

Diese Trennung ermöglicht es, dass Spezifikationen höherer Schichten Authentifizierungs- und Vertrauensmechanismen definieren, die für ihre jeweilige Anwendung geeignet sind, während gleichzeitig die standardisierte Bluetooth®-Link-Layer-Verschlüsselung zum Schutz der über die Verbindung ausgetauschten Daten genutzt wird.

6.3 Zusammenfassung

Der „Bluetooth® Transient Application Key“ führt ein neues Sicherheitsmodell ohne Kopplung ein, das verschlüsselte Bluetooth® LE-Verbindungen ermöglicht, ohne dass eine Kopplung oder ein Bonding erforderlich ist. Die Authentifizierung und der Schlüsselaufbau erfolgen durch eine Anwendung auf einer höheren Ebene, während Bluetooth mithilfe des daraus resultierenden Schlüssels Vertraulichkeit und Integrität auf der Verbindungsebene gewährleistet.

Um diese Funktion zu unterstützen, führt Bluetooth® LE den Sicherheitsmodus 4 ein, der das bestehende Sicherheitsframework um eine neue Option erweitert, die speziell für vorübergehende Interaktionen konzipiert ist. Im Gegensatz zur herkömmlichen, auf Pairing basierenden Sicherheit werden im Modus 4 keine dauerhaften Vertrauensbeziehungen aufgebaut und kein langfristiger Sicherheitsstatus beibehalten.

Durch die Trennung des Vertrauensaufbaus vom Transportschutz erweitert TAK die Bluetooth-Sicherheitsarchitektur, um eine sichere, sitzungsbasierte Kommunikation zu ermöglichen, ohne dass dauerhafte Vertrauensbeziehungen erforderlich sind. TAK ersetzt bestehende, auf dem Pairing basierende Sicherheitsmodelle nicht, sondern ergänzt sie, indem es einen alternativen Ansatz für Anwendungen bietet, die Vertrauen außerhalb des Bluetooth-Stacks aufbauen.

Die Einführung sowohl des „Transient Application Key“ als auch des „Security Mode 4“ stellt daher eine wichtige Weiterentwicklung der Bluetooth® LE-Sicherheitsarchitektur dar und ermöglicht sichere, verschlüsselte, sitzungsbasierte Interaktionen, ohne dass ein Pairing, ein Bonding oder dauerhafte Vertrauensbeziehungen erforderlich sind.

7. Fehlerbehebung bei Bluetooth®-Verschlüsselungsprodukten (EPD)

7.1 Hintergrund

Die Verschlüsselung spielt eine entscheidende Rolle beim Schutz von Benutzerdaten und der Kommunikation. Gleichzeitig stellt sie eine Herausforderung für die Protokollanalyse dar, da aufgezeichneter Datenverkehr ohne Zugriff auf die Anmeldedaten, die die Verbindung schützen, nicht vollständig entschlüsselt werden kann. Bluetooth® Encryption Product Debugging (EPD) löst dieses Problem, indem es autorisierten Debugging-Tools eine standardisierte Methode bietet, auf die aktiven Verschlüsselungsinformationen zuzugreifen, die für die Analyse von verschlüsseltem Bluetooth-Datenverkehr erforderlich sind.

In der Vergangenheit konnte verschlüsselter Bluetooth-Datenverkehr häufig analysiert werden, indem man auf die bei der Kopplung festgelegten langfristigen Sicherheitszugangsdaten, wie beispielsweise den Langzeitschlüssel (LTK), zurückgriff. In vielen Einsatzszenarien lieferte der Zugriff auf diese Zugangsdaten ausreichende Informationen für Protokollanalysatoren und Debugging-Tools, um den Verschlüsselungsstatus einer Verbindung zu rekonstruieren und Interoperabilitätstests, Produktvalidierungen sowie Maßnahmen zur Fehlerbehebung zu unterstützen.

Da sich die Bluetooth-Verschlüsselung jedoch ständig weiterentwickelt, werden aktive Verschlüsselungsdaten zunehmend innerhalb des Controllers generiert und verwaltet. In HCI-basierten Architekturen (Host Controller Interface) sind diese Daten für den Host und externe Debugging-Tools möglicherweise nicht zugänglich, was die Analyse und Fehlerbehebung des verschlüsselten Datenverkehrs erschwert. Dies ist insbesondere bei EKS (Encryption Key Schedule) relevant, wo der Verschlüsselungsstatus, der eine Verbindung schützt, innerhalb des Controllers abgeleitet und verwaltet wird. Ohne standardisierten Zugriff auf die aktiven Verschlüsselungsdaten benötigt ein Host-Entwickler möglicherweise proprietäre Mechanismen, um Controller-Schlüssel zur Entschlüsselung des erfassten Funkverkehrs zu erhalten. EPD löst dieses Problem, indem es einen standardisierten Mechanismus bereitstellt, über den der Host den aktiven Verschlüsselungsstatus abrufen kann. Dadurch können Testaufbauten sowohl den Funkverkehr als auch den HCI-Verkehr erfassen und automatisierte Dekodierung, Fehlerbehebung sowie Interoperabilitätstests unterstützen.

Um dieser Herausforderung zu begegnen, führt Bluetooth® Encryption Product Debugging (EPD) einen standardisierten Mechanismus ein, der es dem Controller ermöglicht, aktive Verschlüsselungsdaten zu Debugging-Zwecken an den lokalen Host zu melden. Durch die Bereitstellung von Einblicken in den aktuellen Verschlüsselungsstatus, der eine Verbindung schützt, trägt EPD dazu bei, die Funktionen zur Protokollanalyse und zum Debugging der Interoperabilität aufrechtzuerhalten, ohne die Funktionsweise der Bluetooth-Verschlüsselung zu verändern.

7.2 Technischer Überblick

7.2.1 Einblick in den aktiven Verschlüsselungsstatus

Bluetooth® EPD bietet Einblick in die Verschlüsselungsinformationen, die eine verschlüsselte Bluetooth®-Verbindung aktiv schützen. Anstatt Kopplungsprotokolle, Bonding-Datenbanken oder andere historische Sicherheitsinformationen offenzulegen, konzentriert sich EPD auf den aktuellen Verschlüsselungsstatus, der vom Controller verwaltet wird und zum Schutz des Datenaustauschs zwischen verbundenen Geräten dient.

Abbildung 7.2.1 veranschaulicht, wie sich die Verschlüsselungstransparenz von der herkömmlichen Bluetooth® LE-Verschlüsselung hin zur auf dem Encryption Key Schedule (EKS) basierenden Verschlüsselung entwickelt.

Bei der herkömmlichen LE-Verschlüsselung beginnt die Fehlersuche häufig mit dem Einblick in den Langzeit-Schlüssel (LTK). Da sich der aktive Verschlüsselungszustand in der Regel aus dem LTK in Verbindung mit den beim Aufbau der Verschlüsselung ausgetauschten Informationen rekonstruieren lässt, sind Protokollanalysatoren in der Regel in der Lage, den Sitzungsschlüssel abzuleiten und den erfassten Datenverkehr zu entschlüsseln.

Bei EKS wird der Prozess jedoch komplexer. Wie in Abbildung 7.2.1 dargestellt, führt EKS eine interne Schlüsselhierarchie ein, in der aus ECDH abgeleitete gemeinsame Geheimnisse zusammen mit anderen kryptografischen Eingaben verwendet werden, um Verkehrsgeheimnisse abzuleiten, aus denen anschließend der Sitzungsschlüssel und der Initialisierungsvektor (IV) generiert werden, die die Verbindung schützen. Unter diesen Umständen reichen Einblicke in langfristige Anmeldedaten allein möglicherweise nicht mehr aus, um den aktuellen Verschlüsselungsstatus zu bestimmen, der den Benutzerverkehr gerade schützt.

EPD begegnet dieser Herausforderung, indem es Einblick in den aktuellen Verschlüsselungsstatus gewährt, anstatt die bei der Kopplung oder dem Bonding verwendeten Langzeit-Zugangsdaten offenzulegen. Anstelle des LTK meldet EPD den Sitzungsschlüssel und den IV, die mit der verschlüsselten Verbindung verbunden sind. Dadurch können Debugging-Tools stets mit dem vom Controller aktiv verwalteten Verschlüsselungskontext synchronisiert bleiben.

7.2.2 EKS-basierte Verschlüsselungsmodi

Um den in Abbildung 7.2.1 dargestellten aktiven Verschlüsselungsstatus besser zu verstehen, ist es hilfreich, kurz zu betrachten, wie Verschlüsselungszugangsdaten bei Verwendung des Encryption Key Schedule (EKS)-Frameworks eingerichtet werden.

Wenn beide Geräte EKS unterstützen, wird die Verschlüsselung mithilfe des Verfahrens „Encryption Start with Key Schedule“ eingerichtet. Im Gegensatz zur herkömmlichen LE-Verschlüsselung führt EKS vom Controller verwaltete Schlüsselableitungsverfahren ein, die ECDH-generierte gemeinsame Geheimnisse und zusätzliche kryptografische Eingaben verwenden, um den Verschlüsselungszustand zum Schutz einer Verbindung herzustellen. Diese Verfahren generieren letztendlich den Sitzungsschlüssel und den IV, die zur Verschlüsselung des Datenverkehrs verwendet werden.

EKS unterstützt zwei Bereitstellungsmodelle.

• EKS mit Langzeitschlüssel (LTK)

In diesem Modus wird ein vom Host bereitgestellter LTK zusammen mit den durch ECDH generierten gemeinsamen Geheimnissen und anderen Verschlüsselungsdaten, die während des Aufbaus der Verschlüsselung ausgetauscht werden, in den Ableitungsprozess einbezogen. Das daraus resultierende Verkehrsgeheimnis wird anschließend zur Ableitung des Sitzungsschlüssels und des IV verwendet, die die Verbindung schützen.

• Opportunistische Verschlüsselung

In diesem Modus wird die Verschlüsselung über das EKS-Framework hergestellt, ohne dass ein zuvor verteilter LTK erforderlich ist. Die Spezifikation definiert den LTK-Eingabewert als einen Schlüssel mit dem Wert Null, während der Sitzungsschlüssel und der IV aus dem ECDH-Schlüsselaustausch und den zugehörigen EKS-Verfahren abgeleitet werden.

Unabhängig davon, wie die Verschlüsselung eingerichtet wird, erzeugen beide Bereitstellungsmodelle letztendlich einen aktiven Verschlüsselungszustand innerhalb des Controllers, der durch den Sitzungsschlüssel und den IV zum Schutz der Verbindung dargestellt wird. Dies sind die Werte, die von EPD gemeldet und über die Host-Controller-Schnittstelle (HCI) für Debugging-Tools bereitgestellt werden.

7.2.3 Bluetooth®-EPD-Meldemechanismus

Um einen standardisierten Zugriff auf den aktuellen Verschlüsselungsstatus zu ermöglichen, führt EPD ein schlankes Berichts-Framework für die Host Controller Interface (HCI) ein. Die Funktion besteht aus zwei HCI-Befehlen zur Steuerung des Berichtsverhaltens und einem HCI-Ereignis, über das Verschlüsselungsinformationen an den Host übermittelt werden.

EPD ist für den Einsatz in kontrollierten Entwicklungs-, Test- und Interoperabilitätsumgebungen vorgesehen und sollte während des normalen Produktbetriebs nicht aktiviert werden.

Tabelle 7.2.3a fasst die durch die EPD-Funktion eingeführten HCI-Elemente zusammen.

Komponente	Zweck
Befehl zum Auslesen des Debug-Berichtsmodus für den Verschlüsselungsschlüssel	Liest die aktuelle EPD-Berichtskonfiguration ein
Befehl zum Schreiben des Verschlüsselungsschlüssels im Debug-Berichtsmodus	Aktiviert oder deaktiviert die Verschlüsselungsberichterstattung
Ereignis „Debug-Bericht zum Verschlüsselungsschlüssel“	Gibt Verschlüsselungsinformationen zu einer aktiven Verbindung aus

Wie aus Tabelle 7.2.3a hervorgeht, ermöglichen die Befehle „Read“ und „Write Encryption Key Debug Reporting Mode“ dem Host, das Berichtsverhalten abzufragen und zu konfigurieren, während das Ereignis „Encryption Key Debug Report“ die tatsächlichen Verschlüsselungsinformationen bereitstellt, die von Debugging-Tools benötigt werden. Zusammen bilden diese Ergänzungen einen standardisierten Mechanismus zur Bereitstellung von Verschlüsselungsinformationen über HCI, ohne dass herstellerspezifische Diagnosetools erforderlich sind.

Das Ereignis „Encryption Key Debug Report“ enthält Informationen zum aktuellen Verschlüsselungsstatus einer Verbindung. Wie in Tabelle 7.2.3b dargestellt, meldet EPD den Sitzungsschlüssel und den IV, die derzeit einer verschlüsselten Verbindung zugeordnet sind, und nicht langfristige Anmeldedaten wie den LTK. Diese Werte stellen den vom Controller aktiv verwalteten Verschlüsselungsstatus dar und entsprechen direkt den Informationen, die zur Ver- und Entschlüsselung des Datenverkehrs verwendet werden.

Parameter	Beschreibung
Verbindungs-Handle	Zeigt die verschlüsselte Verbindung an
Sitzungsschlüssel	Mit der Verbindung verbundener Verschlüsselungsschlüssel
Länge des Sitzungsschlüssels	Länge des Sitzungsschlüssels
IV	Mit der Verbindung verbundener Initialisierungsvektor
IV Länge	Länge des Initialisierungsvektors

7.2.4 Verhalten bei der Erzeugung von Ereignissen

Bluetooth® EPD folgt einem ereignisgesteuerten Berichtsmodell. Anstatt Verschlüsselungsinformationen kontinuierlich zu melden, generiert der Controller ein „Encryption Key Debug Report“-Ereignis nur dann, wenn neue Verschlüsselungsdaten für eine Verbindung aktiv werden. Dieser Ansatz stellt sicher, dass Debugging-Tools aktualisierte Verschlüsselungsinformationen erhalten, sobald sich der aktive Verschlüsselungsstatus ändert, und vermeidet gleichzeitig unnötigen Meldeaufwand.

Auslöseereignis	Debug-Bericht zum Verschlüsselungsschlüssel erstellt
HCI_Verschlüsselung_Änderung	Ja
HCI_Verschlüsselungsschlüssel_Aktualisierung_abgeschlossen	Ja
HCI_LE_CIS_Etabliert	Ja

Wie aus Tabelle 7.2.4 hervorgeht, ist die Erstellung von Berichten direkt an Änderungen des Verschlüsselungsstatus einer Verbindung gekoppelt. Wenn die Verschlüsselung erstmals aktiviert wird, wenn ein bestehender Sitzungsschlüssel aktualisiert wird oder wenn ein neuer verschlüsselter CIS verfügbar wird, erstellt der Controller einen Verschlüsselungsschlüssel-Debug-Bericht, der die mit der Verbindung verbundenen Verschlüsselungsinformationen enthält.

Dieser ereignisgesteuerte Ansatz trägt dazu bei, dass Debugging-Tools während der gesamten Laufzeit einer Verbindung stets mit dem aktuellen Verschlüsselungsstatus synchronisiert bleiben. Da sich die Verschlüsselungsdaten im Laufe der Zeit ändern, werden zusätzliche Berichte erstellt, um den aktualisierten Sitzungsschlüssel und den IV, die die Verbindung schützen, widerzuspiegeln.

Da Berichte nur dann erstellt werden, wenn sich der Verschlüsselungsstatus ändert, minimiert EPD den Implementierungsaufwand und stellt Debugging-Tools dennoch die Informationen zur Verfügung, die zur Analyse des verschlüsselten Bluetooth®-Datenverkehrs erforderlich sind.

7.2.5 Arbeitsablauf für die Bluetooth®-EPD-Berichterstattung

Während in den vorangegangenen Abschnitten die von EPD gemeldeten Informationen und die Bedingungen, unter denen die Meldung erfolgt, beschrieben werden, lässt sich die gesamte Interaktion zwischen dem Host und dem Controller am besten anhand des in Abbildung 7.2.5 dargestellten Meldeablaufs nachvollziehen.

Abbildung 7.2.5 veranschaulicht einen typischen Ablauf der EPD-Berichterstellung. Nachdem der Host die Debug-Berichterstellung für Verschlüsselungsschlüssel aktiviert hat, generiert der Controller jedes Mal, wenn ein neuer Sitzungsschlüssel für eine verschlüsselte Verbindung erstellt wird, einen Debug-Bericht für den Verschlüsselungsschlüssel und übermittelt den zugehörigen Sitzungsschlüssel sowie den Initialisierungsvektor (IV) an den Host. Dieser ereignisgesteuerte Arbeitsablauf ermöglicht es Debugging-Tools, während der gesamten Lebensdauer der Verbindung mit dem aktuellen Verschlüsselungsstatus synchron zu bleiben.

Der Arbeitsablauf lässt sich wie folgt zusammenfassen:

1. Der Host ermöglicht die EPD-Berichterstellung mithilfe des Befehls „Write Encryption Key Debug Reporting Mode“
2. Eine verschlüsselte Verbindung wird unter Verwendung der Standard-Bluetooth-Verschlüsselungsverfahren hergestellt.
3. Für die verschlüsselte Verbindung wird ein neuer Sitzungsschlüssel aktiviert
4. Der Controller erstellt einen Debug-Bericht zum Verschlüsselungsschlüssel, der den Sitzungsschlüssel und den IV enthält, die der Verbindung zugeordnet sind.
5. Der Host empfängt den Bericht und kann Informationen an Protokollanalysatoren, Interoperabilitätstestsysteme oder andere Debugging-Tools weiterleiten.

Bei der Erstellung nachfolgender Sitzungsschlüssel können zusätzliche Berichte generiert werden, wodurch sichergestellt wird, dass die Debugging-Tools mit den Änderungen am aktiven Verschlüsselungszustand synchronisiert bleiben. Der aktive Verschlüsselungszustand einer CIS-Verbindung kann sich beispielsweise ändern, wenn der PHY-Modus auf HDT umgeschaltet wird oder von diesem zurückgeschaltet wird, oder wenn eine freiwillige Schlüsselaktualisierung ausgelöst wird. In diesen Fällen stellt das EPD dem Host den aktualisierten Sitzungsschlüssel und den IV zur Verfügung, sodass die Debugging-Tools den verschlüsselten Datenverkehr weiterhin unter Verwendung des aktuellen Verschlüsselungszustands entschlüsseln können.

7.3 Zusammenfassung

Bluetooth® Encryption Product Debugging (EPD) führt einen standardisierten Mechanismus ein, mit dem der aktive Verschlüsselungsstatus einer verschlüsselten Bluetooth®-Verbindung über die Host Controller Interface (HCI) offengelegt wird. Anstatt auf die Einsicht in langfristige Anmeldedaten wie den Long-Term Key (LTK) zurückzugreifen, bietet EPD direkten Zugriff auf den Sitzungsschlüssel und den Initialisierungsvektor (IV), die die Verbindung derzeit schützen.

Da sich die Bluetooth-Verschlüsselung durch Mechanismen wie den „Encryption Key Schedule“ (EKS) weiterentwickelt, können die Zugangsdaten zum Schutz des Benutzerdatenverkehrs möglicherweise über vom Controller verwaltete kryptografische Verfahren eingerichtet und gepflegt werden. Unter diesen Umständen reicht die Einsicht in langfristige Zugangsdaten allein möglicherweise nicht mehr aus, um eine Protokollanalyse durchzuführen und Fehler bei der Interoperabilität zu beheben. EPD begegnet dieser Herausforderung, indem es eine standardisierte Einsicht in den vom Controller verwalteten aktiven Verschlüsselungsstatus ermöglicht.

Mithilfe von zwei HCI-Befehlen und einem speziellen Berichtsereignis ermöglicht EPD, dass Protokollanalysatoren, Interoperabilitätstestsysteme und Debugging-Tools stets mit Änderungen an verschlüsselten Verbindungen synchronisiert bleiben, ohne dass herstellerspezifische Protokollierungsmechanismen oder proprietäre Debugging-Schnittstellen erforderlich sind.

Durch die Entkopplung der Debugging-Transparenz vom zugrunde liegenden Verfahren zum Aufbau der Verschlüsselung stellt EPD sicher, dass verschlüsselter Bluetooth-Datenverkehr sowohl bei herkömmlichen LE-Verschlüsselungs- als auch bei EKS-basierten Verschlüsselungsimplementierungen weiterhin beobachtbar und debuggbar bleibt.

8. Erläuterung der Bluetooth®-Leistungsklassen

Mit Bluetooth® Core 7.0 werden die bisherigen Definitionen der Bluetooth-Leistungsklassen aus der Spezifikation gestrichen. Zwar wurden Leistungsklassen lange Zeit als informative Klassifizierungen zur Beschreibung der Sendeleistung eines Geräts verwendet, doch basierten die Bluetooth-Zertifizierung und die Konformitätsprüfung stets auf den geltenden Funkvorschriften, die in der Bluetooth® Core-Spezifikation definiert sind. Daher hat die Streichung der Definitionen der Leistungsklassen keine Auswirkungen auf die Zertifizierungsverfahren, die Interoperabilität oder das Verhalten der Geräte.

Bluetooth®-Geräte werden seit jeher bestimmten Leistungsklassen zugeordnet, die die Geräte entsprechend ihrer maximalen Sendeleistung kategorisieren. Für BR/EDR- und LE-Geräte sind diese Klassifizierungen in den Tabellen 8a und 8b aufgeführt.

Leistungsklasse	Anforderungen
1	100 mW (20 dBm) ≥ Pmax > 2,5 mW (4 dBm)
2	2,5 mW (4 dBm) ≥ Pmax > 1 mW (0 dBm)
3	1 mW (0 dBm) ≥ Pmax

Leistungsklasse	Anforderungen
1	100 mW (+20 dBm) ≥ Pmax > 10 mW (+10 dBm)
1.5	10 mW (+10 dBm) ≥ Pmax > 2,5 mW (+4 dBm)
2	2,5 mW (+4 dBm) ≥ Pmax > 1 mW (0 dBm)
3	1 mW (0 dBm) ≥ Pmax ≥ 0,01 mW (-20 dBm)

Obwohl in Produktdokumentationen und Marketingmaterialien häufig darauf Bezug genommen wird, dienten Leistungsklassen bislang eher als beschreibende Klassifizierungen denn als Konformitätsanforderungen. Die Bluetooth-Zertifizierung und -Konformität basierten stets auf den geltenden Funkvorschriften, die in der Bluetooth® Core-Spezifikation definiert sind. Aus diesem Grund werden in der Bluetooth® Core 7.0 die bisherigen Definitionen der Leistungsklassen aus der Spezifikation gestrichen.

Daher hat die Streichung der Definitionen der Leistungsklassen keine Auswirkungen auf Qualifizierungsverfahren, Interoperabilitätsanforderungen, Anforderungen an die Funkleistung oder das Verhalten der Geräte. Vielmehr verdeutlicht diese Änderung die Unterscheidung zwischen informativen Produktklassifizierungen und normativen Bluetooth-Anforderungen.

9. Schlussfolgerung

Bluetooth® Core 7.0 erweitert Bluetooth® LE in mehreren Schlüsselbereichen, darunter Datendurchsatz, isochroner Transport, Sicherheit und Implementierungsunterstützung. HDT erhöht den Datendurchsatz erheblich und bleibt dabei in die bestehende Bluetooth® LE-Architektur integriert; IPU ermöglicht es dem aktiven CIS-Transport, sich an wechselnde Betriebsanforderungen anzupassen, ohne dass der Datenstrom neu aufgebaut werden muss; und EKS bietet einen flexibleren Rahmen für den Aufbau, die Trennung und die Aktualisierung von Verschlüsselungsmaterial. TAK erweitert das Bluetooth-Sicherheitsmodell weiter, indem es sichere, sitzungsorientierte Interaktionen ohne Pairing oder Bonding ermöglicht, während EPD standardisierte Einblicke in den aktiven Verschlüsselungsstatus bietet, um Protokollanalyse, Fehlerbehebung und Interoperabilitätstests zu unterstützen.

Insgesamt setzen diese Verbesserungen die Weiterentwicklung von Bluetooth fort, um eine höhere Leistung, größere Anpassungsfähigkeit sowie flexiblere Sicherheits- und Entwicklungsmodelle zu unterstützen und gleichzeitig die Grundlagen der Bluetooth-Architektur zu bewahren. Bluetooth® Core 7.0 erweitert somit die Funktionen von Bluetooth und gewährleistet gleichzeitig die Interoperabilität und architektonische Konsistenz, auf denen die Technologie basiert.

10. Referenzen

Artikel	Standort
Bluetooth®-Kernspezifikation v7.0	https://www.bluetooth.com/specifications/specs/core-specification-v7/