Bluetooth® Core 6.2 Funktionsübersicht

1. Einleitung

Die Bluetooth® Core Spezifikation v6.2 (Bluetooth® Core 6.2) enthält mehrere Funktionserweiterungen. Dieses Papier bietet einen Überblick über jede Verbesserung.

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

2.1 Bluetooth® Kürzere Verbindungsintervalle

Kürzere Verbindungsintervalle (SCI) reduzieren das minimale Verbindungsintervall von 7,5 ms auf 375 µs und ermöglichen so eine schnellere Reaktionszeit der Geräte für Hochleistungs-HID-Geräte, Echtzeit-HMI-Systeme und Sensoren.

2.2 Bluetooth® Channel Sounding Amplituden-basierte Angriffsresistenz

Channel Sounding Amplitude-based Attack Resilience stärkt die sichere Entfernungsmessung durch die Erkennung und Entschärfung ausgeklügelter RF-Amplitudenangriffe und bietet zusätzlichen Schutz gegen Relay- und Spoofing-Bedrohungen in Automobil-, Smart Home- und Industrieumgebungen.

2.3 Bluetooth® HCI USB LE Isochron-Unterstützung

HCI USB LE Isochronous Support standardisiert die isochrone Kommunikation über USB durch die Einführung des Bulk Serialization Mode, der die Übertragung von Host vereinheitlicht und die nahtlose Integration von Bluetooth® LE Audio ermöglicht.

2.4 Erweiterungen des Bluetooth® LE

LE Test Mode Enhancements ermöglichen flexible, sichere RF-Tests mit Over-the-Air (OTA)-Unterstützung durch die Einführung eines Unified Test Protocol (UTP) für drahtlose PHY-Tests, standardisiertes Messaging und verbesserte Teststeuerung.

3. Bluetooth® Kürzere Verbindungsintervalle

3.1 Hintergrund

Bluetooth® LE verwendet ein konfigurierbares Verbindungsintervall, um ein Gleichgewicht zwischen Latenz, Durchsatz und Stromverbrauch für drahtlose Geräte herzustellen. In der Vergangenheit betrug das Mindestintervall 7,5 ms mit einer Auflösung von 1,25 ms, was für viele Anwendungen ausreichend ist, aber für latenzempfindliche Anwendungsfälle wie AR/VR, Spiele und Echtzeit-Sensorik einschränkend ist.

Die neueste Bluetooth®-Spezifikation reduziert das Mindestintervall auf 375 µs mit einer Auflösung von 125 µs. Dies ermöglicht Kommunikationszyklen im Bereich von weniger als einer Millisekunde, was einen schnelleren Datenaustausch und ein reaktionsschnelleres Nutzererlebnis ermöglicht.

In diesem Abschnitt werden die Beweggründe für kürzere Verbindungsintervalle, die Änderungen der Spezifikation, die diese ermöglichen, und die wichtigsten Überlegungen für Entwickler, die diese in ihre Designs integrieren, erläutert.

3.2 Technische Einzelheiten

3.2.1 Überblick

Die SCI-Erweiterung (Shorter Connection Intervals) geht auf dieses Problem ein, indem sie das unterstützte Mindestintervall auf nur 375 µs mit einer feineren Auflösung von 125 µs reduziert. Um diese Änderung zu unterstützen, führt die Spezifikation mehrere wichtige Aktualisierungen ein:

Neue Link Layer Control PDUs: Wird verwendet, um die neuen, kürzeren Verbindungsintervalle auszuhandeln
Aktualisierte HCI-Befehle und -Ereignisse: Bietet dem Host eine bessere Kontrolle über die Verbindungsparameter
Mechanismus zum Austausch von Funktionen: Ermöglicht es den Geräten, die Unterstützung für die neue Fähigkeit anzuzeigen
Unterstützung von ACL-Daten mit Löschfunktion: Verhindert die Ansammlung veralteter Daten in Übertragungspuffern

Um die Verbindungsintervalle im Rahmen des neuen Modells effektiv zu verwalten, führt SCI einen dreistufigen Rahmen für die Aushandlung und Anwendung von Zeitparametern ein. Diese Werte sind:

Wert der Verbindung	Beschreibung	Verwendung
Grundlegende Verbindungsintervallwerte (BCV)	Standardverbindungsintervallbereich, wenn SCI nicht unterstützt wird.	7,5 ms und darüber, in Vielfachen von 1,25 ms.
Gerundete Verbindungsintervallwerte (RCV)	Obligatorischer Verbindungsintervallbereich, wenn SCI unterstützt wird.	1,25 ms und darüber, in Vielfachen von 1,25 ms.
Erweiterte Verbindungsintervallwerte (ECV)	Optionaler Erweiterungsbereich, der verfügbar ist, wenn SCI unterstützt wird. Diese Werte werden vom Peripheriegerät über die obere Schicht an die Zentrale übermittelt.	Ermöglicht Verbindungsintervalle unter 1,25 ms, bis zu 375 µs in 125-µs-Einheiten. Unterstützt auch Intervalle über 1,25 ms mit 125 μs Auflösung (z. B. 32 ms, was mit BCV nicht möglich ist).

3.2.2 Unterstützung und Verhandlung von Funktionen

Vor der Einleitung kürzerer Intervallverfahren tauschen die Geräte Informationen über Merkmale aus.

Neue Funktion Bits:

Kürzere Verbindungsintervalle - Controller-Unterstützung (an die Gegenstelle gesendet)
Kürzere Verbindungsintervalle - Host (an Peer gesendet, host)
LE Flushable ACL Datahost, wird nicht an die Gegenstelle gesendet)

Regeln:

Wenn beide Peers die Unterstützung kürzerer Intervalle ankündigen, können neue Link Layer PDUs verwendet werden
Andernfalls bleibt die Verbindung auf Baseline Connection Interval Values (BCV ≥ 7,5 ms, in Vielfachen von 1,25 ms) beschränkt.
Wenn LE Flushable ACL Data nicht gesetzt ist, kann der Host die Daten nicht als flushable markieren, und der Controller muss alle ACL-PDUs übertragen.

In der Praxis ergänzt die Funktion "flushable ACL data" kürzere Verbindungsintervalle, indem sie die Anhäufung von abgestandenem Datenverkehr bei steigenden Datenraten verhindert.

3.2.3 Neue Link Layer Control PDUs

Da die alte PDU LL_CONNECTION_UPDATE_IND für Anwendungen mit niedriger Latenz nicht flexibel genug ist, wurden zwei neue PDUs für die Aushandlung der Verbindungsrate geschaffen:

LL_CONNECTION_RATE_REQ - eine Anforderung mit einem vollständigen Vorschlag für neue Timing-Parameter (vom Peripheriegerät gesendet)
LL_CONNECTION_RATE_IND - eine Antwort, die die endgültigen Parameter bei einer bestimmten Ereignisanzahl bestätigt und durchsetzt Instant (wird immer von der Zentrale gesendet)

LL_CONNECTION_RATE_REQ - der "Vorschlag"
Diese PDU wird vom Peripheriegerät gesendet, um eine Aktualisierung vorzuschlagen. Sie enthält einen Bereich akzeptabler Verbindungsintervalle, minimale und maximale Subrate-Faktoren, eine maximale Peripherie-Latenz, eine erforderliche Anzahl kontinuierlicher aktiver Ereignisse nach der Datenübertragung, den Überwachungs-Timeout, eine bevorzugte Periodizität und bis zu vier Kandidaten-Anker-Offsets, die sich auf einen gegebenen Verbindungsereigniszähler beziehen.

Die Schlüsselsemantik ist:

Interval_Min / Interval_Max: Definiert den zulässigen Bereich für connInterval, ausgedrückt in 125 µs-Einheiten. Die Zentrale muss einen Wert innerhalb dieser Grenzen wählen.
SubrateFactorMin / SubrateFactorMax: Definieren Sie den zulässigen Bereich für den Subrate-Faktor. Diese Werte sind an die Latenzzeit gekoppelt: SubrateFactorMax × (Max_Latency + 1) ≤ 500.
Max_latency: Ausgedrückt in Form von Post-Subrate-Ereignissen. Unabhängig vom tatsächlich gewählten Subrate-Faktor.
FortsetzungsZahl: Die Mindestanzahl der nachfolgenden Ereignisse, die nach einem Datenereignis aktiv bleiben müssen. Dies ist nützlich für HID-ähnlichen Verkehr.
Zeitüberschreitung: Überwachungs-Timeout, ausgedrückt in Einheiten von 10 ms.
BevorzugtePeriodizität: Gibt an, dass das vorgeschlagene Intervall idealerweise ein Vielfaches dieses Wertes sein sollte (in Einheiten von 125 µs). Ein Wert von 0 bedeutet keine Präferenz.
ReferenceConnEventCount: Ein Referenzzähler, der für die Auswertung der angegebenen Offsets verwendet wird.
Offset0..Offset3: Bis zu vier mögliche Anker-Offsets (Auflösung 125 µs). Jeder muss eindeutig und gültig sein. Ein Wert von 0xFFFF zeigt an, dass der Offset unbenutzt ist.

Die Zentrale antwortet auf den Empfang dieser PDU entweder mit einer LL_CONNECTION_RATE_IND (Annahme und Abschluss) oder lehnt die Anfrage mit einer LL_REJECT_EXT_IND ab.

LL_CONNECTION_RATE_IND - die "Bestätigung und Durchsetzung"
Diese PDU wird von der Zentrale nur zur Bestätigung der endgültig gewählten Parameter gesendet. Das Feld Instant definiert den genauen Zähler des Verbindungsereignisses, bei dem die neuen Parameter wirksam werden.

Die wichtigsten Punkte sind:

Intervall: Das ausgewählte connInterval, das innerhalb des in der LL_CONNECTION_RATE_REQ angegebenen Bereichs liegen muss.
WinOffset (transmitWindowOffset): Der Offset, relativ zum alten Anker, des ersten Ereignisses nach dem Wechsel
Instant: Der Ereigniszähler definiert den Umschaltpunkt
SubrateFactor, Latenz, ContinuationNumber, Timeout: Die endgültigen Werte, die von der Zentrale angewendet werden

Das Peripheriegerät stellt die neuen Parameter im Augenblick ein. Beide Seiten müssen die Synchronisation aufrechterhalten, um einen nahtlosen Übergang zu gewährleisten.

3.2.4 Verfahren zur Ermittlung des Verbindungssatzes

Verfahren zur Aktualisierung der Verbindungsrate (zentralgesteuert):

Einleiten: Die Zentrale darf dieses Verfahren erst nach erfolgreichem Austausch von Leistungsmerkmalen einleiten und bestätigen, dass die Gegenstelle kürzere Verbindungsintervalle unterstützt (Host ). Es kann durch einen Host oder als Antwort auf eine Peripherieanforderung ausgelöst werden. Das Flussdiagramm ist in Abbildung 3.2.4a dargestellt.
Beschränkungen: Kann nicht gestartet werden, während andere Prozeduren (z.B. Connection Parameters Request, Subrate Request, oder CS-Prozeduren) laufen.
Ausführung:
- Die Zentrale wählt ein neues Intervall (nicht unterhalb des PHY-Minimums).
- Er sendet ein LL_CONNECTION_RATE_IND mit den gewählten Parametern.
- Der Instant definiert die Anzahl der Ereignisse für die Vermittlung. Beide Geräte müssen während des Zeitpunkts und des unmittelbar vorangehenden Ereignisses senden und hören, unabhängig von der Subrate.
- Nach dem Instant arbeiten beide Geräte mit dem neuen Intervall, der Latenz, der Subrate und dem Überwachungs-Timeout.
Transmit Window Offset: Das erste Paket mit den neuen Parametern kann um connIntervalOLD + transmitWindowOffset nach dem alten Anker verzögert werden, was eine Anpassung ermöglicht.
Beendigung: Das Verfahren ist abgeschlossen, wenn der Augenblick verstrichen ist und neue Parameter aktiv sind, oder wenn eine der beiden Seiten die PDU ablehnt. Der Überwachungszeitgeber wird am neuen Ankerpunkt zurückgesetzt.

Abbildung 3.2.4a Die Zentrale A ändert die Verbindungsrate

Verfahren zur Abfrage der Verbindungsrate (peripheriegesteuert):

Initiierung: Das Peripheriegerät kann eine LL_CONNECTION_RATE_REQ senden, um Änderungen vorzuschlagen, vorausgesetzt, dass sowohl der lokale als auch der Peer-Controller die Host ankündigen. Ein Host löst diese Aktion normalerweise aus. Ein typisches Beispiel für ein Flussdiagramm ist in Abbildung 3.2.4b unten dargestellt.
Restriktionen: Wie zentraler Fall - keine Überschneidungen mit Parameter- oder Teilratenanforderungsverfahren.
Ausführung:
- Das Peripheriegerät bereitet die Anforderung nach den Regeln vor, die für Parameteranforderungen (Intervall, Timeout, Offsets) und Subratenanforderungen (Subratenfaktor, Latenz und Fortsetzung) festgelegt wurden.
- Die Zentrale nimmt entweder an und antwortet mit LL_CONNECTION_RATE_IND oder lehnt mit LL_REJECT_EXT_IND ab.
Ablehnungsgründe:
- Controller Busy (0x3A) - wegen kollidierender laufender Verfahren
- Ungültige LL-Parameter (0x1E) - falsch geformte oder außerhalb des Bereichs liegende Felder
- Nicht unterstützter LL-Parameterwert (0x20) - gültig, aber nicht akzeptabel
- Nicht unterstützte Funktion oder Wert (0x11) - z. B. Intervall zu klein für die erforderliche PDU-Länge
Beendigung: Das Verfahren endet, wenn die Zentrale antwortet (annehmen oder ablehnen) und, im Falle der Annahme, wenn das anschließende Aktualisierungsverfahren abgeschlossen ist.

Abbildung 3.2.4b: Peripheriegerät B fordert eine Änderung der Verbindungsrate an, Zentrale A akzeptiert dies

3.2.5 Verbindungsintervallbereiche und die Rolle bei Verfahren der Verbindungsschicht

Wenn ein Peripheriegerät eine LL_CONNECTION_RATE_REQ sendet oder wenn eine Zentrale mit einer LL_CONNECTION_RATE_IND antwortet, sind die intervallbezogenen Felder in diesen PDUs keine beliebigen Werte. Sie müssen aus wohldefinierten Gruppen von Verbindungsintervallwerten (BCV, RCV und ECV) ausgewählt werden, die die Spezifikation aus Gründen der Kompatibilität und der Klarheit der Implementierung einführt.

Die Relevanz der in Abschnitt 2.1 erwähnten Bereiche von BCV, RCV und ECV wird deutlich, wenn man die neuen LL-PDUs interpretiert:

In einer LL_CONNECTION_RATE_REQ müssen die Felder Interval_Min und Interval_Max gültige ECV-Werte sein, wodurch der flexibelste Bereich ausgedrückt wird.
In einem LL_CONNECTION_RATE_IND muss das gewählte Intervall auf einen für beide Seiten akzeptablen Wert zurückgeführt werden. Wenn die Gegenstelle nur RCV unterstützt, muss die Zentrale ihre Auswahl entsprechend einschränken.

Dieser mehrschichtige Ansatz gewährleistet, dass SCI eingeführt werden können, ohne die Interoperabilität zu beeinträchtigen: Steuergeräte, die nur BCV-Werte verstehen, werden weiterhin interoperabel sein. Steuergeräte, die die SCI-Funktion unterstützen, müssen RCV als obligatorische Mindestwerte für diese Funktion unterstützen, während fortgeschrittene Geräte die volle Auflösung von ECV nutzen können. Darüber hinaus sind ECV-Werte optional, und das zentrale Gerät erfährt über die obere Schicht, ob ein Peripheriegerät ECV unterstützt.

Kurz gesagt, BCV gewährleistet die Abwärtskompatibilität, RCV schafft ein Gleichgewicht zwischen Legacy-Anpassung und Flexibilität, während ECV die volle Auflösung für Anwendungen mit extrem niedriger Latenz ermöglicht.

3.2.6 HCI-Unterstützung für kürzere Verbindungsintervalle

An der Host (HCI) werden mehrere neue Primitive eingeführt, um die Steuerung Host und die Sichtbarkeit der SCI-Funktion zu ermöglichen. Diese Befehle und Ereignisse spiegeln die neuen Link-Layer-Prozeduren wider, wobei die Low-Level-Details, wie Offset-Listen und Instanten, weggelassen werden.

