Technischer Überblick über Bluetooth® Core 6.3

1. Einleitung

Die Bluetooth® Core Specification v6.3 (Bluetooth® Core 6.3) enthält mehrere Funktionserweiterungen. Dieses Dokument bietet einen Überblick über die einzelnen Erweiterungen.

Hinweis: Dies ist ein Marketingdokument und soll die Bluetooth® Core Specification in keiner Weise ersetzen oder außer Kraft setzen. Jede Funktionserweiterung wird in einem eigenen Abschnitt beschrieben, beginnend mit relevanten Hintergrundinformationen. Dies soll Lesern helfen, die mit bestimmten Aspekten von Bluetooth® LE nicht vertraut sind. Die Hintergrundabschnitte sind jedoch nicht vollständig. Lesern, die mit der Terminologie oder den Konzepten nicht vertraut sind, wird empfohlen, die Bluetooth® LE herunterzuladen und zu lesen.

2. Auf einen Blick

Es wurde eine Reihe gezielter Verbesserungen eingeführt, um die Leistungsfähigkeit der Bluetooth®-Technologie weiter auszubauen. Diese Aktualisierungen verbessern die hochpräzise Entfernungsmessung, ermöglichen eine detailliertere Leistungsberichterstattung, sichern die Zukunftsfähigkeit der Host Controller Interface (HCI) und vereinheitlichen die Anforderungen an die Funkfrequenz (RF), um die Komplexität des Designs und den Stromverbrauch zu reduzieren.

2.1 Bluetooth®-Kanal-Messung mit Inline-PCT-Übertragung

Die „Bluetooth® Channel Sounding Inline PCT Transfer“-Funktion verbessert die Genauigkeit und Effizienz des Bluetooth® Channel Sounding, indem sie es dem Reflektor ermöglicht, phasenangepasste Töne direkt an die Hardware zu übertragen. Sie modifiziert das Bluetooth® Channel Sounding-Verfahren, indem sie die Phase des Tons am Reflektor anpasst. Der Reflektor meldet die imaginäre (Q-)Komponente der Werte des Phasenkorrekturterms (PCT) nicht mehr über HCI. Diese Änderung optimiert die Leistung, indem sie überflüssige Ergebnisdaten eliminiert, den Overhead reduziert und die Geschwindigkeit und Effizienz des Bluetooth®-Kanalabtastverfahrens verbessert, insbesondere im Zusammenhang mit Ranging Service (RAS) und Ranging Profile (RAP).

2.2 Bluetooth®-Kanal-Sounding: PHY-spezifische RTT-Genauigkeit

Die PHY-spezifische RTT-Genauigkeit für Bluetooth®-Kanalortung ermöglicht es Geräten, die Genauigkeit der Round-Trip-Time für jede PHY separat anzugeben, anstatt sich auf einen einzigen Wert für alle Modi zu stützen. Durch die Einführung neuer PHY-spezifischer Round-Trip-Time-Parameter (RTT) und einer erweiterten Funktionsstruktur können Systeme die optimale Kombination aus PHY und Genauigkeit auswählen, wodurch Präzision, Leistungsskalierung und Interoperabilität in Szenarien mit mehreren PHYs verbessert werden.

2.3 Bluetooth®: Die Bits gehen zur Neige

Bluetooth® Running Out of Bits erweitert die architektonischen Grenzen der HCI, indem es die Bitmaske für unterstützte Befehle von 64 auf 251 Oktette und die LE-Ereignismaske von 8 auf 255 Oktette erweitert. Es bietet die erforderliche Protokollkapazität für zukünftige Funktionserweiterungen, gewährleistet die Erkennbarkeit neu zugewiesener Befehle und Ereignisse und gewährleistet die Abwärtskompatibilität durch versionierte Befehle und bedingte Unterstützungsregeln.

2.4 Lockerung der Bluetooth®-ACP- und C/I-Grenzwerte

Die Lockerung der Bluetooth®-ACP- und C/I-Grenzwerte harmonisiert die HF-Anforderungen zwischen Bluetooth® Classic (Basic Rate/Enhanced Data Rate, BR/EDR) und Bluetooth® LE, indem die BR/EDR-Grenzwerte für die Leistung im benachbarten Kanal (ACP) und das Träger-Störsignal-Verhältnis (C/I) an das LE-1-MS/s-Framework angepasst werden. Die aktualisierten Grenzwerte lockern unnötige Einschränkungen für Bluetooth®-Dual-Mode-Funkmodule, die sowohl Bluetooth® BR/EDR als auch Bluetooth® LE unterstützen, vereinfachen die Designziele für Sender und Empfänger und ermöglichen energieeffizientere, flexiblere HF-Architekturen, ohne die Koexistenzleistung zu beeinträchtigen.

