Kapitel 4. GATT (Dienstleistungen und Merkmale)

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Das Generic Attribute Profile (GATT) legt im Detail fest, wie alle Profil- und Nutzerdaten über eine BLE-Verbindung ausgetauscht werden. Im Gegensatz zu GAP(Kapitel 3), das die Low-Level-Interaktionen mit Geräten definiert, befasst sich GATT nur mit den eigentlichen Datenübertragungsverfahren und -formaten.

GATT bietet auch den Referenzrahmen für alle GATT-basierten Profile (siehe "SIG-definierte GATT-basierte Profile"), die genaue Anwendungsfälle abdecken und die Interoperabilität zwischen Geräten verschiedener Hersteller gewährleisten. Alle Standard-BLE-Profile basieren daher auf GATT und müssen diesem entsprechen, um korrekt zu funktionieren. Das macht GATT zu einem wichtigen Teil der BLE-Spezifikation, denn alle Daten, die für Anwendungen und Nutzer/innen relevant sind, müssen nach den GATT-Regeln formatiert, verpackt und gesendet werden.

GATT verwendet das Attribute Protocol (siehe "Attribute Protocol (ATT)") als Transportprotokoll, um Daten zwischen Geräten auszutauschen. Diese Daten sind hierarchisch in Abschnitten organisiert, die als Dienste bezeichnet werden und konzeptionell zusammenhängende Teile von Benutzerdaten, die als Merkmale bezeichnet werden, zusammenfassen. Dies bestimmt viele grundlegende Aspekte von GATT, die in diesem Kapitel behandelt werden.

Rollen

Wie bei jedem anderen Protokoll oder Profil der Bluetooth-Spezifikation beginnt GATT mit der Definition der Rollen, die interagierende Geräte übernehmen können:

Kunde

Der GATT-Client entspricht dem ATT-Client, der in "Attribute Protocol (ATT)" beschrieben wird . Er sendet Anfragen an einen Server und erhält von diesem Antworten (und vom Server initiierte Aktualisierungen). Da der GATT-Client im Voraus nichts über die Attribute des Servers weiß, muss er sich zunächst über das Vorhandensein und die Art dieser Attribute erkundigen, indem er eine Dienstsuche durchführt. Danach kann er die Attribute des Servers lesen und schreiben und vom Server initiierte Aktualisierungen empfangen.

Server

Der GATT-Server entspricht dem ATT-Server, der in "Attribute Protocol (ATT)" beschrieben wird . Er empfängt Anfragen von einem Client und sendet Antworten zurück. Er sendet auch vom Server initiierte Aktualisierungen, wenn er dafür konfiguriert ist, und ist für die Speicherung und Bereitstellung der in Attributen organisierten Nutzerdaten für den Client verantwortlich. Jedes BLE-Gerät, das verkauft wird, muss mindestens einen einfachen GATT-Server enthalten, der auf Client-Anfragen antworten kann, und sei es nur, um eine Fehlerantwort zurückzuschicken.

Es ist noch einmal erwähnenswert, dass GATT-Rollen sowohl völlig unabhängig von GAP-Rollen sind (siehe "Rollen") als auch gleichzeitig miteinander kompatibel sind. Das bedeutet, dass sowohl eine GAP-Zentrale als auch ein GAP-Peripheriegerät als GATT-Client oder -Server oder sogar als beides gleichzeitig agieren können.

UUIDs

Ein universell eindeutiger Bezeichner (UUID) ist eine 128-Bit-Nummer (16 Byte), die garantiert (oder mit hoher Wahrscheinlichkeit) weltweit eindeutig ist. UUIDs werden in vielen anderen Protokollen und Anwendungen als Bluetooth verwendet. Ihr Format, ihre Verwendung und ihre Erzeugung sind in ITU-T Rec. X.667, alternativ auch bekannt als ISO/IEC 9834-8:2005.

Aus Gründen der Effizienz und weil 16 Bytes einen großen Teil der 27 Byte langen Nutzdaten des Link Layers ausmachen würden, fügt die BLE-Spezifikation zwei zusätzliche UUID-Formate hinzu: 16-Bit und 32-Bit UUIDs. Diese verkürzten Formate können nur mit UUIDs verwendet werden, die in der Bluetooth-Spezifikation definiert sind (d.h. die von der Bluetooth SIG als Standard-Bluetooth-UUIDs aufgeführt sind).

Um die vollständige 128-Bit-UUID aus der gekürzten Version zu rekonstruieren, fügst du den 16- oder 32-Bit-Kurzwert (angegeben durch xxxxxxxx, einschließlich führender Nullen) in die Bluetooth Base UUID ein:

xxxxxxxx-0000-1000-8000-00805F9B34FB

Die SIG stellt (verkürzte) UUIDs für alle Typen, Dienste und Profile bereit, die sie definiert und spezifiziert. Wenn deine Anwendung jedoch eigene benötigt, weil die von der SIG angebotenen UUIDs deine Anforderungen nicht abdecken oder weil du einen neuen Anwendungsfall implementieren möchtest, der in den Profilspezifikationen bisher nicht berücksichtigt wurde, kannst du sie auf der UUID-Generierungsseite der ITU erstellen.

Die Verkürzung ist nicht für UUIDs verfügbar, die nicht von der Bluetooth Base UUID abgeleitet sind (sogenannte herstellerspezifische UUIDs). In diesen Fällen musst du immer den vollen 128-Bit UUID-Wert verwenden.

Attribute

Attribute sind die kleinste von GATT (und ATT) definierte Dateneinheit. Sie sind adressierbare Informationen, die relevante Nutzerdaten (oder Metadaten) über die Struktur und Gruppierung der verschiedenen Attribute auf dem Server enthalten können. Sowohl GATT als auch ATT können nur mit Attributen arbeiten. Damit Clients und Server interagieren können, müssen alle Informationen in dieser Form organisiert sein.

Attribute befinden sich konzeptionell immer auf dem Server und werden vom Client abgerufen (und möglicherweise geändert). Die Spezifikation definiert Attribute nur konzeptionell und zwingt die ATT- und GATT-Implementierungen nicht dazu, ein bestimmtes internes Speicherformat oder einen bestimmten Mechanismus zu verwenden. Da Attribute sowohl statische Definitionen unveränderlicher Natur als auch tatsächliche Nutzerdaten (oft Sensordaten) enthalten, die sich mit der Zeit schnell ändern können (wie in "Attribut- und Datenhierarchie" beschrieben ), werden Attribute in der Regel in einer Mischung aus nichtflüchtigem Speicher und RAM gespeichert.

Jedes einzelne Attribut enthält Informationen über das Attribut selbst und dann die eigentlichen Daten in den Feldern, die in den folgenden Abschnitten beschrieben werden.

Henkel

Das Attribut-Handle ist ein eindeutiger 16-Bit-Bezeichner für jedes Attribut auf einem bestimmten GATT-Server. Es ist der Teil eines jeden Attributs, der es adressierbar macht, und es wird garantiert, dass es sich (mit den im Abschnitt "Caching von Attributen" beschriebenen Einschränkungen ) zwischen Transaktionen oder, bei gebundenen Geräten, sogar über Verbindungen hinweg nicht ändert. Da der Wert 0x0000 ein ungültiges Handle bezeichnet, ist die Anzahl der Handles, die jedem GATT-Server zur Verfügung stehen, 0xFFFF (65535). In der Praxis liegt die Anzahl der Attribute in einem Server jedoch eher bei ein paar Dutzend.

Hinweis

Wenn der Begriff Handle-Range im Zusammenhang mit Attribut-Handles verwendet wird, bezieht er sich auf alle Attribute, deren Handles zwischen zwei bestimmten Grenzen liegen. Zum Beispiel bezieht sich der Handle-Bereich 0x0100-0x010A auf alle Attribute mit einem Handle zwischen 0x0100 und 0x010A.