HCI_LE_Connection_Rate_Request (Befehl)
Ermöglicht es dem Host , eine Änderung der Verbindungsparameter anzufordern, die die Steuerung in eine LL_CONNECTION_RATE_REQ an die Gegenstelle (im Falle einer von der Peripherie initiierten Verbindung) oder LL_CONNECTION_RATE_INS (im Falle einer von der Zentrale initiierten Verbindung) umsetzt
HCI_LE_Set_Default_Rate_Parameters (Befehl)
Ermöglicht dem zentralen Host die Vorkonfiguration von Standard-Verbindungsratenparametern für neue Verbindungen, wodurch die Notwendigkeit vermieden wird, jede Verbindung einzeln neu zu konfigurieren
HCI_LE_Read_Minimum_Supported_Connection_Interval (Befehl)
Ermöglicht dem Host die Abfrage des minimalen Intervalls und der Auflösung, die von der Steuerung unterstützt werden, was für Anwendungen, die eine Leistung im Bereich von unter einer Millisekunde erfordern, unerlässlich ist
LE-Verbindungsratenänderung (Ereignis)
Benachrichtigt den Host , wenn eine Ratenaktualisierung entweder erfolgreich (mit dem angewendeten Intervall, der Latenzzeit und dem Überwachungs-Timeout) oder erfolglos (mit einem Fehlerstatus) abgeschlossen wurde.

Diese Primitive zusammen geben dem Host die Möglichkeit, SCI auf flexible, aber abstrakte Weise anzufordern, zu überwachen und zu konfigurieren, während die detaillierte Aushandlung bei der Steuerungs- und Verbindungsschicht verbleibt.

3.2.7 ACL-Spülmechanismus

Wenn die Verbindungsintervalle kürzer werden, können sich veraltete Daten schnell in den Puffern des Controllers ansammeln. Um zu verhindern, dass veralteter Datenverkehr neuen Datenverkehr blockiert, kann der Host bestimmte ACL-Daten als "flushable" kennzeichnen.

Um den Unterschied zwischen bündelbaren und nicht bündelbaren ACL-Daten schnell zu verstehen, veranschaulichen die folgenden beiden Abbildungen den Unterschied.

Spülbarer ACL-Datenkoffer:

In Abbildung 3.2.7a sind die Datenpakete mit einer ACL Flush Timeout konfiguriert. Wenn eine Verzögerung auf der Verbindungsschicht auftritt (z. B. wenn Paket 3 erneut übertragen wird), werden die Pakete in der Warteschlange (wie die Pakete 4 und 5), die länger als die eingestellte Zeitüberschreitung im Puffer verbleiben, geleert. Durch dieses Verhalten wird vorrangig sichergestellt, dass die Daten im Übertragungskanal frisch sind, anstatt zu garantieren, dass jedes einzelne Paket erfolgreich zugestellt wird.

Abbildung 3.2.7a: Beispiel für einen Host , der bündelbare Daten an den Controller sendet

Nicht spülbarer ACL-Datenkoffer:

In Abbildung 3.2.7b sind die Datenpakete nicht mit einem Timeout konfiguriert, oder das Timeout ist auf unendlich eingestellt. Wenn eine Verzögerung auf der Verbindungsschicht auftritt, verbleiben diese Datenpakete (wie 4 und 5) in der Warteschlange. Sie werden erst gesendet, wenn das alte Paket (Paket 3) erfolgreich übertragen und quittiert wurde. Durch dieses Verhalten wird sichergestellt, dass alle Datenpakete übertragen werden, wodurch die Datenintegrität und -zuverlässigkeit Vorrang erhält.

Abbildung 3.2.7b: Beispiel eines Host , der Daten, die nicht flushbar sind, an den Controller sendet

Lassen Sie uns nun die einzelnen Schritte für das Flushing von ACL-Daten vom Host zum Controller durchgehen.

Der Host markiert das erste Fragment einer L2CAP-PDU als bündig, wenn er sie über HCI sendet. Dies wird durch das Packet_Boundary_Flag im Header des ACL-Datenpakets angezeigt. Nur solche PDUs kommen für das Flushing in Frage.
Der Controller unterhält einen Flush-Timeout für jede logische ACL-Verbindung. Dieser Timer beginnt, wenn das erste Fragment eines flushbaren ACL-U-Pakets gespeichert wird.
Läuft die Flush-Zeitüberschreitung ab, bevor ein Fragment der PDU übertragen wurde, verwirft die Steuereinheit alle Fragmente dieser PDU, einschließlich etwaiger noch ankommender Fortsetzungsfragmente. Die Basisband-Warteschlangen werden ebenfalls von den verbleibenden Segmenten befreit.
Nach dem Flushing wird das nächste ACL-U-Paket normal verarbeitet. Die folgende übertragene PDU enthält immer eine L2CAP-Startanzeige (LLID = 10), die es der Gegenstelle ermöglicht, Methoden der oberen Schicht wie Zähler oder Zeitstempel zu verwenden, wenn sie fehlende Anwendungsnutzdaten erkennen muss.
Wird ein Teil der PDU vor der Zeitüberschreitung gesendet, wird der Flush-Timer abgebrochen, und das Paket wird normal zugestellt.
Standardmäßig ist der Flush-Timeout unendlich, d. h. Pakete werden nie geflusht, es sei denn, es ist ausdrücklich anders konfiguriert.

Host :

Der Host konfiguriert die Zeitüberschreitung für den Flush pro Link mit der Option HCI_Write_Automatic_Flush_Timeout Befehl
- Ein Wert von 0x0000 bedeutet unendlich (keine Spülung)
- Ein endlicher Wert N entspricht einem Timeout von N × 0,625 ms
Bei Beendigung des Befehls erzeugt der Controller ein Standardbefehlsabschlussereignis

Dieser Mechanismus stellt sicher, dass neuer Datenverkehr zeitnah zugestellt werden kann und nicht durch veraltete Pakete verzögert wird, was besonders für Anwendungen mit geringer Latenz wichtig ist.

3.3 Zusammenfassung

Die SCI-Funktion stellt einen bedeutenden Fortschritt für Bluetooth® LE dar. Durch die Verringerung des Mindestintervalls auf 375 µs mit einer feinkörnigen Auflösung von 125 µs ermöglicht sie Anwendungen der nächsten Generation, die eine extrem niedrige Latenzzeit erfordern, wie z. B. Hochleistungs-Gaming-Peripheriegeräte und immersive VR/AR-Controller.

Die Einführung neuer Link-Layer-PDUs, robuster Verhandlungsverfahren und aktualisierter HCI-Befehle bietet einen umfassenden Rahmen für die Verwaltung der Datenübertragung mit hoher Rate. Der ACL-Flush-Mechanismus verbessert die Reaktionsfähigkeit, indem er verhindert, dass veraltete Pakete neue Übertragungen blockieren.

Zusammen stellen diese Innovationen sicher, dass Bluetooth® LE die strengen Latenzanforderungen moderner Technologien erfüllen kann und gleichzeitig die volle Abwärtskompatibilität beibehält.

4. Bluetooth® Channel Sounding Amplituden-basierte Angriffsresistenz

4.1 Hintergrund

4.1.1 Channel Sounding

Bluetooth® Channel Sounding ist eine sichere Feinabstimmungsfunktion in der Bluetooth® Core Specification, die sichere und präzise Entfernungsmessungen zwischen Bluetooth-Geräten ermöglichen soll. Durch die Nutzung der physikalischen Eigenschaften von Funksignalen wird die RSSI-Methode (Received Signal Strength Indicator) deutlich verbessert und bietet eine Genauigkeit im Zentimeterbereich. Es kombiniert phasenbasiertes Ranging (PBR) für hochpräzise Messungen mit Round-Trip-Time (RTT) als Sicherheitsmaßnahme gegen Relais-Angriffe. Dieser Zwei-Methoden-Ansatz verbessert sowohl die Präzision als auch die Sicherheit von Entfernungsmessungen zwischen Bluetooth®-verbundenen Geräten.

4.1.2 Normalisierte Angriffsdetektor-Metrik

