{"id":84024,"date":"2020-06-04T19:42:32","date_gmt":"2020-06-04T17:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty"},"modified":"2020-06-04T19:42:32","modified_gmt":"2020-06-04T17:42:32","slug":"ble-pod-mikroskopom-atty-gatty","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","title":{"rendered":"BLE unter dem Mikroskop (ATTs, GATTs...)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"BLE<\/p>\n

BLE unter dem Mikroskop (ATTs, GATTs...)<\/h2>\n

Teil 1, \u00dcberblick<\/b><\/p>\n

Es ist schon einige Zeit vergangen, seit die erste Spezifikation f\u00fcr Bluetooth 4.0 ver\u00f6ffentlicht wurde. Obwohl das Thema BLE sehr interessant ist, schreckt es viele Entwickler aufgrund seiner Komplexit\u00e4t ab. In meinen vorherigen Artikeln habe ich haupts\u00e4chlich die untersten Ebenen, Link Layer und Physical Layer, behandelt. Dies verhinderte, dass ich mich mit so komplexen und verworrenen Konzepten wie dem Attribut-Protokoll (ATT) und dem allgemeinen Attributprofil (GATT) befassen musste. Allerdings gibt es keinen Weg daran vorbei: Ohne Verst\u00e4ndnis dieser Konzepte ist die Entwicklung kompatibler Ger\u00e4te nicht m\u00f6glich. Heute m\u00f6chte ich dieses Wissen mit Ihnen teilen. In meinem Artikel werde ich mich auf Tutorial<\/a><\/noindex> Einsteigerressourcen von Nordic st\u00fctzen. Also, lassen Sie uns beginnen.
\n<\/a><\/noindex><\/p>\n

Warum ist alles so kompliziert?<\/h3>\n

\nMeiner Meinung nach war sofort klar, dass die Verwaltung von Ger\u00e4ten \u00fcber Smartphones ein sehr vielversprechendes und langfristiges Thema ist. Daher haben wir beschlossen, es von Anfang an strukturiert und maximal auszubauen. So k\u00f6nnen Hersteller verschiedener Ger\u00e4te keine eigenen Protokolle entwickeln, die dann nicht kompatibel sind. Dies f\u00fchrte zu einer gewissen Komplexit\u00e4t. Schon in der ersten Phase haben wir versucht, im BLE-Protokoll alles unterzubringen, was nur m\u00f6glich war \u2013 unabh\u00e4ngig davon, ob es sp\u00e4ter n\u00fctzlich sein wird oder nicht. Au\u00dferdem haben wir die M\u00f6glichkeit vorgesehen, die Liste der Ger\u00e4te in Zukunft zu erweitern.<\/p>\n

Lassen Sie uns einen Blick auf das Bild werfen, das das Protokollschema von BLE zeigt. Es besteht aus mehreren Schichten. Die unterste, die physische Schicht (PHY), ist f\u00fcr den Funkkanal des Ger\u00e4tes verantwortlich. Die Link-Schicht (LL) enth\u00e4lt die gesamte Byte-Sequenz der gesendeten Nachricht. In fr\u00fcheren Artikeln haben wir uns genau damit besch\u00e4ftigt. Das Host Controller Interface (HCI) ist das Protokoll f\u00fcr den Austausch zwischen den Schichten oder Chips von BLE, wenn der Controller und das Host auf unterschiedlichen Chips implementiert sind. F\u00fcr die Paketbildung, die Segmentierung in Frames, die Fehlerkontrolle und das Zusammenf\u00fcgen von Paketen ist das Logical Link Control and Adaptation Protocol (L2CAP) zust\u00e4ndig. Die Verschl\u00fcsselung der Pakete erfolgt durch das Security Manager Protocol (SMP). Das General Access Profile (GAP) ist f\u00fcr den initialen Datenaustausch zwischen den Ger\u00e4ten verantwortlich, um festzustellen, \u201ewer wer ist\u201c. Dazu geh\u00f6ren auch Scanning und Advertising. In diesem Artikel werde ich auf die beiden verbleibenden Teile des Protokolls eingehen \u2013 GATT und ATT. GATT ist eine Erweiterung von ATT, weshalb sie eng miteinander verwoben sind.<\/p>\n

\"BLE
\n
\nUm die Erz\u00e4hlung zu vereinfachen, m\u00f6chte ich eine Analogie verwenden. Ich habe sie irgendwo geh\u00f6rt und m\u00f6chte sie unterst\u00fctzen. Stellen Sie sich ein BLE-Ger\u00e4t als ein B\u00fccherregal mit mehreren Regalen vor. Jedes Regal repr\u00e4sentiert ein bestimmtes Thema. Zum Beispiel haben wir Regale mit Science-Fiction, Mathematik und Enzyklop\u00e4dien. Auf jedem Regal stehen B\u00fccher zu dem angegebenen Thema. In manchen B\u00fcchern befinden sich sogar Papiermarkierungen mit Notizen. Dar\u00fcber hinaus haben wir einen kleinen Papierkatalog aller B\u00fccher. Wenn Sie sich an Schulbibliotheken erinnern \u2014 das ist ein schmaler Kasten mit Papierkarten. In dieser Analogie ist das Regal das Profil unseres Ger\u00e4ts. Die Regale sind die Dienste, die B\u00fccher sind die Eigenschaften und der Katalog ist die Attributtabelle. Die Markierungen in den B\u00fcchern sind die Deskriptoren, \u00fcber die ich sp\u00e4ter noch ausf\u00fchrlicher sprechen werde.<\/p>\n

Jeder, der Ger\u00e4te entwickelt, wei\u00df, dass in vielen Projekten \u00e4hnliche Code Fragmente vorhanden sind. Das liegt daran, dass viele Ger\u00e4te \u00e4hnliche Funktionen bieten. Zum Beispiel wird bei Ger\u00e4ten, die mit Akkus betrieben werden, das Problem des Ladevorgangs und der \u00dcberwachung des Akkustands gleich sein. Dasselbe gilt f\u00fcr Sensoren. Tats\u00e4chlich verfolgt der objektorientierte Programmieransatz \u201edie M\u00f6glichkeit, Objekte zu erstellen, die Eigenschaften und Verhaltensweisen in einer eigenst\u00e4ndigen Einheit verbinden, die dann mehrfach verwendet werden kann\u201c<\/i>. Meiner Meinung nach wurde im BLE ein \u00e4hnlicher Ansatz verfolgt. Die Gruppe der Bluetooth Special Interest Group (SIG) hat Profile entwickelt. Ger\u00e4te verschiedener Hersteller, die \u00fcber dieselben Profile verf\u00fcgen, sollten problemlos miteinander arbeiten. Die Profile bestehen wiederum aus Diensten, und die Dienste aus Merkmalen, die durch Deskriptoren erg\u00e4nzt werden. Allgemein k\u00f6nnte das so aussehen:<\/p>\n

\"BLE
\n
\nAls Beispiel betrachten wir das Profil des Herzfrequenzmonitors (Fitnessarmband). Es besteht aus zwei Diensten und mehreren Eigenschaften. Dadurch wird die Hierarchie des Profils sofort verst\u00e4ndlich. Die Eigenschaft des Kontrollpunkts setzt die Gesamtkalorienverbrauchsz\u00e4hlung auf null zur\u00fcck. <\/p>\n

1. Der Herzfrequenzdienst umfasst drei Eigenschaften (0x180D):
\n    a) Obligatorische Eigenschaft der Herzfrequenz (0x2A37)
\n    b) Optionale Eigenschaft der K\u00f6rperpositionssensorik (0x2A38)
\n    c) Bedingte Eigenschaft des Herzfrequenzkontrollpunkts (0x2A39)
\n2. Der Batteriedienst (0x180F):
\n    a) Obligatorische Eigenschaft des Batteriestands (0x2A19)<\/p>\n