Innerhalb eines GATT-Servers bestimmen die wachsenden Werte der Handles die geordnete Reihenfolge der Attribute, auf die ein Client zugreifen kann. Allerdings sind Lücken zwischen den Handles erlaubt, so dass sich ein Kunde nicht auf eine zusammenhängende Folge verlassen kann, um den Ort des nächsten Attributs zu erraten. Stattdessen muss der Kunde die Discovery-Funktion ("Service and Characteristic Discovery") nutzen, um die Handles der Attribute zu erhalten, an denen er interessiert ist.

Typ

Der Attributtyp ist nichts anderes als eine UUID (siehe "UUIDs"). Dies kann eine 16-, 32- oder 128-Bit-UUID sein, die jeweils 2, 4 oder 16 Bytes belegt. Der Typ bestimmt die Art der Daten, die im Wert des Attributs enthalten sind, und es gibt Mechanismen, um Attribute ausschließlich anhand ihres Typs zu ermitteln (siehe "Dienst- und Merkmalsermittlung").

Obwohl der Attributtyp immer eine UUID ist, können viele Arten von UUIDs zum Ausfüllen des Typs verwendet werden. Dabei kann es sich um Standard-UUIDs handeln, die das Layout der Attributhierarchie des GATT-Servers bestimmen (siehe "Attribut- und Datenhierarchie"), wie z.B. die Dienst- oder Merkmals-UUIDs, Profil-UUIDs, die die Art der im Attribut enthaltenen Daten angeben, wie z.B. Herzfrequenzmessung oder Temperatur, und sogar um proprietäre, herstellerspezifische UUIDs, deren Bedeutung vom Hersteller zugewiesen wird und von der Implementierung abhängt.

Erlaubnisse

Berechtigungen sind Metadaten, die angeben, welche ATT-Operationen (siehe "ATT-Operationen") mit welchen spezifischen Sicherheitsanforderungen auf jedem bestimmten Attribut ausgeführt werden können.

ATT und GATT definieren die folgenden Berechtigungen:

Zugriffsberechtigungen

Ähnlich wie bei den Dateiberechtigungen legen die Zugriffsrechte fest, ob der Client einen Attributwert lesen oder schreiben darf (oder beides) (eingeführt in "Wert"). Jedes Attribut kann eine der folgenden Zugriffsberechtigungen haben:

Keine

Das Attribut kann von einem Client weder gelesen noch geschrieben werden.

Lesbar

Das Attribut kann von einem Kunden gelesen werden.

Beschreibbar

Das Attribut kann von einem Kunden geschrieben werden.

Lesbar und beschreibbar

Das Attribut kann vom Kunden sowohl gelesen als auch geschrieben werden.

Verschlüsselung

Legt fest, ob ein bestimmter Verschlüsselungsgrad erforderlich ist, damit der Client auf dieses Attribut zugreifen kann. (Weitere Informationen zur Authentifizierung und Verschlüsselung findest du unter "Authentifizierung", "Sicherheitsmodi und Verfahren" und "Sicherheitsmodi" ). Dies sind die zulässigen Verschlüsselungsberechtigungen, wie sie von GATT definiert werden:

Keine Verschlüsselung erforderlich (Sicherheitsmodus 1, Stufe 1)

Das Attribut ist über eine nicht verschlüsselte Klartextverbindung zugänglich.

Unauthentifizierte Verschlüsselung erforderlich (Sicherheitsmodus 1, Stufe 2)

Die Verbindung muss verschlüsselt sein, um auf dieses Attribut zugreifen zu können, aber die Verschlüsselungsschlüssel müssen nicht authentifiziert sein (obwohl sie es sein können).

Authentifizierte Verschlüsselung erforderlich (Sicherheitsmodus 1, Stufe 3)

Die Verbindung muss mit einem authentifizierten Schlüssel verschlüsselt sein, um auf dieses Attribut zugreifen zu können.

Autorisierung

Legt fest, ob für den Zugriff auf dieses Attribut eine Benutzererlaubnis (auch Autorisierung genannt, wie in "Sicherheitsmodi und Verfahren" beschrieben ) erforderlich ist. Ein Attribut kann nur wählen, ob eine Berechtigung erforderlich ist oder nicht:

Keine Genehmigung erforderlich

Der Zugriff auf dieses Attribut erfordert keine Berechtigung.

Autorisierung erforderlich

Der Zugriff auf dieses Attribut erfordert eine Berechtigung.

Alle Berechtigungen sind unabhängig voneinander und können vom Server frei kombiniert werden, der sie pro Attribut speichert.

Wert

Der Attributwert enthält den eigentlichen Dateninhalt des Attributs. Es gibt keine Beschränkungen für die Art der Daten, die er enthalten kann (du kannst ihn dir wie einen nicht typisierten Puffer vorstellen, der auf der Grundlage des Attributtyps in den tatsächlichen Typ umgewandelt werden kann), obwohl seine maximale Länge in der Spezifikation auf 512 Byte begrenzt ist.

Wie in "Attribut- und Datenhierarchie" erläutert , kann der Wert je nach Attributtyp zusätzliche Informationen über die Attribute selbst oder tatsächliche, nützliche, benutzerdefinierte Anwendungsdaten enthalten. Dies ist der Teil eines Attributs, auf den ein Kunde frei zugreifen kann (mit den entsprechenden Berechtigungen), um zu lesen und zu schreiben. Alle anderen Entitäten bilden die Struktur des Attributs und können vom Client nicht direkt geändert oder aufgerufen werden (obwohl der Client den Handle und die UUID bei den meisten Austauschvorgängen mit dem Server indirekt verwendet).

Du kannst dir die Gesamtheit der Attribute, die in einem GATT-Server enthalten sind, als Tabelle vorstellen (z. B. Tabelle 4-1), wobei jede Zeile für ein einzelnes Attribut und jede Spalte für die verschiedenen Teile steht, die ein Attribut tatsächlich ausmachen.

Tabelle 4-1. Attribute als Tabelle dargestellt
Henkel Typ Erlaubnisse Wert Wert Länge

0x0201

UUID1 (16-bit)

Nur lesen, keine Sicherheit

0x180A

2

0x0202

UUID2 (16-bit)

Nur lesen, keine Sicherheit

0x2A29

2

0x0215

UUID3 (16-bit)

Lesen/Schreiben, Autorisierung erforderlich

"ein lesbarer UTF-8-String"

23

0x030C

UUID4 (128-bit)

Nur schreiben, keine Sicherheit

{0xFF, 0xFF, 0x00, 0x00}

4

0x030D

UUID5 (128-bit)

Lesen/Schreiben, authentifizierte Verschlüsselung erforderlich

36.43

8

0x031A

UUID1 (16-bit)

Nur lesen, keine Sicherheit

0x1801

2

In diesem fiktiven GATT-Server werden die Attribute, die er enthält, als Zeilen einer einfachen Tabelle dargestellt. Dieser spezielle GATT-Server enthält nur sechs Attribute (eine eher geringe Anzahl im Vergleich zu realen Geräten). Wie bereits in diesem Abschnitt erwähnt, müssen die Handles der verschiedenen Attribute nicht unmittelbar aufeinander folgen, sondern die Reihenfolge muss wie in diesem Beispiel immer weiter fortschreiten.

Die Spalte Wert in der Tabelle soll die große Vielfalt an Formaten widerspiegeln, die Attributwerte in den verschiedenen GATT-basierten Profilen enthalten können. Die Attribute mit den Handles 0x0201, 0x0202 und 0x031A enthalten 16-Bit-Ganzzahlen in ihren jeweiligen Wertfeldern. Das Attribut mit dem Handle 0x0215 enthält einen UTF-8-String, 0x030C enthält einen 4-Byte-Puffer und 0x030D enthält eine IEEE-754 64-Bit-Gleitkommazahl in seinem Wertefeld.

Hierarchie der Attribute und Daten

Obwohl die Bluetooth-Spezifikation im ATT-Abschnitt Attribute definiert, ist das alles, was ATT dazu zu sagen hat. ATT arbeitet mit Attributen und stützt sich auf alle Konzepte, die im Abschnitt "Attribute" erläutert werden, um eine Reihe von präzisen Protokolldateneinheiten (PDUs, allgemein als Pakete bekannt) bereitzustellen, die es einem Client ermöglichen, auf die Attribute eines Servers zuzugreifen.