3. Bluetooth®-Kanal-Sound-Inline-PCT-Übertragung

3.1 Hintergrund

Die phasenbasierte Entfernungsmessung (PBR) bei der Bluetooth®-Kanalortung schätzt die Entfernung durch die Messung von Phasenverschiebungen über mehrere Frequenzen hinweg. Die zentrale Beziehung ergibt sich aus der Ausbreitungsverzögerung τ = 2d/c:

θ(f) = 2πfτ = 2π(2df/c)

Somit ist die Phasenverschiebung θ(f) proportional zur Hin- und Rücklaufstrecke 2d und zur Frequenz f.

Da der Initiator und der Reflektor in der Praxis jeweils unabhängige lokale Oszillatoren (LOs) verwenden, enthält die gemessene Phase einen gerätespezifischen Versatz, der nicht mit dem physikalischen Kanal zusammenhängt. Die am Empfänger beobachtete Phase setzt sich daher wie folgt zusammen:

Kanalbedingte Phase _θCH(f) — Die Phasenverschiebung wird ausschließlich durch die Signalausbreitung in der Luft verursacht. Dies ist eine nützliche Komponente, die die Entfernungsinformation d enthält.
LO-relativer Phasenversatz _ΔθLO(f) — Ein systematischer Versatz, der sich aus der Phasendifferenz zwischen den LO-Signalen des Initiators und des Reflektors ergibt. Dieser Versatz enthält keine Entfernungsinformationen und muss beseitigt werden. Der LO-relative Versatz ist definiert als:
_ΔθLO(f) =_{θLO,Initiator}(f) −_{θLO,Reflector}(f)

Und die gemessenen Phasen in einem wechselseitigen Austausch lauten:

Messung am Reflektor: _θREFL(f) =_θCH(f) +_ΔθLO(f)
Messwert des Initiators: _θINIT(f) =_θCH(f) −_ΔθLO(f)

Bluetooth-Geräte sollten während des PBR-Signalaustauschs darauf hinarbeiten, die durch den Kanal verursachte Phasenverschiebung auszugleichen und gleichzeitig den LO-relativen Phasenversatz zu beseitigen. Dieser Ansatz ermöglicht es den Geräten, präzisere Phasendaten zu erzeugen, was zu genaueren Entfernungsmessungen führt.

3.2 Herkömmliche bidirektionale Phasenauslöschung (digitale Nachbearbeitung)

Die Bluetooth®-Funktion „Channel Sounding Inline Phase Correction Term (IPT) Transfer“ verbessert die Genauigkeit und Effizienz der Entfernungsmessung durch eine Verfeinerung der Phasendatenpräzision. Auf höchster Ebene hängt eine hochpräzise Entfernungsmessung von der Integrität des Phase Correction Term (PCT) ab. IPT ermöglicht es dem Reflektor, eine Inline-Analogphasen-Vorkompensation durchzuführen, wodurch Offsets des lokalen Oszillators (LO) in Echtzeit effektiv neutralisiert werden, noch bevor der Initiator das Signal überhaupt misst. Durch die Übertragung einer „saubereren“ Phasenkomponente verringert IPT das Risiko, dass digitale Verarbeitungsfehler und LO-Drift die endgültige Entfernungsberechnung beeinträchtigen. Darüber hinaus reduziert es den Datenaufwand und verbessert die Entfernungsmessgeschwindigkeit, wodurch innerhalb einer bestimmten Zeit mehr CS-Verfahren durchgeführt werden können.

Ohne IPT beseitigt die Bluetooth®-Kanalmessung den LO-Offset durch eine Zwei-Wege-Messung und digitale Kompensation. Das Verfahren ist im Folgenden beschrieben:

Messung am Reflektor (Vorwärtsweg)
Der Reflektor empfängt das Signal vom Initiator und misst dessen Phase:
_θREFL(f) =_θCH(f) +_ΔθLO(f)
Messung durch den Initiator (Rückweg)
Der Initiator empfängt das reflektierte Signal und misst dessen Phase:
_θINIT(f) =_θCH(f) −_ΔθLO(f)
Digitales Auslöschungs
Der Initiator summiert beide PCTs:
_θREFL(f) +_θINIT(f) =_2θCH(f)
Die _ΔθLO(f) -Terme heben sich gegenseitig auf, wodurch die reine, doppelte Kanalphase entsteht, die für die Entfernungsschätzung benötigt wird.

Und die Einschränkungen dieser traditionellen Methode sind:

Nachbearbeitungslatenz – Die Aufhebung erfolgt im digitalen Bereich, nachdem beide Messungen erfasst wurden.
Datenaufwand – Der Reflektor muss für jeden Ton und jeden Antennenpfad vollständige komplexe PCTs (I und Q) über HCI-Ereignisse melden, was zu einem hohen Datenaufwand in der Steuerungsebene führt.
Algorithmuskomplexität – Der Initiator muss zwei Messungen kombinieren, um _2θCH(f) zu ermitteln.

