Bluetooth® Kernspezifikation Version 6.0

Funktionsübersicht

Geschichte der Revision

1. Einleitung

2. Auf einen Blick

2.1 Channel Sounding

2.2 Entscheidungsbasierte Werbefilterung

2.3 Überwachung der Inserenten

2.4 ISOAL-Erweiterung

2.5 LL Erweiterter Funktionssatz

2.6 Frame Space Update

3. Channel Sounding

3.1 Hintergrund

3.1.1 Gerätepositionierung und Bluetooth LE

3.1.2 Architektur des Datentransports

3.2 Über Channel Sounding

3.2.1 Überblick

3.2.2 Technische Highlights

3.2.3 Weitere Informationen über Channel Sounding

4. Entscheidungsbasierte Werbefilterung

4.1 Hintergrund

4.1.1 Zustände der Verbindungsschicht

4.1.2 Filterrichtlinien

4.1.3 Erweiterte Werbung

4.1.4 Der auslösende Staat

4.1.5 Probleme

4.2 Über entscheidungsbasierte Werbefilterung

4.2.1 Überblick

4.2.2 Vorteile

4.2.3 Technische Highlights

5. Überwachung der Inserenten

5.1 Hintergrund

5.1.1 Geräteerkennung

5.1.2 Verbinden

5.1.3 Reichweite

5.1.4 Duplikate filtern

5.1.5 Bluetooth LE Audio- und Akzeptorverfügbarkeit

5.2 Über die Überwachung von Werbetreibenden

5.2.1 Überblick

5.2.2 Technische Highlights

6. ISOAL-Erweiterung

6.1 Hintergrund

6.1.1 Isochrone Kommunikation

6.1.2 Digitales Audio

6.1.3 ISOAL

6.2 Über die ISOAL-Erweiterung

6.2.1 Verkürzte Latenzzeit

6.2.2 Verbesserte Zuverlässigkeit

7. LL Erweiterter Funktionssatz

7.1 Hintergrund

7.2 Über den erweiterten Funktionsumfang von LL

7.2.1 Überblick

7.2.2 Technische Highlights

8. Frame Space Update

8.1 Hintergrund

8.1.1 Der Zwischenrahmenraum

8.1.2 Der vernetzte Zustand

8.2 Über Frame Space Update

8.2.1 Überblick

8.2.2 Technische Highlights

9. Schlussfolgerung

10. Referenzen


Version:   1.0
Datum der Überarbeitung: 6. August 2024
Autor:   

Martin Woolley, Bluetooth SIG

1. Einleitung

Die Bluetooth® Core Specification Version 6.0 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 und beginnt mit einer Beschreibung der relevanten Hintergrundinformationen. Dies soll denjenigen Lesern das Leben erleichtern, die mit bestimmten Aspekten von Bluetooth Low Energy (LE) noch nicht vertraut sind. Dennoch sind die Hintergrundabschnitte nicht vollständig, und Leser, die sich mit unbekannten Begriffen oder Konzepten konfrontiert sehen, sollten die Bluetooth LE-Fibel herunterladen und lesen.

2. Auf einen Blick

2.1 Bluetooth® Channel Sounding

Bluetooth® Channel Sounding ermöglicht eine sichere Feinabstimmung zwischen zwei Bluetooth Geräten. Unter Entfernungsmessung versteht man die Anwendung bestimmter Techniken zur Bestimmung der Entfernung zwischen zwei Objekten.

Die drahtlose Entfernungsmessung findet in einer Vielzahl von Produkten Anwendung, z. B. in digitalen Schlüssellösungen und "Find My"-Netzen. Die neue Funktion Bluetooth Channel Sounding wurde entwickelt, um einen standardbasierten technischen Ansatz zu bieten, der die anspruchsvollen Genauigkeits- und Sicherheitsanforderungen erfüllt, die solche Produkte in der Regel haben.

2.2 Entscheidungsbasierte Werbefilterung

Die Funktion Bluetooth LE Extended Advertising umfasst eine Reihe von zusammenhängenden Paketen, die sowohl auf dem primären als auch auf dem sekundären Funkkanal übertragen werden.

Bei der entscheidungsbasierten Werbefilterung kann ein Scan-Gerät anhand des Inhalts eines auf einem primären Werbekanal empfangenen Pakets entscheiden, ob es anschließend auf den sekundären Kanälen nach verwandten Paketen sucht. Dies verbessert die Effizienz des Scannens, indem es die Zeit reduziert, die für das Scannen auf sekundären Kanälen nach Paketen aufgewendet wird, die möglicherweise keine für die Anwendung relevanten PDUs enthalten.

2.3 Überwachung der Inserenten

Die Host-Komponente eines Observer-Geräts kann den Bluetooth LE-Controller anweisen, doppelte Werbepakete zu filtern. Wenn eine solche Filterung aktiv ist, empfängt der Host nur ein einziges Werbepaket von jedem einzelnen Gerät (vorbehaltlich der Definitionen der Kernspezifikation, was ein einzelnes Gerät in diesem Zusammenhang ist). Dies verbessert die Effizienz für den Host, hat aber den Nachteil, dass der Host keine Möglichkeit hat, zu wissen, ob ein Gerät noch in Reichweite ist, wenn die Umstände vorschreiben, dass das Beobachtergerät nun versuchen sollte, eine Verbindung zu ihm herzustellen. Dies kann dazu führen, dass der Beobachter Energie verschwendet, indem er mit hohem Tastverhältnis nach einem zuvor entdeckten Gerät sucht, das sich nicht mehr in Reichweite befindet.

Die neue Funktion zur Überwachung von Advertisern verwendet HCI-Ereignisse (Host Controller Interface), um den Host zu informieren, wenn sich ein Gerät von Interesse in und außerhalb der Reichweite bewegt.

2.4 ISOAL-Erweiterung

Der Isochronous Adaptation Layer (ISOAL) ermöglicht die Übertragung größerer Datenrahmen in kleineren Paketen der Verbindungsschicht und sorgt dafür, dass die zugehörigen Zeitinformationen, die für die korrekte Verarbeitung der Daten durch die Empfänger benötigt werden, wiederhergestellt werden können.

ISOAL kann in Abhängigkeit von bestimmten Variablen entweder gerahmte oder ungerahmte PDUs erzeugen. Wenn gerahmte PDUs erzeugt werden, kann sich die Latenzzeit dadurch erhöhen.

In der Bluetooth Core Specification Version 6.0 wurde ISOAL durch die Definition eines neuen Framing-Modus verbessert, der die Latenzzeit für Anwendungsfälle reduziert, die besonders empfindlich auf dieses Problem reagieren. Die gleiche Funktion verbessert auch die Zuverlässigkeit.

2.5 LL Erweiterter Funktionssatz

Die Geräte sind in der Lage, Informationen über die von ihnen unterstützten Merkmale der Verbindungsschicht auszutauschen. Diese Fähigkeit wurde verbessert, um eine größere Anzahl von Funktionen zu unterstützen, was mit der zunehmenden Ausgereiftheit und Vielseitigkeit von Bluetooth LE notwendig geworden ist.

2.6 Frame Space Update

Frühere Versionen der Bluetooth Core Specification definieren einen konstanten Wert für die Zeit, die zwischen benachbarten Übertragungen von Paketen in einem Verbindungsereignis oder einem Connected Isochronous Stream (CIS)-Teilereignis liegt. Dieser Wert wird in der Spezifikation als T_IFS bezeichnet und hatte einen festen Wert von 150 µs.

In Version 6.0 der Kernspezifikation ist der Rahmenabstand, wie er in Verbindungen oder mit verbundenen isochronen Streams verwendet wird, jetzt verhandelbar und kann entweder kürzer oder länger als 150 µs sein.

3. Bluetooth® Channel Sounding

3.1 Hintergrund

Dieser Abschnitt bietet einen Überblick über die Aspekte der Bluetooth LE-Technologie, die zum besseren Verständnis und zur Wertschätzung der neuen Funktion Bluetooth® Channel Sounding beitragen.

3.1.1 Gerätepositionierung und Bluetooth LE

Seit Bluetooth LE zum ersten Mal in der Bluetooth Core Specification spezifiziert wurde, haben Kernfunktionen wie Angle of Arrival (AoA) und Angle of Departure (AoD) Peilung und eine Reihe von zugehörigen Profilen wie das Find Me Profil Bluetooth LE als eine beliebte Technologie für Standortdienste etabliert.

2405 Channel Sounding Abbildung 2Abbildung 1 - Richtungsbestimmung mit AoA und AoD

Darüber hinaus haben sich mehrere proprietäre Beaconing-Nachrichtenformate durchgesetzt, die in standardmäßigen Bluetooth LE-Werbepaketen übertragen werden.

Für viele Anwendungen ist es erforderlich, den Abstand zwischen zwei Bluetooth Geräten zu berechnen. Vor der Veröffentlichung der Bluetooth Core Specification Version 6.0 konnte dies nur mit einer Methode erreicht werden, die als Pfadverlustberechnung bekannt ist. Diese Methode setzt voraus, dass das empfangende Gerät die Stärke des empfangenen Signals ( RSSI) misst und die Stärke des Signals kennt, das von dem entfernten Gerät in einer bestimmten Referenzentfernung vom Sender (z. B. 1 m) gesendet wird. Darüber hinaus besagt die einschlägige Physik, dass die Signalstärke an einem Empfänger umgekehrt proportional zum Quadrat seiner Entfernung vom Sender ist. Mit der Referenzsignalstärke des Senders, dem RSSI und dieser einfachen mathematischen Beziehung ist es möglich, einen Entfernungswert zu berechnen.

2405 Channel Sounding Abbildung 1Abbildung 2 - Inverser quadratischer Pfadverlust über die Entfernung

Pfadverlustberechnungen sind geeignet, wenn die erforderliche Genauigkeit der Entfernungsberechnung sowie die Konsistenz und Zuverlässigkeit solcher Berechnungen nicht besonders hoch sind. Da die Signalstärke anfangs schnell abfällt (siehe Abbildung 2), wenn der Abstand zwischen zwei Geräten relativ gering ist, können Berechnungen der Wegdämpfung recht gute Ergebnisse liefern. Bei größeren Entfernungen kann jedoch eine kleine Signalstärkeschwankung einem großen möglichen Entfernungsbereich entsprechen, wodurch die Berechnung sehr empfindlich auf kleine Fehler reagiert. Die Methode ist anfällig für Störungen und den Einfluss anderer Umweltfaktoren. Außerdem ist sie unsicher, so dass die Anwendungen dem Risiko von Angriffen wie z. B. Spoofing ausgesetzt sind.

Die anspruchsvolleren Anforderungen von Anwendungen wie der Verfolgung von Vermögenswerten und schlüssellosen Zugangs- und Zündsystemen erfordern einen ausgefeilteren, sicheren und standardisierten Ansatz, der genauere und zuverlässigere Ergebnisse liefern kann.

3.1.2 Architektur des Datentransports

Die Bluetooth Core Specification definiert mehrere Konzepte, die zusammen die Bluetooth Datentransportarchitektur bilden. Zu diesen Konzepten gehören der physische Transport, der physische Kanal, die physische Verbindung, die logische Verbindung und der logische Transport. Bestimmte Kombinationen und Konfigurationen sind für die Unterstützung verschiedener Anwendungstypen definiert, die jeweils besondere Merkmale in Bezug auf Eigenschaften wie Topologie, Timing, Zuverlässigkeit, Leistung und Kanalnutzung aufweisen. Die Begriffe Betriebsmodus oder Betriebsart werden manchmal informell verwendet, um sich auf die verschiedenen Konfigurationen der Datentransportarchitektur zu beziehen.

Bluetooth Kern 6 Abbildung 3Abbildung 3 - Teil der Datenübertragungsarchitektur Bluetooth

Abbildung 3 zeigt einen kleinen Teil der Datentransportarchitektur, wobei zwei der am häufigsten verwendeten logischen Transporte und die zugehörigen physikalischen Verbindungen, physikalischen Kanäle und physikalischen Transportkomponenten hervorgehoben werden. Diese beiden logischen Transporte sind für Bluetooth® Channel Sounding von Bedeutung.

3.1.2.1 LE-ACL

LE-ACL ist eine der am häufigsten verwendeten logischen Transportarten von Bluetooth LE, die eine verbindungsorientierte Kommunikation von Daten zwischen zwei Geräten ermöglicht. Tatsächlich werden ACL-Verbindungen im Allgemeinen einfach als Verbindungen bezeichnet. 

Das Gerät, das eine Verbindung anfordert, wird als Zentrale bezeichnet. Das Gerät, das diese Anfrage empfängt und gewährt, wird als Peripheriegerät bezeichnet.

Wenn zwei Geräte eine ACL-Verbindung herstellen, vereinbaren sie eine Reihe von Zeitparametern, die ihre nachfolgende Kommunikation bestimmen. Der Schlüssel zu diesen Parametern ist das Verbindungsintervall. Der Parameter für das Verbindungsintervall legt fest, wie oft (in Millisekunden) das Funkgerät für die Wartung dieser Verbindung verwendet werden kann.

ACL-Verbindungen können verschlüsselt sein. In diesem Fall werden alle Nutzdaten von der Verbindungsschicht vor der Paketübertragung verschlüsselt und beim Empfang durch die Verbindungsschicht des Gegengeräts entschlüsselt.

3.1.2.2 ADVB

ADVB ist der logische Transport für Advertising Broadcast. Er bietet einen verbindungslosen Kommunikationsmodus und kann verwendet werden, um Daten an ein oder mehrere Geräte gleichzeitig zu übertragen oder um das Vorhandensein eines Peripheriegeräts anzuzeigen, damit andere Geräte es erkennen können.

3.2 Über Bluetooth® Channel Sounding

3.2.1 Überblick

Die Bluetooth® Channel Sounding Funktion von Bluetooth LE besteht aus zwei verschiedenen Methoden der Entfernungsmessung, die unabhängig oder in Kombination verwendet werden können. Die beiden Methoden heißen "Phase-Based Ranging" (PBR) und "Round-Trip Timing" (RTT).

Das System unterstützt die Berechnung von wesentlich genaueren Entfernungsmessungen als die Pfadverlustmethode, ist weniger anfällig für Interferenzen und den Einfluss von Umweltfaktoren und beinhaltet zahlreiche Sicherheitsmechanismen.

Dieser Abschnitt bietet eine Einführung in Bluetooth® Channel Sounding. Eine ausführlichere und umfassendere Erklärung finden Sie in dem zugehörigen Dokument Secure Fine Ranging with Bluetooth Channel Sounding , das auf der Website Bluetooth SIG https://www.bluetooth.com verfügbar ist.

3.2.2 Technische Highlights

3.2.2.1 Systemarchitektur

Bluetooth® Channel Sounding findet zwischen zwei verbundenen Geräten in einer 1:1-Topologie statt. Das Gerät, das die Entfernung von sich zu einem anderen Gerät berechnen möchte, wird Initiator genannt. Das andere Gerät wird Reflektor genannt.

Während channel sounding finden mehrere bidirektionale Austauschvorgänge zwischen Initiator und Reflektor in vorher vereinbarten Zeitschlitzen statt.

Im Bluetooth Stack ist channel sounding in erster Linie eine Funktion des Bluetooth Controllers und nicht des Hostteils des Stacks. Der Controller des Initiators leitet Low-Level-Messungen an den Host und schließlich über das Host Controller Interface (HCI) an die Anwendungsschicht weiter. Es liegt in der Verantwortung der Anwendung, die vom Controller bereitgestellten channel sounding Daten zu verwenden, um Entfernungsmessungen zu berechnen.

Abbildung 4 - CS-Geräterollen und Host/Controller-Funktionsverteilung

Geräte, die Bluetooth Channel Sounding verwenden, können eine Antennengruppe enthalten. Dadurch kann die Genauigkeit der Entfernungsmessung verbessert werden, da eine Reihe verschiedener Kommunikationspfade zur Verfügung steht und die Auswirkungen der Mehrwegeausbreitung vermindert werden.

3.2.2.2 Bluetooth® Channel Sounding und die Datentransportarchitektur