Um die Integrität der Entfernungsmessung zu gewährleisten, definiert die Bluetooth® Core Specification die Normalized Attack Detector Metric (NADM), eine gleitende Skala, die die Wahrscheinlichkeit eines Angriffs angibt und von extrem unwahrscheinlich bis extrem wahrscheinlich reicht. Anstatt einen festen Algorithmus vorzuschreiben, bietet die Spezifikation einen flexiblen Rahmen, der auf der Auswertung von CS_Sync-Paketen auf Anomalien, wie unerwartete Bitübergänge oder Phasenwechsel, basiert. Die Controller erzeugen NADM-Werte und melden sie über Host Controller Interface (HCI)-Ereignisse an den host , so dass die Benutzeranwendung eine Bedrohungsanalyse durchführen kann.

4.1.3 Frühzeitige Commit-Range-Angriffe

Ein Early-Commit-Angriff ist eine Art von Entfernungsangriff, bei dem die Phase eines Signals manipuliert wird, um dem Empfänger eine frühere Ankunftszeit als die des legitimen Signals vorzugaukeln. Dieser Angriff erfolgt durch Einspeisung eines manipulierten Signals mit einer angepassten Phase. Dies könnte zum Beispiel durch einen Gaußschen Monopuls erreicht werden, der am Anfang jedes Symbols hinzugefügt wird. Die Manipulation verursacht eine Phasenverzerrung, die zu einer kürzeren berechneten Entfernung führt und einen Man-in-the-Middle-Angriff (MITM) ermöglicht. Um solche Angriffe zu erkennen, werden Methoden wie die normalisierte Kreuzkorrelation und der minimale quadratische Phasenfehler verwendet, um die Phase des empfangenen Signals mit einer Referenz zu vergleichen und anomale Phasenschwankungen zu identifizieren.

4.1.4 Die Entwicklung der Early-Commit-Range-Angriffe

Die sich entwickelnde Landschaft der Sicherheitsbedrohungen machte eine Erweiterung des NADM-Rahmens erforderlich. Es wurde eine neue Klasse von Angriffen identifiziert, die eine amplitudenbasierte Signalmanipulation ausnutzen. Wie die phasenbasierten Angriffe zielen auch diese darauf ab, einen Early-Commit-Effekt hervorzurufen, allerdings durch Ausnutzung der Amplituden-Phasen-Umwandlung im Empfänger. Diese neue Ausfallsicherheitsfunktion ist eine direkte Reaktion auf diese Bedrohungen und stellt eine wichtige Erweiterung der bestehenden NADM-Funktionen dar, die speziell auf Amplituden-basierte Angriffe auf Bluetooth® Channel Sounding RTT-Pakete abzielen und diese abschwächen.

4.2 Technische Einzelheiten

4.2.1 Überblick

Der Kernmechanismus eines amplitudenbasierten Angriffs besteht darin, die nichtlineare Reaktion des Frontends eines Empfängers auszunutzen. Der Angreifer wendet ein periodisches Verstärkungsprofil auf das legitime Signal an, das genau mit dem Symboltaktraster der Kommunikation synchronisiert ist. Diese kontrollierte Amplitudenmanipulation führt zu einer vorhersehbaren Phasenverzerrung im Empfänger, die das wahrgenommene Signal-Timing effektiv nach vorne verschiebt und zu einer erweiterten Timing-Messung führt.

Die neueste Bluetooth® Core Spezifikation (Bluetooth® Core 6.2) führt eine auf der diskreten Fourier-Transformation (DFT) basierende Methode zur Erkennung dieser Angriffe ein. Dieser Ansatz wurde gewählt, weil ein vorhersehbarer Amplitudenangriff, der mit der Symboldauer korreliert, sich als deutliche, quantifizierbare Energiespitzen im Frequenzbereich manifestiert. Diese Spitzen treten bei oder in der Nähe der 1-fachen und 2-fachen Symbolfrequenz auf. Durch die Messung der Energie in diesen spezifischen Frequenzbereichen und den Vergleich mit der Gesamtenergie des Signals kann die DFT-Metrik den Angriff zuverlässig erkennen. Diese Methode ist robuster als alternative Ansätze (z. B. eine stabile Hüllkurvenmetrik ), da sie speziell auf die periodische Natur des Angriffs abzielt und falsch positive Ergebnisse aufgrund zufälliger, unkorrelierter Amplitudenschwankungen vermeidet.

4.2.2 Definition des Angriffssignals und parametrisierte Anforderungen

Das amplitudenbasierte Angriffssignal wird durch Modulation des legitimen Signals erzeugt, mit einem sich wiederholenden Amplifikationsmuster-Term, die die gleiche Periode wie die Symbolperiode des Datenpakets hat, . Der Angreifer muss zunächst das Zeitraster des Symbols des Opfers schätzen. Dann wendet er ein periodisches Verstärkungsprofil an, die eine Summierung des sich wiederholenden Terms ist, auf das legitime Signal. Für die Prüfung und Charakterisierung wird ein vereinfachtes Rechteckwellen-Angriffsmodell verwendet, wie in Abbildung 4.2.2 dargestellt. Das Angriffssignal wird dann durch die folgende Gleichung beschrieben: = ⋅ .

Abbildung 4.2.2: Wellenformen zur Darstellung des Verhältnisses von und

für die Rechteckwelle mit einer Frequenz, die der Symbolfrequenz des legitimen Signals entspricht, wird durch den folgenden Pseudocode definiert.

Dieses Modell wird durch drei Schlüsselparameter definiert, die einen 3D-Suchraum für die Tests bilden. Diese Parameter werden während der Tests systematisch untersucht, um die effektivsten Angriffskonfigurationen für ein bestimmtes Gerät zu ermitteln. Sie sind in der folgenden Tabelle aufgeführt:

Parameter	Definition	Bereich	Index Bereich
_Po	Zeitlicher Versatz des Beginns des Angriffsmusters relativ zum Symbolbeginn als Bruchteil von _Tsym	0,03125 bis 0,96875 in Schritten von 0,0625	[1, 16]
DC	Tastverhältnis des Verstärkers bei Impuls als Bruchteil von _Tsym	0,03125 bis 0,96875 in Schritten von 0,0625	[1, 16]
_Ag	Skalierungsfaktor der Verstärkung, wobei 1,0 das ursprüngliche Signal darstellt.	2.0, 1.9, 1.8, 1.7, 1.6, 1.5, 1.45, 1.4, 1.35, 1.3, 1.275, 1.25, 1.225, 1.2, 1.175, 1.15, 1.125, 1.1, 1.075, 1.05	[1, 20]

Im Allgemeinen wird die Kombination aus Offset () und Einschaltdauer () bestimmen, ob der Attack das Timing vorverlegt, während die Verstärkung () steuert das Ausmaß des zeitlichen Vorlaufs.

4.2.3 Erkennungsmechanismus: Die DFT-Metrik

Die DFT-Metrik ist ein quantitatives Maß, mit dem das Vorhandensein eines periodischen Amplitudenangriffs durch Analyse des Signals im Frequenzbereich erkannt werden kann. Das Grundprinzip besteht darin, dass die Energie eines Angriffs ausreichend mit der Symbolperiode korreliert sein muss, um wirksam zu sein. Diese Korrelation führt zu deutlichen Energiespitzen im Frequenzbereich bei oder in der Nähe der Grund- und Oberwellenfrequenzen der Symbolrate.

Was ist die DFT-Korrelation? Die DFT (Diskrete Fourier-Transformation) ist ein mathematisches Werkzeug, das ein Signal aus dem Zeitbereich (wie es sich im Laufe der Zeit verändert) in den Frequenzbereich (die Stärke seiner verschiedenen Frequenzkomponenten) umwandelt. In diesem Zusammenhang bezieht sich die DFT-Korrelation auf das Ergebnis der DFT - eine Reihe von Koeffizienten, die jeweils die Intensität und Phase einer bestimmten Frequenzkomponente des Signals darstellen. Je höher die Korrelation bei einer bestimmten Frequenz ist, desto stärker ist diese Frequenzkomponente im Signal vorhanden.
Wie sie sich auf den Angriff auswirkt: Da der Amplitudenangriff ein periodisches Muster ist, das genau mit der Symbolperiode des Datenpakets synchronisiert ist, erzeugt er einen eindeutigen Fingerabdruck im Frequenzbereich. Dieser Fingerabdruck erscheint als vorhersehbare Energiespitzen bei der Symbolfrequenz (_f1=1/Tsym) und ihren Oberwellen (_f2=2/Tsym)

