BLE – Ein kurze Einstiegshilfe in die Welt von Bluetooth Low Energy

Als die ersten Bluetooth Low Energy Geräte in den Markt kamen, hatte BLE geradezu etwas Mystisches. Jeder wollte diese Technologie nutzen, auch wenn kaum jemand so richtig verstand wie es funktioniert. Hinzu kam, dass die Integration von BLE damals harte Arbeit war. Um mit BLE zu arbeiten, musste man sich in der Regel umfassend mit der Bluetooth Spezifikation und der genutzten Stack-Implementierung befassen. Das hat sich zum Glück geändert. Mit der weiten Verbreitung von BLE wurde auch die BLE-fähige Hardware immer besser bedienbar. Heute gibt es eine umfangreiche Liste an SoCs und Modulen, welche sich mit sehr geringem Aufwand programmieren lassen. Trotzdem sollte man ein gewisses Grundverständnis mitbringen, um die richtige Hardware und Software auswählen zu können. In diesem Beitrag versuche ich eine kurze Einstiegshilfe zu geben, für alle die sich zum ersten Mal mit dem Thema beschäftigen. Außerdem versuche ich gängige Missverständnisse zu klären und die Limitierungen der Technologie zu beleuchten.

Wer außerdem etwas tiefer in die Welt von BLE einsteigen möchte, dem empfehel ich auch meinen weiterführenden Artikel:

Niedrige Latenzen mit Bluetooth Low Energy

Hier geht es vorallem darum, wie man möglichst niedrige Latenzen mit BLE erreicht. Um dies zu erklären gehen ich allerdings auch auf einige Grundlagen ein, die für ein allgemeines Verständniss von BLE interessant sind.

Welche Hardware eignet sich für mein Projekt?

BLE-fähige Hardware gibt es inzwischen jede Menge auf dem Markt. Welche davon für das eigene Projekt geeignet ist, hängt von dem konkreten Anwendungsszenarien ab.

SoC oder integriertes Modul

Ob ein integriertes Modul oder ein reiner SoC zum Einsatz kommt, hängt vor allem von der Stückzahl ab. Bei hohen Stückzahlen machen sich die geringeren Kosten des SoC bemerkbar. Bei geringeren Stückzahlen zeichnen sich die integrierten Module durch geringere Entwicklungskosten aus. Zudem verfügen Module, sofern diese über eine integrierte Antenne verfügen, in der Regel über Vor-Zertifizierungen für bestimmte Regionen. Kommt ein SoC zum Einsatz muss für jedes Land eine entsprechende Zertifizierung durchgeführt werden. Ein Vorteil der SoCs ist allerdings die Möglichkeit das HF-Front End sowie die Platzierung der Antenne selbst gestalten zu können. Hierdurch können unter Umständen deutlich höhere Übertragungsreichweiten erreicht werden.

Länderzulassung bei BLE-Modulen

Entscheidet man sich für ein vollständig integriertes BLE-Modul mit integrierter Antenne, hat man oft den Vorteil, dass die Module für die entsprechenden Länder vorzertifiziert sind. Dieses Thema wird oft als weniger wichtig angesehen, kann aber entscheidend sein, wenn man vor hat, sein Produkt in vielen Regionen der Welt zu verkaufen. Will man sein Produkt überall auf der Welt anbieten, kann man durchaus mit sechsstelligen Kosten für die Zertifizierungen rechnen. Hier bieten Vorzertifizierungen in den entsprechenden Ländern enormes Einsparpotential.

Man sollte jedoch vorsichtig bei der Verwendung von Modulen ohne metallische Schirmung sein. Diese erhalten z.B. in USA und Kanada auf Grund der regulatorischen Vorgaben keine vollständige Zertifizierung. In Süd-Korea ist die Vorzertifizierung von Modulen ohne metallische Schirmung überhaupt nicht möglich. Wird ein Modul ohne metallische Schirmung verwendet, sollte dringend geprüft werden was diese Entscheidung hinsichtlich der Kosten für die Länderzulassung bedeutet.

Vorinstallierter Stack gegen eigene Bluetooth Firmware

Die Nutzung eines vorinstallierten Bluetooth Stack kann einem viel Ärger ersparen. Gerade im Bereich der Medizintechnik bietet ein vorinstallierter Bluetooth Stack einen wichtigen Vorteil: Der Aufwand für die Dokumentation sinkt enorm. Das mag erst einmal nicht so gravierend klingen. Man sollte aber im Hinterkopf behalten, dass eine eigene Bluetooth Firmware ein zusätzliches Softwareprojekt bedeutet, welches entsprechend der regulatorischen Vorgaben zu entwickeln und zu dokumentieren ist. Hinzu kommt, dass durch die Nutzung eines vorinstallierten Stacks in der Regel deutlich geringere Entwicklungskosten anfallen und keine kostenpflichtigen IDEs oder Compiler verwendet werden müssen.