Abbildung 5 zeigt eine Teilmenge der vollständigen Datentransportarchitektur und die neuen physikalischen Verbindungs- und Kanaltypen, die zur Unterstützung von channel sounding hinzugefügt wurden.

Abbildung 5 - CS und die Datentransportarchitektur

Channel sounding wird über eine ACL-Verbindung zwischen den beiden Geräten eingeleitet. Nach dem Start von channel sounding dient die ACL-Verbindung weiterhin als Transportmittel für den Austausch von Steuerdaten auf der Verbindungsschicht und als Zeitreferenz für die Planung der Funkaktivität von channel sounding . Channel sounding verwendet die neue physikalische Verbindung Channel Sounding und den physikalischen Kanal Channel Sounding .

Die Rollen des Initiators und des Reflektors können jeweils entweder von der Zentrale oder vom Peripheriegerät übernommen werden.

3.2.2.3 Methoden zur Abstandsmessung

3.2.2.3.1 Phasenbasiertes Ranging (PBR)

Die PBR-Methode macht sich eine grundlegende Eigenschaft von Funksignalen zunutze, die als Phase bekannt ist, sowie deren Beziehung zu Frequenz und Wellenlänge. Die Phase kann als ein Bruchteil eines Wellenzyklus betrachtet werden und wird im Allgemeinen als Winkel zwischen 0 und 2π Radiant ausgedrückt. Änderungen der Phase werden manchmal auf Phasendrehungen zurückgeführt.

Abbildung 6 - Beispiele für Phasenwerte innerhalb mehrerer Wellenzyklen

Abbildung 6 zeigt beispielhafte Phasenwerte, die Punkten innerhalb eines Funksignals entsprechen. Beachten Sie die zyklische, sich wiederholende Natur der Werte über mehrere Wellenzyklen.

Bei der Verwendung von PBR sendet der Initiator ein Signal mit einer bestimmten Frequenz, f1, an den Reflektor. Der Reflektor sendet ein Signal zurück an den Initiator, der beim Empfang der Antwort die Phase des empfangenen Signals misst, die wir hier alsPf1 bezeichnen.

Abbildung 7 - Der Initiator sendet ein channel sounding Signal, das der Reflektor als Echo empfängt.

Anschließend sendet der Initiator ein weiteres Funksignal, diesmal mit einer anderen Frequenz, f2. Der Reflektor sendet das empfangene Signal erneut an den Initiator zurück. Durch die Änderung der Frequenz ändert sich die Wellenlänge und folglich auch die PhasePf2, die der Initiator beim Empfang der Antwort vom Reflektor misst.

Der Initiator kann nun die Entfernung zwischen den beiden Geräten anhand einer Formel berechnen, die die Frequenzdifferenz (f1 - f2), die Phasendifferenz (Pf1 -Pf2) und die Lichtgeschwindigkeit berücksichtigt.

In der Praxis werden die Geräte in der Regel mehr als zwei Signale auf mehr als zwei verschiedenen Frequenzen austauschen, da die Verfügbarkeit von mehr Low-Level-Messungen die Genauigkeit der von der Anwendung berechneten Entfernungsmessungen verbessern kann.

Der vom Initiator gemessene Phasenwert ändert sich mit zunehmendem Abstand zwischen den Geräten, wird aber an einem bestimmten Punkt auf Null zurückgesetzt und die Phasenwerte beginnen sich zu wiederholen. Dies ist auf die zyklische Natur der Phasendrehung zurückzuführen, wie in Abbildung 6 dargestellt. Im Zusammenhang mit der Abstandsmessung wird dieses Phänomen als Abstandsmehrdeutigkeit bezeichnet, da derselbe Phasenwert bei mehreren unterschiedlichen Abständen auftreten kann. Wann genau die Entfernungsmehrdeutigkeit zum ersten Mal auftritt, hängt von der Differenz zwischen den Frequenzen der channel sounding Signale ab. Dieser Differenzwert wird als Frequenzabstand bezeichnet. Im Allgemeinen tritt die Abstandsmehrdeutigkeit umso früher auf, je größer der Frequenzabstand ist. Bluetooth CS verwendet einen Frequenzabstand von 1 MHz, und die Mehrdeutigkeit tritt erst bei etwa 150 Metern auf.

Das Problem der Entfernungsmehrdeutigkeit kann durch die Verwendung von Züchterrechten in Verbindung mit der zweiten Entfernungsmessungsmethode, dem Round-Trip-Timing, gelöst werden.

3.2.2.3.2 Round-Trip Timing (RTT)

Bei der RTT-Methode überträgt der Initiator ein Paket an den Reflektor und der Reflektor sendet dasselbe Paket zurück. In dieser Hinsicht und nur in dieser Hinsicht besteht eine Ähnlichkeit mit dem Züchterrechtsverfahren.

Um die Berechnung einer Entfernungsmessung zu ermöglichen, zeichnet der Initiator beim Senden seines Pakets einen Zeitstempel auf. Diese Zeit wird als Time of Departure oder ToD bezeichnet. Beim Empfang des Antwortpakets vom Reflektor zeichnet er erneut einen Zeitstempel auf, der als Ankunftszeit (Time of Arrival, ToA) bezeichnet wird.

Wenn wir die Zeit, die zwischen ToD und ToA verstreicht, alsTA-D bezeichnen, dann könnte ein Maß für die zurückgelegte Entfernung erhalten werden, indemTA-D mit der Lichtgeschwindigkeit (c) multipliziert und dann (da es sich um eine bidirektionale Umlaufzeit handelt) durch 2 geteilt wird. Dies ergibt jedoch eine sehr grobe Schätzung der Entfernung, da die Zeit, die der Reflektor benötigt, um das Paket zu empfangen, es zu verarbeiten, die Antwort zu formulieren und sie zu senden, nicht berücksichtigt wird. Diese Verarbeitung erfordert eine scheinbar kurze und unbedeutende Zeitspanne, aber eine Funkübertragung, die sich mit Lichtgeschwindigkeit (im Vakuum) fortbewegt, kann 300 Meter in einer Mikrosekunde zurücklegen, so dass sehr kleine Ungenauigkeiten bei der Berechnung der Flugzeit erhebliche Auswirkungen auf die berechnete Entfernung haben können. Die genaue Bestimmung der Zeit, die Funksignale tatsächlich in der Luft verbringen, ist daher der Schlüssel zu genauen Entfernungsmessungen mit der RTT-Methode.

RTT in Bluetooth Channel Sounding stellt sicher, dass die Zeit, die der Reflector benötigt, um das empfangene CS-Paket umzudrehen und an den Initiator zurückzusenden, bekannt ist und dieser Zeitwert daher in Berechnungen verwendet werden kann, um eine genauere Flugzeit zu ermitteln. 

Die Bluetooth Core Specification definiert mehrere verschiedene Methoden zur Erfassung von ToA- und ToD-Zeitstempeln. Die Auswahl der Methoden variiert in ihrer Komplexität und Genauigkeit. Die genauesten Methoden zur Zeiterfassung sind als fraktionierte Zeitschätzungen bekannt. Eine möglichst genaue Erfassung der ToA- und ToD-Werte führt zu den genauesten Entfernungsmessungen.

3.2.2.4 Channel Sounding Initialisierung

Bevor channel sounding beginnen kann, müssen der Initiator und der Reflektor eine verschlüsselte ACL-Verbindung aufgebaut haben. Diese Verbindung wird dann für den sicheren Austausch von Link-Layer-Control-PDUs in Verbindung mit channel sounding Initialisierungsverfahren verwendet.

Bluetooth® Channel Sounding hat seine eigenen Sicherheitsmerkmale. Die erste channel sounding Prozedur, die ausgeführt wird, ist die CS Security Start Prozedur. Diese Prozedur stattet beide Geräte mit Initialisierungsvektor- (IV), Instanzierungs-Nonce- (IN) und Personalisierungsvektor- (PV) Werten aus, die anschließend während channel sounding als Eingaben für eine neue Sicherheitsfunktion, den Deterministic Random Bit Generator (DRBG), verwendet werden. DRBG wird in vielen der channel sounding Sicherheitsfunktionen verwendet (siehe 3.2.2.10 Bluetooth® Channel Sounding Sicherheitsübersicht). Die Sicherheit der verschlüsselten ACL-Verbindung schützt den Austausch dieser wichtigen Daten.

Die Bluetooth®-Funktion Channel Sounding bietet Entwicklern eine Reihe von Optionen, mit denen sie die verwendeten Entfernungsmessmethoden, die Genauigkeit der Messungen, die aus dem Verfahren resultierende Latenz, die Sicherheit und andere Variablen steuern oder beeinflussen können. Die Geräte haben nicht notwendigerweise identische channel sounding Fähigkeiten, und das Verfahren CS Capabilities Exchange ermöglicht es den beiden Geräten, Informationen über Fähigkeiten und Präferenzen auszutauschen.

Nach dem Austausch von Fähigkeitsdaten nehmen die Geräte am CS-Konfigurationsverfahren teil und vereinbaren die Konfigurationsparameter, die für das channel sounding Verfahren gelten, wenn es beginnt.

Bei der Verwendung der PBR-Methode wird erwartet, dass der Reflektor die vom Initiator empfangenen Signale mit derselben Frequenz zurücksendet. Alle Geräte können jedoch einen gewissen Grad an Ungenauigkeit bei der Frequenz der erzeugten Signale aufweisen, wobei die beabsichtigte oder gewünschte Frequenz von der tatsächlichen, gemessenen Frequenz des erzeugten Signals abweicht. Die Frequenz steht in direktem Zusammenhang mit der Wellenlänge, und das Züchterrechtsverfahren stützt sich auf diese Beziehung. Ungenauigkeiten in der Frequenz der vom Reflektor zurückgeworfenen Signale können daher die Genauigkeit der Entfernungsmessung beeinträchtigen. Folglich können die Geräte vom Hersteller mit einer Datentabelle ausgestattet werden, die als FAE-Tabelle (Fractional Frequency Offset Actuation Error) bezeichnet wird und für eine Sammlung von Referenzfrequenzen ein Maß für die Differenz zwischen der Frequenz eines erzeugten Signals und der erwarteten oder angeforderten Frequenz, ausgedrückt in Parts Per Million (ppm), liefert. Verwendung des Modus-0[1] FAE-Tabellenanforderungsverfahren kann der Initiator die FAE-Tabelle vom Reflektor anfordern und diese Daten bei seinen Berechnungen berücksichtigen.

Nach Abschluss der Initialisierungsprozeduren kann dann channel sounding beginnen. Dabei führen die beiden Geräte eine Reihe von Austauschvorgängen verschiedener Art durch, um Messungen vorzunehmen, die von einer Anwendung für Entfernungsberechnungen verwendet werden können.

3.2.2.5 Zeiteinteilung

Channel sounding beinhaltet die Verwendung des physikalischen Kanals Channel Sounding aus der allgemeinen Bluetooth Datentransportarchitektur (siehe 3.2.2.2 Channel Sounding und die Datentransportarchitektur). Dieser definiert, wie die Zeit unterteilt und für die HF-Aktivität genutzt wird.

3.2.2.5.1 Ereignisse, Unterereignisse und Schritte

Channel sounding findet in einer Reihe von Verfahren statt. Jeder Vorgang besteht aus einer Reihe von Ereignissen, und jedes Ereignis ist weiter in Unterereignisse unterteilt. Die letzte Unterteilung der Zeit in diesem hierarchischen Schema ist der Schritt. Innerhalb von Schritten findet der HF-Austausch zwischen Initiator und Reflektor statt.

Abbildung 8 - Struktur der Channel Sounding Verfahren in einer Beispielkonfiguration

Verschiedene Konfigurationsparameter steuern Aspekte dieser Struktur, darunter die Kardinalität der Beziehung zwischen Elementen auf verschiedenen Ebenen (z. B. die Anzahl der Schritte pro Unterereignis), die Dauer der Ereignisse und die in den Schritten stattfindende Aktivität. Zum Beispiel gibt es immer mindestens 2 Schritte und maximal 160 Schritte in einem Teilereignis. Pro Vorgang gibt es maximal 256 Schritte.

3.2.2.5.2 Zeitlicher Ankerpunkt

Alle channel sounding Prozedur-, Ereignis-, Unterereignis- und Schritt-Startzeiten sind direkt oder indirekt mit einem ausgewählten Verbindungsereignis in der zugehörigen LE ACL-Verbindung verankert, über die die Link-Layer-Prozeduren zur Einleitung von channel sounding ausgeführt wurden.

3.2.2.6 Bluetooth® Channel Sounding Schritte

3.2.2.6.1 Pakete und Töne

Während eines CS-Schrittes tauschen die Geräte eine Reihe von Paketen aus, die als CS-Sync-Pakete bezeichnet werden, und optional auch Töne, die als CS-Töne bezeichnet werden.

CS-Sync-Pakete können entweder mit dem LE 1M oder LE 2M PHY übertragen werden. Die GFSK[2] Modulationsschema wird in beiden Fällen verwendet, wie auch bei anderen Bluetooth LE-Paketen.

Ein CS-Ton ist ein Signal, das mittels Amplitudenumtastung (ASK) ein Symbol mit fester Frequenz erzeugt.

Schritte haben einen zugehörigen Modus, der von 0 bis einschließlich 3 nummeriert ist. Der Modus legt die Einzelheiten des in dem Schritt stattfindenden Austauschs und dessen Zweck fest.

  • Ein Modus-0-Schritt dient der Kalibrierung und ermöglicht es dem Initiator, das Ausmaß zu bestimmen, in dem die Erzeugung einer bestimmten Frequenz durch den Reflektor von seiner eigenen abweichen könnte. Daraus ergibt sich ein Wert, der als "Fractional Frequency Offset" (FFO) bezeichnet wird und in Berechnungen zum Ausgleich von Unterschieden bei der Frequenzerzeugung verwendet wird. Mode-0-Schritte beinhalten den Austausch von CS-Sync-Paketen.
  • In einem Modus-1-Schritt werden CS-Sync-Pakete bei der Anwendung der Round-Trip-Timing-Methode (RTT) verwendet.
  • Ein Modus-2-Schritt beinhaltet den Austausch von CS-Tönen zum Zweck der phasenbasierten Entfernungsmessung (PBR).
  • Ein Modus-3-Schritt tauscht sowohl CS-Sync-Pakete als auch CS-Töne aus und ermöglicht die Erfassung von Daten für die RTT- und die PBR-Methode in einem einzigen Schritt. Die Unterstützung für Modus-3 ist optional.

Welche Schrittmodi in einem channel sounding Verfahren verwendet werden, hängt von den Regeln in der Bluetooth Kernspezifikation und der von den beiden Geräten vereinbarten Konfiguration ab. Dazu gehört auch, welche Entfernungsmessungsmethode oder -methoden verwendet werden sollen, d. h. RTT und/oder PBR.

3.2.2.6.2 Moduskombinationen und Sequenzierung

Bluetooth Channel Sounding ermöglicht die Kombination und Abfolge von Schrittmodi in verschiedenen Mustern innerhalb eines Verfahrens, wobei die Anwendungsschicht einen großen Teil der Kontrolle erhält, die sie während der Konfiguration ausübt. Die Anwendungsschicht kann auch die Anzahl der Wiederholungen eines channel sounding Verfahrens und andere Variablen konfigurieren, die sich auf die Anzahl der ausgetauschten Pakete oder Töne und in gewisser Hinsicht auch auf deren Inhalt auswirken.

Die Anwendungen werden Fragen wie die erforderliche Genauigkeit der Entfernungsmessung, die Latenztoleranz und die Sicherheitsanforderungen berücksichtigen, wenn es darum geht, die optimale Konfiguration zu finden. So liefert eine größere Anzahl von Vermittlungsstellen im Allgemeinen mehr Messungen und kann zur Verbesserung der Genauigkeit beitragen, allerdings auf Kosten einer höheren Latenzzeit.

An jedem Unterereignis sind immer mindestens zwei verschiedene Schrittmodi beteiligt. Modus 0 beginnt immer jedes Unterereignis, und ein oder zwei andere Modi können für andere Schritte im selben Unterereignis verwendet werden, vorbehaltlich bestimmter zulässiger Kombinationen, die in der Bluetooth Core Specification aufgeführt sind und hier in Tabelle 1 wiederholt werden.