GATT geht noch weiter und stellt eine strenge Hierarchie auf, um die Attribute auf eine wiederverwendbare und praktische Weise zu organisieren, so dass der Zugriff und die Abfrage von Informationen zwischen Client und Server einer präzisen Reihe von Regeln folgen, die zusammen den Rahmen bilden, der von allen GATT-basierten Profilen verwendet wird.

Abbildung 4-1 veranschaulicht die durch das GATT eingeführte Datenhierarchie.

gsbl 0401
Abbildung 4-1. GATT-Datenhierarchie

Die Attribute in einem GATT-Server sind in Diensten gruppiert, von denen jeder null oder mehr Merkmale enthalten kann. Diese Merkmale wiederum können null oder mehr Deskriptoren enthalten. Diese Hierarchie wird für jedes Gerät, das GATT-Kompatibilität beansprucht (im Wesentlichen alle verkauften BLE-Geräte), strikt durchgesetzt. Kein Attribut darf außerhalb dieser Hierarchie stehen, da der Datenaustausch zwischen BLE-Geräten von ihr abhängt.

Bei den meisten Datentypen in der GATT-Hierarchie ist es wichtig, zwischen ihrer Definition (der gesamten Gruppe von Attributen, aus denen sie besteht) und der Deklaration zu unterscheiden. Die Deklaration ist ein einzelnes Attribut, das innerhalb der Definition immer an erster Stelle steht (in aufsteigender Reihenfolge der Handles) und das die meisten Metadaten über die folgenden Daten enthält. Alle Deklarationen haben nur Leserechte und benötigen keine Sicherheit, da sie keine sensiblen Daten enthalten können. Sie sind nur strukturelle Attribute, die es dem Client ermöglichen, das Layout und die Art der Attribute auf dem Server herauszufinden und zu entdecken.

Dienstleistungen

GATT-Dienste fassen konzeptionell zusammenhängende Attribute in einem gemeinsamen Abschnitt des Attributinformationssatzes im GATT-Server zusammen. In der Spezifikation werden alle Attribute eines einzelnen Dienstes als Dienstdefinition bezeichnet. Die Attribute eines GATT-Servers sind also eine Abfolge von Dienstdefinitionen, die jeweils mit einem einzigen Attribut beginnen, das den Beginn eines Dienstes markiert (treffend als Dienstdeklaration bezeichnet). Der Typ und das Werteformat dieses Attributs sind in GATT genau festgelegt, wie in Tabelle 4-2 dargestellt.

Tabelle 4-2. Attribut Diensterklärung
Henkel Typ Erlaubnisse Wert Wert Länge

0xNNNN

UUID-Primärdienst oderUUID-Sekundärdienst

Nur lesen

Dienst UUID

2, 4 oder 16 Bytes

In der Erklärung in Tabelle 4-2 beziehen sichUUIDprimärdienst (0x2800) undUUIDSekundärdienst (0x2801) auf standardmäßige, SIG-zugeordnete UUIDs, die als exklusiver Typ zur Einführung eines Dienstes verwendet werden. Es handelt sich dabei natürlich um 16-Bit-UUIDs (weil sie in der Spezifikation als grundlegende UUIDs definiert sind).

Es ist wichtig, den Unterschied zwischen primären und sekundären Diensten zu kennen. Ein primärer Dienst ist der Standardtyp eines GATT-Dienstes, der relevante Standardfunktionen enthält, die vom GATT-Server bereitgestellt werden. Ein sekundärer Dienst hingegen ist nur für andere primäre Dienste gedacht und macht nur als Modifikator Sinn, da er für sich genommen keine wirkliche Bedeutung hat. In der Praxis werden sekundäre Dienste nur selten genutzt.

Der Wert des Attributs "Dienstdeklaration" selbst enthält eine UUID (wie unter "Wert" erwähnt , kann der Wert eines Attributs ein beliebiger Datentyp sein), die diesmal der UUID des eigentlichen Dienstes entspricht, den diese Deklaration einführt.

Obwohl die Dienstdeklaration immer das erste Attribut des Dienstes sein muss, können viele andere vor der nächsten Dienstdeklaration folgen, normalerweise in Form von Merkmalen und Deskriptoren.

Konzeptionell kann man sich einen GATT-Dienst wie eine Klasse in jeder modernen objektorientierten Sprache vorstellen, einschließlich der Instanziierung, denn ein Dienst kann innerhalb eines GATT-Servers mehrfach instanziiert werden (was allerdings nicht häufig vorkommt und die meisten Dienste daher eher Singletons sind).

Innerhalb einer Dienstdefinition (d. h. innerhalb eines Dienstes) kannst du mithilfe von Include-Definitionen einen oder mehrere Verweise auf andere Dienste hinzufügen. Include-Definitionen bestehen aus einem einzigen Attribut (der Include-Deklaration), das alle Details enthält, die der Client benötigt, um den eingebundenen Dienst zu referenzieren.

Eingebundene Dienste können helfen, doppelte Daten in einem GATT-Server zu vermeiden. Wenn ein Dienst von anderen Diensten referenziert wird, kannst du diesen Mechanismus nutzen, um Speicher zu sparen und das Layout des GATT-Servers zu vereinfachen. In der vorherigen Analogie mit Klassen und Objekten konntest du Include-Definitionen als Zeiger oder Verweise auf eine bestehende Objektinstanz sehen.

Tabelle 4-3 zeigt das Attribut include declaration mit allen Feldern.

Tabelle 4-3. Attribut "Include-Erklärung
Henkel Typ Erlaubnisse Wert Wert Länge

0xNNNN

UUIDinclude

Nur lesen

Eingeschlossener Dienst-Handle, Endgruppen-Handle, Eingeschlossener Dienst UUID

6, 8, oder 20 Bytes

Auch hier ist die UUIDinclude (0x2802) eine spezielle SIG-zugewiesene UUID, die ausschließlich in Include-Deklarationen verwendet wird, und das Wertfeld enthält in diesem Fall sowohl die Start- und End-Handles des Include-Dienstes als auch seine UUID.

Eigenschaften

Du kannst Merkmale als Container für Nutzdaten verstehen. Sie enthalten immer mindestens zwei Attribute: die Merkmalsdeklaration (die Metadaten über die eigentlichen Nutzdaten enthält) und den Merkmalswert (der ein vollständiges Attribut ist, das die Nutzdaten in seinem Wertfeld enthält).

Außerdem können dem Merkmalswert Deskriptoren folgen, die die in der Merkmalsdeklaration enthaltenen Metadaten weiter ausbauen. Die Erklärung, der Wert und die Deskriptoren bilden zusammen die Merkmalsdefinition, also das Bündel von Attributen, die ein einzelnes Merkmal ausmachen.

Tabelle 4-4 zeigt die Struktur der ersten beiden Attribute jedes einzelnen Merkmals.

Tabelle 4-4. Merkmalsdeklaration und Merkmalswertattribute
Henkel Typ Erlaubnisse Wert Wert Länge

0xNNNN

UUID-Merkmal

Nur lesen

Eigenschaften, Wert Handle (0xMMMM), Merkmal UUID

5, 7, oder 19 Bytes

0xMMMM

Merkmal UUID

Jede

Tatsächlicher Wert

Variabel

Alle GATT-Merkmale sind immer Teil einer Dienstleistung und können daher immer in einer solchen enthalten sein.

Attribut der Merkmalserklärung

Auch hier ist der Typ UUID (0x2803) des Attributs Merkmaldeklaration eine standardisierte, eindeutige UUID, die ausschließlich zur Kennzeichnung des Beginns von Merkmalen verwendet wird. Wie alle anderen Deklarationen (z. B. service und include) hat auch dieses Attribut nur Leserechte, denn die Kunden dürfen seinen Wert nur abrufen, aber auf keinen Fall ändern.