Die DFT-Metrik macht sich dieses Prinzip zunutze. Sie berechnet das Verhältnis der kombinierten Energie bei diesen spezifischen Angriffsfrequenzen (und ) auf die Energie der Gleichstromkomponente des Signals (Nullfrequenz). Die Referenzformel lautet:

wo:

φ(_f1) und φ(_f2) sind die DFT-Korrelationen bei der Symbolfrequenz(_f1) und der doppelten Symbolfrequenz(_f2)
φ(0) ist die DFT-Korrelation bei der Gleichstromkomponente

Ein höherer Wert der DFT-Metrik weist auf eine größere Wahrscheinlichkeit eines Angriffs hin, da er ein ausgeprägteres Vorhandensein der für einen Amplitudenangriff charakteristischen periodischen Töne bedeutet. Diese Metrik bietet eine robuste Methode zur zuverlässigen Erkennung von Manipulationen, die auf der Amplitude basieren.

4.2.4 Anforderungen an die Charakterisierung

Bevor die tatsächliche Detektionsfähigkeit getestet wird, muss das zu prüfende Gerät (Instrument Under Test, IUT) zunächst charakterisiert werden, um seine Manipulationsanfälligkeit zu bestimmen. Dieser Prozess identifiziert die spezifischen Kombinationen von , und die das Verhalten des Empfängers am effektivsten beeinflussen. Der Charakterisierungsprozess umfasst die folgenden Schritte:

Anfängliche Datenerfassung: Ein Prüfgerät, das als Initiator fungiert, setzt eine anfängliche Verstärkerverstärkung A_g auf einen hohen Wert. Dann führt es systematisch eine Prozedur für jede Kombination von Tastverhältnis(DC) und Zeitversatz(p_d) durch und zeichnet den zeitlichen Verlauf des Signals auf. Mit diesem Verfahren soll eine Karte der Angriffswirksamkeit erstellt werden.
Datenglättung: Um das zufällige Messrauschen abzuschwächen, wird ein räumlicher Filter auf die Rohdaten angewendet, um sie zu glätten. Dieser Schritt stellt sicher, dass die ermittelten effektiven Angriffspunkte echt sind und nicht auf zufällige Messfehler zurückzuführen sind.
Suche nach lokalen Minima: Das Prüfgerät sucht dann nach lokalen Minima in den geglätteten Daten. Diese Punkte stellen die Parameterkombinationen dar, bei denen der Angriff den größten zeitlichen Vorsprung verursacht hat. Solche Punkte von Interesse werden als die aggressivsten Angriffskonfigurationen betrachtet und aufgezeichnet.
Inkrementelle Verstärkungsreduktion und Bestimmung der Wirksamkeit: Für jeden identifizierten interessierenden Punkt führt das Prüfgerät einen inkrementellen Test durch. Er reduziert schrittweise die Verstärkung des Verstärkers(A_g) und wendet bei jedem Schritt eine statistische Methode, den so genannten Z-Test, an, um festzustellen, ob der Angriff noch wirksam ist. Die Kernidee besteht darin, den durchschnittlichen zeitlichen Vorsprung des Angriffssignals mit dem Durchschnitt eines legitimen Signals zu vergleichen, um festzustellen, ob der Unterschied statistisch signifikant ist (d. h. größer als 10 ns). Wenn der Unterschied groß genug ist, gilt die Angriffskonfiguration als wirksam, bis die Verstärkung so weit reduziert ist, dass sie keinen signifikanten Unterschied mehr verursacht.

Die Parameter aller in der Charakterisierungsphase identifizierten Points of Interest werden in einer Schlüsseldatenstruktur gespeichert, die als Grundlage für die Prüfung der nachfolgenden Erkennungsanforderungen dient.

4.2.5 Anforderungen an die Erkennung

Die letzte Phase des Prozesses beinhaltet die Verifizierung der NADM-Leistung des Prüflings durch obligatorische Tests. Dieser Abschnitt beschreibt, wie die NADM-Implementierung eines Prüflings getestet wird, um festzustellen, ob sie effektiv zwischen legitimen und amplitudenbasierten Angriffssignalen unterscheiden kann.

Testverfahren: Das IUT wird mit verschiedenen PHYs (LE 1M, LE 2M, LE 2M 2BT) und RTT-Stufentypen (Mode-1, Mode-3) getestet, wobei die effektivsten Angriffsparameter verwendet werden, die während der Charakterisierung gefunden wurden. Bei jedem Test wird eine zufällige Folge von legitimen und vom Angreifer modulierten Signalen in zufälliger Reihenfolge gesendet.
Leistungsschwelle: Der Prüfling muß das Vorhandensein oder Nichtvorhandensein eines Angriffs mit einem hohen Maß an Zuverlässigkeit korrekt erkennen. Für jeden Test müssen mindestens 90 Prozent der vom IUT gemeldeten NADM-Werte korrekt wiedergeben, ob es sich um ein normales Signal oder einen Angriff handelt. Wird dieser Schwellenwert nicht erreicht, gilt der Test als nicht bestanden, wodurch sichergestellt wird, dass die endgültige zertifizierte Implementierung gegen diese spezifischen Bedrohungen robust ist.

4.2.6 HCI- und Link-Layer-Updates für Channel Sounding Angriffsresilienz

HCI- und Link-Layer-Updates für Channel Sounding Amplitude-based Attack Resilience
Zur Unterstützung der neuen Amplituden-basierten NADM-Funktionen wurden das Bluetooth® Host Controller Interface (HCI) und der Link-Layer (LL) aktualisiert, damit Geräte mit diesen Sicherheitsfunktionen kommunizieren und darauf reagieren können.

HCI-Updates
Neue Parameter wurden zu bestehenden HCI-Befehlen und -Ereignissen hinzugefügt, um die amplitudenbasierte NADM-Unterstützung zu verwalten:

LE CS Read Remote Supported Capabilities Complete Ereignis: Enthält jetzt Bits, die angeben, ob ein entferntes Gerät die amplitudenbasierte Angriffserkennung sowohl für klingende als auch für zufällige Sequenzen unterstützt
LE CS Befehl Read Local Supported Capabilities: Ermöglicht einem host die Abfrage der amplitudenbasierten NADM-Fähigkeiten seines Controllers
LE CS Befehl Cached Remote Supported Capabilities schreiben: Ermöglicht einem host , die Fähigkeiten eines entfernten Geräts zwischenzuspeichern, um den Verbindungsprozess zu optimieren.

Diese Aktualisierungen ermöglichen die dynamische Aushandlung von Fähigkeiten und die Wahrnehmung zwischen Geräten.

Aktualisierungen der Verbindungsschicht (LL)
Die LL_CS_CAPABILITIES_REQ/RSP PDUs (Protocol Data Units) wurden aktualisiert und enthalten nun ein Bit, das die Unterstützung für die amplitudenbasierte NADM-Funktion anzeigt. Dies ermöglicht es den Geräten, ihre Sicherheitsfunktionen direkt auf der Verbindungsschicht während der Initialisierung des Bluetooth® Channel Sounding zu koordinieren.

4.3 Zusammenfassung

Die Einführung der amplitudenbasierten Angriffsresistenz stärkt die Sicherheitsfähigkeiten von Bluetooth® Channel Sounding. Durch die Definition eines präzisen Angriffsmodells, einer robusten DFT-basierten Erkennungsmetrik und eines gründlichen mehrstufigen Testverfahrens stellt die Spezifikation sicher, dass zertifizierte Geräte ausgeklügelte Versuche zur Manipulation von Entfernungsmessungen zuverlässig erkennen können. In Verbindung mit den notwendigen Aktualisierungen der HCI- und Link-Layer-Protokolle bietet diese Erweiterung einen umfassenden Rahmen für die Eindämmung dieser sich entwickelnden Bedrohung. Sie spiegelt das Engagement der Bluetooth®-Technologie für eine kontinuierliche Verbesserung der Sicherheit wider und stellt sicher, dass die präzise Entfernungsmessung angesichts neuer Herausforderungen sowohl genau als auch vertrauenswürdig bleibt.

5. Bluetooth® HCI USB LE Isochronous-Unterstützung