Main_Mode

Sub_Mode

Mode-1

None

Mode-2

None

Mode-3

None

Mode-2

Mode-1

Mode-2

Mode-3

Mode-3

Mode-2

Tabelle 1 - Zulässige Kombinationen von Betriebsarten, die nicht unter Mode-0 fallen.

In Tabelle 1 werden auch die Begriffe Main_Mode und Sub_Mode eingeführt. Diese Begriffe beziehen sich auf die Art und Weise, in der sich wiederholende Muster von Stufenmodi über eine Reihe von Konfigurationsparametern erstellt werden können. Das Konfigurationsverfahren führt dazu, dass einer der Modi 1 - 3 als Hauptmodus und optional ein anderer als Untermodus bezeichnet wird.

Im Allgemeinen folgt die Abfolge im Schrittbetrieb diesem Muster:

  1. Ein oder mehrere Mode-0-Schritte starten das Unterereignis.
  2. Es folgt eine Abfolge von n Hauptmodusschritten, wobei n zufällig gewählt wird und innerhalb eines konfigurierten Bereichs liegt.
  3. Ein einzelner Untermodus-Schritt folgt auf die Abfolge von n Hauptmodus-Schritten gemäß einem Verfahren, das in der Bluetooth Core Specification als sub_mode insertion bezeichnet wird.

Step-Mode-Sequenzen sind nicht an Sub-Event-Grenzen gebunden, außer durch die allgemeine Regel, dass Sub-Events immer mit einem oder mehreren Mode-0-Schritten beginnen müssen. Vollständige Sequenzen können sich über mehr als ein Unterereignis erstrecken.

3.2.2.7 RF-Kanäle

3.2.2.7.1 Kanäle und Kanalfilterung

Für die Zwecke von channel sounding werden 72 Kanäle mit einer Breite von jeweils 1 MHz und einem eindeutigen Kanalindexwert definiert. Die Anordnung dieser Kanäle stellt sicher, dass die primären LE-Werbekanäle vermieden werden.

Eine Kanalbreite von 1 MHz anstelle der üblichen 2 MHz stellt sicher, dass der Frequenzabstand zwischen Züchterrechtssignalen, die benachbarte Kanäle nutzen, so ist, dass Entfernungsmehrdeutigkeit erst bei etwa 150 Metern auftritt.

Eine spezielle Kanaltabelle, die so genannte CS-Kanaltabelle, gibt an, welche Kanäle bei der Kanalauswahl zu berücksichtigen und welche zu vermeiden sind. Ein Kontrollverfahren auf der Verbindungsschicht ermöglicht es Initiator und Reflektor, diese Tabelle auf der Grundlage der lokalen HF-Bedingungen zu aktualisieren.

Beim Frequenzsprungverfahren wird ein neuer Kanal aus den als verfügbar gekennzeichneten Kanälen ausgewählt. Dies geschieht in der Regel kurz vor der Ausführung eines jeden Schritts, es sei denn, es wird eine Modussequenzierungsfunktion namens "Main Mode Repetition" verwendet.

3.2.2.7.2 Kanalauswahl

Ein neuer Satz von drei Kanalauswahlalgorithmen (CSA) wurde für die Verwendung in Channel Sounding definiert. Sie werden zusammen als CSA #3 und einzeln als CSA #3a, CSA #3b und CSA #3c bezeichnet.

CSA #3a dient ausschließlich zur Auswahl des Kanals, der in Modus-0-Schritten verwendet werden soll.

CSA #3b und CSA #3c sind beide für die Verwendung mit Nicht-Mode-0-Schritten konzipiert, aber nur einer der beiden kann während eines channel sounding Verfahrens verwendet werden.

Während channel sounding werden zwei Kanallisten geführt. Die erste wird nur bei CSA #3a und bei der Auswahl von Kanälen für Mode-0-Schritte verwendet. Die zweite wird für Nicht-Mode-0-Schritte mit CSA #3b oder CSA #3c verwendet.

CSA #3a und CSA #3b arbeiten auf identische Weise, aber mit unterschiedlichen Programmlisten. Beide verwenden denselben Algorithmus, der die Reihenfolge der als enthalten markierten Kanäle zufällig ändert, um eine gemischte Kanalliste zu erstellen. Jeder Eintrag in einer gemischten Kanalliste ist eindeutig und wird nur einmal verwendet. Wenn alle Einträge in der gemischten Kanalliste verwendet wurden, wird sie neu generiert und eine neue zufällige Kanalliste erstellt.

Der Algorithmus CSA #3c unterscheidet sich deutlich von CSA #3b. Teilmengen der in der Kanalkarte enthaltenen Kanäle werden in Gruppen organisiert und Kanalmuster innerhalb der Gruppen, die Formen bilden, werden generiert. Es werden zwei Mustertypen unterstützt, die mit " Hut" und " X" bezeichnet werden. CSA #3c kann unter bestimmten Umständen Vorteile bei der Erkennung reflektierter Signalwege bieten. Weitere Einzelheiten finden Sie in der Bluetooth Core Specification. Die Unterstützung für CSA #3c ist optional.

3.2.2.8 Der LE 2M 2BT PHY

Die physikalische Schicht von Bluetooth LE umfasst die Definition mehrerer zulässiger Konfigurationen, die als PHYs bekannt sind. Die Definition einer PHY umfasst das verwendete Modulationsschema und seine Parameter wie Symbolrate, minimale Frequenzabweichung und Bandbreiten-Bit-Perioden-Produkt (BT).

Vor der Version 6.0 der Bluetooth Core Specification gab es drei definierte PHYs. Ihre Namen sind LE 1M, LE 2M und LE Coded. Der LE Coded PHY ist identisch mit dem LE 1M, außer dass die Pakete einer zusätzlichen Kodierung unterzogen werden, die eine Fehlererkennung und -korrektur ermöglicht.

In Version 6.0 wurde eine neue Konfiguration der physikalischen Schicht namens LE 2M 2BT eingeführt. Diese neue PHY kann nur mit Bluetooth® Channel Sounding verwendet werden.

Ein Vergleich der vier PHYs findet sich in Tabelle 2.

 

LE 1M

LE Coded

LE 2M

LE 2M 2BT

Symbol Rate

1 Msym/s

1 Msym/s

2 Msym/s

2 Msym/s

BT

0.5

0.5

0.5

2.0

Min. Frequency Deviation

185 kHz

185 kHz

370 kHz

420 kHz

Error Detection

CRC

CRC

CRC

N/A

Error Correction

NONE

FEC

NONE

N/A

Requirement

Mandatory

Optional

Optional

Optional. Only to be used with Channel Sounding.

Tabelle 2 - Vergleich der PHYs

Das Bandbreiten-Bit-Perioden-Produkt (BT) ist ein Attribut eines Signals, das Informationen über das Verhältnis zwischen seiner Bandbreite und der Dauer der Symbole liefert.

BT beeinflusst die Form und die Spanne der Funkimpulse, die die Symbole bilden. Ein höherer BT-Wert führt zu einem schmaleren, quadratischeren Impuls und ein niedrigerer Wert zu einer breiteren, runderen Impulsform.

Ein BT-Wert von 2,0 verbessert die Sicherheit von channel sounding in Bezug auf bestimmte Arten von Angriffen auf die physikalische Schicht. Siehe . 3.2.2.10 Bluetooth® Channel Sounding Sicherheitsübersicht.

3.2.2.9 SNR-Steuerung für Channel Sounding Schritte

Einige Funksender sind in der Lage, ihr Signal-Rausch-Verhältnis (SNR) so einzustellen, dass es innerhalb eines bestimmten Bereichs liegt. Die SNR-Steuerungsfunktion ermöglicht es dem Initiator- und dem Reflektor-Gerät, einen SNR-Ausgangspegel zu vereinbaren, der während der CS-Modus-1- und Modus-3-Schritte für die CS-Sync-Paketübertragung verwendet werden soll. Bei der Einstellung des SNR wird dem Signal künstlich ein gewisses Maß an Rauschen beigemischt. Das Vorhandensein dieses Rauschens stellt für die beiden CS-Geräte kein Problem dar, da das Ausgangs-SNR beiden Geräten bekannt ist. Das Risiko einiger Arten von Main-in-the-Middle-Angriffen auf der physikalischen Schicht wird durch diese Technik verringert. 

3.2.2.10 Bluetooth® Channel Sounding Sicherheitsübersicht

Sicherheitsprobleme, die nur bei Lösungen zur Entfernungsmessung auftreten, betreffen in der Regel die Gefahr, dass nicht vertrauenswürdige Geräte einem vertrauenswürdigen Gerät vorgaukeln, ein anderes vertrauenswürdiges Gerät befinde sich in ausreichender Nähe, um eine bestimmte Aktion zuzulassen oder durchzuführen. Wenn beispielsweise bei einem schlüssellosen Zugangssystem ein bösartiges Gerät dem Türschloss vorgaukelt, die zugehörige vertrauenswürdige drahtlose Schlüsselkarte befinde sich in ausreichender Nähe, so dass die Tür automatisch entriegelt wird, könnte sich ein Unbefugter Zugang verschaffen.

Sicherheitsexperten kennen eine Reihe von Angriffen im Zusammenhang mit der Entfernungsmessung. Bei einigen handelt es sich um eigenständige bösartige Geräte, die die Kommunikation von einem vertrauenswürdigen Gerät fälschen (bekannt als Spoofing), und bei anderen handelt es sich um Arten von Man-in-the-Middle-Angriffen (MITM), die Signale von vertrauenswürdigen Geräten weiterleiten und dabei in der Regel das Signal oder seinen digitalen Inhalt manipulieren, um das vertrauenswürdige Gerät zu veranlassen, die Entfernung von ihm zu seinem vertrauenswürdigen Gegenstück falsch zu berechnen. Die Details solcher Angriffe variieren in ihrer Raffinesse sowie in der Komplexität und den Kosten für ihre Durchführung.

Bluetooth Channel Sounding umfasst eine Reihe von Merkmalen, die als Gegenmaßnahmen zu einer Reihe von Sicherheitsbedrohungen bei der Entfernungsmessung dienen können. Diese Merkmale können in vier Kategorien eingeteilt werden:

  1. Kombinierte Anwendung von PBR- und RTT-Methoden.
  • Die Berechnung von Entfernungen unter Verwendung von Daten aus dem Züchterrechtsverfahren und dem RTT-Verfahren ermöglicht eine Gegenprüfung der Werte. Ein signifikanter Unterschied sollte von der Anwendung mit Misstrauen behandelt werden. Angriffe, die auf beide Methoden abzielen und kompatible, hinreichend ähnliche Ergebnisse liefern, um eine Entdeckung durch eine Gegenprüfung zu vermeiden, gelten als sehr komplex und kostspielig in der Umsetzung.
  1. Randomisierung des Bitstroms und der Übertragungsmuster.
  • Zufällige Bitwerte werden an zufällig ausgewählten Positionen im Bitstrom übertragen. Die Werte und Positionen werden mit dem neuen Deterministic Random Bit Generator (DRBG) erzeugt oder ausgewählt. Initiator und Reflektor besitzen beide die gleichen IN-, IV- und PV-Werte (siehe 3.2.2.4 Bluetooth® Channel Sounding Initialisierung) und folglich erzeugen ihre jeweiligen Instanzen des DRBG beim Aufruf denselben Strom zufällig erzeugter Bits. Das bedeutet, dass die beiden legitimen Geräte wissen, welche zufälligen Bitwerte sie erwarten und wo sie diese finden können. Bösartige Geräte sind nicht im Besitz der IN-, IV- und PV-Werte und können diese Werte daher nur erraten. Die Wahrscheinlichkeit, alle zufälligen Teile des Bitstroms bei jedem Austausch zu erraten, ist sehr gering. Darüber hinaus werden einige Zeitschlitze nach dem Zufallsprinzip für die Übertragung genutzt oder nicht genutzt, was wiederum von DRBG kontrolliert wird und nur von den legitimen CS-Geräten vorhersehbar ist.
  1. Verteidigung gegen Symbolmanipulation
  • Bei bestimmten MITM-Angriffen werden Funksymbole so manipuliert, dass das Zielgerät die Entfernung zum anderen legitimen Gerät falsch berechnet. Solche Angriffe beruhen darauf, dass der Angreifer in einem Bruchteil einer Mikrosekunde Übertragungen aus dem Bereich der potenziellen HF-Kanäle findet und das Symbol dann schnell manipuliert.
  • Die Hinzufügung von Rauschen zu Übertragungen bei Verwendung der SNR-Kontrollfunktion erhöht die Verarbeitungszeit, die ein Angreifer für die Signalanalyse aufwenden muss. Wenn genügend zusätzliche Verarbeitungszeit erforderlich ist, wird der Angriff unwirksam gemacht.
  • Der LE 2M 2BT PHY hat eine kürzere Symbolspanne, wodurch es schwieriger ist, Symbole auf diese Weise abzufangen und zu manipulieren.
  1. RF-Signalanalysetechniken einschließlich der Erkennung von Angriffen.
  • Die Kernspezifikation Bluetooth enthält eine Beschreibung eines Angriffserkennungssystems für Bluetooth® Channel Sounding. Dazu gehört eine standardisierte Metrik für die Meldung der Wahrscheinlichkeit, dass ein Angriff auf die Anwendungsschicht erfolgt. Diese Metrik wird als Normalized Attack Detector Metric oder NADM bezeichnet. Ein NADM-Wert wird vom Controller auf der Grundlage der Auswertung des empfangenen Signals zugewiesen und hat die Form einer gleitenden Skala, die die Angriffswahrscheinlichkeit in einem Bereich angibt, der mit "Angriff ist extrem unwahrscheinlich" beginnt und sich bis "Angriff ist extrem wahrscheinlich" an der obersten Grenze erhöht. Tabelle 3 enthält die Definitionen der NADM-Werte, die aus der Bluetooth Core Specification übernommen wurden.
NADM Value Description

0x00

Attack is extremely unlikely

0x01

Attack is very unlikely

0x02

Attack is unlikely

0x03

Attack is possible

0x04

Attack is likely

0x05

Attack is very likely

0x06

Attack is extremely likely

0xFF

Unknown NADM.

Default value for RTT types that do not have a random sequence or sounding sequence.

Tabelle 3 - NADM-Werte

Darüber hinaus können die Implementierer von Bluetooth und die Entwickler von Anwendungen die Standard-Sicherheitsfunktionen, die von Bluetooth Channel Sounding bereitgestellt werden, bei Bedarf durch zusätzliche Schutzmaßnahmen ergänzen.

3.2.3 Weitere Informationen zu Bluetooth® Channel Sounding

Für eine ausführlichere Betrachtung der Funktion Bluetooth Channel Sounding wurde von der Bluetooth SIG ein Papier zu diesem Thema erstellt. Es trägt den Titel Secure Fine Ranging with Bluetooth® Channel Sounding und kann von der WebsiteBluetooth SIG heruntergeladen werden.

Die Bluetooth Kernspezifikation ist die einzige Referenz für Implementierer.

4. Entscheidungsbasierte Werbefilterung

4.1 Hintergrund

In diesem Abschnitt werden Aspekte der Bluetooth LE-Technologie erläutert, die für die entscheidungsbasierte Werbefilterung (DBAF) relevant sind.

4.1.1 Zustände der Verbindungsschicht

Die Verbindungsschicht ist einer der anspruchsvollsten Teile des Bluetooth LE-Stacks. Sie definiert Pakete und PDUs für die Übertragung über die Luft sowie Muster für das Verhalten von Sendern und Empfängern, die Teil der Definition der verschiedenen logischen Transporte sind.

Ein Gerät verfügt über eine oder mehrere Instanzen der Sicherungsschicht, und jede Instanz befindet sich zu einem bestimmten Zeitpunkt in einem bestimmten Zustand. Die Zustände und die zulässigen Übergänge zwischen ihnen werden durch die Zustandsmaschine der Sicherungsschicht definiert.