Datenrate

Das ist eines der am meisten missverstandenen Eigenschaften von BLE. Man liest hier immer wieder den Wert 1 Mbit/s, was natürlich schon ziemlich gut klingt. Leider ist dieser Wert aber vollkommen falsch. Ich werde es an dieser Stelle vermeiden zu tief in das BLE-Protokoll einzusteigen. Um ein grundsätzliches Verständnis dafür zu erhalten warum 1 Mbit/s fern von allem ist was man mit BLE (inklusive dem neuen Standard Bluetooth 5.0) erreichen kann, muss man eigentlich nur folgendes Wissen:

• 1 Mbit/s ist die Bitrate von BLE-Transmittern (bei BT 5.0 ist außerdem 2 Mbit/s wählbar). Wer sich aber schon mal irgendwann mit irgendeinem Kommunikationsprotokoll beschäftigt hat, sollte wissen, dass es immer einen gewissen Overhead im Protokoll gibt.

• Jetzt könnte man hingehen und die netto Datenrate aus Bitrate und Nutzdaten pro Paket berechnen. Würde man das tuen, hätte man immer noch mehr als 900 kbit/s, was ja auch immer noch echt gut klingt… Aber leider auch immer noch falsch ist.
• Nun muss man noch wissen, dass BLE Central und Peripheral Device immer abwechselnd kommunizieren müssen. Selbst wenn das Central Device gerade nichts mitzuteilen hat, muss es mindestens ein leeres Paket senden. Zwischen jedem Paket gibt es dann noch einen Abstand. Geht man also davon aus das ein Gerät immer die volle Menge Nutzdaten überträgt, während das andere nur ein leeres Paket überträgt kommt man, wenn man den Abstand zwischen den Paketen mit einrechnet immer noch auf rund 800 kbit/s. Das ist jetzt das, was theoretisch mit BT 4.2 möglich ist. Leider sieht die Realität meistens deutlich anders aus.
• Die BLE-Kommunikation findet während so genannter „Connection Intervalls“ statt. In diesen Intervallen tauschen die BLE-Geräte Daten miteinander aus. Laut BLE Spezifikation darf dieses Connection Interval minimal 7.5 ms betragen und kann in 1,25 ms Schritten erhöht werden. Theoretisch kann ein Connection Intervall mehrere Sekunden dauern. Das Problem ist, das bis zum Ende des Connection Intervall alle Kommunikation abgeschlossen sein muss. Das heißt, die Wiederkehrende Reihenfolge aus …
• 1. Paket Central an Peripheral
  2. Pause
  3. Paket Peripheral an Central
  4. Pause

… muss abgeschlossen werden. Wäre also zu einem bestimmten Zeitpunkt noch Platz für ein Paket von Central an Peripheral, aber nicht mehr für die übrigen 3 Schritte werden keine weiteren Daten ausgetauscht. Ab hier beginnt das Glaskugellesen. Es ist kaum abzuschätzen wie viele Bytes, wann von Central an Peripheral übertragen werden. Das ist stark abhängig von der Implementierung des BLE-Stacks. Dementsprechend kann man nur schwer vorhersehen wie viele Pakete in einem Intervall ausgetauscht werden können. Außerdem ist die Anzahl der maximalen Pakete in einem Intervall bei den meisten Stack-Implementierungen begrenzt.

• Hinzu kommt das BLE sich nicht besonders gut mit anderen Nutzern des 2,4 GHz Frequenzbandes versteht. Besonders schlecht steht es um die Beziehung mit dem allgegenwärtigen WLAN. Dieses kommuniziert nicht nur auf demselben Frequenzband, sondern überträgt zusätzlich mit einer deutlich höheren Leistung. BLE Daten sind auf Grund der geringen Sendeleistung anfällig für Störungen durch andere Teilnehmer auf dem Frequenzband. Kommt ein Paket hierdurch korrumpiert am Receiver an, wird jede weitere Kommunikation in diesem Connection Intervall eingestellt.

Lange Rede kurzer Sinn: Die Datenrate von BLE ist unter realistischen Bedingungen nur schwer vorher zu sagen und in der Regel deutlich geringer als die Bitrate 1 Mbit/s. Ich denke, dass man in einer einigermaßen „sauberen“ Umgebung mit einer Übertragungsrate von 100 kbit/s durchaus rechnen kann. Mehr bis hin zu den theoretisch erreichbaren 800 kbit/s ist möglich. Man sollte sich aber im Klaren sein, dass solche Werte wirklich nur erreicht werden, wenn man sich knietief in das BLE-Protokoll und die verwendete Stack-Implementierung vergräbt.