3.3 Inline-PCT-Übertragung (IPT): Inline-Analog-Phasenvorausgleich

Die in diesem Änderungsantrag vorgestellte Funktion „Bluetooth® Channel Sounding IPT Transfer“ verlagert die LO-Offset-Kompensation vom digitalen Bereich auf das analoge Frontend des Reflektors.

Der Reflektor nutzt die gemessene Phase _θREFL(f) sofort, um die Phase seines ausgehenden Signals anzupassen, wodurch er die empfangene Phase kohärent weiterleitet.

3.3.1 Phasenfluss bei aktivierter IPT

Reflektormessung (unverändert)
_θREFL(f) =_θCH(f) +_ΔθLO(f)
Übertragung durch den Reflektor (Tastenwechsel)
Anstatt mit seiner eigenen LO-Phase (_θLO,R) zu senden, sendet der Reflektor mit einer Phase, die auf das empfangene Signal abgestimmt ist:
_φTX,R =_θLO,I +_θCH(f)
Der Reflektor benötigt keine Kenntnis des LO des Initiators; durch die kohärente Weiterleitung heben sich die LO-Terme gegenseitig auf.
Der Initiator empfängt das IPT-kompensierte Signal
. Dieses phasenverschobene Signal wandert durch den Kanal zurück (wobei sich _ein weiterer _{Winkel θCH} addiert) und erreicht den Initiator mit der absoluten Phase:
_φRX,I =_θLO,I +_2θCH(f)
Phasen
des Initiators im Basisband Nach der Abwärtskonvertierung unter Verwendung seines eigenen LO (_θLO,I) lautet die Phase des Initiators im Basisband:
_θINIT,IPT(f) =_2θCH(f)
Der Term _ΔθLO(f) wurde im analogen Bereich vor der digitalen Messung entfernt.
PCT-Meldung des Reflektors (vereinfacht)
Da der Reflektor seine gemessene Phase bereits zur Kompensation verwendet hat, meldet er einen PCT mit der Phase Null (Q = 0). Die I-Komponente enthält nur die Signalamplitude. Der PCT des Initiators enthält nun hingegen die direkte _2θCH(f) -Messung.

3.4 Vergleichende Analyse: Traditionell vs. IPT-gestützt

Die Tabelle fasst den Phasenfluss und das Systemverhalten zusammen, wobei die absolute Phase als Referenz zwischen der herkömmlichen Methode und der IPT-basierten Methode dient.

Schritt	Beschreibung	Traditionell (ohne IPT)	IPT-fähig	Technische Auswirkungen
1	Initiator TX	_θLO,I	_θLO,I	Ausgangszustand.
2	Reflektor RX	_θLO,I +_θCH	_θLO,I +_θCH	Gleiche Ausbreitung.
3	Reflektor-Basisband	_θCH +_ΔθLO	_θCH +_ΔθLO	Gleiche Maße.
4	Reflektor TX	_θLO,R	_θLO,I +_θCH	Grundlegender Unterschied: Kein IPT verwendet eine eigene LO. Bei IPT: Die empfangene Phase wird kohärent weitergeleitet.
5	Initiator RX	_θLO,R +_θCH	_θLO,I +_2θCH	IPT verschiebt die Phase um _θCH vorwärts.
6	Initiator-Basisband	_θCH −_ΔθLO	_2θCH	Der Initiator misst direkt die verdoppelte Kanalphase; _ΔθLO wird eliminiert.
7	Reflector-PCT-Bericht	_θCH +_ΔθLO (Komplex I/Q)	Q = 0	IPT vereinfacht den Reflector-Bericht auf die Amplitude (Q = 0).
8	Effektive 2-Wege-Phase	_2θCH (über digitale Summierung)	_2θCH (Direktmessung)	Gleiches Ergebnis, anderer Mechanismus.

3.5 Technische Vorteile und Überlegungen zur Umsetzung

3.5.1 Technische Vorteile

Vereinfachte Verarbeitung durch den Initiator – Der Initiator erhält direkt eine „saubere“ _2θCH(f) -Messung, wodurch sich die Komplexität des Algorithmus und die Latenzzeit verringern.
Reduzierte Datenlast – Der PCT des Reflektors wird vereinfacht (Q = 0), wodurch die HCI-Datenlast pro Ton verringert wird.
Verbesserte Robustheit – Die Kompensation erfolgt in der analogen Hardware sofort, wodurch die Empfindlichkeit gegenüber LO-Drift während des Austauschs verringert wird.
Geringere Latenz – Die Entfernungsmessung kann unmittelbar nach dem Empfang des Initiators beginnen (es muss nicht auf den PCT-Bericht des Reflektors gewartet werden).