Abbildung 9 - Die Link Layer State Machine

Tabelle 4 enthält eine kurze Beschreibung der einzelnen Zustände der Verbindungsschicht.

State

Description

Standby

Device neither transmits nor receives packets.

Initiating

Responds to advertising packets from a particular device to request a connection.

Advertising

Transmits advertising packets and potentially processes packets sent in response to advertising packets by other devices.

Connection

In a connection with another device.

Scanning

Listening for advertising packets from other devices.

Isochronous Broadcast

Broadcasts isochronous data packets.

Synchronization

Listens for periodic advertising belonging to a specific advertising train transmitted by a particular device.

Tabelle 4 - Zustandsbeschreibungen der Verbindungsschicht

Die Zustände Anzeigen, Scannen und Initiieren sind für das DBAF-Merkmal von Bedeutung.

4.1.2 Filterrichtlinien

Eine Filterrichtlinie definiert Kriterien, nach denen die Verbindungsschicht entscheidet, ob sie empfangene Pakete annimmt und an die nächste Verarbeitungsstufe weiterleitet. Es gibt eine Reihe von Filterrichtlinien, die in verschiedenen Zuständen verwendet werden können. Die Filterrichtlinien können vom Host mit HCI-Befehlen ausgewählt und konfiguriert werden.

Für DBAF sind die in den Zuständen der Scan- und Initiator-Verbindungsschicht verwendeten Filterrichtlinien von Bedeutung.

Im Scanning-Zustand wendet die Instanz der Verbindungsschicht eine Scanning-Filterrichtlinie auf empfangene Werbepakete an. Vor der Hinzufügung der DBAF-Funktion wurden zwei grundlegende Scanning-Filter-Richtlinien definiert. Die ungefilterte Scanning-Filterpolitik führt dazu, dass alle empfangenen Werbepakete akzeptiert werden. Bei der gefilterten Scanning-Filter-Policy werden nur die Werbepakete von Geräten akzeptiert, die in einer Filter-Akzeptanzliste (die vom Host ausgefüllt wird) aufgeführt sind. Eine erweiterte Scanning-Filter-Richtlinie ist für die Verwendung mit gerichteter Werbung definiert, bei der die PDUs die Adresse des Zielgeräts enthalten, an das das Werbepaket gerichtet ist.

Eine Initiator-Filter-Richtlinie ähnelt einer Scanning-Filter-Richtlinie, ist aber dazu gedacht, die verbindungsfähigen Werbe-PDUs auszuwählen[3] auswählen, auf die als Antwort eine Verbindungsanfrage gesendet werden könnte. Vor dem DBAF wurden zwei Initiator-Filter-Richtlinien definiert. Im ersten Fall werden nur verbindungsfähige Werbepakete von einem bestimmten Gerät ausgewählt. Im zweiten Fall werden verbindungsfähige Werbepakete von allen Geräten, die in der Filter-Akzeptanzliste enthalten sind, akzeptiert.

In allen Fällen führt die Anwendung einer Filterpolitik zu einer Entscheidung der Verbindungsschicht, ein empfangenes Paket entweder anzunehmen oder zu verwerfen.

4.1.3 Erweiterte Werbung

In der Kernspezifikation von Bluetooth sind mehrere Formen der Werbung definiert. Der logische Transport von Advertising Broadcast (ADVB) beinhaltet die Übertragung von Werbepaketen nach einem leicht randomisierten Zeitplan. ADVB hat eine Grundform, die als Legacy Advertising bekannt ist, und eine anspruchsvollere Variante, die als Extended Advertising bezeichnet wird.

Bei der Legacy-Werbung werden Pakete nur auf den drei primären Werbekanälen mit den Kanalindexwerten 37, 38 und 39 übertragen, die anderen sekundären Werbekanäle bleiben unberücksichtigt.

Die erweiterte Werbung nutzt alle 40 RF-Kanäle von Bluetooth LE. Kopfdaten werden auf den primären Kanälen in einem PDU-Typ übertragen, der als ADV_EXT_IND PDU bekannt ist. Dieser PDU-Typ enthält nicht das AdvData-Feld und trägt daher keine Anwendungsdaten-Nutzlast. Stattdessen enthält sie oft ein Feld namens AuxPtr, das auf ein zugehöriges Hilfspaket verweist, das eine AUX_ADV_IND-PDU enthält und auf einem der 37 sekundären Werbekanäle übertragen wird. Diese PDU enthält das Nutzdatenfeld AdvData.

AuxPtr enthält einen Kanalindexwert, der den Kanal angibt, auf dem das Hilfspaket übertragen wird, den verwendeten PHY und einen Zeitversatz, damit die Empfänger wissen, wann, wo und wie sie es empfangen sollen. Pakete, die auf einem sekundären Kanal übertragen werden und durch das AuxPtr-Feld von einem Paket auf den primären Kanälen referenziert werden, werden als Hilfspakete bezeichnet, während das referenzierende Paket als übergeordnetes Paket bezeichnet wird.

Größere Anwendungsdaten-Nutzdaten können fragmentiert und als Serie von verbundenen PDUs gesendet werden. Die Serie beginnt mit einer AUX_ADV_IND-PDU und wird mit einer Reihe von AUX_CHAIN_IND-PDUs fortgesetzt. Die AUX_ADV_IND-PDU und jede nachfolgende AUX_CHAIN_IND-PDU sind über das Feld AuxPtr miteinander verbunden. Abbildung 10 zeigt ein Beispiel für eine erweiterte Werbung mit PDU-Verkettung.

Abbildung 10 - Erweiterte Werbung mit PDU-Verkettung

Erweiterte Werbe-PDUs wie ADV_EXT_IND enthalten einen erweiterten Header. Dieser enthält eine Reihe von Feldern, deren Vorhandensein in der PDU obligatorisch, optional oder bedingt ist, je nach den Regeln, die in der Bluetooth Core Specification festgelegt sind.

4.1.4 Der auslösende Staat

Im Initiating State versucht ein Gerät, vom Scanning State in den Connection State zu wechseln. Dies geschieht, indem es auf eine verbindungsfähige Werbe-PDU des Zielgeräts wartet und nach Erhalt einer solchen mit einer CONNECT_IND-PDU (Legacy Advertising) oder einer AUX_CONNECT_REQ-PDU (Extended Advertising) antwortet.

4.1.5 Probleme

DBAF verbessert die effektive Einschaltdauer von Scannern in Situationen, in denen längere Zeit Werbung geschaltet wird. Dies wird erreicht, indem ein Problem angegangen wird, das als Ablenkung bekannt ist.

4.1.5.2 Ablenkungen

4.1.5.2.1 Was ist eine Ablenkung?

ADV_EXT_IND-PDUs, die auf den Primärkanälen übertragen werden, enthalten keine Daten der Anwendungsschicht. In bestimmten Fällen muss der Beobachter (das scannende Gerät) AuxPtr folgen, die zugehörige Auxiliary-PDU auf dem Sekundärkanal empfangen und den Inhalt des AdvData-Nutzdatenfeldes untersuchen, bevor er entscheiden kann, ob die angekündigten Daten von Interesse sind oder nicht. Dazu muss er das Scannen auf den primären Kanälen beenden und zum Scannen auf dem im AuxPtr-Feld angegebenen sekundären Kanal wechseln.

Je nach Szenario kann sich herausstellen, dass die angekündigten Daten in den meisten Fällen nicht von Interesse sind. Dies liegt daran, dass der Beobachter während der Zeit, in der er den von AuxPtr angegebenen sekundären Kanal abfragte, die primären Kanäle nicht mehr abfragte und daher möglicherweise Pakete verpasste, die relevant waren.

Diese Situation, in der nach AuxPtr ein Paket gesucht und empfangen wird, das für die Anwendungsschicht nicht von Interesse ist, wird als Ablenkung bezeichnet.

Ablenkungen reduzieren den effektiven Arbeitszyklus des Beobachters. Fehlende Pakete auf den primären Kanälen aufgrund von Ablenkungen können die Gesamtdatenübertragungsrate von Geräten verringern, die erweiterte Werbung als verbindungslosen Datentransfermechanismus verwenden, und die Latenzzeit in anderen Fällen erhöhen.

4.1.5.2.2 Werbesätze und doppelte Daten

Das erweiterte Header-Feld von erweiterten Advertising-PDUs enthält ein optionales Feld namens AdvDataInfo (ADI). ADI enthält zwei Unterfelder, Advertising Data ID (DID) und Advertising Set ID (SID). SID identifiziert ein Werbeset, zu dem eine übertragene PDU gehört. DID enthält eine Zufallszahl, die sich nur dann ändert, wenn eine PDU, die von demselben Werbungsgerät übertragen wird und zum selben Werbungssatz gehört, neue Daten enthält.

AdvDataInfo kann in ADV_EXT_IND-PDUs enthalten sein, die auf dem Primärkanal übertragen werden und denen ein Hilfspaket zugeordnet ist. Dies gibt den scannenden Geräten die Möglichkeit, nur PDUs auszuwählen, die zu dem betreffenden Werbesatz gehören, und doppelte Daten zu erkennen, die sie bereits empfangen haben. Wenn eine dieser Bedingungen zutrifft, kann der Beobachter die Suche nach dem Hilfspaket auf den Sekundärkanälen vermeiden.

Das AdvDataInfo-Feld trägt dazu bei, eine unnötige Suche auf sekundären Kanälen zu vermeiden, ist aber für einige Szenarien ein nicht ausreichend ausgefeilter Mechanismus.

4.2 Über entscheidungsbasierte Werbefilterung

4.2.1 Überblick

DBAF führt einen neuen Typ erweiterter Werbe-PDU namens ADV_DECISION_IND ein, der informell als Entscheidungs-PDU bezeichnet wird. Dieser PDU-Typ soll anstelle der erweiterten Werbe-PDUs ADV_EXT_IND verwendet werden und wird in ähnlicher Weise auf den Primärkanälen übertragen.

Entscheidungs-PDUs enthalten anwendungsspezifische Daten, die ein Scanner auswerten kann, um eine fundiertere Entscheidung darüber zu treffen, ob ein zugehöriges AUX_ADV_IND-Hilfspaket von Interesse ist oder nicht, und somit, ob mit dem Scannen auf dem Sekundärkanal, auf den das AuxPtr-Feld verweist, begonnen werden soll oder nicht.

Das werbende Gerät kann den Inhalt der Entscheidungs-PDUs so konfigurieren, dass die angeschlossenen Geräte leicht überprüfen können, ob die empfangenen Pakete relevant sind oder nicht.

Scanning-Geräte können ihre Filterrichtlinien so konfigurieren, dass sie eine Reihe von logischen Prüfungen auf den Inhalt der empfangenen Entscheidungs-PDUs anwenden, so dass relevante Pakete zuverlässig identifiziert und zugehörige Hilfspakete gescannt werden können, um ihre Anwendungsnutzdaten zu erhalten.

Abbildung 11 - Ein Überblick über DBAF

4.2.2 Vorteile

Die Vorteile von DBAF ergeben sich aus der besseren Kontrolle, die die Anwendungen über die Filterung der empfangenen Pakete durch den Controller haben. Diejenigen Entscheidungs-PDUs, die die anwendungsspezifischen Filterprüfungen nicht bestehen, werden verworfen, und es findet kein Scannen nach Hilfspaketen statt, wodurch eine Ablenkung vermieden wird.

Die Verwendung von Entscheidungs-PDUs anstelle von ADV_EXT_IND-PDUs für erweiterte Werbung hat das Potenzial, den effektiven Arbeitszyklus erheblich zu verbessern und das Auftreten verpasster Pakete auf primären Kanälen aufgrund des Ablenkungsproblems zu verringern. Dies wird sich besonders in Umgebungen bemerkbar machen, in denen eine große Anzahl von Werbegeräten mit erweiterter Werbung vorhanden ist.

In den Fällen, in denen die erweiterte Werbung als Basis für die Datenübertragung verwendet wird (z. B. als Nachrichtenübermittlung), werden die Datendurchsatzraten nicht durch Übertragungen beeinträchtigt, die sonst als Ablenkung dienen würden.

4.2.3 Technische Highlights

4.2.3.1 Werbung

4.2.3.1.1 Entscheidungs-PDUs

Entscheidungs-PDUs, formal bekannt als ADV_DECISION_IND-PDUs, werden in Link-Layer-Paketen entweder über den LE 1M oder den LE Coded PHY übertragen. Abbildung 12 zeigt die Struktur der ADV_DECISION_IND-PDU und wie sie in einem Link-Layer-Paket über den LE 1M (uncodierten) PHY untergebracht ist.

Abbildung 12Abbildung 12 - Das unverschlüsselte LE-Paket der Verbindungsschicht und die ADV_DECISION_IND-PDU

Die Felder AdvMode und Extended Header erscheinen in allen erweiterten Werbe-PDUs. AdvMode gibt den Typ des Werbeereignisses an oder welche drei Werte definiert sind.

AdvMode

Mode

0b00

Non-connectable and non-scannable

0b01

Connectable and non-scannable

0b10

Non-connectable and scannable

0b11

Reserved for future use

Das erweiterte Header-Feld enthält verschiedene Standardfelder, deren Vorhandensein oder Fehlen von Faktoren wie dem PDU-Typ, dem Werbemodus, dem PHY und den Anwendungspräferenzen abhängt. Das AdvDataInfo (ADI)-Feld, das DID enthält und zur Identifizierung doppelter Daten dient, ist ein erweitertes Header-Feld.

AuxPtr ist das einzige erweiterte Header-Feld, das in Entscheidungs-PDUs enthalten sein muss.

Die Felder, die für die Entscheidungs-PDU spezifisch sind, sind das Feld Decision Type Flags und das Feld Decision Data.

Das Scanning-Gerät kann angeben, welche Überprüfungen an empfangenen Entscheidungs-PDUs vorzunehmen sind, und solche Überprüfungen können Felder aus dem erweiterten Header, die Signalstärke (RSSI) oder ergänzende Daten bestimmter Typen umfassen, die von dem werbenden Gerät im Feld Entscheidungsdaten bereitgestellt werden.

Entscheidungsdaten enthält Standard-Unterfelder, von denen derzeit nur eines angegeben ist. Dies ist das Feld Resolvable Tag. Weitere Unterfelder können in Zukunft definiert werden. Platz, der nicht durch Standard-Unterfelder wie Resolvable Tag verbraucht wird, kann für zusätzliche, beliebige Daten verwendet werden.

Abbildung 13 - Das Feld Entscheidungsdaten

Das Feld Decision Type Flags zeigt an, welche Teilfelder im Feld Decision Data vorhanden sind. Ein gesetztes Bit zeigt das Vorhandensein des jeweiligen Teilfeldes an, das in der Spezifikation von Bluetooth der Bitposition innerhalb des Feldes zugeordnet wurde. Das Bit an der Position Null bezieht sich auf das Unterfeld "Resolvable Tag". Alle anderen Bits sind für die zukünftige Verwendung reserviert (RFU).

4.2.3.1.2 Konfigurieren von Entscheidungs-PDUs

Der Host des Werbetreibenden ist für die Konfiguration und Initiierung von Werbung mittels Entscheidungs-PDUs verantwortlich.

Die Werte für die Felder Decision Type Flags und Decision Data müssen vom Host bereitgestellt werden. Dies wird mit dem HCI-Befehl LE Set Decision Data erreicht. Die Parameter dieses Befehls sind der Advertising Handle, der das Werbeset identifiziert, Decision Type Flags, Decision Data Length und Decision Data. Dieser Befehl kann jederzeit aufgerufen werden, nachdem die Werbemittelgruppe erstellt wurde, auch nachdem die Werbung bereits begonnen hat. Das bedeutet, dass die Anwendungsschicht die Entscheidungsdatenfelder bei Bedarf ändern kann.

