Technischer Überblick über Bluetooth® mit hohem Datendurchsatz

Version:	1.0
Erscheinungsdatum:	3. November 2026
Autor:	Alfredo Perez

1. Einleitung

Bluetooth® ist eine vielseitige, weit verbreitete Funktechnologie, die eine breite Palette von Anwendungen und Einsatzmöglichkeiten in den Bereichen Audio, Wearables, Mensch-Maschine-Schnittstellen, Smart Home, Industrie, Automobil und vielen anderen Marktsegmenten ermöglicht. Ihr Erfolg beruht auf grundlegenden Eigenschaften wie Energieeffizienz, Interoperabilität, Benutzerfreundlichkeit sowie einer kontinuierlichen Weiterentwicklung ihrer Funktionen und Leistungsfähigkeit. Gemeinsam haben diese Eigenschaften es der Bluetooth-Technologie ermöglicht, zu wachsen, robuste Entwicklungs- und Produktökosysteme zu ermöglichen und zu unterstützen sowie das Vertrauen von Unternehmen und Verbrauchern weltweit zu gewinnen.

Doch auch die Landschaft der drahtlosen Anwendungen entwickelt sich weiter. Systeme, in denen sich die Bluetooth-Konnektivität seit langem bewährt hat, werden immer ausgefeilter und erzeugen, verarbeiten und verwalten weitaus mehr Daten. Auf dem Audiomarkt beispielsweise gehen die Lösungen in Richtung höherer Klangtreue und Multi-Stream-Anwendungsfälle, die eine größere Datenkapazität und schnellere Kommunikation erfordern, um nahtlose Leistung und Erlebnisse zu bieten. Für Bluetooth entsteht dadurch die Notwendigkeit, steigende Durchsatzanforderungen zu unterstützen, die über die bestehenden Fähigkeiten hinausgehen. Um diesem Bedarf gerecht zu werden, führt die Bluetooth Special Interest Group (SIG) eine umfassende Architektur- und Leistungsverbesserung für Bluetooth LE ein, die als Bluetooth® High Data Throughput (HDT) bekannt ist.

Seit der Einführung des LE 2M PHY im Jahr 2016 lag die von Bluetooth LE unterstützte maximale PHY-Bitrate bei 2 Mbit/s. Mit Bluetooth® HDT werden die Leistung und die Funktionen von Bluetooth LE erheblich erweitert: Die maximale PHY-Bitrate wird um fast das Vierfache erhöht, während gleichzeitig die Kapazität, Energieeffizienz und Zuverlässigkeit verbessert werden. Insgesamt verkürzt Bluetooth HDT die Datenübertragungszeiten, unterstützt anspruchsvollere Anwendungslasten und schafft Spielraum für zukünftige Innovationen. Damit legt es den Grundstein dafür, dass sich die Bluetooth-Technologie-Roadmap entsprechend den Anforderungen moderner Anwendungen weiterentwickeln kann.

Dieses Dokument bietet einen allgemeinen technischen Überblick über „Bluetooth High Data Throughput“ und soll den Lesern dabei helfen, ein grundlegendes Verständnis für diesen wichtigen Meilenstein in der Bluetooth-Technologie zu entwickeln.

2. Hintergrund

Grundsätzlich liegt der Hauptvorteil einer Erhöhung des Durchsatzes in einem Kommunikationssystem auf der Hand: Ein höherer Durchsatz verkürzt die Zeit, die für die Übertragung einer festen Datenmenge zwischen Geräten benötigt wird, oder ermöglicht umgekehrt den Austausch größerer Datenmengen innerhalb eines bestimmten Zeitraums. Die schnellere Durchführung von Übertragungen bietet jedoch noch weitere wertvolle Vorteile. So sind beispielsweise Sender und Empfänger im System für kürzere Zeiträume aktiv, was zu einem geringeren Energieverbrauch führen kann. Zudem trägt dies dazu bei, Sendezeit freizusetzen, die über verwaltete Koexistenzmechanismen für zusätzliche Kommunikationsverbindungen oder zur Nutzung durch andere am selben Standort befindliche Systeme neu zugewiesen werden kann.

In der Praxis erfordert die Steigerung des Durchsatzes eines Kommunikationssystems die Berücksichtigung von drei grundlegenden Entwurfsvariablen: Bandbreite (BW), Signal-Rausch-Verhältnis (SNR) und spektrale Effizienz. Shannons Theorem¹ formalisiert, wie BW und SNR die Kanalkapazität beeinflussen, und zeigt, dass die Kapazität linear mit der BW und logarithmisch mit dem SNR zunimmt. Die Annäherung an die durch Shannons Theorem vorhergesagte Kapazität hängt jedoch vom Erreichen einer hohen spektralen Effizienz ab. Die spektrale Effizienz ist ein Maß dafür, wie viele Bits pro Sekunde pro Hertz verfügbarer Bandbreite (bps/Hz) übertragen werden können. In realen Systemen hängt die spektrale Effizienz von Entscheidungen beim Design der physikalischen Schicht ab, wie beispielsweise der Modulationsordnung, der Codierungseffizienz, der Symbolrate und anderen Implementierungsfaktoren, die beeinflussen, wie effektiv die Bandbreite genutzt werden kann.

Die Bluetooth-Technologie wurde nach Prinzipien konzipiert, bei denen Einfachheit, Zuverlässigkeit, ein effizienter Betrieb in weltweit verfügbaren, lizenzfreien Frequenzbändern sowie – im Falle von Bluetooth LE – Energieeffizienz im Vordergrund stehen. Aus diesem Grund wurden Bluetooth-LE-Funkmodule mit physikalischen Schichten entwickelt, die auf der Gaußschen Frequenzumtastung (GFSK) basieren – einem einfachen, robusten und wenig komplexen Modulationsverfahren – und die nur über eine begrenzte oder gar keine Vorwärtsfehlerkorrektur verfügen. Die Einfachheit der GFSK-PHYs hat sich für Bluetooth bewährt und wird dies auch weiterhin tun, doch ihre Spektraleffizienz ist gering, weshalb sie nur begrenzte Möglichkeiten bieten, den Durchsatz deutlich zu steigern.

Bezugnehmend auf Shannons Theorem könnte ein Ansatz zur Verbesserung des Durchsatzes von GFSK-PHYs darin bestehen, deren Bandbreite zu erhöhen; dies ist jedoch angesichts der Einschränkungen des 2,4-GHz-ISM-Bands und – was noch wichtiger ist – der damit verbundenen Auswirkungen auf die Architektur und die Energieeffizienz nicht praktikabel. Ein weiterer Ansatz könnte darin bestehen, das Signal-Rausch-Verhältnis (SNR) zu erhöhen, doch auch dies ist mit Herausforderungen verbunden. Die Sendeleistung unterliegt gesetzlichen Grenzwerten, während der Spielraum für eine Verbesserung des Rauschverhaltens des Empfängers nur gering ist. Daher ist es sinnvoller, die Einschränkungen bei der Spektraleffizienz anzugehen – und genau das leistet Bluetooth® HDT.

Bluetooth HDT führt eine neue PHY-Schicht ein, die mit derselben Kanalbandbreite und denselben Kanalabständen arbeitet wie Bluetooth LE. Noch wichtiger ist jedoch, dass die PHY kohärente Modulationsverfahren höherer Ordnung und eine Vorwärtsfehlerkorrektur (FEC) umfasst, um eine hohe spektrale Effizienz zu ermöglichen. Bluetooth HDT führt außerdem neue Paketformate und Aktualisierungen der Verbindungsschicht ein, um adaptive Modulation und Verbindungsanpassung zu unterstützen. Dies verbessert die Widerstandsfähigkeit gegenüber Mehrwegausbreitung oder Schwankungen und trägt gleichzeitig dazu bei, die spektralen Effizienzziele der neuen PHY zu erreichen. Darüber hinaus definiert Bluetooth HDT neue HCI-Befehle und -Ereignisse zur Unterstützung der neuen HDT-Funktionen und führt entsprechende Sicherheitsverbesserungen ein.

Die folgenden Kapitel bieten einen detaillierten Überblick über Bluetooth HDT anhand seiner Bausteine. Das Dokument führt den Leser in der folgenden Reihenfolge durch die Hauptkomponenten von Bluetooth HDT: Architektur, physikalische Schicht (PHY), Pakete, Verbindungsschicht (LL), Verschlüsselung, Host-Controller-Schnittstelle (HCI) sowie „Sonstiges“, wozu auch Aktualisierungen der ISOAL- und Host-Schichten des Stacks gehören.

3. Bluetooth®-HDT-Architektur

Bevor wir uns mit den technischen Aspekten von Bluetooth HDT befassen, ist es sinnvoll, sich einen Überblick über die Vorteile und den Mehrwert zu verschaffen, die HDT für die Bluetooth-Technologie mit sich bringt:

• Dadurch wird die maximal unterstützte Bitrate auf 7,5 Mbit/s erhöht.
• Es bietet erhebliche Verbesserungen der WLAN-Leistung, nicht nur eine Steigerung des Durchsatzes
• Es erweitert die verfügbaren Kapazitäten und Funktionen zur Unterstützung bestehender Bluetooth-Anwendungen und Anwendungsfälle.
• Es ermöglicht neue, vielfältigere Anwendungsfälle wie hochauflösendes und verlustfreies Audio

Diese Vorteile werden durch architektonische Innovationen und Verbesserungen erreicht, die in die Bluetooth-Kernspezifikation aufgenommen wurden. Dieser Abschnitt bietet einen Überblick über die wichtigsten architektonischen Grundsätze von Bluetooth HDT.

3.1 Überblick

Die wesentlichen architektonischen Ziele von Bluetooth HDT bestehen darin, den Durchsatz deutlich zu steigern und dabei die Abwärtskompatibilität mit Bluetooth LE zu wahren, die erforderliche Leistung zu erzielen, um höhere Bitraten effizient und zuverlässig zu unterstützen (z. B. bessere Empfindlichkeit, höhere Störfestigkeit sowie Robustheit gegenüber Mehrwegausbreitung und Signalschwankungen), und diese Ziele mit einem im Vergleich zu früheren Bluetooth-Systemen überschaubaren Implementierungsaufwand zu erreichen.

Eine einfache Möglichkeit, die durch Bluetooth HDT eingeführten Innovationen und Verbesserungen zu veranschaulichen, besteht darin, sie der Struktur des Bluetooth-LE-Stacks zuzuordnen. Zur Veranschaulichung zeigt Abbildung 3.1 eine vereinfachte Darstellung des Bluetooth-LE-Stacks, wobei die Schichten, die aktualisiert wurden, um HDT zu ermöglichen, mit einem Stern gekennzeichnet sind.

Abbildung 3.1 – Aktualisierungen des Bluetooth-LE-Stacks für HDT

Wenn man eine Ebene tiefer geht, um einen Überblick auf mittlerer Ebene zu erhalten, lassen sich die wichtigsten Neuerungen und Verbesserungen auf den einzelnen Stack-Ebenen, die HDT ermöglichen oder unterstützen, wie folgt zusammenfassen:

Physikalische Schicht (PHY)

• Eine neue, nicht auf GFSK basierende PHY-Schicht, die auf kohärenten Modulationsverfahren höherer Ordnung und einer Vorwärtsfehlerkorrektur mit Puncturing basiert
• Unterstützung für fünf verschiedene Bitraten bis zu 7,5 Mbit/s

Verbindungsschicht (LL)

• Eine neue Paketstruktur
• Drei neue Varianten des Paketformats
• Ein neues Verfahren für den Austausch von HDT-Konfigurationsdaten
• Aktualisierte Verfahren für das PHY-Update und für den Informationsaustausch bei der CIS-Erstellung
• HDT-Verschlüsselung und größere MIC-Größen

Host-Controller-Schnittstelle (HCI)

• Neue Befehle zum Festlegen von Parametern, zum Auslesen von Nutzdaten, zum Aktivieren von Testfunktionen und vieles mehr
• Neue Ereignisse zur Meldung von HDT-Raten, Verschlüsselungsaktivierung und mehr

Zudem wurden kleinere Aktualisierungen an der Isochronous Adaptation Layer (ISOAL) und an den Host-Schichten des Bluetooth-LE-Stacks vorgenommen. Die Aktualisierungen der Host-Schichten dienen in erster Linie der Überprüfung und Durchsetzung der Anforderungen an die MIC-Länge, während die Aktualisierungen an der ISOAL die Übertragung größerer Datenmengen ermöglichen, die durch die neue PHY-Schicht unterstützt werden.

Die abschließende, auf niedriger Ebene angesiedelte Betrachtung mit höherer technischer Auflösung wird in den folgenden Abschnitten dieses Artikels behandelt: die physikalische Schicht in Abschnitt 4, Pakete in Abschnitt 5, die Verbindungsschicht in Abschnitt 6, Verschlüsselung in Abschnitt 7, HCI in Abschnitt 8 und Sonstiges (z. B. ISOAL und Host-Schichten) in Abschnitt 9.

3.2 Architektonische Grundsätze

Bluetooth High Data Throughput (HDT) ist eine Erweiterung von Bluetooth LE und keine eigenständige oder parallele Technologie. Es führt neue Funktionen ein, behält dabei jedoch den bei Bluetooth LE verwendeten architektonischen Rahmen bei (z. B. dieselben physikalischen Kanäle, logischen Transportschichten, logischen Verbindungen usw.).

HDT ist abwärtskompatibel mit bestehenden GFSK-basierten Bluetooth-LE-Geräten, die im 2,4-GHz-ISM-Band arbeiten und dieselbe Kanalaufteilung verwenden. Genauer gesagt wird eine Verbindung stets über eine GFSK-PHY hergestellt; anschließend können Geräte optional zur HDT-PHY wechseln. HDT ist so konzipiert, dass Geräte innerhalb einer LE-Verbindung dynamisch zwischen GFSK-PHYs und der HDT-PHY wechseln können, wodurch HDT-fähige Geräte bei Bedarf mit älteren Bluetooth-LE-Geräten koexistieren und auf den herkömmlichen Bluetooth-LE-Betrieb zurückgreifen können. Es ist zu beachten, dass die erste Version von HDT keinerlei Form der Werbung unterstützt.

Anstatt die Bandbreite (BW) oder das Signal-Rausch-Verhältnis (SNR) zu erhöhen, erzielt HDT einen höheren Durchsatz durch eine gesteigerte Spektraleffizienz. Dies wird durch die Einführung einer neuen PHY-Schicht erreicht, die auf kohärenten Modulationsverfahren höherer Ordnung in Kombination mit Vorwärtsfehlerkorrektur und Puncturing basiert.

HDT führt eine neue Paketstruktur ein, die hohe Datenraten effizient unterstützt, und definiert mehrere Paketformate, die dazu dienen, Overhead, Robustheit und Effizienz in verschiedenen Betriebsszenarien in Einklang zu bringen. Insbesondere ein Paketformat (PF1) ermöglicht es, dass ein einzelnes HDT-Paket mehrere Nutzdaten – möglicherweise von verschiedenen Anwendungen oder logischen Verbindungen – transportiert und die Nutzdaten in Blöcke aufteilt. Diese Flexibilität ermöglicht Aggregation, eine effiziente Funknutzung, optimierte Wiederholungsübertragungen sowie weitere Vorteile, die später in diesem Beitrag erläutert werden.

HDT wurde entwickelt, um eine zuverlässige Paketauswertung bei hohen Datenraten, adaptive Modulation sowie eine dynamische, paketbezogene Ratenanpassung zu ermöglichen. Die PHY-Schicht maximiert die Wahrscheinlichkeit, dass Steuerinformationen für ein Paket auch unter schlechten Kanalbedingungen decodiert werden können, indem sie diese stets mit dem robustesten Verfahren moduliert und die Steuerinformationen getrennt von den Nutzdaten innerhalb der Paketstruktur verwaltet und verarbeitet.

Um die Robustheit gegenüber Störungen, Mehrwegausbreitung und Fading zu verbessern, integriert HDT PHY-orientierte Mechanismen in die Paketstruktur. Pakete, die über die HDT-PHY-Schicht übertragen werden, können in PHY-Intervalle unterteilt werden, die jeweils durch bekannte Sequenzen begrenzt sind, welche zur Unterstützung der Kanalverfolgung und Phasenkorrektur während des Empfangs dienen. Dieser Ansatz ermöglicht eine Resynchronisation des Empfängers während der Paketübertragung, wodurch die Zuverlässigkeit bei hohen Datenraten verbessert wird und gleichzeitig adaptive Modulation sowie eine dynamische Ratenauswahl unterstützt werden.

Zur Verdeutlichung: Die Segmentierung der Daten in Blöcke und PHY-Intervalle erfolgt unabhängig voneinander. Der wesentliche Unterschied besteht darin, dass Blöcke einen Mechanismus zur logischen Segmentierung der Nutzdaten darstellen, während PHY-Intervalle einen Mechanismus zur Segmentierung der Übertragung auf PHY-Ebene darstellen. In PF1 kann jede Nutzdatenlast, einschließlich ihres MIC, falls verschlüsselt, in Blöcke unterteilt werden, wobei jeder Block durch einen eigenen CRC geschützt ist. Die daraus resultierende Nutzdatenzone kann dann auf der PHY-Schicht in Symbolströme fester Länge unterteilt werden, die als PHY-Intervalle bezeichnet werden. Auf jedes dieser Intervalle folgt eine abschließende Symbolsequenz und – mit Ausnahme des letzten Intervalls – eine PHY-Intervall-Trainingssequenz (PITS). Daher dienen Blockgrenzen und PHY-Intervallgrenzen unterschiedlichen Zwecken und stellen nicht dieselbe Segmentierung dar. Blöcke dienen der Organisation der Nutzdaten, der Fehlererkennung und der selektiven Neuübertragung, während PHY-Intervalle durch überschaubare Dekodierungsintervalle und periodisches Nachlernen des Empfängers eine robuste drahtlose Übertragung gewährleisten.

HDT führt außerdem einen Mechanismus zur physikalischen Kanaladressierung (PCA) ein, um physikalische Verbindungen eindeutig zu identifizieren. Diese Erweiterung kommt Umgebungen mit hoher Gerätedichte zugute, da sie einen großen Adressraum bereitstellt und gleichzeitig die Funktion der Zugangsadresse bei GFSK-PHYs beibehält. Die Trennung der Mechanismen zur Identifizierung physikalischer Kanäle stellt sicher, dass HDT-Pakete auch unter überlasteten HF-Bedingungen effizient gefiltert und korrekt aktiven Verbindungen zugeordnet werden können. Ein physikalischer Kanal kann mehr als eine PCA haben, wobei jede auf einem anderen PHY verwendet wird.

Schließlich werden Sicherheitsaspekte in HDT integriert, ohne das Sicherheitsmodell von Bluetooth LE zu verändern. HDT führt die Unterstützung für größere Message Integrity Check (MIC)-Größen auf der Verbindungsschicht ein und verbessert damit die Datenauthentifizierung für längere Nutzdaten. Zudem unterstützt es die Funktion „Encryption Key Schedule“ (EKS), die ein neues Rahmenwerk für die Einrichtung und Verwaltung von Verschlüsselungsschlüsseln in Bluetooth LE einführt. EKS generiert Sitzungsschlüssel und andere kryptografische Werte, die zum Schutz einer verschlüsselten Verbindung erforderlich sind, und ermöglicht die Aktualisierung von Verschlüsselungsschlüsseln während einer aktiven Verbindung. Für HDT erleichtert EKS die Koordination von Änderungen an Verschlüsselungsschlüsseln und MIC-Größen beim Übergang zwischen GFSK- und HDT-PHYs, ohne dass die Verbindung getrennt oder die Verschlüsselung neu gestartet werden muss.

Es liegt auf der Hand, dass die Einführung einer neuen PHY-Schicht zur Unterstützung von HDT bedeutet, dass für die Implementierung von HDT neue Hardware und somit ein neuer Funkchip erforderlich sind. Zwar wird Bluetooth HDT abwärtskompatibel mit GFSK-basierten Bluetooth-Geräten sein, doch werden reine GFSK-Geräte die neuen, höheren Durchsatzraten nicht unterstützen können.

4. Bluetooth® HDT-Physikalische Schicht (PHY)

Die Bluetooth-HDT-Physikalische Schicht (PHY) definiert die Mechanismen auf Funkebene, die einen höheren Durchsatz ermöglichen. Sie ist als optionale Bluetooth-LE-PHY spezifiziert, die neben der obligatorischen LE-1M-PHY sowie den optionalen LE-2M-, LE-2M-2BT- und LE-Coded-PHYs auf Basis der GFSK-Modulation existiert. Die HDT-PHY arbeitet im 2,4-GHz-ISM-Band und verwendet dieselbe Kanalbandbreite und denselben Kanalabstand wie GFSK-basierte PHYs.

In diesem Abschnitt werden drei grundlegende Bereiche der HDT-PHY näher beleuchtet: Modulation und Bitraten, Bitstream-Verarbeitung sowie Synchronisation und Robustheit.

4.1 Modulation und Bitraten

Modulation ist der Vorgang, bei dem Informationen zur Übertragung auf ein physikalisches Trägersignal abgebildet werden. Bei Bluetooth-LE-PHYs erfolgt diese Abbildung traditionell mittels Gaußscher Frequenzumtastung (GFSK), bei der Informationen durch kleine Frequenzverschiebungen des HF-Trägersignals übertragen werden, wobei in jedem übertragenen Symbol ein Datenbit kodiert wird.

