Inhaltsverzeichnis anzeigen

1. Revision Geschichte

Version	Datum	Autor	Änderungen
1.0.0	22. April 2022	Martin Woolley, Bluetooth SIG	Ursprüngliche Version.
1.0.4	6. Juni 2022	Martin Woolley, Bluetooth SIG	Verbesserungen im Abschnitt Link Layer: Hinzufügung der Information, dass mehrere Link Layer State Machine Instanzen erlaubt sind, Verbesserung der Sprache, um sicherzustellen, dass es sich bei der Kanalklassifizierung um ein optionales Implementierungsmerkmal handelt, Unterscheidung zwischen Kanalstatusberichten und Kanalplanaktualisierungen und Hinweis darauf, dass AFH in einem regulatorischen Kontext eine andere Bedeutung haben kann.
1.1.0	17. Januar 2023	Martin Woolley, Bluetooth SIG	Aktualisiert, um die Bluetooth® Core Specification 5.4 widerzuspiegeln und Informationen über periodische Werbung mit Antworten hinzuzufügen.
1.2.0	15. März 2024	Ifti Anees, Bluetooth SIG	Formataktualisierungen und Korrektur von 14.2 Tippfehlern im Zusammenhang mit der Beobachterrolle.
1.3.0	15. Oktober 2024	Martin Woolley, Bluetooth SIG	Aktualisiert, um Informationen über die Funktionen Bluetooth® Channel Sounding, Decision Based Advertising Filtering und Monitoring Advertisers sowie die überarbeiteten zulässigen Werte der Inter-Frame-Space-Timing-Variablen aufzunehmen.

2. Über dieses Papier

Der ^Bluetooth® Low Energy Primer wurde erstellt, um Technologieexperten wie Produktdesignern und -entwicklern zu helfen, sich schnell mit Bluetooth Low Energy (LE) vertraut zu machen, bevor sie die offiziellen technischen Spezifikationen konsultieren und tiefer in das Thema einsteigen.

Bei der Bluetooth SIG gibt es eine umfangreiche Sammlung von Spezifikationen, Papieren und anderen Bildungsressourcen zu Bluetooth LE . Ein weiteres Ziel dieses Papiers ist es, das Bewusstsein für ihre Existenz und ihren Zweck zu schärfen und dem Leser zu helfen, sich mit dem Thema und dem dazugehörigen Material zurechtzufinden.

Die meisten Bluetooth LE verwenden entweder eine Kombination aus verbindungsloser Kommunikation(Werbung) und Punkt-zu-Punkt-Verbindungen, um Daten auszutauschen, oder sie kommunizieren nur über das Senden von Werbepaketen. Diese Ressource behandelt den Bluetooth LE , wie er für Produkte verwendet wird, die in diese Kategorien fallen. Im Gegensatz dazu wird Bluetooth Mesh hier nicht behandelt. Bluetooth Mesh ist eine spezielle Anwendung von Bluetooth LE , zu der andere Informationsquellen konsultiert werden sollten.

Es ist nicht das Ziel dieses Papiers, genau dasselbe Terrain wie die formalen Spezifikationen zu reproduzieren oder in derselben Tiefe zu behandeln. Von Zeit zu Zeit können kurze Auszüge aus den Spezifikationen eingefügt werden, wenn dies sinnvoll ist. Sie sollten dieses Papier als Orientierungshilfe betrachten, indem es wichtige Bluetooth LE Konzepte vorstellt und erklärt, den Weg zu anderen Ressourcen und Spezifikationen weist und hoffentlich die Lernkurve ein wenig weniger steil macht.

3. Einführung

Die Bluetooth-Technologie gibt es seit dem Jahr 2000. Ursprünglich wurde sie entwickelt, um den drahtlosen Datenaustausch zwischen zwei Geräten zu ermöglichen, ohne dass weitere Netzwerkgeräte erforderlich sind, und fand schnell Eingang in Produkte wie drahtlose Mäuse und Freisprecheinrichtungen für Autos. Letztere ist ein Audioprodukt, und Audio erwies sich als die "Killer-App" für diese ursprüngliche Version der Bluetooth-Technologie. Das war auch viele Jahre lang so.

Diese erste Version der Bluetooth Technologie, die in den allerersten Bluetooth Produkten verwendet wurde, ist offiziell als Bluetooth BR (Basic Rate) bekannt. Sie bot eine Rohdatenrate auf der physikalischen Schicht von 1 Million Bits pro Sekunde (1 mb/s).

Später wurde eine schnellere Version der Bluetooth-Technologie mit der Bezeichnung Bluetooth BR/EDR (Enhanced Data Rate) definiert. Sie bot eine Rohdatenrate von 2 mb/s, war aber immer noch für Anwendungsfälle gedacht, bei denen zwei Geräte direkt miteinander Daten austauschen.

Bluetooth Low Energy (LE) wurde erstmals in der Version 4.0 der Bluetooth Core Specification[1] vorgestellt. Dabei handelte es sich um eine neue Version der Bluetooth-Technologie, die ihren Vorgänger Bluetooth BR/EDR nicht ersetzte, sondern als Alternative mit Fähigkeiten und Qualitäten, die sie perfekt für eine neue Generation von Produkten und die Erfüllung neuer und anspruchsvoller technischer und funktionaler Anforderungen machten.

Bluetooth LE unterstützt andere Topologien als die Punkt-zu-Punkt-Kommunikation zwischen zwei Geräten mit einer Vielzahl von Broadcast-basierten Modi, die es einem Gerät ermöglichen, Daten an eine unbegrenzte Anzahl von Empfängern gleichzeitig zu übertragen. Es ist auch die Grundlage für Bluetooth-Mesh-Networking, das den Aufbau von Netzwerken mit Zehntausenden von Geräten ermöglicht, von denen jedes mit jedem anderen Gerät im Netzwerk kommunizieren kann.

Die Eins-zu-Eins-Kommunikation zwischen zwei Geräten wird sowohl durch die verbindungsorientierte als auch durch die verbindungslose Kommunikation unterstützt. Die Eins-zu-Viele-Kommunikation wird durch verbindungsloses Broadcasting unterstützt.

Die Richtung, in die Anwendungsdaten übertragen werden können, hängt von der Art und Weise ab, in der Bluetooth LE verwendet wird. Beachten Sie, dass der Begriff Modus hier als Abkürzung dafür verwendet werden kann. Einige der Modi beinhalten eine verbindungsorientierte Kommunikation, andere eine verbindungslose Kommunikation. Einige Modi unterstützen den bidirektionalen Austausch von Anwendungsdaten, aber in einigen Fällen können die Anwendungsdaten nur in eine Richtung übertragen werden.

Normalerweise haben Anwendungsdaten keine kritische Beziehung zur Zeit, aber es gibt Fälle, in denen dies der Fall ist, und ein Gerät muss diese Beziehung aufrechterhalten, wenn es empfangene Daten verarbeitet. Bluetooth LE unterstützt isochrone Kommunikation sowohl in einem verbindungsorientierten als auch in einem verbindungslosen Modus. Isochrone Kommunikation ist für genau die Fälle gedacht, in denen Daten zeitgebunden sind. Audio ist ein gutes Beispiel für einen solchen Fall.

Bluetooth LE verfügt über eine Reihe von Funktionen zur Gerätepositionierung, die für standortbezogene Anwendungen vorgesehen sind.

• Bei der Richtungsbestimmung gibt es zwei verschiedene Methoden, mit denen die Richtung eines übertragenen Signals vom Empfänger berechnet werden kann. Die beiden Methoden heißen Ankunftswinkel (Angle of Arrival, AoA) und Abfahrtswinkel (Angle of Departure, AoD).
• Mit ^Bluetooth® Channel Sounding können zwei Geräte zusammenarbeiten und eines der Geräte kann seine Entfernung zum anderen Gerät sicher berechnen.

Eines der ursprünglichen Ziele bei der design dieser neuen Bluetooth-Technologievariante war die äußerst effiziente Nutzung der Energie. Es wurden Geräte ins Auge gefasst, die mit kleinen, münzgroßen Batterien tagelang, wochenlang oder noch länger betrieben werden konnten, und dieses Streben nach Energieeffizienz erklärt viele der bestimmenden Merkmale von Bluetooth LE. Insbesondere weist das design den Geräten asymmetrische Fähigkeiten und Verantwortlichkeiten zu, um sicherzustellen, dass Geräte mit einer relativ reichhaltigen Energiequelle, wie z. B. ein großer Smartphone-Akku, mehr von der schweren Arbeit übernehmen als vergleichbare Geräte, die mit Knopfzellenbatterien betrieben werden. Diese und andere design haben Bluetooth LE zu der drahtlosen Kommunikationstechnologie mit geringem Stromverbrauch gemacht, die es ist, und es für eine weit verbreitete Annahme in einer Vielzahl von Produkttypen in den folgenden Jahren positioniert.

4. Die Bluetooth LE

Ein tiefes und gründliches Verständnis von Bluetooth LE erfordert eine genaue Kenntnis der geltenden Spezifikationen. Die Architektur, die Verfahren und die Protokolle von Bluetooth LE sind vollständig in einer zentralen Spezifikation, der Bluetooth Core Specification, definiert. Die Art und Weise, wie Produkte Bluetooth verwenden, so dass sie interoperabel sind, wird durch Sammlungen von Spezifikationen zweier spezieller Typen abgedeckt, die als Profile und Dienste bekannt sind. Abbildung 1 veranschaulicht die Bluetooth LE und ihre Beziehungen.

Abbildung 1 - Die Bluetooth LE

4.1 Die Bluetooth Kernspezifikation

Die Bluetooth-Kernspezifikation ist die Hauptspezifikation für Bluetooth LE und Bluetooth Classic. Diese Spezifikation:

• definiert die Architektur der Bluetooth Technologie und die Schichten der verschiedenen Stack-Konfigurationen.
• beschreibt und definiert die wichtigsten Merkmale.
• definiert die formalen Verfahren, die den unterstützten Operationen zugrunde liegen.
• definiert die Protokolle, mit denen Geräte zwischen den relevanten Schichten des Stacks kommunizieren.

Die Bluetooth Kernspezifikation ist notwendigerweise eine umfangreiche Spezifikation.

Zusammenfassend definiert die Bluetooth Core Specification die Funktionsweise der Bluetooth Technologie und die Anforderungen an Entwickler bei der Implementierung eines Bluetooth Stacks oder einer oder mehrerer seiner Funktionen.

4.2 Profil-Spezifikationen

Wenn zwei Bluetooth LE über eine Verbindung kommunizieren, wird in der Regel eine Client/Server-Beziehung hergestellt. Die Server enthalten Zustandsdaten und die Clients verwenden diese Daten auf irgendeine Weise.

Stellen Sie sich einen Bluetooth Schlüsselanhänger vor, der Ihnen helfen soll, Ihre Schlüssel wiederzufinden, wenn Sie sie irgendwo abgelegt haben und sie vorübergehend verloren gegangen sind. Eine Smartwatch könnte als Client-Gerät und der Schlüsselanhänger Bluetooth als Server fungieren. Durch Drücken einer Taste auf dem Display der Smartwatch könnte der Zustand des Schlüsselanhängers geändert werden und er würde als Reaktion auf diese Änderung ein lautes Geräusch von sich geben, so dass Sie Ihre Schlüssel wiederfinden können.

Profilspezifikationen legen die Rollen fest, die verwandte Geräte (wie die Smartwatch und der Schlüsselanhänger) übernehmen, und definieren insbesondere das Verhalten des Client-Geräts und die Daten auf dem verbundenen Server, mit denen es arbeiten soll.

Im Beispiel des Schlüsselfinders wird das Verhalten der Smartwatch oder eines anderen Geräts, das die gleiche Rolle übernimmt, in der Spezifikation des Find-Me-Profils definiert.

4.3 Leistungsbeschreibung

Zustandsdaten auf Servern befinden sich in formal definierten Datenelementen, die als Merkmale und Deskriptoren[2] bekannt sind. Merkmale und Deskriptoren sind in Konstrukten gruppiert, die als Dienste bezeichnet werden. Dienste bieten einen Kontext, in dem den darin enthaltenen Merkmalen und Deskriptoren Bedeutung und Verhalten zugewiesen werden können.

Eine Dienstspezifikation definiert einen einzelnen Dienst zusammen mit den darin enthaltenen Merkmalen und Deskriptoren. Die Verhaltensweisen, die das Gerät, das den Dienst beherbergt, als Reaktion auf verschiedene Bedingungen und Zustandsdatenwerte zeigen soll, sind in der Dienstspezifikation festgelegt.

Eine Dienstspezifikation kann als Definition eines Aspekts des Verhaltens eines Servergeräts betrachtet werden.

Im Beispiel der Smartwatch und des Schlüsselanhängers fungiert der Schlüsselanhänger als Server und implementiert den Immediate Alert Service.

4.4 Protokollspezifikationen

Einige standardisierte Bluetooth Anwendungen erfordern ihre eigenen Protokolle, und diese Protokolle haben ihre eigenen Spezifikationen. Die primäre Spezifikation Bluetooth Mesh ist eine Protokollspezifikation.

4.5 Assigned Numbers

Bei verschiedenen Aspekten von Bluetooth LE werden eindeutige Bezeichner verwendet. Zum Beispiel haben alle Dienste, Merkmale und Deskriptoren einen universell eindeutigen Bezeichner (UUID), der den Typ des Dienstes, des Merkmals oder des Deskriptors identifiziert, auf den er sich bezieht, und nicht eine bestimmte Instanz auf einem bestimmten Gerät. Ein Unternehmen kann durch einen eindeutigen Unternehmensidentifikator identifiziert werden, der für bestimmte Profile erforderlich ist.

Die von der Bluetooth SIG zugewiesenen Kennungen werden als zugewiesene Nummern bezeichnet. Eine vollständige Liste dieser Kennungen finden Sie auf der Seite Zugewiesene Nummern auf der Website der Bluetooth SIG .

5. Der Bluetooth LE Stack

5.1 High-Level-Architektur

Der Bluetooth LE besteht aus einer Reihe von Schichten und Funktionsmodulen, von denen einige obligatorisch und einige optional sind. Diese Teile des Stacks sind über zwei große Architekturblöcke verteilt, die als host und den Controller, und eine logische Standardschnittstelle definiert die Art und Weise, wie diese beiden Komponenten miteinander kommunizieren können.

Der host ist oft so etwas wie ein Betriebssystem. Der Controller ist oft ein System auf einem Chip. Dies ist jedoch nicht unbedingt der Fall, und die Bluetooth-Spezifikationen schreiben keine derartigen Implementierungsdetails vor. Wichtig ist, dass host und Controller als getrennte logische Container in der Architektur fungieren, die auf irgendeine Weise in physisch getrennten Komponenten implementiert werden können, wobei eine Standardschnittstelle für die Kommunikation zwischen ihnen definiert ist. So kann ein Bluetooth-System aus host und Steuerungskomponenten verschiedener Hersteller bestehen.

Abbildung 2 veranschaulicht den Bluetooth LE , seine Schichten und ihre Verteilung auf die host und Controller-Komponenten.

DieController (HCI) stellt die logische Schnittstelle zwischen ihnen dar, ist aber keine physische Komponente als solche. HCI kann in Bezug auf den zugrunde liegenden physischen Transport auf verschiedene Weise implementiert werden, aber die logische oder funktionale Schnittstelle ist immer dieselbe.

LC3 ist der Low Complexity Communication Codec, der Standard-Audiocodec, der mit Bluetooth LE Audio verwendet wird. Er ist nicht Teil des Bluetooth LE , wird aber immer in LE-Audioprodukten zu finden sein, wobei die LC3-Komponente entweder im host oder im Controller implementiert ist, wie gezeigt.

Abbildung 3 zeigt das Standard-OSI-Referenzmodell für Kommunikationssysteme. Es ist anzumerken, dass der Bluetooth LE alle Schichten des OSI-Referenzmodells umfasst, im Gegensatz zu vielen anderen drahtlosen Systemen, die nur eine Teilmenge der OSI-Schichten abdecken, z. B. die physikalische und die Datenverbindungsschicht. Ein Vorteil der Bluetooth-Technologie als Full-Stack-Kommunikationssystem ist, dass es keine externen Abhängigkeiten von anderen Normungsgremien gibt. Solche Abhängigkeiten können die Entwicklung einer Technologie einschränken.

Das Bluetooth-Mesh-Protokoll nutzt die Bluetooth LE und fügt dem Core Host eine Sammlung spezialisierter Schichten hinzu, die die Bluetooth-Mesh-Protokolle und -Verfahren implementieren. Der host kann jede der im host von Abbildung 2 gezeigten Schichten enthalten, die zur Unterstützung anderer Produktanforderungen, wie z. B. der Fähigkeit zum Verbindungsaufbau, erforderlich sind.

Diese Ressource deckt Bluetooth Mesh nicht weiter ab, und wer nach einer Bildungsressource zu diesem Thema sucht, sollte Abschnitt 18 konsultieren. Zusätzliche Ressourcen unten.

Abbildung 4 - Der Bluetooth Mesh

5.2 Die Schichten im Überblick

Nachfolgend eine Zusammenfassung der wichtigsten Aufgaben und Funktionen der einzelnen Schichten des Bluetooth LE , wie in Abbildung 2 dargestellt:

Ebene	Zuständigkeiten
Physikalische Schicht	Definiert alle Aspekte der Bluetooth-Technologie, die mit der Verwendung von Funk (RF) zusammenhängen, einschließlich Modulationsschemata, Frequenzbänder, Kanalnutzung, Sender- und Empfängereigenschaften. Es werden mehrere verschiedene, unterstützte Kombinationen von Parametern der physikalischen Schicht definiert, die als PHYs bezeichnet werden.
Verbindungsschicht	Definiert Paketformate für die Luftschnittstelle, Bitstromverarbeitungsverfahren wie Fehlerprüfung, einen Zustandsautomaten und Protokolle für die Over-the-Air-Kommunikation und die Verbindungskontrolle; definiert verschiedene Möglichkeiten der Nutzung des zugrunde liegenden Funks für verbindungslose, verbindungsorientierte und isochrone Kommunikation, die als logische Transporte bezeichnet werden.
Channel Sounding	Bietet einem Gerät die Möglichkeit, Messungen vorzunehmen, die von der Anwendungsschicht zur Berechnung der Entfernung zu einem anderen Gerät verwendet werden können. Es sind zwei verschiedene Methoden integriert, nämlich die phasenbasierte Entfernungsmessung (PBR) und das Round-Trip-Timing (RTT). Diese Methoden können zusammen oder getrennt verwendet werden.
Isochrone Anpassungsschicht(ISOAL)	Ermöglicht die Verwendung unterschiedlicher Rahmendauern durch Geräte, die isochrone Kommunikation verwenden; führt Segmentierung und Wiederzusammensetzung von gerahmten PDUs oder Fragmentierung und Rekombination von ungerahmten PDUs durch.
Host (HCI)	Bietet eine genau definierte funktionale Schnittstelle für die bidirektionale Kommunikation von Befehlen und Daten zwischen der host und der Steuerung.
Logical Link Control and Adaptation Protocol(L2CAP)	Agiert als Protokollmultiplexer innerhalb des host und stellt sicher, dass die Protokolle von der entsprechenden host bedient werden; führt die Segmentierung und den Wiederzusammenbau von PDUs/SDUs zwischen der darunter liegenden und der darüber liegenden Schicht durch L2CAP durch.
Sicherheitsmanager-Protokoll(SMP)	Ein Protokoll, das bei der Durchführung von Sicherheitsverfahren wie dem Pairing verwendet wird.
Attribut-Protokoll(ATT)	Ein von einem ATT-Client und einem ATT-Server verwendetes Protokoll, das die Ermittlung und Verwendung von Daten in der Attributtabelle des Servers ermöglicht.
Generisches Attribut-Profil(GATT)	Definiert übergeordnete Datentypen, die als Dienste, Merkmale und Deskriptoren bekannt sind, in Bezug auf die zugrunde liegenden Attribute in der Attributtabelle.
Generisches Zugangsprofil(GAP)	Definiert Betriebsmodi und Verfahren, die im nichtverbundenen Zustand verwendet werden können, wie z. B. die Verwendung von Werbung für verbindungslose Kommunikation und die Durchführung der Geräteerkennung; definiert Sicherheitsstufen und -modi; definiert einige Benutzerschnittstellenstandards.

6. Die physikalische Schicht

Die physikalische Schicht von Bluetooth LE definiert, wie der Funksender/-empfänger verwendet wird, um digitale Daten für die Übertragung und den Empfang zu kodieren und zu dekodieren, sowie andere funkbezogene Parameter und Eigenschaften, die gelten.

6.1 Frequenzband

Bluetooth LE arbeitet im unlizenzierten 2,4-GHz-Band im Bereich von 2400 MHz bis 2483,5 MHz, das in 40 Kanäle mit einer Breite von jeweils 2 MHz unterteilt ist. Wie die Kanäle genutzt werden, wird durch die Verbindungsschicht und die Datentransportarchitektur festgelegt.

Abbildung 5 - Bluetooth LE

6.2 Modulationsschemata

6.2.1 Gaußsche Frequenzumtastung

Um digitale Daten aus höheren Schichten des Stacks vor der Übertragung zu kodieren und empfangene Funksignale zu dekodieren, verwendet Bluetooth LE ein Modulationsverfahren namens Gaussian Frequency Shift Keying (GFSK). Bei GFSK wird ein Signal mit der Mittenfrequenz des ausgewählten Kanals (dem Träger) um einen bestimmten Betrag nach oben verschoben, um einen digitalen Wert von 1 darzustellen, oder um denselben Betrag nach unten, um einen binären Wert von 0 darzustellen. Das Signal wird nach Gauß gefiltert, um Rauschen zu reduzieren, das mit abrupten Frequenzänderungen einhergehen kann.

Abbildung 6 veranschaulicht den grundlegenden Frequenzumtastungsprozess. Man beachte, dass der Betrag, um den die Frequenz verschoben wird, als Frequenzabweichung bezeichnet wird und je nach verwendeter PHY-Variante mindestens +/-185 kHz oder mindestens 370 kHz beträgt(PHY wird in Abschnitt 6.3 PHY-Varianten erläutert).

Abbildung 6 - Frequenzumtastung in Bluetooth LE

6.2.2 Amplitudenumtastung

Channel Sounding (siehe Abschnitt 8.^Bluetooth® Channel Sounding) verwendet für einige seiner Übertragungen ein Modulationsverfahren namens Amplitude Shift Keying (ASK). ASK ist ein binäres Modulationsverfahren mit zwei Symbolzuständen. Der erste wird durch die Übertragung einer Trägerwelle mit fester Amplitude auf einer ausgewählten Frequenz für eine bestimmte Zeitspanne dargestellt. Der zweite ist das Fehlen einer Übertragung auf der gewählten Frequenz und während des entsprechenden Zeitraums.

6.3 PHY-Varianten

Es wird eine Reihe von Modulationsschema-Varianten definiert. Jede Variante wird als PHY bezeichnet und hat einen Namen. Die Übertragungsgeschwindigkeiten auf der Bitübertragungsschicht werden in Symbolen pro Sekunde und nicht in Bits pro Sekunde gemessen, da die Bitübertragungsschicht nur mit analogen Funkartefakten und nicht mit digitalen Konzepten arbeitet.

Bluetooth LE verwendet ein binäres Modulationsverfahren, d. h. ein einzelnes analoges Symbol steht für ein einzelnes digitales Bit weiter oben im Stapel.

Jeder PHY enthält eine Eigenschaft, die als Product (BT) bezeichnet wird. BT bestimmt das Verhältnis zwischen der Bandbreite eines Signals und der Dauer der Symbole.

Der Wert von BT wirkt sich auf die Form und die Spanne der Funkimpulse aus, 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.

Die in der Bluetooth Core Specification definierten PHY-Typen werden im Folgenden zusammengefasst:

• Der LE 1M PHY verwendet eine Symbolrate von 1 Msym/s mit einer erforderlichen Frequenzabweichung von mindestens 185 kHz und verwendet keine spezielle Kodierung. Alle Geräte müssen den LE 1M PHY unterstützen. BT=0,5 mit diesem PHY.
• LE 2M PHY ist ähnlich wie LE 1M, verwendet jedoch eine Symbolrate von 2 Msym/s und hat eine erforderliche Frequenzabweichung von mindestens 370 kHz. Die Unterstützung des LE 2M PHY ist optional. BT=0,5 mit diesem PHY.
• Der LE 2M 2BT PHY hat eine Symbolrate von 2 Msym/s, erfordert aber einen Frequenzhub von mindestens 420 kHz. BT=2 mit diesem PHY.
• Der LE-codierte PHY verwendet eine Symbolrate von 1 Msym/s, aber die Pakete unterliegen einer Kodierung namens Forward Error Correction (FEC), die in der Verbindungsschicht definiert ist. FEC erhöht die effektive Reichweite der Übertragungen, reduziert aber die Anwendungsdatenrate. Die Unterstützung für den LE Coded PHY ist optional. BT=0,5 mit diesem PHY.

Es folgt ein Vergleich der PHYs:

	LE 1M	LE Kodiert S=2	LE Kodiert S=8	LE 2M	LE 2M 2BT
Symbolrate	1 M/s	1 M/s	1 M/s	2 M/s	2 M/s
Protokoll Datenrate	1 Mbit/s	500 Kbit/s	125 Kbit/s	2 Mbit/s	2 Mbit/s
Ungefähre Max. Anwendungsdatenrate	800 kbps	400 kbps	100 kbps	1400 kbps	N/A[3]
BT	0.5	0.5	0.5	0.5	2.0
Fehlererkennung	CRC	CRC	CRC	CRC	N/A[4]
Fehlerkorrektur	KEINE	FEC	FEC	KEINE	KEINE
Reichweite Multiplikator (ca.)	1	2	4	0.8	0.8
Anforderung	Obligatorisch	Optional	Optional	Optional	Optional

Definitionen

Begriff	Definition
Symbolrate	Die Rate, mit der analoge Symbole auf der Bitübertragungsschicht übertragen werden.
Protokoll Datenrate	Die Übertragungsrate von Bits, die sich auf Bluetooth-Protokolldateneinheiten (PDUs) beziehen, einschließlich ihrer Anwendungsdaten-Nutzlast, aber ohne FEC-Daten, die in Paketen enthalten sind, wenn der LE Coded PHY verwendet wird.
Ungefähre Max. Anwendungsdatenrate	Eine ungefähre maximale Rate, mit der Anwendungsdaten zwischen Anwendungen auf kommunizierenden Geräten übertragen werden können. Anwendungsdaten werden im Nutzlastteil verschiedener PDUs transportiert, der Rest der Protokolldatenrate wird von Bluetooth-Protokolldaten verbraucht.
CRC	Zyklische Redundanzprüfung. Ein Feld, das bei der Erkennung von Übertragungsfehlern verwendet wird. Dieses Feld und seine Verwendung werden auf der Verbindungsschicht definiert.

6.4 Zeiteinteilung

Ein Bluetooth LE ist ein Halbduplex-Gerät, das zwar senden und/oder empfangen kann, aber nicht beides gleichzeitig. Allerdings werden alle PHYs in einem Time Division Duplex (TDD) Schema verwendet, so dass der Anschein eines Vollduplex-Funkgerätes entsteht.

6.5 Sendeleistung und Empfangsempfindlichkeit

Die physikalische Schicht definiert die Eigenschaften des Senders, einschließlich der Anforderungen an die Ausgangsleistung, für die in der Spezifikation festgelegt ist, dass der Ausgangsleistungspegel bei der maximalen Leistungseinstellung zwischen 0,01 mW (-20 dBm) und 100 mW (+20 dBm) liegen muss.

Die Regulierungsbehörden[5] in verschiedenen Teilen der Welt können diese Anforderungen außer Kraft setzen, und die Anwender müssen sicherstellen, dass die Geräte mit den geltenden lokalen Vorschriften übereinstimmen.

Die Empfindlichkeit des Empfängers ist definiert als der Empfänger-Eingangspegel, bei dem eine bestimmte Bitfehlerrate (BER) auftritt. Die angegebene BER variiert je nach Länge eines empfangenen Pakets, da die Verbindungsschicht an jedes Paket ein einzelnes CRC-Feld (Cyclic Redundancy Check) anhängt und dieses als Mechanismus zur Erkennung eines oder mehrerer fehlerhafter Bits im decodierten Paket verwendet. Da die Pakete unterschiedlich lang sind und pro Paket ein CRC-Feld vorhanden ist, beeinflusst die Länge des Pakets die berechnete BER.

Bei Diskussionen über die Empfindlichkeit von Bluetooth LE wird in der Regel eine BER von 0,1 % angegeben. Dies ist die maximale Fehlerrate, die für Pakete mit einer Länge von bis zu 37 Oktetten zulässig ist.

Weitere von der Bitübertragungsschicht festgelegte Empfängereigenschaften sind das Interferenzverhalten, die Sperrung außerhalb des Bandes, die Intermodulationseigenschaften, der maximal nutzbare Eingangspegel und die erforderliche Genauigkeit der Empfangsstärkeanzeige (RSSI).

6.6 Antennenumschaltung

6.6.1 Richtungsbestimmung

Bluetooth LE unterstützt zwei Methoden zur Berechnung der Richtung, aus der ein empfangenes Signal gesendet wurde. Die erste Methode wird als Ankunftswinkel (AoA) und die zweite als Abfahrtswinkel (AoD) bezeichnet. Bei beiden Methoden verfügt ein Gerät über eine Reihe von Antennen und schaltet bei der Übertragung von Peilsignalen (AoD-Methode) oder beim Empfang von Signalen (AoA-Methode) von einer Antenne zur anderen um. Bei den Peilsignalen handelt es sich um Bluetooth-Standardpakete, die ein CTE-Feld (Constant Tone Extension) enthalten.

Antennengruppen gibt es in vielen verschiedenen Ausführungen, und die Umschaltung von einer Antenne auf die nächste kann nach einer Reihe unterschiedlicher Schaltmuster erfolgen. Dies wird vom host gesteuert, aber die Bitübertragungsschicht definiert auch einige allgemein gültige Regeln für den Prozess der Antennenumschaltung, damit verbundene Empfängeranforderungen und einige nützliche Definitionen.

Die Bluetooth Core Specification behandelt dieses Thema ausführlicher in Band 6, Teil A, Abschnitt 5. Weitere Informationen über die AoA- und AoD-Peilungsfunktion finden Sie im Dokument Bluetooth Core Specification Version 5.1 Feature Overview.

6.6.2 Bluetooth Channel Sounding

Bluetooth Channel Sounding erlaubt die Verwendung von mehr als einer Antenne in einem oder beiden Geräten und hat Regeln für die Auswahl und Verwendung von Antennen. Siehe Abschnitt 8.^Bluetooth® Channel Sounding.

7. Die Verbindungsschicht

7.1 Überblick über die Verbindungsschicht