Latenz

Das ist so ziemlich der größte Nachteil in BLE. Im Kapitel „Datenrate“ wurden bereits die sogenannten Connection Intervals angesprochen. Diese regeln, wie oft ein BLE-Gerät mit seiner Gegenstelle kommunizieren darf. Theoretisch können während des ganzen Connection Intervals Daten ausgetauscht werden. Das Problem ist: Stehen zu Beginn des Intervalls keine Daten zur Verfügung, endet der Datenaustausch für diesen Intervall, nachdem beide Geräte ein leeres Paket an ihren Partner übertragen haben. Je nachdem wann Bluetooth Daten zum Senden an den Bluetooth Stack übergeben werden, kann es daher sein, dass es ein volles Intervall dauert, plus die Zeit, die es braucht, um die Daten  zu übertragen.

Hierdurch ergibt sich eine gewisse Variabilität in der Latenz, welche es kaum vorhersehbar macht, wann Daten, die zum Versenden bereit stehen, wirklich an der Gegenstelle ankommen. Schlägt eine Datenübertragung fehl, z.B. auf Grund von Störungen durch andere Teilnehmer aus dem Frequenzband, kann sich diese Variabilität um ein Vielfaches erhöhen. Das folgende Video zeigt ein Beispiel für die Latenz einer BLE Übertragung. Bei diesem Versuch wurden Daten in einem festen Raster an ein BLE Modul übertragen (gelbe Linie). Anschließend wurde der zeitliche Versatz gemessen, wann das Empfänger-Modul die Daten weitergibt (grüne Linie). Trotz Connection Interval von 7,5, ms lag die maximale Latenz hierbei nahezu doppelt so hoch.

Zusammengefasst kann man sagen, dass die Latenz einer BLE-Datenübertragung immer einer gewissen Variabilität unterliegt. Die maximale Latenz kann man durch die Wahl des Connection Intervals beeinflussen. Unter realistischen Bedingungen würde ich allerdings nicht von Intervallen deutlich kleiner als 20 ms ausgehen. Damit kann man in der Regel leben. Man sollte sich aber im Klaren sein, dass man nie mit vollständiger Sicherheit sagen kann, wie lange es dauert bis Daten über BLE übertragen werden. Das macht genaue Synchronisierung zweier BLE-Geräte und die Übertragung von Daten in Echtzeit nur schwer möglich.

BT 4.0 / 4.2 / 5.0 – Alles das gleiche?

Im Grunde stimmt das. BLE ist nun mal BLE. Ein gängiges Missverständnis ist, dass in der Spezifikation von Bluetooth 4.0 ausschließlich BLE enthalten ist. Tatsächlich handelt es sich bei BLE nur um eine Erweiterung des Bluetooth Protokolls, welche seit Version 4.0 hinzugefügt wurde und in den nachfolgenden Versionen weiterentwickelt wurde. Trotzdem ist auch das klassische Bluetooth nach wie vor in der Spezifikation enthalten.

Die Paketstruktur und wie diese ausgetauscht werden ist für BLE in allen Versionen sehr ähnlich. Das macht die Standards (teilweise) rückwärtskompatibel. Trotzdem gibt es gravierende Unterschiede. Hier drei der – aus meiner Sicht – wichtigsten:

1. Secure Pairing: Das ist wohl einer der wichtigsten Neuerungen die BT 4.2 mit sich brachte. Durch neue Pairing-Mechanismen wurde BLE endlich einigermaßen sicher.
2. Paketgröße: Hier hat sich ebenfalls etwas getan. Bei BT 4.2. konnte ein BLE Paket bei BT 4.0 gerade mal 27 Bytes Nutzdaten enthalten, waren es bei BT 4.2 schon 251 Nutzbytes. Es sollte jedoch darauf hingewiesen werden, dass mit größeren Paketen auch die Anzahl der Pakete pro Connection Intervall sinkt. Trotzdem wurde die Datenrate deutlich erhöht, da bei durchgängigen Datenstreams von A nach B, weniger leere Pakete von B nach A benötigt werden (siehe oben). Außerdem gibt es weniger Pausen, welche zwischen jedem Paket eingehalten werden müssen.
3. Bitrate: Die größte Änderung von BT 5.0 ist, dass die Bitrate nun konfigurierbar ist. Statt den üblichen 1 Mbit/s lassen sich nun auch 2 Mbit/s einstellen. Zusätzlich übertragen BT 5.0 fähige Geräte mit deutlich höherer Leistung was zu einer erhöhten Reichweite führt. Da die höhere Datenrate allerdings zu einer geringeren Sensitivität des Receivers führt, hat man effektiv die Wahl zwischen zwei Möglichkeiten:
   • Man Überträgt mit (fast) doppelter Datenrate und ähnlicher Reichweite wie BT 4.2
   • Man Überträgt mit derselben Datenrate, aber dafür mit deutlich erhöhter Reichweite