In Tabelle 4-5 sind die verschiedenen Elemente aufgeführt, die im Attributwert der Merkmalsdeklaration verkettet sind.

Tabelle 4-5. Merkmalserklärung Attributwert
Name Länge in Bytes Beschreibung

Charakteristische Eigenschaften

1

Ein Bitfeld, das die zulässigen Operationen für dieses Merkmal auflistet

Merkmal Wert Handle

2

Das Handle des Attributs, das den Merkmalswert enthält

Merkmal UUID

2, 4, oder 16

Die UUID für dieses besondere Merkmal

Diese drei Felder sind in einem Attributwert der Merkmalserklärung enthalten:

Charakteristische Eigenschaften

Dieses 8-Bit-Bitfeld enthält zusammen mit den zusätzlichen zwei Bits im erweiterten Eigenschaftsdeskriptor (siehe "Erweiterter Eigenschaftsdeskriptor") die Operationen und Prozeduren, die mit diesem Merkmal verwendet werden können. Jede dieser 9 Eigenschaften wird als ein einzelnes Bit in dem in Tabelle 4-6 dargestellten Bitfeld kodiert.

Tabelle 4-6. Charakteristische Eigenschaften
Eigentum Standort Beschreibung

Sendung

Eigenschaften

Wenn gesetzt, kann dieser Merkmalswert in Werbepaketen unter Verwendung des Service Data AD Type platziert werden (siehe "GATT-Attributdaten in Werbepaketen")

Lies

Eigenschaften

Wenn diese Option gesetzt ist, können Kunden dieses Merkmal mit einer der unter "ATT-Operationen" aufgeführten ATT-Leseoperationen lesen .

Schreiben ohne Antwort

Eigenschaften

Wenn diese Option gesetzt ist, können Kunden die ATT-Operation "Schreibbefehl" für dieses Merkmal verwenden (siehe "ATT-Operationen").

Schreibe

Eigenschaften

Wenn gesetzt, können Clients die ATT-Operation Write Request/Response für dieses Merkmal verwenden (siehe "ATT-Operationen").

benachrichtigen

Eigenschaften

Wenn gesetzt, kann der Server die ATT-Operation "Handle Value Notification" für dieses Merkmal verwenden (siehe "ATT-Operationen").

Zeige an.

Eigenschaften

Wenn gesetzt, kann der Server die ATT-Operation Handle Value Indication/Confirmation auf dieses Merkmal anwenden (siehe "ATT-Operationen").

Signierter Schreibbefehl

Eigenschaften

Wenn gesetzt, können Kunden die ATT-Operation "Signed Write Command" für dieses Merkmal verwenden (siehe "ATT-Operationen").

Schreiben in der Warteschlange

Erweiterte Eigenschaften

Wenn diese Option gesetzt ist, können Clients die ATT-Operationen für Warteschlangen-Schreiben auf diesem Merkmal verwenden (siehe "ATT-Operationen").

Beschreibbare Hilfskräfte

Erweiterte Eigenschaften

Wenn diese Option gesetzt ist, kann ein Client in den Deskriptor schreiben, der in "Charakteristische Benutzerbeschreibung Deskriptor" beschrieben ist .

Der Client kann diese Eigenschaften lesen, um herauszufinden, welche Operationen er mit dem Merkmal durchführen darf. Dies ist besonders wichtig für die Eigenschaften Notify und Indicate, da diese Vorgänge vom Server initiiert werden (siehe "Serverinitiierte Aktualisierungen"), aber vom Client erst mit dem Deskriptor aktiviert werden müssen, der unter "Deskriptor für die Client-Merkmalskonfiguration" beschrieben wird .

Merkmal Wert Handle

Diese beiden Bytes enthalten das Attribut-Handle des Attributs, das den tatsächlichen Wert des Merkmals enthält. Obwohl das oft der Fall ist, solltest du nie davon ausgehen, dass dieses Handle an das Handle mit der Deklaration angrenzt (d.h. 0xNNNN+1).

Merkmal UUID

Die UUID des jeweiligen Merkmals. Dies kann entweder eine von der SIG genehmigte UUID sein (wenn die Dutzenden von Merkmalstypen in den Standardprofilen verwendet werden) oder andernfalls eine anbieterspezifische 128-Bit UUID.

Um bei der Analogie von Klasse und Objektorientierung zu bleiben: Merkmale sind wie einzelne Felder oder Eigenschaften in einer Klasse, und ein Profil ist wie eine Anwendung, die eine oder mehrere Klassen für einen bestimmten Bedarf oder Zweck nutzt.

Attribut Merkmalswert

Das Attribut "Merkmalswert" schließlich enthält die eigentlichen Benutzerdaten, die der Client für den praktischen Informationsaustausch lesen und schreiben kann. Der Typ für dieses Attribut ist immer dieselbe UUID, die im Feld für den Merkmalswert steht (siehe "Merkmalswertattribut"). Merkmalswertattribute haben also nicht mehr die Typen von Diensten oder Merkmalen, sondern konkrete, spezifische UUIDs, die sich auf den Messwert eines Sensors oder einen Tastendruck auf einer Tastatur beziehen können.

Der Wert eines Attributs für einen charakteristischen Wert kann jede erdenkliche Art von Daten enthalten, von Temperaturen in Celsius über Schlüssel-Scan-Codes bis hin zu Display-Strings und Geschwindigkeiten in Meilen pro Stunde - alles, was sinnvoll über zwei BLE-Geräte übertragen werden kann, kann den Inhalt dieses Werts ausfüllen.

Charakteristische Deskriptoren

GATT-Merkmalsdeskriptoren (allgemein einfach Deskriptoren genannt) werden meist verwendet, um den Kunden mit Metadaten zu versorgen (zusätzliche Informationen über das Merkmal und seinen Wert). Sie werden immer innerhalb der Merkmalsdefinition und nach dem Attribut Merkmalswert platziert. Deskriptoren bestehen immer aus einem einzigen Attribut, der Merkmals-Deskriptor-Deklaration, deren UUID immer der Deskriptor-Typ ist und deren Wert alles enthält, was durch diesen speziellen Deskriptor-Typ definiert ist.

Du kannst zwei Arten von Deskriptoren in den verschiedenen GATT-Merkmalen finden:

GATT-definierte Deskriptoren

Dies sind die grundlegenden, weit verbreiteten Deskriptorentypen, die einfach Metainformationen über das Merkmal hinzufügen. In den folgenden Abschnitten werden die gängigsten Typen beschrieben.

Profil oder herstellerdefinierte Deskriptoren

Unabhängig davon, ob ein Profil von der SIG oder von einem bestimmten Anbieter spezifiziert und veröffentlicht wird, können diese Deskriptoren alle Arten von Daten enthalten, einschließlich zusätzlicher Informationen über den Merkmalswert, wie z. B. die Kodierung, mit der der Wert von einem Sensor erfasst wurde, oder andere Angaben, die den Messwert selbst ergänzen.

In den folgenden Abschnitten werden einige der am häufigsten verwendeten Deskriptoren beschrieben, die im GATT definiert sind.

Erweiterte Eigenschaften Deskriptor

Wenn dieser Deskriptor vorhanden ist, enthält er lediglich die beiden zusätzlichen Eigenschaftsbits, die in Tabelle 4-6 unter "Merkmal Deklaration Attribut" aufgeführt sind.

Merkmal Benutzer Beschreibung Deskriptor

Wie der Name schon sagt, enthält dieser Deskriptor eine benutzerlesbare Beschreibung für das Merkmal, in dem er platziert ist. Dabei handelt es sich um eine UTF-8-Zeichenkette, die z. B. "Temperatur im Wohnzimmer" lauten könnte.

Client-Merkmal Konfigurationsdeskriptor

Dieser Deskriptortyp (oft mit CCCD abgekürzt) ist zweifelsohne der wichtigste und am häufigsten verwendete und er ist für die meisten Profile und Anwendungsfälle unerlässlich. Seine Funktion ist einfach: Er fungiert als Schalter, mit dem serverinitiierte Aktualisierungen aktiviert oder deaktiviert werden (mehr dazu unter "Serverinitiierte Aktualisierungen"), allerdings nur für das Merkmal, in dem er sich selbst befindet.