5.1 Hintergrund

Im Jahr 2022 wurde die Bluetooth®-Technologie um Unterstützung für isochrone Datentransporte, Connected Isochronous Streams (CIS) und Broadcast Isochronous Streams (BIS) erweitert. Die Marktnachfrage nach USB-basierten isochronen Kommunikationsfunktionen veranlasste die Bluetooth SIG zur Entwicklung der HCI USB LE Isochronous Support-Funktion.

Traditionell definierte die HCI-USB-Transportschicht Endpunkte für ACL-, Befehls-, Ereignis- und SCO/eSCO-Datenverkehr. Es gab jedoch keine standardisierte Methode für die Übertragung von LE Isochronous Traffic über USB. Diese Lücke führte zu Interoperabilitätsproblemen, fragmentierten Implementierungen und erforderte in einigen Fällen, dass Anbieter benutzerdefinierte USB-Endpunkte definierten oder LE-ISO-Verkehr über Massenendpunkte auf nicht standardisierte Weise multiplexten.

Um dieses Problem zu lösen, wurde ein neuer Betriebsmodus namens Bulk Serialization Mode eingeführt. Dieser Ansatz bietet eine einheitliche, standardisierte Methode für die Übertragung von LE-Isochronous-Datenströmen und ist für eine breite Kompatibilität mit bestehenden USB-Controllern ausgelegt, was dazu beiträgt, die Markteinführung neuer Produkte zu beschleunigen.

5.2 Technische Einzelheiten

5.2.1 Legacy-Modus vs. Bulk-Serialisierungsmodus

Die USB-Transportschicht eines Bluetooth® Controllers kann in einem von zwei Modi arbeiten: Legacy Mode und Bulk Serialization Mode. Alle Implementierungen der USB-Transportschicht müssen den Legacy-Modus unterstützen, während die Unterstützung des Bulk-Serialisierungsmodus optional ist.

Legacy-Modus: Dies ist der traditionelle Modus, in dem verschiedene Host Controller Interface (HCI)-Paketarten über dedizierte USB-Endpunkte übertragen werden. Insbesondere verwenden HCI-Befehle den Kontroll-Endpunkt, HCI-Ereignisse den Interrupt-Endpunkt, ACL-Daten verwenden Bulk-Endpunkte und SCO/eSCO-Daten verwenden isochrone Endpunkte. Eine wesentliche Einschränkung dieses Modus ist das Fehlen eines standardisierten Mechanismus für den Austausch von Daten über LE Isochronous Channels.
Bulk-Serialisierungsmodus: Dieser optionale Modus behebt die Einschränkungen des Legacy-Modus, indem er alle HCI-Pakete - einschließlich HCI-ISO-Datenpakete - auf Bulk-Endpunkte konsolidiert. Dieser Ansatz maximiert die Kompatibilität mit einer Vielzahl von bestehenden USB-Controllern und bietet gleichzeitig wesentliche Unterstützung für LE Isochronous Channels.

5.2.2 Betriebsartenumschaltung und Reglerverhalten

Ein präzises Verfahren ermöglicht es dem Host , den Controller anzuweisen, in den neuen Modus zu wechseln. Dieser Mechanismus macht sich ein Schlüsselkonzept der USB-Spezifikation zunutze: die alternative Einstellung. Eine einzelne USB-Schnittstelle kann mehrere alternative Einstellungen unterstützen, die jeweils einen bestimmten Betriebsmodus oder eine bestimmte Konfiguration darstellen.

Anzeige der Unterstützung: Ein Controller, der den Bulk-Serialisierungsmodus unterstützt, signalisiert diese Fähigkeit durch die Aufnahme einer zusätzlichen alternativen Einstellung (alternative Einstellung 1) in die erste Schnittstelle seines USB-Konfigurationsdeskriptors. Diese alternative Einstellung enthält nur Bulk-Endpunkte und unterscheidet sich damit von der Standardeinstellung für den Legacy-Modus (normalerweise alternative Einstellung 0).
Umschaltbefehl: Der Host weist den Controller an, in den Bulk-Serialisierungsmodus zu wechseln, indem er eine Standard-USB-Select-Schnittstellenanforderung ausgibt, um diese spezielle alternative Einstellung zu aktivieren. Dadurch kann der Host den Betriebsmodus der Schnittstelle dynamisch ändern, nachdem das Gerät angeschlossen wurde.

Die Verwendung einer alternativen Einstellung für die Betriebsartumschaltung gilt als zuverlässiger als frühere Vorschläge, die auf USB-Steuerungsübertragungen beruhen, da sie die Kompatibilitätsrisiken mit bestehenden Steuergeräten verringern.

5.2.3 Paketmultiplexing und Identifizierung

Im Bulk-Serialisierungsmodus wird der gesamte HCI-Verkehr auf dieselben Bulk-Endpunkte gemultiplext, so dass ein Mechanismus zur Unterscheidung der Pakettypen erforderlich ist. Dies wird erreicht, indem jedem HCI-Paket ein Ein-Byte-HCI-Paketindikator vorangestellt wird.
In der folgenden Tabelle sind die Indikatoren für die einzelnen HCI-Paketarten aufgeführt:

HCI-Paket Typ	HCI-Paket-Indikator
HCI-Befehlspaket	0x01
HCI ACL Datenpaket	0x02
HCI Synchrone Datenpakete	0x03
HCI-Event-Paket	0x04
HCI-ISO-Datenpaket	0x05
Reserviert für zukünftige Verwendung	Alle anderen Werte

Dieses System ermöglicht es der empfangenden Seite, den Datenstrom genau zu analysieren und jedes Paket an den entsprechenden Handler weiterzuleiten, was die effiziente Übertragung mehrerer HCI-Datentypen über eine einzige Schnittstelle ermöglicht.

5.2.4 Behandlung von Wettlaufbedingungen und Verbesserung der Robustheit

Der neue Modus ermöglicht nicht nur Bluetooth® LE Audio, sondern behebt auch eine hartnäckige Wettlaufsituation in der Legacy-USB-Transportschicht. Im Legacy-Modus werden verschiedene Endpunkttypen in einer bestimmten Reihenfolge innerhalb eines USB-Frames bedient, was dazu führen kann, dass Daten und Ereignisse nicht in der richtigen Reihenfolge zugestellt werden. So kann ein Host beispielsweise ein Datenpaket vor dem Ereignis empfangen, das seine Ankunft signalisiert. Dieses Verhalten kann kritische Prozesse wie den Verbindungsaufbau, die Trennung der Verbindung und die Datenverschlüsselung stören, was sich negativ auf das Benutzererlebnis auswirkt.

Der Bulk-Serialisierungsmodus beseitigt dieses Problem effektiv, indem er alle HCI-Pakete in einem einzigen Bulk-Endpunkt zusammenfasst. Da die Daten als ein einziger, geordneter Strom übertragen werden, wird die Robustheit von Bluetooth®-Anwendungen erheblich verbessert.

5.3 Zusammenfassung

Das Update der Bluetooth® Core Specification führt mit der Definition des Bulk Serialization Mode eine wichtige Verbesserung der USB-Transportschicht ein. Dieser neue Modus bietet eine standardisierte, abwärtskompatible Methode für die Übertragung von LE Isochronous Streams (wie Bluetooth® LE Audiodaten) über USB. Durch die Konsolidierung aller HCI-Paketarten auf Bulk-Endpunkte und die Verwendung eines einfachen Paketindikators löst der aktualisierte Standard Wettlaufbedingungen auf, verbessert die Zuverlässigkeit und gewährleistet einen robusten Kommunikationskanal zwischen dem Bluetooth® Host und dem Controller. Diese Verbesserungen bilden die Grundlage für erweiterte Audio- und Datenanwendungen in modernen Bluetooth®-Geräten.

6. Erweiterungen des Bluetooth® LE

6.1 Hintergrund

6.1.1 PHY-Test und Direkttestmodus

Die Bluetooth® LE definiert Tests der physikalischen Schicht (PHY), um sicherzustellen, dass die Interoperabilität der Geräte und die Leistungskriterien erfüllt sind. Diese Tests, die Aspekte wie die Leistung des Senders, die Empfindlichkeit des Empfängers und neue Funktionen wie Bluetooth® Channel Sounding abdecken, sind für die Konformität und Qualitätssicherung unerlässlich. In der Vergangenheit war die primäre Methode für die Kontrolle und den Test des Funkgeräts eines LE-Geräts die Verwendung des Direct Test Mode (DTM).

