Die meisten BLE-Tag-Entwuerfe sind entweder reine Sender (ein Ortungstag, das nie hoert) oder Dauer-Scanner (ein Tag, das den Gateway-Ping hoeren muss). Der reine Sender ist fuer zentrale Befehle unsichtbar; der Scanner leert eine Knopfzelle in Wochen. Dieser Artikel behandelt die Mitte: ein Tag bei Bedarf erreichbar zu machen und dabei den Mittelstrom im einstelligen Mikroampere-Bereich zu halten.

Das Erreichbarkeitsproblem

Ein BLE-Tag, das nur sendet, kann nicht gepaget werden. Wenn du “dieses bestimmte Asset jetzt finden” oder eine Konfigaenderung pushen willst, hat der Gateway keinen Gespraechspartner. Die naive Loesung: das Tag dauerhaft scannen lassen:

  • RX-Strom eines typischen SoC (nRF52840, nRF5340): 4-8 mA
  • Eine CR2032 mit ~220 mAh nutzbar: 220 / 8 ca. 27 Stunden

Das ist inakzeptabel. Dauerhaftes Lauschen verwandelt ein Mehrjahre-Tag in ein Eintagestag.

Drei Lausch-Strategien

Strategie Lauschstrom Erreichbarkeitslatenz Jahres-Batteriekosten*
Dauer-Scan 5-8 mA ~10 ms in Tagen leer
Periodischer (duty-cycled) Scan 200-400 uA im Mittel ein Intervall (z.B. 2 s) Monate
Wake-up-Radio (WuR) 50-200 nA Wake-Symbol + Boot (~5-50 ms) Jahre

*CR2032, Idle-Sendebasis 5 uA aufgeschlagen.

Der periodische Scan tauscht Latenz gegen Strom: oeffne ein RX-Fenster von W ms alle T ms. Mittlerer Lauschstrom ca. I_rx * W / T. Bei W=100 ms, T=2000 ms, I_rx=5 mA: im Mittel ca. 250 uA. Mit Basis bist du bei ~300 uA – Monate Lebensdauer, aber weit von den Jahren eines reinen Senders entfernt.

Wake-up-Empfaenger

Ein Wake-up-Radio ist ein zweiter Ultra-Low-Power-Empfaenger, der auf ein dediziertes Wake-Symbol abgestimmt ist. Er horcht fast durchgehend mit 50-200 nA und schaltet bei gueltigem Muster das Haupt-BLE-Radio ein. Da das Hauptradio nur nach einem Wake-Ereignis laeuft, wird sein 5-mA-RX-Strom auf seltene Ereignisse verteilt.

WuR-Implementierungen fuer BLE-Klasse-Tags:

  • Sub-GHz OOK/ASK WuR (z.B. 433 MHz, 868 MHz): lange Reichweite, guenstig, proprietaeres PHY. Ein Gateway-Broadcast weckt alle Tags im Umkreis; jeder verifiziert ein Token vor dem BLE-Boot.
  • Induktiv 125 kHz: sehr kurze Reichweite (cm-m), gut fuer “tap to wake”-Leser, immun gegen 2,4-GHz-Stau.
  • In-Band-Preamble-Sniff: manche SoCs schnueffeln das BLE-Preamble mit wenig Strom; kein echtes WuR, aber guenstiger als voller RX.
  • Dedizierter WuR-IC: eigenes Chip auf 2,4 GHz, der ein Interrupt an den SoC gibt; Lauschen gesamt ~100 nA.

Es gibt kein standardisiertes BLE-Wake-up; jeder Hersteller macht es proprietar. Plan einen Gateway, der dein WuR-PHY spricht.

Latenz-Mathematik

Verbindungsloses Paging: max. Latenz = Wake-Fensterperiode T. Sendet der Gateway das Wake-Symbol L ms und das WuR tastet alle S ms ab, antwortet ein Tag innerhalb S + Boot. Bei S=100 ms und BLE-Boot 20 ms: schlimmster Fall ~120 ms.

Verbindungsorientiert (Gateway verbindet dann): plus Verbindungsaufbau (~30-80 ms) und GATT-Discovery falls nicht gecacht. Budget ~150-250 ms von Ende zu Ende.

Ein periodisch scannendes Tag hat den schlechteren schlimmsten Fall: es kann das Paging-Fenster des Gateways verpassen und ein volles Intervall T warten. Bei T=2 s sind das bis 2 s Latenz – okay zum “Asset orten”, schlecht fuer interaktiv.

Strombudget-Beispiel

Ein Tag, 10-mal/Tag gepaget, jeder Wake bootet BLE 200 ms bei 5 mA:

  • WuR-Lauschen: 100 nA * 86400 s = 8,64 mC/Tag
  • 10 Wake * 200 ms * 5 mA = 10 mC/Tag
  • Sende-Basis 5 uA * 86400 = 432 mC/Tag
  • Gesamt ca. 451 mC/Tag -> CR2032 (220 mAh = 792000 mC) -> ~4,8 Jahre

Der WuR-Lauschstrom ist Rundungsfehler. Das ist der Kernpunkt.

Implementierungs-Skizze

<h1>pseudo: nRF wacht per Interrupt vom WuR-IC auf</h1>

def on_wake_interrupt():
ble.power_on()
ble.advertise_wake_token(signed_token)   # beweist, dass es ein echtes Page ist
if gateway.connected:
handle_command()
ble.power_off()

<h1>RTC plant Fallback-Periodik-Scan falls WuR versagt</h1>

rtc.every(3600s, short_scan, window_ms=50)

Das signierte Wake-Token zaehlt: ohne es kann ein Angreifer mit WuR-Sender alle Tags im Umkreis dauerhaft wecken und die Flotte leeren (Denial-of-Sleep-Angriff).

Sicherheitshinweis

Ein nicht authentifiziertes Wake-Symbol ist ein Batterie-DoS-Primitiv. Fordere ein authentifiziertes, replay-geschuetztes Token (z.B. HMAC mit Tag-Schluessel + Rollcounter). Ein Tag, das das Token nicht verifizieren kann, muss schlafen bleiben. Auch ratelimitieren: zweites Wake innerhalb N Sekunden ignorieren, um eine Jam-and-Drain-Schleife zu daempfen.

Wann ein WuR-Tag nutzen

  • Du musst bestimmte Assets pagieren (“zeig mir, wo Palette X jetzt ist”).
  • Tags schlafen Jahre zwischen Kontakten (Kuehlkette, statische Assets).
  • Gateway-Dichte ist niedrig und du kannst keinen Durchgangsdeckung pro Tag leisten.

Weglassen, wenn das Tag ein reiner Sender ist, den feste Gateways schon abdecken, oder wenn Latenz unter ~100 ms Pflicht ist (dann kleinen Periodik-Scan halten).

Fazit

Ein BLE-Tag muss nicht zwischen “nie erreichbar” und “Batterie in einer Woche leer” waehlen. Ein Wake-up-Empfaenger verschiebt die Lauschkosten von Milliampere auf Nanoampere, und ein periodischer Scan ist der pragmatische Mittelweg ohne WuR-PHY. Bemiss Wake-Fenster und -Intervall nach deinem Latenzbudget, authentifiziere den Wake, und das Tag bleibt Jahre erreichbar.