Der Bluetooth-HDT-PHY führt drei kohärente Modulationsverfahren ein, bei denen Daten als komplexwertige Symbole dargestellt und mehrere Bits pro Symbol codiert werden:

• π/4-Quadratur-Phasenumtastung (π/4-QPSK)
• 8-Phasen-Verschiebungsmodulation (8PSK)
• 16-Quadratur-Amplitudenmodulation (16QAM)

Diese Modulationsverfahren übertragen Informationen durch Phasenverschiebungen des HF-Trägers oder, im Falle von 16QAM, durch gleichzeitige Verschiebungen sowohl der Phase als auch der Amplitude des Trägers. Während der Kommunikation bestehen die übertragenen Symbole aus zwei Signalkomponenten, die als In-Phase- (I) und Quadratur- (Q) Signal bezeichnet werden, wobei jedes I/Q-Signalpaar konstruktionsbedingt einen bestimmten Symbolwert darstellt. Die Gesamtheit aller möglichen I/Q-Signalpaare für ein bestimmtes Modulationsverfahren, die als Punkte auf einer komplexen Ebene abgebildet werden, wird als Konstellationsdiagramm bezeichnet. Abbildung 4.1 zeigt die Konstellationsdiagramme für π/4-QPSK, 8PSK und 16QAM.

Abbildung 4.1 – Konstellationsdiagramme für HDT-Modulationsverfahren

Kohärente Modulation bedeutet, dass das Verfahren eine Frequenz- und/oder Phasenverriegelung zwischen Sender und Empfänger des Kommunikationssystems unterstützt, was der Synchronisation zugutekommt und die Fehlerwahrscheinlichkeit verringert. Bei nichtkohärenten Verfahren findet keine solche Verriegelung statt, wodurch das System zwar einfacher aufgebaut ist, unter vergleichbaren Bedingungen jedoch im Allgemeinen fehleranfälliger ist als bei kohärenter Modulation. HDT nutzt kohärente Modulation.

Die HDT-PHY-Schicht kombiniert die neuen Modulationsverfahren mit einer konvolutiven Vorwärtsfehlerkorrektur (FEC) und Puncturing. Die FEC wird auf Basis einer konvolutiven Codierung mit einer Codierungsrate von ½ implementiert, und Puncturing wird eingesetzt, um höhere Codierungsraten zu ermöglichen. Insgesamt unterstützt HDT fünf verschiedene Bitraten, die alle mit einer festen Symbolrate von 2 Msym/s arbeiten. Architektonisch werden die verschiedenen Bitraten als Modi einer einzigen PHY behandelt. Tabelle 4.1 enthält eine Zusammenfassung der relevanten Eigenschaften für jede der Bitraten.

Tabelle 4.1 – HDT-Raten

HDT-Rate	PHY-Bitrate	Modulationsschema	Bits pro Symbol	Implementierung des Controllers
HDT2	2 Mbit/s	π/4-QPSK	2	Obligatorisch
HDT3	3 Mbit/s	π/4-QPSK	2	Obligatorisch
HDT4	4 Mbit/s	8PSK	3	Obligatorisch
HDT6	6 Mbit/s	16QAM	4	Optional
HDT7.5	7,5 Mbit/s	16QAM	4	Optional

Übertragungsraten bis einschließlich HDT4 sind obligatorisch, während Raten über HDT4 optional sind. Wird HDT6 unterstützt, ist HDT7.5 optional. Wird HDT7.5 unterstützt, ist auch HDT6 obligatorisch. Für jede Übertragungsrate gilt: Wird der Empfang (Rx) unterstützt, ist die Übertragung (Tx) optional; wird Tx unterstützt, ist Rx obligatorisch.

Ausführliche Informationen, einschließlich Tabellen mit Symbolkoordinaten, Implementierungsanforderungen usw., finden Sie in den entsprechenden Abschnitten der Bluetooth Core Specification 7.0.

4.2 Bitstream-Verarbeitung

Die Umwandlung digitaler Daten in Symbole zum Senden und Empfangen über eine drahtlose Kommunikationsverbindung erfordert die Steuerung des Datenflusses mithilfe eines gut strukturierten Verarbeitungsmodells, das als „Bitstream-Verarbeitungspipeline“ bezeichnet wird.

Die PHY-Spezifikation für Bluetooth HDT definiert eine deterministische Pipeline zur Verarbeitung des HDT-Bitstreams, die durch das Blockdiagramm in Abbildung 4.2 veranschaulicht wird. Es handelt sich um eine Erweiterung der Pipeline, die in GFSK-basierten LE-PHYs zu finden ist, ergänzt um Intervallabstände und Punkterung. Alle Verarbeitungsschritte werden stets in derselben Reihenfolge durchlaufen, unabhängig von der gewählten PHY-Rate.

Auf der Sendeseite durchlaufen die Rohdatenbits nacheinander die Verschlüsselung (sofern aktiviert), die Erzeugung der zyklischen Redundanzprüfung (CRC), das Daten-Whitening, die Intervallverteilung, die Vorwärtsfehlerkorrektur (FEC)-Codierung und die Punktierung. Die resultierenden Bitfolgen werden anschließend in modulierte I/Q-Signale umgewandelt, die die über Funk zu übertragenden Symbole darstellen. Es ist zu beachten, dass die Intervallaufteilung nur bei Verwendung des HDT-Paketformats 1 (PF1) zur Anwendung kommt (um den Nutzdaten-Bitstrom aufzuteilen und mehrere PHY-Intervalle zu unterstützen). Die vollständigen Definitionen der Paketstruktur und des Formats werden in Abschnitt 5 behandelt.

Auf der Empfangsseite durchlaufen die empfangenen Symbole die entsprechenden umgekehrten Verarbeitungsschritte, um die gesendeten Datenbits zu extrahieren (mit Ausnahme der Punkterung).

Abbildung 4.2 – HDT-Bitstream-Verarbeitungspipeline

Alle Phasen der Pipeline sind bei der HDT-Bitstream-Verarbeitung einheitlich, doch wendet die PHY-Schicht unterschiedliche Verarbeitungsregeln für Steuerinformationen und Nutzdaten an. Steuerinformationen werden separat behandelt, da die neue HDT-Paketstruktur einen Steuerheader definiert, der von den Abschnitten, die die Nutzdaten enthalten, getrennt ist. Diese Trennung in der Paketstruktur ist eine architektonische Entscheidung, um kritische Leistungsziele auf PHY-Ebene zu unterstützen, wie im Folgenden erläutert wird.

Ein Empfänger muss den Steuerheader erfolgreich decodieren, um die darauf folgende Nutzlast mit hohem Durchsatz aus den Paketen extrahieren zu können. Um die Wahrscheinlichkeit zu maximieren, dass Steuerinformationen auch unter schlechten Kanalbedingungen decodiert werden können, werden diese stets mit π/4-QPSK moduliert, dem robustesten in HDT verfügbaren Modulationsverfahren. Zu diesem Zweck bildet der Bitstrom für Steuerdaten einen eigenen Symbolstrom, wobei auf Whitening verzichtet wird und eine Codierungsrate von ½ für die FEC ohne Puncturing verwendet wird. Dies trägt dazu bei, die Zuverlässigkeit der Paketinterpretation bei höheren Datenraten zu verbessern.

Durch die vorzeitige und von der Nutzlast getrennte Verarbeitung von Steuerinformationen wird zudem eine dynamische Datenratenanpassung auf Paket-für-Paket-Basis ermöglicht. Genauer gesagt enthält der Steuerheader eines Pakets Angaben zum Paketformat, zur gewählten Datenrate, zur PHY-Intervallkonfiguration usw. für die nachfolgenden Abschnitte, die die Nutzlast enthalten. Wenn Steuerinformationen vorab empfangen und decodiert werden, kann der Empfänger auf die richtigen Demodulations- und Decodierungseinstellungen für die Verarbeitung der Nutzlast konfiguriert werden – und, was noch wichtiger ist, diese Einstellungen können bei Bedarf für jedes einzelne Paket angepasst werden. Außerdem kann der Empfänger so vorbereitet werden, dass er eine Resynchronisierung während des Pakets unterstützt, wenn die übertragenen Nutzlastdaten in mehrere PHY-Intervalle aufgeteilt werden, um die Robustheit der Verbindung in Kanälen mit Fading oder zeitlichen Schwankungen zu verbessern.

Zur Orientierung bietet Tabelle 4.2 einen allgemeinen Überblick über die Rolle und die wesentlichen Fakten, die man über die einzelnen Phasen der Bitstream-Verarbeitungskette wissen sollte.

Tabelle 4.2 – Übersicht über die Stufen der HDT-Bitstream-Pipeline

Bitstream-Stufe	Zusammenfassung
Verschlüsselung	• Gewährleistet die Vertraulichkeit der Daten durch Anwendung einer kryptografischen Transformation vor der weiteren Verarbeitung • Wird bei aktiver Verschlüsselung auf die Nutzdaten angewendet (z. B. PDU-Header und Nutzdatenbereich in HDT-Paketen) • Folgt dem in Abschnitt 7 beschriebenen HDT-Verschlüsselungsframework • Findet früh in der Pipeline statt, um die Sicherheitsabdeckung zu maximieren und gleichzeitig die Kompatibilität mit nachfolgenden Fehlererkennungs- und -korrekturphasen zu gewährleisten
CRC	• Berechnet über Nutzdatenblöcke (nach einer eventuellen Verschlüsselung) • Bietet Fehlererkennung sowohl für Zufallsfehler als auch für Burst-Fehler
Zahnaufhellung	• Randomisiert Bitmuster und unterbricht lange Sequenzen identischer Bits, wodurch ausreichend Übergänge im Datenstrom für eine zuverlässige Taktrückgewinnung gewährleistet werden • Wird nur auf die Nutzdaten angewendet (z. B. PDU-Header und Nutzdatenbereich in HDT-Paketen); beginnt beim ersten PDU-Header-Bit nach dem Steuer-Header und endet beim letzten Datenbit des Nutzdatenbereichs in einem Paket
Intervallabstand	• Exklusiv für das HDT-Paketformat 1 • Ermöglicht die Aufteilung der Nutzdatenzone in Übertragungsintervalle fester Länge • Ermöglicht das periodische Einfügen von PHY-Intervall-Trainingssequenzen (PITS) zur Aktualisierung der Kanalschätzung
FEC-Codierung	• Gilt für alle übertragenen Daten (z. B. Steuerheader, PDU-Header und Nutzdatenbereich in HDT-Paketen) • Verwendet eine nicht-systematische, nicht-rekursive Faltungscodierung mit einer Codierungsrate von ½ als Basis (Beschränkungslänge K=6) • Bietet Fehlerkorrektur sowohl für zufällige Fehler als auch für kurze Fehlerfolgen
Durchstechen	• Entfernt selektiv bestimmte Bits aus dem FEC-kodierten Bitstrom • Verschiedene Puncturing-Muster in Kombination mit einem einzelnen Konvolutionskodierer der Basis 1/2 erzeugen mehrere Datenraten, die je nach Kanalbedingungen adaptiv angepasst werden können • Puncturing-Muster für HDT maximieren den freien Abstand für jede Ziel-Datenrate – ein Parameter, der die Robustheit einer Kodierrate gegenüber Rauschen misst • PF1 wendet Puncturing auf die Nutzdatenzone an, nicht jedoch auf den PDU-Header; PF0 wendet Puncturing auf beide an

Der Vollständigkeit halber enthält Tabelle 4.3 eine Übersicht über die Puncturing-bezogenen Parameter für jede HDT-Datenrate. Es ist zu beachten, dass HDT3 und HDT6 zwar dasselbe Puncturing-Muster und dieselbe Coderate aufweisen, jedoch unterschiedliche Modulationsverfahren verwenden.

Tabelle 4.3 – Zusammenfassung der HDT-Durchstoßparameter

HDT-Rate	Lochmuster (1 = beibehalten, 0 = weggelassen)	Durchstoßfestigkeit (Ep)	Effektive Codierrate
HDT2	[1 1]	1,0 (2/2)	1/2
HDT3	[1 1 0 1 0 1]	0,667 (4/6)	3/4
HDT4	[1 1 0 1]	0,75 (3/4)	2/3
HDT6	[1 1 0 1 0 1]	0,667 (4/6)	3/4
HDT7.5	[1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 1 0 1 0 0 1 0 1 0 1 1 0 0 1]	0,933 (28/30)	15/16

4.3 Synchronisation und Robustheit

Die für HDT verwendeten kohärenten Modulationsverfahren höherer Ordnung reagieren naturgemäß empfindlicher auf Phasen- oder Frequenzrauschen, Drift und Kanalschwankungen als GFSK. Aus diesem Grund verfügt die HDT-PHY über mehrere Mechanismen, die eine genaue Synchronisation und robuste Dekodierung bei hohen Datenraten gewährleisten. Dadurch werden die angestrebten Verbesserungen der spektralen Effizienz erreicht und eine zuverlässige Leistung in anspruchsvollen Funkumgebungen mit Kanalverschlechterung, Fading oder Mehrwegverzerrungen gewährleistet.

Tabelle 4.4 bietet einen allgemeinen Überblick über die Funktion und die wesentlichen Fakten, die zum Verständnis der einzelnen Mechanismen erforderlich sind. Dazu gehören Trainingssequenzen (kurz und lang), Schutzintervalle, Beendigungssymbole, PHY-Intervalle und PHY-Intervall-Trainingssequenzen (PITS).

Tabelle 4.4 – Zusammenfassung der HDT-Trainings- und Synchronisationsmechanismen

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 eine feine zeitliche Abstimmung, die Schätzung bzw. Korrektur von Frequenzabweichungen sowie die anfängliche Kanalabschätzung • Erscheint auch in der Präambel von HDT-Paketen nach dem 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 • Tritt explizit in der Präambel zwischen STS und LTS sowie implizit im gesamten Paket über Abschlusssymbole auf • 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 Steuerheader, 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 zwischen unabhängig verarbeiteten Symbolströmen zu begrenzen
PHY-Intervalle	• Ermöglicht die Aufteilung langer Nutzdaten in kleinere und leichter zu verarbeitende Dekodierungseinheiten • Tritt ausschließlich in der Nutzdatenzone von HDT-Paketen im Paketformat 1 (PF1) auf • Ermöglicht periodisches Kanal-Tracking und Retraining zwischen Intervallen innerhalb langer PF1-Nutzdaten
PHY-Intervalltrainingssequenz (PITS)	• Aktivieren Sie 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 unterteilt sind • Erscheint ausschließlich in der Nutzdatenzone von HDT-Paketen im Paketformat 1 (PF1)

Zusammen bilden die Synchronisations- und Robustheitselemente im HDT-PHY ein mehrschichtiges Rahmenwerk, das einen zuverlässigen Betrieb mit hohem Durchsatz ermöglicht. Zunächst erfolgt die anfängliche Erfassung durch ein robustes, auf der Präambel basierendes Training mit STS und LTS. Anschließend werden saubere Übergänge und explizite Dekodierungsgrenzen mithilfe von Schutzintervallen und Abschlusssymbolen festgelegt und durchgesetzt. Schließlich wird die Resynchronisation während des Pakets über PHY-Intervalle und die dazugehörigen Trainingssequenzen ermöglicht, um sich bei der Verarbeitung längerer Pakete und höherer Datenraten an wechselnde Kanalbedingungen anzupassen. Dieser strukturierte Ansatz gewährleistet Widerstandsfähigkeit gegenüber Fading, Phasendrift und Mehrwegeeffekten, wodurch HDT erhebliche Durchsatzgewinne bei gleichzeitiger Robustheit und Effizienz erzielen kann.

5. Bluetooth®-HDT-Pakete

Bluetooth® HDT definiert eine neue Paketstruktur, die die im vorigen Abschnitt vorgestellten Funktionen auf PHY-Ebene mit den später in Abschnitt 6 beschriebenen Funktionen und Verfahren der Verbindungsschicht verbindet, um in der Praxis einen höheren Durchsatz und eine robuste Leistung auf zuverlässige Weise zu gewährleisten.

In diesem Abschnitt werden die HDT-Paketstruktur und die Paketformate behandelt, wobei die einzelnen Zonen, Abschnitte und/oder Felder in groben Zügen erläutert werden.

5.1 Überblick über die Struktur von HDT-Paketen

Wie in Abbildung 5.1 dargestellt, besteht die HDT-Paketstruktur aus vier Bereichen: Präambel, Steuerheader, PDU-Header-Bereich und Nutzdatenbereich. Die Präambel und der Steuerheader sind obligatorisch und müssen in allen HDT-Paketformaten vorhanden sein. Das Vorhandensein des PDU-Headers und des Nutzdatenbereichs hängt vom gewählten Paketformat ab.

Abbildung 5.1 – Struktur eines HDT-Pakets

Die Tiefe der HDT-Paketstruktur ist so ausgelegt, dass der PDU-Header und die Payload-Zonen Informationen mit vier Detailebenen enthalten. Zur Verdeutlichung der Kommunikation werden Felder, die sich auf die oberste Ebene des Pakets beziehen, als „Zonen“ bezeichnet, Felder, die sich auf die nächstniedrigere Ebene beziehen, als „Teile“, und Felder für die beiden untersten Ebenen einfach als „Felder“. Beispielsweise könnte man sagen, dass die PDU-Header-Zone der HDT-Paketstruktur einen TX-Teil enthält, in dem das LL-Deskriptor-Feld spezifiziert ist und das das LLID-Feld mit der Link-Layer-ID für jede Nutzlast umfasst. Der Vorteil dieses Namenskonventionsansatzes wird später in diesem Abschnitt deutlich werden.

Im Großen und Ganzen lassen sich die Rolle und der Aufbau der einzelnen Zonen in der HDT-Paketstruktur wie folgt zusammenfassen.

Präambel

• Ermöglicht es dem Empfänger, den Beginn eines eingehenden Pakets zu erkennen, sich mit dem Sender zu synchronisieren und Abweichungen bei Zeit, Frequenz oder Phase auszugleichen sowie eine Kanalschätzung durchzuführen, um durch den Funkkanal verursachte Amplituden- und Phasenverzerrungen zu mindern
• Besteht aus neun Wiederholungen der kurzen Trainingssequenz (STS), gefolgt von einem Schutzintervall (GI) und anschließend zwei Wiederholungen der langen Trainingssequenz (LTS)

Steuerkopf

• Ermöglicht es dem Empfänger, das eingehende Paket der richtigen physikalischen Verbindung zuzuordnen, wesentliche Steuerinformationen zuverlässig zu decodieren (mithilfe einer speziellen Header-Fehlerprüfung) und dies zu tun, bevor eine Demodulation oder Verarbeitung der Nutzdaten erfolgt
• Besteht aus sieben Feldern, die Steuerungsdaten enthalten, darunter die HDT-Paketadresse (HPA-A), das Paketformat, die Auswahl der Übertragungsrate usw.

PDU-Kopfzeilenbereich

• Enthält Metadaten auf Protokollebene, die der Empfänger benötigt, um die in der Payload-Zone folgenden Nutzdaten zu interpretieren und zu verarbeiten, darunter den Pakettyp (z. B. Transport, Link-ID usw.) sowie die Länge der Nutzdaten usw.
• Besteht aus fünf Abschnitten: Initial, RX, TX, Extended Header und Header Error Correct (HEC-P)

Nutzlastzone

• Enthält die übertragenen Nutzdatenblöcke (bei Verschlüsselung zusammen mit ihrer Nachrichtenintegritätsprüfung) sowie die CRCs, geordnet nach dem verwendeten Paketformat
• In den Abschnitten zum Paketformat behandelte Details

5.2 HDT-Paketformate

Um Effizienz und Flexibilität in verschiedenen Kommunikationsszenarien zu gewährleisten, definiert HDT drei Paketformate: „short“, Paketformat 0 (PF0) und Paketformat 1 (PF1).

Kurzform

Das Kurzpaketformat ist eine Struktur mit minimalem Overhead, die sich optimal für Fälle eignet, in denen keine Daten übertragen werden müssen. Es reduziert die Sendezeit (z. B. ist es immer genau 69 µs lang) und eignet sich zur Synchronisation zwischen Geräten sowie zum Austausch von Bestätigungen. Strukturell besteht das Kurzformat, wie in Abbildung 5.2 dargestellt, lediglich aus der Präambel und dem Steuerheader.

Abbildung 5.2 – HDT-Paket, Kurzformat

Paketformat 0 (PF0)

Das Paketformat 0 ist eine Struktur mit geringer Komplexität, die sich optimal für die Übertragung einer unsegmentierten Nutzlast in einem einzigen Block eignet. Strukturell besteht PF0 aus der Präambel, dem Steuerheader, der PDU-Header-Zone und der Nutzlastzone (die bei einer leeren Nutzlast optional sein kann).

Der einzelne Block in der Nutzdatenzone enthält einen MIC, sofern er verschlüsselt ist. Die Nutzdatenzone enthält außerdem einen CRC zur Fehlererkennung, der aus der Summe des gesamten PDU-Headers, des Nutzdatenblocks und des MIC berechnet wird. Abbildung 5.3 veranschaulicht die Struktur von PF0.