DTM arbeitet über eine physikalische Transportschnittstelle zwischen dem Testgerät (dem Upper Tester) und der zu testenden Implementierung (IUT). Diese Schnittstelle ist typischerweise entweder ein Host Controller Interface (HCI) oder ein 2-Draht-UART, wie in Abbildung 1.1 dargestellt. Der Tester sendet standardisierte Befehle und empfängt entsprechende Ereignisse, um das Funkgerät des IUT für Konformitätstests zu steuern. Beispielsweise werden Befehle wie LE_Transmitter_Test und LE_Receiver_Test verwendet, um das IUT in einen Sende- oder Empfangszustand zu versetzen, während Ereignisse wie LE_Packet_Report eine Rückmeldung über die Testergebnisse liefern.

Abbildung 6.1.1 Setup-Alternativen für RFPHY-Testmodi

Diese Methode funktioniert während der design und Entwicklungsphase gut, wenn ein physischer E/A-Anschluss zur Verfügung steht. Eine erhebliche Einschränkung ergibt sich jedoch, sobald die Bluetooth® LE in ein Endprodukt integriert ist. In diesem Zustand ist die physische Steuerungsschnittstelle oft nicht mehr zugänglich, was die Möglichkeiten für Konformitätstests nach der Produktion oder Over-the-Air (OTA) stark einschränkt. Darüber hinaus kann das Vorhandensein einer kabelgebundenen Verbindung manchmal die HF-Eigenschaften des Geräts beeinflussen, was die Testergebnisse verfälschen kann.

6.1.2 Der Übergang zu einem einheitlichen Testprotokoll

Um die Einschränkungen von DTM zu beseitigen, führt die Bluetooth® Core Spezifikation das Unified Test Protocol (UTP) ein. Dieser neue Testmodus ist als gleichwertige Alternative zu DTM konzipiert, mit dem entscheidenden Vorteil, dass er einen OTA-Transport unterstützt und damit die Abhängigkeit von einer physikalischen Steuerschnittstelle eliminiert. UTP ermöglicht HF-PHY-Tests, die denen mit DTM gleichwertig sind, und gewährleistet die vollständige Einhaltung der Spezifikationen, selbst wenn ein physischer E/A-Port nicht zugänglich ist. Darüber hinaus ermöglicht UTP die Durchführung von BER-Empfängermessungen und geht damit über grundlegende PER-Messungen hinaus. Dies ermöglicht ein besseres Verständnis der Leistung des Empfängers.

6.2 Technische Einzelheiten

6.2.1 ETV-Architektur und Nachrichtenübermittlung

Ein typisches UTP-Testszenario folgt einer definierten Abfolge von Nachrichten zwischen dem oberen Tester und dem Prüfling. Der Upper Tester leitet den Prozess ein, indem er die vom Prüfling unterstützten UTP-Funktionen abfragt. Es kann ein optionales Zurücksetzen der Parameter und die Konfiguration des Prüflings für einen bestimmten Sender- oder Empfängertest folgen. Der Test wird dann gestartet, ausgeführt und anschließend gestoppt, wobei der Prüfling detaillierte Berichte an den Prüfer zurückschickt.

Alle ETV-Nachrichten folgen einem standardisierten Typ-Länge-Wert-Format (TLV). Das Feld " Type" (1 Oktett) gibt den Nachrichtentyp an, das Feld " Length" (2 Oktette) gibt die Größe der Nutzlast an, und das Feld " Value" (Länge Oktette) enthält die eigentliche Nutzlast der Nachricht. Diese TLV-Struktur bietet einen flexiblen und erweiterbaren Rahmen für eine Vielzahl von Nachrichten.
Alle ETV-Nachrichten werden in drei Haupttypen eingeteilt: Konfiguration, Kontrolle und Bericht.

Konfigurationsnachrichten
Konfigurationsnachrichten werden vom Prüfer gesendet, um die Testparameter des Prüflings vor Beginn eines Tests einzustellen. Sie bieten eine detaillierte Kontrolle über die Testumgebung und stellen sicher, dass das IUT für das gewünschte Testszenario korrekt konfiguriert ist. Eine vollständige Liste dieser Meldungen umfasst:

UTP_Set_RF_Channel: Legt den HF-Kanal fest, auf dem der Test durchgeführt wird
UTP_Set_Packet_Payload: Legt die Art der Nutzlast fest, die in Testpaketen verwendet werden soll (z. B. Pseudo-Zufall, alle 1en und alle 0en)
UTP_Set_Payload_Length: Setzt die Länge der Testdaten-Nutzlast
UTP_Set_PHY: Konfiguriert den PHY (z. B. LE 1M, LE 2M und LE Coded), der für den Test verwendet werden soll.
UTP_Set_Modulation_Index: Setzt den Modulationsindex für den Sendertest
UTP_Set_CTE_Length: Legt die Länge der Constant Tone Extension (CTE) für die Prüfung des Ankunftswinkels (AoA) oder des Abfahrtswinkels (AoD) fest
UTP_Set_CTE_Type: Legt den Typ des zu verwendenden CTE fest (z. B. AoA und AoD)
UTP_Set_CTE_Slot_Durations: Definiert die Slot-Dauer für den CTE
UTP_Set_CTE_Antenna_IDs: Gibt das Antennenmuster oder die IDs an, die für den CTE verwendet werden sollen
UTP_Set_Packet_Count: Legt die Anzahl der zu sendenden oder zu empfangenden Testpakete fest
UTP_Set_Tx_Power_Level: Stellt den Sendeleistungspegel des IUT ein
UTP_Set_OTA_Exclusion_Period: Konfiguriert den Ausschlusszeitraum für Over-the-Air-Tests
UTP_Set_Vendor_Specific_Data: Eine herstellerspezifische Nachricht für eine proprietäre Konfiguration

Kontrollnachrichten
Kontrollnachrichten werden verwendet, um den gesamten Testablauf zu steuern, einschließlich der Einleitung, Beendigung und Abfrage des Status des IUT. Sie dienen als primäre Befehle für die Steuerung des Prüfablaufs und können je nach Richtung kategorisiert werden.

Kontrollnachrichten, die vom unteren oder oberen Tester gesendet werden: Diese Meldungen weisen das IUT an, bestimmte Aktionen durchzuführen
- UTP_Query_Supported_Features: Fordert das IUT auf, die von ihm unterstützten UTP-Merkmale zu melden
- UTP_Rücksetzen: Setzt das IUT auf seine Standard-Testkonfiguration zurück
- UTP_Start_Test: Startet einen zuvor konfigurierten Sender- oder Empfängertest
- UTP_Stop_Test: Beendet den laufenden Test und weist das IUT an, seine Ergebnisse zu melden
Vom IUT gesendete Kontrollmeldungen: Diese Meldungen werden als Antwort auf Befehle oder zur Anzeige des Status eines Tests gesendet
- UTP_Accept: Bestätigt einen Befehl und zeigt an, dass er akzeptiert wurde.
- UTP_Ablehnen: Signalisiert, dass ein Befehl aufgrund eines Fehlers abgelehnt wurde
- UTP_Reset_Accept: Quittiert einen Reset-Befehl
- UTP_Test_Ended: Benachrichtigt den Prüfer, dass ein Test beendet ist

Berichtsmeldungen
Berichtsmeldungen werden vom Prüfling an den Prüfer gesendet, um Rückmeldungen und Testergebnisse zu liefern. Sie sind wichtig, um Daten zu sammeln und die Leistung des Prüflings gegenüber der Spezifikation zu verifizieren. Eine vollständige Liste dieser Meldungen umfasst:

UTP_Report_Unterstützte_Funktionen: Diese Nachricht wird als Antwort auf eine Abfrage gesendet und enthält Einzelheiten zu den UTP-Merkmalen und -Fähigkeiten des IUT.
UTP_Report_IQ_Samples: Diese Nachricht wird für fortgeschrittene Tests verwendet und liefert I- und Q-Abtastdaten vom Empfänger des IUT.
UTP_Report_Empfänger_Qualität_Zähler: Liefert Statistiken aus einem Empfängertest, wie z. B. die Anzahl der empfangenen Pakete und andere Qualitätsmetriken
UTP_Report_Vendor_Specific_Data: Eine herstellerspezifische Nachricht für die Meldung von proprietären Daten