Der HCI-Befehl LE Set Extended Advertising Parameters wird verwendet, um die primären Variablen eines Werbesatzes zu konfigurieren, z. B. das Werbeintervall. Einer der Parameter des Befehls, Advertising_Event_Properties, ist eine Bitmaske, die verschiedene Host-Anforderungen in Bezug auf das konfigurierte Advertising-Set angibt. Ist z. B. Bit 0 gesetzt, bedeutet dies, dass der Host vom Controller verlangt, einen verbindungsfähigen Werbemodus zu verwenden. Wenn Bit 1 gesetzt ist, sollte die Werbung durchsuchbar sein.

Die Definition des Parameters Advertising Event Properties wurde aktualisiert, damit die Bits 7, 8 und 9 in Verbindung mit Entscheidungs-PDUs verwendet werden können. In Tabelle 5 ist die Bedeutung dieser Bits zusammengefasst.

Bit

Meaning

7

Use decision PDUs when advertising

8

Include AdvA in the extended header of all decision PDUs

9

Include ADI in the extended header of all decision PDUs

Tabelle 5 - Eigenschaften von Werbeereignissen und Entscheidungs-PDUs

Wie gezeigt, kann der Host mit Hilfe des Bits 7 der Werbeereigniseigenschaften den Controller anweisen, Entscheidungs-PDUs in relevanten Werbeereignissen zu übertragen. Aufgrund der Ausgereiftheit der Entscheidungs-PDU-Prüfungen, die für die Verwendung durch den Controller des abtastenden Geräts spezifiziert werden können, kann die Geräteadresse des Werbetreibenden und/oder das ADI-Feld überflüssig sein, und die Bits 8 und 9 ermöglichen es, eines oder beides auszuschließen, was die Pakete um 8 Oktette und ihre Sendezeit um 64 µs über LE 1M verkürzen kann.

4.2.3.2 Scannen

4.2.3.2.1 Modi der Entscheidungs-Scan-Filterpolitik

Wenn eine Anwendung auf dem Scangerät eine entscheidungsbasierte Werbefilterung verwenden möchte, muss sie dies der Steuerung Bluetooth mitteilen. Dies geschieht mit dem Befehl HCI LE Set Extended Scan Parameters und den Bits 2 und 3 des Parameters Scanning Filter Policy.

Mit diesen Bits kann einer von drei Modi ausgewählt werden.

Value

Meaning

0b00

No decisions mode. In this mode, decision PDUs are ignored.

0b01

All-PDUs mode. All types of advertising PDU are selected. Decision PDUs are subject to checks specified by the host. Other advertising PDUs are subject to the basic filter policy.

0b11

Decisions-only mode. Only decision PDUs are selected. These are subject to checks specified by the host. Those that pass are reported to the host in HCI advertising reports. Those that fail are discarded.

4.2.3.2.2 Entscheidungsanweisungen

Die Anwendung auf dem scannenden Gerät verwendet den Befehl LE Set Decision Instructions, um Tests festzulegen, die die Verbindungsschicht bei der Ausführung der Filterrichtlinie auf Entscheidungs-PDUs anwenden muss.

Drei Array-Parameter für den Befehl ermöglichen es dem Host, die durchzuführenden Tests zu konfigurieren.

Parameter

Meaning

Test_Flags[i]

The first 4 bits of this field have defined meanings.

Bit 0 – Creates partitioned groups of tests. See below.

Bit 1 – The test passes if the decision data contains the relevant field and the check made against its value passes.

Bit 2 – The test passes if the decision data contains the relevant field and the check made against its value fails.

Bit 3 – The test passes if the decision data does not contains the relevant field.

 

The value in Test_Field[i] identifies the relevant field. Note that the term “relevant field” applies both to fields in the advertising PDU that may be used in decision checks and values which may be measured (e.g. RSSI) or otherwise calculated (e.g. path loss) and used in decision checks.

 

Test_Field[i]

Identifies the decision data against which the check will be made. The data available for use in decision tests are:

  • Resolvable Tag subfield in Decision Data
  • AdvMode – advertising mode
  • RSSI – received signal strength indicator
  • Path loss calculated from the TX Power field (which must be present) and RSSI
  • AdvA — the advertising device’s address
  • Arbitrary Data (with various options re: minimum length of such data for the field to be regarded as present)
  • Vendor-specific

Test_Parameters[i]

Values to use in checks against the relevant field. The format of this field depends on the relevant field identified in the Test_Field[i] parameter.

 

4.2.3.2.3 Testgruppen

Die durch die drei Parameter-Arrays Test_Flags, Test_Field und Test_Parameters dargestellte Testreihe wird in eine oder mehrere Testgruppen unterteilt.

Der erste Test, der durch Test_Flags[0], Test_field[0] und Test_Parameters[0] dargestellt wird, ist Mitglied der ersten Testgruppe. Wenn das erste Bit von Test_Flags[i] gesetzt ist, gehört er zu einer neuen Testgruppe. Wenn es nicht gesetzt ist, gehört er zur gleichen Gruppe wie der vorherige Test in den Arrays, auf den der Indexwert [i - 1] verweist. Tabelle 1 zeigt ein Beispiel.

Index

Test Flags

Group Membership

0

0b0011

Start of a new group (bit 0 = 1).

1

0b0010

Test is a member of same group as test[0].

2

0b0011

Start of a new group (bit 0 = 1).

3

0b0100

Test is a member of same group as test[2].

4

0b0010

Test is a member of same group as test[2].

Tabelle 6 - Beispiel für die Gruppenzugehörigkeit, gesteuert durch Test_Flags Bit Null

Wenn einer der Tests, die zu derselben Gruppe gehören, nicht bestanden wird, gelten alle Tests der Gruppe als nicht bestanden.

4.2.3.2.4 Testauswertung

Beachten Sie, dass in der folgenden Beschreibung ein Test eine Bedingung ist, die in parallelen Elementen der Parameterarrays Test_Flags, Test_Field und Test_Parameters kodiert ist. Eine Prüfung ist die Auswertung eines Tests anhand bestimmter Werte, die aus einer bestimmten Entscheidungs-PDU gewonnen oder abgeleitet wurden.

Die Verbindungsschicht wertet die DBAF-Tests für jede empfangene Entscheidungs-PDU wie folgt aus:

Für jeden vom Host angegebenen Test wird zunächst die Verfügbarkeit des entsprechenden Feldes geprüft. Dabei kann es sich um das Vorhandensein eines Feldes in der empfangenen PDU handeln oder um die Möglichkeit, den angegebenen Wert, der im Test verwendet werden soll, zu berechnen oder zu messen. Bit 3 in Test_Flags[i] zeigt an, ob das Fehlen des erforderlichen Feldes bedeutet, dass der Test bestanden oder nicht bestanden werden sollte.

Wenn das betreffende Feld vorhanden ist, wird die in Test_Field[i] und Test_Parameters[i] kodierte Prüfung ausgewertet. Die Bits 1 und 2 werden verwendet, um festzustellen, ob eine bestandene oder fehlgeschlagene Prüfung bedeutet, dass der Test, für den die Prüfung durchgeführt wurde, bestanden oder nicht bestanden wurde.

Gruppen ermöglichen die Angabe von zusammengesetzten Bedingungen, bei denen jeder Test in der Gruppe mit anderen in derselben Gruppe mit einem logischen UND verknüpft ist. Mit anderen Worten: Alle Tests in einer Gruppe müssen bestanden werden, damit die Gruppe als Ganzes bestanden ist.

(group 1 test 1) AND (group 1 test 2) AND (group 1 test 3)

Tabelle 7 - Logische Beziehung zwischen Tests in derselben Gruppe

Im Zusammenhang mit dem vollständigen Satz von Testanweisungen gilt, wenn eine oder mehrere Gruppen von Tests bestehen, der gesamte Satz von Tests als bestanden. Mit anderen Worten: Jede Gruppe ist mit anderen Gruppen durch ein logisches ODER verbunden.

(group 1) OR (group 2) OR (group 3) OR (group 4)

 

Die Kombination aus der Möglichkeit, einzelne bedingte Prüfungen auf der Grundlage von Feldern in einer Entscheidungs-PDU oder daraus abgeleiteten Werten zu formulieren, und der Möglichkeit, komplexere zusammengesetzte Bedingungen auf der Grundlage einer Reihe von Testgruppen zu kodieren, macht DBAF zu einem leistungsfähigen Filtermechanismus für Anwendungen.

4.2.3.2.5 Arbeiten mit relevanten Feldern

Wie genau eine Prüfung durchgeführt wird und wie der Inhalt des Eintrags Test_Parameters[i] formatiert wird, hängt von dem jeweiligen Feld ab, das durch Test_Field[i] angegeben wird. Die Bluetooth Core Specification enthält alle Einzelheiten zu den Formaten und Regeln, die hier für jede Art von relevantem Feld zusammengefasst werden.

Auflösbarer Tag

Test_Parameters[i]

PDU Data

Check

A 128-bit key value.

Decision Data contains a hash value and a pseudo random number (prand).

Check passes if hash value equals the value obtained by evaluating ah (key, prand). ah is a hashing function defined in the core specification.

AdvMode

Test_Parameters[i]

PDU Data

Check

A 3-bit Event Type value. The three bits act as flags that map to the three possible values of the AdvMode field.

AdvMode is included in the decision PDU.

Check passes if AdvMode is any of the values indicated by an EventType flag as accepted.

RSSI

Test_Parameters[i]

PDU Data

Check

A range of RSSI values expressed as a minimum and a maximum in dBm.

Measured by the controller for each received packet.

Check passes if the measured RSSI falls within the range specified in the test.

Pfadverlust

Test_Parameters[i]

PDU Data

Check

A range of path loss values expressed as a minimum and a maximum in dBm.

 

Calculated by the controller as the difference between the TX Power field in the received PDU and the RSSI for that packet.

Check passes if the calculated path loss falls within the range specified in the test.

AdvA

Test_Parameters[i]

PDU Data

Check

Contains a field called Check that indicates how to check the AdvA address field in the received decision PDU and zero, one or two test address values and types.

 

AdvA is a field which may be included in decision PDUs.

Depending on the Check parameter field, evaluation of the check will pass if either:

1.      AdvA in the PDU is in the controller’s Filter Accept List.

2.      AdvA in the PDU matches the first of two possible addresses in the Test_Parameters[i] field.

3.      AdvA in the PDU matches either of the  two addresses in the Test_Parameters[i] field.

Beliebige Daten

Test_Parameters[i]

PDU Data

Check

Contains an 8-octet Mask and an 8-octet Target value.

 

The decision PDU Decision Data field contains an Arbitrary Data subfield.

The controller performs a bitwise AND of the Mask and the Arbitrary Data value (zero-padded if necessary). If the result matches the Target parameter, the check passes.

Anbieterspezifisch

Die Interpretation des Wertes von Test_Parameters[i] und die im Test angewandte bedingte Logik ist definitionsgemäß herstellerspezifisch.

4.2.3.2.6 Auflösbare Tags und gemeinsame Nutzung von Schlüsseln

Auflösbare Tags bieten eine einfache Möglichkeit, PDUs als relevant für eine bestimmte Anwendung und ein bestimmtes Gerät zu kennzeichnen. Damit dieses System funktioniert, muss der Schlüsselwert, der für die Hash-Erzeugung und -Prüfung verwendet wird, von den entsprechenden Geräten gemeinsam genutzt werden. Der Mechanismus und das Verfahren dafür werden in zukünftigen GATT-Attributen und Profilspezifikationen definiert.

4.2.3.3 Veranlassung

Der Host konfiguriert die auslösende Filterrichtlinie des Lotsen so, dass sie auf verschiedene Arten funktioniert, von denen einige Entscheidungs-PDUs beinhalten. Sind Entscheidungs-PDUs an der Richtlinie beteiligt, erfolgt die Verarbeitung der empfangenen PDUs im Hinblick auf die Anwendung von Entscheidungsanweisungen auf die gleiche Weise wie im Scanning-Status. 

5. Überwachung der Inserenten

5.1 Hintergrund

In diesem Abschnitt werden Aspekte der Bluetooth LE-Technologie erläutert, die für die Funktion zur Überwachung von Werbeträgern relevant sind. 

5.1.1 Geräteerkennung

Einer der Zwecke der Werbung in Bluetooth LE ist es, die Geräteerkennung zu erleichtern. Indem ein Gerät in regelmäßigen Abständen kleine Datenpakete sendet, informiert es andere Geräte, die sich in Reichweite befinden, über seine Anwesenheit. Gleichzeitig können die Geräte auch anzeigen, dass sie bereit und in der Lage sind, eine Verbindung von anderen Geräten zu akzeptieren.

Die Erkennung anderer Geräte wird durch Scannen erreicht. Beim Scannen wird das Funkgerät des Geräts in Intervallen und für einen bestimmten Zeitraum in den Empfangsmodus versetzt, in dem es auf Übertragungen in den primären Bluetooth LE-Kanälen lauscht. Wenn ein werbendes Gerät ein Paket auf einem Kanal sendet, den das scannende Gerät zu diesem Zeitpunkt abhört, empfängt das scannende Gerät das Paket und das werbende Gerät kann als entdeckt bezeichnet werden.

Werbung zum Zweck der Geräteerkennung ist eine grundlegende Idee der Bluetooth LE-Technologie.

Abbildung 14 - Werbung und Scannen

5.1.2 Verbinden

Nachdem ein Werbegerät entdeckt wurde, versucht das Scan-Gerät in einem nächsten Schritt, eine Verbindung mit dem Werbegerät herzustellen, möglicherweise als Reaktion auf eine Aktion des Benutzers, z. B. die Auswahl des Geräts aus einer Liste.

Der Verbindungsaufbau erfolgt durch Senden einer CONNECT_IND-PDU als Antwort auf eine ältere Werbe-PDU wie eine ADV_IND-PDU oder durch Senden einer AUX_CONNECT_REQ-PDU als Antwort auf eine erweiterte Werbe-PDU AUX_ADV_IND. In beiden Fällen wird die Verbindungsanfrage auf demselben Kanal gesendet wie die PDU, auf die geantwortet wird.

Damit eine PDU empfangen werden kann, auf die eine Verbindungsanfrage gesendet werden kann, muss das verbindende Gerät zuerst scannen. Oft ist es wünschenswert, dass die Verbindung schnell zustande kommt, und zu diesem Zweck wird eine Abtastung mit hohem Tastverhältnis verwendet. Dabei wird das Funkgerät für einen hohen Anteil der Zeit eingeschaltet und im Empfangsmodus gehalten, um die Wahrscheinlichkeit zu maximieren, dass eines der gewünschten verbindungsfähigen Werbepakete so schnell wie möglich empfangen wird. Das Scannen im Allgemeinen ist ein relativ stromhungriger Vorgang, das Scannen mit hohem Tastverhältnis noch mehr.

Abbildung 15 - Anschließen

5.1.3 Reichweite

Ein Scanning-Gerät kann nur dann Pakete von einem Werbegerät empfangen und darauf antworten, wenn sich die beiden Geräte in Reichweite zueinander befinden. Die Reichweite hängt von einer Reihe von Faktoren wie der Sendeleistung, der Empfindlichkeit des Empfängers und der Beschaffenheit der Umgebung ab. Die Reichweite eines Geräts, das als Sender fungiert, ist möglicherweise nicht dieselbe wie die Reichweite eines Empfängers. Und die Reichweite des anderen Geräts, mit dem kommuniziert wird, kann von der Reichweite des ersten Geräts abweichen.

Außerhalb der Reichweite zu sein, bedeutet nicht unbedingt, dass das von einem anderen Gerät gesendete Signal nicht empfangen wird. Ein Gerät kann zwar die Übertragung eines anderen Geräts empfangen, aber wenn das Verhältnis zwischen der Stärke des empfangenen Signals und dem Hintergrundrauschen (d. h. das Signal-Rausch-Verhältnis oder SNR) den Empfänger daran hindert, Daten aus der Übertragung zu extrahieren, ohne dass eine zu hohe Fehlerquote auftritt, dann gelten die beiden Geräte als außer Reichweite, denn das sind sie in jeder Hinsicht.