Abbildung 5.3 – HDT-Paketformat 0 (PF0)

Paketformat 1 (PF1)

Das Paketformat 1 ist die leistungsfähigste und robusteste Struktur, die sich optimal für die effiziente und zuverlässige Übertragung großer Datenmengen eignet. Strukturell besteht PF1 aus der Präambel, dem Steuer-Header, der PDU-Header-Zone und der Nutzdatenzone.

PF1 ermöglicht die Zusammenfassung von bis zu vier verschiedenen Nutzdaten in der Nutzdatenzone (z. B. die nächsten vier zur Übertragung anstehenden Nutzdaten), wobei jede bei aktivierter Verschlüsselung über einen eigenen MIC verfügt. Jede der Nutzdaten kann in Blöcke (1–16) unterteilt werden, wobei für jeden Block ein CRC berechnet wird. Alle Blöcke mit Ausnahme des letzten sind gleich groß, die Größe kann jedoch für jede Nutzdaten unterschiedlich sein. Abbildung 5.4 veranschaulicht die Struktur von PF1. Die Indizes M, N und P beziehen sich auf die Anzahl der Blöcke für die Nutzdaten 0, 1 bzw. 2.

Abbildung 5.4 – HDT-Paketformat 1 (PF1)

Ein Block ist eine neue Einheit zur Übertragung und Validierung von Nutzdaten in der Nutzdatenzone des HDT-Pakets. Anstatt die Nutzdaten als ein einziges zusammenhängendes Ganzes zu behandeln, verarbeitet HDT die Nutzdaten als eine Abfolge von Blöcken, wobei jeder Block durch einen eigenen CRC geschützt ist, damit der Empfänger die Blöcke unabhängig voneinander validieren kann. Der wesentliche Vorteil dieses Konzepts besteht darin, dass es selektive Bestätigungen und Neuübertragungen bei der Übertragung größerer Nutzdatenmengen bzw. Pakete ermöglicht und so einen höheren Durchsatz gewährleistet. Teile des Pakets können nach erfolgreichem Empfang bestätigt werden, und wenn ein Teil der Nutzdaten durch Störungen beschädigt wird, muss die HDT-PHY nur die fehlenden oder beschädigten Blöcke erneut übertragen, während die erfolgreich empfangenen Blöcke erhalten bleiben.

Die Blockgranularität ermöglicht Multiplexing und einen konstanten Durchsatz und ergänzt damit die Fähigkeit von PF1, bis zu vier Nutzdaten in einem Paket zu bündeln. Die Blockgröße für eine bestimmte Nutzdatenmenge wird im TX-Teil der PDU-Header-Zone festgelegt.

Im Allgemeinen verwendet HDT Nutzdaten-Nummern und ein gleitendes Nutzdatenfenster, um die Übertragung, Bestätigung und erneute Übertragung von Nutzdaten zu verwalten. In jeder Richtung einer ACL- oder CIS-Verbindung enthält das Nutzdatenfenster zwischen einer und vier Nutzdaten, die zur Übertragung oder erneuten Übertragung bereit sind, beginnend mit der „CurrentPayloadNumber“. Wenn Nutzdaten am Anfang des Fensters bestätigt werden, erhöht sich die „CurrentPayloadNumber“, wodurch das Fenster vorwärts verschoben wird. Die „ExpectedPayloadNumber“ identifiziert die nächste Nutzlast, die vom Peer-Gerät erwartet wird. SN und NESN enthalten jeweils die drei niedrigstwertigen Bits der „CurrentPayloadNumber“ bzw. der „ExpectedPayloadNumber“, wodurch Geräte den Status des Nutzlastfensters verfolgen können. Dieses Modell zur Nummerierung der Nutzdaten gilt sowohl für PF0 als auch für PF1. PF0 kann nur die erste Nutzdatei im Fenster übertragen oder erneut übertragen, während PF1 ausgewählte Blöcke aus Nutzdaten innerhalb des Fensters übertragen oder erneut übertragen kann.

Zusammenfassend bietet Tabelle 5.1 einen Vergleich der drei Paketformate.

Tabelle 5.1 – Übersicht über die HDT-Paketformate

	Kurz	PF0	PF1
Maximale Nutzlast	K.A.	494 Oktette	8175 Oktette
Nützlich für	Synchronisation, Bestätigungen	Höherer Durchsatz	Höchster Durchsatz, höchste Effizienz und/oder höchste Robustheit
Die wichtigsten Vorteile	Verkürzt die Sendezeit, wenn keine Nutzdaten zum Senden vorhanden sind und wenn nur aufeinanderfolgende vollständige Nutzdaten bestätigt werden müssen	• 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

Lassen Sie uns nun kurz auf die einzelnen Bereiche der Paketstruktur näher eingehen.

5.3 Präambel

Abbildung 5.5 veranschaulicht den Aufbau und den zeitlichen Ablauf der Präambel. Weitere technische Details zur Trainingssequenz und zum Schutzintervall finden Sie in Band 6, Teil A, Abschnitt 7.4 der Bluetooth-Kernspezifikation.

Abbildung 5.5 – Präambel eines HDT-Pakets

5.4 Steuerkopf

Abbildung 5.6 zeigt das Format und die Felder des Steuerkopfes.

Abbildung 5.6 – Steuerheader eines HDT-Pakets

• HPA-A (HDT-Paketadresse – teilweise): Bits 39:24 der vollständigen 40-Bit-HPA. Liefert eine Teiladresse, die es dem Empfänger ermöglicht, eingehende Pakete zu filtern und in Frage kommende physikalische Verbindungen zu identifizieren.
• NESN (Next Expected Sequence Number): Enthält die drei niedrigstwertigen Bits der ExpectedPayloadNumber und liefert kumulative Bestätigungsinformationen für vom Peer-Gerät empfangene Nutzdaten. Während bestätigte Nutzdaten im Nutzdatenfenster vorrücken, gibt der NESN die nächste vom Peer-Gerät erwartete Nutzdate an.
• PFI (Packet Format Indicator): Gibt das für das Paket verwendete Format an. Das Feld ist dynamisch und kann sich von Paket zu Paket ändern.
  • 0: Kurz oder Format 0; 1: Format 1
  • „Short“ kann jederzeit eingefügt werden
  • Man kann jederzeit von PF0 zu PF1 wechseln
  • Ein Wechsel von PF1 zu PF0 ist unter bestimmten Umständen möglich
• RI (Ratenanzeige): Legt die Datenrate für den PDU-Header und die Payload-Zonen fest. Dieses Feld ist dynamisch und kann sich von Paket zu Paket ändern, was eine schnelle Anpassung der PHY-Rate an die Kanalbedingungen ermöglicht.
  • 0b000: Kurzformat (keine Datenzone)
  • 0b001–0b101: Übertragungsraten von 2 Mbit/s bis 7,5 Mbit/s.
• RFU (Für zukünftige Verwendung reserviert)
• PDU-Steuerung: Der Inhalt hängt vom Paketformat ab
  • Kurz: Enthält MD/CIE-Felder (More Data/Close Isochronous Event) zur sofortigen Verbindungssteuerung, 3 RFU-Bits sowie SNR-Felder (Signal-to-Noise Ratio)
  • Format 0: Ein 9b-Wert, der die Gesamtlänge der kombinierten PDU-Header- und Payload-Zonen angibt, ohne den CRC
  • Format 1: Enthält eine 6-Bit-PDU-Header-Zone (ohne den HEC-P-Teil), ein 2-Bit-PHY-INT, das die Anzahl der Nutzlastsymbole pro PHY-Intervall angibt [00: 128; 01: 256; 10: 384; 11: 512], sowie ein RFU-Bit
• HEC-C (Header Error Check – Control): Ein 24-Bit-CRC, der über alle vorangehenden Felder des Steuerheaders berechnet und mit dem vollständigen HPA initialisiert wird, wodurch der Empfänger den Steuerheader anhand des entsprechenden HPA überprüfen und das Paket korrekt der entsprechenden physikalischen Verbindung zuordnen kann.

5.5 PDU-Header-Bereich

Abbildung 5.7 zeigt das Format und die einzelnen Abschnitte der PDU-Header-Zone.

Abbildung 5.7 – Teile der PDU-Header-Zone eines HDT-Pakets

Einleitender Abschnitt

Der Anfangsabschnitt ist ein 8b-Feld, das als Steuerkarte und Einstiegspunkt für die gesamte PDU-Header-Zone dient. Er definiert das Vorhandensein optionaler Abschnitte und enthält transportspezifische Steuerinformationen. Die Interpretation des Anfangsabschnitts hängt vom Transporttyp ab, wie in Tabelle 5.2 zusammengefasst.

Tabelle 5.2 – Transportspezifische Felder im Anfangsabschnitt

Bit	ACL	CIS	BIS
0	XHP (Extended Header Present)	XHP (Extended Header Present)	XHP (Extended Header Present)
1	RxPP (Rx-Anteil vorhanden)	RxPP (Rx-Anteil vorhanden)	Festgelegt auf 0 (kein Rx-Anteil)
2	MD (More Data): Hält das Verbindungsereignis offen, um die Übertragung fortzusetzen	CIE (Close Isochronous Event): Signalisiert den vorzeitigen Abschluss eines Unterereignisses	CSTF (Control Subevent Transmission Flag): Zeigt an, dass eine BIG-Control-PDU in einem späteren Paket folgt; wird in Daten-PDUs gesetzt
3–5	SN (Sequenznummer): Die 3 niedrigstwertigen Bits der „CurrentPayloadNumber“, die die aktuelle Position des Absenders im Payload-Fenster angeben	SN (entspricht der ACL für Daten-PDUs)	CSSN (Control Subevent Sequence Number)
6–7 (PF0)	LLID (Logical Link ID)	LLID (Logical Link ID)	LLID (Logical Link ID)
6–7 (PF1)	TxPP (Tx-Anteil vorhanden) + RFU	TxPP (Tx-Anteil vorhanden) + RFU	TxPP (Tx-Anteil vorhanden) + RFU

Verschreibungspflichtiger Teil

Der Rx-Teil ist in ACL- oder CIS-Paketen enthalten, wenn selektive Bestätigungen erforderlich sind, um anzuzeigen, dass von einem Peer-Gerät gesendete Daten empfangen wurden. Sein Format und seine Felder sind in Abbildung 5.8 dargestellt. Für bis zu vier Nutzdaten können detaillierte Rückmeldungen bereitgestellt werden.

Abbildung 5.8 – PDU-Header-Bereich, Format und Felder des Rx-Teils

• RxPayloadMap: Gibt an, welche der nächsten vier erwarteten Nutzdaten (P+0 bis P+3) in diesem Paket bestätigt werden
• RxAck P+k (2b pro Nutzlast): Legt die Bestätigungsgranularität für jede Nutzlast k fest
  • 00: Nicht bestätigt. Weder die Nutzdaten noch bestimmte Blöcke wurden empfangen und validiert.
  • 01: Vollständig bestätigt. Die gesamte Nutzlast wurde korrekt empfangen (für diese Nutzlast folgt kein RxBitmap).
  • 10/11: Teilweise bestätigt. Bestimmte, jedoch nicht alle logischen Blöcke innerhalb der Nutzlast werden bestätigt. Für diese Nutzlast folgt ein RxBitmap mit 1 oder 2 Oktetten.
• RxBitmap (8 Bit oder 16 Bit): Eine Bitmaske, bei der eine 1 angibt, dass der entsprechende logische Block (gemäß der Segmentierung der Nutzdaten) erfolgreich empfangen und validiert wurde. Ihre Größe richtet sich nach der Anzahl der Blöcke in den Nutzdaten (Nb+1).
  • Alle nicht benötigten Bits werden auf 1 gesetzt, sodass nur 0xFF und 0xFFFF anzeigen, dass die Daten vollständig empfangen und validiert wurden.
  • For 8b bitmask, the 8 most significant bits are set to 1; an 8b mask can only be used if Nb<8 or if all blocks after number 8 have already been acknowledged

Tx-Anteil

Der Tx-Teil ist in Paketen des Formats 1 enthalten, um den übertragenen Inhalt zu beschreiben, sodass der Empfänger Blöcke anhand bestimmter Nutzdaten erkennen und rekonstruieren kann. Sein Format und seine Felder sind in Abbildung 5.9 dargestellt. Für bis zu vier Nutzdaten können detaillierte Angaben gemacht werden.

Abbildung 5.9 – PDU-Header-Bereich, Format und Felder des Tx-Teils

• TxPayloadMap: Gibt an, welche der nächsten vier Nutzdaten (P+0 bis P+3) im Übertragungsfenster Blöcke enthalten, die in diesem Paket enthalten sind
• DscType P+k (2b pro Nutzlast): Beschreibt das Format des folgenden LL-Deskriptors für die Nutzlast k
  • 00: Fehlt (keine Blöcke aus dieser Nutzlast)
  • 01: 2-Oktett-Deskriptor
  • 10: 5-Oktett-Deskriptor
  • 11: 6-Oktett-Deskriptor
• LL-Deskriptor (2, 5 oder 6 Oktette): Enthält Metadaten für eine bestimmte Nutzlast, deren Blöcke vorhanden sind
  • Nutzdatenlänge (13b): Gesamtlänge der gesamten Nutzdaten (einschließlich MIC, falls vorhanden)
  • LLID (2b), RFU (1b): Logischer Link-Identifikator und reservierte Bits
  • Anm. (4b): Anzahl der Blöcke – 1; 0 = 1 Block, 15 = 16 Blöcke. Legt fest, in wie viele Blöcke die Nutzlast unterteilt ist.
  • Blockgröße (9b): Größe aller Blöcke der Nutzdaten mit Ausnahme des letzten Blocks (Bereich 32–511 Oktette). Die Größe des letzten Blocks ist variabel und kann zwischen 32 und „Blocksize+32“ Oktetten liegen.
    • Wenn Nb = 0 ist, kann der einzelne Block eine Größe zwischen 0 und 510 Oktetten haben.
  • TxBlockMap (8b oder 16b): Eine Bitmaske, die angibt, welche spezifischen Blöcke (wie durch Nb und BlockSize definiert) in diesem Paket enthalten sind. Eine 1 bedeutet, dass der Block vorhanden ist.
    • Nicht benötigte Bits werden auf 0 gesetzt

Erweiterte Kopfzeile

Der erweiterte Header ist eine kompakte, auf Flags basierende Struktur, die eine Vielzahl optionaler Funktionen unterstützt, ohne einen festen Overhead zu verursachen. Seine Anwesenheit wird durch das XHP-Bit (Extended Header Present) im Anfangsabschnitt angezeigt. Mit Ausnahme des Flag-Oktetts 0 sind alle Felder optional. Sein Format und seine Felder sind in Abbildung 5.10 dargestellt.

Abbildung 5.10 – PDU-Header-Bereich, Format und Felder des erweiterten Header-Teils

• Flag-Bit-Kodierung: Funktionen werden über ein 7×O+B-Schema adressiert, wobei O der auf Null basierende Flag-Oktett-Index und B die Bitposition ist (1–7, wobei Bit 0 für zukünftige Verwendung reserviert ist). Wird ein Flag-Bit auf 1 gesetzt, bedeutet dies, dass die entsprechende Funktion vorhanden ist und ihre Datenoktette im Bereich „Feature Data“ enthalten sind.
• Reihenfolge der Merkmalsdaten: Die Merkmalsdaten-Oktette werden in der strikten numerischen Reihenfolge ihrer Merkmals-IDs hinter allen Flag-Oktetten aneinandergereiht.

Der erweiterte Header unterstützt eine sorgfältig ausgewählte Reihe von Funktionen, die für HDT von großer Bedeutung sind; jede davon hat einen bestimmten Zweck und unterliegt strengen Implementierungsregeln. Die Funktionen sind auf logische Transporttypen (ACL, CIS, BIS) zugeschnitten und in Tabelle 5.3 zusammengefasst.

Tabelle 5.3 – Funktionen des erweiterten Headers

Feat. Nr.	ACL	Größe	CIS	Größe	BIS	Größe
1	Datenlänge der Funktion „Erweiterter Header“	1. Oktober	Datenlänge der Funktion „Erweiterter Header“	1. Oktober	Datenlänge der Funktion „Erweiterter Header“	1. Oktober
2	Link-Qualität	2. Oktober	Link-Qualität	2. Oktober	—	—
3	—	—	NPI	0. Oktober	—	—
4	Durchflussregelung	0. Oktober	—	—	—	—
5	NPI	0. Oktober	—	—	—	—

Länge der Merkmalsdaten

• Gibt die Gesamtlänge aller nachfolgenden Merkmalsdaten-Oktette innerhalb des erweiterten Headers an
• Das Feld „Feature“ ist in allen Paketen des Formats 0, die einen erweiterten Header enthalten, OBLIGATORISCH. Diese Anforderung ist von entscheidender Bedeutung, da Pakete des Formats 0 kein explizites Längenfeld für die PDU-Header-Zone enthalten. Der Empfänger stützt sich auf diesen Wert, um den Anfang der Nutzdatenzone korrekt zu lokalisieren.
• Es ist zulässig, dieses Feld in PF1 aufzunehmen, aber es ist nicht erforderlich, das Paket wie bei PF0 zu dekodieren (wird normalerweise weggelassen, um Sendezeit zu sparen).
• Ein einzelnes Oktettfeld, das eine vorzeichenlose Ganzzahl enthält, welche die Gesamtzahl der nachfolgenden Merkmalsdaten-Oktette angibt

Link-Qualität

• Ermöglicht die adaptive Datenratensteuerung (ADR), indem dem Sender Rückmeldung über die Qualität des zuletzt empfangenen Pakets gegeben wird
• Kann nur verwendet werden, wenn die Funktion „Link Quality Feedback“ von beiden Geräten unterstützt wird.
• Ein Feld mit 2 Oktaven, das wie folgt aufgebaut ist:
  • RSSI (Bits 0–7): Anzeige der empfangenen Signalstärke
  • SNR (Bits 8–12): Signal-Rausch-Verhältnis
  • Bevorzugte Datenrate (Bits 13–15): Ein 3b-Code, der die vom Empfänger empfohlene PHY-Datenrate (HDT2–HDT7,5) für nachfolgende Übertragungen angibt. Der Wert 0 bedeutet, dass keine konkrete Empfehlung vorliegt.

Durchflussregelung

• Zwei Zustandswerte: STOP und GO
• Bietet eine sofortige, paketweise Flusssteuerung für ACL-Verbindungen
• Beim Empfang eines Pakets, das diese Funktion enthält, muss die Link-Schicht des Empfängers ihren lokalen Flusskontrollstatus für die entsprechende Richtung auf „STOP“ setzen.
• Auswirkungen des „STOP“-Zustands: Im STOP-Zustand darf der Sender nur Folgendes senden:
  • Blöcke aus Nutzdaten, für die bereits mindestens ein Block bestätigt wurde (d. h. Wiederholungsübertragungen)
  • Steuer-PDUs (erkennbar an LLID = 0b11)
• Rückkehr zu „GO“: Der Flusskontrollzustand kehrt zu „GO“ zurück, sobald ein nachfolgendes gültiges Paket empfangen wird, das kein „Stop“-Merkmal enthält; dies bedeutet, dass kein Paket im Kurzformat gesendet werden kann, wenn Sie im „STOP“-Zustand verbleiben möchten.

Null-PDU-Anzeige (NPI)

• Unterscheidet ausdrücklich zwischen einer Null-PDU (einem Protokoll-Platzhalter ohne Datenabsicht) und einer leeren PDU (einer gültigen Daten-PDU mit einer Nutzlast der Länge Null).
• Diese Funktion gilt nur für Pakete im Format 0, deren Nutzdatenbereich leer ist (Länge = 0).
• Semantik:
  • NPI = 1: Die PDU ist eine Null-PDU. Sie dient als Platzhalter (z. B. für Zeitmessungs- oder Bestätigungszwecke) und ist nicht mit einer gültigen PayloadNumber verknüpft. Sie treibt die Datensequenz nicht voran.
  • NPI = 0 oder Merkmal fehlt: Die PDU ist mit einer gültigen PayloadNumber verknüpft. Sie kann Datenoktette in ihrer Nutzlast enthalten oder eine leere PDU sein.

HEC-P

Der HEC-P (Header Error Check – PDU-Header) ist ein 24-Bit-CRC, der den gesamten PDU-Header-Bereich (mit Ausnahme des HEC-P selbst) abdeckt. Er ist nur in PF1 vorhanden (in PF0 entfällt er) und wird mit dem HPA initialisiert.

5.6 Nutzlastzone

Die Struktur der Nutzdatenzone wird durch das gewählte Paketformat bestimmt, das festlegt, wie Daten organisiert, übertragen und geschützt werden sollen. Tabelle 5.4 vergleicht und fasst die wesentlichen Unterschiede in der Nutzdatenzone zwischen Paketformat 0 und Format 1 zusammen.

Tabelle 5.4 – Vergleich der Nutzlastzonen PF0 und PF1

	PF0	PF1