UUID<\/h3>\n

\nUm eindeutig auf die Profilelemente (Dienste, Merkmale und Deskriptoren) zugreifen zu k\u00f6nnen, m\u00fcssen wir ihnen eine Nummer zuweisen. Hierzu wird das Konzept der Universally Unique ID (UUID) oder des Universellen eindeutigen Identifikators eingef\u00fchrt. In Klammern jeder Zeile ist genau dieser UUID angegeben. Dabei gibt es eine Besonderheit: F\u00fcr UUIDs hat man sich f\u00fcr eine L\u00e4nge von 16 und 128 Bit entschieden. Warum, fragen Sie sich? Im BLE-Protokoll steht die Energieeinsparung im Vordergrund. Daher erscheint die Dimension von 16 Bit durchaus sinnvoll. Wohl kaum werden in naher Zukunft mehr als 65.000 einzigartige Dienste und Merkmale entstehen. Bis jetzt ist alles, was m\u00f6glich war, bereits gez\u00e4hlt worden (merken Sie sich, woher das kommt \u2014 \u201eer hat auch Sie gez\u00e4hlt\u201c :-)). Nummerierte Elemente Profilelemente<\/a><\/noindex>, Dienste<\/a><\/noindex>, Merkmale<\/a><\/noindex> und Deskriptoren<\/a><\/noindex> k\u00f6nnen Sie \u00fcber die Links einsehen.<\/p>\n

Ich denke, jeder erinnert sich an die Geschichte mit den 4 Byte IP-Adressen im Internet. Zun\u00e4chst dachte man, das reicht aus, aber wir haben es immer noch nicht geschafft, auf 6-Byte-Adressen umzusteigen. Um einen solchen Fehler nicht zu wiederholen und den kreativen K\u00f6pfen von Hobbybastlern nicht zu viel Raum zu geben, hat SIG beschlossen, auch 128-Bit UUIDs einzuf\u00fchren. Das erinnert mich an den nicht lizenzierten Frequenzbereich von 433 MHz, der verschiedenen Erfindern \u00fcberlassen wurde. In unserem Fall wurde der 128-Bit-Identifikator f\u00fcr Dienste und Merkmale freigegeben. Das bedeutet, dass wir f\u00fcr unsere Dienste und Ger\u00e4te nahezu jeden beliebigen 128-Bit-Wert verwenden k\u00f6nnen. Die Wahrscheinlichkeit, einen identischen UUID zu erstellen, neigt gegen null.<\/p>\n

In der Tat haben die kurzen 16-Bit UUIDs ihre Erweiterung auf 128-Bit-Werte. In der Spezifikation wird diese Erweiterung als Bluetooth Basis UUID bezeichnet und hat den Wert 00000000-0000-1000-8000-00805F9B34FB. Wenn die 16-Bit UUID eines Attributs beispielsweise den Wert 0x1234 hat, dann wird die entsprechende 128-Bit UUID den Wert 00001234-0000-1000-8000-00805F9B34FB haben. Es wird sogar die entsprechende Formel angegeben:<\/p>\n

                                128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID<\/p>\n

Woher diese magische Zahl stammt, ist mir nicht bekannt. Wenn einer der Leser es wei\u00df, m\u00f6ge er es in den Kommentaren schreiben (Der Nutzer mit dem Nickname Sinopteek hat das bereits getan. Siehe Kommentare). Was die Erstellung von 128-Bit UUIDs betrifft, so kann man im Grunde einen speziellen Generator<\/a><\/noindex>verwenden, der das f\u00fcr Sie erledigt.<\/p>\n

ATT\u044b GATT\u044b…<\/h3>\n

\n Nun kommt der spannendste Teil. Ich m\u00f6chte daran erinnern, dass ATT auf einem Client-Server-Modell basiert. Jetzt betrachten wir die Struktur des Servers. Dieser enth\u00e4lt Informationen wie Sensorwerte, den Zustand des Lichtschalters, Standortdaten usw. Jetzt, da alle \u00abTeilnehmer unserer Parade\u00bb nummeriert sind, m\u00fcssen wir sie im Speicher des Ger\u00e4ts anordnen. Daf\u00fcr legen wir sie in eine Tabelle, die als Attributtabelle bekannt ist. Merken Sie sich das gut. Das ist das Herzst\u00fcck von BLE. Genau das werden wir hier weiter betrachten. Jede Zeile nennen wir ein Attribut. Diese Tabelle befindet sich tief im Stack und normalerweise haben wir keinen direkten Zugriff darauf. Wir initialisieren sie und greifen auf sie zu, aber was intern geschieht, bleibt uns hinter sieben Siegeln verborgen. <\/p>\n

Betrachten wir das Bild aus den Spezifikationen, jedoch m\u00f6chte ich zuvor auf die h\u00e4ufige Verwirrung in den Begriffen hinweisen, insbesondere in Bezug auf Deskriptoren. Die Rolle des Deskriptors besteht darin, die Beschreibung einer Eigenschaft zu erg\u00e4nzen. Wenn es notwendig ist, die M\u00f6glichkeiten zu erweitern, werden Deskriptoren verwendet. Sie sind ebenfalls Attribute und werden zusammen mit den Services und Eigenschaften in der Attributtabelle angeordnet. Wir werden diese im zweiten Teil des Artikels ausf\u00fchrlich behandeln. Es kommt jedoch vor, dass Deskriptoren die Zeilennummer in der Attributtabelle bezeichnen. Das sollte man im Hinterkopf behalten. Um keine Verwirrung zu stiften, werden wir f\u00fcr diese Zwecke den Begriff \u201eAttributzeiger\u201c verwenden.
\n\"BLE
\n
\nSo ist ein Attribut \u2014 ein diskretes Wert, das die folgenden Eigenschaften besitzt:
\n1. Attributzeiger (Attribute Handle) \u2014 ist der Index in der Tabelle, der dem Attribut entspricht.
\n2. Attributtyp (Attribute Type) \u2014 ist eine UUID, die seinen Typ beschreibt.
\n3. Attributwert (Attribute Value) \u2014 sind die Daten, die durch den Attributzeiger indiziert werden.
\n4. \u0420\u0430\u0437\u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0430\u0442\u0440\u0438\u0431\u0443\u0442\u043e\u0432 (Attribute Permissions) \u2014 \u044d\u0442\u043e \u0447\u0430\u0441\u0442\u044c \u0430\u0442\u0440\u0438\u0431\u0443\u0442\u0430, \u0440\u0430\u0437\u0440\u0435\u0448\u0435\u043d\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0435     \u043c\u043e\u0433\u0443\u0442 \u0431\u044b\u0442\u044c \u043f\u0440\u043e\u0447\u0438\u0442\u0430\u043d\u044b \u0438\u043b\u0438 \u0437\u0430\u043f\u0438\u0441\u0430\u043d\u044b \u0441 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435\u043c \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0430 \u0430\u0442\u0440\u0438\u0431\u0443\u0442\u043e\u0432<\/p>\n

Wie ist das alles zu verstehen? Ein Attributzeiger ist sozusagen seine Nummer in unserer Tabelle.
\nEr erm\u00f6glicht es dem Kunden, auf das Attribut in Lese- oder Schreibanfragen zu verweisen. Wir k\u00f6nnen unsere Zeilen (Attribute) von 0x0001 bis 0xFFFF nummerieren. In unserer Assoziation mit einem B\u00fccherregal entspricht dies der Nummer der Karte im Papierkatalog. \u00c4hnlich wie im Bibliothekskatalog sind die Karten in aufsteigender Reihenfolge angeordnet. Die Nummer jeder nachfolgenden Zeile muss gr\u00f6\u00dfer als die vorherige sein. Wie in einer Bibliothek k\u00f6nnen manchmal Karten verloren gehen, so k\u00f6nnen auch in unserer Zeilennummerierung L\u00fccken auftreten. Das ist zul\u00e4ssig. Wichtig ist, dass sie in aufsteigender Reihenfolge fortlaufen.<\/p>\n

Der Typ des Attributs bestimmt, was dieses Attribut darstellt. \u00c4hnlich wie in der Programmiersprache C,
\nwo es boolesche, numerische Variablen und Strings gibt, ist es auch hier. Anhand des Typs des Attributs erfahren wir,
\nmit was wir es zu tun haben und wie wir weiter mit diesem Attribut arbeiten k\u00f6nnen. Nachfolgend werden wir einige spezifische Typen von Attributen betrachten. Zum Beispiel die \u201eService-Deklaration\u201c (0x2800), die \u201eCharakteristik-Deklaration\u201c (0x2803) und die \u201eDescriptor-Deklaration\u201c (0x2902).<\/p>\n

Der Wert eines Attributs ist sein tats\u00e4chlicher Wert, um es einfach auszudr\u00fccken. Ist der Typ des Attributs ein String, k\u00f6nnte der Wert beispielsweise das Motto \u201eHello World !!!\u201c sein. Handelt es sich um eine \u201eServiceerkl\u00e4rung\u201c, so ist der Wert der Service selbst. Manchmal handelt es sich auch um Informationen, wo andere Attribute und deren Eigenschaften zu finden sind.<\/p>\n

Die Berechtigungen der Attribute erm\u00f6glichen es dem Server zu verstehen, ob der Zugriff auf Lesen oder Schreiben erlaubt ist.
\nBitte beachten Sie, dass diese Berechtigungen nur f\u00fcr den Wert des Attributs gelten und nicht f\u00fcr die Zeiger, den Typ oder das Feld der Berechtigungen selbst. Das hei\u00dft, wenn das Schreiben des Attributs erlaubt ist, k\u00f6nnen wir beispielsweise \u201eHello World !!!\u201c in \u201eGood morning\u201c \u00e4ndern. Wir k\u00f6nnen jedoch nicht das Hinzuf\u00fcgen einer neuen Zeile verbieten oder den Typ des Attributs \u00e4ndern und die Zeile als \u201eServiceerkl\u00e4rung\u201c kennzeichnen. Wenn der Client den Server anspricht, fragt der Client nach seinen Attributen. Dies erm\u00f6glicht es dem Client zu erfahren, was der Server bereitstellen kann. Es ist jedoch nicht unbedingt erforderlich, Werte zu lesen oder zu schreiben.<\/p>\n

So sieht das aus<\/h3>\n

\nDas Konzept von GATT besteht darin, die Attribute in der Attributtabelle in einer sehr spezifischen und logischen Reihenfolge zu gruppieren. Werfen wir einen genaueren Blick auf das nachstehende Profil der Herzfrequenz. Die ganz linke Spalte dieser Tabelle ist nicht verpflichtend. Sie beschreibt lediglich, was diese Zeile (Attribut) darstellt. Alle anderen Spalten sind uns bereits vertraut.<\/p>\n

\"BLE
\n
\nAm oberen Ende jeder Gruppe haben wir immer das Attribut der Dienstbeschreibung. Sein Typ ist immer 0x2800, und der Zeiger h\u00e4ngt davon ab, wie viele Attribute bereits in der Tabelle vorhanden sind. Seine Berechtigungen sind stets nur lesbar, ohne irgendeine Authentifizierung oder Autorisierung. \u00dcber diese Konzepte werden wir sp\u00e4ter sprechen. Der Wert ist ein weiterer UUID, der definiert, um welchen Dienst es sich handelt. In der Tabelle hat der Wert 0x180D, der von der Bluetooth SIG als Dienst f\u00fcr Herzfrequenz definiert wird. <\/p>\n

Nach der Ank\u00fcndigung des Dienstes folgt die Beschreibung der Eigenschaften. In seiner Form ist es \u00e4hnlich wie die Ank\u00fcndigung des Dienstes. Seine UUID hat immer den Wert 0x2803, und die Berechtigungen sind ebenfalls stets nur lesbar, ohne jegliche Authentifizierung oder Autorisierung. Schauen wir uns das Feld 'Attributwert' an, das einige Daten enth\u00e4lt. Es enth\u00e4lt immer einen Zeiger, eine UUID und eine Menge von Eigenschaften. Diese drei Elemente beschreiben die anschlie\u00dfende Anzeige des Attributwerts. Der Zeiger gibt nat\u00fcrlicherweise die Position der Anzeige des Attributwerts in der Attributtabelle an. Die UUID beschreibt, welche Art von Information oder Wert wir erwarten k\u00f6nnen. Zum Beispiel den Temperaturwert, den Zustand des Lichtschalters oder einen anderen beliebigen Wert. Und schlie\u00dflich die Eigenschaften, die beschreiben, wie man mit dem Attributwert interagieren kann. <\/p>\n

Hier erwartet uns ein weiteres Hindernis. Es bezieht sich auf die Berechtigungen der Attribute und die Eigenschaften der Merkmale. Lassen Sie uns das Bild der Bitfeld-Eigenschaften aus der Spezifikation betrachten.<\/p>\n

\"BLE
\n
\nWie Sie sehen, gibt es hier ebenso Felder, die Lese- und Schreibm\u00f6glichkeiten bieten. Sie fragen sich vielleicht, warum wir Lese-\/Schreibberechtigungen f\u00fcr die Attribute und Eigenschaften haben.
\nSo sollten die Lesef\u00e4higkeit und Schreibf\u00e4higkeit f\u00fcr den Wert der Eigenschaft nicht immer gleich sein? Tats\u00e4chlich sind die Eigenschaften f\u00fcr den Wert der Eigenschaft lediglich Empfehlungen f\u00fcr den Kunden, die in GATT und Anwendungsschichten verwendet werden. Es sind einfach Hinweise darauf, was der Kunde von dem Attribut der Merkmalsbeschreibung erwarten kann. Lassen Sie uns das genauer betrachten. Welche Arten von Berechtigungen gibt es f\u00fcr das Attribut? <\/p>\n

1. Zugriffsberechtigungen:
\n     \u2014 Lesen
\n     \u2014 Schreiben
\n     \u2014 Lesen und Schreiben
\n2. Authentifizierungsberechtigung:
\n     \u2014 Authentifizierung erforderlich
\n     \u2014 Authentifizierung nicht erforderlich
\n3. Autorisierungsberechtigung:
\n     \u2014 Autorisierung erforderlich
\n     \u2014 Autorisierung nicht erforderlich<\/p>\n

Der Hauptunterschied zwischen den Berechtigungen von Attributen und den Eigenschaften von Merkmale besteht darin, dass erstere sich auf Server beziehen, w\u00e4hrend letztere auf Clients zutreffen. Ein Server kann beispielsweise das Lesen des Wertes einer Eigenschaft erlauben, jedoch k\u00f6nnte eine Authentifizierung oder Autorisierung erforderlich sein. Daher erhalten wir bei der Abfrage von Eigenschaftswerten durch den Client die R\u00fcckmeldung, dass das Lesen erlaubt ist, jedoch tritt bei einem Leseversuch ein Fehler auf. Daher kann man mit Sicherheit sagen, dass Berechtigungen \u00fcber den Eigenschaften stehen. Informationen dar\u00fcber, welche Berechtigungen ein Attribut hat, k\u00f6nnen wir von der Client-Seite aus nicht abrufen.<\/p>\n

Deskriptor<\/h3>\n

\nLassen Sie uns zu unserer Tabelle zur\u00fcckkehren. Nach der Deklaration eines Eigenschaftswertes sind folgende Attributdeklarationen m\u00f6glich:
\n1. Neue Deklaration eines Merkmals (es kann viele Merkmale im Dienst geben)
\n2. Neue Deklaration eines Dienstes (es kann viele davon in der Tabelle geben)
\n3. Deklaration des Deskriptors <\/p>\n

Wenn es um die Messung der Herzfrequenz geht, wird in unserer Tabelle der Wert der Eigenschaft von einer Beschreibung begleitet. Die Beschreibung ist ein Attribut mit zus\u00e4tzlichen Informationen zur Eigenschaft. Es gibt mehrere Arten von Beschreibungen. Auf diese werden wir in Teil zwei dieses Artikels ausf\u00fchrlich eingehen. Jetzt betrachten wir nur den Konfigurationsdescriptor der Kundeneigenschaft (Client Characteristic Configuration Descriptor \u2013 CCCD). Dieser hat eine UUID von 0x2902. Mit diesem Descriptor hat der Kunde die M\u00f6glichkeit, die Anzeige oder Benachrichtigung auf dem Server zu aktivieren. Der Unterschied zwischen beiden ist gering, besteht aber dennoch. Eine Benachrichtigung ben\u00f6tigt keine Best\u00e4tigung des Empfangs durch den Kunden. Eine Anzeige hingegen erfordert diese Best\u00e4tigung, auch wenn sie auf GATT-Ebene erfolgt und nicht bis zur Anwendungsebene reicht. Warum ist das so, fragen Sie sich? Leider kann ich Ihnen das nicht sagen. Ich kann nur erw\u00e4hnen, dass die Experten von Nordic empfehlen, die Benachrichtigung zu nutzen. Zumal die Integrit\u00e4tspr\u00fcfung des Pakets (mittels CRC) in beiden F\u00e4llen erfolgt.<\/p>\n

Fazit<\/h3>\n

\nAm Ende des Artikels m\u00f6chte ich Folgendes sagen. Die letzte Tabelle ist etwas verwirrend. Ich habe mich jedoch daf\u00fcr entschieden, sie wiederzugeben, weil sie in Artikel<\/a><\/noindex>, auf die ich mich st\u00fctze. Im zweiten Teil meines Artikels beabsichtige ich, tiefer in die Spezifikationen von Bluetooth 4.0 einzutauchen. Dort erwarten uns genauere Diagramme und Illustrationen. Im dritten Teil m\u00f6chte ich ein Protokoll analysieren, das mit dem Programm Wireshark von einem der Ger\u00e4te erfasst wurde, und die gesamte Theorie, die wir gemeinsam erarbeitet haben, \u201elive\u201c sehen.<\/p>\n

Mitarbeiter der Unternehmensgruppe \u201eC\u00e4sar Satellit\u201c<\/a><\/noindex>
\nWladimir Petscherski
\n
Quelle: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

BLE \u043f\u043e\u0434 \u043c\u0438\u043a\u0440\u043e\u0441\u043a\u043e\u043f\u043e\u043c (ATT\u044b GATT\u044b…) \u0427\u0430\u0441\u0442\u044c 1, \u043e\u0431\u0437\u043e\u0440\u043d\u0430\u044f \u0423\u0436\u0435 \u043f\u0440\u043e\u0448\u043b\u043e \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u0432\u0440\u0435\u043c\u044f, \u0441 \u0442\u0435\u0445 \u043f\u043e\u0440, \u043a\u043e\u0433\u0434\u0430 \u0432\u044b\u0448\u043b\u0430 \u043f\u0435\u0440\u0432\u0430\u044f \u0441\u043f\u0435\u0446\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u044f \u043d\u0430 Bluetooth 4.0. \u0418, \u0445\u043e\u0442\u044f \u0442\u0435\u043c\u0430 BLE \u043e\u0447\u0435\u043d\u044c \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u0430, \u043e\u043d\u0430 \u0434\u043e \u0441\u0438\u0445 \u043f\u043e\u0440 \u043e\u0442\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442 \u043c\u043d\u043e\u0433\u0438\u0445 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432, \u0438\u0437-\u0437\u0430 \u0441\u0432\u043e\u0435\u0439 \u0441\u043b\u043e\u0436\u043d\u043e\u0441\u0442\u0438. \u0412 \u0441\u0432\u043e\u0438\u0445 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0438\u0445 \u0441\u0442\u0430\u0442\u044c\u044f\u0445 \u044f \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u043b \u0432 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u043c \u0441\u0430\u043c\u044b\u0439 \u043d\u0438\u0436\u043d\u0438\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c Link Layer \u0438 Physical Layer. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84025,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84024","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47BLE unter dem Mikroskop (ATTs GATTs\u2026) | ProHoster","description":"BLE unter dem Mikroskop (ATTs GATTs...) Teil 1, \u00dcberblick. Es ist schon einige Zeit vergangen, seit die erste Spezifikation f\u00fcr Bluetooth 4.0 ver\u00f6ffentlicht wurde. Und obwohl das Thema BLE sehr interessant ist, schreckt es viele Entwickler aufgrund seiner Komplexit\u00e4t weiterhin ab. In meinen vorherigen Artikeln habe ich haupts\u00e4chlich die untersten Ebenen, die Linkschicht und die physikalische Schicht, behandelt.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47BLE \u043f\u043e\u0434 \u043c\u0438\u043a\u0440\u043e\u0441\u043a\u043e\u043f\u043e\u043c (ATT\u044b GATT\u044b\u2026) | ProHoster","og:description":"BLE \u043f\u043e\u0434 \u043c\u0438\u043a\u0440\u043e\u0441\u043a\u043e\u043f\u043e\u043c (ATT\u044b GATT\u044b...) \u0427\u0430\u0441\u0442\u044c 1, \u043e\u0431\u0437\u043e\u0440\u043d\u0430\u044f \u0423\u0436\u0435 \u043f\u0440\u043e\u0448\u043b\u043e \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u0432\u0440\u0435\u043c\u044f, \u0441 \u0442\u0435\u0445 \u043f\u043e\u0440, \u043a\u043e\u0433\u0434\u0430 \u0432\u044b\u0448\u043b\u0430 \u043f\u0435\u0440\u0432\u0430\u044f \u0441\u043f\u0435\u0446\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u044f \u043d\u0430 Bluetooth 4.0. \u0418, \u0445\u043e\u0442\u044f \u0442\u0435\u043c\u0430 BLE \u043e\u0447\u0435\u043d\u044c \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u0430, \u043e\u043d\u0430 \u0434\u043e \u0441\u0438\u0445 \u043f\u043e\u0440 \u043e\u0442\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442 \u043c\u043d\u043e\u0433\u0438\u0445 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432, \u0438\u0437-\u0437\u0430 \u0441\u0432\u043e\u0435\u0439 \u0441\u043b\u043e\u0436\u043d\u043e\u0441\u0442\u0438. \u0412 \u0441\u0432\u043e\u0438\u0445 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0438\u0445 \u0441\u0442\u0430\u0442\u044c\u044f\u0445 \u044f \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u043b \u0432 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u043c \u0441\u0430\u043c\u044b\u0439 \u043d\u0438\u0436\u043d\u0438\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c Link Layer \u0438 Physical Layer.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-04T17:42:32+00:00","article:modified_time":"2020-06-04T17:42:32+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84024","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:06:38","updated":"2022-09-28 11:11:59"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/84024","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=84024"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/84024\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/84025"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=84024"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=84024"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=84024"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}