3.5.2 Überlegungen zur Umsetzung

Komplexität des Reflektors – Der Reflektor muss eine phasenkohärente Neuübertragung unterstützen, was zusätzliche Hardware zur Phasenverfolgung oder Phasenkompensation erfordert.
Funktionsaushandlung – IPT ist eine verhandelbare und konfigurierbare Funktion. Die Unterstützung wird im LL_CS_CAPABILITIES-Austausch (IPT-Bit in [v2]-PDUs) angegeben und über die LL_CS_CONFIG_REQ-PDU (IPT-Bit) aktiviert. Eine Sitzung nutzt IPT nur, wenn beide Geräte diese Funktion unterstützen und sie auf beiden Geräten explizit aktiviert ist.
Neue Zeitparameter – Die Spezifikation führt ergänzende Zeitparameter (T_IP2_IPT, T_SW_IPT) ein, um möglichen Verarbeitungsunterschieden bei aktivem IPT Rechnung zu tragen. Die Dauer der Antennenumschaltung richtet sich nach den aktivierten Funktionen beider Peers.
Abwärtskompatibilität – Geräte, die die Bluetooth®-Funktion „Channel Sounding Inline PCT Transfer“ nicht unterstützen, arbeiten weiterhin mit der herkömmlichen Zwei-Wege-Unterdrückungsmethode. Die Funktion ist so konzipiert, dass sie für ältere Initiatoren transparent bleibt.

4. Bluetooth®-Kanal-Sounding: PHY-spezifische RTT-Genauigkeit

4.1 Hintergrund

Bluetooth® Channel Sounding umfasst zudem ein sekundäres Entfernungsmessverfahren namens Round-Trip Time (RTT), das die Entfernung durch Berechnung der Laufzeit (ToF) einer HF-Signalübertragung zwischen Geräten schätzt. Während die Genauigkeit von RTT grundsätzlich von der Genauigkeit der internen Uhr und der Auflösung des Zeitstempels abhängt, wird die letztlich erreichbare Zeitgenauigkeit in einer Sounding-Sitzung durch die Anzahl der durchgeführten CS_SYNC-Austausche bestimmt.

Vor der Einführung der PHY-spezifischen Verbesserung der RTT-Genauigkeit im Rahmen des Bluetooth® Channel Sounding gab ein Gerät eine einzige RTT-Genauigkeitsanforderung an, die für alle PHYs galt. Diese Anforderung umfasste ein bestimmtes Ziel für die Laufzeitgenauigkeit (z. B. 10 ns oder 150 ns) sowie die Mindestanzahl an CS_SYNC-Austauschvorgängen, die zu deren Erreichung erforderlich waren. Dabei wurden jedoch PHY-spezifische Leistungsmerkmale nicht berücksichtigt. Verschiedene PHYs weisen unterschiedliche Funkcharakteristiken auf (z. B. Symbolperiode und Störfestigkeit), die sich direkt auf die Genauigkeit der RTT-Messung auswirken. Das bisherige einheitliche Deklarationsmodell konnte zu Herausforderungen bei der RTT-Entfernungsmessung führen – wie z. B. die Notwendigkeit von mehr Austauschvorgängen als erforderlich und/oder ungenaue ToF-Daten –, die beide die Berechnungen der RTT-Entfernungsmessung beeinträchtigen können.

Diese Erweiterung führt einen Mechanismus zur Angabe der RTT-Genauigkeit pro PHY ein, der es Geräten ermöglicht, die RTT-Leistung separat für den LE-1M-PHY sowie die optionalen LE-2M- und LE-2M-2BT-PHYs festzulegen, wodurch die Genauigkeit der Entfernungsmessung bei der RTT-basierten Entfernungsbestimmung verbessert wird.

4.2 Technischer Überblick

4.2.1 Neue RTT-Genauigkeitsparameter für LE-2M-PHYs

Es wurden drei neue 1-Oktett-Parameter eingeführt, um die RTT-Leistung für LE 2M- und LE 2M 2BT-PHYs anzugeben:

RTT_2M_AA_Only_N: Für den reinen AA-Modus bei LE-2M-PHYs
RTT_2M_Sounding_N: Für Standard-Sounding-Sequenzen bei LE-2M-PHYs
RTT_2M_Random_Sequence_N: Für Zufallssequenzen auf LE-2M-PHYs

Details zu den Parametern: Der Wert jedes Parameters bestimmt dessen Bedeutung:

Wert = 0x00: Zeigt an, dass der entsprechende RTT-Modus von LE-2M/2M-2BT-PHYs nicht unterstützt wird.
Wert = 0x01 bis 0xFF: Gibt die Anzahl der CS_SYNC-Austauschvorgänge an, die erforderlich sind, um die Genauigkeitsanforderungen für diesen RTT-Modus zu erfüllen.