Der Wert eines CCCD ist nichts anderes als ein Zwei-Bit-Bitfeld, wobei ein Bit für Meldungen und das andere für Hinweise steht. Ein Client kann diese Bits jederzeit setzen und löschen, und der Server prüft sie jedes Mal, wenn sich der Wert des Merkmals, das sie einschließt, geändert hat und möglicherweise eine Aktualisierung über die Luft erfolgt.

Jedes Mal, wenn ein Client Benachrichtigungen oder Hinweise für ein bestimmtes Merkmal, das diese unterstützt, aktivieren möchte, verwendet er einfach ein Write Request ATT-Paket, um das entsprechende Bit auf 1 zu setzen. Der Server antwortet dann mit einer Write Response und beginnt, die entsprechenden Pakete zu senden, wann immer er den Client über eine Änderung des Wertes informieren möchte.

Außerdem haben CCCDs zwei besondere Eigenschaften, die sie von anderen Attributen unterscheiden:

Ihre Werte sind pro Verbindung eindeutig

In Szenarien mit mehreren Verbindungen, in denen eine Zentrale mit mehreren Peripheriegeräten verbunden ist und gleichzeitig als GATT-Server fungiert, erhält jedes Peripheriegerät seine eigene Kopie des CCCD-Werts, wenn es ihn mit ATT liest.

Ihre Werte bleiben bei Verbindungen mit verbundenen Geräten erhalten

Unter "Attribut-Caching" wird das Zwischenspeichern von Attributen ausführlicher behandelt, aber das betrifft nur Attribut-Handles. Werte werden in der Regel nicht gerätebezogen gespeichert und der GATT-Server kann sie zwischen den Verbindungen zurücksetzen. Dies ist bei CCCDs zwischen verbundenen Geräten nicht der Fall: Der letzte Wert, den ein Client in eine CCCD auf dem Server geschrieben hat, wird bei einer erneuten Verbindung garantiert wiederhergestellt, unabhängig davon, wie viel Zeit zwischen den Verbindungen verstrichen ist.

Viele Protokollstacks haben spezielle Mechanismen, um mit CCCDs umzugehen, sowohl aus Sicht des Clients als auch des Servers, weil sie so wichtig für den korrekten Betrieb und die rechtzeitige Datenaktualisierung zwischen Peers sind.

Charakteristisches Präsentationsformat Deskriptor

Wenn vorhanden, enthält dieser Deskriptortyp das tatsächliche Format des umschließenden Merkmalswerts in seinem Sieben-Byte-Attributwert. Die Liste der verfügbaren Formate umfasst Boolesche Werte, Zeichenketten, Ganzzahlen, Fließkommazahlen und sogar generische Puffer ohne Typisierung.

Beispiel Service

In diesem Abschnitt wird ein Beispiel für einen bestimmten Dienst vorgestellt, der heute in vielen kommerziellen Produkten zu finden ist. Der Heart Rate Service (HRS) gibt die Herzfrequenz des Nutzers an ein Überwachungsgerät weiter.

Abbildung 4-2 zeigt eine Instanz des HRS auf einem fiktiven Server. Dies wäre nicht der einzige Dienst, der auf dem Server enthalten ist. Du kannst dies also als einen Ausschnitt aus dem vollständigen Satz von Attributen sehen, auf die ein Client zugreifen könnte.

gsbl 0402
Abbildung 4-2. GATT Herzfrequenz-Dienst

Im Folgenden wird der in Abbildung 4-2 dargestellte HRS-Dienst Griff für Griff beschrieben:

Henkel 0x0021

Dieses Attribut enthält die Dienstdeklaration (siehe "Dienste") für den Herzfrequenzdienst. Dies sind die Felder des Attributs Dienstdeklaration:

UUID

Die UUID ist die standardmäßige 16-Bit-UUID für eine Primärdienstdeklaration,UUIDprimärdienst (0x2800).

Wert

Der Wert ist die 16-Bit-UUID für den Herzfrequenzdienst, die von der SIG (0x180D) zugewiesen wurde.

Henkel 0x0024

Dieses Attribut enthält die Merkmalserklärung (siehe "Attribut Merkmalserklärung") für das Merkmal Herzfrequenzmessung. Dies sind die Felder des Attributs "Merkmalserklärung":

UUID

Die UUID ist die Standard-16-Bit-UUID für eine Merkmalsdeklaration, UUIDcharacteristic (0x2803).

Wert

Die Merkmalseigenschaften für dieses Merkmal sind "notify only", der Merkmalswert "handle" ist 0x0027, und der Merkmalswert "UUID" ist die UUID für die Herzfrequenzmessung (0x2A37).

Henkel 0x0027

Dieses Attribut enthält den Merkmalswert (siehe "Attribut Merkmalswert"), in diesem Fall die Herzfrequenzmessung selbst. Dies sind die Felder des Attributs Merkmalswert:

UUID

Dieselbe UUID, die in den letzten beiden Bytes des Attributwerts der Merkmalserklärung steht.

Erlaubnisse

Der Wert dieses Attributs ist weder lesbar noch beschreibbar: Ein Client kann seinen Wert nur über die vom Server gesendeten Benachrichtigungen erfahren.

Wert

Die tatsächlich gemessene Herzfrequenz (zur Verdeutlichung fiktiv in Schlägen pro Minute dargestellt).

Henkel 0x0028

Dieses Attribut enthält einen CCCD (ein Schlüsseldeskriptor, der in "Client Characteristic Configuration Descriptor" beschrieben wird ). Dies sind die Felder des CCCD-Attributs:

UUID

Die UUID für jede CCCD ist immer die Standard-16-Bit-UUIDCCCD (0x2902).

Erlaubnisse

Eine CCCD muss immer lesbar und beschreibbar sein. Die Sicherheitsstufe, die für die Ausführung dieser Vorgänge erforderlich ist, wird durch das Profil oder die Anwendung definiert.

Wert

Wie bereits festgestellt, ist der Wert des CCCD ein Bitfeld, in diesem Fall 0x0001, das angibt, dass die Benachrichtigungen für dieses bestimmte HRM-Merkmal aktiviert sind.

Henkel 0x002A

Dieses Attribut enthält eine weitere Merkmalsdeklaration (siehe "Attribut Merkmalsdeklaration"), dieses Mal für das Merkmal Körper-Sensor-Standort. Dies sind die Felder des Attributs "Merkmalserklärung":

UUID

Die UUID ist die Standard-16-Bit-UUID für eine Merkmalsdeklaration, UUIDcharacteristic (0x2803).

Wert

Die Merkmalseigenschaften für dieses Merkmal sind schreibgeschützt, der Merkmalswert-Handle ist 0x002C und der Merkmalswert UUID ist die UUID für den Körper-Sensor-Standort (0x2A38).

Henkel 0x002C

Dieses Attribut enthält den Merkmalswert (siehe "Merkmalswert-Attribut"), in diesem Fall die Position des Körpersensors. Dies sind die Felder des Attributs "Merkmalswert":

UUID

Dieselbe UUID, die in den letzten beiden Bytes des Attributwerts der Merkmalsdefinition steht.

Erlaubnisse

Der Wert dieses Attributs ist schreibgeschützt: Ein Client kann nur überprüfen, wo sich der Sensor befindet, aber nicht seinen Standort ändern (das ist Sache des Servers).

Wert

Die tatsächliche Position des Körpersensors (aus Gründen der Übersichtlichkeit fiktiv als "Finger" dargestellt).

Es gibt verschiedene Tools, mit denen du die verschiedenen Dienste auf einem Server in einem ähnlichen Format wie in Abbildung 4-2 erkennen und anzeigen kannst. In Kapitel 6 findest du weitere Informationen zu diesen Tools.

Erweiterte Attribut-Konzepte