Nutzlastdaten	In einem einzigen, zusammenhängenden Block enthalten und übertragen	Aus bis zu vier Nutzdaten zusammengefasst, segmentiert und in einer Folge aus mehreren Blöcken übertragen
Maximale Nutzdatenmenge pro Paket	1	1 bis 4 (identifiziert über TxPayloadMap)
Nutzlastkapazität (Größe)	0–494 Oktette + Mikrofon, falls vorhanden	0–8175 Oktette + MICs, falls vorhanden
CRC-Schutz	Ein einziger 32b-CRC, der sowohl die PDU-Header-Zone als auch die Payload-Zone abdeckt	32b CRC pro Block; auf jeden Block folgt unmittelbar sein eigener CRC.
Wichtiger Aspekt	Einfachheit; ähnlich dem gängigen PDU-Modell	Höherer Durchsatz durch längere Pakete, mit selektiver Blockbestätigung und Wiederholungsübertragungen
Unterstützung für PHY-Intervalle	Nein	Ja

Bei PF1 ist die Unterteilung in Intervalle auf der PHY-Schicht mit Terminierung und PITS zur Erhöhung der Robustheit während der Kommunikation zwingend vorgeschrieben (außer bei einer Nutzlastzone, die kürzer als ein Intervall ist).

Auf der Verbindungsebene werden Nutzdaten in Blöcke segmentiert, um selektive Bestätigungen und erneute Übertragungen zu ermöglichen. Die Blöcke werden von der Verbindungsebene mithilfe von Block-Maps/Bitmaps verfolgt und referenziert. Auf der PHY-Ebene wird die Nutzdatenzone mittels der Intervallabstandsstufe in der Bitstream-Verarbeitungspipeline weiter in Symbolströme fester Länge segmentiert, die als PHY-Intervalle bezeichnet werden.

PHY-Intervalle bestehen aus einer festen Anzahl von Symbolen, die Nutzdaten übertragen, gefolgt von einer Abschlusssymbolfolge und einer PHY-Intervall-Trainingssequenz (PITS), außer nach dem letzten Intervall. Die PITS liefert ein bekanntes Trainingsmuster, das es dem Empfänger ermöglicht, die Zeit- sowie Trägerfrequenz- und -phasenreferenzen während des Pakets zu aktualisieren, um die Auswirkungen von Kanalverschlechterungen auf die längeren, von PF1 übertragenen aggregierten Nutzdaten zu bewältigen und zu mindern und so den Durchsatz zu maximieren.

Die PHY-Intervallgröße wird über das Feld „PHY INT“ im Steuerheader konfiguriert, wie in Tabelle 5.5 dargestellt.

Tabelle 5.5 – Symbole pro PHY-Intervall

PHY INT	Symbole pro Intervall
0b00	128
0b01	256
0b10	384
0b11	512

Dieser Bitstrom für ein PHY-Intervall enthält außerdem die erforderlichen FEC-Abschlussbits und eine Nullauffüllung (sofern erforderlich). Nach der Modulation kann die tatsächliche Symbolanzahl pro PHY-Intervall je nach Datenrate leicht variieren, wie in Tabelle 5.6 dargestellt.

Beachten Sie außerdem, dass die verschiedenen PHY-Raten unterschiedliche Bitanzahlen pro Symbol aufweisen. Daher umfassen die Daten in PHY INT 0b00 bei HDT2 128 Bit (16 Oktette), bei HDT3 192 Bit (24 Oktette), bei HDT4 256 Bit (32 Oktette), 384 Bit (48 Oktette) bei HDT6 und 480 Bit (60 Oktette) bei HDT7,5.

Tabelle 5.6 – Anzahl der Symbole pro PHY-Intervall je nach Datenrate

PHY INT	HDT2	HDT3	HDT4	HDT6	HDT7.5
0b00	133	132	131	130	130
0b01	261	260	259	258	258
0b10	389	388	387	386	386
0b11	517	516	515	514	514

Zur Veranschaulichung wird in Abbildung 5.11 die Struktur für PF1 noch einmal dargestellt, wobei die zusätzliche Unterteilung der Nutzlastzone in PHY-Intervalle verdeutlicht wird.

Abbildung 5.11 – Unterteilung der PF1-Nutzlastzone in Blöcke und PHY-Intervalle

Aus der Perspektive der PHY-Schicht bietet Abbildung 5.12 zur Veranschaulichung eine alternative Darstellung aller drei HDT-Paketformate in Form von Symbolen.

Abbildung 5.12 – Darstellung der HDT-Paketformate aus Sicht der PHY-Schicht

Beachten Sie, dass Abschlusssymbole das Ende von Symbolströmen innerhalb von HDT-Paketen markieren, wobei jede Gruppe von Abschlusssymbolen aus zwei Symbolen mit ausschließlich Null-Bits besteht, die gemäß dem Schema des vorangehenden Symbolstroms moduliert sind. Bei PF0 werden Abschlusssymbole nach dem Steuerheader und nach dem kombinierten PDU-Header und der Nutzlast eingefügt. Bei PF1 erscheinen die Abschlusssymbole nach dem Steuer-Header, nach dem PDU-Header und nach jedem PHY-Intervall.

6. Bluetooth® HDT-Verbindungsschicht (LL)

Bluetooth HDT führt neue oder aktualisierte Funktionen, Verfahren und Steuer-PDUs ein, die die Fähigkeiten der Bluetooth-LE-Verbindungsschicht erweitern, um die neuen PHY- und Paketformate zu unterstützen und die mit HDT angestrebten Verbesserungen hinsichtlich Durchsatz, Leistung, Zuverlässigkeit und Sicherheit zu ermöglichen.

Allgemein gesagt definieren Funktionen die Fähigkeiten, die Geräte unterstützen können, während Prozeduren die koordinierten Vorgänge festlegen, die Geräte ausführen müssen, um diese Fähigkeiten zu nutzen oder zu verwalten. Steuer-PDUs sind Nachrichten der Verbindungsschicht, die zwischen Geräten ausgetauscht werden, um Informationen, Parameter und/oder Zustandsänderungen zu übermitteln, die zur Ausführung der Prozeduren erforderlich sind. Auf diese Weise beschreiben Funktionen, welche Fähigkeiten verfügbar sind, definieren Prozeduren, wie Geräte deren Nutzung koordinieren, und stellen Steuer-PDUs die Nachrichten bereit, die zur Durchführung dieser Koordination verwendet werden.

Dieser Abschnitt bietet einen Überblick über die durch Bluetooth HDT ermöglichten erweiterten Funktionen der Verbindungsschicht und enthält eine Zusammenfassung der neuen, aktualisierten und überarbeiteten Funktionen, Verfahren und Steuer-PDUs der Verbindungsschicht für die HDT-Aktivierung.

6.1 Überblick über die neuen Funktionen der Link-Schicht für HDT

Einleitung und Durchführung von HDT

Bluetooth® HDT wird durch verbindungsbasierte Vorgänge initiiert und verwaltet, die über physikalische Datenkanäle und den ACL-Transport ablaufen. Sobald jedoch eine HDT-fähige Verbindung zwischen Geräten hergestellt ist, kann diese zur Unterstützung einer ACL-Verbindung oder eines verbundenen isochronen Streamings genutzt werden.

Bei der isochronen Übertragung müssen Geräte GFSK-basierte Advertising-Signale verwenden, um die periodischen Advertising-Signale zu erkennen. Anschließend kann ein BIG, der ein oder mehrere BIS enthält, gesendet oder empfangen werden, ohne dass eine ACL-Verbindung erforderlich ist. Die HDT-PHY-Schicht unterstützt derzeit keinerlei Form von Advertising.

Insgesamt muss der HDT-Betrieb stets explizit über die definierten Verfahren der Verbindungsschicht initiiert werden. Er erfordert zudem eine symmetrische PHY-Nutzung in beiden Verbindungsrichtungen (mit Ausnahme von Broadcasts), was bedeutet, dass sowohl für den Sendevorgang als auch für den Empfangsvorgang je nach Fall entweder der HDT-PHY oder beide GFSK-PHYs verwendet werden müssen. Bei Verwendung des HDT-PHYs kann die Datenrate von Paket zu Paket unabhängig variieren, wobei nicht erforderlich ist, dass in beiden Richtungen dieselbe Rate verwendet wird.

Das neue HDT-Konfigurationsaustauschverfahren ermöglicht es Geräten, miteinander zu kommunizieren und unterstützte HDT-Funktionen (z. B. maximale Datenrate, Paketformate, Nutzdatengrößen usw.) auszuhandeln. Anschließend kann durch die Ausführung des PHY-Update-Verfahrens unter Verwendung der aktualisierten Steuer-PDUs LL_PHY_REQ [v2], LL_PHY_RSP [v2] und LL_PHY_UPDATE_IND [v2] die Kommunikation auf den HDT-PHY umgestellt oder der Übergang in den HDT-Modus bzw. der Ausstieg daraus gesteuert werden. Wenn die HDT-Fähigkeiten zwischen Geräten inkompatibel oder nicht unterstützt sind oder die Betriebsbedingungen dies erfordern, kann die Kommunikation auf einem GFSK-PHY verbleiben oder zu diesem zurückkehren, wobei alle PHY-Zustandsänderungen dem Host über HCI-Ereignisse gemeldet werden, um Transparenz und Kontrolle zu gewährleisten.

HDT – Verwaltung der Datenlänge und Zeitplanung

HDT führt Funktionen zur Verwaltung der Datenlänge ein, die es der Link-Schicht ermöglichen, für jede Verbindung über die HDT- und GFSK-PHYs separate Parameter für Übertragungslänge und Timing zu verwalten. Darüber hinaus ermöglichen aktualisierte Wertebereichsgrenzen für diese Parameter größere Paketnutzdaten und sorgen gleichzeitig dafür, dass die maximalen Sendezeitgrenzen für Pakete eingehalten werden. Ein Controller kann große Nutzdaten in mehrere Blöcke aufteilen oder bei Bedarf die gewählte Datenrate anpassen, um die Paketübertragungszeiten innerhalb festgelegter Grenzen zu halten. Dadurch wird sichergestellt, dass die Zeit- und Planungsanforderungen für Bluetooth-LE-Verbindungsereignisse sowie für den gleichzeitigen Betrieb mehrerer Verbindungen und/oder isochroner Datenströme erfüllt werden können.

Mit der Prozedur „Data Length Update“ können Geräte die maximalen Sende- und Empfangsgrößen sowie die Timing-Parameter übermitteln, die für LL-Daten-PDUs zu verwenden sind. Durch die Ausführung der Prozedur mit den aktualisierten Steuer-PDUs LL_LENGTH_REQ [v2] und LL_LENGTH_RSP [v2] lässt sich festlegen, für welche PHY die Parameter gelten.

HDT-Verbindungsqualität

HDT erweitert Bluetooth LE um eine optionale Funktion zur Rückmeldung der Verbindungsqualität (Link Quality Feedback, LQF), die den Austausch von Echtzeitinformationen über die Kanalbedingungen mittels eines speziellen Verfahrens auf Verbindungsebene ermöglicht. Ist diese Funktion aktiviert, werden Kennzahlen zur Verbindungsqualität in die übertragenen Pakete aufgenommen und kontinuierlich zwischen den Controllern ausgetauscht. Diese Informationen ermöglichen es, dynamische Entscheidungen zum Verbindungsbetrieb als Reaktion auf sich ändernde Funkbedingungen zu treffen, wie beispielsweise die Anpassung von Übertragungsparametern, die Auswahl einer anderen HDT-Datenrate oder den Rückgriff auf eine GFSK-PHY-Schicht, wenn die Bedingungen dies erfordern.

Geräte können das neue Verfahren „HDT Link Quality Enable“ zusammen mit der neuen Steuer-PDU „LL_HDT_LQF_REPORTING_IND“ verwenden, um anzugeben, wann Informationen zur Verbindungsqualität in Paketen enthalten sein sollen bzw. nicht mehr enthalten sein sollen.

HDT und isochrone Kanäle

HDT erweitert die isochronen Übertragungsmöglichkeiten von Bluetooth LE, um verbundene oder gesendete isochrone Datenströme über die neue HDT-PHY-Schicht zu unterstützen.

Geräte können HDT-spezifische Betriebsparameter (z. B. HDT-PHY, Datenraten, Nutzdatenfenstergrößen, usw.) aushandeln und zeitgebundene isochrone Datenströme einrichten, die große Nutzdatenmengen zuverlässig über das HDT-PHY übertragen können, sowie Pakete mithilfe des Verfahrens zur Erstellung verbundener isochroner Datenströme (Connected Isochronous Stream Creation) unter Verwendung der aktualisierten Steuer-PDUs LL_CIS_REQ [v2] und LL_CIS_IND [v2]. Insbesondere ist eine verbundene isochrone Kommunikation mit hohem Durchsatz entscheidend für die Realisierung hochwertiger Audiolösungen und -anwendungen mit Bluetooth LE.

Für die Rundfunkübertragung wird der Zustand „Isochronous Broadcasting“ des Luftschnittstellenprotokolls der Verbindungsschicht aktualisiert und umfasst nun breitere Wertebereiche für den BIG-Parameter zur Verwaltung der HDT-Datenlänge, überarbeitete BIGInfo-Header-Felder sowie die Unterstützung blockbasierter Bestätigungen. Dadurch können synchronisierte Empfänger HDT für Rundfunkströme mit hohem Durchsatz nutzen, wobei die bestehenden Zeit- und Synchronisationsanforderungen eingehalten werden, die für periodische Advertising- und isochrone Rundfunkübertragungen definiert sind.

HDT – Sicherheit und Verschlüsselung

HDT verbessert die Sicherheit von Bluetooth LE durch die Einführung der Unterstützung für größere Message Integrity Check (MIC)-Größen sowie der neuen Funktion „Encryption Key Schedule“ (EKS) zur Generierung und Aktualisierung von Verschlüsselungsschlüsseln. Die Link-Schicht koordiniert den Austausch von Parametern zwischen den Geräten und verwaltet den Übergang in den HDT-Betrieb, wobei die Kommunikation verschlüsselt bleibt.

Mit dem neuen Verfahren „Encryption Start with Key Schedule“ können Geräte verschlüsselungsbezogene Parameter austauschen und über die Steuer-PDUs LL_ENC_ECDH_REQ und LL_ENC_ECDH_RSP eine der neuen, von HDT unterstützten MIC-Größen (128b oder 64b) für die Verbindung auswählen. Sobald die Langzeit- und Sitzungsschlüssel für die Verbindungsverschlüsselung von den Geräten berechnet wurden, wird die Verschlüsselung über die PDUs „LL_START_ENC_REQ“ und „LL_START_ENC_RSP“ gestartet. Beachten Sie, dass EKS auch mit GFSK-PHYs verwendet werden kann; in diesem Fall ist ausschließlich eine MIC-Größe von 32b zulässig.

Darüber hinaus ermöglicht das Verfahren „PHY-Update und Verschlüsselungsaktualisierung“ bei Geräten, die die EKS-Funktion unterstützen, die gleichzeitige Durchführung einer PHY-Änderung und einer Verschlüsselungsschlüsselaktualisierung, ohne die Verbindung zu trennen oder die Verschlüsselung zu unterbrechen – und zwar mithilfe der aktualisierten Steuer-PDUs LL_PHY_REQ [v2], LL_PHY_RSP [v2] und LL_PHY_UPDATE_IND [v2]. Zur Verdeutlichung: Eine Änderung der MIC-Größe erzwingt immer eine Schlüsselaktualisierung, eine Schlüsselaktualisierung erzwingt jedoch keine Änderung der MIC-Größe.

In Abschnitt 7 dieses Dokuments wird die HDT-Verschlüsselung ausführlicher behandelt.

HDT-Zuverlässigkeit und Durchflussregelung

HDT ermöglicht Mechanismen auf der Link-Schicht zur blockbasierten Auswertung von Nutzdaten, um Übertragungsfehler zu erkennen und zu beheben. Die bestehenden Mechanismen zur Sequenznummerierung und Bestätigung in Bluetooth LE werden weiterhin für die kumulative Bestätigung von Nutzdaten und zur Aufrechterhaltung der Paketreihenfolge verwendet, doch HDT ergänzt diese durch die selektive Bestätigung von Blöcken. Die Felder „SN“, „NESN“, „RxPayloadMap“, „RxBitmap“, „Nb“ und „BlockSize“ in HDT-Paketen werden von der Link-Schicht verwendet, um zu prüfen, ob ein Block bestätigt wurde oder nicht, und um anschließend festzustellen, ob eine erneute Übertragung erforderlich ist. Dadurch wird der Overhead bei der erneuten Übertragung minimiert, da nur die betroffenen Teile einer großen Nutzlast erneut gesendet werden.

HDT verbessert zudem die Flusskontrolle auf der Link-Schicht durch einen Mechanismus zur sofortigen Flussunterbrechung, der es einem empfangenden Gerät ermöglicht, die Übertragung neuer Nutzdaten vorübergehend anzuhalten, wenn zusätzliche Puffer- oder Verarbeitungszeit benötigt wird. Anhand von Informationen, die in einem erweiterten Paket-Header enthalten sind, kann ein Empfänger einem Gegenstück signalisieren, die Übertragung neuer Daten zu unterbrechen, während die Wiederholungsübertragung fortgesetzt werden kann. Sobald der Empfänger bereit ist, weiteren Datenverkehr anzunehmen, kann die normale Datenübertragung wieder aufgenommen werden, ohne dass eine Neukonfiguration der Verbindung oder andere Eingriffe auf höheren Schichten erforderlich sind.

6.2 Merkmale der Link-Schicht für HDT

Die Bluetooth-LE-Verbindungsschicht verwendet die in [Band 6], Teil B, Abschnitt 4.6 der Bluetooth-Kernspezifikation definierte Bitmaske „ FeatureSet “, um die von einem Controller unterstützten Funktionen zu identifizieren. Für HDT führt die „ FeatureSet “ ein Bit ein, das die Unterstützung der grundlegenden HDT-Funktion kennzeichnet, sowie zusätzliche Bits, die die Unterstützung optionaler HDT-Funktionen kennzeichnen, darunter höhere HDT-Raten, Paketformat 1, Rückmeldung zur Verbindungsqualität und isochroner Betrieb über die HDT-PHY.

Im Folgenden sind die HDT-bezogenen „ FeatureSet “-Bits aufgeführt, die eingeführt wurden, um die Unterstützung für HDT-Funktionen darzustellen:

• 77 – Hoher Datendurchsatz
• 78 – HDT6-Tarif erhalten
• 79 – HDT6-Rate senden
• 80 – HDT7.5-Tarif erhalten
• 81 – HDT7.5-Rate senden
• 82 – HDT-Paketformat 1
• 83 – Feedback zur Linkqualität
• 84 – Isochroner Sender auf dem LE-HDT-PHY
• 85 – Synchronisierter Empfänger auf dem LE-HDT-PHY

Für jedes „ FeatureSet “-Bit definiert die Spezifikation die Anforderungen, die ein Controller erfüllen muss, um die Unterstützung der entsprechenden Funktion anzuzeigen, einschließlich – sofern zutreffend – der zugehörigen PHY-Funktionen, Paketformate, Verfahren und Steuer-PDUs.

Im Folgenden werden die verbindlichen Anforderungen im Zusammenhang mit dem „High Data Throughput“ FeatureSet -Bit beschrieben. Für alle übrigen „ FeatureSet “-Bits, die die Unterstützung optionaler HDT-Funktionen kennzeichnen, finden Sie die vollständigen Definitionen und die zugehörigen Unterstützungsanforderungen in [Band 6], Teil B, Abschnitt 4.6 der Bluetooth-Kernspezifikation.

Hoher Datendurchsatz

Ein Controller, der die Funktion „High Data Throughput“ (HDT) unterstützt, muss außerdem die Funktionen „LE-Verschlüsselung mit Diversifikatoren“, „LE-Datenpaketlängenverlängerung“, „Verschlüsselungsschlüsselplan“ und „Kanalauswahlalgorithmus Nr. 2“ sowie die folgenden HDT-Funktionen unterstützen:

• LE HDT PHY (siehe [Band 6], Teil A, Abschnitte 3.6 und 4.1.2)
• HDT-Symbolstromverarbeitung ([Band 6] Teil A, Abschnitt 7), ausgenommen:
  • PHY-Intervalle ([Band 6] Teil A, Abschnitt 7.2)
  • 16QAM-Symbolzuordnung ([Band 6] Teil A, Abschnitt 7.3.3)
  • PITS ([Band 6] Teil A, Abschnitt 7.4.5)
• RMS- und EVM-Werte des Senders ([Vol. 6] Teil A, Anhang C)
• Paketformat für den LE-HDT-PHY ([Band 6] Teil B, Abschnitt 2.7), ausgenommen:
  • Paketformat 1
  • Struktur des Nutzdatenblocks ([Band 6] Teil B, Abschnitt 2.7.4)
  • Verbindungsqualität ([Band 6] Teil B, Abschnitt 2.7.2.4.1)
• 32b CRC-Erzeugung ([Band 6] Teil B, Abschnitt 3.1.2)
• Bitstromverarbeitung für LE HDT ([Band 6] Teil B, Abschnitt 3.4), ausgenommen:
  • Intervallabstände ([Band 6] Teil B, Abschnitt 3.4.2)
• Verfahren zum Austausch von HDT-Konfigurationen ([Band 6] Teil B, Abschnitt 5.1.34), mit Ausnahme von:
  • Anwendungen, bei denen isochrone Sender, synchronisierte Empfänger sowie isochrone Broadcast-Streams, -Gruppen und -PDUs auf dem LE-HDT-PHY zum Einsatz kommen