Präzise Zielangabe: Wenn ein Parameterwert ungleich Null ist, gibt das entsprechende Bit im erweiterten Feld „RTT_Capability“ das Ziel für die Anzahl der Austausche an:

10 ns Laufzeitgenauigkeit (Bit = 1)
150 ns Laufzeitgenauigkeit (Bit = 0)

Wenn der Parameterwert 0x00 (nicht unterstützt) lautet, wird das zugehörige Präzisionsbit in RTT_Capability ignoriert.

4.2.2 Verbesserungen der Host-Controller-Schnittstelle (HCI)

Die HCI-Schicht integriert diese neuen Parameter über versionierte Befehle und Ereignisse, um die Abwärtskompatibilität zu gewährleisten.

Neue HCI-Befehle und -Ereignisse [v2]:

HCI_LE_CS_Read_Local_Supported_Capabilities [v2]: Gibt die Funktionen des lokalen Geräts zurück, nun einschließlich der drei neuen LE-2M-Parameter und des erweiterten 6-Bit-Feldes „RTT_Capability [v2]“.
LE_CS_Read_Remote_Supported_Capabilities_Complete [v2]: Gibt die Funktionen des Remote-Geräts zurück.
HCI_LE_CS_Write_Cached_Remote_Supported_Capabilities [v2]: Ermöglicht es dem Host, zwischengespeicherte Remote-Fähigkeiten zu schreiben.

Aktualisierungen der wichtigsten Parameter:

Um höhere Datenraten zu unterstützen, enthält die HCI nun spezielle Parameter für die Austauschanzahl bei LE 2M PHY (nur AA, Sounding und Zufallssequenz). Diese ergänzen die bestehenden LE 1M-Parameter. Die Unterstützung dieser [v2]-Versionen ist für Geräte obligatorisch, die die PHY-spezifische RTT-Genauigkeit für Bluetooth® Channel Sounding implementieren.

Abwärtskompatibilität und Standardwerte:

Für den Befehl `HCI_LE_CS_Write_Cached_Remote_Supported_Capabilities` gewährleistet eine Standardlogik die Kompatibilität mit älteren [v1]-Strukturen:

Unterstützung älterer Befehle: Wenn ein [v1]-Befehl verwendet wird, enthält dieser nicht die spezifischen Felder für den LE 2M PHY.
Automatische Zuordnung: In diesem Fall füllt der Controller die fehlenden LE-2M-Parameter automatisch mit den Werten, die für die entsprechenden LE-1M-Parameter angegeben wurden.

4.2.3 Aktualisierungen des Link-Layer-Protokolls (LL)

Die Verbindungsschicht integriert dieselben Parameter über ein erweitertes PDU-Format, jedoch mit einer anderen strukturellen Anordnung.

Erweitertes LL-PDU-Format [v2]:

Das PDU-Format LL_CS_CAPABILITIES_REQ/RSP [v2] wird um Felder für die drei neuen LE-2M-Parameter erweitert.
Die PDU enthält ein RTT-PHY-Indikatorbit (im Feld „Subfeatures_Supported“), das die Verwendung des PHY-spezifischen Modells signalisiert.

Im Gegensatz zur HCI-Sequenz sind die Parameter in der LL-PDU gemäß dem definierten Format innerhalb der CtrData-Struktur verteilt.

4.3 Technische Vorteile und Überlegungen zur Umsetzung

4.3.1 Technische Vorteile

Optimierte Effizienz bei der Entfernungsmessung: Die Geräte können nun für jede spezifische PHY-Schicht die minimal erforderliche Anzahl an CS_SYNC-Austauschvorgängen durchführen, wodurch sich die Funkbetriebszeit und der Stromverbrauch verringern.

Präzise Zielgenauigkeit: Durch die Entkopplung der LE 1M- und LE 2M-Deklarationen können Systeme auf leistungsfähigen PHYs eine höhere Präzision (10 ns) erzielen, ohne durch leistungsschwächere PHYs eingeschränkt zu werden.

Verbesserte Interoperabilität: Durch die explizite Angabe der Unterstützung für verschiedene RTT-Modi pro PHY wird eine besser vorhersehbare Leistung in Umgebungen mit Geräten verschiedener Hersteller gewährleistet.

4.3.2 Überlegungen zur Umsetzung

Obligatorische Unterstützung von HCI [v2]: Wenn ein Gerät die PHY-spezifische RTT-Genauigkeit von Bluetooth® Channel Sounding implementiert, muss es die [v2]-Versionen der Lese-/Schreibbefehle der LE CS-Funktion unterstützen.

Logik der Abwärtskompatibilität: Das Standardverhalten bei „fehlenden Parametern“ ist obligatorisch. Der Controller setzt LE-2M-Parameter auf die entsprechenden LE-1M-Werte, um einen nahtlosen Betrieb mit älteren Hosts zu gewährleisten.