In diesem Abschnitt werden weitere Konzepte für die Arbeit mit Attributen vorgestellt, die ebenfalls erwähnenswert sind, weil ihr Verständnis häufig für viele Arten von BLE-Anwendungen erforderlich ist.

Attribut-Caching

In "Attribute" wird beschrieben, wie ein Client mit Hilfe von Attribut-Handles alle verfügbaren Attribute eines Servers einzeln ansprechen kann. Die Liste der verfügbaren Handles und den Inhalt der jeweiligen Attribute zu ermitteln, kann ein zeitaufwändiger (und energieintensiver) Prozess sein, der in "Dienst- und Merkmalsermittlung" näher erläutert wird. In diesem Abschnitt wird jedoch beschrieben, was ein Client tun kann, um zu vermeiden, dass er jedes Mal, wenn er sich erneut mit einem Server verbindet, den Erkennungsvorgang durchführen muss, und unter welchen Umständen er dies tun kann.

Server neigen in der Regel dazu, einen stabilen Satz von Attributen beizubehalten, und ihre Grundstruktur ändert sich in den meisten Fällen während der Lebensdauer eines Servergeräts nicht. Aber die Implementierung setzt in dieser Hinsicht keine starren Grenzen, und ein Server kann seine Attribute jederzeit komplett überarbeiten und sogar durch einen radikal neuen Satz ersetzen (z. B. durch ein Firmware-Update oder durch die Installation von Anwendungen auf dem Servergerät). Daher sind bestimmte Regeln und Einschränkungen erforderlich, damit sich ein Kunde auf die Gültigkeit der zuvor ermittelten Handles verlassen kann, ohne Gefahr zu laufen, dass sie auf dem Server geändert wurden und somit nicht mehr gültig sind.

Generell empfiehlt die Spezifikation, dass Clients die Handles der Attribute, an denen sie interessiert sind, zwischenspeichern (d. h. für nachfolgende Transaktionen und sogar Verbindungen). Attributwerte, vor allem wenn sie tatsächlichen Nutzerdaten entsprechen, sind sehr flüchtig, so dass es in der Regel wenig Sinn macht, sie für eine spätere Verwendung lokal im Client zu speichern.

Die Spezifikation sieht das Merkmal "Service Changed" (ausführlicher in "GATT Service") vor, mit dem Server dem Client mögliche Änderungen des Inhalts ihrer Attributinformationen mitteilen können. Es handelt sich dabei um ein optionales Merkmal, d.h. sein bloßes Vorhandensein auf dem Server ist bereits ein Hinweis auf mögliche strukturelle Attributänderungen.

Kunden können feststellen, ob das Ergebnis der Suche für die zukünftige Verwendung zwischengespeichert werden kann, indem sie die folgenden Bedingungen beachten:

Kein Merkmal "Dienst geändert" auf dem Server vorhanden

Die Clients können alle gefundenen Handles frei und ohne Einschränkungen zwischenspeichern. Der Server garantiert, dass sie sich während der Lebensdauer des Geräts nicht ändern.

Dienst Geändertes Merkmal auf dem Server vorhanden

In diesem Fall muss ein Client die vom Server initiierten Aktualisierungen abonnieren, indem er in die entsprechende CCCD des Merkmals "Service Changed" schreibt (siehe "Merkmalsdeskriptoren"). Auf diese Weise kann der Server den Client über alle strukturellen Änderungen informieren. Wenn der Client und der Server wie in "Sicherheitsmodi und Verfahren" beschrieben verbunden sind , kann der Client die Attribut-Handles über die Verbindungen hinweg zwischenspeichern und erwarten, dass sie identisch bleiben. Wenn die Geräte nicht miteinander verbunden sind, muss der Client bei jeder erneuten Verbindung zum Server eine Erkennung durchführen.

Unter "GATT-Service" findest du weitere Informationen zur Verwendung des Merkmals "Service geändert".

GATT-Attributdaten in Werbepaketen

Obwohl GATT in erster Linie auf etablierten Verbindungen zwischen einer Zentrale und einem Peripheriegerät beruht (wie in "Rollen" beschrieben ), ist es auch möglich, Teile der Attributinformationen, die vom Server gehostet werden, in Werbepakete einzubinden, so dass ein oder mehrere Serverattribute für jeden Beobachter oder jede Zentrale beim Scannen verfügbar sind.

In Tabelle 3-3 wird der AD-Typ für Dienstdaten beschrieben, aber nicht das Format, das verwendet wird, um Serverattribute in ein Werbepaket einzuschließen. Die Ergänzung zur Kernspezifikation auf der Seite Angenommene Dokumente der Spezifikation legt die Felder fest, die der GATT-Server in die Nutzdaten eines Werbepakets einfügen muss, um die Daten eines bestimmten Dienstes für Scanner verfügbar zu machen.

Wie in Tabelle 4-7 zu sehen ist, muss ein GATT-Server zwei verschiedene Felder in den Dienstdatenabschnitt des Werbepakets aufnehmen, um Dienstdaten senden zu können.

Tabelle 4-7. Dienstdaten AD-Typ
Feld Länge in Bytes Beschreibung

UUID

2, 4, oder 16

Die tatsächliche UUID, die die Daten identifiziert

Dienstdaten

Variabel

Die Daten, die mit dem durch die UUID identifizierten Dienst verbunden sind

Der Inhalt des Feldes Dienstdaten kann dem vollständigen oder teilweisen Wert eines bestimmten Merkmals oder Deskriptors innerhalb des entsprechenden Dienstes entsprechen. Welche das sind, muss in der jeweiligen Profilspezifikation festgelegt werden, denn nur das Profil hat genügend Wissen über die Daten, um zu entscheiden, welche Informationen am wichtigsten sind und übertragen werden sollen.

Eigenschaften

GATT-Merkmale sind genau definierte Verfahren, die einen GATT-basierten Datenaustausch ermöglichen. Sie basieren alle auf den verschiedenen Operationen, die ATT bietet (siehe "ATT-Operationen").

Bis zu einem gewissen Grad sind die meisten der in diesem Kapitel aufgeführten Funktionen auf die eine oder andere Weise in den meisten GATT-APIs enthalten. Die GATT-Server-APIs bieten zusätzlich die Möglichkeit, den eigentlichen Server mit Attributen zu bestücken, aber das ist stark von der Implementierung abhängig und geht über den Rahmen dieses Kapitels hinaus.

Austausch MTU

Mit diesem kurzen Zwei-Paket-Verfahren kann jeder ATT-Peer dem anderen Ende die maximale Übertragungseinheit (MTU, d. h. die maximale Paketlänge) mitteilen, die er in seinen Puffern speichern und daher akzeptieren kann.

Dieses Verfahren wird nur verwendet, wenn entweder der Client oder der Server (oder beide) mit MTUs umgehen können, die länger sind als die Standardwerte ATT_MTU von 23 Bytes (siehe "Logical Link Control and Adaptation Protocol (L2CAP)") und dem anderen Ende mitteilen wollen, dass es Pakete senden kann, die länger sind als die Standardwerte, die die Spezifikation verlangt. L2CAP fragmentiert dann diese größeren Pakete in kleine Link-Layer-Pakete und setzt sie aus kleinen Link-Layer-Paketen wieder zusammen.

Dienst und Merkmal Entdeckung

Wie bereits an anderer Stelle in diesem Kapitel erwähnt, hat der Client keine Kenntnis über die Attribute, die in einem GATT-Server vorhanden sein könnten, wenn er sich das erste Mal mit ihm verbindet. Daher muss der Client zunächst eine Reihe von Datenpaketen austauschen, um die Anzahl, den Ort und die Art aller Attribute zu ermitteln, die von Interesse sein könnten. Wie im Abschnitt "Caching von Attributen" beschrieben , können Verfahren dieser Kategorie in einigen Fällen übersprungen werden.

Für die Erkennung von Primärdiensten bietet GATT die folgenden zwei Optionen:

Entdecke alle primären Dienstleistungen