• PDUs „LL_LENGTH_REQ [v2]“ und „LL_LENGTH_RSP [v2]“
• PDUs „LL_HDT_CONFIG_REQ“ und „LL_HDT_CONFIG_RSP“

Darüber hinaus muss ein Controller, der die Funktion „Hoher Datendurchsatz“ sowie die Funktion „Connected Isochronous Stream“ (zentral oder peripher) unterstützt, auch Folgendes unterstützen:

• LL_CIS_REQ [v2] und LL_CIS_IND [v2]

Weitere Einzelheiten finden Sie unter ([Band 6] Teil B, Abschnitt 4.6.54).

6.3 Verfahren der Verbindungsschicht für HDT

6.3.1 Neue Verfahren

Zur Unterstützung der HDT-Funktionen werden die folgenden Verfahren in das Link-Layer-Steuerungsprotokoll für ACL-Verbindungen aufgenommen:

• Vorgehensweise beim Austausch der HDT-Konfiguration
• Vorgehensweise zum Aktivieren der HDT-Verbindungsqualität

Im Folgenden finden Sie eine Übersicht über deren Funktion sowie die PDUs, die für deren Einleitung und Abschluss erforderlich sind. Beachten Sie, dass diese Vorgänge erst durchgeführt werden können, nachdem der ACL-Link den Status „Connection“ erreicht hat.

Vorgehensweise beim Austausch der HDT-Konfiguration

Ändert die Konfigurationswerte, die einer Verbindung auf dem LE-HDT-PHY zugeordnet sind. Die ausgetauschten Werte haben keine Auswirkungen auf bereits vorhandene ACLs oder CISes auf dem LE-HDT-PHY. Die Werte werden für anschließend erstellte CISes wirksam sowie für die ACL, wenn von einem GFSK-PHY auf den LE-HDT-PHY umgeschaltet wird. Der Vorgang wird durch das Senden der PDU „LL_HDT_CONFIG_REQ“ eingeleitet und ist abgeschlossen, sobald die PDU „LL_HDT_CONFIG_RSP“ empfangen wurde. Jede gesendete PDU bezieht sich ausschließlich auf die Konfiguration des sendenden Geräts, wodurch Kollisionen zwischen auf beiden Seiten initiierten Vorgängen harmlos sind.

Vorgehensweise zum Aktivieren der HDT-Verbindungsqualität

Weist einen Remote-Controller an, die Übertragung von Rückmeldungen zur Verbindungsqualität in jedem über die angegebenen Transportprotokolle gesendeten Paket zu starten oder zu beenden. Der Vorgang wird durch das Senden der PDU „LL_HDT_LQF_REPORTING_IND“ eingeleitet und ist abgeschlossen, sobald die Bestätigung der PDU „LL_HDT_LQF_REPORTING_IND“ empfangen wurde. Die Rückmeldung zur Verbindungsqualität wird mit demselben Verfahren deaktiviert.

6.3.2 Aktualisierte Verfahren

Die folgenden Verfahren zur ACL-Steuerung wurden angepasst, um die Unterstützung von HDT-Funktionen zu ermöglichen:

• Verschlüsselungsverfahren
  • Verschlüsselung: Beginn mit dem „Diversifiers“-Verfahren (Teil 1)
  • Verschlüsselung: Beginn mit dem Schlüsselplanungsverfahren (Teil 1)
  • Verschlüsselungsstart mit Diversifikatoren und Verschlüsselungsstart mit Schlüsselplanverfahren (Teil 2)
  • Vorgehensweise bei einer Verschlüsselungspause
• Vorgehensweise zur Aktualisierung der Datenlänge
• Vorgehensweise zur Aktualisierung der PHY-Einstellungen und zur Erneuerung der Verschlüsselung
• Vorgehensweise zur Erstellung eines vernetzten isochronen Streams
• Vorgehensweise zur Aktualisierung des Frame-Speichers

Im Folgenden finden Sie eine Übersicht über die Funktionen aller aktualisierten Prozeduren sowie die PDUs, die zu deren Einleitung und Abschluss erforderlich sind. Beachten Sie auch hier, dass diese Prozeduren erst nach dem Wechsel in den Verbindungszustand für die ACL-Verbindung ausgeführt werden können.

Verschlüsselungsverfahren

Aktivieren Sie die Verschlüsselung und Authentifizierung von Daten-PDUs, um die Vertraulichkeit und Integrität der Nutzdaten zu schützen. Wenn sowohl die Zentrale als auch das Peripheriegerät die Funktion „Encryption Key Schedule“ (EKS) unterstützen, initiiert die Zentrale das Verfahren „Encryption Start with Key Schedule“; andernfalls initiiert sie das Verfahren „Encryption Start with Diversifiers“. Sobald die Verbindung verschlüsselt ist, kann der Verschlüsselungsschlüssel von der Verbindungsschicht mithilfe des Verfahrens „PHY Update and Encryption Refresh“ geändert werden, sofern sowohl die Zentrale als auch das Peripheriegerät EKS unterstützen; andernfalls erfolgt dies über das Verfahren „Encryption Pause“.

Sowohl das Verfahren „Verschlüsselung mit Diversifikatoren“ als auch das Verfahren „Verschlüsselung mit Schlüsselschema“ bestehen aus zwei Teilen. Der erste Teil unterscheidet sich bei beiden Verfahren, während der zweite Teil bei beiden gleich ist.

Verschlüsselung: Beginn mit dem „Diversifiers“-Verfahren (Teil 1)

Um die Verschlüsselung zu aktivieren, generieren die Zentrale und das Peripheriegerät ihre jeweiligen Anteile am Initialisierungsvektor (IV) und am Session Key Diversifier (SKD) und tauschen diese über die PDUs „LL_ENC_REQ“ und „LL_ENC_RSP“ aus. Anschließend kombiniert jede LL die IV- und SKD-Teile. Der Host des Peripheriegeräts teilt seiner LL den zu verwendenden Langzeitschlüssel (LTK) mit. Die Verschlüsselung wird über einen Drei-Wege-Handshake unter Verwendung der PDUs „LL_START_ENC_REQ“ und „LL_START_ENC_RSP“ gestartet.

Verschlüsselung: Beginn mit dem Schlüsselplanungsverfahren (Teil 1)

Um die Verschlüsselung zu aktivieren, generieren die Zentrale und das Peripheriegerät ihre jeweiligen Anteile des öffentlichen Schlüssels (PubKey) und der Zufallszahl (Rand) und tauschen diese über die PDUs „LL_ENC_ECDH_REQ“ und „LL_ENC_ECDH_RSP“ aus. Bei Verwendung einer GFSK-PHY-Schicht wird für die Verbindung ein 32-Bit-MIC verwendet. Bei Verwendung der HDT-PHY-Schicht wird für die Verbindung ein 128-Bit-MIC verwendet, sofern nicht Flags für einen 64-Bit-MIC gesetzt sind.

Verschlüsselungsstart mit Diversifikatoren und Verschlüsselungsstart mit Schlüsselplan (Teil 2)

Legt fest, welche Art von Langzeitschlüssel (LTK) verwendet werden soll (z. B. ausschließlich Nullen, wenn opportunistische Verschlüsselung zum Einsatz kommt) und woher dieser stammt (z. B. vom Host an die LL übermittelt) – zur Verschlüsselung. Im Fall der Zentrale übermittelt der Host den LTK stets an die Verbindungsschicht. Im Fall des Peripheriegeräts ist dies nicht zwingend der Fall; wenn dies geschieht, verwendet die LL ihn zur Berechnung des Sitzungsschlüssels. Die Berechnung des Sitzungsschlüssels basiert auf [Band 3], Teil H, Abschnitt 2.2.1 für den Verschlüsselungsstart mit Diversifikatoren und auf [Band 6], Teil E, Abschnitt 4.2.1 für den Verschlüsselungsstart mit Schlüsselplan.

Vorgehensweise bei einer Verschlüsselungspause

Fasst beide Verfahren zum Start der Verschlüsselung zusammen. Daher gelten dieselben Aktualisierungen.

Vorgehensweise zur Aktualisierung der Datenlänge

Dient dazu, die aktuellen Werte für die maximalen Empfangs- und Sende-Nutzdatenlängen sowie die Zeiten für die LL-Daten-PDU (connMaxRxOctets, connMaxRxTime, connMaxTxOctets und connMaxTxTime) an ein Peer-Gerät zu übermitteln. Eine Aktualisierung des Wortlauts der Spezifikation stellt klar, dass, falls der Controller mehr als einen Parametersatz für die Verbindung unterstützt, im Rahmen des Verfahrens ausgewählt werden kann, welcher Satz aktualisiert werden soll. Das Verfahren wird entweder durch die Übertragung der PDU „LL_LENGTH_REQ“ durch die Zentrale oder durch das Peripheriegerät initiiert. Die Anfrage wird mit einer PDU „LL_LENGTH_RSP“ beantwortet. Die Antwort aktualisiert den in der Anfrage-PDU angegebenen Parametersatz.

Vorgehensweise zur Aktualisierung der PHY-Einstellungen und zur Erneuerung der Verschlüsselung

Wird verwendet, um die Tx- oder Rx-PHYs (oder beide) einer ACL-Verbindung zu ändern oder den Verschlüsselungsschlüssel und den IV zu aktualisieren, sofern die Geräte die EKS-Funktion unterstützen, oder beides. Dies hat keine Auswirkungen auf PHYs oder Schlüssel/IVs, die mit CISes verknüpft sind. Eine Anforderung wird mithilfe der PDU „LL_PHY_REQ“ initiiert. Die Antwort auf die Anforderung erfolgt mit der PDU „LL_PHY_RSP“. Die Zentrale sendet im letzten Schritt immer eine PDU vom Typ „LL_PHY_UPDATE_IND“.

HDT führt Formulierungen für Regeln ein, die klären, wie mit Daten, die sich in der Übertragung befinden oder in der Warteschlange stehen, vor der Anforderung oder Beantwortung eines PHY-Updates umgegangen werden soll, wie die Aktualisierung des Verschlüsselungsschlüssels zu handhaben ist, welche Verhaltensweisen ungültig sind usw. Darüber hinaus führt HDT die [v2] der PDUs ein, die ein „Refresh“-Feld enthalten, um (im Fall von LL_PHY_REQ/RSP) eine Auffrischungsanforderung für den Verschlüsselungsschlüssel zu erfordern oder (im Fall von LL_PHY_UPDATE_IND) anzuzeigen, sowie ein „MIC_Length“-Feld, um die bevorzugte MIC-Länge auf dem HDT-PHY anzugeben. Beachten Sie, dass eine MIC-Länge von 64 Bit nur dann ausgewählt wird, wenn beide Seiten dies erfordern; ein Gerät kann die von seinem Gegenstück geforderte Sicherheit nicht herabsetzen.

Vorgehensweise zur Erstellung eines vernetzten isochronen Streams

Wird verwendet, um eine CIS zwischen einer Zentrale und einem Peripheriegerät zu erstellen. Die Anforderung wird ausschließlich von einer Zentrale mithilfe der PDU „LL_CIS_REQ“ initiiert. Das Peripheriegerät antwortet auf die Anforderung im Falle einer Annahme mit der PDU „LL_CIS_RSP“ oder im Falle einer Ablehnung mit der PDU „LL_REJECT_EXT_IND“ und dem entsprechenden Grundcode. Nach Erhalt der Antwort erstellt die Zentrale die CIS, indem sie mit der PDU „LL_CIS_IND“ antwortet, oder sie bricht sie mit der PDU „LL_REJECT_EXT_IND“ ab. HDT führt Regeln ein, die die Anforderungen für die Erstellung einer CIS auf den GFSK- oder HDT-PHYs sowie für die Verwendung von PDU-Versionen, symmetrischen PHYs und der EKS-Funktion klarstellen.

6.4 PDUs der Link-Layer-Steuerung für HDT

6.4.1 Neue Steuer-PDUs

Im Folgenden werden neue Steuer-PDUs (für physikalische Datenkanäle) vorgestellt, die eingeführt wurden, um Anfragen, Antworten oder Meldungen im Zusammenhang mit den neu definierten Verfahren zur HDT-Unterstützung über Funk zu übermitteln:

• (0x40) LL_ENC_ECDH_REQ
• (0x41) LL_ENC_ECDH_RSP
• (0x42) LL_HDT_CONFIG_REQ
• (0x43) LL_HDT_CONFIG_RSP
• (0x44) LL_HDT_LQF_REPORTING_IND.

Im Folgenden werden das Format ihres „CtrData“-Feldes sowie einzeilige Beschreibungen für jedes darunter liegende Feld aufgeführt.

LL_ENC_ECDH_REQ

• Flags_C: Verschlüsselungsflags von Central [Bit 0: 0 = 128-Bit-MIC, 1 = 64-Bit-MIC; Bit 1: Opportunistische Verschlüsselung]
• Rand_C: Von der Zentrale bereitgestellte Zufallszahl
• KeyType_C: Typ des von Central verwendeten öffentlichen Schlüssels [0 = abgeleitet unter Verwendung der elliptischen Kurve P-256]
• PubKey_C: Öffentlicher ECDH-Schlüssel von Central [Pubkey_C31-0 = X-Koordinate, Pubkey_C63-32 = Y-Koordinate]

LL_ENC_ECDH_RSP

• Flags_P: Verschlüsselungsflags des Peripheriegeräts [Bit 0: 0 = 128-Bit-MIC, 1 = 64-Bit-MIC]
• Rand_P: Von Peripheral bereitgestellte Zufallszahl
• KeyType_P: Art des von Peripheral verwendeten öffentlichen Schlüssels [0 = abgeleitet unter Verwendung der elliptischen Kurve P-256]
• PubKey_P: Öffentlicher ECDH-Schlüssel des Peripheriegeräts [Pubkey_C31-0 = X-Koordinate, Pubkey_C63-32 = Y-Koordinate]

LL_HDT_CONFIG_REQ und LL_HDT_CONFIG_RSP

• ACL_RX_Payload_Window_Size: Wird in Empfangsrichtung auf den Wert gesetzt, der um eins kleiner ist als der bei der ACL-Verbindung verwendete Wert für PayloadWindowSize; Standardwert = 0
• Max_CIS_TX_Payload_Window_Size: Setzen Sie diesen Wert auf einen Wert, der um eins kleiner ist als die maximale Nutzdatenfenstergröße, die auf dem zugehörigen CIS in TX-Richtung verwendet wird; Standardwert = 0
• Max_CIS_RX_Payload_Window_Size: Setzen Sie diesen Wert auf den Wert, der um eins kleiner ist als die maximale Nutzdatenfenstergröße, die auf dem zugehörigen CIS in Empfangsrichtung verwendet wird; Standardwert = 0
• ACL_RX_Rates: Übertragungsraten, die der Controller von einem Remote-Controller über die ACL-Verbindung empfangen darf [Bit 0: HDT2; Bit 1: HDT3; Bit 2: HDT4; Bit 3: HDT6; Bit 4: HDT7,5]
• Max_ACL_RX_Octets_Per_Packet: Maximale Anzahl an Datenoktetten, die in einem einzelnen Paket über die ACL-Verbindung empfangen werden können. Ausgenommen sind MIC, Abschlusssequenzen, PITS usw.

LL_HDT_LQF_REPORTING_IND

• Transport: Gibt an, für welche logischen Transporte die LQF-Berichterstellung für [Bit 0: ACL; Bit 1: CIS] aktiviert oder deaktiviert ist.

6.4.2 Aktualisierte Steuer-PDUs

Im Folgenden sind aktualisierte Steuer-PDUs (für physikalische Datenkanäle) aufgeführt, die Änderungen oder zusätzliche Felder enthalten, um Anfragen, Antworten oder Meldungen im Zusammenhang mit den aktualisierten Verfahren der Verbindungsschicht zur Unterstützung von HDT über Funk zu übermitteln:

• (0x14) LL_LENGTH_REQ
• (0x15) LL_LENGTH_RSP
• (0x16) LL_PHY_REQ
• (0x17) LL_PHY_RSP
• (0x18) LL_PHY_UPDATE_IND
• (0x1F) LL_CIS_REQ
• (0x21) LL_CIS_IND
• (0x23) LL_POWER_CONTROL_REQ.

Im Folgenden werden das Format ihres „CtrData“-Feldes sowie einzeilige Beschreibungen für jedes darunter liegende Feld aufgeführt, das entweder geändert oder hinzugefügt wurde. Hinweis: Aufgrund der Anpassungen für die HDT-Unterstützung können diese LL-Control-PDUs nun mehr als ein Format aufweisen, das durch [v1] oder [v2] gekennzeichnet ist. Jedes Feld innerhalb des „CtrData“-Feldes hat in allen Formaten, in denen es vorkommt, dieselbe Bedeutung.

LL_LENGTH_REQ und LL_LENGTH_RSP

• PHY_S: Gibt an, für welchen Satz von PHY-Parametern die PDU gilt [0=GFSK; 1=HDT]; das Feld wird in LL_LENGTH_RSP ignoriert

LL_PHY_REQ und LL_PHY_RSP

• TX_PHYS: Der Sender bevorzugt folgende PHY-Konfiguration: [Bit 0: LE_1M; Bit 1: LE_2M; Bit 2: LE Coded; Bit 4: HDT]
• RX_PHYS: Der Sender bevorzugt folgende Empfänger-PHYs: [Bit 0: LE_1M; Bit 1: LE_2M; Bit 2: LE Coded; Bit 4: HDT]
• Aktualisierung: Schlüsselaktualisierung [1=erforderlich]; Wert=0, falls nicht angegeben, oder wird ignoriert, wenn die Verbindung nicht verschlüsselt ist oder wenn eines der Geräte die EKS-Funktion nicht unterstützt
• MIC_Length: [1 = Anforderung eines 64-Bit-MIC für HDT, 0 oder nicht angegeben = 128-Bit-MIC für HDT]; wird ignoriert, wenn die Verbindung nicht verschlüsselt ist, der Schlüssel nicht aktualisiert wurde oder auf GFSK-PHY umgeschaltet wird

LL_PHY_UPDATE_IND

• PHY_C_TO_P: PHY für von der Zentrale gesendete Pakete [Bit 0: LE_1M; Bit 1: LE_2M; Bit 2: LE Coded; Bit 4: HDT]
• PHY_P_TO_C: PHY für von Peripheriegeräten gesendete Pakete [Bit 0: LE_1M; Bit 1: LE_2M; Bit 2: LE Coded; Bit 4: HDT]
• Sofort: Bestimmtes Verbindungsereignis in der Zukunft, auf das der Zählwert des Verbindungsereigniszählers verweist
• Adresse: Physikalische Kanaladresse für den PHY, der ab diesem Zeitpunkt für die ACL-Verbindung verwendet wird
• Aktualisieren: 1 = Der Verschlüsselungsschlüssel wird aktualisiert; 0 oder nicht angegeben = Der Verschlüsselungsschlüssel wird nicht aktualisiert oder die Verbindung ist nicht verschlüsselt
• MIC_Length: [1 = Aktualisierung und 64-Bit-MIC für HDT, 0 oder nicht angegeben = 128-Bit-MIC für HDT]; wird ignoriert, wenn die Verbindung nicht verschlüsselt ist, der Schlüssel nicht aktualisiert wurde oder auf GFSK-PHY umgeschaltet wird

LL_CIS_REQ

• Max_Payload_C_To_P: Maximale Nutzdatengröße (in Byte) auf der Verbindungsschicht, die die Zentrale in einer CIS-PDU übertragen darf
• Max_Payload_P_To_C: Maximale Nutzdatengröße (in Byte) auf der Verbindungsschicht, die das Peripheriegerät in einer CIS-PDU übertragen darf
• Rates_C_To_P: Von der Zentrale zugelassene Raten [Bit 0: HDT2; Bit 1: HDT3; Bit 2: HDT4; Bit 3: HDT6; Bit 4: HDT7,5]
• Rates_P_To_C: Zulässige Raten vom Peripheriegerät [Bit 0: HDT2; Bit 1: HDT3; Bit 2: HDT4; Bit 3: HDT6; Bit 4: HDT7,5]
• Payload_Window_Size_C_To_P: Anzahl der Payloads im Fenster, die Central verfolgen, übertragen und erneut übertragen kann (von 1 bis 4)
• Payload_Window_Size_P_To_C: Anzahl der Payloads im Fenster, die das Peripheriegerät verfolgen, übertragen und erneut übertragen kann (von 1 bis 4)
• MIC_Length: Wenn CIS auf HDT-PHY läuft und verschlüsselt ist, gilt 1 = 64-Bit-MIC und 0 = 128-Bit-MIC, andernfalls wird dieser Wert ignoriert.
• SE_Length: Zeit (in us), die für das Unterereignis reserviert werden muss

LL_CIS_IND

• Bei CIS auf GFSK-PHY: AA = Zugriffsadresse des CIS oder 0, wenn PCA-H in der PDU enthalten ist
• Wenn CIS von HDT PHY: AA=HPA31-0, dann muss PCA-H vorhanden und auf HPA39-32 eingestellt sein

LL_POWER_CONTROL_REQ