Erweiterte PDU-Verarbeitung: Die Link-Schicht muss aktualisiert werden, um das erweiterte PDU-Format „LL_CS_CAPABILITIES“ zu verarbeiten, bei dem die neuen Parameter in die CtrData-Struktur eingebettet sind.

5. Bluetooth® geht der Speicherplatz aus

5.1 Hintergrund

Die Host Controller Interface (HCI) ist die standardisierte Kommunikationsschicht zwischen einem Bluetooth-Host und einem Bluetooth-Controller. Befehle werden vom Host an den Controller gesendet, während Ereignisse vom Controller an den Host gesendet werden. Die Bluetooth® Core Specification verwendet Bitmaskenfelder, um die Unterstützung für diese Befehle und Ereignisse zu definieren und zu steuern:

Supported_Commands: Eine vom Befehl HCI_Read_Local_Supported_Commands zurückgegebene Bitmaske, bei der jedes Bit einem bestimmten HCI-Befehl entspricht (1 = unterstützt).
LE_Event_Mask: Ein Parameter, der vom Befehl HCI_LE_Set_Event_Mask verwendet wird, wobei jedes Bit steuert, ob ein bestimmter Low-Energy-Ereignistyp (LE) für die Meldung an den Host aktiviert ist.

Im Zuge der Weiterentwicklung der Bluetooth-Technologie, insbesondere durch die rasche Einführung von Bluetooth® LE-Funktionen, sind die verfügbaren Bits in diesen Feldern fast vollständig ausgeschöpft. Die ursprüngliche Begrenzung auf 512 Bit für Befehle und auf 64 Bit für Bluetooth® LE-Ereignisse hat sich zu einem Engpass für die Hinzufügung neuer HCI-Befehle und -Ereignisse in künftigen Spezifikationsaktualisierungen entwickelt.

5.2 Technischer Überblick

5.2.1 Neue Befehlsversionen

Diese neue Funktion ändert die bestehenden Befehle nicht. Stattdessen werden neue „v2“-Varianten mit neuen OpCode-Befehlsfeldern (OCF) eingeführt:

HCI_Read_Local_Supported_Commands [v2] (OCF: 0x0010): Dieser neue Befehl gibt die vollständige 251-Oktett-Bitmaske „Supported_Commands“ zurück. Der ursprüngliche Befehl [v1] (OCF 0x0002) gibt weiterhin nur die ersten 64 Oktette zurück. Ein neuer OCF ist erforderlich, da die Rückgabeparameter von HCI-Befehlen versionsgebunden sind; die Wiederverwendung des ursprünglichen OCF würde erfordern, dass ältere Hosts eine erweiterte Rückgabestruktur analysieren müssten, die sie nicht unterstützen.
HCI_LE_Set_Event_Mask [v2] (OCF: 0x00A4): Dieser neue Befehl ermöglicht es dem Host, die vollständige 255-Oktett-LE_Event_Mask zu setzen. Der ursprüngliche [v1]-Befehl (OCF 0x0001) setzt nur die ersten 64 Bits (8 Oktette) der Maske; die Bits 64 und höher bleiben bei Verwendung des v1-Befehls unverändert.

5.2.2 Rückwärtskompatibilität und Erkennung von Funktionen