Mit dieser Funktion können Clients eine vollständige Liste aller primären Dienste (unabhängig von den Dienst-UUIDs) vom Remote-Server abrufen. Diese Funktion wird häufig verwendet, wenn der Client mehr als einen Dienst unterstützt und sich daher über die vollständige Dienstunterstützung auf der Serverseite informieren möchte. Da der Client bei der Anfrage einen Handle-Bereich angeben kann, muss er 0x0001-0xFFFF als Handle-Bereich festlegen, um diese Funktion zu implementieren und den gesamten Attributbereich des Servers abzudecken.

Erkennen des primären Dienstes anhand der UUID des Dienstes

Wenn der Client weiß, nach welchem Dienst er sucht (in der Regel, weil er selbst nur diesen einen Dienst unterstützt), kann er mit dieser Funktion einfach nach allen Instanzen eines bestimmten Dienstes suchen, auch mit der Anforderung, den Handle-Bereich auf 0x0001-0xFFFF zu setzen.

Jedes dieser Verfahren liefert Handle-Ranges, die sich auf die Attribute beziehen, die zu einem einzelnen Dienst gehören. Die Funktion discover all primary services ermittelt auch die UUIDs der einzelnen Dienste.

Wenn der Client bereits Dienste auf dem Server gefunden hat, kann er die Beziehungsermittlung (die Ermittlung aller enthaltenen Dienste) mit der folgenden Funktion durchführen:

Inklusivleistungen finden

So kann ein Kunde den Server über alle enthaltenen Dienste innerhalb eines Dienstes abfragen. Der Handle-Bereich, der in einer solchen Abfrage angegeben wird, bezieht sich auf die Grenzen eines bestehenden Dienstes, die zuvor mit der Dienstsuche ermittelt wurden. Wie bei der Dienstsuche erhält der Kunde auch hier eine Reihe von Handle-Ranges, ggf. zusammen mit UUIDs.

Für die Merkmalsermittlung bietet das GATT die folgenden Optionen:

Entdecke alle Merkmale eines Dienstes

Sobald ein Kunde den Handle-Bereich für einen Dienst erhalten hat, an dem er interessiert ist, kann er eine vollständige Liste der Merkmale des Dienstes abrufen. Die einzige Eingabe ist der Handle-Bereich, und im Gegenzug gibt der Server sowohl den Handle als auch den Wert aller Merkmalserklärungsattribute zurück, die in diesem Dienst enthalten sind (siehe "Merkmalserklärungsattribut").

Merkmale nach UUID entdecken

Dieses Verfahren ist identisch mit dem vorherigen, mit dem Unterschied, dass der Client alle Antworten verwirft, die nicht mit der angestrebten charakteristischen UUID übereinstimmen.

Sobald die Grenzen (in Form von Handles) eines Zielmerkmals festgelegt sind, kann der Kunde mit der Erkennung der Merkmalsdeskriptoren fortfahren:

Entdecke alle charakteristischen Deskriptoren

Da der Client nun im Besitz einer Reihe von Handle-Bereichen und UUIDs für einige oder alle Merkmale eines Dienstes ist, kann er diese Funktion nutzen, um alle Deskriptoren innerhalb eines bestimmten Merkmals abzurufen. Der Server antwortet mit einer Liste von UUID- und Handle-Paaren für die verschiedenen Deskriptor-Deklarationen (siehe "Merkmalsdeskriptoren").

Alle Funktionen in diesem Abschnitt können über offene, ungesicherte Verbindungen ausgeführt werden, da die Erkennung für alle Clients ohne Einschränkungen erlaubt ist.

Merkmale und Deskriptoren des Lesens

Um den aktuellen Wert eines Merkmalswerts oder eines Deskriptors zu erhalten, hat der Kunde die folgenden Möglichkeiten:

Merkmalswert oder Deskriptor lesen

Mit dieser Funktion kann der Inhalt eines Merkmalswerts oder eines Deskriptors einfach über dessen Handle gelesen werden. Es können nur die ersten ATT_MTU-1 Bytes des Inhalts gelesen werden, denn das ist die maximale Anzahl von Bytes, die in das Antwortpaket passen (1 Byte ist für den ATT-Operationscode reserviert).

Langer Merkmalswert oder Deskriptor lesen

Wenn der Wert zu lang ist, um mit der vorherigen Funktion gelesen zu werden, enthält diese Funktion zusammen mit dem Handle einen Offset in der Anfrage, so dass der Merkmalswert oder der Deskriptorinhalt in aufeinanderfolgenden Chunks gelesen werden kann. Je nach Länge des zu lesenden Attributwerts können mehrere Anfrage/Antwort-Paare erforderlich sein.

Zusätzlich, und nur für charakteristische Werte anwendbar, sind diese Funktionen verfügbar:

Merkmalswert mit Merkmals-UUID lesen

Wenn ein Kunde die spezifischen Handles für die Merkmale, an denen er interessiert ist, nicht kennt, kann er die Werte aller Merkmale eines bestimmten Typs lesen. Der Kunde gibt einfach einen Handle-Bereich und eine UUID an und erhält ein Array mit den Werten der Merkmale, die in diesem Bereich liegen.

Mehrere Kennwerte lesen

Umgekehrt kann ein Kunde, der bereits die Handles für eine Gruppe von Merkmalen hat, deren Wert er erhalten möchte, eine Anfrage mit dieser Gruppe von Handles senden und anschließend die Werte für alle entsprechenden Merkmale erhalten.

Das Lesen von Merkmalen und Deskriptoren unterliegt den Sicherheitsberechtigungen und der Server kann die Berechtigung verweigern, wenn die Sicherheitsstufe der Verbindung nicht den festgelegten Anforderungen entspricht (siehe "Sicherheit").

Schriftliche Merkmale und Deskriptoren

Um in den Wert eines Merkmalswerts oder eines Deskriptors zu schreiben, hat der Kunde die folgenden Auswahlmöglichkeiten:

Merkmalswert oder Deskriptor schreiben

Diese Funktion wird verwendet, um in einen Merkmalswert oder Deskriptor zu schreiben. Der Client gibt ein Handle und den Inhalt des Wertes an (bis zu ATT_MTU-3 Bytes, da das Handle und der ATT-Operationscode im Paket mit den Daten enthalten sind) und der Server bestätigt den Schreibvorgang mit einer Antwort.

Langer Merkmalswert oder Deskriptor schreiben

Ähnlich wie bei der Funktion " Lange Kennwerte oder Deskriptoren lesen" kann ein Client mehr als ATT_MTU-3 Bytes an Daten in den Kennwert oder Deskriptor eines Servers schreiben. Dazu werden mehrere Prepare-Write-Operationen in eine Warteschlange gestellt, die jeweils einen Offset und die Daten selbst enthalten, und schließlich mit einer Execute-Write-Operation atomar geschrieben.

Zusätzlich, und nur für charakteristische Werte anwendbar, sind diese Funktionen verfügbar:

Schreiben ohne Antwort

Diese Funktion ist das umgekehrte Äquivalent zu Benachrichtigungen (siehe "Server-initiierte Updates") und verwendet Schreibbefehlspakete. Schreibbefehle sind unbestätigte Pakete, die ein Handle und einen Wert enthalten. Sie können jederzeit und in beliebiger Menge gesendet werden, ohne dass ein Mechanismus zur Flusskontrolle greift (mit Ausnahme der nativen Link-Layer-Flusskontrolle, der der gesamte Datenverkehr unterliegt). Es steht dem Server frei, sie stillschweigend zu verwerfen, wenn er sie nicht verarbeiten kann oder wenn die Attributberechtigungen ihn daran hindern, sie anzunehmen. Der Client wird das nie erfahren, aber das ist einvernehmlich geregelt. Die einzige Möglichkeit für den Kunden, herauszufinden, ob der Wert geschrieben wurde, ist, ihn nachträglich zu lesen.

Zuverlässig schreibt

Ähnlich wie bei der Funktion " Mehrere Merkmalswerte lesen" sendet ein Client, wenn er Schreibvorgänge für mehrere Merkmalswerte in die Warteschlange stellen will, ein abschließendes Paket, um die anstehenden Schreibvorgänge zu bestätigen und auszuführen.