• PHY: PHY, für den die Anfrage gestellt wird [Bit 0: 1M; Bit 1: 2M; Bit 2: codiert S=8; Bit 3: codiert S=2; Bit 4: HDT]

7. Bluetooth®-HDT-Verschlüsselung

HDT erweitert das Rahmenwerk für die Verschlüsselung und Authentifizierung von Bluetooth LE, um einen stärkeren Datenschutz zu gewährleisten, die Kompatibilität mit dem bestehenden Sicherheitsmodell zu wahren und sicherzustellen, dass die Bluetooth-Technologie mit den Sicherheitstrends der Branche und den regulatorischen Anforderungen Schritt halten kann.

Dieser Abschnitt bietet einen Überblick über die durch Bluetooth® HDT ausgelösten Verbesserungen im Bereich der Verschlüsselung sowie eine Zusammenfassung der neuen Funktionen, Verfahren und Parameter, die zu deren Umsetzung eingeführt wurden.

7.1 Überblick über die Verbesserungen bei der HDT-Verschlüsselung

HDT erweitert die Verschlüsselungsfunktionen von Bluetooth LE durch die Einführung der Unterstützung für größere „Message Integrity Check“ (MIC)-Größen sowie für die neue „Encryption Key Schedule“ (EKS)-Funktion, die mit Bluetooth Core 7.0 eingeführt wurde. Der gesamte Verschlüsselungs- und Authentifizierungsprozess stützt sich jedoch weiterhin auf bewährte kryptografische Algorithmen, wobei ECDH für die Einrichtung eines gemeinsamen Geheimnisses, AES-CMAC für die Schlüsselableitung und AES-CCM für die Datenverschlüsselung und den Integritätsschutz verwendet werden.

Unterstützung für größere MIC-Größen

Bei GFSK-basierten Bluetooth-PHYs hat der an verschlüsselte Pakete angehängte MIC eine feste Länge von 32 Bit (4 Oktette). Bei HDT erfordern längere Paketnutzdaten längere MICs, um die Wahrscheinlichkeit einer unentdeckten Datenverfälschung oder -manipulation zu verringern. Daher führt HDT die Unterstützung für folgende MIC-Größen ein:

• 64b (8 Oktette)
• 128b (16 Oktette)

Die MIC-Größe wird während der von der Verbindungsschicht verwalteten Verschlüsselungseinrichtungsphase festgelegt. Wenn eine der beiden Seiten 128b bevorzugt, wird 128b ausgewählt. Die neuen MIC-Größen können nur auf Pakete angewendet werden, die über die HDT-PHY übertragen werden (GFSK-basierte PHYs verwenden weiterhin einen 32b-MIC). Die ausgewählte MIC-Größe wird gemäß den NIST-Empfehlungen symmetrisch über die gesamte Verbindung hinweg durchgesetzt und an den verwendeten Sitzungsschlüssel gebunden.

Bei HDT-Paketen mit dem Paketformat 1 (PF1) werden die verschlüsselte Nutzlast und der MIC vor der Übertragung (nach der Verschlüsselung) in Blöcke unterteilt. Daher kann jeder Block beim Empfang entschlüsselt werden, die MIC-Überprüfung kann jedoch erst erfolgen, nachdem alle Blöcke erfolgreich empfangen und wieder zusammengesetzt wurden.

Unterstützung für den Verschlüsselungsschlüsselplan (EKS)

Um mit HDT zu arbeiten, müssen Geräte eine Verbindung über eine GFSK-PHY herstellen, die unterstützten HDT-Funktionen ermitteln, Konfigurationsparameter auswählen bzw. austauschen und anschließend über ein PHY-Update sowie eine Aktualisierung der Verschlüsselung auf die HDT-PHY umschalten. Aus Sicht der Verschlüsselung bedeutet dies eine Änderung der MIC-Größe von 32 Bit auf 64 Bit oder 128 Bit, was wiederum einen Wechsel des Verschlüsselungsschlüssels erfordert.

Die Funktion „Encryption Key Schedule“ (EKS) ermöglicht die Generierung, Verwaltung und Aktualisierung von Verschlüsselungsschlüsseln, um Änderungen an der PHY-Schicht (und der MIC-Größe) zu unterstützen, ohne dass die Verbindung getrennt oder der Verschlüsselungsvorgang neu gestartet werden muss. Mithilfe von aus ECDH abgeleiteten gemeinsamen Geheimnissen und AES-CMAC-basierten Schlüsselableitungsfunktionen ermöglicht EKS die Unterstützung folgender Funktionen:

• Opportunistische Verschlüsselung
• Perfect Forward Secrecy (PFS)
• Nahtlose PHY-Übergänge mit synchronisierten Schlüssel- und MIC-Aktualisierungen
• Schlüsseltrennung pro Stream für ACL- und CIS-Übertragungen

Mit der opportunistischen Verschlüsselung können Geräte eine verschlüsselte Verbindung ohne zuvor ausgetauschten Lebensdauerschlüssel (LTK) herstellen, wodurch eine verschlüsselte Kommunikation auch dann möglich ist, wenn die Geräte noch nicht gekoppelt wurden. Dies bietet ein ähnliches Maß an Vertraulichkeit und Integrität wie bei der Kopplung von Geräten über LE Secure Connections mit der „Just Works“-Methode, jedoch ohne Authentifizierung oder Schutz vor Man-in-the-Middle-Angriffen (MITM).

Bei PFS führt eine Kompromittierung des LTK, des privaten Schlüssels oder eines aktuellen Sitzungsschlüssels eines Geräts nicht zur Offenlegung früherer Sitzungsschlüssel. Daher bleiben frühere verschlüsselte Sitzungen sicher. Die Offenlegung eines Sitzungsschlüssels nach einer Verschlüsselungsaktualisierung gibt keinen Aufschluss über den vorherigen Sitzungsschlüssel vor der Verschlüsselungsaktualisierung. Aus einem einzelnen Sitzungsschlüssel lassen sich keine anderen Sitzungsschlüssel oder Verkehrsgeheimnisse ableiten. Aus einem Verkehrsgeheimnis lassen sich zwar spätere Verkehrsgeheimnisse ableiten, frühere jedoch nicht.

Die Trennung der Schlüssel pro Stream war zwar bereits zuvor möglich, erforderte jedoch eine vollständige Wiederholung des Vorgangs „Verschlüsselung mit Diversifikatoren“. EKS PFS vereinfacht diesen Vorgang erheblich. Derzeit hat eine CIS-Sitzung eine begrenzte Laufzeit, da der CIS-Sitzungsschlüssel nicht aktualisiert werden kann.

Die Unterstützung von EKS ist für Geräte, die HDT unterstützen, obligatorisch. Wenn beide Geräte einer Verbindung EKS unterstützen, ist dessen Verwendung obligatorisch. Wird EKS nicht unterstützt, bleibt die Verschlüsselung mit Diversifikatoren weiterhin in Kraft.

Neue Funktionen, Prozeduren und Parameter

Im Rahmen der EKS-Funktion werden neue kryptografische Funktionen, neue kryptografische Tag-Werte und neue Verfahren zur Ableitung von Sitzungsschlüsseln eingeführt. Zudem werden den vom AES-CCM-Algorithmus verwendeten Counter-Mode-Blöcken neue Felder und Werte hinzugefügt, um die MIC-Berechnung mit den neuen Größen zu unterstützen.

7.2 Aktualisierungen zur Schlüsselableitung

Kryptografische Toolbox

Die Schlüsselableitungshierarchie für EKS umfasst

• Ein abgeleiteter Schlüssel: Der Basisschlüssel, der aus dem gemeinsamen ECDH-Geheimnis zwischen den Geräten abgeleitet und als Teil der EKS-Schlüsselhierarchie verwendet wird
• Ein Verkehrsgeheimnis: Ein Schlüssel, der aus dem abgeleiteten Geheimnis gewonnen wird, um Sitzungsschlüssel und IVs zu generieren
• Ein Sitzungsschlüssel und ein Initialisierungsvektor (IV): Werden vom AES-CCM-Algorithmus zur Erzeugung des MIC sowie zur Verschlüsselung und Authentifizierung von Paketen verwendet

Die neuen kryptografischen Funktionen, die zur Unterstützung von EKS eingeführt wurden, basieren auf der AES-CMAC-Funktion (siehe [Band 3], Teil H, Abschnitt 2.2.5 der Bluetooth-Kernspezifikation). Sie unterstützen die gesamte Schlüsselableitungshierarchie in Verbindung mit einem LTK und einem gemeinsamen ECDH-Geheimnis. Die mit den neuen Funktionen ermöglichte CMAC-basierte Schlüsselableitungshierarchie ist in Abbildung 7.1 dargestellt.

Abbildung 7.1 – CMAC-basierte Schlüsselableitungshierarchie mit EKS

Eine Übersicht über die neuen kryptografischen Funktionen und Tags finden Sie in den Tabellen 7.1 und 7.2. Mit Tags versehene Eingaben gewährleisten eine kryptografische Trennung zwischen den Schlüsseln.

Tabelle 7.1 – Funktionen der kryptografischen Toolbox

Funktion	Beschreibung
k1	Leitet mithilfe von AES-CMAC einen neuen 128-Bit-Schlüssel aus einem vorhandenen Schlüssel und kontextspezifischen Informationen ab. Wird als Baustein für andere Ableitungen verwendet.
k2	Leitet das anfängliche „abgeleitete Geheimnis“ aus dem gemeinsamen ECDH-Geheimnis ab. Dies ist die Wurzel der Schlüsselhierarchie für eine Verbindung.
k3	Aktualisiert ein „Traffic Secret“, um die Aktualisierung von Sitzungsschlüsseln ohne erneutes Pairing zu ermöglichen
kv1	Leitet den 128-Bit-Sitzungsschlüssel aus einem „Traffic Secret“ ab. Wird für die AES-CCM-Verschlüsselung verwendet.
kv2	Leitet den 64-Bit-Initialisierungsvektor (IV) aus einem Traffic Secret ab. Wird in AES-CCM zur Erstellung von Nonces verwendet.
kv12	Keine Funktion, sondern eine Notation, die angibt, dass sowohl kv1 als auch kv2 stets gemeinsam verwendet werden, um den Session Key und den IV aus einem Traffic Secret abzuleiten
ee1	Leitet das abgeleitete Geheimnis aus einem Basisschlüssel (z. B. LTK- oder ECDH-Ausgabe) und Kontext-Tags oder aus einem zuvor abgeleiteten Geheimnis ab
ee2	Leitet das Verkehrsgeheimnis aus einem Basisschlüssel und einem Kontext ab
ee12	Keine Funktion, sondern eine Notation, die angibt, dass sowohl ee1 als auch ee2 stets gemeinsam verwendet werden, um sowohl das abgeleitete Geheimnis als auch das Verkehrsgeheimnis abzuleiten

Tabelle 7.2 – Werte der kryptografischen Tags

Bezeichner	Wert	Herleitung	Verwendung
taghs	0x6465_72697665_64206873	„abgeleitetes hs“	k2
tagda	0x646572_69766564_2041434C	„abgeleitete ACL“	Anfängliches abgeleitetes Geheimnis
tagdc	0x646572_69766564_20434953	„abgeleitetes CIS“	Später abgeleitetes Geheimnis
tagta	0x747261_66666963_2041434C	„Verkehrs-ACL“	ACL-Verkehrsgeheimnis
tagtc	0x747261_66666963_20434953	„Verkehrs-CIS“	Das Geheimnis des CIS-Verkehrs
tagtr	0x747261_66666963_20757064	„Verkehrsinfo“	k3
tagsk	0x6B6579	„Schlüssel“	kv1
tagiv	0x6976	„iv“	kv2

Kryptografische Verfahren

ACL-Verschlüsselung starten

Wenn bei einer ACL-Verbindung mit EKS die Verschlüsselung initiiert wird, müssen die Geräte zunächst öffentliche Schlüssel austauschen und mithilfe des Verfahrens „Encryption Start with Key Schedule“ ein gemeinsames ECDH-Geheimnis erstellen. Anschließend müssen sie den empfangenen öffentlichen Schlüssel validieren und mithilfe der Funktion „ee12“ Anfangswerte für das abgeleitete Geheimnis und das Verkehrsgeheimnis der ACL berechnen. Schließlich müssen die Geräte mithilfe der Funktion „kv12“ den anfänglichen Sitzungsschlüssel und den Initialvektor (IV) berechnen.

Sind die Geräte nicht gekoppelt, wird ein LTK mit dem Wert Null verwendet, wodurch eine opportunistische Verschlüsselung ermöglicht wird. Die opportunistische Verschlüsselung ermöglicht es den Geräten, von GFSK-PHYs auf den HDT-PHY umzuschalten und dabei die Verschlüsselung aufrechtzuerhalten, selbst wenn kein LTK verfügbar ist.

Geheimnisse des CIS-Verkehrs

Jedes Mal, wenn ein neuer „Connected Isochronous Stream“ (CIS) erstellt wird, generieren die Geräte mithilfe der Funktion „ee12“ unter Verwendung von CIS-spezifischen Kennungen (CIG_ID, CIS_ID) einen neuen „Derived Secret“-Wert sowie den anfänglichen „Traffic Secret“ für diesen CIS. Dies ermöglicht eine streamspezifische Schlüsseltrennung und erhöht somit die Sicherheit in Szenarien mit mehreren Streams. Anschließend müssen die Geräte mithilfe der Funktion „kv12“ den anfänglichen Sitzungsschlüssel und den IV für den CIS berechnen.

Derzeit verfügt jedes CIS während seiner gesamten Lebensdauer (2^39 Pakete) über ein einziges „Traffic Secret“, da sein Sitzungsschlüssel nicht aktualisiert werden kann.

Aktualisierung des ACL-Sitzungsschlüssels

HDT unterstützt die Aktualisierung des Sitzungsschlüssels während der Verbindung, ohne dass ein Eingreifen des Hosts erforderlich ist. Das „Traffic Secret“ wird von den Geräten mithilfe der k3-Funktion aktualisiert, woraufhin über die kv12-Funktion ein neuer Sitzungsschlüssel und ein neuer IV abgeleitet werden. Bei der Aktualisierung bleiben sowohl der Paketzähler als auch die Nummerierung der Nutzdaten erhalten, sodass die Paketsequenzierung ohne Unterbrechung der Datenübertragung fortgesetzt werden kann. Dies bedeutet, dass der Sitzungsschlüssel innerhalb von 2^39 Paketen seit der letzten Aktualisierung aktualisiert werden muss.

Integration mit PHY-Übergängen

Bei Bluetooth LE war für den Wechsel der PHY-Schicht während einer verschlüsselten Sitzung bislang in der Regel eine Unterbrechung und ein Neustart der Verschlüsselung erforderlich. HDT macht dies überflüssig, indem es EKS in die PHY-Übergänge integriert:

• Beim Wechsel von einem GFSK-PHY mit einem 32b-MIC zu einem HDT-PHY mit einem 64b- oder 128b-MIC oder umgekehrt führt die Verbindungsschicht eine koordinierte Schlüsselaktualisierung mithilfe von EKS durch
• Eine Schlüsselaktualisierung bei einer GFSK-PHY-Schicht kann auch mit dem Wechsel zu einer anderen GFSK-PHY-Schicht koordiniert werden.
• Wenn ein PHY-Wechsel eine Änderung der MIC-Größe erfordert, treten der neue Sitzungsschlüssel und die neue MIC-Größe gleichzeitig mit dem PHY-Wechsel in Kraft.
• Beim Wechsel zwischen zwei GFSK-PHYs findet kein Schlüssel-/MIC-Wechsel statt, und dieser muss auch nicht unbedingt erfolgen, solange die Verbindung auf dem HDT-PHY besteht.
• Diese Koordination gewährleistet eine durchgehende Verschlüsselung, ohne dass ungeschützte Daten offengelegt werden oder eine erneute Authentifizierung des Hosts erforderlich ist.

Diese Integration vereinfacht den PHY-Wechsel und erhöht die Sicherheit, indem sie sicherstellt, dass Änderungen der MIC-Größe stets mit einem Schlüsselwechsel einhergehen, wie vom NIST vorgeschrieben.

Ein Hinweis: Wenn die Signale „LL_PHY_REQ/RSP“ und „LL_PHY_UPDATE_IND“ über den HDT-PHY gesendet werden, müssen die ACL-Nutzdaten (nicht jedoch die Daten der Steuerungsebene) für einen Teil des Vorgangs unterbrochen werden.

7.3 Aktualisierungen der Verschlüsselung

CCM-Algorithmus

Für die Verschlüsselung und Authentifizierung erfordert der CCM-Algorithmus, dass die Nutzdaten und zusätzliche Parameter in den CCM-Nonce, die Blöcke im Zählermodus und die Verschlüsselungsblöcke formatiert werden. Der CCM-Nonce gewährleistet die Eindeutigkeit jedes Pakets, die Blöcke im Zählermodus dienen zur Berechnung des MIC, und die Verschlüsselungsblöcke liefern den Schlüsselstrom, der zur Verschlüsselung der Nutzdaten und des MIC verwendet wird.

Die Unterstützung von EKS und variablen MIC-Längen führt zu Aktualisierungen des Formats und der Felder der Counter-Mode-Blöcke, die sich auf Unterschiede zwischen dem GFSK-PHY- und dem HDT-PHY-basierten Betrieb beziehen und der durch Verfahren der Verbindungsschicht festgelegten MIC-Größe (32b, 64b oder 128b) Rechnung tragen.

8. Bluetooth® HDT Host Controller Interface (HCI)

Bluetooth® HDT führt neue Befehle und Ereignisse ein und aktualisiert bestehende, um die Funktionen der Host Controller Interface (HCI) zu erweitern und einen höheren Durchsatz, eine verbesserte Leistung und Robustheit sowie erhöhte Sicherheit zu gewährleisten.

Dieser Abschnitt enthält eine Übersicht über die neuen, höherversionenierten und aktualisierten HCI-Befehle und -Ereignisse für die HDT-Aktivierung. Außerdem enthält er Nachrichtenablaufdiagramme, die typische Interaktionen wichtiger HCI-Befehle und -Ereignisse für die HDT-Unterstützung mit der Bluetooth-LE-Verbindungsschicht veranschaulichen.

8.1 Übersicht über neue oder aktualisierte HCI-Befehle und -Ereignisse

Die Tabellen 8.1, 8.2 und 8.3 bieten jeweils einen Überblick über neue, hochversionsierte und aktualisierte HCI-Befehle und -Ereignisse für die HDT-Unterstützung. Zur Verdeutlichung: Bei hochgestuften Befehlen und Ereignissen werden neue Befehls- oder Rückgabeparameter für die HDT-Unterstützung eingeführt, während bei aktualisierten Befehlen und Ereignissen lediglich neue Werte für die HDT-Aktivierung und -Unterstützung zu bereits vorhandenen Befehls- oder Rückgabeparametern hinzugefügt werden. Weitere Einzelheiten, einschließlich der Unterstützungsanforderungen für jeden Befehl oder jedes Ereignis, finden Sie in [Band 4], Teil E, Abschnitt 3 der Bluetooth-Kernspezifikation.

Tabelle 8.1 – Neue HCI-Befehle und -Ereignisse für die HDT-Unterstützung

Befehl / Ereignis	Beschreibung
Befehl „LE Read Encryption Key Schedule Debug Mode“	Wird verwendet, um den Debug-Modus bei Verwendung der EKS-basierten Verschlüsselung auszulesen
Befehl „LE Set HDT Default Parameters“	Wird von einem Host verwendet, um die Standard-HDT-Parameter für den lokalen Controller festzulegen
LE-Befehl „HDT-Parameter testen“	Wird von einem Host verwendet, um die HDT-Testparameter für die Verbindung festzulegen
LE-Testbericht: Veranstaltung zur HDT-Verbindungsqualität	Gibt Informationen zur Verbindungsqualität der empfangenen HDT-PHY-Testpakete aus
Befehl „LE Write Encryption Key Schedule Debug Mode“	Wird von einem Host verwendet, um den Debug-Modus während der EKS-basierten Verschlüsselung einzustellen

Tabelle 8.2 – Aktualisierte HCI-Befehle und -Ereignisse für die HDT-Unterstützung