Bedingte Unterstützung:
Die v2-Befehle lauten optional die ein Controller implementieren muss, wobei folgende wesentliche Bedingungen gelten: Diese Bedingungen stellen sicher, dass der Host über die erforderlichen Werkzeuge verfügt, um erweiterte Funktionen eines Controllers zu erkennen und zu steuern, falls dieser solche Funktionen nutzt.
- Ein Controller muss die Funktion `HCI_LE_Set_Event_Mask [v2]` implementieren, wenn er Ereignisse unterstützt, die über die ursprüngliche Bit-Zuweisung hinausgehen.
- Ein Controller muss HCI_Read_Local_Supported_Commands [v2] implementieren, wenn er Befehle unterstützt, die über die ursprüngliche Bit-Zuweisung hinausgehen.
Befehls- und Ereigniserkennung:
Die Überprüfung der Unterstützung für einen bestimmten Befehl hängt davon ab, ob sich das entsprechende Bit im ursprünglichen oder im erweiterten Block des Feldes „Supported_Commands“ befindet. Beachten Sie, dass die Befehlsversion (v1 vs. v2) unabhängig von der Position des Bits ist.
- Ursprünglicher Block (Oktette 0–63): Die Bits, die die Unterstützung für die beiden neuen v2-Befehle kennzeichnen, befinden sich im ursprünglichen Teil des Feldes „Supported_Commands“, genauer gesagt in Oktett 49. Da sich diese Bits im ursprünglichen Block befinden, kann ein Host die Unterstützung für v2-Befehle mithilfe des Befehls „HCI_Read_Local_Supported_Commands [v1]“ ermitteln.
- Erweiterter Block (Oktett 64+): Um die Unterstützung für einen Befehl im erweiterten Block zu prüfen, muss der Host den Befehl HCI_Read_Local_Supported_Commands [v2] verwenden. Wenn der Controller diesen v2-Befehl nicht unterstützt, lehnt er die Anfrage mit dem Fehlercode „Unbekannter HCI-Befehl (0x01)“ ab. Dadurch kann der Host eindeutig feststellen, dass der Controller die erweiterten Funktionen für „Running Out of Bits“ (ROOB) nicht unterstützt.
Versionskonsistenz:
- Befehle: Die Rückgabeparameter eines Befehls entsprechen immer der Version des ausgeführten Befehls. So gibt beispielsweise der Befehl [v1] 64 Oktette zurück, während der Befehl [v2] 251 Oktette zurückgibt.
- Ereignisse: Ein HCI-Ereignis gibt stets Felder zurück, die auf der höchsten Version des Ereignisses basieren, die sowohl vom Controller unterstützt als auch vom Host freigegeben wird.
Beibehaltung des Standardverhaltens:
Die Standardkonfiguration der Ereignismaske bleibt unverändert, und alle Bits, die nicht ausdrücklich aufgeführt oder unterstützt werden, bleiben für zukünftige Verwendung reserviert (RFU).

6. Lockerung der Bluetooth®-ACP- und C/I-Grenzwerte

6.1 Hintergrund

Die Bluetooth®-Kernspezifikation hat sich im Laufe mehrerer Versionen weiterentwickelt, was zu getrennten, zunehmend voneinander abweichenden technischen Anforderungen für ihre beiden wichtigsten Technologien auf der physikalischen Ebene geführt hat: Bluetooth® Classic (Basic Rate/Enhanced Data Rate, BR/EDR) und Bluetooth® LE. Im Laufe der Zeit haben sich die Spezifikationsanforderungen für wichtige HF-Leistungskennzahlen, insbesondere die Adjacent Channel Power (ACP) und das Carrier-to-Interference (C/I)-Verhältnis, unabhängig voneinander entwickelt. Dies hat zu Diskrepanzen zwischen den Grenzwerten und Testmethoden geführt, die für Bluetooth® BR/EDR- und Bluetooth® LE-Funkmodule vorgeschrieben sind.

Wichtig ist, dass die Anforderungen an Bluetooth® LE ACP und C/I durch diese Erweiterung unverändert bleiben.

Die in dieser Funktion eingeführten Änderungen konzentrieren sich ausschließlich auf Bluetooth® BR/EDR und passen dessen HF-Anforderungen an das bestehende LE-1-MS/s-Framework an.

Für ACP: Die Bluetooth®-BR/EDR-Spezifikationen sehen für höhere Frequenzabstände (z. B. > 3 MHz) Emissionsgrenzwerte vor, die etwa 15–17 dB strenger sind als die für Bluetooth® LE.
Für C/I: Die Anforderungen an die Störfestigkeit von Bluetooth®-BR/EDR-Empfängern sind strenger als die für Bluetooth® LE, insbesondere im Vergleich zu den Bluetooth®-High-Data-Throughput-Modi (HDT).

Diese Unstimmigkeiten stellen eine Herausforderung bei der Entwicklung moderner Bluetooth®-Dual-Mode-Funkmodule dar, die sowohl Bluetooth® BR/EDR als auch Bluetooth® LE (einschließlich Bluetooth® HDT) unterstützen müssen. Um die Konformität sicherzustellen, sind Entwickler gezwungen, die strengsten Anforderungen beider Standards zu erfüllen, was zu überbestimmten, suboptimalen Designs führt.

Diese Änderung beseitigt diese Unstimmigkeiten durch die Einführung eines einheitlichen Ansatzes auf der Grundlage des LE-1-MS/s-Rahmenwerks, das für die Signale mit einer Nennbandbreite von 1 MHz bei Bluetooth® BR und EDR geeignet ist.

6.2 Technischer Überblick

In diesem Abschnitt werden die konkreten Abweichungen und die vorgeschlagenen Änderungen für jeden wichtigen HF-Parameter aufgeführt.

6.2.1 Harmonisierung der Grenzwerte für die Leistung im Nachbarkanal (ACP)

Die Leistung in benachbarten Kanälen (Adjacent Channel Power, ACP) ist ein entscheidender Senderparameter, der die Leistungsabstrahlung in benachbarte Frequenzkanäle quantifiziert. Ihr Hauptzweck besteht darin, die Koexistenz sicherzustellen, indem Interferenzen mit anderen Bluetooth-Verbindungen oder drahtlosen Systemen, die auf benachbarten Frequenzen arbeiten, minimiert werden.

