Mit der Bluetooth-Spezifikation Version 5.3 wurden neue Funktionen für Bluetooth Low Energy eingeführt. Richtig angewendet können Entwickler damit Endgeräte realisieren, die noch sparsamer mit Energie umgehen – und zugleich zuverlässiger arbeiten.
Seit der Veröffentlichung der Version 5.3 der Bluetooth Core Specification [1] im Juli 2021 können Entwickler von mehr Flexibilität und Konfigurations-Optionen profitieren als jemals zuvor. Bestandteil dieses Version 5.3 waren drei Updates an Bluetooth Low Energy, die die Leistungsfähigkeit verbessern, die Stromaufnahme reduzieren und die Latenz für Geräte verringern können.
Die Verbesserungen sind darüber hinaus jedoch für alle Arten von Anwendungen und Geräten relevant, die Bluetooth Low Energy nutzen.Seit der Veröffentlichung der Version 5.3 der Bluetooth Core Specification [1] im Juli 2021 können Entwickler von mehr Flexibilität und Konfigurations-Optionen profitieren als jemals zuvor. Bestandteil dieses Version 5.3 waren drei Updates an Bluetooth Low Energy, die die Leistungsfähigkeit verbessern, die Stromaufnahme reduzieren und die Latenz für Geräte verringern können. Die Verbesserungen sind darüber hinaus jedoch für alle Arten von Anwendungen und Geräten relevant, die Bluetooth Low Energy nutzen.
Bluetooth-Geräte können unterschiedliche Zeitspannen für ein Verbindungsintervall festlegen, also für die Wartezeit des jeweiligen Geräts zwischen den aufeinander folgenden Verbindungs-Ereignissen. Längere Verbindungsintervalle sparen Strom, weil pro Zeiteinheit weniger häufig kommuniziert wird. Andererseits lässt sich mit kürzeren Verbindungsintervallen erreichen, dass ein Gerät schneller reagiert und pro Zeiteinheit mehr Daten übertragen kann.
Durch Ändern des Verbindungsintervalls entsteht Latenz. In der Praxis bedeutet dies, dass bis zu sechs Verbindungs-Ereignisse erforderlich sind, um die von einem Gerät gewünschte Änderung des Verbindungsintervalls umzusetzen (siehe Bild 1).
Die Zeit, die für diese sechs Ereignisse benötigt wird, kann zu einem Problem werden, wenn das Verbindungsintervall als Reaktion auf eine externe Messung von lang auf kurz geändert werden soll. Sind sechs Verbindungsintervalle erforderlich, um das Verbindungsintervall beispielsweise von 1 s auf 100 ms zu verkürzen, ergibt sich für den Anwender eine Wartezeit von immerhin 6 s, bevor die Änderung vollzogen ist.
Kommt dies in einer zeitsensiblen Applikation vor, wie etwa beim schnellen Auslesen eines Sensors, ist eine derartige Latenz unter Umständen inakzeptabel. Abhilfe schafft das so genannte »connection subrating«, mit dem sich der Zeitaufwand für den Wechsel von einem langen zu einem kurzen Verbindungsintervall verkürzen lässt. Hierfür werden die Zentrale und die Peripherieeinheit angewiesen, Verbindungs-Ereignisse zu überspringen – abhängig davon, ob im letzten Verbindungsereignis Daten übertragen wurden oder nicht.
Um connection subrating zu nutzen, müssen vom Anwender zwei Parameter angegeben werden, nämlich ein Subrate-Faktor und ein Continuation-Wert. Beim Subrate-Faktor handelt es sich um die Zahl ungenutzter Verbindungs-Ereignisse zwischen zwei genutzten Verbindungs-Ereignissen. Wie Bild 2 verdeutlicht, muss nach jedem Subrate-Faktor ein Verbindungs-Ereignis genutzt werden, unabhängig davon, ob tatsächlich Daten zur Übertragung anstehen oder nicht.
Der Continuation-Wert gibt an, auf wie viele aufeinander folgende Verbindungen Geräte nach einem nicht-leeren Verbindungsereignis – einem Verbindungsereignis also, bei dem Daten zwischen Geräten übertragen werden – antworten müssen. Nicht in allen Verbindungsereignissen werden tatsächlich Daten übertragen. Viele werden stattdessen nur genutzt, um die Verbindung zwischen den Geräten aufrecht zu erhalten.
In Bild 3 lautet der Continuation-Wert 1. Nach einem nicht-leeren Verbindungsereignis (5) werden die nachfolgenden Verbindungen weiterhin verarbeitet, bis das nächste leere Verbindungs-Ereignis (8) vorkommt. Von hier an werden sämtliche Ereignisse nicht genutzt, bis das nächste Subrating-Verbindungsereignis (10) vorkommt.
Mit dem beschriebenen Verfahren reduziert sich die beim Ändern des Verbindungsintervalls entstehende Verzögerung, weil kein gesondertes Aushandeln zwischen den Geräten mehr nötig ist. Stattdessen kann die Änderung dynamisch für jedes Verbindungsereignis erfolgen.
Das Bluetooth-Protokoll unterteilt das 2,4-GHz-Frequenzband in kleinere, jeweils 2 MHz breite Kanäle, zwischen denen die beteiligten Geräte während ihrer Kommunikation hin und herwechseln. Diese Spread-Spectrum-Strategie vermindert die Zahl der auftretenden Paketkollisionen und der Störbeeinflussungen im ISM-Band (Industrial, Scientific and Medical), indem die Geräte sehr oft den Kanal wechseln, und zwar in einer zufälligen oder vorher festgelegten Abfolge. Diese Kanalabfolge wird als Channel Map (Kanalplan) bezeichnet.
In der Vergangenheit entschied allein das zentrale Gerät über den Kanalplan. Es scannte hierfür die verschiedenen Kanäle im 2,4-GHz-Band, um festzustellen, welche Kanäle für die Kommunikation in Frage kämen (Bild 4). Dicht belegte Kanäle wurden dabei ausgeklammert, um die Wahrscheinlichkeit von Paketkollisionen zu verringern.
Da die Priorität allein vom zentralen Gerät festgelegt wurde, hatten Peripheriegeräte keinerlei Mitspracherecht, was die verwendeten Kanäle betraf. Da Bluetooth-Geräte aber über immer größere Distanzen kommunizieren können, kann es vorkommen, dass Peripherie und Zentrale unterschiedliche Bedingungen in ihrer Umgebung vorfinden. Diese Unterschiede können problematisch werden, wenn im Kanalplan auch solche Kanäle verzeichnet sind, die aus Sicht der Zentrale keine nennenswerten Störungen aufweisen, beim Peripheriegerät aber in den Kanälen das Störaufkommen erheblich ist (Bild 5).
Mit Einführung der Coded-PHY-Technik in Bluetooth LE sind die Entfernungen, die sich mit Bluetooth-LE-Verbindungen überbrücken lassen, drastisch gewachsen. Ein Beispiel sind elektronische Regalplatz-Etiketten: es wäre wenig sinnvoll, wenn hier allein die Zentraleinheit über den Kanalplan entscheiden würde, denn die elektronischen Etiketten sind über die gesamte Fläche eines Ladengeschäfts verteilt und finden dabei naturgemäß sehr unterschiedliche Kanalbedingungen vor, die jedoch im Kanalplan unberücksichtigt bleiben, wenn dieser ausschließlich von der Zentrale aufgestellt wird.
Mit der neuen, verbesserten Kanal-Klassifizierung können die Peripheriegeräte ihre Kanal-Klassifizierung an die Zentrale melden, um Einfluss auf die Aufstellung des Kanalplans für die Kommunikation zwischen Peripherie und Zentrale zu nehmen. Hierdurch sinkt das Risiko, dass Datenpakete verlorengehen, wenn der verwendete Kanal bei einer der beteiligten Einheiten dicht belegt ist, denn bei der Festlegung des Kanalplans werden die Bedingungen beider Seiten berücksichtigt (siehe Bild 6).
Bluetooth-LE-Geräte, die das periodische Advertising nutzen, senden Informationen in der Regel mehrere Male, um die Diversität der Übertragung zu steigern und die Wahrscheinlichkeit dafür zu erhöhen, dass ein scannendes Gerät die Übertragung korrekt decodiert. Dies führt dazu, dass die empfangenden Geräte mehrere Kopien ein und desselben Pakets erhalten und decodieren und dafür unnötig Energie aufwenden.
Deshalb können sendende Geräte jetzt beim periodischen Advertising ein AdvDataInfo-Feld in die von ihnen gesendeten Pakete einfügen, damit die empfangenden Einheiten feststellen können, ob sie das betreffende Paket schon einmal empfangen haben. Ist dies der Fall, wird der Empfang abgebrochen, damit die Funkeinheit weniger Energie benötigt. Außerdem wird hierdurch vermieden, dass die Funkeinheit das redundante Paket an den Hostprozessor überträgt. Durch Filtern der Daten, die an den Hostprozessor weitergegeben werden, können Geräte ihren Energiebedarf senken, indem sie redundante Pakete ignorieren (siehe Bilder 7 und 8).
Besonders nützlich ist dies bei batteriebetriebenen Bluetooth-LE-Geräten wie etwa Asset-Tracking-Tags, die nach Bluetooth-LE-Beacons suchen. Um die Batterielebensdauer zu verlängern, wird hier angestrebt die Energieaufnahme auf ein Minimum zu reduzieren. Dementsprechend kann es sich ein Entwickler hier schlicht nicht leisten, Energie mit der Verarbeitung redundanter Informationen zu vergeuden. Mit dem neuen Update der Spezifikation können solche Anwendungen ihre Energieeffizienz gegenüber früher verbessern.
Literatur
[1] Hollander, D.: New Core Specification v5.3 Feature Enhancements. Bluetooth SIG, Bluetooth Blog, 15. Juli 2021, www.bluetooth.com/blog/new-core-specification-v5-3-feature-enhancements/.
[2] Wooley, M.: Bluetooth Core Specification Version 5.3 Feature Enhancements. Bluetooth SIG, Version 1.0.0, 24. Juni 2021, www.bluetooth.com/bluetooth-resources/bluetooth-core-specification-version-5-3-feature-enhancements/.
Der Autor
Nathan Block
ist Applikationsingenieur bei Texas Instruments im 2,4-GHz-Konnektivitätsteam. Zu seinen Aufgaben zählt die Unterstützung von netzwerkfähigen Mikrocontrolleranwendungen, mit erschwinglichen, stromsparenden ICs und Modulen, die mit integrierten Wireless-Protokollstacks und Beispielen für die Entwicklung geliefert werden.
Block schloss sein Studium der Elektrotechnik an der University of Michigan im Jahr 2020 mit einem Bachelor- und einem Master-Abschluss ab.