Befehl / Ereignis	Beschreibung
Ereignis „Verschlüsselungsänderung“ [v3]	Zeigt an, dass die Änderung der Verschlüsselung für das angegebene Connection_Handle abgeschlossen ist
Ereignis „Aktualisierung des Verschlüsselungsschlüssels abgeschlossen“ [v2]	Teilt dem Host mit, dass der Verschlüsselungsschlüssel für das angegebene Connection_Handle aktualisiert wurde, sobald die Verschlüsselung unterbrochen und anschließend wieder aufgenommen wurde.
LE CIS – Etablierte Veranstaltung [v3]	Zeigt an, dass der Controller ein CIS eingerichtet hat
LE-Befehl „Create BIG“ [v2]	Erstellt ein oder mehrere BISes eines BIG
LE Create BIG – Komplette Veranstaltung [v2]	Zeigt an, dass der Controller einen Versuch abgeschlossen hat, die vom Host angeforderten BISes zu erstellen
LE-Befehl „Create BIG Test“ [v2]	Wird verwendet, um zu Testzwecken ein oder mehrere BIS eines BIG zu erstellen
Ereignis „Änderung der LE-Datenlänge“ [v2]	Wird verwendet, um eine Änderung der maximalen Paketgrößen durch die Verbindungsschicht anzuzeigen
LE-Befehl „Verschlüsselung aktivieren“ [v2]	Wird verwendet, um eine Verschlüsselung auf Verbindungsebene zu aktivieren
LE-Befehl „Maximale Datenlänge lesen“ [v2]	Ermöglicht es dem Host, die vom Controller unterstützten Parameter „MaxTxOctets“, „MaxTxTime“, „MaxRxOctets“ und „MaxRxTime“ auszulesen
LE-Befehl „Vorgeschlagene Standarddatenlänge lesen“ [v2]	Ermöglicht es dem Host, die anfänglichen Werte für „MaxTxOctets“ und „MaxTxTime“ für HDT-PHY oder neue Verbindungen über ein GFSK-PHY auszulesen, die dem Controller vorgeschlagen wurden
LE-Empfänger-Testbefehl [v4]	Führt den LE-Empfängertest durch
Befehl „LE CIG-Parameter festlegen“ [v2]	Wird von einem Central-Host verwendet, um Parameter für ein oder mehrere CIS festzulegen, die im Controller einer CIG zugeordnet sind
LE-Befehl „CIG-Parameter testen“ [v2]	Nur zu Testzwecken. Wird von einem Central-Host verwendet, um Parameter für ein oder mehrere CIS festzulegen, die im Controller einer CIG zugeordnet sind.
Befehl „LE Set Data Length“ [v2]	Wird verwendet, um dem Controller maximale Paketgrößen vorzuschlagen
Befehl „LE Test End“ [v2]	Beendet den aktuellen Empfänger- oder Sendertest
LE-Sender-Testbefehl [v5]	Führt den LE-Sender-Test durch
LE-Befehl „Vorgeschlagene Standarddatenlänge schreiben“ [v2]	Ermöglicht es dem Host, Anfangswerte für „MaxTxOctets“ und „MaxTxTime“ für die HDT-PHY oder neue Verbindungen über eine GFSK-PHY vorzuschlagen
Befehl „Verschlüsselungsschlüssel aktualisieren“ [v2]	Wird vom Host verwendet, um den Controller dazu zu veranlassen, den Verschlüsselungsschlüssel zu aktualisieren, indem die Verschlüsselung unterbrochen und anschließend fortgesetzt wird.

Tabelle 8.3 – Aktualisierte HCI-Befehle und -Ereignisse für die HDT-Unterstützung

Befehl / Ereignis	Beschreibung
LE BIG Sync – Etablierte Veranstaltung	Zeigt an, dass der Controller einen Synchronisierungsversuch mit den angeforderten BIS-Systemen abgeschlossen hat
Veranstaltung „LE BIGInfo Advertising Report“	Zeigt an, dass der Controller eine Advertising-PDU empfangen hat, die ein BIGInfo-Feld enthielt
Befehl „LE CS Set Procedure Parameters“	Wird vom Host verwendet, um Parameter für die Planung einer oder mehrerer CS-Prozeduren durch den lokalen Controller festzulegen
LE-Befehl zur Erhöhung der Sendeleistung beim Lesen	Dient zum Auslesen der aktuellen und maximalen Sendeleistung des lokalen Controllers über die ACL-Verbindung
Ereignis „LE Frame Space Update abgeschlossen“	Dient dazu, den Host über Änderungen an den Werten des Frame-Speicherplatzes zu informieren
Veranstaltung „LE PHY Update Complete“	Dient dazu, den Host über den aktuellen PHY in jeder Richtung zu informieren
LE PHY-Befehl lesen	Dient zum Auslesen des aktuellen PHY-Werts in jeder Richtung
LE-Befehl zum Auslesen der Sendeleistung	Dient zum Auslesen der Sendeleistung, die von der Fernbedienung über die ACL-Verbindung verwendet wird
LE-Befehl „Standard-PHY festlegen“	Dient zur Konfiguration der bevorzugten PHYs für neue Verbindungen des lokalen Geräts
Befehl „LE Set Event Mask“	Dient zur Steuerung, welche Ereignisse von der HCI für den Host generiert werden
LE-Set-PHY-Befehl	Wird verwendet, um eine Änderung des PHY für ein Connection_Handle anzufordern
Ereignis „LE-Sendeleistungsmeldung“	Dient zur Anzeige der Sendeleistung auf der ACL-Verbindung
Befehl „Ereignismaske festlegen – Seite 2“	Dient zur Steuerung, welche Ereignisse von der HCI für den Host generiert werden

8.2 Neue HCI-Befehle und -Ereignisse

Befehl „LE Read Encryption Key Schedule Debug Mode“

Aktiviert den Debug-Modus bei Verwendung der verschlüsselungsschlüsselbasierten Verschlüsselung. Der Befehl gilt für alle nachfolgenden Verbindungen und hat keine Auswirkungen auf bereits bestehende Verbindungen.

Befehl „LE Set HDT Default Parameters“

Ermöglicht es einem zentralen oder peripheren Host, seine Standardparameter für den HDT-PHY festzulegen, die für alle nachfolgenden Verbindungen verwendet werden sollen. Bestehende Verbindungen sind davon nicht betroffen.

• Preferred_MIC_Length – Gibt die bevorzugte MIC-Länge an, die bei allen verschlüsselten Verbindungen auf dem LE HDT PHY verwendet werden soll
• Preferred_Packet_Format – Gibt das bevorzugte HDT-Paketformat an, das für die Datenübertragung auf der LE-HDT-PHY verwendet werden soll
• Preferred_ACL_Rates – Gibt die bevorzugten Übertragungsraten an, die über eine ACL-Verbindung auf dem LE-HDT-PHY verwendet werden sollen

LE-Befehl „HDT-Parameter testen“

Nur zu Testzwecken. Wird vom zentralen oder peripheren Host verwendet, um bei Verwendung des HDT-PHY Testparameter für die durch das Connection_Handle angegebene ACL- oder CIS-Verbindung festzulegen. Der Host kann die unterstützten HDT-Nutzdaten und Paketfunktionen für den lokalen Controller mithilfe von HCI_LE_Read_Maximum_Data_Length auslesen.

• MIC_Length – Gibt die Länge des MIC an, der für die Verschlüsselung der durch das Handle angegebenen ACL-Verbindung verwendet werden soll
• Packet_Format – Gibt das Format an, das für alle übertragenen Pakete mit einer PDU-Header-Zone verwendet werden soll
• Blocks_Per_Payload – Gibt die Anzahl der Blöcke pro Nutzlast an, die bei Verwendung von PF1 für die Verbindung verwendet werden sollen
• TX_Rate – Gibt die HDT-Rate an, die bei der Übertragung über die ACL-Verbindung verwendet werden soll (wird bei CIS ignoriert)

LE-Testbericht: Veranstaltung zur HDT-Verbindungsqualität

Wird generiert, wenn der lokale Controller Ergebnisse zur Verbindungsqualität aus empfangenen LE-HDT-PHY-Testpaketen zu melden hat.

• Subevent_Code – Code für Teilveranstaltung der Veranstaltung
• Channel_Index – HF-Kanal, auf dem Testpakete empfangen werden
• Report_Status – Gibt an, ob der Controller noch weitere Berichte zu versenden hat oder nicht
• Report_Count – Gibt die Anzahl der pro Paket gemeldeten RSSI[i]- und SNR[i]-Parameterwerte an
• RSSI[i] – RSSI-Wert, der einem einzelnen Testpaket in der Reihenfolge seines Empfangs zugeordnet ist
• SNR[i] – SNR-Wert, der einem einzelnen Testpaket in der Reihenfolge seines Empfangs zugeordnet ist

Befehl „LE Write Encryption Key Schedule Debug Mode“

Dient dazu, den Controller so zu konfigurieren, dass er ein vordefiniertes ECDH-Schlüsselpaar für die Verschlüsselung auf Basis des „Encryption Key Schedule“ verwendet, damit Debug-Geräte die verschlüsselte Verbindung überwachen können. Der Befehl gilt für alle nachfolgenden Verbindungen und hat keine Auswirkungen auf bereits bestehende Verbindungen.

8.3 Aktualisierte HCI-Befehle und -Ereignisse

Ereignis „Verschlüsselungsänderung“ [v3]

Dient zur Anzeige, dass eine Änderung des Verschlüsselungsmodus abgeschlossen ist. Mit [v3] werden neue Ereignisparameter eingeführt, um die MIC-Länge für die Verbindung anzugeben, falls eine EKS-basierte Verschlüsselung verwendet wird, sowie um anzugeben, ob bei der Prozedur „Verschlüsselungsstart mit Schlüsselplan LL“ ein Debug-Schlüsselpaar verwendet wird.

Ereignis „Aktualisierung des Verschlüsselungsschlüssels abgeschlossen“ [v2]

Dient dazu, dem Host mitzuteilen, dass der Verschlüsselungsschlüssel für das angegebene `Connection_Handle` aktualisiert wurde. [v2] führt die Ereignisparameter `MIC_Length`, `Key_Schedule_Enabled` und `Key_Schedule_Debug_Flag` ein, die denselben Zweck erfüllen wie das Ereignis „Encryption Change“ [v3]. Wird das Ereignis durch einen LE-PHY-Aktualisierungsvorgang ausgelöst, wird es unmittelbar nach dem Ereignis `HCI_LE_PHY_Update_Complete` gesendet.

LE CIS – Etablierte Veranstaltung [v3]

Teilt dem Host mit, dass eine CIS erfolgreich hergestellt wurde oder fehlgeschlagen ist (z. B. abgelehnt oder vor der Herstellung unterbrochen). [v3] führt die folgenden Ereignisparameter ein, fügt neue Werte für PHY-Ereignisparameter hinzu, um die HDT-Nutzung anzugeben, und erhöht die Obergrenze für Max_Payload-Ereignisparameter auf 8175 Oktette.

• Rates_C_To_P – Gibt die Verwendung bestimmter LE-codierter oder HDT-Datenraten in Richtung „Zentrale zu Peripherie“ an
• Rates_P_To_C – Gibt die Verwendung bestimmter LE-codierter oder HDT-Datenraten in Richtung vom Peripheriegerät zur Zentrale an
• Config_ID – CIG-Konfigurationskennung
• TL_Group_ID – Kennung der Transport-Latenzgruppe, die mit der Config_ID verknüpft ist
• Encryption_Enabled – Gibt an, ob die Verschlüsselung auf dem CIS aktiviert ist, sowie den Typ (z. B. EKS, opportunistisch)
• MIC_Length – Gibt die Länge des für die Verschlüsselung zu verwendenden MIC an

LE-Befehl „Create BIG“ [v2]

Wird verwendet, um ein BIG aus einem oder mehreren BIS zu erstellen. Alle BIS in einem BIG haben für alle Parameter denselben Wert. Mit [v2] werden die folgenden Befehlsparameter sowie eine neue Bitnummer für den PHY-Parameter eingeführt, um die Übertragung von Paketen mit dem HDT-PHY anzugeben.

• Coded_Rates – Gibt die bevorzugte Übertragungsrate an, die gegenüber dem LE Coded PHY verwendet werden soll
• HDT_Rates – Gibt die bevorzugte(n) Übertragungsrate(n) an, die über die HDT-PHY-Schicht verwendet werden sollen
• HDT_MIC_Length – Gibt die Länge des MIC an, der für die Verschlüsselung über HDT verwendet werden soll
• HDT_Packet_Format – Gibt das bevorzugte HDT-Paketformat für die Datenübertragung an, wenn BIS auf HDT-PHY läuft

LE Create BIG – Komplette Veranstaltung [v2]

Zeigt an, dass der Befehl „HCI_LE_Create_BIG“ oder „HCI_LE_Create_BIG_Test“ abgeschlossen wurde und – bei erfolgreichem Abschluss – dass die Verbindungsschicht in den Zustand „Isochronous Broadcasting“ übergegangen ist. Mit [v2] werden die folgenden Ereignisparameter eingeführt, ein neuer Wert für den PHY-Ereignisparameter zur Angabe der HDT-Nutzung hinzugefügt und die Obergrenze für die Größe von „Max_Payload“ auf 8175 Oktette erhöht.

• Tarife – Gibt die Kodierung(en) oder Tarife an, die für „LE Coded“ oder „HDT PHY“ verwendet werden
• Encryption_Enabled – Gibt an, ob die Verschlüsselung auf dem BIG aktiviert ist oder nicht
• MIC_Length – Gibt die Länge des für die Verschlüsselung zu verwendenden MIC an

LE-Befehl „Create BIG Test“ [v2]

Nur zu Testzwecken. Dient zur Erstellung eines BIG mit einem oder mehreren BIS. Alle BIS in einem BIG weisen für alle Parameter denselben Wert auf. Mit [v2] werden die folgenden Befehlsparameter eingeführt, eine neue Bitnummer für den PHY-Parameter hinzugefügt, um die Übertragung von Paketen mit dem HDT-PHY anzuzeigen, und die Obergrenze für die Größe von „Max_Payload“ auf 8175 Oktette angehoben.

• Coded_Rates – Gibt die bevorzugte Übertragungsrate an, die gegenüber dem LE Coded PHY verwendet werden soll
• HDT_Rates – Gibt die bevorzugten Übertragungsraten an, die gegenüber dem HDT-PHY verwendet werden sollen
• HDT_MIC_Length – Gibt die Länge des MIC an, der für die Verschlüsselung über HDT verwendet werden soll
• HDT_Packet_Format – Gibt das bevorzugte Paketformat für die Datenübertragung an, wenn BIS auf HDT-PHY aktiviert ist
• HDT_Blocks_Per_Payload – Gibt die Anzahl der Blöcke pro Nutzlast an, die bei der Verbindung mit PF1 verwendet werden sollen

Ereignis „Änderung der LE-Datenlänge“ [v2]

Benachrichtigt den Host über eine Änderung entweder der maximalen Nutzdatenlänge von Daten-PDUs auf der Link-Schicht oder der maximalen Übertragungszeit von Paketen, die LL-Daten-PDUs in beide Richtungen enthalten. Mit [v2] wird der PHYS-Ereignisparameter eingeführt, um anzugeben, für welche PHYs die Ereignisparameter gelten. Außerdem wird die Obergrenze für die Größen von Max_TX_Octets und Max_RX_Octets auf 8175 Oktette erhöht.

LE-Befehl „Verschlüsselung aktivieren“ [v2]

Dient zur Authentifizierung des angegebenen, dem Remote-Gerät zugeordneten Verschlüsselungsschlüssels und zur Verschlüsselung der Verbindung nach der Authentifizierung. Mit [v2] werden die Befehlsparameter „HDT_MIC_Length“ und „Encryption_Type“ eingeführt, um die bevorzugte MIC-Länge für die Verschlüsselung sowie den Verschlüsselungstyp (EKS oder opportunistische Verschlüsselung) für eine ACL-Verbindung über HDT-PHY anzugeben.

LE-Befehl „Maximale Datenlänge lesen“ [v2]

Ermöglicht es dem Host, die maximal unterstützte Nutzlastgröße und die Paketdauer des Controllers für die Übertragung und den Empfang von LL-Daten-PDUs abzurufen. Mit [v2] wird der PHY-Befehlsparameter eingeführt, um anzugeben, für welchen PHY die Parameter ausgelesen werden, sowie die unten aufgeführten Rückgabeparameter für die Unterstützung der HDT-Funktion. Außerdem wird die Obergrenze für den Wertebereich von „Supported_Max_TX/RX_Octets“ auf 8175 Oktette erhöht.

• Supported_Max_TX_Payload_Window_Size – Vom Controller unterstützte maximale Größe des Sende-Nutzdatenfensters
• Supported_Max_RX_Payload_Window_Size – Vom Controller unterstützte maximale Größe des Empfangs-Nutzdatenfensters
• Supported_Max_RX_Octets_Per_Packet – Maximale Gesamtanzahl an Nutzdaten-Oktetten, die in einem einzelnen Paket empfangen werden können

LE-Befehl „Vorgeschlagene Standarddatenlänge lesen“ [v2]

Ermöglicht es dem Host, die für den Controller festgelegten empfohlenen Standardwerte für die Übertragungsparameter der LL-Daten-PDU auszulesen (Suggested_Max_TX_Octets, Suggested_Max_TX_Time). [v2] führt den Befehlsparameter „PHYS“ ein, um anzugeben, für welchen PHY die Übertragungsparameter gelesen werden (GFSK oder HDT), und erhöht zudem die Obergrenze für den zurückgegebenen Wertebereich von „Suggested_Max_TX_Octets“ auf 8175 Oktette.

LE-Empfänger-Testbefehl [v4]

Wird verwendet, um einen Test zu starten, bei dem das IUT in festen Intervallen Testreferenzpakete empfängt. Mit [v4] wird der Befehlsparameter „HDT_SNR_Test“ eingeführt, um anzugeben, ob die SNR-Messung für die HDT-PHY durchgeführt werden soll. Außerdem wird ein neuer Wert für „PHY“ hinzugefügt, um die Verwendung der HDT-PHY anzuzeigen.

Befehl „LE CIG-Parameter festlegen“ [v2]

Wird von einem Central-Host verwendet, um eine CIG zu erstellen und die Parameter eines oder mehrerer CISes festzulegen, die im Controller mit einer CIG verknüpft sind. [v2] führt die folgenden Befehlsparameter für die HDT-PHY-Unterstützung sowie neue Bitnummern für PHY_C_To_P[i] und PHY_P_To_C[i] ein, um die Verwendung von HDT-PHY anzuzeigen.

• Coded_Rates_C_To_P[i] – Gibt die bevorzugte Übertragungsrate an, die gegenüber dem LE Coded PHY von der Zentrale zur Peripherie verwendet werden soll
• Coded_Rates_P_To_C[i] – Gibt die bevorzugte Übertragungsrate an, die gegenüber dem LE Coded PHY vom Peripheriegerät zur Zentrale verwendet werden soll
• HDT_Rates_C_To_P[i] – Gibt die bevorzugten Übertragungsraten an, die über die HDT-PHY-Schicht von der Zentrale zur Peripherie verwendet werden sollen
• HDT_Rates_P_To_C[i] – Gibt die bevorzugten Übertragungsraten an, die über die HDT-PHY-Schicht von der Peripherie zur Zentrale verwendet werden sollen
• HDT_MIC_Length[i] – Gibt die MIC-Länge für die Verschlüsselung an
• HDT_Packet_Format[i] – Gibt das bevorzugte HDT-Paketformat an, das der Controller verwenden soll

LE-Befehl „CIG-Parameter testen“ [v2]

Nur zu Testzwecken. Wird vom Host einer Zentrale verwendet, um eine CIG zu erstellen und die Parameter einer oder mehrerer CISes festzulegen, die im Controller mit einer CIG verknüpft sind. [v2] führt die folgenden Befehlsparameter für die HDT-PHY-Unterstützung ein, erhöht die Obergrenze für die Befehlsparameter „Max Payload“ auf 8175 Oktette und definiert neue Bitnummern für PHY_C_To_P[i] und PHY_P_To_C[i], um die Verwendung von HDT-PHY anzuzeigen.

• Coded_Rates_C_To_P[i] – Gibt die bevorzugte Übertragungsrate an, die über die LE Coded PHY von der Zentrale zur Peripherie verwendet werden soll
• Coded_Rates_P_To_C[i] – Gibt die bevorzugte Übertragungsrate an, die über die LE Coded PHY von der Peripherie zur Zentrale verwendet werden soll
• HDT_Rates_C_To_P[i] – Gibt die bevorzugten Übertragungsraten an, die über die HDT-PHY-Schicht von der Zentrale zur Peripherie verwendet werden sollen
• HDT_Rates_P_To_C[i] – Gibt die bevorzugten Übertragungsraten an, die über die HDT-PHY-Schicht von der Peripherie zur Zentrale verwendet werden sollen
• HDT_MIC_Length[i] – Gibt die Länge des MIC an, der für die Verschlüsselung über HDT verwendet werden soll
• HDT_Packet_Format[i] – Gibt das bevorzugte HDT-Paketformat an, das der Controller verwenden soll
• HDT_Payload_Window_Size_C_To_P[i] – Gibt die Größe des von der Zentrale zur Peripherie verwendeten Nutzdatenfensters an
• HDT_Payload_Window_Size_P_To_C[i] – Gibt die Größe des vom Peripheriegerät an die Zentrale verwendeten Nutzdatenfensters an

Befehl „LE Set Data Length“ [v2]

Ermöglicht es dem Host, die maximale Größe der Übertragungsnutzlast und die Zeit vorzuschlagen, die für LL-Daten-PDUs auf einer bestimmten Verbindung verwendet werden sollen. [v2] führt den Befehlsparameter PHYS ein, um anzugeben, für welche PHYs die Parameter gelten (GFSK oder HDT), und erhöht die Obergrenze des Wertebereichs für TX_Octets auf 8175 Oktette.

Befehl „LE Test End“ [v2]

Dient dazu, einen laufenden Test abzubrechen. Mit [v2] wird der Rückgabeparameter „Num_Blocks“ eingeführt, der die Anzahl der am HDT-PHY empfangenen Blöcke angibt.

LE-Sender-Testbefehl [v5]