Die Änderung sieht vor, dass die ACP-Grenzwerte von 1 MS/s sowie die Prüfverfahren sowohl für Bluetooth®-BR- als auch für EDR-Sender gelten. Die wichtigsten Neuerungen sind:

Gelockerte Grenzwerte für größere Abstände: Der absolute Leistungsgrenzwert für benachbarte Kanäle bei Abständen von ≥ 3 MHz wird von -40 dBm auf -30 dBm gelockert und entspricht damit der LE-Spezifikation. Der Grenzwert für den zweitbenachbarten Kanal bei einem Abstand von 2 MHz bleibt bei -20 dBm.

6.2.2 Optimierung des Träger-Störsignal-Verhältnisses (C/I)

Das Träger-Stör-Verhältnis (C/I) gibt die Fähigkeit eines Empfängers an, ein gewünschtes Signal erfolgreich zu demodulieren, wenn auf einer benachbarten Frequenz ein starkes Störsignal vorhanden ist. Es ist das empfangsseitige Gegenstück zur ACP-Spezifikation des Senders. Ein ausgewogenes Verhältnis auf Systemebene ist unerlässlich: Ein extrem störungsfreier Sender bringt nur minimalen Nutzen, wenn der Empfänger die in der Praxis auftretenden Störpegel aus benachbarten Frequenzen nicht verträgt.

Die Änderung übernimmt den Wortlaut und die Methodik des LE 1 MS/s C/I-Tests, wobei für das Störsignal die entsprechende Bluetooth®-BR- oder EDR-Modulation verwendet wird. Die Grenzwerte werden auf der Grundlage des für die jeweilige Modulationsart erforderlichen Demodulations-SNR angepasst.

Für Bluetooth® Basic Rate (BR – GFSK):
- Der Sollpegel des Signals wird für alle Tests auf -67 dBm standardisiert, was die Testbedingungen vereinfacht.
- Die C/I-Grenzwerte werden, soweit dies gerechtfertigt ist, gelockert, um der Leistung von Bluetooth® LE gerecht zu werden:
  - Nachbarband (2 MHz): Von -30 dB auf -17 dB geändert.
  - Angrenzend (≥3 MHz): Von -40 dB auf -27 dB geändert.
  - Bildfrequenz ±1 MHz: Von -20 dB auf -15 dB geändert.
Für Bluetooth® Enhanced Data Rate (EDR):
- Zudem wird ein einheitlicher Signalpegel von -67 dBm verwendet.
- Die Grenzwerte werden gelockert, wobei der inhärente Leistungsunterschied (Delta) zwischen π/4-DQPSK- und 8DPSK-Modulationen beibehalten wird:
  - Für π/4-DQPSK:
    - Nachbarband (2 MHz): -30 dB → -17 dB
    - Nachbarband (≥3 MHz): -40 dB → -27 dB
    - Bildfrequenz ±1 MHz: -20 dB → -15 dB
  - Für 8DPSK (das ein höheres Signal-Rausch-Verhältnis erfordert):
    - Benachbart (2 MHz): -25 dB → -12 dB (behält einen Unterschied von +5 dB gegenüber π/4-DQPSK bei)
    - Benachbart (≥3 MHz): -33 dB → -20 dB (behält eine Differenz von +7 dB bei)
    - Bildfrequenz ±1 MHz: -13 dB → -8 dB

7. Schlussfolgerung

Bluetooth® Core 6.3 bietet Verbesserungen, die die Entfernungsmessgenauigkeit, die Skalierbarkeit der Schnittstellen und die Effizienz des Funkdesigns steigern. Fortschritte bei der Bluetooth®-Kanalabtastung reduzieren den Fehler des lokalen Oszillators, senken den Verarbeitungs- und Meldeaufwand und ermöglichen genauere, PHY-bewusste Entfernungsmessungen. Erweiterungen der Host-Controller-Schnittstelle unterstützen die kontinuierliche Erweiterung der Funktionen bei gleichzeitiger Aufrechterhaltung der Abwärtskompatibilität, und harmonisierte HF-Anforderungen vereinfachen das Design von Dual-Mode-Funkmodulen und verbessern die Energieeffizienz. Zusammen stärken diese Aktualisierungen die technische Grundlage der Bluetooth-Technologie und unterstützen kontinuierliche Innovationen für eine breite Palette von Geräten und Anwendungsfällen.

8. Referenzen

Artikel	Standort
Bluetooth®-Kernspezifikation v6.3	https://www.bluetooth.com/specifications/specs/core-specification-6-3/
Technisches Übersichtspapier zum Bluetooth® Channel Sounding	https://www.bluetooth.com/channel-sounding-tech-overview/