6.2.2 UTP-Transportoptionen und spezifische Befehle

Die Vielseitigkeit von UTP wird durch seine Fähigkeit unterstrichen, über drei verschiedene Transportschnittstellen zu arbeiten: 2-Draht-UART, HCI und OTA.

UTP2-Draht-UART-Modus
Wie DTM kann auch UTP über eine physikalische 2-Draht-UART-Transportschnittstelle arbeiten. Dies ermöglicht einen nahtlosen Übergang von DTM zu UTP für Testaufbauten, die diese Schnittstelle bereits nutzen. UTP-Nachrichten werden gekapselt und über die UART-Verbindung zwischen dem Upper Tester und dem IUT ausgetauscht.

UTPHCI-Modus
Wenn UTP über den HCI-Transport arbeitet, werden spezielle HCI-Befehle und -Ereignisse verwendet, um das Testen zu erleichtern. Ein Host kann mit dem Befehl HCI_LE_UTP_Send eine UTP-Nachricht an die Steuerung senden, während die Steuerung den Host mit dem Ereignis HCI_LE_UTP_Receive über eine empfangene UTP-Nachricht informiert. Darüber hinaus ermöglicht der Befehl HCI_LE_Enable_UTP_OTA_Mode dem Host , den OTA-UTP-Modus auf der Steuerung zu aktivieren.

UTPOTA-Modus
Der Over-the-Air (OTA)-Transport ist die wichtigste Erweiterung von UTP. In diesem Modus werden sowohl Kontrollnachrichten als auch RF PHY-Testpakete drahtlos über die 2,4 GHz RF-Schnittstelle ausgetauscht. Dies macht eine physikalische Testschnittstelle überflüssig, da der Tester den Prüfling über dieselbe Funkverbindung steuert, die auch getestet wird.

Ein Controller verwendet das UTP OTA-Modus-Verfahren, um in den RF PHY-Testmodus zu gelangen. Die Zentrale oder das Peripheriegerät kann diese Prozedur jederzeit nach Eintritt in den Verbindungsstatus durch Senden einer LL_OTA_UTP_IND PDU einleiten. Das Verfahren gilt als abgeschlossen, wenn die Link-Layer-Bestätigung für diese PDU gesendet oder empfangen wird. UTP-Nachrichten werden dann unter Verwendung dieser LL_OTA_UTP_IND-PDUs transportiert.

LL_OTA_UTP_IND PDU-Format
Die LL_OTA_UTP_IND-PDU hat das folgende Format:

Opcode (1 Byte): Identifiziert den Typ der ETV-Nachricht.
Transaction_ID (1 Byte): Ein Identifikator, der zur Paarung von Anfrage- und Antwortnachrichten verwendet wird.
UTP_Message (Variable): Überträgt die eigentliche ETV-Nachricht, die einer TLV-Struktur (Type-Length-Value) folgt. Dadurch kann die Nachricht jeden UTP-Nachrichtentyp enthalten, z. B. eine Konfigurations- oder Kontrollnachricht, was ein hohes Maß an Flexibilität und Erweiterbarkeit bietet.

Sicherheits- und Verschlüsselungsanforderungen
Das vielseitige Format der LL_OTA_UTP_IND-PDU ermöglicht die effiziente Kapselung und Übertragung von UTP-Nachrichten in verschiedenen Prüfszenarien.
Für UTP OTA wird eine entscheidende Sicherheits- und Integritätsprüfung durchgeführt. UTP-PDUs dürfen nur verarbeitet werden, wenn alle folgenden Bedingungen erfüllt sind:

Die ACL ist verschlüsselt
Die Funktion des OTA-UTP-Modus wird vom Controller unterstützt
Der OTA-UTP-Modus ist auf dem IUT aktiviert

Wenn die ACL beim Empfang einer UTP-PDU nicht verschlüsselt ist, muss die Steuereinheit die PDU sofort zurückweisen, indem sie eine LL_REJECT_EXT_IND-PDU mit dem Fehlercode Insufficient Security (0x2F) sendet. Wenn der OTA-UTP-Modus beim Empfang einer UTP-PDU nicht aktiviert ist, muss die Steuereinheit die PDU zurückweisen, indem sie eine LL_REJECT_EXT_IND-PDU mit dem Fehlercode Command Disallowed (0x0C) sendet.

Dieser Mechanismus gewährleistet, dass der Testmodus nur unter sicheren und vorkonfigurierten Bedingungen aufgerufen werden kann.

6.2.3 Beispiel für einen OTA-Sendertest

Bei einem OTA-Sendertest weist der Upper Tester den Prüfling an, mit der Übertragung von HF-PHY-Testpaketen zu beginnen. Der Prüfling fährt fort, diese Pakete auf einer konfigurierten Frequenz zu senden, bis entweder eine bestimmte Paketanzahl erreicht ist oder der untere Tester einen Befehl zur Beendigung des Tests sendet.
Der Zweck dieses Tests ist es, die Sendereigenschaften des Prüflings zu überprüfen, wie z.B. die Sendeleistung, das Leistungsdichtespektrum und die Modulationsgenauigkeit, ohne dass eine physikalische Verbindung die Messungen beeinflusst. Abbildung 6.2.3 zeigt ein Beispiel für einen OTA-Sendertest.

Abbildung 6.2.3: Beispiel für einen OTA-Sendertest: Unterer Tester beendet die Sequenz vorzeitig, Paketanzahl erreicht

6.2.4 Beispiel eines OTA-Empfängertests

Bei einem OTA-Empfängertest löst der obere Tester den Test aus, und der untere Tester beginnt mit der Übertragung von HF-PHY-Testpaketen auf einer konfigurierten Frequenz. Der untere Tester überträgt die Pakete über eine Anzahl von Verbindungsintervallen, die erforderlich sind, um die konfigurierte Paketanzahl zu erfüllen.

Das IUT hört diese Pakete ab und berichtet über die Empfangsqualität. Dieser Test bewertet die Empfängerleistung des Prüflings, einschließlich Empfindlichkeit und Blockierungseigenschaften. Abbildung 6.2.4 zeigt ein Beispiel für einen OTA-Empfängertest.

Abbildung 6.2.4: Beispiel eines OTA-Empfängertests

6.3 Zusammenfassung

Die Einführung des Unified Test Protocol stellt einen bedeutenden Fortschritt bei der Konformitätsprüfung von Bluetooth® LE RF PHY dar. Durch die Bereitstellung eines umfassenden Satzes von Nachrichten und Kontrollmechanismen bietet das UTP eine flexiblere und leistungsfähigere Lösung als das traditionelle DTM. Vor allem die Unterstützung von OTA-Transport in Verbindung mit genau definierten Verfahren und Sicherheitsmaßnahmen auf der Verbindungsschicht beseitigt die seit langem bestehende Einschränkung der Abhängigkeit von der physikalischen Schnittstelle.

UTP ermöglicht praktischere und genauere Tests von Geräten in ihrem endgültigen Formfaktor und erweitert den Anwendungsbereich von Konformitätstests auf Szenarien, die bisher nur schwer oder gar nicht zu bewältigen waren.

7. Schlussfolgerung

Bluetooth® Core 6.2 führt neue Funktionen ein, die die Reaktionsfähigkeit von Geräten verbessern, die Sicherheit erhöhen und die Kommunikations- und Testmöglichkeiten verbessern. Von deutlich verkürzten Verbindungsintervallen, die schnellere, reaktionsschnellere Interaktionen ermöglichen, bis hin zu erweiterten Sicherheitsfunktionen, die vor ausgeklügelten HF-Amplitudenangriffen schützen, erfüllen diese Verbesserungen die sich entwickelnden Anforderungen moderner drahtloser Ökosysteme. Die standardisierte isochrone Kommunikation über USB vereinfacht die Integration von Bluetooth® LE Audio, während die verbesserten Testfunktionen eine flexiblere, sicherere und umfassendere RF-Validierung gewährleisten. Zusammengenommen positionieren diese Fortschritte die Bluetooth®-Technologie für weitere Innovationen in einer Vielzahl von Branchen und Anwendungsfällen.

8. Referenzen

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