Wird verwendet, um einen Test zu starten, bei dem das IUT in festen Intervallen Testreferenzpakete generiert. Mit [v5] werden die folgenden Befehlsparameter für HDT-Übertragungstests eingeführt und ein neuer Wert für „PHY“ hinzugefügt, um die Verwendung von HDT-PHY anzuzeigen.

• HDT_Rate_Indicator – Gibt die HDT-PHY-Übertragungsrate an
• HDT_Packet_Format_Indicator – Gibt das HDT-Paketformat an
• HDT_Payload_Length – Gibt die Länge der Nutzdaten im Paketformat 0 an (wird in PF1 ignoriert)
• HDT_PHY_Interval – Gibt die Anzahl der Nutzlastsymbole pro PHY-Intervall an
• HDT_Num_Blocks[i] – Gibt die Anzahl der Blöcke (Nb) in der Nutzlast an (Nb = 0 für PF0)
• HDT_Block_Size[i] – Gibt die Länge jedes Blocks in der Nutzlast an, mit Ausnahme des letzten Blocks
• HDT_Final_Block_Size[i] – Gibt die Länge des zuletzt zu übertragenden Blocks an

LE-Befehl „Vorgeschlagene Standarddatenlänge schreiben“ [v2]

Ermöglicht es dem Host, die empfohlenen Standardwerte für die Übertragungsparameter der LL-Daten-PDU für den Controller festzulegen bzw. zu schreiben (Suggested_Max_TX_Octets, Suggested_Max_TX_Time). [v2] führt den Befehlsparameter PHYS ein, um anzugeben, für welchen PHY die Übertragungsparameter festgelegt werden (GFSK oder HDT), und erhöht die Obergrenze für den Wertebereich von Suggested_Max_TX_Octets auf 8175 Oktette.

Befehl „Verschlüsselungsschlüssel aktualisieren“ [v2]

Wird vom Host verwendet, um den Controller dazu zu veranlassen, den Verschlüsselungsschlüssel für die durch das Connection_Handle identifizierte ACL-Verbindung mithilfe der Prozedur „Encryption Refresh“ zu aktualisieren. Die MIC-Länge wird angegeben, wenn für die Verbindung der HDT-PHY verwendet wird.

8.4 Aktualisierte HCI-Befehle und -Ereignisse

LE BIG Sync – Etablierte Veranstaltung

Die Obergrenze für den Wertebereich des Ereignisparameters „Max_Payload“ wurde auf 8175 Oktette erhöht.

Veranstaltung „LE BIGInfo Advertising Report“

Die Obergrenze für den Wertebereich des Ereignisparameters „Max_Payload“ wurde auf 8175 Oktette erhöht. Zudem wurde ein neuer PHY-Ereignisparameter definiert, der anzeigt, dass BIG über den HDT-PHY übertragen wird.

Befehl „LE CS Set Procedure Parameters“

Es wurde ein neuer PHY-Befehlsparameterwert definiert, um die Nutzung des HDT-PHY anzuzeigen.

LE-Befehl zur Erhöhung der Sendeleistung beim Lesen

Es wurden neue Werte für die PHY-Befehls- und Rückgabeparameter definiert, um die HDT-PHY-Zuordnung festzulegen.

Ereignis „LE Frame Space Update abgeschlossen“

Es wurde eine neue Bitnummer für den PHYS-Ereignisparameter definiert, um die Nutzung des HDT-PHY anzuzeigen.

Veranstaltung „LE PHY Update Complete“

Es wurden neue Werte für die Ereignisparameter „TX_PHY“ und „RX_PHY“ definiert, um die Verwendung von HDT-PHY für das Senden und Empfangen anzuzeigen.

LE PHY-Befehl lesen

Neue Werte für die Rückgabeparameter „TX_PHY“ und „RX_PHY“, die definiert wurden, um die Nutzung von HDT-PHY anzuzeigen.

LE-Befehl zum Auslesen der Sendeleistung

Es wurde ein neuer Wert für den PHY-Befehlsparameter definiert, um die HDT-PHY-Zuordnung festzulegen.

LE-Befehl „Standard-PHY festlegen“

Es wurden neue Werte für die Befehlsparameter TX_PHY und RX_PHY definiert, um die Nutzung von HDT-PHY anzuzeigen.

Befehl „LE Set Event Mask“

Der Maske wurden vier Ereignisse hinzugefügt: LE CIS Established [v3], LE Create BIG Complete [v2], LE Data Length Change [v2] und LE Test Report HDT Link Quality.

LE-Set-PHY-Befehl

Es wurden neue Bitnummern für die Befehlsparameter „TX_PHYs“, „RX_PHYs“ und „PHY_Options“ definiert, um die Verwendung und die Einstellungen des HDT-PHY anzugeben.

Ereignis „LE-Sendeleistungsmeldung“

Es wurde ein neuer PHY-Ereignisparameterwert definiert, um die Nutzung des HDT-PHY anzuzeigen.

Befehl „Ereignismaske festlegen – Seite 2“

Der Maske wurden drei Ereignisse hinzugefügt: „Änderung der Verschlüsselung“ [v3], „Aktualisierung des Verschlüsselungsschlüssels abgeschlossen“ [v2] und „Debug-Bericht zum Verschlüsselungsschlüssel“.

8.5 Ablaufdiagramme

Die folgenden Diagramme veranschaulichen typische Interaktionen zwischen relevanten HCI-Befehlen und -Ereignissen für die HDT-Unterstützung mit der Bluetooth-LE-Verbindungsschicht.

Wechsel von GFSK-PHY zu HDT-PHY

Unverschlüsselte ACL-Verbindung

Abbildung 8.1 – Umschalten auf HDT-PHY bei einer unverschlüsselten ACL-Verbindung

Verschlüsselte ACL-Verbindung

Abbildung 8.2 – Umstellung auf HDT-PHY bei einer verschlüsselten ACL-Verbindung

Von HDT-PHY auf GFSK-PHY umstellen

Unverschlüsselte ACL-Verbindung

Abbildung 8.3 – Umschaltung von HDT-PHY auf GFSK-PHY bei einer unverschlüsselten ACL-Verbindung

Verschlüsselte ACL-Verbindung

Abbildung 8.4 – Umschaltung von HDT-PHY auf GFSK-PHY bei einer verschlüsselten ACL-Verbindung

Aktualisierung der Datenlänge

Abbildung 8.5 – Aktualisierung der Datenlänge

[v2] oder höher des Befehls „HCI_LE_Set_Data_Length“, des Ereignisses „HCI_LE_Data_Length_Change“, der PDU „LL_LENGTH_REQ“ und der PDU „LL_LENGTH_RSP“ werden verwendet, um die Parameter für den HDT-PHY zu ändern.

CIG-Einrichtung über HDT

Abbildung 8.6 – CIG- und CIS-Konfiguration über HDT-PHY

Verschlüsselung mit Schlüsselplan starten

Abbildung 8.7 – Verschlüsselung mit Schlüsselplan starten

Opportunistische Verschlüsselung mit Schlüsselplan starten

Abbildung 8.8 – Opportunistische Verschlüsselung starten

Verschlüsselung mit Schlüsselplan neu starten

Abbildung 8.9 – Verschlüsselung mit Schlüsselplan neu starten

Verschlüsselung mit Schlüsselplan aktualisieren

Abbildung 8.10 – Aktualisierung der Verschlüsselung mit Schlüsselplan

9. Sonstiges

Bluetooth® HDT führt Aktualisierungen der Host- und ISOAL-Schichten des Bluetooth-LE-Stacks ein. Die Aktualisierungen der Host-Schicht dienen in erster Linie der Überprüfung und Durchsetzung der Anforderungen an die MIC-Länge, während die Aktualisierungen der ISOAL-Schicht die Übertragung größerer Datenmengen ermöglichen, die durch die neue HDT-PHY-Schicht unterstützt werden.

9.1. Protokoll zur Steuerung und Anpassung logischer Verbindungen (L2CAP)

HDT macht die MIC-Länge zu einem zusätzlichen Sicherheitskriterium für die Erstellung von L2CAP-Datenkanälen mit Credit Based Flow Control (CBFC).

CBFC ist ein Mechanismus, bei dem vom Empfänger gewährte Credits zur Regulierung der Datenübertragung zwischen Geräten und zur Verwaltung verbindungsorientierter L2CAP-Kanäle verwendet werden. Es gibt zwei CBFC-Modi: LE und Enhanced. Grob gesagt richtet LE-CBFC einen einzelnen L2CAP-Kanal pro Verbindung ein, während Enhanced-CBFC mehrere Kanäle gleichzeitig einrichten kann. Beide Modi werden durch L2CAP-Prozeduren aktiviert, die den Austausch einer kreditbasierten Verbindungsanfrage und einer entsprechenden Antwort beinhalten.

HDT erweitert die Sicherheitsüberprüfung, die beim Aufbau von kreditbasierten L2CAP-Kanälen durchgeführt wird, und ermöglicht es Geräten, zusätzlich zu den herkömmlichen Überprüfungen hinsichtlich Authentifizierung, Autorisierung und Verschlüsselungsschlüssellänge auch die Anforderungen an die MIC-Länge zu überprüfen und durchzusetzen. Es führt Werte für das Datenfeld „Result“ in Antwortpaketen ein, um anzuzeigen, dass eine Verbindungsanfrage abgelehnt wird, weil die ausgehandelte MIC-Länge unzureichend ist.

9.2. Generisches Zugriffsprofil (GAP)

HDT nimmt geringfügige Änderungen an der Spezifikation des LE-Sicherheitsmodus 1 sowie an den Verfahren zur Dienstautorisierung vor und verbessert damit die Art und Weise, wie Bluetooth-LE-Geräte die Sicherheitsanforderungen für den Zugriff auf Dienste über das Generic Access Profile (GAP) bewerten und erfüllen.

In GAP legen Sicherheitsmodi die Anforderungen fest, die eine Bluetooth-LE-Verbindung erfüllen muss, damit ein Gerät sicher auf Dienste und Attribute zugreifen kann. Der LE-Sicherheitsmodus 1 regelt die Sicherheit für LE-ACL-Verbindungen anhand von vier Sicherheitsstufen, wobei unterschiedliche Kombinationen aus Authentifizierung und Verschlüsselung zum Einsatz kommen.

HDT erweitert den LE-Sicherheitsmodus 1, indem es für verschlüsselte Verbindungen, die über die HDT-PHY-Schnittstelle laufen, die Verwendung eines Langzeitschlüssels (LTK) mit einer Stärke von 128 Bit (äquivalent) vorschreibt. Geräten ist es untersagt, eine Verbindung auf die HDT-PHY-Schnittstelle umzustellen oder eine CIS herzustellen, die die HDT-PHY-Schnittstelle nutzt, wenn der zugehörige LTK die erforderliche Stärke von 128 Bit nicht erfüllt.

HDT aktualisiert außerdem die GAP-Verfahren, die zur Bearbeitung und Einleitung von Dienstanfragen verwendet werden. Wenn ein Dienst ein Sicherheitsniveau erfordert, das von der aktuellen Verbindung nicht erfüllt wird, kann GAP nun eine Dienstanfrage prüfen und sie mit dem Fehlercode „MIC Length Too Short“ ablehnen, falls die ausgehandelte MIC-Länge nicht den Anforderungen des Dienstes entspricht.

Wenn ein Gerät eine Dienstanforderung initiiert und die MIC-Länge nicht ausreicht, kann GAP eine PHY-Aktualisierung und eine Verschlüsselungsaktualisierung auslösen, um die erforderliche MIC-Länge zu ermitteln, bevor die Anforderung erneut versucht wird. Kann die erforderliche MIC-Länge nicht ermittelt werden, wird die Anforderung abgelehnt.

Weitere Einzelheiten finden Sie in Band 3, Teil C der Kernspezifikation.

9.3. Attributprotokoll (ATT)

HDT macht die MIC-Länge zu einem zusätzlichen Sicherheitskriterium für den Zugriff auf Attribute, die vom Attribute Protocol (ATT) verwaltet werden.

ATT ist das Protokoll, das von Bluetooth-LE-Geräten verwendet wird, damit ein Client die von einem Server bereitgestellten Attribute erkennen, lesen, schreiben und anderweitig darauf zugreifen kann.

HDT führt einen neuen Fehlercode ein: „MIC Length Too Short“(MIC-Länge zu kurz). Dieser gibt an, dass eine Anforderung zum Zugriff auf ein Attribut abgelehnt wird, da die ausgehandelte MIC-Länge die Sicherheitsanforderungen des angeforderten Attributs nicht erfüllt. Der Fehlercode ist in die ATT-Attributberechtigungen integriert und wird in allen ATT-Prozeduren unterstützt, die auf geschützte Attribute zugreifen, einschließlich der Attributermittlung sowie Lese- und Schreibvorgängen.

Die aktualisierten ATT-PDUs, die den neuen Fehlercode unterstützen, sind in Band 3, Teil F der Kernspezifikation aufgeführt und werden nachfolgend zur Information aufgeführt.

• ATT_ERROR_RSP
• ATT_FIND_INFORMATION_REQ
• ATT_FIND_BY_TYPE_VALUE_REQ
• ATT_READ_BY_TYPE_REQ
• ATT_READ_REQ
• ATT_READ_BLOB_REQ
• ATT_READ_MULTIPLE_REQ
• ATT_READ_BY_GROUP_TYPE_REQ
• ATT_READ_MULTIPLE_VARIABLE_REQ
• ATT_WRITE_REQ
• ATT_PREPARE_WRITE_REQ

9.4. Generisches Attributprofil (GATT)

HDT nimmt geringfügige Anpassungen an den im GATT-Profil definierten Prozeduren vor, um Merkmalswerte und Deskriptoren zu lesen und zu schreiben, die dazu beitragen, die Sicherheitsprüfungen der MIC-Länge auf ATT-Ebene sowie den neuen Fehlerzustand „MIC-Länge zu kurz“ zu erkennen und weiterzugeben.

Die aktualisierten GATT-Verfahren sind in Band 3, Teil G der Kernspezifikation aufgeführt und werden nachfolgend zur Information aufgeführt.

• Merkmalswert lesen
• Langen charakteristischen Wert lesen
• Mehrere Merkmalswerte auslesen
• Mehrere Merkmalswerte mit variabler Länge lesen
• Charakteristischen Wert eingeben
• Langen charakteristischen Wert eingeben
• Merkmal Wert Zuverlässige Schreibvorgänge
• Charakteristikdeskriptor lesen
• Langen Merkmalsdeskriptor lesen
• Charakteristikdeskriptor schreiben
• Langen Merkmalsdeskriptor schreiben

9.5. Isochrone Anpassungsschicht (ISOAL)

HDT führt Aktualisierungen der Isochronous Adaptation Layer (ISOAL) ein, die erforderlich sind, um die Übertragung größerer Datenmengen zu unterstützen, die durch die HDT-PHY-Schicht ermöglicht wird.

ISOAL ist für die Segmentierung und den Neuzusammensetzung von Service Data Units (SDUs) zuständig, die über isochrone Übertragungskanäle ausgetauscht werden (wie sie in den CIS- und BIS-Strömen von LE Audio verwendet werden).

Um größere SDU-Segmente zu unterstützen, passt HDT das Format des ISOAL-Framed-PDU-Segmentierungsheaders an, indem das Feld „Length“ von 8 Bit auf 12 Bit erweitert wird. Das Feld „Length“ gibt die Größe des in einer gerahmten PDU übertragenen SDU-Segments in Oktetten an. Um die Kompatibilität mit dem bestehenden Header-Format zu gewährleisten, wird der 12-Bit-Wert innerhalb des Segmentierungsheaders in die separaten Felder „Length High“ und „Length Low“ unterteilt.

Diese Änderungen erhöhen die maximale SDU-Segmentgröße, die durch ISOAL dargestellt werden kann, und ermöglichen so den effizienten Transport größerer Nutzdaten bei gleichzeitiger Aufrechterhaltung der Kompatibilität mit der bestehenden ISOAL-Segmentierungs- und Wiederzusammensetzungsarchitektur. Weitere Einzelheiten finden Sie in Band 6, Teil G der Bluetooth-Kernspezifikation.

Obwohl diese Änderungen innerhalb von ISOAL umgesetzt werden, können sich ihre Auswirkungen auf höhere Schichten des Bluetooth-Stacks erstrecken. Durch die Unterstützung größerer SDU-Segmente ermöglicht ISOAL den Controllern den Transport größerer isochroner Nutzdaten, die letztendlich über größere ISO-Datenpakete an den Host übermittelt werden können. Während Segmentierung und Neuzusammenstellung für die meisten Host- und Anwendungssoftwareprogramme transparent bleiben, trägt die durch HDT bereitgestellte erhöhte Nutzdatenkapazität dazu bei, anspruchsvollere isochrone Datenströme zu unterstützen, ohne dass Änderungen an der zugrunde liegenden ISOAL-Segmentierungs- und Neuzusammenstellungsarchitektur erforderlich sind.

10. Schlussfolgerung

Bluetooth® High Data Throughput erweitert die Funktionen und die Leistung von Bluetooth LE erheblich und schafft damit die Grundlage für eine neue Generation drahtloser Anwendungen sowie neue Innovationsmöglichkeiten im gesamten Bluetooth-Ökosystem.

Der neue Bluetooth-HDT-PHY erweitert die Leistungsgrenzen von Bluetooth LE und erhöht die maximal unterstützte Bitrate auf 7,5 Mbit/s – dank höherer spektraler Effizienz, adaptiver Datenraten und Mechanismen, die darauf ausgelegt sind, eine zuverlässige Kommunikation unter wechselnden Kanalbedingungen aufrechtzuerhalten.

Die neue Bluetooth-HDT-Paketstruktur ergänzt die PHY mit höherer Kapazität durch flexible Formate, die auf ein ausgewogenes Verhältnis zwischen Effizienz, Robustheit und Overhead ausgelegt sind. Durch die Trennung des Steuerheaders von der Nutzlast können wichtige Paketinformationen robuster verarbeitet werden, während gleichzeitig dynamische Datenraten für die Übertragung der Nutzlast unterstützt werden. Größere Nutzlasten, die Aggregation von Nutzlasten, blockbasierte Übertragung und selektive Neuübertragung ermöglichen es HDT zudem, größere Datenmengen effizient zu übertragen und so die Auswirkungen von Übertragungsfehlern zu begrenzen.

Die Erweiterungen der HDT-Verbindungsschicht bieten die erforderlichen Funktionen, um den HDT-Betrieb zu konfigurieren und zu verwalten, Übergänge zwischen GFSK- und HDT-PHYs zu koordinieren, auf sich ändernde Verbindungsbedingungen zu reagieren, isochrone Kommunikation zu unterstützen und die mit Bluetooth HDT eingeführten erweiterten Sicherheitsfunktionen zu verwalten.

HDT verbessert die Sicherheit von Bluetooth LE durch längere MIC-Längen und die Unterstützung der Funktion „Encryption Key Schedule“ (EKS), wodurch ein stärkerer Schutz für größere Nutzdatenmengen sowie koordinierte Schlüsselaktualisierungen beim Übergang der Geräte zwischen dem GFSK- und dem HDT-Betrieb ermöglicht werden. EKS führt zudem Funktionen wie opportunistische Verschlüsselung, Perfect Forward Secrecy und eine flexiblere Verwaltung der Verschlüsselungsschlüssel ein.

Durch Aktualisierungen der HCI- und Host-Schichten wird die HDT-Controller-Funktionalität in den übergeordneten Bluetooth-LE-Stack integriert. Dadurch erhält der Host die erforderlichen Schnittstellen, um HDT-Einstellungen und -Parameter festzulegen, den HDT-Betrieb zu überwachen und die größeren Nutzdatenmengen sowie die erweiterten Sicherheitsanforderungen zu unterstützen, die mit dem neuen PHY eingeführt wurden.

Für etablierte Bluetooth-Anwendungen und Anwendungsfälle bietet Bluetooth HDT Funktionen, die Entwickler in neuen Produktgenerationen nutzen können, um schnellere Datenübertragungen, höhere Kapazitäten, verbesserte Effizienz und eine stabilere drahtlose Leistung zu erzielen. Gleichzeitig erweitert HDT die Möglichkeiten von Bluetooth LE und bietet die zusätzliche Leistung und Kapazität, die für anspruchsvollere Anwendungen wie hochauflösendes und verlustfreies Audio sowie für neue Anwendungen mit immer höheren Datenanforderungen erforderlich sind.

Insgesamt hat sich die Bluetooth-Technologie kontinuierlich weiterentwickelt, um neuen Anwendungen gerecht zu werden und gleichzeitig die Interoperabilität, Effizienz und Flexibilität zu bewahren, die zu ihrer breiten Akzeptanz beigetragen haben. Bluetooth® High Data Throughput stellt einen wichtigen nächsten Schritt in dieser Entwicklung dar und bietet die zusätzliche Leistung und Kapazität, die erforderlich sind, damit sich Bluetooth LE gemeinsam mit den Anwendungen und Nutzererlebnissen, die darauf angewiesen sind, weiterentwickeln kann.

Die vollständigen Implementierungsanforderungen und technischen Details finden Sie in der Bluetooth Core Specification 7.0.

1. C. E. Shannon, „A mathematical theory of communication“, Bell System Technical Journal, Band 27, S. 379–423 und 623–656, Juli und Oktober 1948.