Erwähnenswert ist außerdem, dass durch die höhere Bitrate bei hohen Datenmengen auch die Latenz sinken kann. Zwar liegt der minimale Connection Interval nach wie vor bei 7,5 ms, allerdings können nun deutlich mehr Pakete pro Interval übertragen werden.

Datensicherheit

BLE-Kommunikation findet in der Regel verschlüsselt statt. Eine Ausnahme stellen gewisse Daten, welche während dem Pairing ausgetauscht werden dar. Wie sicher eine BLE-Verbindung ist, steht und fällt mit dem verwendeten Pairing Mechanismus. Seit BT 4.2 gibt es die so genannten Secure Connections. Wie der Name erahnen lässt, wurde BT durch diese Mechanismen deutlich sicherer. Vor allem im Medizinbereich würde ich daher von der Verwendung der alten Legacy Connections abraten. Zum Glück unterstützen heute fast alle BLE-Geräte auf dem Markt Secure Connections. Der Unterschied im neuen Standard besteht im Protokoll, mit dem Schlüssel bei Pairing ausgetauscht werden. Hierfür wird seit 4.2 das Elliptic Curve Diffie-Hellman (ECDH) Verfahren angewendet, was die Sicherheit des Pairing Prozesses deutlich erhöht hat.

Leider werden trotzdem immer wieder Sicherheitslücken von BLE-Geräten bekannt. Diese resultieren allerdings in der Regel weniger aus der BT-Spezifikation, sondern sind in der Regel Folge einer mangelhaften Implementierung des Pairings. Wenn man den Einsatz von BLE im Medizinbereich plant, sollte man daher die Möglichkeit vorsehen, Bluetooth Hardware mit einem Update zu versehen, für den Fall, dass Sicherheitslücken bekannt werden.

Außerdem ist bei BLE Pairing nicht gleich Pairing. Seid BT 4.2 gibt es 4 verschiedene Pairing Mechanismen, welche jeweils ein unterschiedliches Maß an Sicherheit bieten.

• Just Works^TM: Wie der Name vermuten lässt, handelt es sich hierbei um einen einfachen, gleichzeitig aber vergleichsweise unsicheren Pairing Mechanismus, auch wenn die Sicherheit des Mechanismus im Vergleich zum alten BT 4.0 Standard deutlich erhöht wurde.
• Out of Band: Bei diesem Mechanismus wird ein großer Teil der Daten beim Pairing über eine alternative Verbindung ausgetauscht. Hierbei kann es sich z.B. über eine kabelgebundene Verbindung handeln. Zu beachten ist, dass dieser Mechanismus nur dann Sicherheit bietet, wenn der alternative Kanal nicht abgehört wird.
• Passkey: Bei diesem Verfahren erhalten beide Geräte einen 6-stelligen Code, welcher zur Authentifizierung der Verbindung dient. Das Verfahren wurde ebenfalls im Standard BT 4.2 deutlich sicherer gestaltet, bietet aber nach wie vor ein gewisses Risiko, besonders wenn statische Codes verwendet werden.
• Numeric Comparison: Dieses Verfahren ähnelt dem Just Works^TM, bietet allerdings eine erhöhte Sicherheit durch Hinzufügen eines weiteren Schritts am Ende des Pairings. Bei diesem berechnen beide Geräte einen 6-stelligen Code, welcher dem Nutzer auf den Displays der Geräte angezeigt wird. Der Nutzer muss nun auf beiden Geräten bestätigen, dass die Codes gleich sind. Diese Methode bietet einen erhöhten Schutz vor Angriffen, setzt aber das Vorhandensein von Displays auf beiden Geräten voraus.

Welche Pairing Methode gewählt wird hängt vom Anwendungsszenario und den daraus resultierenden Sicherheitsanforderungen ab. Werden sicherheitskritische oder personenbezogene Daten ausgetauscht, sollte man sich gut mit den jeweiligen Vor- und Nachteilen der jeweiligen Mechanismen auseinandersetzen.

Möchten Sie BLE einsetzen und haben dazu Fragen? Dann freuen wir uns, wenn wir Sie bei dem Thema unterstützen können. Nutzen Sie gerne unser Know-how an dieser Stelle.

Viele Grüße

Björn Schmitz