BLE unter der Lupe (ATTы GATTы…)
Teil 1, Überblick
Seit der Veröffentlichung der ersten Spezifikation für Bluetooth 4.0 ist bereits eine ganze Weile vergangen. Und obwohl das BLE-Thema sehr interessant ist, schreckt es aufgrund seiner Komplexität dennoch viele Entwickler ab. In meinen vorherigen Artikeln habe ich mich hauptsächlich mit der untersten Ebene, der Verbindungsschicht und der physikalischen Schicht, befasst. Dadurch konnten wir vermeiden, auf so komplexe und verwirrende Konzepte wie das Attribute Protocol (ATT) und das General Attribute Profile (GATT) zurückgreifen zu müssen. Ohne sie zu verstehen, ist es jedoch unmöglich, kompatible Geräte zu entwickeln. Heute möchte ich dieses Wissen mit Ihnen teilen. In meinem Artikel werde ich mich darauf verlassen für Anfänger von der Nordic-Website. Also lasst uns anfangen.
Warum ist alles so schwer?
Meiner Meinung nach war sofort klar, dass die Verwaltung von Geräten über Smartphones ein vielversprechendes und nachhaltiges Thema ist. Deshalb beschlossen sie, es sofort und maximal zu strukturieren. Damit Hersteller verschiedener Gadgets keine eigenen Protokolle entwickeln, die dann inkompatibel sind. Daher die Schwierigkeit. Bereits in der ersten Phase wurde versucht, alles Mögliche in das BLE-Protokoll zu integrieren. Dabei spielt es keine Rolle, ob es später nützlich sein wird oder nicht. Darüber hinaus sahen sie die Möglichkeit vor, die Geräteliste für die Zukunft zu erweitern.
Schauen wir uns das Bild an, auf dem das BLE-Protokolldiagramm gezeichnet ist. Es besteht aus mehreren Schichten. Die unterste, physikalische Schicht (PHY) ist für den Funkkanal des Geräts verantwortlich. Link Layer (LL) enthält die gesamte Bytefolge in der übertragenen Nachricht. In früheren Artikeln haben wir genau das untersucht. Host Controller Interface (HCI) ist ein Austauschprotokoll zwischen BLE-Schichten oder Chips, wenn Controller und Host auf unterschiedlichen Chips implementiert sind. Das Logical Link Control and Adaptation Protocol (L2CAP) ist für die Paketbildung, das Framing, die Fehlerkontrolle und die Paketassemblierung verantwortlich. Für die Verschlüsselung der Pakete ist das Security Manager Protocol (SMP) verantwortlich. Das General Access Profile (GAP) ist für den anfänglichen Datenaustausch zwischen Geräten verantwortlich, um zu bestimmen, „Who is Who“. Dazu gehören auch Scannen und Werbung. In diesem Artikel werde ich mich auf die beiden verbleibenden Teile des Protokolls konzentrieren – GATT und ATT. Das GATT ist ein Überbau des ATT und daher eng miteinander verflochten.
Um die Geschichte zu vereinfachen, möchte ich auf eine Analogie zurückgreifen. Ich habe es irgendwo gehört und würde es gerne unterstützen. Stellen Sie sich ein BLE-Gerät wie ein Bücherregal mit mehreren Regalen vor. Jedes Regal ist ein eigenes Thema. Wir haben zum Beispiel Regale mit Science-Fiction, Mathematik und Enzyklopädien. In jedem Regal stehen Bücher zu einem bestimmten Thema. Und einige Bücher haben sogar Lesezeichen aus Papier mit Notizen. Darüber hinaus haben wir einen kleinen Papierkatalog aller Bücher. Wenn Sie sich erinnern, sind Schulbibliotheken eine schmale Schachtel mit Papierkarten. In dieser Analogie ist der Schrank das Profil unseres Geräts. Regale sind Dienstleistungen, Bücher sind Merkmale und der Katalog ist eine Attributtabelle. Lesezeichen in Büchern sind Deskriptoren, auf die ich später noch näher eingehen werde.
Jeder, der Geräte entwickelt hat, weiß, dass viele Projekte ähnliche Codeteile haben. Tatsache ist, dass viele Geräte über eine ähnliche Funktionalität verfügen. Wenn Geräte beispielsweise mit Batterien betrieben werden, ist das Problem des Ladens und der Überwachung ihres Füllstands dasselbe. Das Gleiche gilt für Sensoren. Eigentlich ein objektorientierter Programmieransatz „bietet die Möglichkeit, Objekte zu erstellen, die Eigenschaften und Verhaltensweisen zu einer in sich geschlossenen Einheit kombinieren, die dann wiederverwendet werden kann“. Meiner Meinung nach hat BLE einen ähnlichen Ansatz versucht. Profile wurden von der Bluetooth Special Interest Group (SIG) entwickelt. Geräte unterschiedlicher Hersteller mit gleichen Profilen sollten problemlos miteinander zusammenarbeiten. Profile wiederum bestehen aus Diensten und Diensten aus Merkmalen, ergänzt durch Deskriptoren. Im Allgemeinen könnte es so aussehen:
Betrachten Sie beispielsweise das Profildiagramm eines Herzfrequenzmessers (Fitnessarmband). Es besteht aus zwei Diensten und mehreren Merkmalen. Daraus wird sofort die Profilhierarchie deutlich. Das Checkpoint-Merkmal setzt die Gesamtkalorienverbrauchszählung auf Null zurück.
1. Der Herzfrequenzdienst umfasst drei Merkmale (0x180D):
a) Obligatorische Herzfrequenzkennlinie (0x2A37)
b) Optionale Positionscharakteristik des Körpersensors (0x2A38)
c) Bedingte Eigenschaften des Herzfrequenzkontrollpunkts (0x2A39)
2. Batteriewartungsservice (0x180F):
a) Kennlinie des obligatorischen Batterieladezustands (0x2A19)
UUID
Damit wir eindeutig auf Profilelemente (Dienste, Merkmale und Deskriptoren) zugreifen können, müssen wir sie alle irgendwie nummerieren. Zu diesem Zweck wird ein Konzept wie Universally Unique ID (UUID) oder Universally Unique Identifier eingeführt. Die UUID ist in den Klammern jeder Zeile angegeben. Und hier gibt es eine Besonderheit. Für die UUID haben wir uns entschieden, einen Code mit einer Länge von 16 und 128 Bit zu verwenden. Warum fragst du? Im BLE-Protokoll dreht sich alles um Energieeinsparung. Daher ist die Dimension von 16 Bit durchaus sinnvoll. Es ist unwahrscheinlich, dass in naher Zukunft mehr als 65 geschaffen werden. einzigartige Dienstleistungen und Eigenschaften. Im Moment waren alle möglichen Elemente bereits gezählt (denken Sie daran, woher das kam: „Er hat Sie auch gezählt“ :-)) Nummerierte Elemente , , и Sie können sich die Links ansehen.
Ich denke jedoch, dass sich jeder an die Geschichte mit 4 Bytes IP-Adressen im Internet erinnert. Zuerst dachten wir, das sei genug, aber jetzt können wir immer noch nicht auf eine 6-Byte-Adresse umstellen. Um diesen Fehler nicht zu wiederholen und den spielerischen Händen der Heimwerker freien Lauf zu lassen, entschied sich SIG umgehend für die Einführung von 128-Bit-UUIDs. Das erinnert mich persönlich an das nicht lizenzierte 433-MHz-Band, das vom Radiosender an alle möglichen Kulibins vergeben wurde. In unserem Fall wurde eine 128-Bit-Kennung von Diensten und Merkmalen ausgelagert. Das bedeutet, dass wir für unsere Dienste und Geräte nahezu jeden 128-Bit-Wert verwenden können. Dennoch tendiert die Wahrscheinlichkeit, auf die gleiche UUID zu stoßen, gegen Null.
Tatsächlich haben kurze 16-Bit-UUIDs ihre Erweiterung auf einen 128-Bit-Wert. In der Spezifikation heißt diese Erweiterung Bluetooth Base UUID und hat den Wert 00000000-0000-1000-8000-00805F9B34FB. Wenn beispielsweise die 16-Bit-Attribut-UUID den Wert 0x1234 hat, dann hat die entsprechende 128-Bit-UUID den Wert 00001234-0000-1000-8000-00805F9B34FB. Und sogar die entsprechende Formel ist angegeben:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Ich weiß nicht, woher diese magische Zahl kommt. Wenn es einer der Leser weiß, lassen Sie ihn in den Kommentaren schreiben (Ein Benutzer mit dem Spitznamen Sinopteek hat dies bereits getan. Siehe Kommentare). Was die Erstellung von 128-Bit-UUIDs betrifft, können Sie im Prinzip eine spezielle verwenden Wer wird es für Sie tun?
ATTy GATTy...
Eigentlich beginnt dann der Spaß. Ich möchte Sie daran erinnern, dass ATT auf einer Client-Server-Beziehung basiert. Jetzt schauen wir uns das Servergerät an. Es enthält Informationen wie Sensorwerte, Lichtschalterstatus, Standortdaten usw. Da nun alle „Teilnehmer unserer Parade“ nummeriert sind, müssen wir sie irgendwie im Speicher des Geräts ablegen. Dazu legen wir sie in einer Tabelle namens Attributtabelle ab. Merken Sie sich das gut. Dies ist das Herzstück von BLE. Darauf werden wir weiter eingehen. Jetzt nennen wir jede Zeile ein Attribut. Diese Tabelle liegt tief im Stapel und wir haben in der Regel keinen direkten Zugriff darauf. Wir initialisieren es und greifen darauf zu, aber was darin passiert, bleibt uns hinter sieben Siegeln verborgen.
Schauen wir uns das Bild aus der Spezifikation an, aber vorher möchte ich gleich auf die häufige Begriffsverwirrung, nämlich bei den Deskriptoren, aufmerksam machen. Die Rolle des Deskriptors besteht darin, die Beschreibung des Merkmals zu ergänzen. Wenn es notwendig ist, seine Fähigkeiten zu erweitern, werden Deskriptoren verwendet. Sie sind ebenfalls Attribute und befinden sich ebenso wie Dienste und Merkmale in der Attributtabelle. Wir werden sie im zweiten Teil des Artikels ausführlich untersuchen. Manchmal beziehen sich Deskriptoren jedoch auf die Zeilennummer in der Attributtabelle. Dies muss im Hinterkopf behalten werden. Um Verwirrung zu vermeiden, verwenden wir für diese Zwecke den Begriff „Attributzeiger“.
Ein Attribut ist also ein diskreter Wert, dem die folgenden Eigenschaften zugeordnet sind:
1. Attributhandle ist der Tabellenindex, der dem Attribut entspricht
2. Der Attributtyp ist eine UUID, die seinen Typ beschreibt
3. Der Attributwert sind die vom Attributzeiger indizierten Daten
4. Attributberechtigungen sind der Teil eines Attributs, die Berechtigungen, die mit dem Attributprotokoll nicht gelesen oder geschrieben werden können
Wie ist das alles zu verstehen? Der Attributzeiger ist relativ gesehen seine Nummer in unserer Tabelle.
Es ermöglicht einem Client, in Lese- oder Schreibanforderungen auf ein Attribut zu verweisen. Wir können unsere Zeilen (Attribute) von 0x0001 bis 0xFFFF nummerieren. In unserer Verbindung mit dem Bücherregal ist dies die Kartennummer im Papierkatalog. Ähnlich wie im Bibliothekskatalog sind die Karten in aufsteigender Reihenfolge der Nummer angeordnet. Die Nummer jeder nachfolgenden Zeile muss größer sein als die der vorherigen. Genau wie in der Bibliothek gehen manchmal Karten verloren, daher kann es bei uns zu Lücken in der Zeilennummerierung kommen. Dies ist erlaubt. Die Hauptsache ist, dass sie schrittweise voranschreiten.
Der Attributtyp bestimmt, was das Attribut darstellt. Analog zur C-Sprache gilt:
Wo es boolesche, numerische Variablen und Zeichenfolgen gibt, ist es hier. Anhand des Attributtyps erkennen wir
womit wir es zu tun haben und wie wir weiterhin mit diesem Attribut arbeiten können. Im Folgenden betrachten wir einige spezifische Arten von Attributen. Zum Beispiel „Dienstdeklaration“ (0x2800), „Merkmalsdeklaration“ (0x2803), „Deskriptordeklaration“ (0x2902).
Der Wert eines Attributs ist seine tatsächliche Bedeutung, verzeihen Sie die Tautologie. Handelt es sich bei dem Attributtyp um einen String, dann kann der Attributwert beispielsweise der Slogan „Hello World!!!“ sein. Wenn der Attributtyp eine „Dienstdeklaration“ ist, dann ist sein Wert der Dienst selbst. Und manchmal handelt es sich dabei um Informationen darüber, wo andere Attribute und deren Eigenschaften zu finden sind.
Mithilfe von Attributberechtigungen kann der Server erkennen, ob Lese- oder Schreibzugriff zulässig ist.
Beachten Sie, dass diese Berechtigungen nur für den Attributwert gelten und nicht für den Zeiger, den Typ oder das Berechtigungsfeld selbst. Diese. Wenn die Attributaufzeichnung erlaubt ist, können wir beispielsweise die Zeile „Hallo Welt!!!“ ändern. zur Zeile „Guten Morgen“. Aber wir können das Schreiben einer neuen Zeile nicht verbieten oder den Attributtyp ändern und die Zeile als „Dienstdeklaration“ bezeichnen. Wenn ein Client einen Server kontaktiert, fordert der Client dessen Attribute an. Dadurch kann der Client wissen, was der Server bereitstellen kann. Allerdings ist es nicht notwendig, die Werte zu lesen und zu schreiben.
Wie es aussieht
Das Konzept von GATT besteht darin, Attribute in einer Attributtabelle in einer sehr spezifischen und logischen Reihenfolge zu gruppieren. Schauen wir uns das Herzfrequenzprofil unten genauer an. Die Spalte ganz links in dieser Tabelle ist optional. Es beschreibt uns einfach, was diese Zeile (Attribut) ist. Alle anderen Spalten sind uns bereits bekannt.
Oben in jeder Gruppe befindet sich immer ein Dienstdeklarationsattribut. Sein Typ ist immer 0x2800 und der Zeiger hängt davon ab, wie viele Attribute bereits in der Tabelle vorhanden sind. Seine Berechtigungen sind immer schreibgeschützt, ohne jegliche Authentifizierung oder Autorisierung. Wir werden etwas später über diese Konzepte sprechen. Der Wert ist eine weitere UUID, die identifiziert, um welchen Dienst es sich handelt. In der Tabelle ist der Wert 0x180D, was von der Bluetooth SIG als Herzfrequenzdienst definiert wird.
Nach der Bekanntgabe des Dienstes erfolgt die Bekanntgabe des Merkmals. Die Form ähnelt einer Diensterklärung. Seine UUID ist immer 0x2803 und seine Berechtigungen sind immer schreibgeschützt, ohne jegliche Authentifizierung oder Autorisierung. Schauen wir uns das Feld „Attributwert“ an, das einige Daten enthält. Es enthält immer einen Zeiger, eine UUID und eine Reihe von Eigenschaften. Diese drei Elemente beschreiben die spätere Deklaration des Merkmalswertes. Der Zeiger gibt natürlich die Position der Merkmalswertdeklaration in der Attributtabelle an. Die UUID beschreibt, welche Art von Informationen oder Werten wir erwarten können. Zum Beispiel der Temperaturwert, der Zustand des Lichtschalters oder ein anderer beliebiger Wert. Und schließlich Eigenschaften, die beschreiben, wie mit dem Merkmalswert interagiert werden kann.
Hier erwartet uns eine weitere Gefahr. Es ist mit Attributberechtigungen und charakteristischen Eigenschaften verknüpft. Schauen wir uns das Bild der Bitfeldeigenschaften aus der Spezifikation an.
Wie Sie sehen, gibt es hier auch Felder, die Lese- und Schreibfunktionen bieten. Sie fragen sich vielleicht, warum wir Lese-/Schreibberechtigungen für Attribute und Eigenschaften haben
Lesen/Schreiben für Merkmalswert? Sollten sie nicht immer gleich sein? Tatsache ist, dass es sich bei den Eigenschaften für den Merkmalswert eigentlich nur um Empfehlungen für den Client handelt, der in GATT und Anwendungsschichten verwendet wird. Hierbei handelt es sich lediglich um Hinweise darauf, was der Client von dem charakteristischen Deklarationsattribut erwarten könnte. Schauen wir uns das genauer an. Welche Arten von Berechtigungen hat ein Attribut?
1. Zugriffsberechtigungen:
- lesen
- aufzeichnen
- lesen und Schreiben
2. Authentifizierungsberechtigung:
- Authentifizierung erforderlich
- Keine Authentifizierung erforderlich
3. Autorisierungserlaubnis:
- Autorisierung erforderlich
- keine Genehmigung erforderlich
Der Hauptunterschied zwischen Attributauflösung und charakteristischen Eigenschaften besteht darin, dass erstere für Server und letztere für Clients gelten. Der Server darf den charakteristischen Wert möglicherweise lesen, erfordert jedoch möglicherweise eine Authentifizierung oder Autorisierung. Wenn der Kunde die Eigenschaften des Merkmals anfordert, erhalten wir daher, dass das Lesen zulässig ist. Aber wenn wir versuchen zu lesen, erhalten wir eine Fehlermeldung. Daher können wir getrost über die Priorität von Berechtigungen gegenüber Eigenschaften sprechen. Auf der Clientseite können wir keine Kenntnis darüber erlangen, welche Berechtigungen ein Attribut hat.
Deskriptor
Kehren wir zu unserem Tisch zurück. Nach der Wertdeklaration eines Merkmals sind folgende Attributdeklarationen möglich:
1. Neue Merkmalsdeklaration (eine Leistung kann viele Merkmale haben)
2. Neue Serviceerklärung (in der Tabelle können viele davon vorhanden sein)
3. Deklarieren eines Handles
Beim Merkmal Herzfrequenzmessung steht in unserer Tabelle neben der Angabe des Merkmalswertes auch die Angabe des Deskriptors. Ein Deskriptor ist ein Attribut mit zusätzlichen Informationen zu einem Merkmal. Es gibt verschiedene Arten von Deskriptoren. Wir werden im zweiten Teil dieses Artikels ausführlich darüber sprechen. Im Moment gehen wir nur auf den Client Characteristic Configuration Descriptor (CCCD) ein. Es hat eine UUID gleich 0x2902. Mithilfe dieses Deskriptors hat der Client die Möglichkeit, die Anzeige oder Benachrichtigung auf dem Server zu aktivieren. Der Unterschied zwischen ihnen ist gering, aber immer noch da. Für die Benachrichtigung ist keine Empfangsbestätigung des Kunden erforderlich. Die Angabe erfordert dies, obwohl es auf der GATT-Ebene erfolgt und nicht die Anwendungsebene erreicht. Warum so, fragen Sie? Leider weiß ich das nicht. Lassen Sie mich nur sagen, dass nordische Experten die Verwendung von Benachrichtigungen empfehlen. Darüber hinaus erfolgt in beiden Fällen eine Überprüfung der Paketintegrität (mittels CRC).
Abschluss
Am Ende des Artikels möchte ich dies sagen. Die letzte Tabelle ist etwas verwirrend. Allerdings habe ich es gewählt, weil es gegeben ist worauf ich mich verlassen kann. Im zweiten Teil meines Artikels möchte ich tiefer auf die BlueTooth 4.0-Spezifikation eingehen. Dort erwarten uns weitere korrekte Diagramme und Zeichnungen. Im dritten Teil möchte ich das mit dem Wireshark-Programm von einem der Gadgets erhaltene Protokoll analysieren und die gesamte Theorie, die wir studieren, „live“ sehen.
Mitarbeiter der Unternehmensgruppe
Petscherskich Wladimir
Source: habr.com