Wie in 3.1.1 Ortungsdienste und Bluetooth LE beschrieben, kann der RSSI als grober Näherungswert für die Entfernung dienen und bei der Berechnung des Pfadverlusts verwendet werden. Für einige Anwendungen ist eine Verbindung zu einem anderen Gerät nur dann sinnvoll, wenn es sich sowohl in Reichweite als auch in ausreichender Nähe befindet. Der Anwendungsfall kann bei dieser Beurteilung eine wichtige Rolle spielen. Vielleicht ist es nur sinnvoll, eine Verbindung herzustellen, wenn sich der Benutzer ganz in der Nähe des anderen Geräts befindet. Daher werden manchmal regelmäßig RSSI-Messungen durchgeführt und ausgewertet, bevor eine Anwendung sich nahe genug an einem anderen Gerät befindet, um eine Verbindung mit diesem herzustellen.

5.1.4 Duplikate filtern

Werbepakete werden von der Verbindungsschicht im Bluetooth LE-Controller empfangen, wenn sich die Verbindungsschicht im Abtastzustand befindet. Ein Werbegerät sendet wiederholt Pakete in einem konfigurierten Zeitintervall. Wenn sie zur Geräteerkennung verwendet werden, ändert sich der Inhalt der Werbepakete in der Regel nicht mit der Zeit.

Daten aus Werbepaketen, die von der Steuereinheit von einem oder mehreren Geräten empfangen werden, werden in einem HCI-Ereignis an den Host übermittelt. Für die Meldung von Werbedaten an den Host sind mehrere HCI-Ereignisarten definiert, und welche verwendet wird, hängt von der Art der Werbung ab. Bei Legacy-Werbung wird zum Beispiel das Ereignis LE Advertising Report verwendet. Bei erweiterter Werbung wird das Ereignis LE Extended Advertising Report verwendet. Bei periodischer Werbung werden die LE Periodic Advertising Report-Ereignisse verwendet.

Werbung, insbesondere von mehreren Geräten in der Umgebung, kann viele HCI-Werbeberichte generieren, die jeweils über einen internen Transport vom Controller zum Host weitergeleitet werden. Anwendungen, die sich über eine API für den Empfang von Werbedaten registrieren, können viele Rückrufe erhalten, wobei die in diesen Rückrufen gelieferten Daten unveränderlich und daher von fragwürdigem Wert sind.

Der wiederholte Empfang von unveränderlichen Werbepaketen von demselben Gerät hat jedoch einen gewissen Wert. So kann das scannende Gerät verfolgen, ob sich das andere Gerät gerade in Reichweite befindet.

Glücklicherweise haben die HCI-Befehle, mit denen der Host das Scannen aktivieren kann(LE Set Scan Enable und LE Set Extended Scan Enable), jeweils einen Parameter namens Filter_Duplicates. Damit kann der Host dem Controller mitteilen, ob ihm doppelte Werbeberichte gemeldet werden sollen.

Abbildung 16 zeigt, dass die Überprüfung durch den Host ohne aktivierte Duplikatfilterung aktiviert ist.

Abbildung 16 - Werbepakete und Berichte

Abbildung 17 zeigt die aktivierte Überprüfung mit eingeschalteter Duplikatfilterung. Beachten Sie, dass nur das erste empfangene Werbepaket dazu führt, dass ein Werbebericht an den Host gesendet wird.

Abbildung 17 - Filterung doppelter Werbe-PDUs

Die Option Filter_Duplicates wirkt auf alle Werbepakete von allen Geräten und es gibt keine Möglichkeit, sie nur auf ein bestimmtes Gerät anzuwenden, während alle Werbepakete von anderen Geräten ungefiltert bleiben.

Die Anwendungen haben also die Wahl. Die erste Option besteht darin, alle Werbeberichte zu empfangen und auf dem Laufenden zu halten, ob sich ein anderes Gerät in Reichweite befindet, aber in Kauf zu nehmen, dass dies eine Menge HCI-Verkehr und Rückrufe in den Anwendungscode erzeugt. Die Alternative besteht darin, die Meldung von doppelten Werbeberichten zu unterdrücken, aber sofort den Überblick darüber zu verlieren, ob sich das betreffende Gerät weiterhin in Reichweite befindet oder nicht. Keine dieser beiden Optionen ist ideal

5.1.5 Bluetooth LE Audio- und Akzeptorverfügbarkeit

In der Terminologie des Common Audio Profile (CAP) ist ein Acceptor ein Gerät, das einen Audiostrom von einem anderen Gerät, dem Initiator, annehmen kann. Es wird empfohlen, dass Initiatoren nicht die Filter-Akzeptanzliste (siehe 4.1.2 Filterrichtlinien) verwenden, da diese oft mit den Adressen von Geräten gefüllt ist, an die der Initiator gebunden ist. Persönliche Audiogeräte sind wahrscheinlich gebunden, aber bei LE Audio geht es um mehr als nur persönliches Audio.

Für ein optimales Nutzererlebnis sollte der Aufbau eines Audiostroms mit möglichst geringer Latenzzeit erfolgen. Daher ist es wünschenswert, zu verfolgen, ob sich ein Akzeptanzkandidat in Reichweite befindet oder nicht. Die Suche nach einem Audiogerät, nur um zu prüfen, ob es sich noch in Reichweite befindet, ist eine Zeit- und Energieverschwendung, die sich nachteilig auf die Latenzzeit und das Benutzererlebnis auswirkt.

LE Audio-Anwendungsfälle gehörten zu den Schlüsselszenarien, die bei der Entwicklung der Funktion zur Überwachung von Werbetreibenden eine Rolle spielten.

 

5.2 Über die Überwachung von Werbetreibenden

5.2.1 Überblick

Die Verwendung der Filter_Duplicates-Parameter zur Unterdrückung der Meldung von Werbepaketen, die mit einem bereits an den Host gemeldeten Paket identisch sind, lässt den Host im Unklaren darüber, ob das werbende Gerät noch in Reichweite ist, wenn es an der Zeit ist, eine Verbindung zu ihm herzustellen. Dem Verbindungsaufbau geht in der Regel ein teures Scannen mit hoher Einschaltdauer voraus, und wenn sich das Zielgerät nicht mehr in Reichweite befindet, war diese Aktivität eine reine Energieverschwendung. Die Funktion zur Überwachung von Werbeträgern löst dieses Problem.

Wenn die Funktion "Monitoring Advertisers" verwendet wird, weist der Host den Controller an, das Vorhandensein eines oder mehrerer Werbegeräte zu überwachen. Anstatt den Host mit einem Werbebericht pro empfangenem Werbepaket zu überfordern, informiert die Werbeüberwachung den Host einmal, wenn ein überwachtes Gerät die Reichweite verlässt und ein weiteres Mal, wenn es wieder in Reichweite kommt. Auf diese Weise kann eine Anwendung effizient die Geräte verfolgen, mit denen sie eine Verbindung herstellen möchte. Dabei werden auch die Anforderungen der Anwendung an die Signalstärke berücksichtigt.

Wenn die Anwendung beschließt, eine Verbindung zu einem der überwachten Geräte herzustellen, nachdem ihr mitgeteilt wurde, dass sich das Gerät in Reichweite befindet, ist das Scannen, das dem Verbindungsaufbau vorausgeht, wahrscheinlich keine vergebliche Mühe. Das Zielgerät sollte vorhanden und in Reichweite sein, so dass das Scannen ein Werbepaket ergibt, auf das eine Verbindungsanforderung als Antwort gesendet werden kann.

Die Überwachung von Werbemitteln funktioniert unabhängig von der Filter-Akzeptanzliste (siehe 4.1.2 Filterrichtlinien) und macht es daher einfach, die Filter-Akzeptanzliste nur für gebundene Geräte und die Überwachung von Werbemitteln für alle Geräte im Allgemeinen zu verwenden, unabhängig davon, ob sie mit dem scannenden Gerät verbunden sind oder nicht.

Es gibt viele Situationen und Produkttypen, die von der Funktion "Monitoring Advertisers" durch verbesserte Energieeffizienz und ein besseres Benutzererlebnis profitieren werden. LE-Audiogeräte, die einen Audiostrom initiieren(CAP-Initiatoren), sind eine Produktkategorie, für die diese Funktion definiert wurde.

5.2.2 Technische Highlights

5.2.2.1 Liste der überwachten Werbetreibenden

Die Bluetooth Core Specification definiert die Monitored Advertisers List. Dabei handelt es sich um eine Datenstruktur im Controller, die eine Liste der Werbegeräte enthält, die der Host im Auge behalten möchte.

Zu jedem Gerät in der Liste gibt es mehrere Parameter, und jeder Eintrag kann als ein zugehöriger Zeitgeber betrachtet werden. Darüber hinaus hat jeder Eintrag einen Status namens Awaiting RSSI High, der von der Implementierung gepflegt wird. Dieser Status zeigt an, ob sich das überwachte Gerät in Reichweite befindet. Wenn "Awaiting RSSI High" wahr ist, befindet sich das Gerät nicht in Reichweite. 

Ein Verständnis der Parameter in der Liste der überwachten Werbeträger vermittelt ein Verständnis dafür, wie die Überwachung durch den Controller funktioniert.

Parameter(s)

Description

Address and Address Type

The address and address type of the device to be monitored. These two parameters allow the controller to identify and monitor the device.

 

RSSI Threshold Low

If the RSSI of all advertising packets from this monitored device stays at or below this value for the period of time indicated by the Time Out parameter then it is said that a loss-of-signal has occurred. When this happens, the controller notifies the host using an HCI LE Monitor Advertisers Report event. The state of this device set to Awaiting RSSI High.

 

RSSI Threshold High

If the RSSI of an advertising packet received from this monitored device is greater than or equal to this value, and the device state is Awaiting RSSI High then the controller sends a HCI LE Monitor Advertisers Report event to the host to inform it that the device is in range. The state for this device is cleared or set to indicate that it is no longer awaiting an RSSI above the high threshold and the timer that is used to monitor for loss of signal is reset.

 

Time Out

A time in seconds used to monitor for signal loss. If no RSSI measurement exceeds the RSSI Threshold Low parameter in this period then loss-of-signal is said to have occurred.

 

 

5.2.2.2 Host-Controller-Schnittstelle

Der Host konfiguriert die Liste der Überwachungsanzeigen und empfängt Ereignisse, die sich auf überwachte Geräte beziehen, über das Host Controller Interface (HCI). Es sind drei Befehle und ein Ereignis definiert.

HCI Command or Event

Description

LE Monitored Advertisers List command

Used by the host to add or remove an entry from the Monitored Advertisers List or to clear the list completely. An array of one or more devices to be monitored plus their associated RSSI thresholds and timeout parameter are provided in this command.

 

LE Monitored Advertisers Enable command

Allows the host to enable or disable advertiser monitoring in the controller.

 

LE Read Monitored Advertisers List Size command

Allows the host to determine the total number of entries the controller can currently accommodate in its Monitored Advertisers list. Note that this value may change at any time.

 

LE Monitored Advertisers Report event

Generated by the controller whenever for a monitored device there is a loss-of-signal or the device comes back into range. The Condition parameter indicates which of these two conditions is responsible for the event having been generated.

 

 

5.2.2.3 Beispiel

Abbildung 18 veranschaulicht die Funktionsweise von Monitoring Advertisers. Die linke Hälfte der Abbildung enthält ein Nachrichtenablaufdiagramm. Ein Werbegerät ist als Ganzes dargestellt, während ein Scan-Gerät in seine Controller- und Host-Teile unterteilt ist, so dass die HCI-Kommunikation zwischen den beiden Teilen ersichtlich ist.  

Die rechte Hälfte des Diagramms zeigt die RSSI-Werte, die eingestellten niedrigen und hohen RSSI-Schwellenwerte sowie die Statusinformationen Timer und Awaiting RSSI High.

Die Zeit fließt von oben nach unten im Diagramm. Die Punkte von Interesse sind auf der linken Zeitachse alphabetisch gekennzeichnet. Tabelle 8 fasst zusammen.

Point

 

A

The scanner’s host starts by asking the controller how many advertising devices it can monitor.  The host then adds a device to the list along with RSSI low, RSSI high and timeout values (not shown). Finally, the host tells the controller to enable advertiser monitoring.

B

At this point the illustration starts to show advertising packets transmitted by the first device. Note that the device could have been advertising prior to this point but the packets are only shown from here. Received packets have an RSSI that is greater than the configured low threshold and so the timer for the monitored device is reset as each packet is received.

C

The next few packets received after point C have an RSSI that is lower than the low RSSI threshold and so it is at point C that the timer is last reset and the timer runs from that point.

D

A series of low RSSI packets are now received and at point D, a timeout occurs. The controller indicates the loss of signal condition to the host by sending a LE Monitor Advertisers Report event with condition == 0x00. The device is now in the Awaiting High RSSI state in the monitoring advertisers list.

E

At point E, the first of a series of packets whose RSSI is above the low threshold is received. For each such packet, the timer is reset.

F

At point F, the RSSI value exceeds the RSSI High threshold. The host is informed that the monitored device is back in range with a sufficiently strong signal via a LE Monitor Advertisers Report event with condition == 0x01 sent by the controller. The device is no longer in the Awaiting High RSSI state.

Tabelle 8 - Beispiel für die Überwachung von Werbetreibenden - Punkte von Interesse

Abbildung 18 - Ein Beispiel für die Überwachung von Advertisern im Einsatz

6. ISOAL-Erweiterung

6.1 Hintergrund

In diesem Abschnitt werden Aspekte der Bluetooth LE-Technologie erläutert, die für die Verbesserungen an der Isochronous Adaptation Layer (ISOAL) des Bluetooth LE-Stacks relevant sind.

6.1.1 Isochrone Kommunikation

Die Bluetooth LE Datentransportarchitektur umfasst die logischen Transporte LE CIS und LE BIS, wobei CIS für Connected Isochronous Stream und BIS für Broadcast Isochronous Stream steht. Diese logischen Transporte werden durch den LE Isochronous Physical Link und den LE Isochronous Physical Channel unterstützt.

Abbildung 19 - Isochrone Kommunikation und die Datentransportarchitektur

Isochrone Kommunikation wird verwendet, wenn die zwischen Geräten zu übertragenden Daten zeitgebunden sind. Das bedeutet, dass bei der Verarbeitung der übertragenen Daten durch den/die Empfänger ein strikter Zeitbezug eingehalten werden muss.

Bluetooth LE Audio verwendet eine isochrone Kommunikation, die sicherstellt, dass mehrere zusammenhängende Datenströme von ihren jeweiligen Empfängern gleichzeitig wiedergegeben werden. Konkret bedeutet dies zum Beispiel, dass Audiodaten für den linken Stereokanal und Audiodaten für den rechten Stereokanal zu unterschiedlichen Zeiten von der Audioquelle übertragen werden können, aber von zwei separaten Audiosenken (z. B. linke und rechte Ohrhörer) für die beiden Stereokanäle zur gleichen Zeit und in der vom Benutzer erwarteten Weise wiedergegeben werden.

CIS bietet einen verbindungsorientierten Ansatz für isochrone Kommunikation. CIS umfasst in der Regel kleine Gruppen von Geräten wie z. B. ein Smartphone und ein Paar Hörgeräte. Die Kommunikation kann jedoch bidirektional sein, so dass ein Hörgerät ein Mikrofon enthalten und sowohl als Audioquelle als auch als Audiosenke fungieren kann.

BIS beinhaltet die Übertragung isochroner Daten und ist für die Übermittlung isochroner Daten wie z. B. Audio an eine große Gruppe von Geräten gedacht. Die Kommunikation ist jedoch unidirektional.

Isochrone Kommunikation, insbesondere bei der Verarbeitung von Audiodaten, ist mit einer Reihe von Herausforderungen verbunden.

Die erste ist die korrekte Synchronisierung der Datenwiedergabe (in diesem Fall der Audiowiedergabe) über mehrere, völlig unabhängige Geräte hinweg. Dies ist genau das Problem, für das die isochrone Kommunikation konzipiert ist.

Latenz ist manchmal ein Problem und manchmal nicht. Der Benutzer wird sich der Latenz nur dann bewusst, wenn er eine andere Referenz hat, mit der er das erwartete Timing von Klängen in seinen Audiogeräten und das tatsächliche Timing von Klängen, die er erlebt, vergleichen kann. Wenn z. B. ein Hörgeräteträger sowohl einige Umgebungsgeräusche als auch die an seine Hörgeräte übertragenen Geräusche hören kann, wird er bei einer erheblichen Latenz eine Verzögerung zwischen den Umgebungsgeräuschen und ihren verstärkten Gegenstücken wahrnehmen. Bluetooth isochrone Kommunikation ermöglicht die Auswahl von Konfigurationen mit geringer Latenz, um den Anforderungen solcher Geräte gerecht zu werden.

Zuverlässigkeit ist wichtig, da die Toleranz für Datenverluste in vielen Audioszenarien begrenzt ist. Sowohl CIS als auch BIS enthalten Mechanismen zur Verbesserung der Zuverlässigkeit.

6.1.2 Digitales Audio

Die isochrone Kommunikation ist nicht nur für Audioanwendungen geeignet, aber sie ist die Hauptanwendung, für die sie ursprünglich entwickelt wurde. Die Art und Weise, in der digitale Audiodaten erzeugt werden, bringt bestimmte Herausforderungen mit sich, denen eine Schicht im Bluetooth LE-Stack, die so genannte Isochronous Adaptation Layer (ISOAL), Rechnung trägt.

Audio wird durch einen Prozess, der als Sampling bekannt ist, in ein digitales Format umgewandelt. Bei der Abtastung wird die Amplitude eines Signals in regelmäßigen Abständen gemessen und aufgezeichnet. Dabei entsteht eine große Datenmenge, die im Zusammenhang mit Bluetooth LE Audio Daten sind, die letztendlich übertragen werden müssen.

Bluetooth LE Audio verwendet einen Codec namens LC3[4] der einen Kompressionsalgorithmus auf die Sample-Daten anwendet und deren Größe erheblich reduziert. Codecs funktionieren im Allgemeinen durch Erkennung und Nutzung von Mustern, die in einer Reihe von aufeinanderfolgenden Samples gefunden werden. Damit ein Codec funktioniert, benötigt er also eine ganze Reihe von Samples, die er auf einmal analysieren kann.

Eine Sammlung von Samples, die gleichzeitig von einem Codec analysiert werden, wird als Frame bezeichnet. Frames haben eine feste Dauer, die normalerweise in Millisekunden gemessen wird, und enthalten eine durch die Abtastrate bestimmte Anzahl von Samples. Zum Beispiel enthält ein 10ms-Frame 441 Samples, wenn die Samplerate 44,1 KHz beträgt.

6.1.3 ISOAL

6.1.3.1 ISOAL in der Bluetooth Architektur

Daten, wie z. B. digitale Audiodaten, werden von der Anwendungsschicht eines Systems erzeugt. Diese befindet sich im Host-Teil des Bluetooth Stacks und ist in der Regel entweder ein Dienst des Betriebssystems (OS) oder eine Benutzeranwendung, die auf dem OS läuft. In der Bluetooth Kernspezifikation wird die Schicht, die Daten für die isochrone Kommunikation bereitstellt, einfach als obere Schicht bezeichnet.

Die Verbindungsschicht Bluetooth kommuniziert Daten mit einem oder mehreren anderen Geräten über einen der isochronen logischen Transporte. Die Verbindungsschicht ist im Bluetooth Controller implementiert, der in der Regel ein System auf einem Chip ist.

ISOAL tauscht isochrone Daten in Service Data Units (SDUs) mit ISOAL und ISOAL tauscht Protocol Data Units (PDUs) mit der Verbindungsschicht aus. Abbildung 20 zeigt die Beziehung zwischen diesen drei Teilen eines Bluetooth Systems.

Abbildung 20 - ISOAL in der Architektur Bluetooth

Der Host und der Controller sind in der Regel diskrete, unabhängige Komponenten und kommunizieren über die Host-Controller-Schnittstelle über eine der unterstützten Übertragungsarten wie USB oder UART miteinander.

6.1.3.2 Von ISOAL behandelte Themen

Es gibt zwei wichtige Bereiche, in denen Unterschiede zwischen den Betriebsparametern des Datenproduzenten in der oberen Schicht und denen der Verbindungsschicht zu Komplikationen führen können.

Der erste betrifft die Größe der in der oberen Schicht erzeugten SDUs. Es ist üblich, dass die SDUs deutlich größer sind als die maximale PDU-Größe, die von der Verbindungsschicht unterstützt wird.

ISOAL ermöglicht es der oberen Schicht, größere SDUs zu erzeugen, als die Verbindungsschicht in einer einzigen PDU verarbeiten kann.

Der zweite Punkt betrifft die Zeitplanung. Die Übermittlung von Daten durch die Verbindungsschicht erfolgt in Ereignissen, die in Intervallen auftreten. Dieses Intervall kann eine Reihe von Werten annehmen und wird allgemein als ISO-Intervall bezeichnet. Frames werden von der oberen Schicht ebenfalls in Intervallen erzeugt und in SDUs weitergereicht, wobei SDU für Service Data Unit steht. Das Zeitintervall, das für die SDU-Produktion durch die obere Schicht gilt, wird als SDU-Intervall bezeichnet.

Das ISO-Intervall, das von der Verbindungsschicht im Controller verwendet wird, ist oft nicht dasselbe wie das SDU-Intervall, das von der oberen Schicht im Host verwendet wird, und die beiden Intervallwerte sind keine ganzzahligen Vielfachen voneinander. Darüber hinaus ist es üblich, dass die Aktivitäten dieser beiden Schichten nicht synchronisiert sind, so dass es zu Wartezeiten kommen kann, während die Daten das System durchlaufen. Es ist zu beachten, dass eine Null-PDU übertragen wird, wenn die Verbindungsschicht während eines Ereignisses keine Daten von der oberen Schicht zu übertragen hat.

Abbildung 21 zeigt die Auswirkungen einer unsynchronisierten SDU- und PDU-Produktion.

Abbildung 21 - unsynchronisierte SDU- und PDU-Produktion

Die zu übertragenden Daten sind stark an die Zeit gebunden, und die Empfänger müssen in der Lage sein, diese Zeitbeziehung wiederherzustellen und sicherzustellen, dass bei der Verarbeitung der Daten das erwartete Ergebnis erzielt wird. Dies ist immer ein Problem, aber es ist noch komplizierter, wenn es keine Synchronisation zwischen der oberen Schicht und dem Transport gibt.

ISOAL erlaubt es, dass die Produktionsrate von SDUs durch die obere Schicht von der Übertragungsrate isochroner PDUs durch die Verbindungsschicht abweicht und dass ihr Betrieb unsynchronisiert ist.

6.1.3.3 ISOAL-Verarbeitungspfade

Es gibt zwei mögliche Wege, die die isochronen Daten durch ISOAL nehmen können, und diese sind in Abbildung 22 mit unterschiedlichen Farben dargestellt.

Wenn das SDU-Intervall ein ganzzahliges Vielfaches des ISO-Intervalls ist und der Betrieb der oberen Schicht und der Transportschicht synchronisiert sind, dann werden ungerahmte PDUs durch ein Verfahren namens Fragmentierung erzeugt. Andernfalls werden gerahmte PDUs erzeugt, und es wird ein Verfahren namens Segmentierung angewendet.

Abbildung 22Abbildung 22- ISOAL

6.1.3.4 Unframed und Framed PDUs

Wird der ungerahmte PDU-Pfad verwendet, werden SDUs, die größer sind als die von der Verbindungsschicht zugelassene maximale PDU-Größe, durch einen als Fragmentierung bezeichneten Prozess in kleinere Teile aufgeteilt. Kopfzeilen geben an, ob ein Fragment die gesamte SDU, den Anfang, die Fortsetzung oder das Ende einer SDU darstellt.

In umgekehrter Richtung werden SDUs aus den kleineren, von der Verbindungsschicht empfangenen PDUs ohne Rahmen rekombiniert.

Wenn der gerahmte PDU-Pfad verwendet wird, wird ein Prozess namens Segmentierung auf SDUs angewendet. Wie bei der Fragmentierung werden SDUs in kleinere Teile mit Headern aufgeteilt, aber der Header, der den Beginn einer SDU anzeigt, enthält auch Zeitversatzinformationen, so dass der Empfänger diese wichtigen Zeitinformationen wieder zusammensetzen und behalten kann.

SDUs werden je nach Ergebnis des Fragmentierungs- oder Segmentierungsprozesses in einer oder mehreren Link Layer PDUs übertragen.

6.1.3.5 Rahmungsmodus

Ein Framing-Modus ist in der Bluetooth Core Specification definiert. Vor Version 6.0 waren nur zwei Framing-Modi definiert, die jeweils dem gerahmten oder ungerahmten Fall entsprachen.

6.1.3.6 Probleme mit der ISOAL-Segmentierung

Der ISOAL-Rahmenprozess befasst sich mit zwei Aspekten der Daten, die ihm von der oberen Schicht übergeben werden. Es ermöglicht die Übertragung größerer SDUs, indem es sie in kleinere PDUs unterteilt, und es stellt sicher, dass der zeitliche Bezug der Daten erhalten bleibt und rekonstruiert werden kann.

Bei der Segmentierung gibt es zwei Probleme, die je nach Anwendung von Bedeutung sein können oder auch nicht.

Der erste betrifft die Zuverlässigkeit. In jedem drahtlosen Kommunikationssystem gibt es immer eine gewisse Wahrscheinlichkeit für den Verlust von Paketen. Wenn eine SDU, die z. B. Audiodaten enthält, in mehrere PDUs aufgeteilt wird, die in einer entsprechenden Reihe von Paketen der Verbindungsschicht über die Luft übertragen werden, erhöht sich die Wahrscheinlichkeit, dass eines oder mehrere dieser Pakete verloren gehen und damit die SDU als Ganzes gefährdet ist.

Der zweite Punkt betrifft die Latenzzeit. Wenn die Segmentierung angewandt wird, muss die obere Schicht auf dem empfangenden Gerät warten, bis sie alle Segmente der SDU empfangen hat, bevor sie sie wieder zusammensetzen und verarbeiten kann. Im Falle von Audio bedeutet dies, dass ein Audio-Frame neu erstellt und mit Hilfe des LC3-Verfahrens dekodiert werden muss.[5] Codec dekodiert wird, bevor mit der Audio-Rendering-Phase begonnen wird. Diese Wartezeit schlägt sich in einer Latenzzeit nieder.

6.2 Über die ISOAL-Erweiterung

Die isochrone Anpassungsschicht verfügt über einen neuen Framing-Modus namens Unsegmented Framed Mode. Hosts können diesen Modus auswählen, indem sie im Parameter Framing des Befehls HCI LE Set CIG Parameters oder des Befehls LE Create BIG einen Wert von 0x02 angeben.

Der unsegmentierte Framing-Modus ermöglicht die Verwendung von gerahmten PDUs und die Beibehaltung der Zeitinformationen jeder SDU, ohne dass eine Segmentierung erforderlich ist. Dieser neue Framing-Modus hat zwei Vorteile. Erstens entfällt die durch die Segmentierung bedingte Latenzzeit. Zweitens wird das Risiko von SDU-Verlusten aufgrund von Paketverlusten verringert.

6.2.1 Verkürzte Latenzzeit

Durch die Eliminierung der Segmentierung aus dem Framing-Prozess enthält jedes Link-Layer-Paket effektiv eine ganze SDU. Dies entspricht im Falle von LE-Audio einem ganzen Audio-Frame, und die obere Schicht muss nicht auf den Empfang einer Reihe von Paketen warten, bevor sie in der Lage ist, die empfangenen Audiodaten zu dekodieren und zu verarbeiten.

6.2.2 Verbesserte Zuverlässigkeit

Bei der Segmentierung wird eine einzelne SDU als Nutzlast von mehreren Paketen transportiert. Geht man von einer konstanten Wahrscheinlichkeit von Paketverlusten aus, so ist die Wahrscheinlichkeit, dass ein oder mehrere Teile der SDU verloren gehen, umso größer, je mehr Pakete erforderlich sind, um eine SDU in ihrer Gesamtheit zu transportieren.

Wenn der unsegmentierte Framing-Modus verwendet wird, reicht die maximale PDU-Größe immer aus, um eine ganze SDU zu enthalten, ohne dass eine Segmentierung erforderlich ist. Es besteht also eine Eins-zu-Eins-Beziehung zwischen SDUs der oberen Schicht und den PDUs, die die Verbindungsschicht überträgt. Folglich steigt das Risiko von Paketverlusten nicht in dem Maße, wie es der Fall ist, wenn die Segmentierung mehrere PDUs für jede SDU erzeugt.

7. LL Erweiterter Funktionssatz

7.1 Hintergrund

Die Verbindungsschicht (LL) ist eine komplexe Schicht des Bluetooth LE-Stacks. Es werden zahlreiche Fähigkeiten definiert, die als Features bezeichnet werden.

Die Unterstützung für ein Merkmal ist oft optional. Bevor ein Gerät ein Leistungsmerkmal verwendet oder eine LL-Prozedur durchführt, die sich auf eines dieser Leistungsmerkmale bezieht oder davon abhängt, muss es feststellen, ob das Leistungsmerkmal sowohl von seinem eigenen Bluetooth Controller als auch vom Controller des entfernten Geräts unterstützt wird oder nicht. Zu diesem Zweck wurden in der Bluetooth Core Specification eine 8-Oktet-Bitmaske namens FeatureSet und ein Verfahren zum Austausch von Merkmalen definiert.

Die Definition von FeatureSet weist jedem seiner 64 Bits eine Bedeutung zu. Ein Bitwert von 1 bedeutet, dass das zugehörige Merkmal unterstützt wird, ein Wert von 0 bedeutet, dass es nicht unterstützt wird.

Das Verfahren "Feature Exchange Link Layer Control" umfasst den Austausch von LL_FEATURE_REQ- und LL_FEATURE_RSP-PDUs, wenn es vom zentralen Gerät in einer Verbindung initiiert wird. Das Peripheriegerät kann das Verfahren ebenfalls initiieren, tut dies jedoch durch Senden einer LL_PERIPHERAL_FEATURE_REQ-PDU, auf die die Zentrale mit LL_FEATURE_RSP antwortet. Alle drei PDU-Typen enthalten die FeatureSet-Bitmaske, die angibt, welche Merkmale das sendende Gerät unterstützt. Abbildung 23 zeigt das Feature Exchange Link Layer Control-Verfahren, wenn es von der Zentrale eingeleitet wird, die hier als Gerät A dargestellt wird.

Abbildung 23 - Zentral initiierter LL-Merkmal-Austauschvorgang

Im Laufe der Zeit wurde Bluetooth immer ausgefeilter und die Liste der Funktionen wurde erweitert. Die 64 Bits der FeatureSet-Bitmaske reichen nicht mehr aus, um die große Bandbreite an Merkmalen abzudecken, die in der Bluetooth Core Specification Version 6.0 und zukünftigen Versionen dieses Dokuments definiert sind. 

Abbildung 24 zeigt das Ende der Tabelle, die die Bedeutung der Bits im Feld FeatureSet in Version 5.4 der Bluetooth Core Specification definiert. Lediglich Bit Nummer 63 ist hier nicht belegt.

Abbildung 24 - Das FeatureSet-Feld in der Version {Atlanta Versionsnummer} der Bluetooth Core Specification

7.2 Über den erweiterten Funktionsumfang von LL

7.2.1 Überblick

LL Extended Feature Set bietet ein Mittel, mit dem weitere Merkmale, die über diejenigen hinausgehen, für die ein Bit im FeatureSet-Feld zugewiesen wurde, als von Geräten unterstützt oder nicht unterstützt angezeigt werden können. Es wurde entwickelt, um die Entwicklung der Bluetooth Technologie bis weit in die Zukunft hinein zu unterstützen, mit ausreichender Kapazität, um Bits zur Anzeige der Unterstützung für 1984 unterzubringen.

7.2.2 Technische Highlights

LL Extended Feature Set ist selbst ein Link Layer Feature, das ein Gerät entweder unterstützt oder nicht. Dies wird durch den Wert von Bit Nummer 63 im Feld FeatureSet angezeigt.

Die FeatureSet-Bitmaske wurde vergrößert und ist in adressierbare Seiten unterteilt. Seite 0 enthält die ersten 64 Bits, die gemäß der Spezifikation des Feldes vor Version 6.0 der Bluetooth Core Specification definiert sind. Es folgen 10 Seiten, die von 1 beginnend fortlaufend nummeriert sind und jeweils 192 Bits (24 Oktette) groß sind.

Geräte, die das Leistungsmerkmal "LL Extended Feature Set" unterstützen, können sich gegenseitig mit Hilfe des Verfahrens " Feature Page Exchange" (Austausch von Leistungsmerkmalen) über das erweiterte Leistungsmerkmal informieren. Das Verfahren kann entweder vom Zentralgerät oder vom Peripheriegerät eingeleitet werden.

Zwei neue HCI-Befehle und ein neues HCI-Ereignis wurden für die Verwendung mit dem LL Extended Feature Set definiert. Dabei handelt es sich um den Befehl LE Read All Local Supported Features, den Befehl LE Read All Remote Features bzw. das Ereignis LE Read All Remote Features Complete.

Ein Aufruf des Befehls LE Read All Remote Features führt zur Übertragung einer Reihe von LL_FEATURE_EXT_REQ-PDUs, von denen jede vom entfernten Gerät mit einer LL_FEATURE_EXT_RSP-PDU beantwortet wird. Wenn alle entfernten FeatureSet-Seiten abgerufen worden sind, werden die Einzelheiten dem initiierenden Host in einem Ereignis LE Read All Remote Features Complete gemeldet. Siehe Abbildung 25.

Abbildung 25 - Austausch des erweiterten LL-Feature-Sets

Sowohl die LL_FEATURE_EXT_REQ- als auch die LL_FEATURE_EXT_RSP-PDUs haben die gleiche Struktur mit drei Feldern in der Link-Layer-Daten-PDU CtrData-Feld. Tabelle 9 zeigt die Felder in diesen PDU-Typen.

CtrData

MaxPage

(1 octet)

PageNumber

(1 octet)

FeaturePage

(24 octets)

Tabelle 9 - Inhalt der LL_FEATURE_EXT_REQ und LL_FEATURE_EXT_RSP PDUs

Das Feld MaxPage wird verwendet, um die höchste Seitennummer anzugeben, auf der ein Bit ungleich Null vorhanden ist.

Das Feld PageNumber identifiziert die Nummer der 24-Oktett-Seite innerhalb des erweiterten FeatureSets, dessen Werte angefordert oder gemeldet werden.

FeaturePage enthält die 192 Bit-Werte, die in der durch PageNumber identifizierten Seite enthalten sind.

Das Feature Page Exchange-Verfahren kann vom Host oder autonom von der Verbindungsschicht gestartet werden. Es wurden neue Versionen bestehender HCI-Befehle und -Ereignisse definiert, um die Nutzung des erweiterten Funktionsumfangs durch den Host zu ermöglichen. 

8. Frame Space Update

8.1 Hintergrund

In diesem Abschnitt werden die Aspekte der Bluetooth LE-Technologie erläutert, die für die Frame Space Update-Erweiterung relevant sind.

8.1.1 Der Zwischenrahmenraum

Die Verbindungsschicht legt ein Luftschnittstellenprotokoll fest, und dazu gehört auch die Definition eines Zeitintervalls, des so genannten Inter Frame Space (IFS).

Die IFS muss zwischen zwei aufeinanderfolgenden Paketen liegen, die auf demselben Kanal gesendet werden. Vor der Version 6.0 der Bluetooth Core Specification wurde diese Zeitspanne mit dem symbolischen Bezeichner T_IFS bezeichnet und hatte einen festen Wert von 150 µs.

Für die verschiedenen Transportarten werden auch Mindestzeitdauern festgelegt, die zwischen dem Ende des letzten in einem Ereignis oder Unterereignis übertragenen Pakets und dem Beginn des nächsten Ereignisses/Subereignisses liegen müssen. 

8.1.2 Der vernetzte Zustand

In Abbildung 9 ist die Zustandsmaschine der Verbindungsschicht dargestellt. Zwei logische Transportarten können im Verbindungszustand arbeiten. Dies sind der asynchrone verbindungsorientierte logische Transport (ACL) und der verbundene isochrone Strom (CIS).

Der ACL-Transport ermöglicht es einem Gerät in der Zentralrolle, während Verbindungsereignissen Pakete mit einem anderen Gerät in der Peripherierolle auszutauschen.

Abbildung 26 zeigt ein Beispiel für eine ACL-Verbindung, wie sie vor Version 6.0 der Bluetooth Core Specification definiert war, wobei der feste Wert T_IFS den zeitlichen Abstand definiert, der zwischen den Paketen desselben Verbindungsereignisses bestehen muss, die entweder von der Zentrale zur Peripherie oder von der Peripherie zur Zentrale gesendet werden. Außerdem muss zwischen dem Ende eines Verbindungsereignisses und dem Beginn des nächsten ein Zeitraum von mindestens T_IFS liegen.

Abbildung 26 - Über eine ACL-Verbindung ausgetauschte Pakete

Das CIS verwendet ein System von Unterereignissen, in denen Pakete ausgetauscht werden. Vor Version 6.0 war der zeitliche Abstand zwischen den Paketen desselben Unterereignisses ebenfalls als fester Wert T_IFS definiert, wie in Abbildung 27 dargestellt. Darüber hinaus wurde ein Zeitraum definiert, der als Minimum Subevent Space bezeichnet wird und den symbolischen Namen T_MSS hat. Zwischen dem Ende eines CIS-Subevents und dem Beginn des nächsten muss ein Zeitraum von mindestens T_MSS liegen. In der Bluetooth Core Specification vor Version 6.0 hatte T_MSS denselben festen Wert von 150 µs wie T_IFS. Es ist zu beachten, dass ein CIS eine zugehörige ACL-Verbindung hat, die zum Aufbau des CIS und zum Austausch von Link Layer Control PDUs, die das CIS betreffen, verwendet wird.

Abbildung 27 - über einen verbundenen isochronen Datenstrom (CIS) ausgetauschte Pakete

8.2 Über Frame Space Update

8.2.1 Überblick

Bluetooth In der Version 6.0 der Kernspezifikation wurden die folgenden Änderungen an den Rahmenabständen vorgenommen: 

  • Für die Zeitabstände, die für ACL-Verbindungen und CIS gelten, wurden fünf verschiedene symbolische Namen vergeben.
  • Die Werte sind nicht mehr auf 150 µs festgelegt.
  • Die Werte für jeden der fünf Rahmentypen sind standardmäßig auf 150 µs eingestellt, aber neue Werte können von der Zentrale und den Peripheriegeräten ausgehandelt werden, nachdem eine Verbindung hergestellt worden ist.

Die Werte für den Rahmenabstand können entweder kürzer oder länger als die standardmäßigen 150 µs sein.

Die Änderung ist nur für ACL-Verbindungen und verbundene isochrone Ströme relevant. Andere Transporttypen verwenden weiterhin einen festen Interframe-Abstand von 150 µs, der jetzt mit dem symbolischen Namen T_IFS_150 bezeichnet wird.

Kürzere Frame-Space-Werte können den Gesamtdurchsatz erhöhen. Beispiele für Anwendungen, die von einem kürzeren Frame Space und höheren Datendurchsatzraten profitieren, sind:

  • Fitness-Tracker, die alle gesammelten Daten in einem Zug an ein angeschlossenes Gerät wie ein Smartphone oder einen Laptop übertragen müssen.
  • Firmware-Aktualisierungen.
  • Bluetooth LE-Audio. Audiopakete, die über einen verbundenen isochronen Stream gesendet werden, können schneller und in kürzeren Bursts gesendet werden. Dadurch wird die Wahrscheinlichkeit von Kollisionen mit anderen Geräten verringert.
  • Geräte, die ihr Funkgerät für andere Zwecke nutzen, z. B. für Wi-Fi, haben mehr Zeit für diese Aktivitäten.

Längere Frame-Space-Werte können für Fluglotsen mit relativ geringer Verarbeitungsleistung von Vorteil sein, da sie dem Fluglotsen mehr Zeit für die Verarbeitung längerer Pakete geben.

8.2.2 Technische Highlights

8.2.2.1 Abstandsarten

Für ACL-Verbindungen sind drei Abstandsarten definiert. Tabelle 10 gibt einen Überblick über die neuen Abstandstypen für ACL-Verbindungen.

Spacing Type Symbolic Identifier

Definition

T_IFS_ACL_CP

The duration of the required spacing time which must exist from the end of a packet transmission by the Central device and the start of the following slot in the same connection event, which may potentially be used by the Peripheral.

 

T_IFS_ACL_PC

The duration of the required spacing time from the end of a packet transmission by the Peripheral device in a connection and the start of the following slot to potentially be used by the Central in the same connection event.

 

T_IFS_END

The minimum time to elapse between the end of a connection event and the start of the next one.

 

Tabelle 10 - Neue Rahmenabstandstypen und Bezeichner für ACL-Verbindungen

In Abbildung 28 sind die Verbindungsereignisse und die Paketübertragung in einer ACL-Verbindung dargestellt, wobei die neuen Abstandsarten durch ihre symbolischen Bezeichner gekennzeichnet sind.

Abbildung 28 - neue Rahmenabstandsarten in einer ACL-Verbindung

Für verbundene isochrone Datenströme werden zwei Abstandsarten definiert. Tabelle 11 fasst die neuen Abstandsarten für CIS zusammen. 

Spacing Type Symbolic Identifier

Definition

T_IFS_CIS

The duration of the required spacing time from the end of a packet transmission by the Central device in a CIS and the start of the following transmission by the Peripheral.

 

T_MSS_CIS

The minimum subevent space which is the minimum time that must elapse between the end of a packet transmitted in one subevent and the start of the next subevent.

 

Tabelle 11 - Neue Rahmenabstandsarten und -kennungen für CIS

In Abbildung 29 sind die Sub-Ereignisse und die Paketübertragung in einem zusammenhängenden isochronen Datenstrom dargestellt, wobei die neuen Abstandsarten durch ihre symbolischen Bezeichner gekennzeichnet sind.

Abbildung 29 - neue Arten von Rahmenabständen in einem verbundenen isochronen Datenstrom (CIS)

Die Steuergeräte können so konfiguriert werden, dass sie unterschiedliche Werte für jede der Abstandsarten pro Bluetooth LE PHY (LE 1M, LE 2M und LE Coded) verwenden.

In allen Fällen ist der Standardwert für einen Abstandsparameter 150 µs und der zulässige Wertebereich für einen Abstandsparameter ist 0 bis 10.000 µs.

In allen Fällen ist eine Toleranz von ±2 µs zulässig.

8.2.2.2 Frame Space Update

In der Spezifikation für die Verbindungsschicht ist ein neues Verfahren mit der Bezeichnung "Frame Space Update"-Verfahren definiert. Mit dieser Prozedur können die Geräte Werte für alle anwendbaren Abstandstypen für einige oder alle unterstützten PHYs aushandeln.

Entweder das Zentralgerät oder das Peripheriegerät kann das Frame Space Update-Verfahren einleiten. Dies geschieht durch Senden einer LL_FRAME_SPACE_REQ über die Verbindung. Als Antwort muss das andere Gerät eine LL_FRAME_SPACE_RSP PDU senden.

Die PDU LL_FRAME_SPACE_REQ enthält die folgenden Felder:

Field

Meaning

FS_MIN

The minimum requested frame spacing in microseconds.

FS_MAX

The maximum requested frame spacing in microseconds.

PHYs

A single octet bit mask where bit 0 indicates the LE 1M PHY, bit 1 indicates the LE 2M PHY and bit 2 indicates the LE Coded PHY. One or more of these bits may be set to indicate the PHYs for which the frame spacing update is being requested.

 

Spacing Type

A 2-octet bit mask which indicates the spacing parameters for which new values are being requested. Bit 0 indicates T_IFS_ACL_CP, bit 1  indicates T_IFS_ACL_PC, bit 2 indicates T_IFS_END, bit 3 indicates T_IFS_CIS and bit 4 indicates T_MSS_CIS.

 

Das antwortende Gerät validiert die Anfrage unter Anwendung der Regeln der Bluetooth Core Specification. Wenn die Anforderung gültig ist und erfüllt werden kann, sendet es eine LL_FRAME_SPACE_RSP-PDU zurück, die den zu verwendenden Frame Space-Wert enthält. Dabei handelt es sich um den niedrigsten Wert innerhalb des angeforderten Bereichs, den das Gerät unterstützen kann. Beide Geräte übernehmen die neuen Werte und teilen ihren Hosts die Änderung mit.

Kann der Anforderung nicht entsprochen werden, wird eine LL_REJECT_EXT_IND-PDU mit dem Fehlercode "Unsupported Feature or Parameter Value" zurückgegeben, und die verwendeten Parameter für den Rahmenabstand bleiben unverändert.

8.2.2.3 Host-Controller-Schnittstelle

Die Host-Controller-Schnittstelle wurde aktualisiert, um das neue Frame Space Update-Verfahren zu unterstützen.

Das Verfahren wird eingeleitet, indem ein Host den neuen Befehl HCI_LE_Frame_Space_Update an seine Steuerung sendet. Der Befehl enthält die Abstandsarten und den Zeitbereich, in dem neue Rahmenraumwerte angefordert werden, sowie die PHYs, für die die neuen Werte gelten sollen.

Änderungen werden dem Host nach Abschluss des Frame Space Update-Verfahrens über das neue Ereignis LE Frame Space Update Complete mitgeteilt.

Abbildung 30 zeigt die Interaktionen, die zwischen Host und Controller und zwischen den Geräten stattfinden, wenn das Verfahren zur Aktualisierung des Rahmenraums eingeleitet wird.

Abbildung 30 - Frame Space Update HCI und Link Layer Interaktionen

9. Schlussfolgerung

Bluetooth Die Version 6.0 der Kernspezifikation setzt den Trend fort, dass die Technologie von Bluetooth regelmäßig mit neuen Funktionen und technischen Verbesserungen aktualisiert wird.

Channel Sounding wird ein auf Normen basierendes, sicheres Konzept für eine zuverlässige und genaue Entfernungsmessung ermöglichen, von dem viele Arten von Produkten profitieren werden.

Decision-Based Advertising Filtering verbessert den Durchsatz und die Zuverlässigkeit bei der Verwendung von Bluetooth extended advertising für verbindungslose Datenübertragung.

Die Überwachung von Werbetreibenden wird für Anwendungsentwickler von Nutzen sein und die Bereitstellung besserer Benutzeroberflächen und eines besseren Benutzererlebnisses ermöglichen.

Die an ISOAL vorgenommenen Verbesserungen kommen denjenigen Audioanwendungen zugute, bei denen eine niedrige Latenzzeit, wie sie vom Benutzer wahrgenommen wird, wichtig ist.

Die LL Extended Feature Set Fähigkeit ermöglicht die Erkennung von Feature-Support in den anspruchsvollsten, funktionsreichen Geräten von heute und in der Zukunft.

10. Referenzen

Item Location

Bluetooth Core Specification version 6.0

https://www.bluetooth.com/specifications/specs/

The Bluetooth LE Security Study Guide

https://www.bluetooth.com/bluetooth-resources/le-security-study-guide/

Bluetooth® Channel Sounding Technical Overview paper

https://www.bluetooth.com/channel-sounding-tech-overview/

 

FOTNOTEN


[1] Der Modus 0 wird in 3.2.2.5.1 Ereignisse, Unterereignisse und Schritte erläutert.
[2] Gaußsche Frequenzverschiebungstaste
[3] Verbindungsfähige Werbe-PDUs sind solche, die als Antwort eine Verbindungsanfrage zulassen
[4] Kommunikationscodec mit geringer Komplexität
[5] Low Complexity Communications Codec - der von Bluetooth LE Audio verwendete Audiocodec

HINWEIS: Die Bluetooth SIG hat ihre Nutzungsbedingungen am 29. Oktober 2024 aktualisiert.Mehr erfahren
Hilfe erhalten