Das Schreiben von Merkmalen und Deskriptoren unterliegt den Sicherheitsberechtigungen, und der Server kann die Erlaubnis verweigern, wenn die Sicherheitsstufe der Verbindung nicht den festgelegten Anforderungen entspricht (siehe "Sicherheit").

Server-initiierte Updates

Vom Server initiierte Aktualisierungen sind die einzigen asynchronen (d.h. nicht als Antwort auf eine Anfrage des Clients) Pakete, die vom Server zum Client gesendet werden können. Durch diese Aktualisierungen werden Änderungen eines Merkmalswerts rechtzeitig gemeldet, ohne dass der Client sie regelmäßig abfragen muss, was sowohl Strom als auch Bandbreite spart.

Es gibt zwei Arten von Server-initiierten Updates:

Merkmal Wert Benachrichtigung

Benachrichtigungen sind Pakete, die das Handle eines Merkmals zusammen mit seinem aktuellen Wert enthalten. Der Client empfängt sie und kann entscheiden, ob er darauf reagieren will, aber er sendet keine Bestätigung an den Server zurück, um den Empfang zu bestätigen. Neben "Schreiben ohne Antwort" ist dies das einzige andere Paket, das nicht der standardmäßigen Anfrage/Antwort-Flusskontrolle in ATT entspricht, da der Server jederzeit eine beliebige Anzahl dieser Benachrichtigungen senden kann. Für diese Funktion wird das ATT-Paket handle value notification (HVN) verwendet.

Merkmal Wert Indikation

Indications hingegen folgen demselben Handle/Value-Format, benötigen aber eine explizite Bestätigung vom Client in Form einer Confirmation. Beachte, dass der Server zwar keine weiteren Indications (auch nicht für andere Merkmale) senden kann, bis er die Bestätigung vom Client erhält (da diese in die entgegengesetzte Richtung fließt als die üblichen Anfrage/Antwort-Paare), eine ausstehende Bestätigung aber keine Auswirkungen auf mögliche Anfragen hat, die der Client in der Zwischenzeit senden könnte. Diese Funktion verwendet die ATT-Pakete handle value indication (HVI) und handle value confirmation (HVC).

Der Client muss beide Arten von serverinitiierten Aktualisierungen aktivieren, indem er in die entsprechende CCCD schreibt, bevor der Server sie senden kann. Im Abschnitt "Client Characteristic Configuration Descriptor" wird dieser Prozess ausführlich beschrieben.

Sicherheit

Im Abschnitt "Sicherheitsmodi und Verfahren" wird erläutert, wie das GAP-Authentifizierungsverfahren genutzt werden kann, um von einem Sicherheitsmodus in einen höheren, sichereren Modus zu wechseln, indem die verschiedenen im Sicherheitsmanager und im GAP verfügbaren Mittel genutzt werden. GATT-Transaktionen können als Auslöser für ein solches Authentifizierungsverfahren dienen. Wie in "Berechtigungen" beschrieben , verfügt jedes Attribut eines GATT-Servers über fein abgestufte, unabhängige Lese- und Schreibberechtigungen, die auf ATT-Ebene durchgesetzt werden.

Generell gilt, dass der Zugriff auf Attribute, die Deklarationen sind, keine besondere Sicherheit erfordert. Das gilt sowohl für Dienst- als auch für Merkmalsdeklarationen, nicht aber für Deskriptor-Deklarationen, die die relevanten Daten direkt in ihnen und nicht in einem separaten Attribut enthalten. Dies geschieht, damit Clients, die sich noch nicht mit einem Server gepaart oder verbunden haben, zumindest eine grundlegende Dienst- und Merkmalsermittlung durchführen können, ohne auf Sicherheitsverfahren zurückgreifen zu müssen. Das Attributlayout und die Datenhierarchie eines Servers werden nicht als sensible Informationen betrachtet und sind daher für alle Kunden frei zugänglich.

Beim Zugriff auf einen Merkmalswert oder eine Deskriptor-Deklaration (auch Service Request genannt) kann ein Client jedoch ein ATT-Paket als Fehlerantwort erhalten (siehe "ATT-Operationen"), das anzeigt, dass die aktuelle Sicherheitsstufe der Verbindung nicht hoch genug ist, um die Anfrage auszuführen. Die folgenden zwei Fehlercodes werden in der Regel für diesen Zweck verwendet und in das Fehlerantwortpaket eingefügt:

Unzureichende Authentifizierung

Bedeutet, dass der Link nicht verschlüsselt ist und dass der Server keinen Langzeitschlüssel (LTK, erstmals vorgestellt in "Sicherheitsschlüssel") zur Verschlüsselung des Links zur Verfügung hat, oder dass der Link zwar verschlüsselt ist, aber der LTK, der zur Durchführung des Verschlüsselungsvorgangs verwendet wird, nicht authentifiziert ist (mit Man-in-the-Middle-Schutz erzeugt; siehe "Authentifizierung"), während die Berechtigungen eine authentifizierte Verschlüsselung erfordern.

Unzureichende Verschlüsselung

Bedeutet, dass die Verbindung nicht verschlüsselt ist, aber eine geeignete LTK verfügbar ist.

GAP- und GATT-Rollen sind in keiner Weise miteinander verknüpft und können frei kombiniert werden, aber Sicherheitsverfahren werden immer von der GAP-Zentrale initiiert (siehe "Security Manager (SM)"). Je nachdem, welcher Peer als Zentrale und welcher als Peripherie agiert, kann es also entweder dem GATT-Client oder dem GATT-Server obliegen, das Pairing-, Bonding- oder Verschlüsselungsverfahren einzuleiten, um die Sicherheitsstufe der Verbindung zu erhöhen. Sobald die Sicherheitsstufe mit den Berechtigungen des Attributs übereinstimmt, kann der Client die Anfrage erneut zur Ausführung an den Server senden.

GATT-Dienst

Genauso wie GAP einen eigenen SIG-spezifizierten Dienst hat, der für alle Geräte verpflichtend ist (ausführlich beschrieben in "GAP-Dienst"), hat auch GATT einen eigenen Dienst (der bis zu einem Merkmal enthält), der in allen GATT-Servern enthalten sein muss. Der optionale Dienst changed characteristic (kurz vorgestellt in "Attribute Caching"), kann nicht gelesen oder geschrieben werden und sein Wert wird dem Client nur über die Merkmalswertangaben mitgeteilt.

Wie in Tabelle 4-8 dargestellt, besteht der Wert nur aus einem Handle-Bereich, der einen bestimmten Bereich von Attributen im Server abgrenzt. Dies ist der Bereich, der von strukturellen Änderungen betroffen ist und vom Kunden neu entdeckt werden muss. Der Kunde muss in diesem Bereich eine Dienst- und Merkmalserkennung durchführen, da die Attribute, die er zwischengespeichert haben kann, möglicherweise nicht mehr gültig sind.

Tabelle 4-8. Dienst geänderter Merkmalswert
Henkel Typ Erlaubnisse Wert Wert Länge

0xNNNN

UUID-Dienstgeändert

Keine

Betroffener Griffbereich

4

Ein Client muss für dieses Merkmal zunächst Angaben auf der entsprechenden CCCD aktivieren, damit er über Änderungen in der Attributstruktur des Servers informiert wird.

Wenn der Server eine strukturelle Änderung im Attribut-Layout erfährt, sendet er sofort eine Handle-Wert-Angabe an den Client und wartet auf die entsprechende Bestätigung. Auf diese Weise kann er sicher sein, dass der Kunde versteht, dass zwischengespeicherte Attribut-Handles in diesem Bereich möglicherweise nicht mehr gültig sind. Wenn sich die Attribute außerhalb der Lebensdauer einer Verbindung mit einem gebundenen Gerät ändern, sendet der Server den Hinweis gleich nach dem Verbindungsaufbau, damit der Kunde die Chance hat, den betroffenen Bereich wiederzufinden.

Get Erste Schritte mit Bluetooth Low Energy now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial