Erste Schritte mit Bluetooth Low Energy

Kapitel 1. Einführung

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Bluetooth Low Energy (BLE, auch als Bluetooth Smart vermarktet) wurde als Teil der Bluetooth 4.0 Kernspezifikation eingeführt. Es ist verlockend, BLE als eine kleinere, hoch optimierte Version seines großen Bruders, des klassischen Bluetooth, darzustellen, aber in Wirklichkeit hat BLE eine ganz andere Herkunft und andere Ziele.

Ursprünglich von Nokia unter dem Namen Wibree entwickelt, bevor es von der Bluetooth Special Interest Group (SIG) übernommen wurde, wollten die Autoren nicht eine weitere, zu breit angelegte Funklösung vorschlagen, die versucht, jedes mögliche Problem zu lösen. Von Anfang an ging es darum, einen Funkstandard mit dem geringstmöglichen Stromverbrauch zu entwickeln, der speziell auf niedrige Kosten, geringe Bandbreite, geringen Stromverbrauch und geringe Komplexität optimiert ist.

Diese Ziele werden in der Kernspezifikation deutlich, die versucht, BLE zu einem echten Stromsparstandard zu machen, der von Siliziumherstellern implementiert und in der realen Welt mit einem knappen Energie- und Siliziumbudget eingesetzt werden kann. Es könnte der erste weit verbreitete Standard sein, der realistischerweise den Anspruch erhebt, über einen längeren Zeitraum mit einer einfachen Knopfzelle betrieben werden zu können, auch wenn viele andere Funktechnologien diesen Anspruch regelmäßig in ihrem Marketing erheben.

Was BLE anders macht

Bluetooth Low Energy ist zwar an sich eine gute Technologie, aber was BLE wirklich spannend macht und seine phänomenale Verbreitung so schnell vorangetrieben hat, ist, dass es die richtige Technologie mit den richtigen Kompromissen zur richtigen Zeit ist. Für einen relativ jungen Standard (er wurde 2010 eingeführt) hat sich BLE ungewöhnlich schnell durchgesetzt, und die Zahl der Produkte, die BLE bereits enthalten, zeigt, dass er anderen drahtlosen Technologien zum gleichen Zeitpunkt weit voraus ist.

Im Vergleich zu anderen Funkstandards ist das schnelle Wachstum von BLE relativ einfach zu erklären: BLE hat sich schneller weiterentwickelt, weil sein Schicksal so eng mit dem phänomenalen Wachstum von Smartphones, Tablets und mobilen Computern verbunden ist. Die frühzeitige und aktive Einführung von BLE durch Schwergewichte der Mobilfunkbranche wie Apple und Samsung öffnete die Türen für eine breitere Implementierung von BLE.

Vor allem Apple hat erhebliche Anstrengungen unternommen, um einen zuverlässigen BLE-Stack zu entwickeln und Designrichtlinien für BLE zu veröffentlichen. Das wiederum hat die Hersteller von Siliziumkomponenten dazu veranlasst, ihre begrenzten Ressourcen in die Technologie zu investieren, von der sie glauben, dass sie auf lange Sicht am erfolgreichsten sein wird.

Während die Märkte für Mobiltelefone und Tablets immer reifer werden und die Kosten und Gewinnspannen sinken, birgt das Bedürfnis nach Konnektivität mit der Außenwelt auf diesen Geräten ein enormes Wachstumspotenzial und bietet Peripherieanbietern die einmalige Gelegenheit, innovative Lösungen für Probleme anzubieten, von denen die Menschen heute vielleicht noch gar nicht wissen, dass sie sie haben.

BLE bietet so viele Vorteile und öffnet kleinen, wendigen Produktentwicklern die Türen zu einem potenziell riesigen Markt für aufgabenspezifische, kreative und innovative Produkte mit einem relativ bescheidenen Entwicklungsbudget. Du kannst heute All-in-One-Funk-plus-Mikrocontroller-Lösungen (System-on-Chip) für deutlich unter 2 $ pro Chip und in kleinen Mengen kaufen, was weit unter dem Gesamtpreis ähnlicher Funktechnologien wie WiFi, GSM, Zigbee usw. liegt. Mit BLE kannst du schon heute praktikable Produkte entwickeln, die mit jeder modernen mobilen Plattform kommunizieren können, und zwar mit Chips, Tools und Standards, die leicht zugänglich sind.

Einer der vielleicht weniger sichtbaren Schlüsselfaktoren für den Erfolg von BLE ist, dass es als erweiterbarer Rahmen für den Datenaustausch konzipiert wurde. Das ist ein grundlegender Unterschied zum klassischen Bluetooth, das sich auf eine strenge Reihe von Anwendungsfällen konzentrierte. BLE hingegen wurde so konzipiert, dass jeder, der eine Idee und eine Reihe von Datenpunkten aus einem Zubehörteil hat, diese umsetzen kann, ohne viel über die zugrunde liegende Technologie wissen zu müssen. Die Smartphone-Hersteller haben den Wert dieses Vorschlags früh erkannt und flexible und relativ einfache APIs bereitgestellt, damit die Entwickler mobiler Anwendungen das BLE-Framework auf jede erdenkliche Weise nutzen können.

Geräte, die mit Smartphones oder Tablets kommunizieren, bieten einen weiteren, leicht zu unterschätzenden Vorteil für Produktdesigner: Sie haben eine ungewöhnlich niedrige Akzeptanzschwelle. Die Nutzerinnen und Nutzer sind bereits daran gewöhnt, die Handys oder Tablets in ihrem Besitz zu benutzen. Das bedeutet, dass der Aufwand, eine neue Benutzeroberfläche zu erlernen, begrenzt ist, solange wir die reichhaltige visuelle Sprache respektieren, an die sich die Menschen auf den von ihnen genutzten Plattformen gewöhnt haben.

Mit einem relativ einfach zu verstehenden Datenmodell, keinen aufdringlichen Lizenzkosten, keinen Gebühren für den Zugang zu den Kernspezifikationen und einem schlanken Protokollstapel sollte klar sein, warum Plattformentwickler und Anbieter von Mobilgeräten in BLE einen Gewinner sehen.

Die Spezifikation

Im Juni 2010 führte die Bluetooth SIG Bluetooth Low Energy mit der Version 4.0 der Bluetooth Core Specfication ein. An der Spezifikation wurde mehrere Jahre gearbeitet, und die meisten umstrittenen Abschnitte und Entscheidungen wurden von den an der Entwicklung beteiligten Unternehmen schließlich ausgeräumt.

Das erste große Update, Bluetooth 4.1, wurde im Dezember 2013 veröffentlicht und ist die aktuelle Referenz für alle, die BLE-Produkte entwickeln wollen. Obwohl die grundlegenden Bausteine, Verfahren und Konzepte beibehalten wurden, gab es auch in dieser Version zahlreiche Änderungen und Verbesserungen, um die Erfahrung der Nutzer/innen zu verbessern.

Wie alle Bluetooth-Spezifikationen ist auch 4.1 rückwärtskompatibel mit 4.0 und gewährleistet so die korrekte Interoperabilität zwischen Geräten, die verschiedene Versionen der Spezifikation verwenden. Die Spezifikationen erlauben es Entwicklern, Produkte für jede der beiden Versionen (bis zur Veraltung) zu entwickeln und zu qualifizieren. Aufgrund der raschen Einführung neuer Versionen der Spezifikationen und der Tatsache, dass die Version 4.1 mehrere gemeinsame Praktiken zwischen Geräten standardisiert, ist es jedoch empfehlenswert, die neueste verfügbare Version zu verwenden.

Wenn nicht anders angegeben, wird in diesem Buch die Bluetooth-Spezifikation 4.1 als Referenz verwendet. Wo immer es nötig ist, und vor allem, wenn wir eine bemerkenswerte Änderung oder Ergänzung erwähnen, werden wir klarstellen, wenn die vorherige 4.0-Spezifikation einen bestimmten Bereich nicht abdeckt.

Die neueste verabschiedete Version der Bluetooth-Spezifikation findest du auf der Seite der Bluetooth SIG (Specification Adopted Documents).

Konfigurationen

Die Bluetooth-Spezifikation umfasst sowohl das klassische Bluetooth (den bekannten Funkstandard, der seit einigen Jahren in vielen Verbrauchergeräten zu finden ist) als auch Bluetooth Low Energy (den neuen, stark optimierten Funkstandard, der mit Version 4.0 eingeführt wurde). Diese beiden Funkstandards sind nicht direkt miteinander kompatibel und Bluetooth-Geräte, die mit einer Spezifikationsversion vor 4.0 arbeiten, können nicht mit einem BLE-Gerät kommunizieren. Das On-Air-Protokoll, die oberen Protokollschichten und die Anwendungen sind unterschiedlich und nicht kompatibel zwischen den beiden Technologien.

Basierend auf der Spezifikation Unterstützung

Tabelle 1-1 zeigt die drahtlosen Technologien für die drei wichtigsten Gerätetypen, die heute auf dem Markt sind.

Tabelle 1-1. Konfigurationen der Spezifikationen

Gerät	Unterstützung von BR/EDR (klassisches Bluetooth)	BLE (Bluetooth Low Energy) Unterstützung
Pre-4.0 Bluetooth	Ja	Nein
4.x Single-Mode (Bluetooth Smart)	Nein	Ja
4.x Dual-Mode (Bluetooth Smart Ready)	Ja	Ja

Wie du siehst, definiert die Bluetooth-Spezifikation (4.0 und höher) zwei drahtlose Technologien:

BR/EDR (klassisches Bluetooth)

Der drahtlose Standard, der sich mit der Bluetooth-Spezifikation seit 1.0 weiterentwickelt hat.

BLE (Bluetooth Low Energy)

Der Low-Power-Funkstandard, der mit der Version 4.0 der Spezifikation eingeführt wurde.

Und das sind die beiden Gerätetypen, die mit diesen Konfigurationen verwendet werden können:

Single-Mode-Gerät (BLE, Bluetooth Smart)

Ein Gerät, das BLE implementiert und mit Singlemode- und Dualmode-Geräten kommunizieren kann, aber nicht mit Geräten, die nur BR/EDR unterstützen.

Dual-Mode-Gerät (BR/EDR/LE, Bluetooth Smart Ready)

Ein Gerät, das sowohl BR/EDR als auch BLE implementiert und mit jedem Bluetooth-Gerät kommunizieren kann.

Abbildung 1-1 zeigt die Konfigurationsmöglichkeiten zwischen den verfügbaren Bluetooth-Versionen und -Gerätetypen sowie die Protokollstacks, mit denen diese Geräte miteinander kommunizieren können.

Abbildung 1-1. Konfigurationen zwischen Bluetooth-Versionen und Gerätetypen

Immer mehr BR/EDR-Geräte, die auf den Markt kommen, sind auch mit BLE ausgestattet, und es wird erwartet, dass sich dieser Trend fortsetzen wird, da Single-Mode-BLE-Sensoren immer allgegenwärtiger werden. Diese Dual-Mode-Geräte können die von einem Single-Mode-BLE-Gerät erhaltenen Daten über ihre GSM- oder WiFi-Funkgeräte an das Internet weiterleiten - eine Funktion, die immer häufiger genutzt wird, je mehr BLE-Sensoren auf den Markt kommen.

Basierend auf der Chipanzahl

In Kapitel 2 werden die verschiedenen Protokollschichten, aus denen der Bluetooth-Protokollstapel besteht, vorgestellt und besprochen. Für den Moment reicht es jedoch aus, die drei Hauptbausteine eines jeden Bluetooth-Geräts zu skizzieren:

Bewerbung

Die Benutzeranwendung, die mit dem Bluetooth-Protokollstapel zusammenarbeitet, um einen bestimmten Anwendungsfall abzudecken.

Gastgeber

Die oberen Schichten des Bluetooth-Protokollstapels.

Controller

Die unteren Schichten des Bluetooth-Protokollstapels, einschließlich des Funkgeräts.

Außerdem enthält die Spezifikation ein Standard-Kommunikationsprotokoll zwischen dem Host und dem Controller - das Host Controller Interface (HCI) - um die Interoperabilität zwischen Hosts und Controllern verschiedener Hersteller zu ermöglichen.

Diese Schichten können in einem einzigen integrierten Schaltkreis (IC) oder Chip implementiert werden, oder sie können in mehrere ICs aufgeteilt werden, die über eine Kommunikationsschicht (UART, USB, SPI oder andere) verbunden sind.

Dies sind die drei gängigsten Konfigurationen, die heute in handelsüblichen Produkten zu finden sind:

SoC (System on Chip)

Ein einziger IC betreibt die Anwendung, den Host und den Controller.

Dual IC über HCI

Ein IC führt die Anwendung und den Host aus und kommuniziert über HCI mit einem zweiten IC, der den Controller ausführt. Der Vorteil dieses Ansatzes ist, dass, da HCI in der Bluetooth-Spezifikation definiert ist, jeder Host mit jedem Controller kombiniert werden kann, unabhängig vom Hersteller.

Dual IC mit Konnektivitätsvorrichtung

Ein IC führt die Anwendung aus und kommuniziert über ein proprietäres Protokoll mit einem zweiten IC, auf dem sowohl der Host als auch der Controller laufen. Da die Spezifikation ein solches Protokoll nicht enthält, muss die Anwendung an das spezifische Protokoll des gewählten Anbieters angepasst werden.

Abbildung 1-2 zeigt die verschiedenen Hardware-Konfigurationen mit den Schichten des Bluetooth-Protokollstapels.

Abbildung 1-2. Hardware-Konfigurationen

Bei einfachen Sensoren werden in der Regel SoC-Konfigurationen verwendet, um die Kosten und die Komplexität der Leiterplatte gering zu halten, während Smartphones und Tablets in der Regel die Dual-IC-über-HCI-Konfiguration wählen, da sie in der Regel bereits über eine leistungsstarke CPU verfügen, die den Protokollstack ausführen kann. Die Dual-IC-Konfiguration mit Konnektivität wird auch in anderen Szenarien verwendet, z. B. bei einer Uhr mit einem speziellen Mikrocontroller, der mit BLE-Konnektivität ausgestattet ist, ohne dass das gesamte Design überarbeitet werden muss.

Wichtigste Beschränkungen

Wie bei allen Dingen in der Technik kommt es auch bei Bluetooth Low Energy darauf an, die richtigen Kompromisse zu finden. BLE versucht nicht, eine Lösung für jeden Bedarf an drahtloser Datenübertragung zu sein, und klassisches Bluetooth, WiFi, NFC und andere drahtlose Technologien haben immer noch ihren Platz, mit ihren eigenen Kompromissen und Entscheidungen.

Um zu verstehen, was BLE ist (und was nicht), ist es hilfreich, die wichtigsten Einschränkungen zu kennen (wie sie in der Bluetooth 4.0-Spezifikation und später definiert sind) und zu wissen, wie sich diese Einschränkungen in realen Produkten niederschlagen.

Datendurchsatz

Die Modulationsrate des Bluetooth Low Energy-Funks ist in der Spezifikation auf konstant 1 Mbit/s festgelegt. Dies ist die theoretische Obergrenze für den Durchsatz, den BLE bieten kann. In der Praxis wird diese Grenze jedoch in der Regel durch eine Reihe von Faktoren deutlich gesenkt, z. B. durch bidirektionalen Datenverkehr, Protokoll-Overhead, CPU- und Funkbeschränkungen sowie künstliche Softwarebeschränkungen.

Um einige dieser praktischen Einschränkungen zu veranschaulichen, betrachten wir die folgenden Grundvoraussetzungen, die wir für eine Berechnung verwenden werden:

• Ein zentrales (Master-)Gerät hat eine Verbindung mit einem peripheren (Slave-)Gerät initiiert und aufgebaut.

• Während einer aktiven Verbindung definiert die Spezifikation das Verbindungsintervall als das Intervall zwischen zwei aufeinanderfolgenden Verbindungsereignissen (ein Datenaustausch, bevor wieder in den Ruhezustand gewechselt wird, um Energie zu sparen), und dieses Verbindungsintervall kann auf einen Wert zwischen 7,5 ms und 4 s eingestellt werden.

Inden Kapiteln "Link Layer" und "Roles" werden die verschiedenen Rollen innerhalb einer Verbindung im Detail erläutert. Für dieses Beispiel verwenden wir den nRF51822, einen weit verbreiteten SoC (System on Chip) BLE-IC von Nordic Semiconductor, der in einer Vielzahl von BLE-Zubehör auf dem Markt verwendet wird. Die Funkhardware und der BLE-Stack von Nordic führen zu den folgenden Einschränkungen beim Datendurchsatz:

• Der nRF51822 kann bis zu sechs Datenpakete pro Verbindungsintervall übertragen (begrenzt durch den IC).

• Jedes ausgehende Datenpaket kann bis zu 20 Byte Nutzdaten enthalten (dies ist in der Spezifikation festgelegt, es sei denn, es werden höhere Paketgrößen ausgehandelt).

Wenn man das kürzeste Verbindungsintervall (die Häufigkeit, mit der der Master und der Slave Pakete austauschen, beschrieben in "Verbindungen") von 7,5 ms annimmt, ergibt das ein Maximum von 133 Verbindungsereignissen (ein einzelner Paketaustausch zwischen den beiden Peers) pro Sekunde und 120 Bytes pro Verbindungsereignis (6 Pakete * 20 Benutzerbytes pro Paket). Eine kontinuierliche Übertragung mit der maximalen Datenrate des nRF51822 würde in der Praxis zu folgender Berechnung führen:

133 connection events per second * 120 bytes = 15960 bytes/s
                                               or ~0.125Mbit/s (~125kbit/s)

Das ist bereits deutlich weniger als das theoretische Maximum von BLE, aber das Peer-Gerät, an das du Daten sendest (in der Regel ein Smartphone oder ein Tablet), kann weitere Einschränkungen mit sich bringen.

Dein Smartphone oder Tablet ist vielleicht auch damit beschäftigt, mit anderen Geräten zu kommunizieren, und die vom Hersteller implementierten BLE-Stacks haben zwangsläufig ihre eigenen Beschränkungen, was bedeutet, dass das zentrale Gerät möglicherweise nicht in der Lage ist, Daten mit der maximalen Datenrate zu verarbeiten. Und aufgrund zahlreicher anderer Faktoren kann das tatsächliche Verbindungsintervall weiter auseinanderliegen oder unregelmäßiger sein, als du ursprünglich geplant hattest.

In der Praxis sollte man also in einem typischen Best-Case-Szenario von einem potenziellen maximalen Datendurchsatz in der Nähe von 5-10 KB pro Sekunde ausgehen, je nachdem, wo die Grenzen der beiden Peers liegen. So bekommst du eine Vorstellung davon, was du mit Bluetooth Low Energy machen kannst und was nicht, wenn es darum geht, Daten an dein Handy oder Tablet zu übertragen. Das erklärt auch, warum andere Technologien wie WiFi und klassisches Bluetooth immer noch ihren Platz in der Welt haben.

Rennen bis zum Leerlauf

In einer Welt, in der die Dinge normalerweise immer schneller werden, mögen 10 KB/s langsam und kontraproduktiv erscheinen, aber sie unterstreichen das Hauptziel von Bluetooth Low Energy: niedriger Energieverbrauch! Selbst bei diesen relativ bescheidenen Datenraten sind 10 KB/s schnell verbraucht, und die Bluetooth SIG hat sich bewusst dagegen entschieden, ein weiteres allgemeines drahtloses Protokoll zu entwickeln und ihm das Etikett " stromsparend" aufzudrücken. Stattdessen wollten sie das Protokoll mit dem geringstmöglichen Stromverbrauch entwickeln und haben es in jeder Hinsicht optimiert, um dieses Ziel zu erreichen. Der einfachste Weg, den Verbrauch wertvoller Batterieleistung zu vermeiden, ist, das Funkgerät so oft und so lange wie möglich auszuschalten. Dazwischen wird das Funkgerät einfach ausgeschaltet.

Das bedeutet, dass geringe Datenmengen in kurzen Stößen übertragen werden und die Verbindungsintervalle so weit wie möglich auseinander liegen, um die Batterie zu schonen. Das vom Benutzer wählbare Verbindungsintervall von 7,5 ms bis 4 s bietet ein ausreichend großes Fenster, damit Produktdesigner den richtigen Kompromiss zwischen Reaktionsfähigkeit (ein kurzes Verbindungsintervall) und Batterielebensdauer (ein längeres Verbindungsintervall) finden können, ohne sich zu weit von den engen Designzielen hinter BLE zu entfernen.

Betriebsbereich

Die tatsächliche Reichweite eines drahtlosen Geräts hängt von einer Vielzahl von Faktoren ab (Betriebsumgebung, Antennendesign, Gehäuse, Geräteausrichtung usw.), aber Bluetooth Low Energy konzentriert sich wenig überraschend auf die Kommunikation über sehr kurze Distanzen.

Die Sendeleistung (in der Regel in dBm gemessen) ist in der Regel über einen bestimmten Bereich konfigurierbar (in der Regel zwischen -30 und 0 dBm), aber je höher die Sendeleistung (bessere Reichweite) ist, desto mehr wird die Batterie beansprucht, was die nutzbare Lebensdauer der Batteriezelle(n) verringert.

Es ist möglich, ein BLE-Gerät zu entwickeln und zu konfigurieren, das Daten zuverlässig 30 Meter oder mehr auf Sicht übertragen kann. Die typische Reichweite liegt aber wahrscheinlich eher bei 2 bis 5 Metern, wobei bewusst versucht wird, die Reichweite zu verringern und die Batterie zu schonen, ohne dass die Übertragungsdistanz zu einem Ärgernis für den Endnutzer wird.

Netzwerk-Topologie

Ein Bluetooth Low Energy-Gerät kann auf zwei Arten mit der Außenwelt kommunizieren: per Broadcasting oder per Verbindung. Jeder Mechanismus hat seine eigenen Vorteile und Einschränkungen und beide unterliegen den Richtlinien des Generic Access Profile (GAP), das in Kapitel 3 ausführlich beschrieben wird.

Übertragen und Beobachten

Mit dem verbindungslosen Rundsenden kannst du Daten an jedes Scan-Gerät oder jeden Empfänger in Hörweite senden. Wie in Abbildung 1-3 dargestellt, kannst du mit diesem Mechanismus Daten in eine Richtung an jeden beliebigen Empfänger senden, der in der Lage ist, die übertragenen Daten zu empfangen.

Abbildung 1-3. Broadcast-Topologie

Der Rundfunk definiert zwei verschiedene Rollen:

Broacaster

Sendet regelmäßig nicht verbindungsfähige Werbepakete an alle, die sie empfangen wollen.

Beobachter

Scannt wiederholt die voreingestellten Frequenzen, um alle nicht verbindungsfähigen Werbepakete zu empfangen, die gerade gesendet werden.

Broadcasting ist wichtig zu verstehen, denn es ist die einzige Möglichkeit für ein Gerät, Daten an mehr als einen Peer gleichzeitig zu übertragen. Du sendest Daten aus, indem du die Werbefunktionen von BLE nutzt, die in den Kapiteln "Werbung und Scannen" und "Senden und Beobachten" näher erläutert werden .

Das Standard-Werbepaket enthält eine 31-Byte-Nutzlast, die Daten zur Beschreibung des Senders und seiner Fähigkeiten enthält, aber auch benutzerdefinierte Informationen, die du an andere Geräte senden möchtest. Wenn die standardmäßige 31-Byte-Nutzlast nicht ausreicht, um alle erforderlichen Daten unterzubringen, unterstützt BLE auch eine optionale sekundäre Werbe-Nutzlast (die so genannte Scan Response), mit der Geräte, die ein sendendes Gerät erkennen, einen zweiten Werberahmen mit einer weiteren 31-Byte-Nutzlast anfordern können, insgesamt also bis zu 62 Byte.

Broadcasting ist schnell und einfach zu bedienen und eine gute Wahl, wenn du nur eine kleine Menge an Daten nach einem festen Zeitplan oder an mehrere Geräte senden willst. In Kapitel 9 findest du ein praktisches Beispiel für das verbindungslose BLE-Broadcasting in Aktion mit iBeacon.

Eine große Einschränkung von Broadcasting im Vergleich zu einer regulären Verbindung ist, dass es keinerlei Sicherheits- oder Datenschutzbestimmungen gibt (jedes Beobachtergerät kann die übertragenen Daten empfangen), so dass es sich nicht unbedingt für sensible Daten eignet.

Verbindungen

Wenn du Daten in beide Richtungen übertragen musst oder wenn du mehr Daten hast, als die beiden Werbenutzlasten unterbringen können, musst du eine Verbindung verwenden. Eine Verbindung ist ein permanenter, regelmäßiger Datenaustausch von Paketen zwischen zwei Geräten. Er ist daher von Natur aus privat (die Daten werden nur an die beiden an einer Verbindung beteiligten Peers gesendet und von diesen empfangen, und von keinem anderen Gerät, es sei denn, es schnüffelt wahllos herum). Unter "Verbindungen" findest du weitere Informationen über Verbindungen auf der unteren Ebene, und unter "Rollen" werden die entsprechenden GAP-Rollen erläutert.

Verbindungen beinhalten zwei verschiedene Rollen:

Zentral (Master)

Scannt wiederholt die voreingestellten Frequenzen nach verbindungsfähigen Werbepaketen und initiiert bei Eignung eine Verbindung. Sobald die Verbindung hergestellt ist, verwaltet die Zentrale das Timing und leitet den periodischen Datenaustausch ein.

Peripheriegerät (Slave)

Ein Gerät, das in regelmäßigen Abständen verbindungsfähige Werbepakete sendet und eingehende Verbindungen annimmt. Sobald eine aktive Verbindung besteht, folgt das Peripheriegerät dem Timing der Zentrale und tauscht regelmäßig Daten mit ihr aus.

Um eine Verbindung zu initiieren, empfängt ein zentrales Gerät die verbindungsfähigen Werbepakete von einem Peripheriegerät und sendet dann eine Anfrage an das Peripheriegerät, um eine exklusive Verbindung zwischen den beiden Geräten herzustellen. Sobald die Verbindung hergestellt ist, stellt das Peripheriegerät die Werbung ein und die beiden Geräte können mit dem Datenaustausch in beide Richtungen beginnen, wie in Abbildung 1-4 dargestellt.

Abbildung 1-4. Verbundene Topologie

Eine Verbindung ist also nichts anderes als der periodische Austausch von Daten zu bestimmten Zeitpunkten (Verbindungsereignisse) zwischen den beiden beteiligten Peers. Es ist wichtig zu wissen, dass die Zentrale zwar das Gerät ist, das den Verbindungsaufbau verwaltet, dass aber beide Geräte bei jedem Verbindungsereignis unabhängig voneinander Daten senden können und dass die Rollen keine Einschränkungen hinsichtlich des Datendurchsatzes oder der Priorität mit sich bringen.

Ab Version 4.1 der Spezifikation wurden alle Beschränkungen für Rollenkombinationen aufgehoben, und die folgenden sind alle möglich:

• Ein Gerät kann gleichzeitig als Zentrale und als Peripheriegerät fungieren.

• Eine Zentrale kann mit mehreren Peripheriegeräten verbunden werden.

• Ein Peripheriegerät kann mit mehreren Zentralen verbunden werden.

Frühere Versionen der Spezifikation beschränkten das Peripheriegerät auf einen einzigen zentralen Anschluss (allerdings nicht umgekehrt) und begrenzten die Rollenkombinationen.

Der größte Vorteil von Verbindungen (im Vergleich zu Broadcasting) ist die Möglichkeit, die Daten mit einer viel feineren Kontrolle über jedes Feld oder jede Eigenschaft durch die Verwendung zusätzlicher Protokollschichten und insbesondere des Generic Attribute Profile (GATT) zu organisieren. Die Daten werden in Einheiten organisiert, die Dienste und Merkmale genannt werden (mehr dazu in Kapitel 4).

Das Wichtigste ist, dass du mehrere Dienste und Merkmale haben kannst, die in einer sinnvollen Struktur organisiert sind. Dienste können mehrere Merkmale enthalten, jedes mit eigenen Zugriffsrechten und beschreibenden Metadaten. Zu den weiteren Vorteilen gehören ein höherer Durchsatz, die Möglichkeit, eine sichere verschlüsselte Verbindung herzustellen, und die Aushandlung von Verbindungsparametern, die an das Datenmodell angepasst sind.

Verbindungen ermöglichen ein viel umfangreicheres, mehrschichtiges Datenmodell. Sie haben auch das Potenzial, viel weniger Energie zu verbrauchen als der Broadcast-Modus, weil sie die Verzögerung zwischen den Verbindungsereignissen weiter ausdehnen oder große Datenpakete nur dann senden können, wenn neue Werte verfügbar sind, anstatt ständig die gesamte Nutzlast mit einer bestimmten Rate zu übermitteln, ohne zu wissen, wer zuhört oder wie oft. Und nicht nur das: Da beide Peers wissen, wann die Verbindungsereignisse in der Zukunft stattfinden werden, kann das Funkgerät länger abgeschaltet werden, was im Vergleich zum Broadcasting potenziell Batteriestrom spart.

Schließlich können diese Topologien in einem größeren BLE-Netzwerk frei gemischt werden, wie in Abbildung 1-5 dargestellt. Ein BR/EDR/LE-fähiges Gerät kann BLE- und BR/EDR-Verbindungen miteinander verbinden, und die Anzahl der Kombinationen und Teilnehmer im Netzwerk wird nur durch die Beschränkungen der Funkgeräte und Protokollstacks der einzelnen beteiligten Geräte begrenzt.

Abbildung 1-5. Gemischte Topologie

Es gibt immer mehr fortschrittliche Dual-Mode- und Single-Mode-Geräte, die mehrere Funktionen gleichzeitig erfüllen können. So können sie an mehreren Verbindungen gleichzeitig teilnehmen und gleichzeitig Werbung zur Übertragung von Daten nutzen.

Protokolle versus Profile

Von Anfang an hat die Bluetooth-Spezifikation eine klare Trennung zwischen den unterschiedlichen Konzepten von Protokollen und Profilen eingeführt:

Protokolle

Protokolle sind die Schichten, die die verschiedenen Paketformate, das Routing, das Multiplexing, die Kodierung und die Dekodierung implementieren, damit die Daten effektiv zwischen den Teilnehmern übertragen werden können.

Profile

"Profile definieren im Wesentlichen, wie Protokolle verwendet werden sollten, um ein bestimmtes Ziel zu erreichen, unabhängig davon, ob es sich um ein allgemeines oder spezifisches Ziel handelt.

Kapitel 2 befasst sich ausführlich mit den Protokollen, aber die folgenden Abschnitte bieten eine kurze Einführung in die Profile und ihre Bedeutung für einen Anwendungsentwickler.

Allgemeine Profile

Generische Profile sind in der Spezifikation definiert und es ist wichtig zu verstehen, dass zwei von ihnen grundlegend sind, um die Interoperabilität zwischen BLE-Geräten verschiedener Hersteller zu gewährleisten:

Generisches Zugangsprofil (GAP)

GAP deckt das Nutzungsmodell der untergeordneten Funkprotokolle ab, um Rollen, Verfahren und Modi zu definieren, die es den Geräten ermöglichen, Daten zu übertragen, Geräte zu erkennen, Verbindungen herzustellen, Verbindungen zu verwalten und Sicherheitsstufen auszuhandeln, und ist damit im Wesentlichen die oberste Steuerungsebene von BLE. Dieses Profil ist für alle BLE-Geräte verbindlich und muss von allen eingehalten werden.

Generisches Attributprofil (GATT)

Für den Datenaustausch in BLE definiert GATT ein grundlegendes Datenmodell und Verfahren, mit denen Geräte Datenelemente erkennen, lesen, schreiben und zwischen ihnen austauschen können. Es ist im Grunde genommen die oberste Datenschicht von BLE.

GAP (ausführlicher in Kapitel 3) und GATT (ausführlicher in Kapitel 4) sind so grundlegend für BLE, dass sie oft als Grundlage für Anwendungsprogrammierschnittstellen (APIs) verwendet werden, die den Einstiegspunkt für die Interaktion der Anwendung mit dem Protokollstapel bilden.

Anwendungsfall-spezifische Profile

Die anwendungsspezifischen Profile in diesem Abschnitt und an anderer Stelle beschränken sich auf GATT-basierte Profile. Das bedeutet, dass alle diese Profile die Verfahren und Betriebsmodelle des GATT-Profils als Grundbaustein für alle weiteren Erweiterungen verwenden.

Zum Zeitpunkt der Erstellung dieses Artikels gibt es keine Nicht-GATT-Profile, aber die Einführung von verbindungsorientierten L2CAP-Kanälen in Version 4.1 der Spezifikation könnte bedeuten, dass in Zukunft auch GATT-freie Profile auftauchen könnten.

SIG-definierte GATT-basierte Profile

Die Bluetooth SIG geht über die Bereitstellung eines soliden Referenzrahmens für die obersten Steuer- und Datenschichten der an einem BLE-Netzwerk beteiligten Geräte hinaus. Genau wie die USB-Spezifikation bietet sie auch eine vordefinierte Reihe von Anwendungsprofilen auf der Grundlage von GATT, die alle Verfahren und Datenformate abdecken, die für die Umsetzung einer Vielzahl spezifischer Anwendungsfälle erforderlich sind, einschließlich der folgenden :

Finde mich Profil

Ermöglicht es Geräten, andere Geräte physisch zu orten (z. B. mit einem Schlüsselring das Telefon zu finden oder umgekehrt).

Annäherungsprofil

Erkennt das Vorhandensein oder Fehlen von Geräten in der Nähe (Piepton, wenn ein Gegenstand beim Verlassen des Zimmers vergessen wird).

HID über GATT-Profil

Überträgt HID-Daten über BLE (Tastaturen, Mäuse, Fernbedienungen).

Glukoseprofil

Überträgt den Blutzuckerspiegel sicher über BLE.

Gesundheitsthermometer Profil

Überträgt die Körpertemperaturwerte über BLE.

Geschwindigkeits- und Trittfrequenzprofil beim Radfahren

Ermöglicht es den Sensoren am Fahrrad, Geschwindigkeits- und Trittfrequenzdaten an ein Smartphone oder Tablet zu übertragen.

Eine vollständige Liste der von der SIG genehmigten Profile findest du auf der Seite "Specification Adopted Documents" der Bluetooth SIG. Außerdem kannst du Bluetooth-Dienste und -Eigenschaften direkt auf dem Bluetooth Developer Portal einsehen, insbesondere die Liste aller derzeit angenommenen Dienste.

Anbieter-spezifische Profile

Die Bluetooth-Spezifikation erlaubt es den Anbietern auch, eigene Profile für Anwendungsfälle zu definieren, die nicht von den SIG-Profilen abgedeckt werden. Diese Profile können den beiden an einem bestimmten Anwendungsfall beteiligten Parteien vorbehalten bleiben (z. B. einem Gesundheitszubehör und einer Smartphone-Anwendung) oder sie können vom Hersteller veröffentlicht werden, damit andere Parteien Implementierungen des Profils auf der Grundlage der vom Hersteller bereitgestellten Spezifikation bereitstellen können.

Einige Beispiele für Letzteres sind Apples iBeacon (siehe "iBeacon" für weitere Details) und der Apple Notification Center Service (siehe "Apple Notification Center Service mit einem externen Display").