Die Link-Layer-Spezifikation ist fast der größte Abschnitt der Bluetooth LE , der zweitgrößte nach dem Abschnitt " Host Controller Interface Functional Specification". Allerdings ist sie wohl auch die komplizierteste.

Die Verbindungsschicht hat viele Aufgaben. Sie definiert mehrere Arten von Paketen, die über die Luft übertragen werden, und ein zugehöriges Luftschnittstellenprotokoll. Ihr Betrieb unterliegt einer genau definierten Zustandsmaschine. Je nach Zustand kann die Verbindungsschicht auf ganz unterschiedliche Weise arbeiten, ausgelöst durch eine Reihe von Ereignissen. Es sind zahlreiche Kontrollverfahren definiert, die den Zustand einer Verbindung oder Verbindungsnutzungsparameter beeinflussen. Die Auswahl und Klassifizierung von Funkkanälen ist in der Spezifikation der Verbindungsschicht festgelegt.

Die Verbindungsschicht unterstützt sowohl verbundene als auch verbindungslose Kommunikation sowie deterministisches und (leicht) zufälliges Ereignis-Timing. Sie unterstützt sowohl die Punkt-zu-Punkt-Kommunikation zwischen zwei Geräten als auch die Eins-zu-Viel-Kommunikation von einem Gerät zu einer unbegrenzten Anzahl von empfangenden Geräten gleichzeitig. Je nachdem, wie die Verbindungsschicht verwendet wird, kann die Übertragung von Anwendungsdaten bidirektional sein oder nur in eine Richtung erfolgen.

Ein Großteil der Vielseitigkeit von Bluetooth LE liegt in der Ausgereiftheit der Verbindungsschicht begründet.

7.2 Pakete

Die Verbindungsschicht definiert zwei Pakettypen. Der erste wird von den uncodierten PHYs (siehe Abbildung 7), LE 1M und LE 2M und der zweite vom LE Coded PHY (siehe Abbildung 8) verwendet. Beachten Sie, dass andere Pakettypen für die Verwendung mit Channel Sounding definiert sind.

Abbildung 7 - Link-Layer-Paketformat für die LE uncodierten PHYs

Abbildung 8 - Link-Layer-Paket für den LE Coded PHY

Beide Pakettypen enthalten die Felder Präambel, Zugangsadresse und CRC. In Tabelle 1 wird jedes dieser gemeinsamen Felder erläutert.

Link Layer Packet Field Name	Beschreibung
Präambel	Die Präambel ermöglicht es dem Empfänger, sich genau auf die Frequenz des Signals zu synchronisieren, eine automatische Verstärkungsregelung durchzuführen und das Symboltiming zu schätzen.
Zugang Adresse	Die Zugangsadresse wird von den Empfängern verwendet, um Signale von Hintergrundgeräuschen zu unterscheiden und um festzustellen, ob ein Paket für das empfangende Gerät relevant ist oder nicht. Ein Paar verbundener Geräte tauscht zum Beispiel Pakete mit derselben zufällig zugewiesenen Zugangsadresse aus. Geräte, die nicht an der Verbindung teilnehmen, ignorieren solche Pakete, da die Zugangsadresse für sie nicht relevant ist. In ähnlicher Weise verwenden alle Legacy-Werbepakete dieselbe Zugangsadresse mit dem Wert 0x8E89BED6, was bedeutet, dass diese Pakete von allen Geräten empfangen werden können.
CRC	Die zyklische Redundanzprüfung wird zur Fehlererkennung verwendet. Sein Wert wird vom Sender anhand des Wertes der anderen Bits im Paket berechnet. Beim Empfang eines Pakets berechnet das empfangende Gerät ebenfalls einen CRC-Wert aus den Werten der Bits im empfangenen Paket mit Ausnahme derjenigen, die das CRC-Feld bilden. Der vom Empfänger berechnete CRC-Wert wird dann mit dem Wert des CRC-Feldes im Paket verglichen. Wenn die beiden CRC-Werte übereinstimmen, wurde das Paket korrekt empfangen. Andernfalls wird davon ausgegangen, dass es ein oder mehrere fehlerhafte Bits enthält.

Tabelle 1 - Gemeinsame Link-Layer-Paketfelder

Das PDU-Feld von Link-Layer-Paketen kann eine Vielzahl verschiedener Protokolldateneinheiten (PDUs) enthalten, je nachdem, wie Bluetooth LE verwendet wird. Die Constant Tone Extension (CTE) ist nur vorhanden, wenn eine der beiden Peilmethoden (Ankunftswinkel oder Abfahrtswinkel) verwendet wird.

Die PDU- und CRC-Felder werden vor der Übertragung des Pakets einem so genannten Whitening-Prozess unterzogen. Der Zweck des Whitening ist es, lange Sequenzen von Nullen oder Einsen in den Paketen zu vermeiden, da dies zu einer Drift der Frequenzverriegelung des Empfängers führen kann. Der Whitening-Prozess wird vom Empfänger rückgängig gemacht, um den ursprünglichen Bitstrom wiederherzustellen, bevor der CRC überprüft wird.

Das PDU-Feld kann verschlüsselt sein. In diesem Fall enthält es ein Feld für die Prüfung der Nachrichtenintegrität, das vor Manipulationen der PDU schützt[6].

Wenn der LE Coded PHY verwendet wird, wird der Bitstrom vor der Übertragung einer zusätzlichen Verarbeitung unterzogen. Die Anwendung eines FEC-Codierers (Forward Error Correction), gefolgt von einem Pattern Mapper, erzeugt zusätzliche Daten, die vom Empfänger verwendet werden, wenn er diese Prozesse in umgekehrter Richtung anwendet und, wenn möglich, den Wert aller Bits mit dem falschen Wert korrigiert.

7.3 Zustandsmaschine

Die Verbindungsschicht wird von einer Zustandsmaschine gesteuert, die in Abbildung 9 dargestellt ist.

Abbildung 9 - Die Link Layer State Machine

Einzelheiten zu den einzelnen Zuständen finden Sie in der Spezifikation der Verbindungsschicht. Eine Zusammenfassung findet sich in Tabelle 2. Beachten Sie, dass einige Begriffe später in diesem Abschnitt erklärt werden.

Staat	Beschreibung
Bereitschaft	Gerät sendet und empfängt keine Pakete.
Initiieren	Reagiert auf Werbepakete von einem bestimmten Gerät, um eine Verbindung anzufordern.
Werbung	Überträgt Werbepakete und verarbeitet möglicherweise Pakete, die als Antwort auf Werbepakete von anderen Geräten gesendet werden.
Verbindung	In einer Verbindung mit einem anderen Gerät.
Scannen	Lauschen auf Werbepakete von anderen Geräten.
Isochroner Rundfunk	Sendet isochrone Datenpakete.
Synchronisierung	Lauscht auf periodische Werbung, die zu einem bestimmten Werbezug gehört, der von einem bestimmten Gerät gesendet wird.

Tabelle 2 - Zustände der Verbindungsschicht

Im Zustand "Verbindung" sind zwei wichtige Geräterollen definiert. Diese sind die zentrale Rolle und die periphere Rolle. Ein Gerät, das eine Verbindung initiiert und vom Zustand "Initiating" in den Zustand "Connection" übergeht, übernimmt die Rolle "Central". Ein Gerät, das eine Verbindungsanfrage annimmt und vom Zustand "Werbung" in den Zustand "Verbindung" übergeht, nimmt die Rolle "Peripherie" ein.

Nehmen wir zum Beispiel ein Herzfrequenzmessgerät, das die Messwerte an ein Smartphone zur Verwendung durch eine Anwendung überträgt. Normalerweise würde das Smartphone die zentrale Rolle und der Herzfrequenzmesser die periphere Rolle übernehmen. Das Smartphone erkennt das Überwachungsgerät, indem es nach dessen Werbepaketen sucht, und initiiert dann, in der Regel unter Mitwirkung des Benutzers, eine Verbindung zu ihm. Sobald die Verbindung hergestellt ist, weist die Smartphone-Anwendung das Überwachungsgerät gemäß den in der Spezifikation des Herzfrequenzprofils festgelegten zusätzlichen Verfahren an, Messungen über die Verbindung zu senden.

Eine Instanz des Zustandsautomaten darf sich jeweils nur in einem Zustand befinden. Eine Verbindungsschichtimplementierung kann mehr als eine Zustandsmaschineninstanz gleichzeitig unterstützen.

Nicht alle Rollen- und Statuskombinationen sind zulässig. Die Bluetooth Core Specification enthält weitere Einzelheiten dazu.

7.4 Kanalauswahl

Wie in Abschnitt 6.1 Frequenzband beschrieben, unterteilt Bluetooth LE das 2,4-GHz-Frequenzband in 40 Kanäle. Die Verbindungsschicht steuert, wie diese Kanäle verwendet werden, was wiederum von der allgemeinen Art und Weise abhängt, in der Bluetooth LE für die Kommunikation verwendet wird (genauer gesagt, vom aktuellen physikalischen Kanal - dies wird in Abschnitt 7.7 Die Datentransportarchitektur behandelt).

Bluetooth LE nutzt Spreizspektrumsverfahren auf verschiedene Weise, um Daten über mehrere Kanäle im Laufe der Zeit zu übertragen. Dadurch wird die Wahrscheinlichkeit von Kollisionen verringert, was die Kommunikation zuverlässiger macht.

Ein bekanntes Beispiel für ein Spreizspektrumverfahren, das in Bluetooth LE verwendet wird, ist das adaptive Frequenzsprungverfahren. Dabei wird der für die Paketkommunikation verwendete Funkkanal in regelmäßigen Abständen gewechselt. Die Kanäle werden mit Hilfe eines Kanalauswahlalgorithmus und einer Datentabelle, der so genannten Kanalkarte , ausgewählt, die jeden Kanal entweder als benutzt oder als unbenutzt klassifiziert. Die Implementierungen können die Qualität der Kommunikation auf den einzelnen Kanälen überwachen, und wenn sich herausstellt, dass ein Kanal schlecht funktioniert, z. B. aufgrund von Störungen durch andere Quellen, kann die Kanaltabelle aktualisiert werden, um die Klassifizierung dieses Kanals auf " unbenutzt" zu setzen, wodurch sichergestellt wird, dass dieser Kanal nicht mehr vom Algorithmus ausgewählt wird. Auf diese Weise passt sich der Algorithmus für die Kanalauswahl an die jeweiligen Bedingungen an und optimiert die Leistung so zuverlässig wie möglich.

Wie Funkkanäle verwendet werden, wird weiter unten bei der Erörterung der logischen Bluetooth LE und der zugehörigen physischen Kanäle beschrieben.

7.5 Filterrichtlinien

Die Verbindungsschicht hat die Möglichkeit, empfangene Pakete nach verschiedenen Kriterien zu filtern, damit höhere Schichten des LE-Stapels nicht mit irrelevanten PDUs belastet werden, die zu verarbeiten sind. Die Kriterien, nach denen entschieden wird, ob Pakete gefiltert und verworfen oder zur weiteren Verarbeitung ausgewählt werden sollen, werden durch eine Reihe von Link-Layer-Filterrichtlinien definiert und implementiert. Es gibt getrennte Filterrichtlinien für jeden der Link-Layer-Zustände Advertising, Scanning, Initiating und Periodic Sync Establishment.

Filterrichtlinien arbeiten in einem Modus, von denen eine Reihe für die verschiedenen Zustände der Verbindungsschicht definiert sind. Der Standardmodus führt in allen Fällen dazu, dass keine Paketfilterung stattfindet. Andere Modi verwenden oft eine Liste von Geräteadressen, die Filter Accept List. In diesen Fällen werden Pakete von Geräten, deren Adresse in der Filter Accept List enthalten ist, wahrscheinlich nicht gefiltert, obwohl es andere Details zu den Bedingungen gibt, die in den verschiedenen Modi angewandt werden, und die Bluetooth Core Spezifikation für Details konsultiert werden sollte. Dies ist jedoch das Grundprinzip, das in den meisten Fällen zum Tragen kommt.

Anwendungen können die Filter-Akzeptanzliste auffüllen und die Filterrichtlinienmodi für die verschiedenen Link-Layer-Zustände mit HCI-Befehlen konfigurieren.

Eine Reihe spezieller Filterrichtlinienmodi, die so genannten "Decision Scanning Filter Policy Modes", sind definiert, und ihre Verwendung wird als " Decision-Based Advertising Filtering" (DBAF) bezeichnet. Mit DBAF können anspruchsvollere Filterbedingungen formuliert werden als nur die Prüfung auf Mitgliedschaft in der Filter-Akzeptanzliste.

DBAF-Modi gelten nur für die Scanning-Filter-Richtlinie und nur für bestimmte Arten von Werbe-PDUs, die auf den Primärkanälen empfangen werden. Die Filterung, die durch einen Entscheidungs-Scanning-Filtermodus herbeigeführt werden kann, gilt nur für erweiterte Werbepakete; weitere Informationen zu diesem Thema sind in Abschnitt 7.7.2.3.7 Entscheidungsbasierte Werbefilterung zu finden.

7.6 Überwachung der Inserenten

7.6.1 Filtern und Anwesenheit

Werbung kann als verbindungsloser Kommunikationstransport verwendet werden, aber wahrscheinlich wird sie am häufigsten zur Geräteerkennung eingesetzt.

Die Geräteerkennung umfasst das Scannen nach Werbepaketen. Der Empfang von Werbepaketen dient als Hinweis darauf, dass das werbende Gerät vorhanden ist, und kann je nach Art der Werbe-PDU anzeigen, dass das Gerät für eine Verbindung zur Verfügung steht.

Werbepakete werden vom controller verarbeitet, wobei die Einzelheiten in der Spezifikation für die Verbindungsschicht festgelegt sind. Die Host des Stapels werden über das Eintreffen von Werbepaketen und deren Inhalt anhand von Ereignissen informiert, die über dieController gesendet werden.

Ein Gerät kann zwischen einmal alle 20 Millisekunden und einmal alle 10,24 Sekunden werben. Da jedes empfangene Paket ein HCI-Ereignis erzeugt und vielleicht jedes Ereignis zu einem Aufruf einer Funktion in einer Anwendung führt, kann Werbung den physischen HCI-Transport, den Bluetooth LE Host und die Anwendung stark belasten. Glücklicherweise gibt es eine Möglichkeit, dies zu vermeiden.

Wenn die Werbung nur zum Zweck der Geräteerkennung erfolgt, ändert sich der Inhalt der Pakete normalerweise nicht. Eine Anwendung, die Anrufe zu empfangen wünscht, die sich auf empfangene Werbepakete beziehen, verwendet einen von mehreren HCI-Befehlen, um die Steuerung entsprechend zu instruieren. Mit diesen HCI-Befehlen kann die Anwendung angeben, ob sie Duplikate empfangen möchte oder nicht, indem sie einen treffend benannten HCI-Befehlsparameter, Filter_Duplicates, setzt. Wenn die Filterung von Duplikaten festgelegt ist, wird ein HCI-Ereignis und der damit verbundene Aufruf an die Anwendung nur einmal pro Werbegerät ausgeführt.

Das Filtern von Duplikaten hat jedoch auch einen potenziellen Nachteil. Bei ungefilterten Duplikaten weiß eine Anwendung im Allgemeinen, ob sich ein Gerät von Interesse noch in Reichweite befindet oder nicht. Wenn die Anwendung keine Werbedaten für das Gerät mehr erhält, kann davon ausgegangen werden, dass es sich nicht mehr in Reichweite befindet. Bei aktivierter Duplikatfilterung ist das Ausbleiben von HCI-Werbeereignissen jedoch kein Indikator mehr dafür, dass sich das Gerät nicht mehr in Reichweite befindet. Es ist genauso wahrscheinlich, dass es doppelte Pakete sendet und dass diese gefiltert werden.

Der Verlust des Bewusstseins für das Vorhandensein eines Geräts wird zu einem besonderen Problem, wenn es darum geht, Verbindungen herzustellen. Stellen Sie sich eine Anwendung vor, die nach Geräten in Reichweite sucht und dem Benutzer auf einer grafischen Benutzeroberfläche eine Liste zur Auswahl vorlegt. Wenn der Benutzer eine Auswahl trifft, fordert die Anwendung eine Verbindung mit dem ausgewählten Gerät an. Wenn eine Verbindung hergestellt werden muss, muss der LE-Controller zunächst eine Abtastung mit hohem Tastverhältnis durchführen. So kann er ein Werbepaket vom Zielgerät empfangen, bevor er ihm auf demselben Kanal mit einer Verbindungsanforderung antwortet. High Duty Cycle ist eine aggressive Form des Scannens, bei der die Werbepakete schnell empfangen werden, aber viel Energie verbraucht wird. Dies ist in Ordnung, wenn das Gerät, mit dem eine Verbindung hergestellt werden soll, noch in Reichweite ist, aber wenn es sich in der Zeit, die der Benutzer für die Auswahl benötigt hat, aus der Reichweite entfernt hat, dann ist dieser relativ teure Scanvorgang eine Energieverschwendung.

Manchmal lohnt es sich für eine Anwendung nicht, eine Verbindung zu einem Gerät herzustellen, wenn die Signalstärke gering ist, weil dies zum Beispiel ein Indikator dafür sein könnte, dass das Gerät nicht nahe genug ist, damit der Anwendungsfall der Anwendung sinnvoll ist. Technisch gesehen könnte das Gerät also noch vorhanden sein, aber bei einer geringen Signalstärke wäre das Scannen, um eine Verbindung herzustellen, genauso eine Energieverschwendung, wie wenn es sich tatsächlich außerhalb der Reichweite befindet.

Mit der Funktion zur Überwachung von Werbeträgern können doppelte Werbepakete gefiltert werden, ohne dass die Möglichkeit verloren geht, zu verfolgen, ob ein Gerät noch vorhanden ist und ob seine Signalstärke ausreicht, um eine Verbindung zu ihm herzustellen.

7.6.2 Werbebeobachtung nutzen

Der LE-Controller verwaltet eine Liste, die so genannte " Monitored Advertisers List". Anwendungen können HCI-Befehle verwenden, um ein Gerät von Interesse zusammen mit einem niedrigen RSSI-Schwellenwert (Signalstärke), einem hohen RSSI-Schwellenwert und einem Zeitüberschreitungswert zur Liste hinzuzufügen. Die Anwendung kann die Überwachung von Werbeträgern auch mit einem anderen Befehl aktivieren oder deaktivieren.

In Tabelle 3 werden die Parameter erläutert, die bestimmen, wie sich die Überwachung von Werbetreibenden für ein bestimmtes Gerät verhält.

Kenngröße(n)	Beschreibung
Adresse und Adresstyp	Die Adresse und der Adresstyp des zu überwachenden Geräts. Diese beiden Parameter ermöglichen es dem Controller, das Gerät zu identifizieren und zu überwachen.
RSSI-Schwellenwert niedrig	Wenn das RSSI aller Werbepakete von diesem überwachten Gerät für die durch den Time Out-Parameter angegebene Zeitspanne auf oder unter diesem Wert bleibt, wird gesagt, dass ein Signalverlust aufgetreten ist. Wenn dies geschieht, benachrichtigt die Steuerung den host mit einem HCI LE Monitor Advertisers Report-Ereignis. Der Status dieses Geräts wird auf " Awaiting RSSI High" gesetzt .
RSSI-Schwellenwert Hoch	Wenn die RSSI eines von diesem überwachten Gerät empfangenen Werbepakets größer oder gleich diesem Wert ist und der Gerätestatus " Awaiting RSSI High" lautet, sendet die Steuerung ein HCI LE Monitor Advertisers Report-Ereignis an den host , um ihn zu informieren, dass das Gerät in Reichweite ist. Der Status für dieses Gerät wird gelöscht oder gesetzt, um anzuzeigen, dass es nicht mehr auf ein RSSI über dem hohen Schwellenwert wartet, und der Timer, der zur Überwachung des Signalverlusts verwendet wird, wird zurückgesetzt.
Auszeit	Eine Zeit in Sekunden, die für die Überwachung des Signalverlusts verwendet wird. Wenn in diesem Zeitraum keine RSSI-Messung den Parameter RSSI-Schwelle niedrig überschreitet, gilt der Signalverlust als eingetreten.

Tabelle 3 - Parameter für überwachte Anzeigenkunden

Die Funktion zur Überwachung von Werbeträgern kann unabhängig davon verwendet werden, ob der controller angewiesen wurde, doppelte Werbeträger zu filtern oder nicht, ist aber eindeutig am nützlichsten, wenn sie bei aktivierter Filterung von doppelten Werbeträgern verwendet wird.

Abbildung 10 zeigt ein Beispielszenario mit der Funktion zur Überwachung von Werbeträgern. Der linke Teil des Diagramms ist ein Sequenzdiagramm, das den Empfang von Werbepaketen, die Verwendung von HCI-Befehlen zur Konfiguration der Werbeüberwachung und anschließend die Verwendung von HCI-Ereignissen zur Anzeige der Ein- und Ausfahrt des werbenden Geräts auf der Grundlage der konfigurierten RSSI-Schwellenwerte zeigt. Die rechte Seite zeigt die sich ändernde Signalstärke des Geräts und die daraus resultierenden Zustandsänderungen und HCI-Ereignisse.

Abbildung 10 - Beispiel für die Überwachung von Werbetreibenden

Tabelle 4 erläutert die beschrifteten Punkte von Interesse in Abbildung 10.

Punkt	Erläuterung
A	Der host des Scanners fragt zunächst das Steuergerät, wie viele Werbegeräte es überwachen kann. Der host fügt dann ein Gerät zur Liste hinzu, zusammen mit den Werten für RSSI niedrig, RSSI hoch und Timeout (nicht gezeigt). Schließlich weist der host das Steuergerät an, die Überwachung der Werbeträger zu aktivieren.
B	An diesem Punkt beginnt die Abbildung, Werbepakete zu zeigen, die vom ersten Gerät übertragen werden. Beachten Sie, dass das Gerät bereits vor diesem Zeitpunkt Werbung gesendet haben könnte, aber die Pakete werden erst ab diesem Zeitpunkt angezeigt. Empfangene Pakete haben einen RSSI-Wert, der größer ist als der konfigurierte niedrige Schwellenwert, so dass der Timer für das überwachte Gerät bei jedem empfangenen Paket zurückgesetzt wird.
C	Die nächsten Pakete, die nach Punkt C empfangen werden, haben einen RSSI-Wert, der unter dem niedrigen RSSI-Schwellenwert liegt, so dass der Timer an Punkt C zum letzten Mal zurückgesetzt wird und ab diesem Punkt läuft.
D	Es wird nun eine Reihe von Paketen mit niedrigem RSSI empfangen, und am Punkt D tritt eine Zeitüberschreitung ein. Der Controller zeigt dem host den Signalverlust an, indem er ein Ereignis LE Monitor Advertisers Report mit condition == 0x00 sendet. Das Gerät befindet sich nun im Zustand "Awaiting High RSSI" (Warten auf hohes RSSI) in der Liste der Überwachungswerber.
E	Zum Zeitpunkt E wird das erste einer Reihe von Paketen empfangen, deren RSSI über dem niedrigen Schwellenwert liegt. Für jedes dieser Pakete wird der Timer zurückgesetzt.
F	Am Punkt F überschreitet der RSSI-Wert den Schwellenwert RSSI High. Der host wird über ein vom Controller gesendetes Ereignis LE Monitor Advertisers Report mit condition == 0x01 informiert, dass das überwachte Gerät wieder mit einem ausreichend starken Signal in Reichweite ist. Das Gerät befindet sich nicht mehr im Zustand "Awaiting High RSSI".

Tabelle 4 - Interessante Punkte im Beispiel der Überwachung von Anzeigenkunden

7.7 Die Datentransportarchitektur

Der Abschnitt über die Architektur der Bluetooth-Kernspezifikation definiert eine Reihe von Konzepten, die zusammengenommen die Bluetooth-Datentransportarchitektur bilden. Zu den wichtigsten dieser Konzepte gehören der physikalische Kanal, die physikalische Verbindung, die logische Verbindung und der logische Transport. Bestimmte Kombinationen sind für die Unterstützung verschiedener Anwendungstypen definiert, die jeweils besondere Anforderungen in Bezug auf Topologie, Timing, Zuverlässigkeit und Kanalnutzung haben.

Ein physikalischer Kanal definiert eine von mehreren verschiedenen Möglichkeiten der Kommunikation über Bluetooth. Zum Beispiel kann die Kommunikation zwischen zwei verbundenen Geräten über den LE Piconet Physical Channel erfolgen, der ein adaptives Frequenzsprungverfahren über 37 Kanäle beinhaltet. Alternativ dazu kann der LE Advertising Physical Channel für die verbindungslose Broadcast-Kommunikation von einem Gerät zu einer unbegrenzten Anzahl anderer Geräte verwendet werden. Der LE Periodic Physical Channel kann ebenfalls für die Übertragung von Daten verwendet werden, allerdings auf einer regelmäßigen Basis mit einem deterministischen Zeitplan. Beobachtergeräte (Empfänger) sind in der Lage, diesen Zeitplan zu bestimmen und ihn zur Synchronisierung ihrer Abtastzeitpläne zu verwenden.

Eine Physikalische Verbindung basiert auf einem einzigen physikalischen Kanal und spezifiziert bestimmte Merkmale dieser Verbindung, wie z. B. die Verwendung oder Nichtverwendung von Leistungssteuerung.

Logische Verbindungen und Transporte haben verschiedene Parameter, die dazu dienen, einen bestimmten Satz von Datenkommunikationsanforderungen über eine physikalische Verbindung unter Verwendung eines bestimmten physikalischen Kanaltyps zu unterstützen.

Zum Beispiel verwendet die zuverlässige, bidirektionale Punkt-zu-Punkt-Kommunikation in Bluetooth LE den asynchronen verbindungsorientierten logischen Transport (ACL) mit entweder einer LE-C-Verbindung für Steuerdaten oder einer LE-U-Verbindung für Nutzdaten über eine physikalische Verbindung, die auf dem LE Piconet Physical Channel basiert.

Andererseits verwendet die unzuverlässige, unidirektionale Broadcast-Kommunikation in Bluetooth LE den logischen Transport LE Advertising Broadcast (ADVB) mit entweder einem ADVB-C-Link für Steuerdaten oder einem ADVB-U-Link für Nutzdaten über eine physikalische Verbindung, die auf dem LE Advertising Physical Channel basiert.

7.8 Die logischen Transporte

7.8.1 LE ACL - LE Asynchroner verbindungsorientierter logischer Transport

7.8.1.1 Grundlagen

Wenn zwei Bluetooth LE miteinander verbunden sind, verwenden sie den asynchronen verbindungsorientierten logischen Transport (LE-ACL oder einfach ACL). LE-ACL ist einer der am häufigsten verwendeten logischen Bluetooth LE , der eine verbindungsorientierte Kommunikation von Daten ermöglicht. Tatsächlich werden ACL-Verbindungen im Allgemeinen einfach als Verbindungen bezeichnet.

Ein Gerät kann eine Verbindung mit einem werbenden Gerät herstellen, indem es auf ein empfangenes Werbepaket mit einer PDU antwortet, die eine Verbindung anfordert. In der Anfrage wird eine Reihe von Parametern angegeben. Zu diesen Parametern gehören die Zugriffsadresse, das Verbindungsintervall, die periphere Latenz, der Überwachungs-Timeout und die Kanalzuordnung.

Das Gerät, das die Verbindung anfordert, geht vom Bereitschaftszustand in den Initiierungszustand über, wechselt dann in den Verbindungszustand und übernimmt die Rolle der Zentrale. Das andere Gerät geht vom Zustand "Werbung" in den Zustand "Verbindung" über und nimmt die Rolle des Peripheriegeräts ein.

Der Parameter für das Verbindungsintervall legt fest, wie oft (in Millisekunden) das Funkgerät für die Bedienung dieser Verbindung verwendet werden kann. Wann immer das Verbindungsintervall abläuft, beginnt ein Verbindungsereignis, und zu diesem Zeitpunkt kann das zentrale Gerät in der Verbindung ein Paket senden. Verbindungsereignisse für eine bestimmte Verbindung haben jeweils eine 16-Bit-Kennung, die ein Zählerwert ist, der bei jedem Ereignis erhöht wird. Zu Beginn eines jeden Verbindungsereignisses wird der zu verwendende Funkkanal mit Hilfe des entsprechenden Kanalauswahlalgorithmus ausgewählt.

Der Parameter Überwachungs-Timeout gibt die maximale Zeit an, die zwischen dem Empfang von zwei Link-Layer-Datenpaketen verstreichen darf, bevor die Verbindung als verloren gilt.

Das Peripheriegerät, das über dieselben vereinbarten Verbindungsparameter wie das Zentralgerät verfügt, weiß, wann und über welchen Kanal es die von der Zentrale gesendeten Pakete zu erwarten hat, und kann sich daher dafür entscheiden, genau zur gleichen Zeit auf diesem Kanal zu lauschen und somit das Paket von der Zentrale zu empfangen. Nach dem Empfang des letzten Bits des Pakets der Zentrale wartet das Peripheriegerät eine kurze Zeitspanne (Standardwert 150 Mikrosekunden) und kann dann dem Zentralgerät antworten. Beachten Sie, dass die Zeitspanne zwischen den Paketübertragungen als Inter-Frame-Space-Time (IFS) bezeichnet wird.

Die Zentrale und das Peripheriegerät wechseln sich dann mit dem Senden und Empfangen von Paketen ab und können während des Verbindungsvorgangs eine durch die Implementierung festgelegte Anzahl von Paketen austauschen. Das Verhalten des Peripheriegeräts kann durch einen Parameterwert für die Latenzzeit des Peripheriegeräts, der nicht Null ist, geändert werden.

Abbildung 11 zeigt einen grundlegenden Austausch von Paketen während zweier Verbindungsereignisse, wobei C>P die Paketübertragung durch die Zentrale und P>C durch das Peripheriegerät anzeigt.

Abbildung 11 - Austausch von Basispaketen über eine LE-ACL-Verbindung

Pakete, die über eine LE ACL-Verbindung ausgetauscht werden, enthalten entweder LL-Daten-PDUs oder LL-Steuer-PDUs, die mit Link-Layer-Steuerungsverfahren verbunden sind.

7.8.1.2 Bestellung und Bestätigungen

LE-ACL beinhaltet ein System, das sicherstellt, dass die Daten in der richtigen Reihenfolge verarbeitet werden, dass der Empfang von Paketen bestätigt werden kann und dass auf dieser Grundlage entschieden wird, ob mit dem nächsten Paket fortgefahren oder stattdessen das vorherige Paket erneut übertragen wird.

Datenpakete enthalten drei wichtige Felder, die zur Zuverlässigkeit der Kommunikation beitragen. Diese Felder sind die Sequenznummer (SN), die nächste erwartete Sequenznummer (NESN) und das Feld Weitere Daten. Bei allen drei Feldern handelt es sich um Ein-Bit-Felder, deren Verwendung ein System von Bestätigungen und eine Methode zur Überprüfung der richtigen Reihenfolge der empfangenen Pakete ermöglicht.

Die Kommunikation beginnt damit, dass das zentrale Gerät (Gerät A) ein Link-Layer-Datenpaket sendet, bei dem SN und NESN beide auf Null gesetzt sind. Von diesem Zeitpunkt an wechselt der Wert des SN-Feldes, wie er von Gerät A eingestellt wurde, bei jedem stattfindenden Paketaustausch zwischen Null und Eins, wenn alles in Ordnung ist. Das Peripheriegerät (Gerät B) weiß daher immer, wie der SN-Wert des nächsten zu empfangenden Pakets sein sollte, und überprüft dies.

Wenn Gerät B ein Paket von Gerät A mit dem erwarteten SN-Wert empfängt, antwortet es mit einem Datenpaket der Verbindungsschicht, in dem NESN auf den logischen Wert NOT(SN) gesetzt ist. Wenn der empfangene SN-Wert beispielsweise 1 war, wird NESN in der Antwort 0 sein.

Wenn Gerät A eine Antwort von Gerät B erhält, in der NESN auf den Wert gesetzt ist, den Gerät A in seinem nächsten Paket für SN zu verwenden beabsichtigt, betrachtet Gerät A dies als eine Bestätigung von Gerät B, dass es das zuletzt gesendete Paket korrekt empfangen hat. Abbildung 12 zeigt dies.

Abbildung 12 - Ein erfolgreicher Austausch von Paketen auf der Verbindungsschicht

Wenn Gerät B ein Paket mit dem falschen SN-Wert empfängt, geht es davon aus, dass es sich um die erneute Übertragung des zuvor empfangenen Pakets handelt, bestätigt es, leitet es aber nicht zur weiteren Verarbeitung weiter.

Erhält Gerät A in einer Antwort von Gerät B einen unerwarteten NESN-Wert oder gar keine Antwort, sendet es das Paket erneut mit demselben SN-Wert, der ursprünglich verwendet wurde. Es steht den verschiedenen Controller-Implementierungen frei, unterschiedliche Algorithmen zu implementieren, um festzulegen, wie oft das Paket erneut gesendet werden muss, bevor die Kommunikation als gescheitert gilt. Siehe Abbildung 13.

Abbildung 13 - Wiederholte Übertragungen auf der Verbindungsschicht

Jedes Paket enthält ein CRC-Feld, und verschlüsselte Pakete enthalten auch ein MIC-Feld. Beim Empfang eines Pakets prüft die Verbindungsschicht den CRC-Wert und, falls vorhanden, den MIC-Wert. Wenn eine der beiden Prüfungen fehlschlägt, wird das Paket nicht bestätigt, was im Allgemeinen dazu führt, dass der Absender des Pakets es erneut sendet. Siehe Abbildung 14.

Abbildung 14 - Link Layer Behandlung von CRC-Fehlern

7.8.1.3 Peripherie-Latenzzeit

Das Peripheriegerät muss nicht bei jedem Verbindungsereignis auf Pakete vom Zentralgerät warten. Der Parameter für die Latenzzeit des Peripheriegeräts legt die Anzahl der aufeinanderfolgenden Verbindungsereignisse fest, während der das Peripheriegerät nicht lauschen muss. Dadurch kann das Peripheriegerät Strom sparen.

Abbildung 15 zeigt das Verhalten des Peripheriegeräts, wenn die Latenzzeit des Peripheriegeräts = 1 ist und es daher nur während alternativer Verbindungsereignisse lauscht. Die Zentrale kann während der Ereignisse, bei denen das Peripheriegerät nicht zuhört, senden, aber solche Pakete werden nicht empfangen und daher nicht bestätigt, wodurch das Verbindungsereignis beendet wird.

Abbildung 15 - Eine ACL-Verbindung mit Peripherie-Latenz = 1

7.8.1.4 Kanalnutzung

LE-ACL verwendet ein Verfahren, das als adaptives Frequenzsprungverfahren bekannt ist. Zu Beginn eines jeden Verbindungsereignisses findet ein Frequenzsprung statt, wobei ein Funkkanal mit Hilfe eines Kanalauswahlalgorithmus deterministisch aus der Menge der verfügbaren Kanäle ausgewählt wird. Jedes Gerät in der Verbindung schaltet dann auf den ausgewählten Kanal um, und im Laufe der Zeit und einer Reihe von Verbindungsereignissen findet die Kommunikation über eine häufig wechselnde Reihe verschiedener Kanäle statt, die über das 2,4-GHz-Band verteilt sind, wodurch die Wahrscheinlichkeit von Kollisionen erheblich verringert wird.

Von den 40 Kanälen, die für die Verwendung durch Bluetooth LE definiert sind, stehen 37 dieser Kanäle (die so genannten Allzweckkanäle) für eine LE-ACL-Verbindung zur Verfügung.

In einer bestimmten Umgebung funktionieren einige Bluetooth möglicherweise nicht gut, weil sie durch Störungen beeinträchtigt werden, während andere Kanäle zuverlässig funktionieren. Im Laufe der Zeit kann sich die Liste der zuverlässigen und unzuverlässigen Kanäle ändern, wenn andere drahtlose Kommunikationsgeräte in der Umgebung kommen und gehen.

Das zentrale Gerät in einer Verbindung unterhält eine Kanalkarte, die die Mehrzweckkanäle als verwendet oder nicht verwendet klassifiziert. Diese Kanalkarte wird mit dem Peripheriegerät über ein Verbindungsschichtverfahren ausgetauscht, so dass beide über dieselben Informationen darüber verfügen, welche Kanäle verwendet werden und welche nicht. Der Kanalauswahlalgorithmus stellt sicher, dass als ungenutzt eingestufte Kanäle vermieden werden.

Standardmäßig werden alle Mehrzweckkanäle als verwendet eingestuft, aber die Zentralgeräte können implementierungsspezifische Techniken verwenden, um zu überwachen, wie gut die einzelnen Kanäle funktionieren. Stellt die Zentrale fest, dass ein oder mehrere Kanäle nicht gut genug funktionieren, kann sie deren Klassifizierung in der Kanalkarte auf unbenutzt aktualisieren. Wird hingegen festgestellt, dass ein zuvor schlecht funktionierender Kanal jetzt gut funktioniert, kann seine Klassifizierung in der Kanalkarte auf verwendet aktualisiert werden. Die Aktualisierungen der Kanalzuordnung können dann an das Peripheriegerät weitergegeben werden.

Ein Peripheriegerät kann auch seine eigene Kanalüberwachung durchführen und in regelmäßigen Abständen Kanalstatusberichte an das Zentralgerät senden, wobei der Status jedes Kanals als gut, schlecht oder unbekannt eingestuft wird. Die Zentrale kann dann Entscheidungen über die Kanalklassifizierung in der Kanalkarte treffen, die sowohl ihre eigenen Funkbedingungen als auch die des entfernten Peripheriegeräts berücksichtigen.

Auf diese Weise ist es möglich, dass ein Bluetooth LE nur die optimale Untergruppe der verfügbaren Kanäle verwendet und so zum Beispiel effektiv mit anderen drahtlosen Technologien koexistiert, die statisch zugewiesene Kanäle verwenden. Dies ist der adaptive Aspekt des adaptiven Frequenzsprungsystems von Bluetooth.

Hinweis: Regulierungsbehörden können adaptive Frequenzsprünge und die damit verbundene Terminologie anders definieren als die Bluetooth-Kernspezifikation. Es wird empfohlen, die Vorschriften für die Frequenznutzung in den Zielmärkten bereits zu Beginn des Produktentwicklungszyklus zu prüfen, da sich daraus bestimmte Implementierungsentscheidungen ergeben können. Siehe Abschnitt 18. Zusätzliche Ressourcen finden Sie einen Link zum Regulatory Aspects Document der Bluetooth SIG, das Hinweise zu regulatorischen Fragen enthält.

Abbildung 16 zeigt, wie die Kanäle während des Tests von zwei angeschlossenen Geräten genutzt wurden, und veranschaulicht, wie sich die Funknutzung über das ISM-2,4-GHz-Spektrum verteilt. Am unteren Rand des Diagramms sehen Sie den Kanalindex und die Frequenzen in MHz. Der Kanalindex ist eine indirekte Art, einen Funkkanal zu referenzieren.

Abbildung 16 - Adaptives Frequenzsprungverfahren zur Verteilung der Kommunikation auf verschiedene Kanäle

7.8.1.5 Kontrolle der Verbindungsschicht

Die Spezifikation der Verbindungsschicht legt eine Reihe von Kontrollverfahren fest. Eine Auswahl von Beispielen ist in Tabelle 5 aufgeführt.

Kontrollverfahren	Beschreibung
Update der Verbindung	Ermöglicht es entweder dem zentralen oder dem peripheren Gerät, Änderungen der Verbindungsparameter Verbindungsintervall, periphere Latenzzeit und Überwachungs-Timeout anzufordern.
Update der Kanalkarte	Ermöglicht es dem Zentralgerät, seine neuesten Kanalzuordnungsdaten an das angeschlossene Peripheriegerät zu übertragen.
Verschlüsselung	Ermöglicht es, die Verschlüsselung von Paketen entweder zentral oder dezentral zu aktivieren.
Austausch von Funktionen	Ermöglicht es der Zentrale oder dem Peripheriegerät, einen Austausch der von jedem Gerät unterstützten Verbindungsschichtmerkmale zu initiieren, die als Bitmap-Feld kodiert sind.
Periodische Werbung Sync-Übertragung	Ermöglicht es entweder der Zentrale oder der Peripherie, Synchronisationsinformationen über periodische Werbung[7] zu übertragen, die sich auf einen periodischen Werbezug beziehen, der dem anderen Gerät über eine LE ACL-Verbindung entdeckt wurde.
CIS-Erstellungsverfahren	Ermöglicht einem zentralen Gerät, einen Connected Isochronous Stream (CIS)[8] mit dem Peripheriegerät zu erstellen.
Anfrage zur Leistungssteuerung	Ermöglicht es einem Peer, den anderen Peer aufzufordern, seinen Sendeleistungspegel anzupassen.
Berichte zur Kanalklassifizierung	Ermöglicht es einem Peripheriegerät, Daten zur Kanalklassifizierung an die angeschlossene Zentrale zu melden.

Tabelle 5 - Beispiel für Kontrollverfahren auf der Verbindungsschicht

7.8.1.6 Unterbemessene Verbindungen

Unterbewertete Verbindungen sind LE ACL-Verbindungen, denen zusätzliche Eigenschaften zugewiesen sind und die sich in mancher Hinsicht anders verhalten. Die zusätzlichen Eigenschaften werden als Subrate-Faktor, Subrate-Basisereignis und Fortsetzungsnummer bezeichnet.

Die untergeordneten Verbindungseigenschaften bieten einen Mechanismus, mit dem angegeben werden kann, dass nur eine bestimmte Teilmenge von Verbindungsereignissen von den angeschlossenen Geräten aktiv genutzt werden soll, während das Funkgerät bei anderen Verbindungsereignissen nicht verwendet wird. Eine unterbewertete Verbindung kann daher ein kurzes ACL-Verbindungsintervall haben, aber dennoch einen niedrigen Duty Cycle aufweisen.

Abbildung 17 veranschaulicht die grundlegenden Konzepte im Zusammenhang mit unterbewerteten Verbindungen

Abbildung 17 - Eine einfache unterbewertete Verbindung mit Unterbewertungsfaktor=5

Hier können wir sehen, dass nur eines von fünf Verbindungsereignissen genutzt wird. Die anderen vier werden übersprungen, so dass während dieser Verbindungsereignisse keine Funkaktivität stattfindet. Dieses Verhältnis zwischen genutzten und übersprungenen Verbindungsereignissen wird durch den Parameter "Subrate-Faktor" bestimmt, der in diesem Beispiel auf 5 gesetzt ist.

Das Verbindungsereignis, bei dem das Funkgerät zum Senden und Empfangen von Paketen der Verbindungsschicht verwendet wird, wird als subrated connection event bezeichnet.

Angesichts der Beziehung zwischen den zugrundeliegenden ACL-Verbindungsparametern und den Parametern, die das Subrating von Verbindungen regeln, kann man sich eine Verbindung mit Subrating so vorstellen, dass sie sowohl ein Verbindungsintervall hat, das die Häufigkeit steuert, mit der ACL-Verbindungsereignisse auftreten, als auch ein effektives Verbindungsintervall, das bestimmt, wie oft diese ACL-Verbindungsereignisse tatsächlich genutzt werden, nachdem die Subrating-Parameter angewendet worden sind.

Unterbewertete Verbindungen verwenden einen anderen Satz von Link-Layer-Kontrollverfahren, und insbesondere das Verfahren zur Aktualisierung von unterbewerteten Verbindungsparametern funktioniert anders als das allgemeine Kontrollaktualisierungsverfahren. Entscheidend ist, dass Änderungen an unterbewerteten Verbindungsparametern fast augenblicklich vorgenommen werden können, während es bei allgemeinen Parameteränderungen sehr lange dauern kann, bis sie wirksam werden. Der Vorteil von subrated-Verbindungen besteht also darin, dass dauerhafte Verbindungen, die ein geringes Tastverhältnis aufweisen und wenig Strom verbrauchen, aufgebaut werden können und ohne für den Benutzer spürbare Verzögerung auf eine Verbindung mit hohem Tastverhältnis und hoher Bandbreite umgeschaltet werden können. Diese Fähigkeit ist besonders in einigen LE-Audio-Szenarien anwendbar, z. B. bei Hörgeräten und Smartphones.

Die Bluetooth Core Specification Version 5.3 Feature Enhancements enthält ein umfangreiches Kapitel zum Thema subrated connections und wird als Quelle für weitere Informationen empfohlen.

7.8.2 ADVB - LE Advertising Broadcast

7.8.2.1 Grundlagen

LE Advertising Broadcast (oder einfach Advertising) bietet einen verbindungslosen Kommunikationsmodus. Er kann zur Datenübertragung oder zur Anzeige der Verfügbarkeit eines Peripheriegeräts verwendet werden, an das eine Verbindung hergestellt werden soll.

Im Allgemeinen sind Werbepakete dazu bestimmt, von jedem Scan-Gerät in Reichweite empfangen zu werden, und daher kann Werbung zur gleichzeitigen Übertragung von Daten an mehrere Scan-Geräte in einer One-to-many-Topologie verwendet werden. Eine besondere Form der Werbung, die als gerichtete Werbung bezeichnet wird, ist jedoch definiert und ermöglicht die verbindungslose Kommunikation von Daten von einem werbenden Gerät zu einem bestimmten Scan-Gerät, das durch seine Bluetooth-Geräteadresse identifiziert wird.

Werbung, wie sie für den logischen ADVB-Transport gilt, unterstützt die Kommunikation von Anwendungsdaten nur in einer Richtung, nämlich vom werbenden Gerät zu den scannenden Geräten, aber solche Geräte können auf Werbepakete mit PDUs antworten, die weitere Informationen oder den Aufbau einer Verbindung anfordern. Wenn ein Scanning-Gerät antwortet, um weitere Informationen zu erhalten, spricht man von einem aktiven Scanning. Wenn es dies nicht tut, spricht man von passivem Scanning.

Werbung wird im Allgemeinen als unzuverlässiger Transport bezeichnet, da von den Empfängern keine Bestätigungen gesendet werden.

Es sind zwei Kategorien von Werbeverfahren definiert, die in der Bluetooth Core Specification als Legacy Advertising und Extended Advertising bezeichnet werden.

7.8.2.2 Veraltete Werbung

7.8.2.2.1 Kanalnutzung und Paketgröße

Legacy-Werbepakete, die den PDU-Typ ADV_IND verwenden (siehe 7.8.2.2.3 Legacy-Werbung und zugehörige PDU-Typen), sind 37 Oktette lang, mit einem 6-Oktett-Header und einer Nutzlast von höchstens 31 Oktetten. Identische Kopien von Werbepaketen werden auf bis zu drei dedizierten Kanälen mit den Nummern 37, 38 und 39, den so genannten primären Werbekanälen, übertragen, und zwar ein Kanal nach dem anderen und in einer bestimmten Reihenfolge.

Abbildung 18 - Ältere Werbung und Kanalnutzung

7.8.2.2.2 Zeitplanung

Die Übertragung eines Werbepakets erfolgt immer dann, wenn ein Werbeereignis eintritt. Die Terminierung der Werbeereignisse wird durch Zeitparameter gesteuert und ist im Grundfall bewusst etwas unregelmäßig gestaltet, um anhaltende Kollisionen mit anderen Werbegeräten zu vermeiden. Einem als advDelay bezeichneten Wert wird bei jedem Werbeereignis ein Pseudozufallswert im Bereich von 0 bis 10 ms zugewiesen, der zum regulären Werbeintervall(advInterval) addiert wird, so dass die Werbeereignisse zeitlich gestört werden. Abbildung 19 gibt Abbildung 4.5 aus Band 6 Teil B der Bluetooth-Kernspezifikation wieder und veranschaulicht die Wirkung des Parameters advDelay.

Abbildung 19 - Zeitlich gestörte Werbeereignisse mit advDelay

Die Planung von Werbeereignissen auf diese Weise hilft, Kollisionen zu vermeiden, erschwert aber den Empfängern den effizienten Empfang von Werbepaketen, da ein höherer RX-Duty-Cycle erforderlich ist, um den unvorhersehbaren Zeitpunkt von Werbeereignissen zu berücksichtigen.

7.8.2.2.3 Veraltete Werbung und zugehörige PDU-Typen

Es sind mehrere PDU-Typen für die Verwendung mit Legacy Advertising definiert. Verschiedene PDU-Typen werden für ungerichtete Werbung verwendet, bei der die Pakete für ein beliebiges Scanning-Gerät bestimmt sind, und für gerichtete Werbung, bei der die Pakete an ein bestimmtes Gerät gerichtet sind. Der PDU-Typ gibt auch an, ob aktives Scannen erlaubt ist oder nicht, wobei die Empfänger mit Anfragen nach weiteren Daten antworten, und ob mit dem werbenden Gerät eine Verbindung hergestellt werden darf oder nicht. Die gesamte Legacy-Werbung findet auf einem oder mehreren der Primärkanäle mit den Nummern 37, 38 und 39 statt und darf nur den LE 1M PHY verwenden.

In Tabelle 6 sind die Legacy-PDUs für Werbung aufgeführt.

PDU-Name	Beschreibung	Kanäle	PHY(s)	Übermittelt von	Einlesbar	Anschließbar
ADV_IND	Ungezielte Werbung	primär	LE 1M	Peripherie	Y	Y
ADV_DIRECT_IND	Gezielte Werbung	primär	LE 1M	Peripherie	N	Y
ADV_NONCONN_IND	Ungezielte, nicht verknüpfbare, nicht durchsuchbare Werbung	primär	LE 1M	Peripherie	N	N
ADV_SCAN_IND	Ungezielte, durchsuchbare Werbung	primär	LE 1M	Peripherie	Y	N
SCAN_REQ	Anfrage scannen	primär	LE 1M	Zentrale	K.A.	K.A.
SCAN_RSP	Scan-Antwort	primär	LE 1M	Peripherie	K.A.	K.A.
CONNECT_IND	Anfrage verbinden	primär	LE 1M	Zentrale	K.A.	K.A.

Tabelle 6 - Ältere Werbe-PDUs

Abschnitt 4.4 des Kapitels über die Spezifikation der Verbindungsschicht in der Bluetooth enthält vollständige Angaben zu allen Werbe-PDU-Typen.

7.8.2.3 Erweiterte Werbung

Mit der Version 5 der Bluetooth Core Specification wurden einige wichtige Änderungen an der Art und Weise vorgenommen, wie Werbung durchgeführt werden kann. Es wurden acht neue PDUs für Werbung, Scannen und Verbindung hinzugefügt und neue Verfahren definiert. Dieser neue Satz von Werbemöglichkeiten wird als " erweiterte Werbung" bezeichnet.

Die erweiterte Werbung ermöglicht die Übertragung sehr viel größerer Datenmengen, die Durchführung von Werbung nach einem deterministischen Zeitplan und die Übertragung mehrerer verschiedener Sätze von Werbedaten, die unterschiedlichen Konfigurationen unterliegen. Sie bietet auch erhebliche Verbesserungen in Bezug auf die Konkurrenzsituation und den Arbeitszyklus.

Die erweiterte Werbung wird sowohl von den logischen Transporten ADVB als auch PADVB verwendet.

7.8.2.3.1 Kanalnutzung und Paketgröße

Die Funkkanäle werden anders genutzt als bei der herkömmlichen Werbung, wobei die Hauptwerbekanäle 37, 38 und 39 weniger Daten übertragen und die Mehrzweckkanäle 0 - 36 den größten Teil der Daten übertragen.

Wie in 7.8.2.2 Legacy-Werbung beschrieben, überträgt Legacy-Werbung dieselbe Nutzlast bis zu dreimal auf drei verschiedenen primären Werbekanälen. Bei der erweiterten Werbung werden die Nutzdaten nur einmal übertragen, und zwar mit kleinen Headern, die auf die Nutzdaten in den primären Kanälen verweisen. Die Gesamtmenge der übertragenen Daten ist daher geringer als im entsprechenden Fall mit Legacy-Werbung, so dass der effektive Duty Cycle reduziert wird.

Abbildung 20 - Geringere Konkurrenzsituation und geringere Einschaltdauer

Bei der erweiterten Werbung können die Pakete bis zu 255 Oktette lang sein. Dies wird zum Teil dadurch erreicht, dass die Nutzlast auf einen der Allzweckkanäle im Kanalnummernbereich 0-36 verlagert wird.

Abbildung 21 - Erweiterte Werbung unterstützt größere Werbepakete und Channel Offload

Bei erweiterter Werbung werden auf den primären Kanälen mit den Nummern 37, 38 und 39 nur Kopfdaten übertragen. Dazu gehört ein Feld namens AuxPtr.

Das Feld AuxPtr verweist auf ein zugehöriges Hilfspaket, das die Nutzlast enthält, die auf einem Allzweckkanal aus der Gruppe der Kanäle mit den Nummern 0 - 36 übertragen wird. AuxPtr enthält den Index des Allzweckkanals, der den Kanal angibt, auf dem das Hilfspaket übertragen wird, damit die Empfänger wissen, wo es zu finden ist. Pakete, die auf einem Allzweckkanal übertragen werden und durch das Feld AuxPtr von einem Paket auf den Primärkanälen referenziert werden, werden als untergeordnete Pakete bezeichnet, während das referenzierende Paket als übergeordnetes Paket bezeichnet wird.

Die Auswahl der Kanalindexwerte in AuxPtr ist implementierungsspezifisch, wobei die Bluetooth nur empfiehlt, dass "eine ausreichende Kanaldiversität verwendet wird, um Kollisionen zu vermeiden".

7.8.2.3.2 Paketverkettung

Für Anwendungsfälle, in denen eine Anwendung noch mehr Daten (bis zu 1.650 Byte) übertragen muss, kann der Controller die Daten fragmentieren und Pakete aneinanderreihen, wobei jedes Paket eine Teilmenge dieser Daten enthält. Jedes verkettete Paket kann auf einem anderen Kanal übertragen werden, wobei das AuxPtr-Header-Feld auf das nächste in der Kette verweist. Abbildung 22 veranschaulicht dies.

Abbildung 22 - Erweiterte Werbung mit Paketverkettung

7.8.2.3.3 Werbesets

Die bisherige Werbung sieht keine formale Möglichkeit vor, die Nutzdaten und Parameter der Werbung zu variieren. Die erweiterte Werbung enthält einen Standardmechanismus für mehrere, unterschiedliche Sätze von Werbedaten.

Die Werbesätze haben eine ID, die angibt, zu welchem Satz ein bestimmtes Paket gehört, und jeder Satz hat seine eigenen Werbeparameter, z. B. das Werbeintervall und den zu verwendenden PDU-Typ.

Die Aufgabe, die verschiedenen Gruppen zu planen und zu übertragen, fällt dem Link Layer im Controller zu und muss nicht vom Host gesteuert werden, was weit weniger energieeffizient wäre. Der Host muss dem Controller nur anfangs die Werbesätze und ihre jeweiligen Parameter mitteilen, danach übernimmt der Link Layer die Aufgabe.

7.8.2.3.4 Regelmäßige Werbung

Die erweiterte Werbung umfasst eine Werbemethode, bei der eine deterministische Zeitplanung verwendet wird, deren Einzelheiten von Scannern entdeckt und synchronisiert werden können. Dies wird als Periodic Advertising bezeichnet. Periodische Werbung ist als eigener logischer Transport definiert und wird daher in Abschnitt 7.8.3 PADVB - LE Periodic Advertising Broadcast beschrieben.

7.8.2.3.5 Erweiterte Werbung und zugehörige PDU-Typen

Eine Reihe von PDU-Typen sind für die Verwendung mit erweiterter Werbung definiert. In Tabelle 7 sind die PDUs für die erweiterte Werbung aufgeführt.

PDU-Name	Beschreibung	Kanäle	PHY(s)	Übermittelt von
ADV_EXT_IND	Erweiterte Werbung	primär	LE 1M, LE codiert	Peripherie
ADV_DECISION_IND	Entscheidung PDU	primär	LE 1M, LE codiert	Peripherie
AUX_ADV_IND	Untergeordnete erweiterte Werbung	Allgemeiner Zweck	LE 1M, LE 2M, LE codiert	Peripherie
AUX_CHAIN_IND	Zusätzliche Werbedaten	Allgemeiner Zweck	LE 1M, LE 2M, LE codiert	Peripherie
AUX_SYNC_IND	Regelmäßige Synchronisierung der Werbung	Regelmäßig	LE 1M, LE 2M, LE codiert	Peripherie
AUX_SCAN_REQ	Anforderung eines Hilfsscans	Allgemeiner Zweck	LE 1M, LE 2M, LE codiert	Zentrale
AUX_SCAN_RSP	Hilfsscan-Antwort	Allgemeiner Zweck	LE 1M, LE 2M, LE codiert	Peripherie
AUX_CONNECT_REQ	Anforderung einer Hilfsverbindung	Allgemeiner Zweck	LE 1M, LE 2M, LE codiert	Zentrale
AUX_CONNECT_RSP	Antwort der Hilfsverbindung	Allgemeiner Zweck	LE 1M, LE 2M, LE codiert	Peripherie

Tabelle 7 - Erweiterte Werbe-PDUs

Die Nutzdaten von PDUs des Typs ADV_EXT_IND, AUX_ADV_IND, AUX_SCAN_RSP, AUX_SYNC_IND, AUX_CHAIN_IND und AUX_CONNECT_RSP sind durch das gleiche Format definiert, das als Common Extended Advertising Payload Format bekannt ist. Dazu gehören Felder wie das AuxPtr-Feld und AdvMode. AdvMode verwendet zwei Bits, um die verbindungsfähigen und abfragbaren Eigenschaften des Werbemodus anzugeben, anstatt verschiedene PDU-Typen.

Abschnitt 4.4 des Kapitels über die Spezifikation der Verbindungsschicht in der Bluetooth enthält vollständige Angaben zu allen Werbe-PDU-Typen.

7.8.2.3.6 Zeitplanung

Erweiterte Werbung findet in erweiterten Werbeereignissen statt. Ein Extended-Advertising-Ereignis beginnt zur gleichen Zeit wie ein Advertising-Ereignis und umfasst das übergeordnete Paket mit einem AuxPtr-Feld und die damit verbundenen untergeordneten Pakete.

7.8.2.3.7 Entscheidungsbasierte Werbefilterung

Ablenkungen

Wenn eine ADV_EXT_IND-PDU empfangen wird, folgt der Scanner immer dem AuxPtr-Feld und sucht nach der zugehörigen untergeordneten PDU (z. B. einer AUX_ADV_IND-PDU). Für einige Anwendungen kann dies ein ineffizientes Verhalten sein, das die Empfängerleistung auf den primären Kanälen negativ beeinflusst.

Stellen Sie sich das folgende Szenario vor:

• Scanner empfängt eine ADV_EXT_PDU
• Der Scanner verwendet die Informationen im Feld AuxPtr, um auf den angegebenen Sekundärkanal umzuschalten.
• Der Scanner empfängt wie erwartet eine AUX_ADV_IND PDU.
• Die Anwendungsschicht empfängt die erweiterte Werbe-PDU, prüft aber das AdvData-Nutzdatenfeld, um festzustellen, dass die Anwendungsdaten für die Anwendung zu diesem Zeitpunkt nicht relevant oder interessant sind.

Was hier passiert ist, nennt man Ablenkung. Es gab keine Möglichkeit, im Voraus zu wissen, ob die Nutzdaten in der erweiterten Werbe-PDU für die Anwendung nützlich sein würden, ohne sie zu scannen und dann zur Auswertung an die Anwendung weiterzugeben. Und während das Scannen auf dem von AuxPtr angegebenen sekundären Kanal stattfand, wurden die primären Kanäle nicht gescannt, so dass es möglich ist, dass andere ADV_EXT_IND-PDUs übersehen wurden. Wie man sieht, können unter diesen Umständen und für einige Anwendungen Ablenkungen problematisch sein.

DBAF löst das Problem der Ablenkung.

DBAF und die Werbevorrichtung

Wenn DBAF verwendet wird, sendet das werbende Gerät ADV_DECISION_IND PDUs auf den Primärkanälen anstelle von ADV_EXT_IND PDUs.

Abbildung 23 - ADV_DECISION_IND

Das Feld Entscheidungsdaten wird in Abbildung 24 erweitert.

Abbildung 24 - Das Feld ADV_DECISION_IND Entscheidungsdaten

Das Feld Resolvable Tag enthält einen von der Anwendung zugewiesenen Hash-Wert, der als Kennzeichnung für PDUs verwendet wird, die zu dieser Anwendung gehören. Auf diese Weise kann der Scanner auf einfache Weise feststellen, in welchen Fällen er AuxPtr folgen und nach zugehörigen Hilfs-PDUs suchen sollte. Zukünftige Profile werden voraussichtlich Wege definieren, wie Schlüsselwerte, die zur Erstellung von Hash-Werten für auflösbare Markierungen verwendet werden, zwischen Geräten ausgetauscht werden können.

Andere Daten, auf deren Grundlage Entscheidungen getroffen werden sollen, können in das Feld Beliebige Daten aufgenommen werden.

DBAF und das Abtastgerät

Die Anwendung auf dem Abtastgerät kann logische Tests formulieren, die der controller anhand von ADV_DECISION_PDUs auswerten muss, um zu entscheiden, ob auf dem Sekundärkanal nach zugehörigen Hilfs-PDUs gesucht werden soll oder nicht. Die Tests können sich auf die Daten im Feld Entscheidungsdaten der ADV_DECISION_IND-PDUs oder auf andere Felder wie das Feld Werbemodus (AdvMode) beziehen. Darüber hinaus kann der Empfangssignalstärke-Indikator (RSSI) in die Entscheidungstests einbezogen werden.

Die Testanforderungen werden über HCI-Befehle, die die Anwendung aufruft, an die controller übermittelt. Tests können gruppiert werden, und Gruppen können Elemente relativ komplizierter zusammengesetzter Bedingungen bilden, die logische UND- oder logische ODER-Operationen beinhalten. Zum Beispiel:

• (Gruppe 1 Test 1) UND (Gruppe 1 Test 2) UND (Gruppe 1 Test 3)
• (Gruppe 1) ODER (Gruppe 2) ODER (Gruppe 3) ODER (Gruppe 4)

Die Anwendung informiert den controller über den Modus der Entscheidungs-Scan-Filterrichtlinie, den er verwenden muss. Die Optionen sind:

1. Modus "Keine Entscheidungen". In diesem Modus werden die Entscheidungs-PDUs ignoriert.
2. Modus Alle-PDUs. Alle Arten von Werbe-PDUs werden ausgewählt. Entscheidungs-PDUs werden den vom host festgelegten Prüfungen unterzogen. Andere Werbe-PDUs unterliegen der grundlegenden Filterrichtlinie.
3. Nur-Entscheidungs-Modus. Es werden nur Entscheidungs-PDUs ausgewählt. Diese werden den vom host festgelegten Prüfungen unterzogen. Diejenigen, die bestanden werden, werden dem host in HCI-Werbeberichten mitgeteilt. Diejenigen, die nicht bestanden werden, werden verworfen.

7.8.2.4 Vergleich zwischen herkömmlicher Werbung und erweiterter Werbung

Tabelle 8 enthält einen zusammenfassenden Vergleich von herkömmlicher Werbung und erweiterter Werbung.

	Legacy-Werbung	Erweiterte Werbung
Maximale Größe der host	31 Bytes	1.650 Bytes	Extended Advertising unterstützt die Fragmentierung, wodurch die maximale Größe der host um das 50-fache erhöht werden kann.
Max. host pro Paket	31 Bytes	254 Bytes	Extended Advertising PDUs verwenden das Common Extended Advertising Payload Format, das ein 8x größeres Werbedatenfeld unterstützt.
TX-Kanäle	37,38,39	0-39	Die erweiterte Werbung verwendet die 37 Allzweckkanäle als sekundäre Werbekanäle. Der PDU-Typ ADV_EXT_IND darf jedoch nur auf den primären Werbekanälen (37, 38, 39) übertragen werden.
PHY-Unterstützung	LE 1M	LE 1MLE 2M (ohne ADV_EXT_IND PDUs)LE kodiert	Alle erweiterten Werbe-PDUs mit Ausnahme von ADV_EXT_IND können mit jedem der drei LE-PHYs übertragen werden, mit Ausnahme der ADV_EXT_IND-PDU, die mit LE 1M oder LE Coded PHYs übertragen werden kann.
Max. aktive Werbekonfigurationen	1	16	Die erweiterte Werbung umfasst Werbesätze, die es den Werbegeräten ermöglichen, bis zu 16 verschiedene Werbekonfigurationen gleichzeitig zu unterstützen und die Werbung für jeden Werbesatz entsprechend den in den Sätzen festgelegten Zeitintervallen zu verschachteln.
Kommunikationstypen	Asynchron	AsynchronSynchron	Erweiterte Werbung beinhaltet periodische Werbung, die eine zeitsynchrone Kommunikation von Werbedaten zwischen Sendern und Empfängern ermöglicht.

Tabelle 8 - Vergleich zwischen herkömmlicher und erweiterter Werbung

7.8.3 PADVB - LE Periodic Advertising Broadcast

7.8.3.1 Grundlagen

Werbung, wie sie vom logischen Transport ADVB (siehe 7.8.2 ADVB - LE Advertising Broadcast) durchgeführt wird, beinhaltet einen gewissen Grad an Zufälligkeit bei der zeitlichen Planung der Übertragung von Werbepaketen. Zufällige Verzögerungen zwischen 0 und 10 ms werden absichtlich in die Planung von Werbeereignissen eingefügt, um anhaltende Paketkollisionen zu vermeiden. Bei der Durchführung von Legacy-Werbung ist dies die einzige Möglichkeit, wie Werbung funktionieren kann.

Periodische Werbung beinhaltet die Übertragung von Paketen nach einem deterministischen Zeitplan und bietet einen Mechanismus, der es anderen Geräten ermöglicht, ihr Scannen nach Paketen mit dem Zeitplan des werbenden Geräts zu synchronisieren. Periodische Werbung ist immer nicht durchsuchbar und nicht verbindbar.

Periodische Werbung kann für Beobachtergeräte von Vorteil sein, da sie eine energieeffizientere Art der Abtastung bietet und eine Schlüsselkomponente in LE-Audio-Übertragungslösungen darstellt.

Die Werbung erfolgt in festen Intervallen, die als periodisches Werbeintervall bezeichnet werden, und die Nutzdaten der Werbung können sich ändern. Eine Reihe von AUX_SYNC_IND- und zugehörigen AUX_CHAIN_IND-PDUs wird als periodischer Werbezug bezeichnet.

Bei jedem periodischen Werbeereignis wird eine einzelne AUX_SYNC_IND-PDU übertragen, gefolgt von null oder mehr AUX_CHAIN_IND-PDUs, je nachdem, ob die host Nutzlast eine Fragmentierung erfordert oder nicht.

Die AUX_ADV_IND PDU enthält ein Feld namens SyncInfo, das Teil des Common Extended Advertising Payload Formats ist und Kanal- und Zeitversatzinformationen enthält.

7.8.3.2 Kanalnutzung

Die periodische Werbung verwendet die 37 Allzweck-Werbekanäle. Ein Kanal wird zu Beginn jedes periodischen Werbeereignisses unter Verwendung des Kanalauswahlalgorithmus Nr. 2 mit einem Ereigniszählerfeld namens paEventCounter als Eingabe ausgewählt. Dieser Zähler wird bei jedem periodischen Werbeereignis inkrementiert. Bei allen AUX_CHAIN_IND-PDUs, die mit einer AUX_SYNC_IND-PDU verknüpft sind, wird der Kanal mithilfe eines implementierungsspezifischen Algorithmus ausgewählt und im Feld AuxPtr angegeben. Siehe Abbildung 25.

7.8.3.3 Zeitplanung

Das periodische Werbeintervall bestimmt, wie oft periodische Werbung für einen bestimmten Werbesatz erfolgen kann. Es beginnt mit der Übertragung einer AUX_SYNC_IND PDU und wird mit einer Reihe von null oder mehr AUX_CHAIN_IND PDUs fortgesetzt, wie in Abbildung 25 dargestellt.

Abbildung 25 - Regelmäßige Werbeveranstaltungen

Beachten Sie, dass Abbildung 25 vereinfacht wurde, indem potenziell mehrere ADV_EXT_IND-PDUs auf verschiedenen primären Werbekanälen durch ein einziges Kästchen dargestellt wurden.

7.8.3.4 Einrichtung der Synchronisation

Ein Abtastgerät kann sich auf zwei Arten mit einem periodischen Werbezug synchronisieren. Es kann entweder nach AUX_ADV_IND-PDUs scannen und den Inhalt des SyncInfo-Feldes verwenden, um die zu verwendenden periodischen Werbungsintervalle, den Zeitversatz und die Kanalinformationen festzulegen, oder es kann diese Informationen über eine LE-ACL-Verbindung von einem anderen Gerät erhalten, das diese Informationen selbst aus AUX_ADV_IND-PDUs ermittelt hat. Diese Methode wird als "Periodic Advertising Sync Transfer"-Verfahren bezeichnet.

7.8.4 PAwR - LE Periodische Werbung mit Antworten

7.8.4.1 Grundlagen

PAwR ist der periodischen Werbung (PADVB) in mehrfacher Hinsicht ähnlich:

• Mit PADVB können Anwendungsdaten von einem Gerät (dem Broadcaster) an ein oder mehrere Empfangsgeräte (die Observer) übertragen werden, wobei eine One-to-many-Kommunikationstopologie entsteht. Das Gleiche gilt für PAwR.
• PAwR und PADVB verwenden beide ein verbindungsloses Kommunikationsverfahren.
• Die Übertragung von Werbepaketen erfolgt in beiden Fällen periodisch mit einem festen Intervall und ohne zufällige Störung des Zeitplans.
• Beobachter können den vom Broadcaster verwendeten periodischen Sendeplan anhand von AUX_ADV_IND-PDUs oder mit Hilfe des PAST-Verfahrens (Periodic Advertising Sync Transfer) ermitteln.

PAwR unterscheidet sich von PADVB wie folgt:

• PADVB unterstützt nur die unidirektionale Kommunikation von Daten von einem Broadcaster zu Observern. PAwR-Beobachter können Antwortpakete zurück an den Broadcaster senden. PAwR bietet einen bidirektionalen, verbindungslosen Kommunikationsmechanismus.
• Synchronisationsinformationen für periodische Werbung ohne Antworten (PADVB) sind im SyncInfo-Feld von AUX_ADV_IND PDUs enthalten. Synchronisationsinformationen für periodische Werbung mit Antworten (PAwR) sind im SyncInfo-Feld und im ACAD-Feld der AUX_ADV_IND-PDUs enthalten.
• Der PADVB Broadcaster plant Übertragungen innerhalb von Werbeveranstaltungen. Der PAwR Broadcaster plant Übertragungen in einer Reihe von Ereignissen und Unterereignissen, und es wird erwartet, dass die Beobachter so synchronisiert sind, dass sie nur während eines bestimmten Unterereignisses oder bestimmter Unterereignisse zuhören.
• Der PAwR Broadcaster kann einen Sendezeitschlitz nutzen, um eine Verbindungsanforderung (AUX_CONNECT_REQ PDU) an ein bestimmtes Gerät zu senden und eine LE-ACL-Verbindung mit ihm aufzubauen. PADVB hat diese Fähigkeit nicht.
• Bei der periodischen Werbung ohne Antwort (PADVB) ändern sich die Anwendungsdaten in der Regel nur von Zeit zu Zeit. Bei PAwR wird davon ausgegangen, dass sich die Anwendungsdaten häufig ändern.
• Mit PADVB werden dieselben Anwendungsdaten an alle Beobachtergeräte geliefert, die mit demselben Werbeset synchronisiert sind. Mit PAwR können unterschiedliche Daten an jedes Beobachtergerät oder jede Gruppe von Beobachtergeräten geliefert werden.

Die Unterstützung des Verfahrens Periodic Advertising Sync Transfer (PAST) ist bei PADVB optional, bei PAwR jedoch obligatorisch.

7.8.4.2 Kanalnutzung

Die Kanalauswahl wird mit dem Kanalauswahlalgorithmus Nr. 2 durchgeführt und erfolgt bei jedem periodischen Werbe-Sub-Ereignis (siehe 7.8.4.3 Scheduling). Antworten auf PDUs, die in einem Subevent übertragen werden, verwenden denselben Kanal. Dazu gehören AUX_SYNC_SUBEVENT_RSP PDUs, die als Antwort auf eine AUX_SYNC_SUBEVENT_IND PDU gesendet werden, und AUX_CONNECT_RSP PDUs, die als Antwort auf AUX_CONNECT_REQ PDUs gesendet werden.

7.8.4.3 Zeitplanung

Wie bei anderen Werbemodi findet die Aktivität in Ereignissen statt, die im Fall von PAwR als "Periodic advertising with responses events" (PAwR-Ereignisse) bezeichnet werden. Diese Ereignisse treten in festen Intervallen auf, ohne zufällige Störungen bei der Terminierung. Ein Ereignis beginnt jedes periodische Werbeintervall ms.

Jedes PAwR-Ereignis besteht aus mehreren Unterereignissen, und während der Unterereignisse werden die Werbepakete übertragen. Der Host konfiguriert die Anzahl der Unterereignisse pro Ereignis bis zu einem Maximum von 128. Ein Sub-Ereignis beginnt jedes periodische Werbe-Sub-Ereignis-Intervall ms. Der Host konfiguriert die Anzahl der Sub-Ereignisse pro Ereignis und das Intervall der periodischen Werbe-Sub-Ereignisse mit einem Host Controller Interface (HCI)-Befehl namens HCI_LE_Set_Periodic_Advertising_Parameters V2 (oder höher).

Siehe Abbildung 26 - PAwR-Ereignisse und Unterereignisse.

Abbildung 26 - PAwR-Ereignisse und Unterereignisse[9]

In jedem Unterereignis sendet der Broadcaster ein Paket, das normalerweise eine AUX_SYNC_SUBEVENT_IND-PDU enthält, aber auch eine AUX_CONNECT_REQ-PDU enthalten kann. Nach einer Verzögerung, die als Periodic Advertising Response Slot Delay bezeichnet wird, wird eine Reihe von Zeitschlitzen innerhalb desselben Unterereignisses für den Empfang von Antworten von Beobachtergeräten reserviert. Antworten auf AUX_SYNC_SUBEVENT_IND PDUs werden in AUX_SYNC_SUBEVENT_RSP PDUs gesendet. Der Host konfiguriert die Anzahl der erforderlichen Antwortschlitze mit dem HCI-Befehl HCI_LE_Set_Periodic_Advertising_Parameters. Abbildung 27 veranschaulicht die Struktur eines PAwR-Subereignisses.

Abbildung 27 - Ein PAwR-Unterereignis mit Antwortschlitzen

7.8.4.4 Einrichtung der Synchronisation

7.8.4.4.1 Allgemeines

Der Prozess der Synchronisierung versorgt das beobachtende Gerät mit den Informationen, die es benötigt, um effizient nach relevanten Paketen zu suchen und diese zu empfangen, die vom werbenden Gerät gesendet werden. Im Falle von PAwR sind dies drei Aspekte:

1. Der Beobachter muss wissen, wie oft periodische Werbung mit Antwortereignissenstattfinden wird und wann das nächste derartige Ereignis eintreten wird. Diese Informationen werden in einem Parameter mit der Bezeichnung " periodic advertising interval" und einem berechneten Wert mit der Bezeichnung " syncPacketWindowOffset" bereitgestellt.
2. Der Beobachter benötigt Informationen über Unterereignisse, u. a. wie oft sie auftreten und wie viele Unterereignisse jede periodische Werbung mit Antwortereignissen enthält. Er muss auch bestimmte Details über die Zeitschlitze innerhalb jedes Unterereignisses kennen, die für die Übertragung von Antworten reserviert sind. Diese Informationen sind in den Parametern Subevent_Interval, Num_Subevents, Response_Slot_Delay, Response_Slot_Spacing und Num_Response_Slots enthalten.
3. Schließlich muss ein Beobachter wissen, nach welcher Unterereignisnummer er suchen soll, welchen bestimmten Antwortslot er verwenden soll und welche Zugangsadresse in den übertragenen Antwortpaketen verwendet werden soll.

Nachdem der Beobachter die in (1) beschriebene Information über den Zeitpunkt des Ereignisses und die Informationen über die Unterereignisse in (2) erhalten hat, verfügt er über eine vollständige Beschreibung der zeitlichen Parameter und der Struktur der Ereignisse und Unterereignisse des PAwR-Werbezugs. Aber erst wenn er über die Informationen in (3) verfügt, kann er sein Scanning so planen, dass er nur die Pakete empfängt, von denen er erwartet, dass sie relevante Daten enthalten, und er kann die Übertragung von Antwortpaketen planen.

(1) und (2) werden durch den logischen PAwR-Transport behandelt, wie in der Bluetooth-Kernspezifikation definiert. Es gibt zwei Verfahren, die verwendet werden können, um diese Ebene der Synchronisationsinformationen zu erhalten. Die beiden Verfahren werden in diesem Dokument in den Abschnitten 7.8.4.4.2 Scanning for Periodic Advertising Synchronization Information und 7.8.4.4.3 Periodic Advertising Sync Transfer (PAST) behandelt.

(3) muss von der Anwendungsschicht angesprochen werden und kann in einer anwendbaren Bluetooth wie demESLElectronic Shelf Label) definiert werden.

7.8.4.4.2 Scannen nach Informationen zur periodischen Werbesynchronisation

PAwR und PADVB verwenden jeweils ein ähnliches Verfahren, um durch Scannen periodische Werbesynchronisationsinformationen zu erhalten.

Sowohl bei PAwR als auch bei PADVB sucht ein Beobachter nach AUX_ADV_IND-Paketen, die auf den sekundären Werbekanälen übertragen werden. AUX_ADV_IND enthält das Feld SyncInfo, das den Wert des periodischen Werbeintervalls und einige Datenelemente enthält, aus denen eine Variable namens syncPacketWindowOffset berechnet werden kann. Nachdem der Beobachter diese beiden Werte erfasst hat, kann er berechnen, wann periodische Werbung mit Antwortereignissengemäß (1) in 7.8.4.4.1 Allgemeines auftreten wird.

PAwR benötigt auch Informationen über Sub-Events und Antwort-Slots, gemäß (2) in 7.8.4.4.1 Allgemein, bevor es die Synchronisationsprozedur abschließen kann. Diese Informationen befinden sich in derselben AUX_ADV_IND-PDU, aus der das periodische Werbeintervall entnommen wurde, jedoch in einem Werbedatentyp (AD-Typ) namens Periodic Advertising Response Timing Information, der wiederum im Feld Additional Controller Advertising Information (ACAD) der PDU zu finden ist.

7.8.4.4.3 Periodische Werbe-Synchronisationsübertragung (PAST)

Bei Verwendung des PAST-Verfahrens kann es vorkommen, dass das Gerät, das die Synchronisationsparameter über die Verbindung weitergibt, diese zunächst durch Scannen im Namen des anderen Geräts erhält. Im Falle von PAwR ist die Unterstützung von PAST jedoch obligatorisch, so dass der PAwR Broadcaster die erforderlichen Synchronisationsdaten über eine LE ACL-Verbindung an den Observer weitergeben kann. Bei diesem Ansatz ist für beide Geräte kein Scannen nach AUX_ADV_IND PDUs erforderlich.

7.8.4.4.4 Synchronisierung von Unterereignissen und Zuweisung von Antwortschlitzen

Bei der Synchronisierung von Teilereignissen geht es darum, einem Observer-Gerät mitzuteilen, nach welchem Teilereignis es suchen soll. Ein oder mehrere Observer-Geräte können mit demselben Unterereignis synchronisiert werden. Ein einzelner Beobachter kann für den Empfang während eines oder mehrerer Unterereignisse synchronisiert werden.

Damit ein Beobachter eine Antwort-PDU senden kann, muss er über eine Grundlage verfügen, um zu bestimmen, welcher Slot für die Antwort auf ein Unterereignis zu verwenden ist.

Für beide Aspekte ist die Anwendungsschicht zuständig.

7.8.5 LE BIS und LE CIS - Isochrone Kommunikation

7.8.5.1 Grundlagen

Isochrone Kommunikation ist eine Möglichkeit, Bluetooth LE zur Übertragung zeitlich begrenzter Daten zwischen Geräten zu nutzen. Sie bietet einen Mechanismus, der es mehreren Senkengeräten, die Daten von derselben Quelle zu unterschiedlichen Zeiten empfangen, ermöglicht, ihre Verarbeitung dieser Daten zu synchronisieren. LE Audio verwendet isochrone Kommunikation.

Bei der isochronen Kommunikation haben die Daten eine zeitlich begrenzte Gültigkeitsdauer, nach deren Ablauf sie als verfallen gelten. Abgelaufene Daten, die noch nicht übertragen worden sind, werden verworfen. Dies bedeutet, dass die Geräte immer nur Daten empfangen, die in Bezug auf das Alter und die akzeptable Latenzzeit, die ein Profil ausdrücken kann, gültig sind.

Daten werden in isochronen Strömen übertragen, und die Ströme gehören zu isochronen Gruppen. Die Geräte warten eine gewisse Zeit, damit alle Streams, die derselben Gruppe angehören, die Möglichkeit haben, zusammengehörige Pakete zu übermitteln, bevor sie die empfangenen Pakete gleichzeitig verarbeiten. Beispielsweise könnte Stereomusik über zwei Streams übertragen werden, einen für den linken Stereokanal und einen für den rechten Stereokanal. Die beiden Ströme wären Mitglieder derselben Gruppe, und als solche findet das Rendering der von den beiden Strömen empfangenen Pakete zur gleichen Zeit statt, so dass der Benutzer die Stereomusik wie vorgesehen hören kann.

Es werden zwei logische Transporte definiert, die den LE Isochronous Physical Channel verwenden. Connected Isochronous Streams (LE CIS oder einfach CIS) verwenden eine verbindungsorientierte Kommunikation und unterstützen die bidirektionale Übertragung von Daten. Broadcast Isochronous Streams (LE BIS oder einfach BIS) verwenden eine verbindungslose Broadcast-Kommunikation und ermöglichen die unidirektionale Übertragung von Daten.

7.8.5.2 Verbundene isochrone Ströme

7.8.5.2.1 CIS-Übersicht

Ein einzelner CIS-Datenstrom ermöglicht eine isochrone Punkt-zu-Punkt-Kommunikation zwischen zwei verbundenen Geräten und überträgt Daten in einer PDU der Verbindungsschicht, die als CIS-PDU bezeichnet wird. Der logische LE-CIS (CIS)-Transport ist in der gesamten Datentransportarchitektur in Abbildung 28 dargestellt.

Abbildung 28 - LE-CIS in der Bluetooth

Zwei logische Verbindungen, LE-S und LE-F, sind definiert und unterstützen sowohl ungerahmte (LE-S) als auch gerahmte (LE-F) Daten. Die Verwendung von LE-S bzw. LE-F ist ein Anliegen der isochronen Anpassungsschicht.

Ein CIS-Stream verwendet den isochronen physischen LE-Kanal und kann jeden der Bluetooth LE PHYs verwenden.

Die bidirektionale Kommunikation wird durch ein CIS unterstützt, und es wird ein Quittierungsprotokoll verwendet.

CIS-Streams sind Mitglieder von Gruppen, die Connected Isochronous Groups (CIGs) genannt werden und jeweils 1 oder mehrere CIS enthalten können. Siehe Abbildung 29.

Es kann maximal 31 CIS pro CIG geben. Mehrere CIGs können von der Zentrale erstellt werden. Die verfügbare Sendezeit und andere Implementierungsdetails reduzieren diese Grenzen jedoch häufig auf niedrigere Werte.

Abbildung 29 - Ein CIG mit zwei CIS

7.8.5.2.2 Kanalnutzung

Verbundene isochrone Streams verwenden adaptive Frequenzsprünge mit Kanalauswahlalgorithmus Nr. 2.

7.8.5.2.3 Zeitplanung

Die Terminplanung einer CIG und der ihr angeschlossenen CIS wird durch ein System von CIG-Ereignissen, CIS-Ereignissen und Unterereignissen geregelt.

Ein CIG-Ereignis signalisiert den Beginn der Planung von Aktivitäten in den CIS, die zu der CIG gehören, und dies geschieht am Ankerpunkt des ersten CIS in der Gruppe. CIG-Ereignisse treten in einem Intervall auf, das in einem Parameter namens ISO_Intervall angegeben ist.

Jedes CIS-Ereignis ist in ein oder mehrere Unterereignisse unterteilt. Die Anzahl der verwendeten Unterereignisse wird in einem Stream-Parameter namens NSE angegeben. In einem verbundenen isochronen Datenstrom sendet die Zentrale während eines Unterereignisses einmal (T), und das Peripheriegerät antwortet (R), wie in Abbildung 30 dargestellt. Die Unterereignisse sind durch eine Dauer voneinander getrennt, deren Wert in einem CIS-Parameter namens Sub_Interval angegeben wird. Sub_Interval ist immer auf Null gesetzt, wenn es nur ein Unterereignis pro CIS-Ereignis gibt, andernfalls beträgt er mindestens 400 Mikrosekunden, ist aber kleiner als das ISO-Intervall.

Beachten Sie, dass der Kanal bei jedem Unterereignis gewechselt wird.

Jedes CIS kann während eines CIG-Ereignisses nacheinander abgearbeitet werden, oder die Unterereignisse verschiedener CIS können ineinander verschachtelt werden. Ein Beispiel für ein CIG, das drei CIS enthält, von denen jedes nacheinander abgearbeitet wird, ist in Abbildung 30 dargestellt.

Abbildung 30 - CIS-Ereignisse und Unterereignisse

Jedes CIS hat neben der Anzahl der Unterereignisse (NSE) noch eine Reihe anderer wichtiger Parameter, darunter Flush Timeout (FT) und Burst Number (BN).

Jede Nutzlast (z. B. ein Stück Audiodaten, das von einem Audiocodec wie LC3[10] ausgegeben wird) erhält eine maximale Anzahl von CIS-Ereignissen, in denen sie erfolgreich übertragen werden kann (was durch eine Bestätigung angezeigt wird), was im FT-Parameter angegeben ist. In jedem der Unterereignisse eines solchen CIS-Ereignisses kann ein Versuch unternommen werden, und wenn dies innerhalb von FT-Ereignissen nicht gelingt, wird das Paket verworfen. Es kommt vor, dass mehrere PDUs, die unterschiedliche Daten (d. h. Nutzdaten) enthalten, gleichzeitig verfügbar sind, und ein CIS erlaubt die Übertragung mehrerer unterschiedlicher PDUs während desselben CIS-Ereignisses. Die Anzahl der verschiedenen PDUs, die bei jedem CIS-Ereignis bedient werden können, wird im Parameter Burst Number (BN) angegeben.

7.8.5.2.4 Synchronisierung der Verarbeitung

Ein CIG hat einen zugehörigen Timing-Parameter namens CIG_Sync_Delay. CISes in derselben CIG haben jeweils einen Timing-Parameter namens CIS_Sync_Delay, der bei der Synchronisierung der isochronen Datenverarbeitung (in der Regel Audio-Rendering) durch die Empfänger über alle Streams in der Gruppe verwendet wird. Die Empfänger warten die in diesem Parameter angegebene Zeit ab, bevor sie die empfangenen Daten wiedergeben.

Abbildung 31 - Synchronisiertes Rendering von CIS-Daten in einem CIG

Wie in Abbildung 31 dargestellt, hat jeder Stream einen anderen CIS_Sync_Delay-Wert. Für den ersten CIS-Datenstrom in der CIG wird er auf den Gruppenebenenparameter CIG_Sync_Delay eingestellt. CIS_Sync_Delay wird für jeden der anderen Streams in der Gruppe auf einen progressiv niedrigeren Wert eingestellt. Das bedeutet, dass ein Gerät, das von einem Stream empfängt, der früher in der Gruppe bedient wurde, länger warten muss, bevor es den Inhalt des empfangenen Pakets wiedergibt, als Geräte, die Pakete empfangen, die später in der CIS-Ereignisverarbeitung der Gruppe übertragen wurden. Spezifikationen auf höherer Ebene, wie z. B. Profile, können die Verwendung einer weiteren Darstellungsverzögerung vorschreiben, die bei der Berechnung des Zeitpunkts, zu dem die Daten wiedergegeben werden sollten, zu berücksichtigen ist, damit lokale Verarbeitungsverzögerungen berücksichtigt werden können. Das Ergebnis dieses gestaffelten Verzögerungssystems ist, dass jedes Senkengerät die empfangenen Daten zur gleichen Zeit verarbeitet.

7.8.5.2.5 CIS-Stream-Erstellung

Für den Aufbau eines isochronen Datenstroms muss zunächst eine ACL-Verbindung eingerichtet werden. Diese Verbindung dient zwei Zwecken. Erstens ermöglicht sie den Austausch von Link Layer Control PDUs. Zweitens bietet sie einen zeitlichen Bezugspunkt, anhand dessen CIS-Ereignisse geplant werden können, sobald der Datenstrom eingerichtet worden ist.

Das zentrale Gerät leitet immer das Verfahren zur Erstellung eines CIS ein. Dazu sendet es eine Link Layer Control PDU, die LL_CIS_REQ PDU. Wenn alles in Ordnung ist, antwortet das Peripheriegerät mit einer LL_CIS_RSP-PDU, und der Datenstrom gilt als eingerichtet, wenn die Zentrale anschließend eine LL_CIS_IND-PDU sendet. Diese PDU enthält wichtige Parameter, die das Timing von CIS-Ereignissen und die Verzögerung vor dem Rendering bestimmen. Insbesondere gibt CIS_Offset einen Versatz in Mikrosekunden zwischen dem ACL-Ankerpunkt (dem Zeitpunkt, zu dem das erste Paket in einem Verbindungsereignis gesendet wird) und dem ersten CIS-Ereignis für den Stream an. CIG_Sync_Delay enthält den Gesamtwert für die CIG-Synchronisationsverzögerung in Mikrosekunden und CIS_Sync_Delay enthält den Wert für die Synchronisationsverzögerung, der von diesem Stream verwendet werden soll.

Nach der Erstellung des Datenstroms läuft dieser unabhängig von und neben der ACL-Verbindung, mit der er erstellt wurde. Wenn jedoch die ACL-Verbindung geschlossen wird, muss auch das zugehörige CIS beendet werden.

7.8.5.2.6 CIS-Verschlüsselung

Eine von einem CIS verwendete Verbindung kann verschlüsselt werden, wenn die beiden Peer-Geräte gekoppelt wurden.

7.8.5.3 Isochrone Sendeströme

7.8.5.3.1 BIS Überblick

Ein BIS-Stream ermöglicht die isochrone Kommunikation zwischen einem Sender und vielen Empfängergeräten. Die Daten werden in PDUs der Verbindungsschicht, den so genannten BIS Data PDUs, übertragen. Steuerinformationen werden in BIS-Steuer-PDUs übertragen.

Der logische LE-BIS (BIS)-Transport ist in der Gesamtarchitektur des Datentransports in Abbildung 32 dargestellt.

Abbildung 32 - LE-BIS in der Bluetooth

Die Datenübertragung über ein BIS kann gerahmt oder ungerahmt erfolgen, wobei die logischen Verbindungstypen LE-S und LE-F entsprechend definiert sind. Die logische Verbindung LEB-C überträgt Steuerinformationen.

Ein BIS-Stream verwendet den isochronen physikalischen LE-Kanal und kann jeden der Bluetooth LE PHYs verwenden.

BIS-Streams sind Mitglieder von Gruppen, die Broadcast Isochronous Groups (BIG) genannt werden und von denen jede 1 oder mehrere BIS enthalten kann. Siehe Abbildung 33.

Abbildung 33 - Ein BIG mit zwei BIS

Es können maximal 31 BIS pro BIG vorhanden sein. Das zentrale Gerät kann mehrere BIGs erstellen. Die verfügbare Sendezeit und andere Implementierungsdetails reduzieren diese Grenzen jedoch häufig auf niedrigere Werte.

Unidirektionale Kommunikation wird nur von einem BIS unterstützt.

Im Gegensatz zu einem CIS enthält ein BIS kein Bestätigungsprotokoll. Dies macht den BIS-Transport von Natur aus unzuverlässig. Um dem entgegenzuwirken, wird ein System zur bedingungslosen Neuübertragung von Paketen verwendet. Da die Kommunikation unidirektional ist, ist es bei einem BIS nicht erforderlich, Zeitschlitze für Antworten von Peripheriegeräten zu reservieren (wie dies bei CIS der Fall ist). Daher können während einer bestimmten Sendezeit doppelt so viele Unterereignisse für Übertragungen eingeplant werden, so dass es mehr Möglichkeiten für diese die Zuverlässigkeit erhöhenden Neuübertragungen gibt. Da Neuübertragungen in verschiedenen Unterereignissen gesendet werden, werden sie außerdem auf verschiedenen Kanälen übertragen. Die ausgewählten Kanäle müssen mindestens 6 MHz von der letzten Übertragung entfernt sein, was dazu beiträgt, mögliche Paketverluste aufgrund von Störungen auf einem bestimmten Kanal zu verringern.

7.8.5.3.2 Kanalnutzung

Isochrone Broadcast-Streams verwenden adaptive Frequenzsprünge mit Kanalauswahlalgorithmus Nr. 2.

7.8.5.3.3 Zeitplanung

Die Zeitplanung eines BIG und seiner BIS-Mitglieder wird durch ein System von BIG-Ereignissen, BIS-Ereignissen und Unterereignissen geregelt. Darüber hinaus ist ein spezielles Steuer-Sub-Ereignis für die Übertragung von Steuer-PDUs für das gesamte BIG definiert.

Ein BIG-Ereignis signalisiert den Beginn der Planung von Aktivitäten in den BIS, die zum BIG gehören. BIS-Ereignisse beginnen in Intervallen, die ein Vielfaches des Wertes sind, der in einem BIG-Parameter namens BIS_Spacing vom Beginn des BIG (bekannt als BIG-Ankerpunkt) angegeben ist.

Jedes BIS-Ereignis ist in ein oder mehrere Unterereignisse unterteilt. Die Anzahl der verwendeten Unterereignisse wird in einem Stream-Parameter namens NSE angegeben. Während eines Unterereignisses sendet der Sender ein einzelnes Paket. Die Kommunikation ist unidirektional und es ist nicht erforderlich, Pakete zu empfangen. Die Unterereignisse sind durch eine Dauer voneinander getrennt, deren Wert in einem BIG-Parameter namens Sub_Interval angegeben wird.

Für verbundene isochrone Gruppen kann die Planung von BIS-Ereignissen innerhalb eines BIG entweder sequentiell oder verschachtelt erfolgen.

Ein BIG-Ereignis kann ein Kontrollunterereignis enthalten, das immer als letztes Unterereignis im BIG geplant ist.

Beachten Sie, dass der Kanal bei jedem Unterereignis gewechselt wird.

Abbildung 28 zeigt ein Beispiel für die BIG- und BIS-Ereignisse und Unterereignisse, die in der sequenziellen Anordnung geplant sind. Beachten Sie, dass am Ende des BIG-Ereignisses Nr. 1 ein BIG-Steuersubereignis (mit Tc bezeichnet) übertragen wird.

Abbildung 34 - BIG/BIS-Ereignisplanung

7.8.5.3.4 Synchronisierung der Verarbeitung

Die synchrone Verarbeitung von Daten über isochrone Broadcast-Streams in einem BIG wird auf ähnliche Weise erreicht wie bei der isochronen Kommunikation im Netz. Die Empfänger verfügen über Informationen über das BIG und seine allgemeinen Parameter und wissen, welche(n) Stream(s) sie empfangen möchten. Die Timing-Parameter eines BIG gelten einheitlich für alle Streams. Anhand des Gesamtwerts BIG_Sync_Delay und des Parameters BIS_Spacing können die Empfänger berechnen, wie lange sie warten müssen, bevor sie die empfangenen Daten so verarbeiten können, dass sie mit den anderen Streams synchronisiert werden.

7.8.5.3.5 BIS-Stream-Erstellung

Damit ein Gerät in der Lage ist, innerhalb eines BIS übertragene Pakete zu empfangen und den Inhalt dieser Pakete gleichzeitig mit anderen Geräten, die andere Streams desselben BIS empfangen, wiederzugeben oder zu verarbeiten, muss das Gerät zunächst die BIG und die sie definierenden Parameter ermitteln, z. B. die Anzahl der darin enthaltenen Streams, die Abstände zwischen den Ereignissen der einzelnen Streams und zwischen den Unterereignissen sowie die Zeitversatzinformationen zur Berechnung der Zeitankerpunkte. Zu diesem Zweck übermitteln die Rundfunkanstalten die erforderlichen Parameter in regelmäßigen Abständen durch Werbung. Ein zusammengesetztes Feld mit der Bezeichnung BIGInfo wird in AUX_SYNC_IND PDUs innerhalb des ACAD-Feldes (Additional Controller Advertising Data) übertragen und enthält die erforderlichen Daten.

Es gibt zwei Möglichkeiten, BIGInfo zu empfangen. Im ersten Fall muss sich der Empfänger direkt mit dem periodischen Werbungszug (siehe 7.8.3.1 Grundlagen) synchronisieren, indem er das definierte Verfahren anwendet, die AUX_SYNC_IND PDU empfängt und BIGInfo aus ACAD extrahiert. Die Suche nach und die Synchronisierung mit einem periodischen Werbungszug kann jedoch eine teure Prozedur in Bezug auf den Stromverbrauch sein. Im zweiten Fall kann ein Gerät die Suche nach und die Synchronisierung mit dem periodischen Werbungszug an ein anderes Gerät delegieren, das in der Regel über mehr Stromressourcen verfügt. Nach der Erfassung von BIGInfo gibt das Gerät, an das die Abtastung delegiert wurde, diese Informationen über eine effizientere ACL-Verbindung an das Gerät weiter, das den isochronen Sendestrom empfangen möchte. Dies geschieht mit einem Verfahren namens Periodic Advertising Sync Transfer (PAST).

7.8.5.3.6 BIG-Verschlüsselung

Ein BIG kann verschlüsselt sein. Dazu müssen die Geräte, die ihre BIS empfangen, nicht mit dem sendenden Gerät gekoppelt sein. Stattdessen muss ein Broadcast-Code-Parameter, der zur Ableitung eines Verschlüsselungscodes verwendet wird, verteilt werden. Dies kann "out of band" oder nach Verfahren erfolgen, die in übergeordneten Profilen beschrieben sind.

7.8.5.4 Weiterübertragungen und Verlässlichkeit

Die Zuverlässigkeit kann durch erneute Übertragungen identischer Pakete innerhalb einer Folge von Teilereignissen in BIS- oder CIS-Streams erhöht werden. Im Fall von BIS sind Neuübertragungen bedingungslos, während sie bei CIS erfolgen, wenn das Peripheriegerät eine Übertragung nicht bestätigt hat.

Da im Fall von BIS keine Zeitschlitze für periphere Antworten reserviert werden müssen (wie bei CIS), können während einer bestimmten Sendezeit doppelt so viele Sub-Events für Übertragungen eingeplant werden, so dass es eine größere Chance für zuverlässigkeitssteigernde Neuübertragungen gibt.

Wiederholte Übertragungen werden auf verschiedenen Kanälen übertragen, da sie unterschiedliche Sub-Events belegen, und die ausgewählten Kanäle müssen mindestens 6 MHz von der letzten Übertragung entfernt sein. Dies trägt dazu bei, mögliche Paketverluste aufgrund von Störungen auf einem bestimmten Kanal zu verringern.

8. Channel Sounding

8.1 Einführung in Bluetooth Channel Sounding

Bluetooth Channel Sounding ist eine optionale Funktion eines Bluetooth LE Controllers. Wenn sie verwendet wird, erzeugt sie Daten, mit denen eine Anwendung ihre aktuelle Entfernung zu einem entfernten Gerät berechnen kann. Das entfernte Gerät verwendet ebenfalls channel sounding und nimmt an einer Reihe von Funksignalaustauschvorgängen mit dem ersten Gerät teil.

Bluetooth Channel Sounding ist genauer, zuverlässiger und wesentlich sicherer als Methoden, die die Signalstärke (Received Signal Strength Indicator oder RSSI) als Näherungswert für die Entfernung verwenden. Erste Implementierungen von Bluetooth Channel Sounding haben eine Genauigkeit von +/- 20 cm bei Entfernungen von bis zu 100 Metern erreicht. RSSI-basierte Entfernungsschätzungen sind besonders schlecht und unzuverlässig bei Entfernungen von mehr als ein paar Metern. Außerdem bietet es keine inhärente Sicherheit, so dass bei seiner Verwendung große Vorsicht geboten ist.

Es ist zu beachten, dass die Bluetooth-Kernspezifikation keinen Algorithmus für die Berechnung von Entfernungen anhand der vom Bluetooth Channel Sounding erzeugten Daten bereitstellt. Dies liegt in der Verantwortung der Anwendungsschicht (siehe Abschnitt 8.14 Anwendungen zur Entfernungsmessung).

Bluetooth Channel Sounding wurde entwickelt, um die sichere Berechnung der Entfernung für Anwendungen wie schlüssellose Zugangs- und Zündsysteme zu ermöglichen, bei denen die Sicherheit stark genug sein muss, um einen wertvollen Gegenstand wie ein Auto zu schützen.

8.2 Geräte-Rollen

Beim Bluetooth Channel Sounding werden zwei Geräterollen definiert. Der Initiator ist das Gerät, das das channel sounding startet und schließlich die von ihm erzeugten Daten an seine Anwendungsschicht weiterleitet, wo ein Entfernungswert berechnet werden kann. Das andere Gerät ist der Reflektor. In allen Fällen besteht das channel sounding darin, dass der Initiator ein Signal sendet und der Reflektor darauf mit einer eigenen Übertragung antwortet.

Abbildung 35 - Austausch von Signalen zwischen Initiator und Reflektor während CS

Wie wir noch sehen werden, sind eine Reihe von Übertragungen unterschiedlicher Art und in verschiedenen Sequenzen an einem vollständigen channel sounding beteiligt.

8.3 Bluetooth Channel Sounding in der Datentransportarchitektur

Die Datentransportarchitektur Bluetooth LE wurde in Abschnitt 7.7 Die Datentransportarchitektur vorgestellt. Bluetooth Channel Sounding besteht aus einem physikalischen Kanal und einer physikalischen Verbindung, wie in Abbildung 36 neben Beispielen für andere Transporte dargestellt.

Abbildung 36 - Bluetooth Channel Sounding in der Datentransportarchitektur

8.4 Zwei Bluetooth Channel Sounding Methoden

Bluetooth Channel Sounding ist aus vielen Gründen interessant. Ein Unterscheidungsmerkmal ist jedoch, dass in der Bluetooth-Kernspezifikation zwei ganz unterschiedliche Methoden der Entfernungsmessung definiert sind und eine Anwendung entweder eine der beiden Methoden oder, für größtmögliche Sicherheit, beide Methoden in Kombination verwenden kann. Die beiden Methoden heißen "Phase-Based Ranging" (PBR) und "Round-Trip Timing" (RTT) und werden im Folgenden in ihren Grundlagen beschrieben. Auf das Thema Sicherheit wird in Abschnitt 8.13 Sicherheit näher eingegangen.

8.4.1 Phasenbasiertes Ranging

Das Züchterrecht macht sich die Tatsache zunutze, dass Funkübertragungen aus einer Reihe von Wellen bestehen und dass jede vollständige Welle, ein so genannter Wellenzyklus, eine konstante physikalische Länge hat, sofern sich die Frequenz der Übertragung nicht ändert.

Abbildung 37 - Zwei Wellenzyklen, jeder mit der angegebenen Wellenlänge

Ein Bruchteil einer Wellenlänge wird durch eine Größe namens Phase dargestellt. Die Phase wird als Winkel in Grad oder Radiant ausgedrückt. Die Wellenlänge und die Phase eines Signals stehen im Mittelpunkt der Funktionsweise von PBR.

In Abbildung 38 wird eine Reihe von Punkten innerhalb eines Wellenzyklus markiert und der dieser Position entsprechende Phasenwert in Radiant angegeben.

Abbildung 38 - Beispiel für Phasenwerte

Es ist nicht möglich, die Entfernung zwischen zwei Geräten nur anhand der Wellenlänge eines Signals und eines vom Empfänger im Initiatorgerät gemessenen Phasenwertes zu berechnen. PBR funktioniert also durch den Austausch von zwei verschiedenen Signalen, jedes mit einer anderen Frequenz (f1 und f2) und daher mit einer anderen Wellenlänge.

Der Initiator sendet auf der Frequenz f1. Das Reflektorgerät empfängt diese Übertragung und sendet sie mit derselben Frequenz an den Initiator zurück. Der Initiator misst die Phase (p1) der Antwortübertragung und notiert sie. Dann sendet der Initiator ein weiteres channel sounding mit der Frequenz f2. Wiederum antwortet der Reflektor mit einer ähnlichen Übertragung auf der gleichen Frequenz f2, und der Initiator misst die Phase (p2) an dem Punkt, an dem die Antwort empfangen wird.

Abbildung 39 - erster Austausch von Züchterrechtssignalen bei der Frequenz f1

Abbildung 40 - zweiter PBR-Signalaustausch bei Frequenz f2

Aus der Differenz zwischen den gemessenen Phasenwerten der beiden channel sounding (p2 - p1) lässt sich mit Hilfe einfacher Mathematik der Abstand zwischen den beiden Geräten ableiten.

In der Praxis ist die Art und Weise, wie Bluetooth PBR verwendet, etwas komplizierter als die hier gegebene Beschreibung, aber im Kern ist es diese grundlegende Methodik.

Es gibt jedoch eine Komplikation bei der Verwendung von Phasenwerten zur Berechnung der Entfernung. Der Phasenwert ist, wenn er entlang mehrerer Wellenzyklen eines Signals gemessen wird, zyklisch. Gemessen für einen Wellenzyklus durchläuft er alle Werte von 0 Radiant bis 2π Radiant (0 - 360 Grad). Beim nächsten Wellenzyklus des Signals beginnt die Phase jedoch wieder bei 0 Radiant und durchläuft erneut alle Werte bis 2π Radiant. Dies wiederholt sich bei jedem Wellenzyklus. In Abbildung 41 ist dieses zyklische Muster dargestellt.

Abbildung 41 - die zyklische Natur der Phasenwerte

Im Zusammenhang mit dem Züchterrecht hat dies Konsequenzen. Der Phasenwert ändert sich mit dem Abstand zwischen den Geräten. Ab einem bestimmten physischen Abstand beginnen sich die Phasenwerte zu wiederholen. Folglich kann derselbe Phasendifferenzwert mehr als eine Entfernung implizieren. Dies wird als Entfernungsambiguität bezeichnet. Glücklicherweise stellt das design von Bluetooth Channel Sounding sicher, dass dies in der Praxis kein Problem darstellt, wie in 8.10 Kanäle und Kanalauswahl erläutert.

8.4.2 Hin- und Rückreisezeitpunkt

Funksignale bewegen sich mit Lichtgeschwindigkeit. Bei der RTT-Methode wird die Zeit gemessen, die ein Signal benötigt, um vom Initiator zum Reflektor und wieder zurück zu gelangen, wobei die Zeit berücksichtigt wird, die der Reflektor benötigt, um das empfangene Signal zu verarbeiten und seine Antwort zu formulieren und zu senden. Die Entfernung kann dann berechnet werden, indem die gemessene Zeit für den Hin- und Rückweg zwischen den Geräten mit der Lichtgeschwindigkeit multipliziert und das Ergebnis dann durch zwei geteilt wird.

Abbildung 42 - RTT-Übertragungen und Zeitpunkte

In Abbildung 42 ist ein Austausch von RTT-Paketen dargestellt. Die grün gestrichelten Linien ( ---- ) stellen die verstrichene Zeit dar, in der keines der beiden Signale in der Luft ist. Auf der Zeitachse sind vier Punkte markiert, die in Tabelle 9 erläutert werden.

Augenblick in der Zeit	Erläuterung
ToDA	Zeitpunkt des Verlassens von Gerät A. Dies ist der Zeitpunkt, zu dem das Signal von Gerät A über die Luft übertragen wird.
ToAB	Zeitpunkt des Eintreffens bei Gerät B. Dies ist der Zeitpunkt, zu dem das Signal an der Antenne von Gerät B angekommen ist.
ToDB	Time of Departure from Device B. Dies ist die Zeit, zu der Device B über die Luft sendet.
ToAA	Zeitpunkt des Eintreffens bei Gerät A: Dies ist der Zeitpunkt, zu dem das Signal von Gerät B an der Antenne von Gerät A empfangen wird.

Tabelle 9 - RTT-Zeitpunkte

Die Round-Trip-Time (RTT) kann durch die in Abbildung 42 dargestellten Zeitpunkte wie folgt ausgedrückt werden:

RTT = 2 * ToF = (_ToAA - _ToDA) - (_ToDB - _ToAB)

Der Begriff ist die Durchlaufzeit beim Reflektor. Der Initiator subtrahiert diesen Wert von der Zeit, die zwischen seiner Übertragung und dem Empfang einer Antwort vom Reflektor vergeht. Aber woher weiß der Initiator, wie lange der Reflektor gebraucht hat, um das Signal des Initiators zu verarbeiten und mit seiner Antwort zu antworten?

Die Antwort ist einfach. Die Zeit, die der Reflektor benötigt, ist ein fester Zeitraum, der zwischen den beiden Geräten vereinbart wird, bevor das Channel Sounding beginnt.

Tatsächlich muss eine Reihe von Prozeduren ausgeführt werden, bevor Channel Sounding beginnen kann. Die Spezifikation der Verbindungsschicht definiert eine Reihe von Kontrollverfahren, von denen sich einige mit der Konfiguration und dem Start des Channel Sounding befassen.

8.5 Bluetooth Channel Sounding Kontrollverfahren der Verbindungsschicht

Um die channel sounding einzuleiten, müssen die beiden Geräte zunächst eine LE-ACL-Verbindung herstellen (siehe 7.8.1 LE ACL - LE Asynchronous Connection-Oriented Logical Transport). Die Verschlüsselung muss auf der Verbindung aktiviert sein, bevor die Kontrollverfahren für channel sounding die Verbindung nutzen können, und daher müssen die beiden channel sounding gepaart sein.

Sobald eine verschlüsselte Verbindung zwischen den beiden Geräten hergestellt ist, werden die folgenden Kontrollverfahren der Verbindungsschicht ausgeführt:

1. Channel Sounding Sicherheit Start
2. Channel Sounding Austausch von Fähigkeiten
3. Channel Sounding Konfiguration
4. Modus-0 FAE-Tabellenabfrage
5. Channel Sounding Start

8.5.1 Channel Sounding Sicherheit Start

Bluetooth Channel Sounding hat eine Reihe einzigartiger Sicherheitsmerkmale, die in anderen Aspekten von Bluetooth LE nicht zu finden sind. Einige von ihnen hängen von drei numerischen Parametern ab, dem Initialisierungsvektor (CS_IV), der Instantiation Nonce (CS_IN) und dem Personalisierungsvektor (CS_PV).

Während des Channel Sounding Security Start-Verfahrens generiert jedes der beiden Geräte einen Wert für jeden der drei Sicherheitsparametertypen und übergibt sie über die verschlüsselte LE-ACL-Verbindung an das andere Gerät. Jedes Wertepaar für jeden der drei Typen wird dann von jedem Gerät verkettet, so dass am Ende des Prozesses jedes Gerät im Besitz der gleichen 128-Bit-CS_IV-, 64-Bit-CS_IN- und 128-Bit-CS_PV-Werte ist.

8.5.2 Channel Sounding Austausch von Fähigkeiten

Nicht alle channel sounding haben die gleichen Möglichkeiten. So können beispielsweise die unterstützten channel sounding (siehe Abschnitt 8.4 Zwei Channel Sounding ) unterschiedlich sein. Insgesamt sind 22 Parameter für die channel sounding definiert.

Damit die beiden Geräte zu einer channel sounding gelangen können, die beide unterstützen können, müssen sie zunächst Informationen über ihre Fähigkeiten austauschen. Zu diesem Zweck definiert die Verbindungsschicht die PDUs LL_CS_CAPABILITIES_REQ und LL_CS_CAPABILITIES_RSP.

8.5.3 Channel Sounding Konfiguration

Auf der Grundlage der Informationen über die channel sounding jedes Geräts wird eine ausgewählte Konfiguration, die beide Geräte unterstützen können, unter Verwendung der PDUs LL_CS_CONFIG_REQ und LL_CS_CONFIG_RSP der Verbindungsschicht ausgetauscht.

Die Rolle des Initiators oder des Reflektors bei channel sounding wird während dieses Verfahrens festgelegt, wobei die Anwendung, die den Prozess steuert, ihre Wahl in der PDU LL_CS_CONFIG_REQ sendet, auf die das andere Gerät antwortet.

8.5.4 Mode-0 FAE-Tabellenabfrage

Alle Geräte weisen eine gewisse Ungenauigkeit bei der Einstellung der Sendefrequenz auf, die je nach dem HF-Kanal, in dem sich die gewünschte Frequenz befindet, variieren kann.

Fractional Frequency Offset Actuation Error (FAE) ist ein Maß für die Ungenauigkeit, mit der ein Gerät die Frequenz seiner Übertragungen einstellen kann. Er wird als Differenz zwischen der beabsichtigten und der tatsächlich erzeugten Frequenz in Teilen pro Million (ppm) ausgedrückt.

Ein channel sounding muss eine Kalibrierung durchführen, die die FAE des Reflektors berücksichtigt, und benötigt dazu eine Tabelle mit FAE-Daten vom Reflektor. Er erhält diese Daten über das Kontrollverfahren Link Layer Mode-0 FAE Table Request. Dazu sendet der Initiator eine LL_CS_FAE_REQ-PDU, auf die der Reflektor mit einer LL_CS_FAE_RSP-PDU antwortet, die seine FAE-Tabelle enthält. Beachten Sie, dass die FAE-Tabelle eines Geräts während der Herstellung eingerichtet wird.

Der Modus 0 wird in Abschnitt 8.8 Schritte und Modi erläutert.

8.5.5 Channel Sounding Start

Nach dem Austausch von Sicherheitsmaterial, der Vereinbarung einer Konfiguration und der gemeinsamen Nutzung von FAE-Daten, sofern vorhanden, kann der Initiator nun den controller anweisen, mit der channel sounding zu beginnen. Dies beinhaltet den Austausch der Link Layer Control PDUs LL_CS_REQ, LL_CS_RSP und LL_CS_IND.

Das Channel sounding erfolgt in einer Abfolge von verschiedenen Vorgängen, die als CS-Schritte bezeichnet werden, und unterliegt einer Reihe von Zeitparametern. Diese werden während des Channel Sounding Start ausgetauscht.

8.6 Zeiteinteilung

Die logischen Transporte, die in 7.8 Die logischen Transporte erläutert wurden, strukturieren alle die Zeitachse, entlang derer Aktivitäten in Form von Ereignissen und manchmal Unterereignissen stattfinden. Die Abfolge und Zeitplanung von channel sounding ist anspruchsvoller und variabel, und um dem Rechnung zu tragen, werden vier Ebenen der Zeiteinteilung definiert.

Wenn channel sounding ausgeführt wird, geschieht dies in einer Reihe von einer oder mehreren CS-Prozeduren. Ein CS-Verfahren ist in CS-Ereignisse unterteilt, und jedes CS-Ereignis ist in CS-Unterereignisse unterteilt. Innerhalb jedes CS-Subereignisses ist eine Reihe von zwei oder mehr CS-Schritten geplant, und innerhalb dieser CS-Schritte finden die HF-Sende- und Empfangsaktivitäten statt. Abbildung 43 zeigt diese Konzepte, wie sie in einer Beispielkonfiguration verwendet werden könnten.

Abbildung 43 - CS Zeitteilungskonzepte

8.7 Pakete und Töne

Die RF-Aktivität, die innerhalb der CS-Schritte stattfindet, hat eine von zwei Formen:

1. Pakete - diese enthalten binäre Daten, die mit GFSK (Gaussian Frequency Shift Keying) für die Übertragung über Funk moduliert werden.
2. Töne - das sind Funkübertragungen, die keine Daten enthalten. Die Eigenschaften des Funksignals selbst werden von der PBR-Methode verwendet, die keine Daten aus dem digitalen Bereich benötigt.

Channel sounding werden als CS_Sync-Pakete bezeichnet, und es sind eine Reihe von Varianten definiert. CS_Sync-Pakete werden während der Kalibrierungsschritte und bei Verwendung der RTT-Methode übertragen. Die Töne, die bei der channel sounding verwendet werden, sind als CS-Töne bekannt und werden verwendet, wenn die PBR-Methode angewandt wird.

8.8 Schritte und Modi

CS-Schritte sind die unterste Ebene des Zeiteinteilungs- und Zeitplanungsschemas, das beim Bluetooth Channel Sounding verwendet wird. Die Schritte haben einen zugehörigen Modus, von denen vier definiert sind.

Modus	Beschreibung
0	Modus-0 wird für Kalibrierungszwecke verwendet.
1	mode-1 bezieht sich auf die RTT-Methode.
2	mode-2 bezieht sich auf die Züchterrechtsmethode.
3	mode-3 unterstützt sowohl RTT als auch PBR in einem einzigen Schritt mit zwei Methoden.

8.8.1 Modus-0

Der Zweck des Schrittmodus-0 besteht darin, dem Initiator die Berechnung eines Wertes zu ermöglichen, der als Fractional Frequency Offset (FFO) bezeichnet wird.

Die Frequenz von Signalen, die von channel sounding erzeugt werden, ist aufgrund der Beziehung zwischen Frequenz, Wellenlänge und Phase eine entscheidende Komponente für die Funktionsweise derChannel Sounding . Wie genau die Frequenz eines erzeugten Signals mit der beabsichtigten Frequenz übereinstimmt, ist jedoch unterschiedlich, und ein gewisses Maß an Ungenauigkeit ist immer zu erwarten.

Der FFO ist ein Maß für das Ausmaß, in dem sich der Reflektor bei der Erzeugung einer bestimmten Zielfrequenz vom Initiator unterscheidet. Zur Berechnung des FFO werden die Frequenz des vom Reflector empfangenen CS-Tons und die Mode-0-FAE-Tabelle des Reflectors herangezogen, die der Initiator während des Kontrollverfahrens 8.5.4 Mode-0-FAE-Tabellenanforderung erhalten hat.

FFO wird in Berechnungen verwendet, um Unterschiede zwischen Initiator und Reflektor auszugleichen und letztlich die Genauigkeit der Ergebnisse zu verbessern.

Abbildung 44 zeigt die von Initiator und Reflektor in einem Mode-0-Schritt übertragenen Pakete und Töne.

Abbildung 44 - Paket- und Tonübertragungen im Modus 0

Die Bluetooth-Kernspezifikation definiert die im Diagramm dargestellten und gekennzeichneten Zeitschlitze. Die Bezeichnungen und ihre Bedeutung sind in Tabelle 10 aufgeführt.

T_SY	Zeit für die Synchronisationssequenz.
T_RD	Zeit für die Abwärtsrampe der Übertragung. Diese Zeit beträgt 5 μs und wird vom Sender verwendet, um Energie aus dem HF-Kanal zu entfernen.
T_IP1	Zeit für das Intermezzo zwischen dem Ende der Übertragung des Initiators und dem Beginn der Übertragung durch den Reflektor. Die Dauer variiert zwischen 10 μs und 145 μs und wird im Verfahren zum Austausch von Fähigkeiten festgelegt.
T_GD	Überwachungszeit. Immer 10 μs lang.
T_FM	Zeit für die Frequenzmessung. Immer 80 μs Dauer für Schrittmodus-0.

Tabelle 10 - CS-Schritt-Zeitschlitze

Jedes CS-Unterereignis beginnt mit mindestens einem Modus-0-Schritt.

8.8.2 Modus-1

Modus-1-Schritte beinhalten den Austausch von CS_Sync-Paketen zur Messung einer Umlaufzeit. Abbildung 45 zeigt den Paketaustausch und die für diesen Schrittmodus definierten Zeitschlitze.

Abbildung 45 - Paketaustausch in Modus-1 (RTT)

Um die Berechnung einer Round-Trip-Zeit zu ermöglichen, erfasst der Initiator einen Zeitstempel beim Senden des CS_Sync-Pakets und einen weiteren beim Empfang eines CS_Sync-Pakets vom Reflektor. In der Bluetooth Core Specification sind mehrere Zeitstempelverfahren definiert, die jeweils unterschiedliche Genauigkeitsgrade bieten.

8.8.3 Modus-2

Modus-2-Schritte beziehen sich auf die Verwendung der PBR-Methode zur Entfernungsmessung. Initiator und Reflektor tauschen CS-Töne aus, wobei jedes Gerät auf der gleichen Frequenz sendet. Bei Verwendung der PBR-Methode können mehrere Antennen beteiligt sein, was sich in der Bedeutung der in Abbildung 46 dargestellten Zeitschlitze widerspiegelt.

Abbildung 46 - Austausch von CS-Tönen im Modus 2 (PBR)

In Abbildung 46 sind einige zusätzliche Zeitschlitzbezeichnungen dargestellt, die in Tabelle 11 erläutert werden.

T_SW	Für die Antennenumschaltung reservierte Zeitspanne.
T_PM	Zeit für die Übertragung eines Phasenmesstons.
T_IP2	Zeit für das Intermezzo zwischen den CS-Tönen.
N_AP	Anzahl der Antennenpfade.

Tabelle 11 - Zusätzliche PBR-Zeitschlitzbezeichnungen

8.8.4 Modus-3

Modus-3-Schritte bieten dem Initiator die Grundlage sowohl für eine RTT- als auch für eine KBR-Berechnung in einem einzigen Schritt. Abbildung 47 zeigt den Austausch von CS_Sync-Paketen und CS-Tönen, der in diesem Schrittmodus stattfindet.

Abbildung 47 - In einem Mode-3-Schritt ausgetauschte Pakete und Töne

8.9 Betriebsart Sequenzierung

Ein CS-Verfahren besteht immer aus mehreren CS-Schritten mit einer Mischung aus zwei oder drei verschiedenen Modi. Im Allgemeinen gilt: Je mehr Schritte ausgeführt werden, desto mehr Daten werden für die Entfernungsberechnung erfasst und desto besser sind die Ergebnisse. Die Anzahl der CS-Prozeduren, CS-Ereignisse, CS-Unterereignisse und CS-Schritte, die ausgeführt werden, sowie die Mischung der verwendeten Schrittmodi wird von den Anwendungen konfiguriert. Dies wird als Mode Sequencing bezeichnet.

Modus 0 ist immer beteiligt, und alle CS-Unterereignisse müssen mit einem, zwei oder drei aufeinanderfolgenden Modus-0-Schritten beginnen. Mindestens ein und höchstens zwei andere Modi müssen in einer Schrittfolge vorhanden sein. Es sind jedoch nicht alle Kombinationen zulässig, und die Bluetooth-Kernspezifikation legt fest, welche Kombinationen zulässig sind. In einer bestimmten Konfiguration wird einer der ausgewählten Nicht-Modus-0-Modi als Main_Mode und der andere (falls vorhanden) als Sub_Mode bezeichnet. Die Bluetooth Core Specification enthält weitere Informationen über die Bedeutung dieser Begriffe und ihre Auswirkungen auf die Modusreihenfolge.

Tabelle 12 zeigt die zulässigen Nicht-Mode-0-Kombinationen.

Haupt_Modus	Unter_Modus
Modus-1	Keine
Modus-2	Keine
Modus-3	Keine
Modus-2	Modus-1
Modus-2	Modus-3
Modus-3	Modus-2

Tabelle 12 - Zulässige Kombinationen von Betriebsarten, die nicht dem Modus 0 entsprechen.

Im Allgemeinen folgt die Abfolge im Schrittbetrieb diesem Muster:

1. Ein oder mehrere Mode-0-Schritte starten ein Unterereignis.
2. Es folgt eine Folge von n Hauptmodusschritten, wobei n zufällig ausgewählt wird und in einem Bereich liegt, der während der Konfiguration der channel sounding festgelegt wird.
3. Ein einzelner sub_mode-Schritt folgt auf die Abfolge von n main_mode-Schritten.

Abbildung 48 zeigt ein Beispiel.

Abbildung 48 - Beispiel einer Schrittmodussequenz mit Konfigurationsparametern

8.10 Kanäle und Kanalauswahl

In Abschnitt 6.1 Frequenzband wird erläutert, wie Bluetooth LE das 2,4-GHz-Frequenzband in 40 Kanäle mit einer Breite von jeweils 2 MHz unterteilt. Abschnitt 7.8 Die logischen Transporte erklärt, wie die verschiedenen logischen Transporte, die durch die Link-Layer-Spezifikation definiert sind, bei der Auswahl der Kanäle vorgehen. Bluetooth Channel Sounding verfolgt in beiderlei Hinsicht einen anderen Ansatz.

8.10.1 RF-Kanäle

Channel Sounding wird im unlizenzierten 2,4-GHz-Band betrieben, wie dies auch bei der Verwendung der logischen Übertragungsschicht der Fall ist. Das Band ist jedoch in 79 Kanäle von 1 MHz Breite unterteilt, von denen 72 für das channel sounding zur Verfügung stehen. Die Anordnung dieser Kanäle gewährleistet, dass die primären LE-Werbekanäle vermieden werden.

In Tabelle 13 sind die Kanäle channel sounding , ihre Kanalindexwerte und die Angabe, ob jeder Kanal während der channel sounding verfügbar ist oder nicht, dargestellt.

CS-Kanal-Index	RF-Mittenfrequenz	Erlaubt
0	2402 MHz	Nein
1	2403 MHz	Nein
2	2404 MHz	Ja
...	...	...
22	2424 MHz	Ja
23	2425 MHz	Nein
24	2426 MHz	Nein
25	2427 MHz	Nein
26	2428 MHz	Ja
...	...	...
76	2478 MHz	Ja
77	2479 MHz	Nein
78	2480 MHz	Nein

Tabelle 13 - CS-Kanal-Indizes und physikalische HF-Kanäle

Die Verwendung einer Kanalbreite von 1 MHz anstelle der üblichen 2 MHz stellt sicher, dass Entfernungsmehrdeutigkeit (wie in 8.4.1 Phasenbasiertes Ranging erläutert) erst bei etwa 150 Metern auftritt. Dies ist mehr als ausreichend für die Arten von Anwendungen, für die Bluetooth Channel Sounding konzipiert ist.

8.10.2 Kanalfilterung

Das adaptive Frequenzsprungverfahren (AFH) wurde in Abschnitt 7.4 Kanalauswahl erläutert. Der adaptive Aspekt von AFH besteht darin, dass die Geräte die Leistung der einzelnen HF-Kanäle messen und Informationen darüber, ob ein bestimmter Kanal verwendet werden sollte oder nicht, zwischen den kommunizierenden Geräten austauschen. Auf diese Weise können sich die Geräte an die HF-Umgebung anpassen, in der sie arbeiten, und Kanäle mit übermäßigen Störungen vermeiden.

Bluetooth Channel Sounding unterhält aus den gleichen Gründen eine Kanalindexfilter-Bitmap. Jeder Kanal in der Karte ist entweder als eingeschlossen oder ausgeschlossen gekennzeichnet. Der Kanalauswahlprozess stellt sicher, dass als ausgeschlossen markierte Kanäle niemals ausgewählt werden. Der Initiator und der Reflektor tauschen Informationen über die HF-Kanalleistung untereinander aus, indem sie das Verfahren zur Aktualisierung der Channel Sounding für das Link Layer Channel Sounding verwenden.

8.10.3 Kanalwahl und Frequenzsprungverfahren

Ein Kanal wird direkt vor der Ausführung jedes CS-Schrittes ausgewählt, wie in Abbildung 49 dargestellt.

Abbildung 49 - Frequenzsprung vor der Schrittausführung

In der Bluetooth sind drei Kanalauswahlalgorithmen definiert, die ausschließlich für das Bluetooth Channel Sounding verwendet werden. Sie sind bekannt als CSA #3a, CSA #3b und CSA #3c.

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-Stufen ausgelegt, aber nur eine der beiden darf während eines CS-Verfahrens verwendet werden.

CSA #3a und CSA #3b funktionieren auf sehr ähnliche Weise. Beide verwenden eine Kanalliste, die die Indizes aller Kanäle enthält, die als in der Kanalkarte enthalten markiert sind. Die Kanallisten werden gemischt, wenn die channel sounding beginnt, und die Kanalauswahl umfasst dann einfach die Verwendung jedes Kanals in der gemischten Liste, einen nach dem anderen, wobei jeder Kanal immer nur einmal verwendet wird. Die Regel für CSA #3a ist, dass, wenn alle Kanalindizes in der gemischten Liste verwendet wurden, die zugehörige Kanalliste neu generiert und neu gemischt wird und die Verwendung erneut beginnt. Bei CSA #3b kann die gemischte Liste mehrere Male durchlaufen werden, bevor sie neu generiert wird.

CSA #3c unterscheidet sich deutlich von CSA #3b und ist komplizierter, kann aber unter bestimmten Umständen Vorteile bei der Erkennung reflektierter Signalwege bieten. Weitere Einzelheiten finden Sie in der Bluetooth . Die Unterstützung für CSA #3c ist optional.

8.11 Antennenumschaltung und Antennenwege

Die Geräte können über eine Gruppe von bis zu vier Antennen für die phasenbasierte Entfernungsmessung verfügen. Die Übertragung von einer Antenne in einem der Geräte zu einer der Antennen im anderen Gerät bildet einen Antennenpfad. Es sind maximal 4 Antennenpfade zulässig, was die Permutationen der Antennengruppengröße in Initiator und Reflektor auf eine Liste von 8 beschränkt (siehe Tabelle 14).

Antennenkonfigurationsindex (ACI)	Gerät Eine Anzahl von Antennen	Gerät B Anzahl der Antennen	Anzahl der Antennenwege (N_AP)
0	1	1	1
1	2	1	2
2	3	1	3
3	4	1	4
4	1	2	2
5	1	3	3
6	1	4	4
7	2	2	4

Tabelle 14 - Kombinationen von Antennengruppengrößen und Antennenpfaden

Die folgenden Abbildungen zeigen Beispiele für zwei verschiedene Antennenkonfigurationen und die dazugehörigen Antennenwege.

Die Antennenumschaltung erfolgt während der Übertragung von CS-Tönen in Mode-2- und Mode-3-Schritten. Dies spiegelt sich in dem Begriff N_AP (Anzahl der Antennenwege) in den Formeln für die Zeitschlitzdauer in Abbildung 46 und Abbildung 47 wider.

8.12 RTT und Genauigkeit

Die Lichtgeschwindigkeit in einem Vakuum beträgt 299.792.458 Meter pro Sekunde. Das bedeutet, dass das Licht in nur einer Mikrosekunde fast 300 Meter zurücklegt. Und natürlich bewegen sich auch Radiowellen mit Lichtgeschwindigkeit.

Daher ist die Genauigkeit, mit der die ToD- und ToA-Zeitstempel des Initiators bei der RTT-Methode erfasst werden, entscheidend. Ein sehr kleiner Fehler in den erfassten Zeitstempeln kann zu einem erheblichen Fehler in der resultierenden Entfernungsberechnung führen.

Die Erfassung von Zeitstempeln mit ausreichender Genauigkeit für Entfernungsschätzungen stellt die Ingenieure vor große Herausforderungen. Die Bluetooth Core Specification beschreibt mehrere Ansätze.

• Zugriffsadresse: Die Zugriffsadresse ist das erste Feld in CS_Sync-Paketen und hat eine Länge von 32 Bit. Eine Zeitstempel-Methode besteht darin, die Zeit zu erfassen, zu der die Zugriffsadresse empfangen wird, obwohl einige Details, wie genau dies geschehen soll, der Implementierung überlassen werden.
• Fractional Timing-Schätzungen: Es gibt zwei Möglichkeiten, zu einer fraktionierten Zeitschätzung zu gelangen, von denen eine wahrscheinlich genauer ist als die Verwendung der Zugangsadresse. Im Allgemeinen beinhalten die fraktionierten Methoden die Analyse eines Feldes, das am Ende von CS_Sync-Paketen platziert werden kann, um sehr kleine Zeitfehler zu bestimmen. Zu diesem Zweck kann eines von zwei Feldern an CS_Sync-Pakete angehängt werden.
  • Zufällige Sequenz: Es ist unwahrscheinlich, dass die Abtastung eines empfangenen Signals mit der Phase des empfangenen Signals übereinstimmt, und dies kann die Ursache für kleine Zeitfehler sein. Die Analyse des Zufallssequenzfeldes kann den Unterschied zwischen den tatsächlichen Abtastpunkten und denen, die optimal gewesen wären, aufzeigen. Dies kann dann genutzt werden, um die Genauigkeit der Zeitstempelwerte zu verbessern.
  • Klingende Sequenz: Dies ist eine abwechselnde Folge von 1en und 0en. Wenn sie mit GFSK moduliert und übertragen wird, haben die Symbole, die 1en und 0en darstellen, unterschiedliche Frequenzen und können als zwei verschiedene Töne betrachtet werden. Die Analyse der Phasendifferenz zwischen den beiden Tönen ermöglicht die Messung von Zeitfehlern, was zur Verbesserung von Zeitstempeln genutzt werden kann.

Im Allgemeinen können Messungen über eine Reihe von Schritten dazu beitragen, die Genauigkeit von Zeitstempeln durch eine Analyse der Verteilung der Werte zu verbessern.

8.13 Sicherheit

Die Sicherheit von Systemen zur Entfernungsmessung birgt einige neue Herausforderungen. Im Allgemeinen besteht die Bedrohung, gegen die es sich zu schützen gilt, darin, dass ein bösartiges Gerät einem der beiden vertrauenswürdigen Geräte (insbesondere dem Initiator im Fall von Bluetooth Channel Sounding) vorgaukelt, das andere vertrauenswürdige Gerät sei näher als es tatsächlich ist, was offensichtliche Folgen haben kann, z. B. den Diebstahl eines Autos.

In den nächsten beiden Abschnitten werden zwei Arten von Angriffen kurz erläutert. In Abschnitt 8.13.3 Sicherheitsmerkmale des Bluetooth Channel Sounding werden die Merkmale des Bluetooth Channel Sounding zusammengefasst, die vor Angriffen dieser Art (und anderen) schützen.

8.13.1 Spoofing

Eine Klasse von Angriffen besteht darin, dass eines der vertrauenswürdigen Geräte durch das angreifende Gerät imitiert wird. Ein Beispiel hierfür ist ein Replay-Angriff, bei dem das böswillige Gerät die zwischen vertrauenswürdigen Geräten ausgetauschten Pakete während eines normalen, erfolgreichen Dialogs aufzeichnet. Später verwendet es dann einige der aufgezeichneten Pakete, um Antworten zu senden, die ein vertrauenswürdiges Gerät dazu bringen, sich so zu verhalten, als befände es sich in einem Dialog mit seinem legitimen Gegenstück.

In Abbildung 52 stellen Alice und Bob die beiden vertrauenswürdigen Geräte in einem proprietären drahtlosen Entfernungsmessungssystem dar, das nur unzureichend gesichert ist. Der Angreifer ist ein bösartiges Gerät, das in dieser ersten Phase des Angriffs einfach den Austausch zwischen Alice und Bob abhört und die Pakete aufzeichnet.

In Abbildung 53 werden in Phase 2 des Angriffs die in Phase 1 aufgezeichneten Pakete verwendet, um Alice vorzugaukeln, dass der Austausch mit dem vertrauenswürdigen Gerät Bob erfolgt.

Abbildung 52 - Replay-Angriff Teil 1

Abbildung 53 - Replay-Angriff Teil 2

Bluetooth Channel Sounding verfügt über mehrere Schutzmechanismen gegen Angriffe dieser Art.

8.13.2 Relay-Angriffe

Eine andere Art von potenziellem Angriff ist der sogenannte Relay-Angriff. Dabei handelt es sich um einen Man-in-the-Middle-Angriff (MITM), der auf der physikalischen Ebene arbeitet und Signale von einem vertrauenswürdigen Gerät an ein anderes weiterleitet, das Signal aber in Echtzeit auf irgendeine Weise manipuliert, um den Eindruck zu erwecken, dass die Geräte näher beieinander sind, als sie es tatsächlich sind.

Abbildung 54 - Relay-Angriff

Bluetooth Channel Sounding verfügt über mehrere Schutzmechanismen gegen Angriffe dieser Art.

8.13.3 Bluetooth Channel Sounding Sicherheitseigenschaften

Bluetooth Channel Sounding umfasst eine umfangreiche Reihe von Sicherheitsfunktionen, und das Generic Access Profile definiert vier Sicherheitsstufen, die für channel sounding gelten.

Die vollständige Liste der Sicherheitsmerkmale, die für Bluetooth Channel Sounding definiert sind, kann in vier Kategorien unterteilt werden.

8.13.3.1 Verwendung von PBR- und RTT-Methoden in Kombination

Bluetooth Channel Sounding unterstützt sowohl die phasenbasierte Methode der Entfernungsmessung als auch die Round-Trip-Timing-Methode. Die Flexibilität der Step-Mode-Sequenzierung bedeutet, dass Anwendungen beide Methoden gleichzeitig verwenden können. Auf diese Weise können die von diesen beiden recht unterschiedlichen Methoden erzeugten Daten miteinander abgeglichen werden.

Die Komplexität, beide Methoden gleichzeitig anzugreifen, so dass sowohl die Phase der channel sounding als auch die berechneten Umlaufzeiten manipuliert werden, um irreführende und konsistente Ergebnisse zu erzielen, wird von Sicherheitsexperten als sehr hoch angesehen. Dies allein ist ein leistungsfähiger Mechanismus zur Aufdeckung von Angriffen.

8.13.3.2 Randomisierung des Bitstroms und der Übertragungsmuster

Die Sicherheit derChannel Sounding umfasst die Spezifikation einer Funktion namens Deterministic Random Bit Generator (DRBG). Durch wiederholte Aufrufe dieser Funktion wird eine Folge von Werten erzeugt, die für den zufälligen Beobachter zufällig und unvorhersehbar ist.

DRBG verwendet jedoch die Werte für den Initialisierungsvektor (CS_IV), die Instanziierungs-Nonce (CS_IN) und den Personalisierungsvektor (CS_PV), die von beiden Geräten während der Channel Sounding Security Start-Prozedur festgelegt wurden, und zwei Geräte, die dieselben Werte für diese DRBG-Parameter verwenden, werden bei einer Reihe von Aufrufen der Funktion genau die gleiche Abfolge von Ausgaben erzeugen. Daher ist die Abfolge für Geräte, die über die drei DRBG-Parameter verfügen, deterministisch, für andere (wie einen Angreifer) jedoch unvorhersehbar. CS_IV, CS_IN und CS_PV haben jedes Mal, wenn eine channel sounding durchgeführt wird, andere Werte, und da sie aus einem Austausch von Teilwerten über eine verschlüsselte LE-ACL-Verbindung erzeugt werden, kann man sicher davon ausgehen, dass ein Angreifer die verwendeten DRBG-Parameterwerte nicht kennt.

DRBG wird verwendet, um sowohl den Inhalt des Bitstroms als auch das gesamte Übertragungsmuster zu randomisieren. In der Bluetooth-Kernspezifikation ist festgelegt, dass Bereiche des channel sounding Bitstroms zufällig ausgewählt und dann auf ein zufällig generiertes Bitmuster gesetzt werden, wobei in beiden Fällen DRBG verwendet wird. Darüber hinaus sind für Modus-2- und Modus-3-Schritte Zeitschlitze definiert, die als Tonerweiterungsschlitze bezeichnet werden, und ob während dieser Schlitze eine Übertragung erfolgt oder nicht, hängt von DRBG-Aufrufen ab.

Die Verwendung von DRBG auf diese beiden Arten bedeutet, dass sowohl der Initiator als auch der Reflektor den Inhalt ihrer Übertragungen und das Vorhandensein bzw. Nichtvorhandensein der übertragenen Töne in den Tonerweiterungsschlitzen zufällig festlegen können. Da DRBG per Definition deterministisch ist, wissen sowohl Initiator als auch Reflector (jeweils im Besitz von CS_IV, CS_IN und CS_PV), was sie zu erwarten haben, während ein Angreifer dies nicht weiß. Wenn eine der beiden channel sounding unerwartete Bitwerte oder unerwartete Übertragungen (oder ein unerwartetes Ausbleiben von Übertragungen) feststellt, wird dies als potenzieller Angriff gewertet.

Replay-Angriffe können nicht erfolgreich sein, da sich die Abfolge der übertragenen Pakete und Töne jedes Mal ändert, wenn die beiden Geräte eine channel sounding durchführen, und eine einfache Wiedergabe einer aufgezeichneten früheren Reihe von Austauschvorgängen leicht zu erkennen wäre.

8.13.3.3 Schutz vor Symbolmanipulation

Es gibt eine Reihe bekannter Angriffe auf der physikalischen Schicht, bei denen ein Man-in-the-Middle (MITM) den Wert teilweise empfangener Funksymbole von einem rechtmäßigen Sendegerät vorwegnimmt und die vollständigen Versionen dieser Symbole frühzeitig weiterleitet und so das Timing so manipuliert, dass der rechtmäßige Empfänger die Umlaufzeit und damit die Entfernung falsch berechnet. Das Signal des Angreifers wird in der Regel verstärkt, so dass das Zielgerät das manipulierte Signal als primäres Signal ansieht und nicht das schwächere Originalsignal, das aufgrund der Mehrwegeausbreitung als Reflexion angesehen und nicht beachtet werden kann. Dieser Angriff nutzt die übliche, volle Dauer eines Symbols aus, um einen zeitlichen Vorsprung zu erzielen, und Symbole mit einer längeren Dauer sind für diese Art von Angriff anfälliger als solche mit einer kürzeren Dauer.

Der LE 2M 2BT PHY mit seinem product von 2,0 führt zu Symbolimpulsen, die kürzer sind als die mit den anderen PHYs verbundenen Impulse, was das Risiko dieser Arten von Angriffen verringert.

Eine weitere Funktion, die zum Schutz vor Relais-Angriffen eingesetzt werden kann, ist die SNR-Kontrolle.

Die SNR-Kontrolle ermöglicht es dem Initiator und dem Empfänger, einigen Signalen eine vorher vereinbarte Menge an Zufallsrauschen beizumischen. Symbolmanipulations-Relaisangriffe beruhen darauf, dass der Angreifer in der Lage ist, das legitime Signal sehr schnell zu isolieren und zu manipulieren, und zwar in viel weniger Zeit als der vollen Dauer eines Symbols. Durch das Einbringen von Rauschen in das Signal wird die Analyse des Angreifers erschwert und verlangsamt, so dass die Wahrscheinlichkeit, dass solche Angriffe erfolgreich sind, sinkt. Andererseits sind die Initiator- und Reflektorgeräte, die den SNR im Voraus vereinbart haben, in der Lage, das künstlich hinzugefügte Rauschen leicht zu filtern.

8.13.3.4 RF-Signalanalysetechniken und Angriffserkennung

Die Spezifikation von Bluetooth Channel Sounding enthält eine Beschreibung eines Angriffserkennungssystems und eine standardisierte Metrik zur Angabe der Wahrscheinlichkeit, dass ein Angriff im Gange ist, die so genannte Normalized Attack Detector Metric (NADM). NADM verwendet eine gleitende Skala mit zugehörigen adjektivischen Begriffen, wie in Tabelle 15 dargestellt.

NADM-Wert	Beschreibung
0x00	Ein Angriff ist extrem unwahrscheinlich
0x01	Ein Angriff ist sehr unwahrscheinlich
0x02	Ein Angriff ist unwahrscheinlich
0x03	Ein Angriff ist möglich
0x04	Ein Angriff ist wahrscheinlich
0x05	Ein Angriff ist sehr wahrscheinlich
0x06	Ein Angriff ist sehr wahrscheinlich
0xFF	Unbekannter NADM.Standardwert für RTT-Typen, die keine Zufallsfolge oder klingende Folge haben.

Tabelle 15 - NADM-Werte

Zu den Indikatoren für einen möglichen Angriff gehören unerwartete Bitwerte oder Phasenanpassungen. Die Eigenschaften eines Referenzsignals, mit dem Vergleiche angestellt werden können, sind in der Bluetooth festgelegt.

8.14 Anwendungen zur Entfernungsmessung

Bluetooth Channel Sounding selbst berechnet keine Entfernungswerte. Stattdessen stellt es Anwendungen das Rohmaterial zur Verfügung, einschließlich Zeitinformationen sowie Amplituden- und Phasenwerte(IQ-Samples), die in proprietären Entfernungsberechnungsalgorithmen verwendet werden können. Ein Standardalgorithmus ist nicht definiert, da dies keinen Einfluss auf die Interoperabilität hat und es den Herstellern freisteht, sich durch die Qualität der Ergebnisse, die ihre Algorithmen erzielen können, zu unterscheiden.

Anwendungen, die Bluetooth Channel Sounding verwenden, haben eine Reihe von Aufgaben zu erfüllen, unter anderem:

• Implementierung eines Algorithmus, der die von Bluetooth Channel Sounding gelieferten Daten zur Berechnung von Entfernungsmessungen verwendet.
• Auswahl einer Konfiguration, einschließlich der zu verwendenden Schrittmodi und ihrer Sequenzierungs- und Zeitparameter, die den Anforderungen und Prioritäten der Anwendung entspricht. Dazu gehört auch die Abwägung von Aspekten wie der Latenz gegen die Menge der zu erzeugenden channel sounding .
• Verwendung von HCI-Befehlen ( Host Controller Interface) zur Einleitung und Durchführung der in Abschnitt 5 "Bluetooth Channel Sounding Link Layer Control Procedures" beschriebenen Steuerungsverfahren.
• Auswahl einer der in GAP definierten Sicherheitsstufen für channel sounding und Konfiguration des channel sounding unter Berücksichtigung der Sicherheitsanforderungen.
• Verarbeitung der durch NADM-Werte ausgedrückten Informationen zur Angriffserkennung in einer für die Anwendung geeigneten Weise.

Die Bluetooth Channel Sounding dient als strenger, standardisierter und interoperabler Rahmen für genaue und sichere Entfernungsmessungsanwendungen und bietet den Entwicklern gleichzeitig die Flexibilität, ihre Anwendungen entsprechend ihren jeweiligen Prioritäten zu optimieren.

9. Die isochrone Anpassungsschicht

9.1 Grundsätzliches

Der Zweck des Isochronous Adaptation Layer (ISOAL) besteht im Wesentlichen darin, ein potenzielles Problem zu lösen, das sowohl bei der isochronen Kommunikation mit angeschlossenen als auch bei der Rundfunkkommunikation mit Audiogeräten auftreten kann. Sie kann auch in anderen Bereichen der isochronen Kommunikation Anwendung finden.

9.1.1 Audio-Sampling 101

Digitales Audio funktioniert, indem ein analoges Audiosignal abgetastet und ein Codec auf das abgetastete Audiosignal angewendet wird, um die digitalen Abtastdaten zu komprimieren und anderweitig zu verarbeiten, bevor sie gespeichert oder - im Falle von Bluetooth LE - übertragen werden. Beim Lesen oder Empfangen kodierter digitaler Audiodaten wird der Prozess umgekehrt, wobei ein Codec verwendet wird, um die Daten zu dekodieren und eine Reihe digitaler Abtastwerte zu erzeugen, die dann verwendet werden, um die ursprünglichen analogen Audiodaten (ungefähr) wiederherzustellen. Abbildung 55 veranschaulicht die Schritte der Abtastung, Kodierung und Übertragung eines Audiosignals und die umgekehrten Schritte des Empfangs kodierter Audiodaten, ihrer Dekodierung und schließlich ihrer Wiedergabe.

Abbildung 55 - Schritte der Audioverarbeitung

Eines der Hauptziele eines Audiocodecs ist es, die Größe der Audiodaten zu reduzieren, damit sie effizient über eine Verbindung mit begrenzter (und kostbarer!) Bandbreite übertragen werden können. Bei der Abtastung wird die Amplitude eines Signals in regelmäßigen Abständen gemessen und aufgezeichnet. Die Häufigkeit, mit der ein Abtastwert aufgezeichnet wird, wird als Abtastrate bezeichnet. Die vertikalen Linien in Abbildung 56 stellen Abtastwerte des kontinuierlich variablen Audiosignals dar, das durch die Kurve repräsentiert wird. Diese Reihe von Abtastwerten stellt eine ungefähre Darstellung des ursprünglichen analogen Signals dar. Je häufiger Abtastungen vorgenommen werden (d. h. je höher die Abtastrate), desto näher kommt diese Annäherung an das Original, und wenn man den Prozess umkehrt, um das ursprüngliche Audiosignal wiederherzustellen, sind die Ergebnisse und die wahrgenommene Qualität umso besser.

Eine weitere Dimension der Abtastung ist die Bittiefe. Die Amplitude des Signals muss bei der Abtastung durch einen ganzzahligen Wert dargestellt werden. Ein Ansatz besteht darin, den Bereich der möglichen Amplitudenwerte in 256 diskrete Amplitudenbänder zu unterteilen und jedes durch eine Zahl zwischen 0 und 255 darzustellen. Bei diesem Schema benötigt ein einzelnes Sample nur ein Byte (8 Bits), um das Band aufzuzeichnen, in das der abgetastete Amplitudenwert fällt, und die Bittiefe wird daher als 8 Bits bezeichnet. Die Unterteilung des möglichen Amplitudenbereichs in mehrere diskrete Bänder bietet ein feinkörnigeres System zur Darstellung von Abtastwerten und damit potenziell qualitativ bessere Ergebnisse. Bei einer Bittiefe von 24 Bits beispielsweise kann der Bereich der möglichen Amplitudenwerte durch eine ganze Zahl im Bereich von 0 bis 16.777.215 dargestellt werden. Für jede Abtastung werden jedoch 3 Byte benötigt, so dass bei einer Abtastung mit dieser höheren Bittiefe dreimal so viele Daten erzeugt werden.

Die digitale Abtastung kann große Datenmengen erzeugen. Nehmen wir einen dreiminütigen Song, der mit einer Rate von 44,1 kHz (CD-Qualität) und einer Bittiefe von 24 gesampelt wird. Wenn wir nachrechnen, ergibt sich, dass die Menge an Rohdaten, die benötigt wird, um den gesamten Song in digitaler Form darzustellen, fast 24 Megabyte beträgt. Darüber würden wir uns keine Gedanken machen, wenn wir die Daten nur auf der 4-Terabyte-Festplatte eines Computers speichern wollten, aber bei der Übertragung dieser Daten über eine Kommunikationsverbindung mit begrenzter Bandbreite ist das ein Problem. Hier kommen Codecs ins Spiel.

Abbildung 56 - Diskrete Abtastwerte, die ein kontinuierliches analoges Signal darstellen

9.1.2 Codecs und Frames

Ein Codec wie LC3, der von Bluetooth LE Audio verwendet wird, kann digitale Rohdaten auf weniger als 25 % der ursprünglichen Größe komprimieren (beachten Sie jedoch, dass die tatsächlichen Ergebnisse stark vom ursprünglichen Audioinhalt abhängen). Dies ist eine erhebliche Einsparung.

Codecs arbeiten im Allgemeinen durch Erkennung und Ausnutzung von Mustern, die in einer Reihe von aufeinanderfolgenden Abtastwerten gefunden werden. Um ein sehr einfaches Beispiel zu geben und nur dieses Prinzip zu veranschaulichen: Wenn der Datensatz eine Reihe von 100 aufeinanderfolgenden Abtastwerten enthält, die alle den gleichen Wert von, sagen wir, 50 haben, dann könnte ein Codec unter der Annahme einer Bittiefe von 8 Bit dies als zwei Bytes darstellen, die [100,50] enthalten, anstatt die ursprüngliche Reihe von 100 Bytes, die die Liste der einzelnen Abtastwerte [50,50,50...,50] enthalten. Damit ein Codec funktioniert, braucht er natürlich eine ganze Reihe von Samples, die er analysieren und kodieren kann, und nicht nur ein Sample auf einmal (in einem einzelnen Sample sind nicht viele Muster zu finden!).

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 4410 Samples, wenn die Samplerate 44,1 KHz beträgt.

Verschiedene Audioprodukte können unterschiedliche Frame-Dauern verwenden. 10 ms und 7,5 ms sind üblich. Wenn ein Gerät (die Quelle) Audio mit einer bestimmten Rahmendauer produziert und ein anderes Gerät (die Senke) es konsumiert, aber eine andere Rahmendauer verwendet, gibt es ein Problem, das gelöst werden muss. Hier kommt ISOAL ins Spiel.

9.2 Gerahmt vs. ungerahmt

Wenn Geräte eine isochrone Kommunikation verwenden, müssen die vom sendenden Gerät und einem empfangenden Gerät verwendeten Rahmendauern nicht gleich sein. Dies führt zu zwei möglichen Situationen:

1. Die vom ersten Gerät verwendete Bilddauer ist ein exaktes Vielfaches der vom anderen Gerät verwendeten Bilddauer.
2. Die vom ersten Gerät verwendete Rahmendauer ist nicht ein exaktes Vielfaches der vom anderen Gerät verwendeten Rahmendauer.

In der ersten Situation ist die Beziehung zwischen der größeren und der kleineren Rahmendauer einfach, und die Umwandlung von Daten zwischen den beiden ist ein unkomplizierter Vorgang. Daten, die in der Nutzlast einer oder mehrerer erforderlicher Link-Layer-PDUs gesendet werden, gelten als rahmenlos und enthalten keine zusätzlichen Daten zur Unterstützung der Anpassung der Rahmendauer zwischen den beiden Anforderungen.

Im zweiten Fall können Link-Layer-PDUs Teile der größeren Nutzlast zusammen mit kurzen Header-Feldern enthalten, die anzeigen, ob ein Teil der Beginn eines Rahmens, eine Fortsetzung oder das Ende eines Rahmens ist. Auf diese Weise formatierte Daten werden als Frames bezeichnet.

Sowohl Connected Isochronous PDUs als auch Broadcast Isochronous PDUs (definiert durch die Verbindungsschicht) enthalten ein Feld namens LLID. LLID zeigt an, ob die Nutzlast der Link-Layer-PDU gerahmte oder ungerahmte Daten enthält. Je nachdem, ob die Daten gerahmt oder ungerahmt sind, wendet ISOAL auf die Daten, die es von der Sicherungsschicht erhält, unterschiedliche Verfahren an. In ähnlicher Weise wirkt sich die Frage, ob Framing erforderlich ist oder nicht, auf die ISOAL-Verarbeitung von Daten aus, die es in SDUs der oberen Schicht empfängt und zur Übertragung in ISO-PDUs der Sicherungsschicht an die Sicherungsschicht weitergibt.

9.3 Fragmentierung und Rekombination

Sind die Daten rahmenlos, wird durch Rekombination eine einzelne Dienstdateneinheit (SDU) aus einer Reihe von einem oder mehreren Fragmenten erstellt, die in der Nutzlast einer oder mehrerer PDUs der Verbindungsschicht enthalten sind. Der ISOAL leitet dann die SDU an die obere Schicht weiter. Dies ist in Abbildung 57 dargestellt.

Abbildung 57 - Rekombination von ungerahmten ISO-PDUs

Wenn SDUs der oberen Schicht für die Übertragung in PDUs der Verbindungsschicht in kleinere Nutzdaten aufgeteilt werden müssen und kein Framing erforderlich ist, wird dieser Vorgang als Fragmentierung bezeichnet. Dies ist in Abbildung 58 dargestellt.

Abbildung 58 - Fragmentierung erzeugt ungerahmte ISO-PDUs

Unframed PDUs haben einen Header, der Felder enthält, die anzeigen, dass die folgenden Daten entweder der Beginn einer SDU, die Fortsetzung der vorherigen SDU oder das Ende dieser SDU sind. PDUs enthalten immer nur ein einziges Fragment einer ungerahmten SDU.

9.4 Segmentierung und Wiederzusammenbau

Wenn die Daten gerahmt sind, wird durch die Neuzusammensetzung eine einzelne Dienstdateneinheit (SDU) aus einer Reihe von einem oder mehreren Segmenten in der Nutzlast einer oder mehrerer PDUs der Verbindungsschicht erstellt. Der ISOAL übergibt dann die SDU an die obere Schicht. Dies ist in Abbildung 59 dargestellt.

Abbildung 59 - Wiederzusammenbau von gerahmten ISO-PDUs

Wenn SDUs der oberen Schicht in kleinere Nutzdaten für die Übertragung in PDUs der Verbindungsschicht aufgeteilt werden müssen und ein Framing erforderlich ist, wird dieser Vorgang als Segmentierung bezeichnet. Dies ist in Abbildung 60 dargestellt.

Abbildung 60 - Segmentierung zur Erstellung von gerahmten ISO-PDUs

Segmente in gerahmten PDUs haben einen Header, der Felder enthält, die anzeigen, dass die folgenden Daten entweder der Beginn einer SDU, die Fortsetzung der vorherigen SDU oder das Ende dieser SDU sind, sowie Zeitversatzinformationen. PDUs können mehrere Fragmente einer gerahmten SDU enthalten.

10. DieController

10.1 Grundsätzliches

DieController (HCI) definiert eine standardisierte Schnittstelle, über die ein host Befehle an den controller erteilen kann und ein controller mit dem host kommunizieren kann. Die Spezifikation ist in mehrere Teile aufgeteilt, wobei der erste Teil die Schnittstelle nur in funktionaler Hinsicht definiert, ohne Rücksicht auf spezifische Implementierungsmechanismen, und die anderen Teile definieren, wie HCI bei Verwendung einer der vier möglichen physikalischen Transportarten implementiert werden kann.

HCI wird sowohl von Bluetooth LE als auch von Bluetooth BR/EDR verwendet.

10.2 Die HCI-Funktionsspezifikation

Die funktionale Schnittstelle wird in Form von Befehlen und Ereignissen definiert . Dabei handelt es sich im Wesentlichen um Nachrichten, die zwischen host und Steuerung ausgetauscht werden können. Befehle werden vom host an die Steuerung gesendet und Ereignisse von der Steuerung an den host. Ein Ereignis kann eine Antwort auf einen Befehl sein oder durch eine unaufgeforderte Nachricht gesendet werden. Siehe Abbildung 61.

Abbildung 61 - HCI-Befehle und Ereignisse

10.3 HCI-Transporte

Die vier HCI-Transportarten sind:

1. UART
2. USB
3. Sicher Digital (SD)
4. Dreidraht-UART

10.3.1 UART-Transport

Der HCI-UART-Transport kann zur Implementierung der HCI-Kommunikation über UART verwendet werden, wenn sowohl der host als auch der controller über UART auf derselben Leiterplatte angeschlossen sind. Es wird ein Protokoll definiert, das auf 5 Pakettypen basiert. Dabei handelt es sich um das HCI-Befehlspaket, das HCI-ACL-Datenpaket, das HCI-Synchrondatenpaket, das HCI-Ereignispaket und das HCI-ISO-Datenpaket.

Die Anforderungen an die RS232-Konfiguration sind festgelegt. Zusammenfassend lässt sich sagen, dass der UART-Transport 8 Datenbits, keine Parität, 1 Stoppbit und RTS/CTS-Flusskontrolle verwendet.

10.3.2 USB-Transport

USB kann auf zwei Arten als HCI-Transportmittel verwendet werden. Dercontroller kann in einem USB-Dongle implementiert werden. Alternativ kann USB auch intern in einem product verwendet werden, um host und controller zu verbinden.

Der USB-Standard definiert Puffer, in die Daten gesendet oder von denen sie empfangen werden können, sogenannte Endpunkte. Die HCI-USB-Transport-Spezifikation gibt die erwarteten Endpunkte und ihre erforderlichen oder vorgeschlagenen Eigenschaften an.

10.3.3 Sicher digital

Ein Protokoll zur Verwendung mit dem HCI-SD-Transport wird von der Secure Digital Association (SDA) definiert und verwaltet. Der Abschnitt der Bluetooth über den HCI-SD-Transport besteht größtenteils aus Verweisen auf externe Spezifikationen der SDA sowie aus einem Überblick über die Kommunikationsarchitektur.

10.3.4 Dreidraht-UART

Die Spezifikation für den Dreidraht-UART-HCI-Transport beschreibt eine Architektur und ein Protokoll für die Kommunikation von HCI-Befehlen und -Ereignissen zwischen zwei dreidrahtverbundenen UARTs. Sie befasst sich mit Zuverlässigkeit, Datenintegrität, Verbindungsaufbau, Energieverwaltung und Hardwarekonfiguration.

10.4 HCI-Beispiele

Es folgen eine Reihe von Beispielen, die die funktionale HCI-Schnittstelle in Aktion zeigen.

10.4.1 Verbindungslose AoA/AoD

Abbildung 62 zeigt den Austausch von HCI-Befehlen und -Ereignissen während der Konfiguration des Controllers durch den host , um die Übertragung von Paketen vorzubereiten, die die Peilung entweder nach dem Ankunftswinkel (AoA) oder dem Abfahrtswinkel (AoD) unterstützen.

Abbildung 62 - Verbindungslose controller

10.4.2 LE-Pfadverlust-Überwachung

Die Überwachung des LE-Pfadverlustes ist Teil der LE-Leistungssteuerung. Ein Gerät, das die von einem angeschlossenen Peer-Gerät verwendete Sendeleistung verwalten möchte, um sie innerhalb des optimalen Leistungsbereichs für den Empfänger zu halten, könnte diese Funktion nutzen.

Abbildung 63 zeigt einen host , der die HCI-Befehle sendet, die zur Konfiguration und anschließenden Aktivierung der LE-Pfadverlustüberwachung erforderlich sind. Nachdem die Überwachung aktiviert wurde, sendet der Controller LE Path Loss Threshold-Ereignisse mit Pfadverlustdaten an den host.

Abbildung 63 - LE-Pfadverlustüberwachung

10.4.3 Aktives Scannen

Aktives Scannen wird von Peripheriegeräten unterstützt, die Legacy-Werbung verwenden und mehr Daten übermitteln müssen, als in einem einzigen Werbepaket enthalten sein können. Weitere Informationen zu diesem Thema finden Sie in Abschnitt 14.3 Discovery.

Abbildung 64 zeigt die host in einem Gerät(Gerät A), das seinen Controller für aktives Scanning konfiguriert und dann mit einem separaten Befehl das Scanning durch Aktivierung einleitet. Wenn abfragbare Werbepakete wie ADV_IND von einem anderen Gerät durch die Verbindungsschicht von Gerät A empfangen werden, antwortet es, weil es für aktives Scannen konfiguriert wurde, indem es eine SCAN_REQ PDU sendet und eine SCAN_RSP PDU vom anderen Gerät zurückerhält. Der Inhalt des ursprünglichen Werbepakets und die Scan-Antwort werden dann in einer Reihe von HCI LE Advertising Report-Ereignissen an den Host von Gerät A weitergeleitet.

Abbildung 64 - Aktives Scannen

11. Das Logical Link Control and Adaptation Protocol

11.1 Grundsätzliches

Das Logical Link Control and Adaptation Protocol (L2CAP) ist für das Protokollmultiplexing, die Flusskontrolle sowie die Segmentierung und den Wiederzusammenbau von Dienstdateneinheiten (SDUs) zuständig.

L2CAP verwendet das Konzept des Kanals, um Sequenzen von Paketen zu trennen, die zwischen den Schichten des Stacks übertragen werden. Feste Kanäle erfordern keine Einrichtung, sind sofort verfügbar und werden einem bestimmten Protokoll der höheren Schicht zugeordnet. Kanäle können auch dynamisch erstellt und über einen bestimmten PSM-Wert (Protocol Service Multiplexer) mit einem Protokoll verbunden werden.

In Abbildung 65 sind die primären L2CAP-Funktionen dargestellt.

Abbildung 65 - L2CAP-Primärfunktionen

11.2 L2CAP und Protokoll-Multiplexing

Oberhalb von L2CAP im Stack befinden sich Schichten, die unterschiedliche Protokolle wie das Attributprotokoll (ATT) und das Sicherheitsmanagerprotokoll (SMP) verwenden. Das L2CAP-Protokollmultiplexing stellt sicher, dass SDUs im Stack an die entsprechende Schicht zur Verarbeitung weitergeleitet werden.

Wenn ein L2CAP-Kanal das Attributprotokoll abwickelt, verwendet er entweder einen festen Kanal, der für ATT reserviert ist und in diesem Fall als nicht erweiterter ATT-Träger fungiert, oder er verwendet eine Reihe von einem oder mehreren dynamischen Kanälen, die jeweils als erweiterter ATT-Träger fungieren. Der nicht erweiterte ATT-Träger unterstützt ATT-Transaktionen, die nacheinander ausgeführt werden, eine nach der anderen. Der erweiterte ATT-Träger unterstützt parallele ATT-Transaktionen, die sequentiell innerhalb paralleler L2CAP-Kanäle ausgeführt werden. Siehe 12. Das Attributprotokoll für weitere Einzelheiten hierzu.

11.3 L2CAP und Flusskontrolle

Bei der Flusskontrolle geht es darum, sicherzustellen, dass die Geschwindigkeit, mit der Pakete von einer Schicht eines Stapels erzeugt werden, nicht die Geschwindigkeit übersteigt, mit der eine Schicht im selben Stapel oder auf einem entfernten Gerät diese Pakete verarbeitet. Ohne Flusskontrolle besteht die Gefahr von Problemen wie Pufferüberläufen.

Die kreditbasierte Flusskontrolle ist einer von vielen möglichen Ansätzen zur Flusskontrolle. In groben Zügen funktioniert sie wie folgt:

• Das sendende Gerät kennt die Kapazität des empfangenden Geräts, d. h. die Anzahl der PDUs, die es verarbeiten kann, ohne dass Daten verloren gehen (z. B. weil der Puffer überläuft). Es erhält diese Kapazitätsinformationen durch die Konfiguration oder durch einen Austausch zwischen den beiden Geräten, bevor die Datenübertragung beginnt.
• Der Sender setzt einen Zähler auf die Kapazitätsgrenze des Empfängers. Jedes Mal, wenn eine PDU vom Sender gesendet wird, wird der Zähler dekrementiert. Wenn der Zählerwert Null erreicht, weiß der Sender, dass die Kapazität des Empfängers ausgeschöpft ist, und stoppt daher vorübergehend das Senden weiterer PDUs, während der Empfänger seinen Rückstand abarbeitet.
• Nachdem der Empfänger eine oder mehrere PDUs aus seinem Puffer gelesen und verarbeitet hat, sendet er eine entsprechende Anzahl von Credits an den Sender zurück, der damit seinen Zähler inkrementiert. Wenn der Zähler einen Wert ungleich Null hat, kann der Sender weitere PDUs senden.

L2CAP definiert mehrere Betriebsmodi, die sich hauptsächlich auf die Flusskontrolle beziehen.

ATT über einen nicht erweiterten L2CAP-Träger verwendet beispielsweise den einfachen L2CAP-Modus, der keine Flusskontrolle bietet. Dies macht ATT unzuverlässig, und die Anwendungen müssen die Möglichkeit in Betracht ziehen, dass übertragene ATT-PDUs vom empfangenden Gerät verloren gehen können. Im Falle von unbestätigten PDUs, wie z. B. Benachrichtigungen, weiß das sendende Gerät dank der Bestätigungen auf der Verbindungsschicht, ob die PDU vom Stack auf dem entfernten Gerät empfangen wurde oder nicht, hat aber keine Möglichkeit zu erfahren, ob die PDU erfolgreich an die empfangende Anwendung am oberen Ende des Stacks übermittelt wurde. 

ATT über einen L2CAP-erweiterten ATT-Träger verwendet den Enhanced Credit Based Flow Control Mode, der eine Flusskontrolle bietet. EATT kann daher als zuverlässig angesehen werden.

11.4 L2CAP-Segmentierung und Neuzusammensetzung

Für Schichten oberhalb und unterhalb von L2CAP gilt eine MTU-Größe (Maximum Transmission Unit), die angibt, wie groß eine PDU des Typs sein darf, der von dieser Schicht erstellt wird. Der ATT_MTU-Parameter definiert beispielsweise die maximale Größe, die eine ATT-PDU haben darf.

L2CAP selbst und die darüber oder darunter liegenden Schichten können unterschiedliche MTU-Größen haben, so dass es erforderlich sein kann, einige PDUs/SDUs in eine Reihe kleinerer Teile aufzuteilen, die die benachbarte Schicht verarbeiten kann, oder umgekehrt eine Reihe zusammengehöriger kleinerer Teile wieder zu vollständigen PDUs/SDUs zusammenzufügen. Diese Prozesse, wie sie von L2CAP in Bezug auf die oberen Schichten angewandt werden, werden als Segmentierung und Reassemblierung bezeichnet, während die entsprechenden Prozesse, wie sie sich auf L2CAP und seine Beziehung zu den unteren Schichten beziehen, als Fragmentierung und Rekombination bezeichnet werden.

12. Das Attributprotokoll

12.1 Grundsätzliches

Das Attributprotokoll (ATT) wird von zwei Geräten verwendet, von denen eines die Rolle des Clients und das andere die des Servers übernimmt. Der Server stellt eine Reihe von zusammengesetzten Datenelementen zur Verfügung, die als Attribute bezeichnet werden. Die Attribute werden vom Server in einer indizierten Liste, der Attributtabelle, organisiert.

Jedes Attribut enthält einen Handle, einen Universally Unique Identifier (UUID), einen Wert und eine Reihe von Berechtigungen.

• Der Handle ist ein eindeutiger Indexwert, mit dem ein ATT-Client auf einen bestimmten Eintrag in der Attributtabelle verweisen kann.
• Die UUID identifiziert den Typ des Attributs.
• Das Berechtigungsfeld besteht aus einer Reihe von Flags, die angeben, ob der Zugriff lesend, schreibend oder in beiden Formen erlaubt ist, sowie aus anderen Sicherheitsbedingungen, die erfüllt sein müssen, damit der Zugriff erlaubt ist.
• Das Studienhandbuch von Bluetooth SIG Verstehen der Sicherheit in Bluetooth LE enthält weitere Informationen über Attributberechtigungen.
• Das Attributwertfeld ist ein Byte-Array, das den Wert des Attributs enthält. Die Interpretation des Byte-Arrays sowohl in Bezug auf die Datentypen als auch auf die Semantik ist Sache der höheren Schichten des Stacks.

Das Generic Attribute Profile (GATT) definiert, wie Attribute Konstrukte höherer Ebene, bekannt als Dienste, Merkmale und Deskriptoren, darstellen können. Typischerweise wird eine Gruppe von Attributen in einem zusammenhängenden Handle-Wertebereich benötigt, um komplexere Typen wie diese zu repräsentieren, und das Attributprotokoll unterstützt aus diesem Grund die Arbeit mit Gruppen von Attributen, die durch einen Handle-Wertebereich identifiziert werden. Siehe Abschnitt 13. Das generische Attributprofil für weitere Informationen hierzu.

ATT wird von einem ATT-Client verwendet, um Einzelheiten der Attributtabelle in einem ATT-Server zu ermitteln, einschließlich der Handle-Werte von Attributen oder Attributtypen von Interesse. Wenn die Handle-Werte bekannt sind, können sie mit einigen PDU-Typen verwendet werden, um bestimmte Attribute in der Tabelle zu identifizieren und dann auf sie einzuwirken. Zum Beispiel kann das ATT_READ_BY_GROUP_TYPE_REQ PDU verwendet werden, um das Handle und die UUID aller Attribute zu finden, die Teil der Definition eines Primärdienstes sind. Eine kürzere Formulierung ist, dass die ATT_READ_BY_GROUP_TYPE_REQ PDU verwendet werden kann, um alle GATT-Primärdienste zu finden, die z.B. durch die Attributtabelle definiert sind.

Bei der Verwendung von PDUs wie ATT_READ_BY_GROUP_TYPE_REQ, die Discovery-Operationen unterstützen, wird ein Handle-Bereich angegeben, der die Teilmenge der zu durchsuchenden Einträge in der Attributtabelle (und das kann die gesamte Tabelle sein) und einen Attributtyp angibt, nach dem gesucht werden soll. Abbildung 66 veranschaulicht diesen Vorgang, wobei alle Primärdienste gesucht werden und die Antwort den Bereich der Handle-Werte angibt, der Attribute enthält, die sich auf den gefundenen Primärdienst beziehen.

Abbildung 66 - Anfrage und Antwort zum Lesen nach Gruppentyp

ATT ist einer der primären Mechanismen, über den Anwendungen in verbundenen Bluetooth LE miteinander interagieren. Dabei werden die vom Protokoll definierten PDUs und Verfahren verwendet, die in Spezifikationen auf höherer Ebene, wie dem Generic Attribute Profile (GATT), festgelegt sind.

Zwei Varianten des ATT sind definiert, das Basis-ATT und das neuere Enhanced Attribute Protocol (EATT).

ATT kann sowohl von Bluetooth LE als auch von Bluetooth BR/EDR verwendet werden. In diesem Dokument wird nur ATT in Verbindung mit Bluetooth LE betrachtet.

12.2 ATT PDUs

Das Attributprotokoll definiert 31 verschiedene PDUs, die jeweils auf einer von sechs allgemeinen Methoden beruhen.

12.2.1 Befehle

Eine ATT-Befehls-PDU wird von einem Client an einen Server gesendet, ohne dass eine Antwort vom Server angefordert wird. Ein Beispiel für einen Befehl ist der in Abbildung 67 dargestellte ATT_WRITE_CMD.

Abbildung 67 - ATT_WRITE_CMD

12.2.2 Ersuchen und Antworten

Eine ATT-Anfrage-PDU wird von einem Client an einen Server gesendet. Vom Server wird erwartet, dass er innerhalb von 30 Sekunden mit einer Antwort-PDU des entsprechenden Typs oder mit einer Fehlerantwort-PDU (ATT_ERROR_RSP) antwortet. Wird nicht innerhalb von 30 Sekunden geantwortet, gilt dies als Zeitüberschreitung.

Ein Beispiel für ein PDU-Paar aus Anfrage und Antwort sind die in Abbildung 68 dargestellten PDUs ATT_WRITE_REQ und ATT_WRITE_RSP.

Abbildung 68 - ATT_WRITE_REQ

12.2.3 Benachrichtigungen

Benachrichtigungen sind unaufgeforderte PDUs vom Typ ATT_HANDLE_VALUE_NTF, die von einem Server an einen Client gesendet werden. Es ist keine Antwort-PDU definiert. Siehe Abbildung 69.

Abbildung 69 - ATT_HANDLE_VALUE_NTF

12.2.4 Hinweise und Bestätigungen

Eine ATT Indication PDU wird von einem Server an einen Client gesendet. Vom Client wird erwartet, dass er innerhalb von 30 Sekunden mit einer Bestätigungs-PDU eines entsprechenden Typs oder mit einer Fehlerantwort-PDU (ATT_ERROR_RSP) antwortet. Erfolgt die Antwort nicht innerhalb von 30 Sekunden, gilt dies als Zeitüberschreitung.

Ein Beispiel für ein PDU-Paar aus Anzeige und Bestätigung sind die PDUs ATT_HANDLE_VALUE_IND und ATT_HANDLE_VALUE_CFM, die in Abbildung 70 - Anzeigen und Bestätigungen dargestellt sind.

Abbildung 70 - Anzeigen und Bestätigungen

12.2.5 PDU-Format

Alle ATT-PDUs haben die gleiche Struktur, bestehend aus einem Opcode, der den PDU-Typ identifiziert, einer Reihe von Parametern und einer optionalen Authentifizierungssignatur. Es ist zu beachten, dass das Signaturfeld nur selten verwendet wird und überflüssig ist, wenn das Attributprotokoll über eine verschlüsselte Verbindung läuft, da alle verschlüsselten Pakete auf der Verbindungsschicht Authentifizierungsdaten enthalten.

12.2.6 Maximale Übertragungseinheit

Die maximale Länge einer ATT-PDU hängt von dem festgelegten MTU-Wert (Maximum Transmission Unit) ab. Je nachdem, welcher Träger[11] für ATT verwendet wird, kann einer von zwei Mechanismen zur Festlegung der MTU verwendet werden.

12.3 Vorgänge

ATT definiert das Konzept einer Transaktion. Von einem Client angeforderte PDUs werden vom Server innerhalb von 30 Sekunden mit einer Antwort-PDU beantwortet. Von einem Server gesendete Indikationen müssen vom Client innerhalb von 30 Sekunden mit einer Bestätigungs-PDU beantwortet werden. Jedes Anfrage/Antwort-Paar oder Anzeige/Bestätigung-Paar bildet eine Transaktion. Wenn eine Transaktion eine Zeitüberschreitung aufweist, gilt sie als gescheitert und es dürfen keine weiteren PDUs irgendeiner Art über den aktuellen Träger gesendet werden.

ATT verwendet ein sequentielles Transaktionsmodell. Das bedeutet, dass, wenn eine ATT-Transaktion gestartet wurde, keine weiteren ATT-PDUs durch dieselbe Trägerinstanz verarbeitet werden dürfen, bis die aktuelle Transaktion abgeschlossen ist. Die Transaktion gilt als abgeschlossen, wenn die erwartete Antwort- oder Bestätigungs-PDU von dem entfernten Gerät empfangen wurde oder wenn die Transaktion nach einer Wartezeit von 30 Sekunden abgelaufen ist.

12.4 Träger

ATT wird von der darunter liegenden L2CAP-Schicht auf eine von zwei Arten gehandhabt, die jeweils als Bearer bezeichnet werden. Die beiden ATT-Bearer sind der Unenhanced ATT-Bearer und der Enhanced ATT-Bearer. Welcher Träger verwendet wird, hat Auswirkungen auf die Art und Weise, in der ATT verwendet werden kann, und in einigen Fällen auf die Zuverlässigkeit des Protokolls. Das generische Attributprofil befasst sich mit der Verwendung von ATT und besagt zum Beispiel, dass:

Der unverbesserliche ATT-Träger

• Verwendet einen festen L2CAP-Kanal, daher darf es nur eine Instanz dieses Trägers geben.
• Transaktionen sind streng sequentiell, unabhängig davon, wie viele Clients auf der Anwendungsschicht ATT verwenden. Dies kann bedeuten, dass eine von einer Anwendung eingeleitete Transaktion Transaktionen verzögern kann, die eine andere Anwendung starten möchte.
• Die PDUs ATT_EXCHANGE_MTU_REQ und ATT_EXCHANGE_MTU_RSP können ausgetauscht werden, um die Wahl der ATT-MTU zu beeinflussen, die über den unverstärkten ATT-Träger verwendet werden soll.
• Alle von einem Client empfangenen Meldungen, die aufgrund von Problemen wie Pufferüberlauf nicht verarbeitet werden können, werden verworfen. Daher gilt die ATT_HANDLE_VALUE_NTF-PDU als unzuverlässig, wenn sie über den Unenhanced ATT-Bearer verwendet wird.
• Die Unterstützung einiger PDU-Typen wie ATT_MULTIPLE_HANDLE_VALUE_NTF, ATT_READ_MULTIPLE_VARIABLE_REQ und ATT_READ_MULTIPLE_VARIABLE_RSP ist bei Verwendung des Unenhanced ATT bearer optional.
• Der L2CAP-Kanal, der den Unenhanced ATT-Träger unterstützt, kann unverschlüsselt oder verschlüsselt sein.

Der Enhanced ATT-Träger

• Verwendet dynamische L2CAP-Kanäle und mehrere Kanäle und damit mehrere Trägerinstanzen sind zulässig.
• Die Transaktionen werden sequentiell, aber pro Träger, abgewickelt. Daher sind innerhalb eines Stapels parallele Transaktionen möglich, die jeweils von einer separaten Enhanced ATT-Trägerinstanz abgewickelt werden. Dies hat offensichtliche Vorteile, da die Möglichkeit vermieden wird, dass die Nutzung von ATT durch eine Anwendung von einer anderen blockiert wird.
• ATT MTU wird automatisch auf den MTU-Wert gesetzt, der auf der L2CAP-Schicht verwendet wird, und die ATT_EXCHANGE_MTU_REQ- und ATT_EXCHANGE_MTU_RSP-PDUs sind über einen Enhanced ATT-Träger nicht zulässig.
• Eine L2CAP-Flusskontrollmethode namens Enhanced Credit Based Flow Control Mode wird mit dem Enhanced ATT-Bearer verwendet. Dies hat zur Folge, dass PDUs, die bei der Verwendung über den Unenhanced ATT-Bearer unzuverlässig sind, bei der Verwendung eines Enhanced ATT-Bearer als zuverlässig angesehen werden können.
• Die Unterstützung einiger PDUs wie ATT_MULTIPLE_HANDLE_VALUE_NTF, ATT_READ_MULTIPLE_VARIABLE_REQ und ATT_READ_MULTIPLE_VARIABLE_RSP ist bei Verwendung des erweiterten ATT-Trägers obligatorisch.
• Der L2CAP-Kanal, der den Enhanced ATT-Träger unterstützt, muss ein verschlüsselter Kanal sein.

12.5 Entdeckung der Unterstützung für EATT

Der definierte generische Attributprofildienst ermöglicht es einem Client, festzustellen, ob ein verbundener Server EATT unterstützt oder nicht, und umgekehrt dem Client zu ermöglichen, den Server darüber zu informieren, dass er EATT unterstützt.

Ein Merkmal namens Server Supported Features muss in den Dienst Generic Attribute Profile aufgenommen werden, wenn EATT vom Server unterstützt wird. Bit 0 des ersten Oktetts des Wertes dieses Merkmals auf 1 gesetzt bedeutet, dass EATT unterstützt wird. Ein GATT/ATT-Client kann durch Auslesen dieses Merkmals feststellen, ob der Server EATT unterstützt oder nicht.

Der Merkmalswert Client Supported Features besteht aus Bits, die anzeigen, ob bestimmte Merkmale unterstützt werden oder nicht. Bit 1 zeigt an, ob der Enhanced ATT Bearer vom Client unterstützt wird oder nicht. Bit 2 zeigt an, ob die ATT_MULTIPLE_HANDLE_VALUE_NTF PDU unterstützt wird oder nicht. Der Client muss einen entsprechenden Wert in dieses Merkmal schreiben, um dem Server mitzuteilen, welche Merkmale er unterstützt.

Abbildung 71 - Erkennung der EATT-Funktionsunterstützung

13. Das generische Attributprofil

13.1 Grundsätzliches

Das generische Attributprofil (GATT) definiert Datentypen höherer Ebene, die auf den in der Attributtabelle enthaltenen Attributen basieren (siehe 12. Das Attributprotokoll). Diese Datentypen werden als Dienste, Merkmale und Deskriptoren bezeichnet. Es definiert auch eine Reihe von Verfahren zur Verwendung dieser Datentypen über das Attributprotokoll (ATT). Anwendungen verwenden in der Regel Plattform-APIs, die auf diese Prozeduren abgebildet werden.

Dienste sind Gruppierungsmechanismen, die einen Kontext für die Nutzung der in ihnen enthaltenen Merkmale bieten und einen definierten Typ haben. Häufig entsprechen Dienste einem primären Merkmal oder einer Fähigkeit eines Geräts.

Merkmale sind einzelne Elemente von Zustandsdaten und haben einen Typ, einen zugehörigen Wert und eine Reihe von Eigenschaften, die angeben, wie die Daten in Bezug auf Gruppen von verwandten GATT-Verfahren verwendet werden können. So kann beispielsweise festgelegt werden, dass ein angeschlossenes Peer-Gerät den Wert eines bestimmten Merkmals lesen, aber nicht in dieses Merkmal schreiben kann.

Merkmale gehören zu einer Dienstleistung. Ein und derselbe Merkmalstyp kann Mitglied von mehr als einem Dienst sein, und je nach den verschiedenen Kontexten, die diese Dienste bieten, können die Regeln für die Verwendung des Merkmals variieren. Eine Leistungsbeschreibung enthält diese Details.

Deskriptoren gehören zu einigen Merkmalen und können Metadaten wie eine textliche Beschreibung des Merkmals enthalten oder ein Mittel zur Steuerung des Verhaltens eines Merkmals darstellen. Merkmale haben null oder mehr Deskriptoren, die ihnen zugeordnet sind. Zum Beispiel definiert GATT eine Operation namens Merkmalswert-Benachrichtigung, die beinhaltet, dass ein Gerät eine ATT PDU mit einem Merkmalswert asynchron an den verbundenen Peer sendet, ohne eine Antwort vom anderen Gerät zu verlangen. Wenn ein Merkmal Benachrichtigungen unterstützt, werden diese typischerweise entweder bei Änderung des Merkmalswertes oder periodisch, gesteuert durch einen Timer, gesendet. Dies geschieht durch das Setzen einer Markierung in einem bestimmten Deskriptortyp, dem Client Characteristic Configuration Deskriptor, den das Merkmal haben muss, wenn es Meldungen unterstützt.

Die hierarchische Struktur der Dienste, Merkmale und Deskriptoren ist in Abbildung 72 dargestellt.

Abbildung 72 - Dienstleistungen, Merkmale und Deskriptoren

GATT definiert zwei Rollen. Der GATT-Client sendet ATT-Befehle und -Anfragen an den GATT-Server. Der GATT-Server akzeptiert und verarbeitet die von einem GATT-Client empfangenen Befehle und Anfragen und sendet dem GATT-Client ATT-Benachrichtigungen, Hinweise und Antworten.

Zwei spezielle Dienste sind in allen GATT-Servern obligatorisch. Dies sind der generische Zugriffsdienst und der generische Attributdienst.

13.2 Bluetooth SIG vs. Benutzerdefiniert

Einige Dienste, Merkmale und Deskriptoren werden von der Bluetooth SIG definiert und haben 16-Bit-UUID-Werte, die ihren Typ identifizieren. Die Bluetooth SIG der einzelnen definierten Typen ist unter specifications/assigned-numbers verfügbar. Implementierer können 16-Bit-UUIDs und andere Arten von zugewiesenen Nummern erwerben, wie unter https://support.bluetooth.com/hc/en-us/articles/360062030092-Requesting-Assigned-Numbers beschrieben .

Ein Implementierer kann benutzerdefinierte Dienste, Merkmale und Deskriptoren definieren. Benutzerdefinierte Dienste, Merkmale und Deskriptoren können entweder durch vom Implementierer zugewiesene 128-Bit-UUID-Werte identifiziert werden oder der Implementierer kann 16-Bit-UUID-Werte von der Bluetooth SIG erwerben. 16-Bit-UUIDs haben auch einen entsprechenden 128-Bit-Wert in der Form 0000XXXX-0000-1000-8000-00805F9B34FB, wobei XXXX der 16-Bit-UUID-Wert ist. Implementierer dürfen keine UUIDs in diesem Bereich verwenden, es sei denn, eine UUID wurde von der Bluetooth SIG erworben.

Ein GATT-Server kann nur von Bluetooth SIG definierte Dienste, Merkmale und Deskriptoren (Attribute) oder eine Mischung aus von Bluetooth SIG definierten Attributen und eigenen Attributen enthalten.

13.3 Verfahren

GATT-Prozeduren, die u.a. die Entdeckung von Diensten, die Entdeckung von Merkmalen, die Entdeckung von Deskriptoren, das Lesen und Schreiben von Merkmalswerten und die Benachrichtigung und Anzeige von Merkmalswerten abdecken, sind definiert. Die GATT-Spezifikation bietet eine klare Zuordnung zwischen ihren Prozeduren und dem zugrunde liegenden ATT-Protokoll, das diese Prozeduren verwenden müssen.

13.4 Beispiele

13.4.1 Bluetooth SIG nur definierte Attribute

Abbildung 73 zeigt ein Beispiel für einen Satz von Diensten mit ihren Merkmalen. Ein Merkmal hat einen zugehörigen Deskriptor. Jedes Attribut in diesem Beispiel wird von der Bluetooth SIG definiert.

Abbildung 73 - Ein Beispielsatz von Diensten, Merkmalen und Deskriptoren

Die dargestellten Dienste sind diejenigen, die ein Gerät, das das Standard-Näherungsprofil implementiert, wahrscheinlich haben würde (die Dienste Sofortalarm und Sendeleistung sind nicht obligatorisch). Beachten Sie, dass das Merkmal " Alarmstufe" zweimal vorkommt, einmal im Dienst " Verlust der Verbindung" und einmal im Dienst " Sofortige Alarmierung ". Die UUID ist in beiden Fällen die gleiche. Dadurch wird das Merkmal als Alarmstufenmerkmal identifiziert. Der Dienst, in dem das Merkmal gruppiert ist, bietet jedoch einen anderen Kontext, und die Regeln und das Verhalten in Bezug auf das Merkmal " Alarmstufe" unterscheiden sich in den beiden Diensten.

Das Merkmal " Service geändert" hat einen zugehörigen Konfigurationsdeskriptor für das Merkmal "Kunde", da das Merkmal Meldungen unterstützt. Jedes Merkmal, das Benachrichtigungen oder Hinweise unterstützt, muss einen Konfigurationsdeskriptor für das Kundenmerkmal haben, da sein Wert (in den die Kunden schreiben können) steuert, ob Benachrichtigungen oder Hinweise derzeit aktiviert sind oder nicht. 

13.4.2 Mischung aus Bluetooth SIG und benutzerdefinierten Attributen

Abbildung 74 zeigt einen GATT-Server mit einer Mischung aus GATT-Attributen, die von der Bluetooth SIG definiert wurden, und einem einzigen benutzerdefinierten Dienst, der ein einziges benutzerdefiniertes Merkmal enthält. Der benutzerdefinierte Dienst heißt Proximity Monitoring Service und hat einen UUID-Type Identifier Wert von 0x 3E099910-293F-11E4-93BD-AFD0FE6D1DFD. Sein Merkmal heißt Client Proximity characteristic und hat den UUID-Wert 0x 3E099911-293F-11E4-93BD-AFD0FE6D1DFD. Beachten Sie, dass dieser Dienst und dieses Merkmal in der Projektarbeit in der pädagogischen Entwicklerressource An Introduction to Bluetooth Low Energy Development verwendet werden. Siehe 18. Zusätzliche Ressourcen für weitere Details.

Abbildung 74 - Eine Mischung aus von Bluetooth SIG definierten und benutzerdefinierten Attributen

14. Das allgemeine Zugangsprofil

14.1 Grundsätzliches

Der Abschnitt Generic Access Profile (GAP) der Bluetooth-Kernspezifikation definiert Verfahren zur Geräteerkennung und zum Verbindungsaufbau zwischen zwei Geräten. Die Durchführung der verbindungslosen Datenkommunikation im Allgemeinen, die Verwendung periodischer Werbung (siehe 7.8.3 PADVB - LE Periodic Advertising Broadcast) und die Einrichtung isochroner Kommunikation (siehe 7.8.5 LE BIS und LE CIS - Isochronous Communication) sind ebenfalls Themen, die von GAP abgedeckt werden.

Darüber hinaus werden in diesem Abschnitt der Kernspezifikation auch einige wichtige Standards für die Benutzeroberfläche und bestimmte Aspekte der Bluetooth LE behandelt.

Die Übertragung von Werbepaketen(Advertising) und deren Empfang durch Scanning ist der Kern der Funktionsweise von GAP. Es gibt verschiedene Arten von Werbe- und Scanning-Paketen, die von der Verbindungsschicht definiert werden. Es ist zu beachten, dass das Nutzdatenfeld AdvData heißt und nicht in allen PDU-Typen vorhanden ist. Wenn es vorhanden ist, werden die darin enthaltenen Daten als eine Reihe von einem oder mehreren Längen/Tag/Wert-Konstrukten kodiert, die als AD-Typen bekannt sind. AD-Typen sind im Dokument Core Specification Supplement (CSS) definiert, das auf der Spezifikationsseite unter bluetooth.com verfügbar ist.

GAP ist sowohl für Bluetooth LE als auch für Bluetooth BR/EDR von Bedeutung. Im weiteren Verlauf dieses Abschnitts wird nur GAP im Zusammenhang mit Bluetooth LE behandelt. Darüber hinaus ist anzumerken, dass Aktivitäten wie Werbung und Scanning zwar von zentraler Bedeutung für GAP sind, diese Verfahren jedoch tatsächlich von der Verbindungsschicht durchgeführt werden, ebenso wie die beteiligten PDU-Typen.

14.2 Rollen

GAP definiert vier Geräterollen. Diese sind in Tabelle 16 aufgeführt und erläutert.

Rolle	Beschreibung
Rundfunkveranstalter	Ein Gerät, das eine Form von Werbung verwendet, um Daten verbindungslos zu übertragen. Dazu gehören Legacy-Werbung, erweiterte Werbung und periodische Werbung. Ein Broadcaster kann auch einen isochronen Rundfunkstrom übertragen. Ein Broadcaster hat einen Sender, der Besitz eines Empfängers ist jedoch optional. Ein Broadcaster akzeptiert keine Verbindungen von zentralen Geräten (es sei denn, er agiert auch in der Rolle des Peripheriegeräts).
Beobachter	Ein Observer empfängt Werbepakete oder isochrone Broadcast-Datenpakete. Er stellt keine Verbindung zu anderen Geräten her, enthält einen Empfänger und kann, muss aber nicht, einen Sender enthalten. Der Observer ist in der Lage, Broadcast-Daten verbindungslos zu empfangen.
Peripherie	Ein Peripheriegerät kann mit einem Zentralgerät verbunden werden. Es enthält einen Sender und einen Empfänger.
Zentrale	Eine Zentrale ist in der Lage, den Aufbau einer Verbindung mit einem Peripheriegerät zu initiieren. Sie enthält sowohl einen Sender als auch einen Empfänger.

Tabelle 16 - GAP-Rollen

Beachten Sie, dass die Rollenbezeichnungen Central und Peripheral auch von der Verbindungsschicht verwendet werden. Die Begriffe in diesen beiden unterschiedlichen Kontexten bedeuten nicht dasselbe.

14.3 Entdeckung

Ein Broadcaster- oder Peripheriegerät befindet sich entweder im nicht auffindbaren Modus oder in einem der beiden auffindbaren Modi, die GAP definiert. Bei Werbung im nicht auffindbaren Modus sind die übertragenen Pakete über die Luft sichtbar (dies ist kein Sicherheitsmerkmal), aber Scan-Geräte, die entweder das allgemeine auffindbare Verfahren oder das begrenzte auffindbare Verfahren durchführen, ignorieren diese Pakete.

Ein auffindbares Gerät kann sich entweder im allgemeinen auffindbaren Modus oder im begrenzten auffindbaren Modus befinden. Im Modus der allgemeinen Auffindbarkeit ist ein Gerät für unbestimmte Zeit auffindbar, im Modus der eingeschränkten Auffindbarkeit für maximal drei Minuten.

Erkennende Geräte sind in der Lage zu erkennen, in welchem der erkennbaren Modi sich ein werbendes Gerät befindet, indem sie einen AD-Typ im AdvData-Feld namens Flags untersuchen. Der eingeschränkte Erkennungsmodus wird häufig verwendet, um Geräten Vorrang zu geben, mit denen der Benutzer kürzlich interagiert hat, z. B. durch Drücken einer Taste oder durch einfaches Aufnehmen und Bewegen des Geräts.

Wenn ein Zentral- oder Beobachtergerät versucht, andere Geräte zu finden, kann es entweder passives Scannen oder aktives Scannen verwenden. Welches der beiden Verfahren zulässig ist, hängt davon ab, ob das Gerät versucht, Geräte im allgemeinen Erkennungsmodus oder im eingeschränkten Erkennungsmodus zu erkennen.

Beim passiven Scanning werden Werbe-PDUs empfangen, ohne Scanning-PDUs zu senden. Beim aktiven Scanning werden Werbe-PDUs empfangen und als Antwort darauf weitere Informationen angefordert, indem Scanning-PDUs gesendet werden. Die verschiedenen PDU-Typen werden von der Verbindungsschicht definiert und sind in 7.8.2 ADVB - LE Advertising Broadcast zusammengefasst.

In der Bluetooth Core Spezifikation wird darauf hingewiesen, dass einige Geräte nur die herkömmliche Werbung verwenden, während andere die erweiterte Werbung nutzen oder beide Formen der Werbung miteinander verschachteln können. Es wird empfohlen, dass Geräte, die eine der Erkennungsprozeduren durchführen, das Scannen nach beiden Arten von Werbung verschachteln. Es wird auch empfohlen, dass ein Gerät auf allen von ihm unterstützten PHYs scannt.

Abbildung 75 zeigt die GAP-Erkennungsmodi in Verbindung mit anderen relevanten Variablen.

14.4 Verbindungsmodi

Ein werbendes Gerät kann entweder durch die verwendete PDU (Legacy-Advertising) oder durch den Wert des AdvMode-Feldes (Extended-Advertising) angeben, ob es für eine Verbindung zur Verfügung steht oder nicht.

Abbildung 75 zeigt die GAP-Verbindungsarten in Verbindung mit anderen relevanten Variablen.

Ein Gerät kann eine Verbindung mit einem anderen Gerät anfordern, indem es eine der von GAP definierten verbindungsbezogenen Prozeduren durchführt. Dazu wird im Allgemeinen entweder eine CONNECT_IND-PDU (Legacy Advertising) oder eine AUX_CONNEXT_REQ-PDU (Extended Advertising) als Antwort auf eine empfangene PDU eines von mehreren Typen, die dies erlauben, gesendet. Die Verbindungsschicht definiert die PDU-Typen für Werbung und Verbindungsanforderung sowie die Regeln für die PDU-Typen, auf die eine Verbindungsanforderung als Antwort gesendet werden kann. Siehe 7.8.2.2.3 Legacy Advertising und zugehörige PDU-Typen und 7.8.2.3.5 Extended Advertising und zugehörige PDU-Typen.

14.5 Gerichtet und ungerichtet

Werbung, wie sie von GAP verwendet wird, kann entweder ungerichtet sein, was bedeutet, dass PDUs für jedes Beobachter- oder Zentralgerät gelten, das sie empfängt, oder gerichtet, was bedeutet, dass nur ein bestimmtes Gerät solche PDUs verarbeiten sollte. PDUs mit gerichteter Werbung enthalten das Feld TargetA mit der Bluetooth-Adresse des vorgesehenen Empfängergeräts. Bei ungerichteter Werbung fehlt das TargetA-Feld.

Abbildung 75 zeigt gerichtete und ungerichtete Werbung im Zusammenhang mit der GAP-Erkennung und den Verbindungsmodi.

Abbildung 75 - GAP-Erkennung und Verbindungsmodi

Beachten Sie, dass die AD Type Flags in Legacy-Advertising-Paketen erscheinen, die auf dem primären Werbekanal empfangen werden. Wenn jedoch erweiterte Werbung verwendet wird, ist das AdvData-Feld in ADV_EXT_IND-PDUs, die auf den primären Kanälen empfangen werden, nicht vorhanden. Wenn Flags bei erweiterter Werbung verwendet wird, erscheint es in AUX_EXT_IND-PDUs auf den Allzweckkanälen.

14.6 Durchsuchbar vs. nicht durchsuchbar

Bestimmte Werbe-PDU-Typen gelten als abfragbar. Das bedeutet, dass ein Gerät, das eine solche PDU empfängt, mit einer Scan-Request-PDU eines geeigneten Typs antworten darf, um weitere Werbedaten anzufordern. Werbe-PDUs werden von der Verbindungsschicht definiert. Siehe 7.8.2.2.3 Legacy Advertising and Associated PDU Types und 7.8.2.3.5 Extended Advertising and Associated PDU Types für weitere Einzelheiten.

14.7 GAP und LE Sicherheit

Die GAP-Spezifikation definiert eine Reihe von Sicherheitsbegriffen, Modi und Verfahren. Im Allgemeinen beziehen die GAP-Sicherheitsverfahren andere Schichten des Stacks wie das Security Manager Protocol (SMP) und die Verbindungsschicht mit ein, aber das übergeordnete Verfahren für die Verwendung dieser Schichten zur Erzielung bestimmter Ergebnisse ist in Band 3 Teil C (Generic Access Profile) der Bluetooth Core Specification definiert, die für Einzelheiten konsultiert werden sollte.

14.8 Regelmäßige Werbung

Periodic Advertising (sowohl mit als auch ohne Antworten) wird von der Verbindungsschicht durchgeführt (siehe 7.8.3 PADVB - LE Periodic Advertising Broadcast), aber GAP spezifiziert das Verfahren für einen Broadcaster, um in den periodischen Werbemodus zu gelangen und für einen Observer, um sich mit einem periodischen Werbezug zu synchronisieren. Darüber hinaus ist in GAP das PAST-Verfahren (Periodic Advertising Synchronization Transfer) definiert, das es einem Beobachter ermöglicht, Parameter für die periodische Werbesynchronisation von einem Broadcaster zu erwerben und sie über eine ACL-Verbindung an ein anderes Gerät weiterzugeben.

14.9 Isochroner Rundfunk

Isochrone Kommunikation unter Verwendung von isochronen Broadcast-Streams und verbundenen isochronen Streams wird von der Verbindungsschicht durchgeführt (siehe 7.8.5 LE BIS und LE CIS - Isochrone Kommunikation), aber GAP spezifiziert die Verfahren, die ein Broadcaster und Observer befolgen müssen, um diese Form der Kommunikation durchzuführen.

15. Das Sicherheitsmanager-Protokoll

15.1 Grundsätzliches

Das Sicherheitsmanager-Protokoll (SMP) ist Teil der Sicherheitsmanager-Komponente des Stacks. Es unterstützt die Ausführung von sicherheitsrelevanten Prozeduren wie Pairing, Bonding und Schlüsselverteilung.

Die Komponente Sicherheitsmanager stellt eine kryptografische Toolbox für Sicherheitsfunktionen bereit, die andere Schichten nutzen können, und definiert Paarungsalgorithmen.

Abschnitt 16. Sicherheit in Bluetooth LE hat mehr über Sicherheit im Allgemeinen zu sagen.

15.2 Beispiel

Abbildung 76 zeigt die Verwendung von SMP bei der Kopplung zweier Geräte. Beachten Sie den Austausch von Eingangs-/Ausgangsfähigkeiten und anderen Flags während des SMP Pairing Feature Exchange. Dies ist ein wichtiger Schritt, der bestimmt, welcher Pairing-Algorithmus ausgewählt wird und wie Schritte wie die Authentifizierung und die Einbindung in das Verfahren erfolgen.

Abbildung 76 - SMP im Einsatz während der Kopplung

16. Sicherheit in Bluetooth LE

Sicherheit ist ein kritisches Thema, das sorgfältig bedacht und verstanden werden muss.

Bluetooth LE bietet eine Reihe von Sicherheitsfunktionen und -merkmalen, von denen die meisten optional sind. Sie sollten dies als einen Werkzeugkasten betrachten, der Sicherheitswerkzeuge enthält, mit denen bestimmte Sicherheitsprobleme angegangen und bestimmte Sicherheitsanforderungen erfüllt werden können. Es liegt in der Verantwortung des Produktteams, nachdem es die Sicherheitsanforderungen für ein Produkt ermittelt hat, diese Anforderungen zu erfüllen. Gegebenenfalls sollte dies durch die Verwendung ausgewählter Bluetooth LE Sicherheitsfunktionen erreicht werden.

Angesichts der Bedeutung dieses Themas wurde von der Bluetooth SIG eine Bildungsressource zu diesem Thema erstellt, deren Inhalt hier nicht wiederholt werden soll. Weitere Informationen finden Sie in Abschnitt 18. Zusätzliche Ressourcen für weitere Informationen.

17. Anwendungen

Die in den anderen Abschnitten beschriebenen Funktionen von Bluetooth LE werden letztendlich durch Anwendungen genutzt. Aber nicht alle Funktionen der neuesten Bluetooth Core Spezifikation werden notwendigerweise für Anwendungen verfügbar sein. Die Hauptgründe, warum dies der Fall ist, sind:

1. Es dauert seine Zeit, bis neue Funktionen der Bluetooth in Komponenten implementiert sind und in allgemein erhältlichen Produkten wie Computern, Smartphones usw. erscheinen.
2. Viele Bluetooth LE sind optional, und es liegt in der Entscheidung des Implementierers, welche Funktionen er einbezieht und welche er weglässt. Der Implementierer kann der Hersteller des Controller-Chips oder der Entwickler des Betriebssystems sein, das z. B. die Host enthält. Nur weil ein Gerät, für das eine Anwendung entwickelt werden soll, angibt, dass es eine bestimmte Version der Bluetooth-Kernspezifikation unterstützt, heißt das nicht unbedingt, dass es alle Funktionen dieser Version unterstützt.
3. Selbst wenn der Bluetooth eines Geräts eine bestimmte Funktion unterstützt, bedeutet dies nicht, dass sie den Anwendungsentwicklern zur Verfügung steht. Anwendungsentwickler arbeiten mit APIs und nicht direkt mit dem Stack. Wenn es keine API für eine Bluetooth gibt, kann sie von einer Anwendung nicht genutzt werden, selbst wenn dercontroller die Funktion unterstützt.

Die Lehre hieraus ist, dass man einige Nachforschungen anstellen sollte, bevor man sich an die Entwicklung einer Anwendung macht. Überprüfen Sie insbesondere die API-Dokumentation, um sicherzustellen, dass die benötigten Funktionen unterstützt werden, und überprüfen Sie die Spezifikation der Bluetooth der Hardware und des Betriebssystems, auf denen die Anwendung laufen soll.

18. Zusätzliche Ressourcen

In diesem Abschnitt werden weitere Ressourcen aufgeführt, die das Lernen über Bluetooth LE aus verschiedenen Perspektiven unterstützen.

Ressource	Beschreibung	Standort
Bluetooth Kernspezifikation	Die wichtigste technische Spezifikation. Definiert alle Schichten des Bluetooth-Stacks und die zugehörigen Protokolle und Verfahren. Deckt sowohl Bluetooth LE als auch Bluetooth BR/EDR ab.	Spezifikationen/specs/
Profil und Leistungsbeschreibung	Eine Dienstspezifikation definiert einen einzelnen GATT-Dienst zusammen mit den darin enthaltenen Merkmalen und Deskriptoren. Die Profilspezifikationen definieren die Rollen, die verbundene Geräte einnehmen, und legen insbesondere das Verhalten des Client-Geräts und die Daten auf dem verbundenen Server fest, mit denen es arbeiten soll.	Spezifikationen/specs/
LC3	Definiert den von LE Audio verwendeten Low Complexity Communication Codec.	Spezifikationen/specs/
Studienführer - Einführung in die Bluetooth Low Energy Entwicklung	Eine Bildungsressource für Entwickler, die etwas über Softwareentwicklung für verbindungsorientierte Szenarien mit Smartphones und Peripheriegeräten lernen möchten. Enthält eine Reihe praktischer Projekte mit Lösungen.	bluetooth-resources/bluetooth-le-developer-starter-kit/
Studienführer - Eine Einführung in die Entwicklung von Bluetooth Mesh Software	Eine Bildungsressource für Entwickler, die etwas über Bluetooth-Mesh und die Implementierung von Mesh-Modellen in Mikrocontrollern lernen möchten. Enthält eine Reihe praktischer Projekte mit Lösungen.	bluetooth-resources/bluetooth-mesh-developer-study-guide/
Studienführer - Einführung in die Bluetooth Mesh Proxy-Funktion	Ein Lehrmittel für Entwickler, die lernen möchten, wie man GUI-Anwendungen für Geräte wie Smartphones erstellt, die eine Interaktion mit Knoten in einem Bluetooth-Mesh-Netzwerk ermöglichen. Enthält eine Reihe praktischer Projekte mit Lösungen.	bluetooth-resources/bluetooth-mesh-proxy-kit/
Papier - Bluetooth Mesh Networking - Eine Einführung für Entwickler	Eine Bildungsressource für alle, die sich für die wichtigsten Konzepte und Funktionen von Bluetooth Mesh interessieren.	bluetooth-resources/bluetooth-mesh-networking-an-introduction-for-developers/
Papier - Bluetooth-Mesh-Modelle - ein technischer Überblick	Eine lehrreiche Ressource für alle, die sich für ein besseres Verständnis der Standardmodelle interessieren, die für die Verwendung in Bluetooth-Mesh-Produkten verfügbar sind.	bluetooth-resources/bluetooth-mesh-models/
Studienführer - Verständnis der Bluetooth LE	Ein Lehrmittel, das alle Aspekte der Sicherheit in Bluetooth LE (außer Bluetooth Mesh) erklärt und veranschaulicht. Es ist sowohl für absolute Neulinge im Bereich der Sicherheit als auch für Personen mit Vorkenntnissen geeignet. Enthält eine Reihe praktischer Projekte mit Lösungen.	bluetooth-resources/le-security-study-guide/
Papier - Leitfaden für bewährte Praktiken zu Bluetooth-Sicherheit und Datenschutz	Ein Leitfaden, der Implementierern helfen soll, besser zu verstehen, warum bestimmte verfügbare Sicherheits- und Datenschutzoptionen für bestimmte Anwendungen besser oder schlechter sind als andere und welche Risiken und Fallstricke in den Spezifikationen verbleiben.	bluetooth-resources/bluetooth-security-and-privacy-best-practices-guide/
Studienführer - Bluetooth-Technologie für Linux-Entwickler	Eine Bildungsressource für Linux-Entwickler, die etwas über die Entwicklung von Software lernen möchten, die den Linux-Bluetooth-Stack, BlueZ, verwendet. Enthält eine Reihe praktischer Projekte mit Lösungen.	bluetooth-resources/bluetooth-for-linux/
Studienführer - Entwurf und Entwicklung von Bluetooth Internet Gateways	Eine pädagogische Ressource, die Bluetooth-Internet-Gateways erklärt, die verwendet werden, um den Zugang zu Bluetooth LE und Bluetooth-Mesh-Geräten vom Internet aus zu ermöglichen. Veranschaulicht mögliche Architekturen und Implementierungsansätze. Enthält eine Reihe praktischer Projekte mit Lösungen.	bluetooth-resources/bluetooth-internet-gateways/
Studienführer - Eine Einführung in Web-Bluetooth	Ein Lehrmittel für Entwickler, die etwas über die Entwicklung von Webanwendungen lernen möchten, die die JavaScript Web Bluetooth APIs verwenden. Enthält eine Reihe praktischer Projekte mit Lösungen.	bluetooth-resources/web-bluetooth-tutorial/
Studienführer - Eine Einführung in Bluetooth Beacons	Eine Bildungsressource für Entwickler, die mehr über Bluetooth Beacons erfahren möchten. Enthält eine Reihe praktischer Projekte mit Lösungen.	bluetooth-resources/beacon-smart-starter-kit/
Papier - Bluetooth Core Spezifikation Version 5.0 Funktionserweiterungen	Erläutert die neuen Funktionen und andere Änderungen, die in Version 5.0 der Bluetooth Core Spezifikation veröffentlicht wurden. Beinhaltet den LE 2M PHY, LE Coded PHY und erweiterte Werbung.	bluetooth-resources/bluetooth-5-go-faster-go-further/
Papier - Bluetooth Core Spezifikation Version 5.1 Funktionsübersicht	Erläutert die neuen Funktionen und andere Änderungen, die in Version 5.1 der Bluetooth Core Spezifikation veröffentlicht wurden. Beinhaltet AoA und AoD Peilung.	bluetooth-resources/bluetooth-core-specification-v5-1-feature-overview/
Papier - Bluetooth Core Spezifikation Version 5.2 Funktionsübersicht	Erläutert die neuen Funktionen und andere Änderungen, die in Version 5.2 der Bluetooth Core Spezifikation veröffentlicht wurden. Beinhaltet das Enhanced Attribute Protocol, LE Power Control und LE Isochronous Channels.	bluetooth-resources/bluetooth-core-specification-version-5-2-feature-overview/
Papier - Bluetooth Core Spezifikation Version 5.3 Funktionsübersicht	Erläutert die neuen Funktionen und andere Änderungen, die in Version 5.3 der Bluetooth Core Spezifikation veröffentlicht wurden. Beinhaltet LE Enhanced Connection Update mit Subrating und LE Channel Classification.	bluetooth-resources/bluetooth-core-specification-version-5-3-feature-enhancements/
Bluetooth® Core Spezifikation Version 5.4 - Technischer Überblick	Erläutert die neuen Funktionen und andere Änderungen, die in Version 5.4 der Bluetooth Core Spezifikation veröffentlicht wurden. Beinhaltet periodische Werbung mit Antworten und verschlüsselte Werbedaten.	bluetooth-resources/bluetooth-core-specification-version-5-4-technical-overview/
Bluetooth® Core Specification v6.0 Funktionsübersicht	Erläutert die neuen Funktionen und andere Änderungen, die in Version 6.0 der Bluetooth Core Spezifikation veröffentlicht wurden. Enthält Bluetooth Channel Sounding, entscheidungsbasierte Werbefilterung und die Überwachung von Werbeträgern.	kernspezifikation-6-feature-overview/
Bluetooth Channel Sounding Technischer Überblick	Bietet einen detaillierten technischen Überblick über Bluetooth Channel Sounding.	bluetooth-resources/bluetooth-channel-sounding-a-technical-overview/
eBook - Einführung in Bluetooth LE Audio	Ein Buch von Nick Hunn, das eine klare Einführung in die Funktionen und technischen Details von Bluetooth LE Audio bietet.	bluetooth-resources/le-audio-book/
Dokument über regulatorische Aspekte	Enthält Anleitungen und unterstützende Informationen zur Bluetooth LE und zum Verständnis der Bluetooth SIGfür die in verschiedenen geografischen Regionen geltenden HF-Vorschriften.	bluetooth-resources/bluetooth-low-energy-regulatory-aspects-document-rad/

[1] Die Bluetooth-Spezifikationen werden in Abschnitt 4 vorgestellt.

[2] Dienste, Merkmale und Deskriptoren werden im Abschnitt Generisches Attributprofil erläutert.

[3] LE 2M 2BT wird nur für Bluetooth Channel Sounding und nicht für die allgemeine Datenkommunikation verwendet.

[4] Bluetooth Channel Sounding ist ein Sonderfall und wird in 8.^Bluetooth® Channel Sounding behandelt.

[5] Weitere Informationen zu Bluetooth LE und RF-Vorschriften finden Sie unter 18. Zusätzliche Ressourcen für das Dokument zu den rechtlichen Aspekten

[6] Abschnitt 15 behandelt die Sicherheit von Bluetooth LE im Detail.

[7] [8] Periodische Werbung und isochrone Streams werden in 7.8 Die logischen Transporte erklärt

[9] #nse - 1 bedeutet Anzahl der Unterereignisse minus eins

[10] Der von LE Audio verwendete Low Complexity Communications Codec

[11] Siehe 12.4 Träger