Ein Single-Hop-BLE Tag erreicht 10-30 Meter Reichweite in Innenraeumen. In einem 20.000 m2 grossen Lager bedeutet das dutzende Gateways fuer volle Abdeckung. Mesh-Netzwerke drehen das Modell um: Tags leiten Pakete gegenseitig weiter und erweitern die Reichweite Hop fuer Hop, bis die Daten ein Gateway erreichen. BLE Mesh 1.0 (2017) fuehrte Managed-Flood-Relay ein; Mesh 1.1 (2023) ergaenzte Directed Forwarding. Fuer Asset-Tracking loest Mesh drei Probleme: Reichweitenerweiterung ohne proportionale Gateway-Kosten, Fehlertoleranz durch redundante Pfade und schrittweise Verschlechterung bei Ausfall einzelner Tags.
Dieser Artikel zerlegt Mesh-Netzwerke aus der Perspektive batteriebetriebener Asset-Tags. Wir behandeln Protokoll-Internals, Relay-Knotenauswahl, Energiebudget-Berechnungen, Latenz und Durchsatz, Skalierbarkeitsgrenzen bei 100 bis 5000+ Knoten, Provisionierung im grossen Stil, Sicherheitsarchitektur und Vendor-Stack-Vergleich.
1. BLE Mesh-Protokollstack
BLE Mesh arbeitet ausschliesslich auf Advertising-Kanaelen (37/38/39 bei 2402/2426/2480 MHz) mit verbindungslosen PDUs. Der Stack hat fuenf Schichten:
| Schicht | Funktion | Schluesselparameter |
|---|---|---|
| Bearer | Transport ueber ADV oder GATT | ADV: 31-Byte PDU, 3 Kanaele; GATT: Proxy, 20-Byte MTU |
| Netzwerk | Adressierung, Relay, TTL | 29-Byte PDU, 7-Bit TTL, 24-Bit SEQ, 15-Bit Unicast |
| Unterer Transport | Segmentierung, Reassemblierung | 12-Byte Segment, 20s ACK |
| Oberer Transport | App-Key-Verschluesselung | Access-Payload-Verschluesselung, 4-Byte transMIC |
| Access | Modellnachrichten, Opcodes | Vendor 3 Byte, SIG 2 Byte |
Die Netzwerk-PDU ist kompakt: 1 Byte TTL, 3 Bytes SEQ (24-Bit-Sequenz fuer Replay-Schutz), 2 Bytes SRC, 2 Bytes DST und bis zu 12 Bytes Transport-Payload. Die gesamte PDU wird mit dem 128-Bit Network Key verschluesselt. Relay-Knoten leiten Pakete weiter, ohne den Anwendungs-Payload zu entschluesseln.
Fuer Asset-Tags ist der ADV-Bearer die einzige praktikable Option. GATT-Verbindungen verbrauchen 3-5 mA waehrend Verbindungsereignissen, was fuer Knopfzellen-Tags untragbar ist. Der Relay-Mechanismus arbeitet ausschliesslich auf dem ADV-Bearer.
2. Managed Flood: Wie Relay funktioniert
BLE Mesh verwendet Managed-Flood-Relay, keine Routing-Tabellen. Jeder Knoten mit aktivierter Relay-Funktion sendet empfangene Nachrichten erneut, gesteuert durch drei Mechanismen:
- TTL (Time To Live): 7-Bit-Zaehler, wird an jedem Hop dekrementiert. Bei 0 stoppt die Nachricht. Standard-TTL: 5-7 fuer Lager, 10+ fuer Campus.
- Message Cache: Jeder Knoten speichert kuerzlich gesehene Nachrichten, identifiziert durch (SRC, SEQ). Minimum 2 Eintraege; praktische Implementierungen verwenden 32-256. Duplikate werden verworfen, was Schleifen verhindert.
- Network-Key-Match: Nur Nachrichten mit bekanntem Network Key werden weitergeleitet.
Relay-Retransmission-Timing: Nach Empfang einer Nachricht wartet der Relay 3,5 ms (fester Backoff) plus 0-10 ms zufaellige Verzoegerung, dann sendet er auf allen drei Advertising-Kanaelen erneut. Latenz pro Hop: ca. 4-15 ms.
Warum Managed Flood statt Routing? Traditionelle Mesh-Protokolle (Zigbee, Thread) verwenden Routing-Tabellen, die Speicher (8-16 Byte pro Eintrag), periodische Routenaktualisierungen (Stromverbrauch) und Konvergenzzeit bei Topologieaenderungen (Sekunden bis Minuten) erfordern. Fuer mobile Asset-Tags ist Routing-Tabellen-Konvergenz unpraktikabel. Managed Flood vermeidet alle drei: kein Routing-Zustand, keine Routenaktualisierungen, instantane Pfadanpassung. Der Preis ist hoehere Nachrichtenduplikation und Kanalauslastung.
3. Relay-Knotenauswahl fuer Asset-Tags
Nicht jeder Tag sollte Relay sein. Die Relay-Funktion fuegt 200-500 uA zum durchschnittlichen Stromverbrauch hinzu, katastrophal fuer Knopfzellen-Tags. Die Strategie: Infrastrukturknoten als Relays festlegen, waehrend Asset-Tags als Non-Relay-Publisher arbeiten.
| Kriterium | Relay-geeignet | Non-Relay |
|---|---|---|
| Stromquelle | Netzbetrieb oder grosse Batterie | CR2032, CR2477 |
| Mobilitaet | Feste Infrastruktur | Mobile Asset-Tags |
| Position | Decken, Gaenge, Eingaenge | Zufaellig auf Assets |
| Funkumgebung | Stabiler RSSI (> -70 dBm) | Variabel durch Bewegung |
Produktionsdeployments verwenden 20-30 netzbetriebene Relay-Knoten fuer Mesh-Backbone-Abdeckung, waehrend 500-2000 Asset-Tags als Non-Relay-Knoten Daten publizieren. Das Relay-zu-Tag-Verhaeltnis haengt von der Skala ab:
| Skala | Relays | Tags | Verhaeltnis |
|---|---|---|---|
| Klein (2.000 m2) | 5-8 | 50-100 | ~10% |
| Mittel (10.000 m2) | 15-25 | 300-500 | ~5% |
| Gross (30.000 m2) | 40-60 | 1000-2000 | ~3% |
| Campus | 80-150 | 3000-5000 | ~2-3% |
4. Energiebudget: Relay vs Non-Relay
Non-Relay-Tag (nRF52840)
| Zustand | Strom | Intervall | Durchschnitt |
|---|---|---|---|
| Sleep (RAM-Retention) | 1,5 uA | – | 1,5 uA |
| RC32K + RTC | 0,2 uA | – | 0,2 uA |
| Advertiser TX (+4 dBm) | 4,6 mA | 100 ms | 24,3 uA |
| Advertiser RX | 5,2 mA | 100 ms | 23,4 uA |
| Sensor-Lesung (SHT40) | 0,9 mA | 10 s | 0,18 uA |
| Gesamt | – | – | ~49,6 uA |
CR2032 (175 mAh nutzbar), 100 ms Intervall:
Lebensdauer = 175.000 uAh / 49,6 uA = 3.528 h = 147 Tage1-Sekunden-Intervall (Stromsparmodus):
Gesamtdurchschnitt = 6,5 uA
Lebensdauer = 175.000 / 6,5 = 26.923 h = 3,1 JahreRelay-Tag (nRF52840, kontinuierliches Scannen)
| Zustand | Strom | Duty | Durchschnitt |
|---|---|---|---|
| Sleep | 1,5 uA | – | 1,5 uA |
| Scanner RX (3 Kanaele) | 5,2 mA | 30% | 1.560 uA |
| Relay TX | 4,6 mA | 0,5% | 23 uA |
| Eigenes Advertising | 4,6 mA | 0,05% | 2,3 uA |
| Gesamt | – | – | ~1.592 uA = 1,59 mA |
CR2032: 175.000 / 1.592 = 110 Stunden = 4,6 Tage (unpraktikabel)
4x AA (2.500 mAh): 2.500.000 / 1.592 = 1.571 h = 65 Tage
Netzbetrieb: unbegrenzt
Fazit: Relay-Knoten benoetigen externe Stromversorgung. Knopfzellen-Tags duerfen Relay niemals aktivieren. Produktionsdeployments verwenden dedizierte netzbetriebene Relay-Infrastruktur.
5. Nachrichtenlatenz und Durchsatz
Latenz pro Hop
Jeder Relay-Hop fuegt hinzu: Empfaengerverarbeitung (1-3 ms) + Relay-Backoff (3,5 + 0-10 ms) + Advertising-Ereignis (1,1 ms) = 5-16 ms typisch, 20 ms Worst Case.
5 Hops: 25-80 ms typisch, 100-150 ms Worst Case
10 Hops: 50-160 ms typisch, 200-300 ms Worst CaseKanalueberlastung
| Last (msgs/s) | Auslastung | Verlustrate | Hinweise |
|---|---|---|---|
| 50 | ~1% | <0,1% | Sauber |
| 200 | ~4% | 0,5-1% | Normal fuer 500 Knoten |
| 500 | ~10% | 2-5% | Grenze naehert sich |
| 1000 | ~21% | 8-15% | Ueberlastung |
| 2000 | ~42% | 25-40% | Unzuverlaessig |
Fuer 500-Knoten-Mesh, 5% Relays, TTL=7, 1 msg/10s:
Original: 500 x 0,1 = 50 msgs/s
Relay-Verstaerkung: x3,3
Gesamt: 165 msgs/s, Auslastung 3,4%, Verlust <0,5%Bei 1 msg/s (Echtzeit-Tracking):
Gesamt: 1.650 msgs/s, Auslastung 34%, Verlust 15-25% (Subnetting erforderlich)6. Skalierbarkeitsanalyse
| Knoten | Relays | TTL | Last | Verlust | P95 | Urteil |
|---|---|---|---|---|---|---|
| 100 | 5 | 5 | 33/s | <0,1% | 40 ms | Exzellent |
| 500 | 25 | 7 | 165/s | 0,5% | 80 ms | Gut |
| 1000 | 50 | 7 | 330/s | 2-3% | 120 ms | Akzeptabel |
| 2000 | 100 | 10 | 660/s | 5-8% | 200 ms | Grenzfall |
| 5000 | 250 | 10 | 1650/s | 15-25% | 500 ms | Subnet erforderlich |
| 5000 (5 Subnets) | 250 | 7 | 330/Sub | 2-3% | 120 ms | Gut |
Subnetting-Strategie
- Geografisch: Ein Subnet pro Etage/Gebaeude. Bridge-Knoten an Eingaengen.
- Funktional: Ein Subnet pro Anwendung. Reduziert Crosstraffic.
- Hierarchisch: Backbone-Subnet (nur Relay, Netzstrom) verbindet Tag-Subnets. Am skalierbarsten.
Jedes Subnet unterstuetzt 32.767 Unicast-Adressen. Die eigentliche Begrenzung ist Kanalauslastung, nicht Adressraum.
7. Directed Forwarding (Mesh 1.1)
Mesh 1.1 (2023) fuehrte Directed Forwarding ein: vorberechnete Pfade fuer Unicast-Nachrichten statt Managed Flood. Nur Knoten auf dem Pfad leiten die Nachricht weiter.
Vorteile: 60-80% weniger Kanalauslastung fuer Unicast-Traffic, 5000+ Knoten pro Subnet ohne Subnetting, 20-30% geringere Latenz.
Nachteile: Routing-Tabellen-Speicher (0,4-3,2 KB RAM), Pfadkonvergenz (2-10s bei Topologieaenderung), erfordert Mesh-1.1-Stack.
Empfehlung: Directed Forwarding auf festen Infrastruktur-Relay-Knoten aktivieren, Managed Flood fuer mobile Tags beibehalten.
8. Provisionierung im grossen Stil
Provisionierung weist Unicast-Adresse, Network Key, App Key und IV-Index zu. Verwendet PB-ADV (3-8s pro Geraet) oder PB-GATT (10-20s).
Batch-Provisionierung mit parallelen Sitzungen:
Sequenziell: 1000 x 5s = 83 Minuten
Batch (10): 8,3 Minuten
Batch (20): 4,2 MinutenPraktische Grenze: 20 parallele Sitzungen bevor Kanalueberlastung zu Fehlern fuehrt.
Adresszuweisung
| Bereich | Zweck | Anzahl |
|---|---|---|
| 0x0001-0x00FF | Provisionierer | 255 |
| 0x0100-0x0FFF | Relay/Infrastruktur | 3.840 |
| 0x1000-0x7EFF | Asset-Tags | 28.160 |
| 0x7F00-0x7FFF | Reserviert | 256 |
9. Sicherheitsarchitektur
| Schluessel | Geltungsbereich | Zweck |
|---|---|---|
| Device Key (128-Bit) | Pro Geraet, nur Provisionierer | Konfiguration, Node-Reset |
| Network Key (128-Bit) | Pro Subnet, alle Knoten | Netzwerkschicht-Verschluesselung |
| App Key (128-Bit) | Pro Anwendung | Access-Schicht, Sensordaten |
Relay-Knoten leiten Nachrichten mit dem Network Key weiter, koennen aber den Anwendungs-Payload nicht entschluesseln. Ein kompromittierter Relay erhaelt Netzwerkzugang, aber keinen Zugriff auf Sensordaten.
IV-Update
Die 24-Bit-SEQ bietet Replay-Schutz. Der IV-Index (32-Bit) inkrementiert, um den SEQ-Raum zurueckzusetzen. Mindestintervall: 96 Stunden. Bei 1 msg/10s pro Tag dauert SEQ-Ueberlauf 1.942 Tage (5,3 Jahre). IV-Updates sind fuer Asset-Tags selten.
Multi-Tenant-Isolation
Mehrere App Keys bieten logische Isolation. Jeder Tenant erhaelt einen eindeutigen App Key; Tags koennennicht gegenseitig lesen, selbst wenn sie denselben Network Key und Relay-Infrastruktur teilen.
10. BLE Mesh vs Thread vs Zigbee
| Parameter | BLE Mesh | Thread | Zigbee 3.0 |
|---|---|---|---|
| PHY-Rate | 1-2 Mbps | 250 kbps | 250 kbps |
| Relay | Managed Flood/Directed | RPL-Routing | Baum + Mesh |
| Routing-Zustand | 0 KB | 1-4 KB | 2-8 KB |
| Max. Knoten | 1000-5000/Subnet | 250-500 | 250-500 |
| Sleep-Strom | 1,5-5 uA | 3-10 uA | 2-5 uA |
| TX (+4 dBm) | 4,6 mA | 8,0 mA | 8,0 mA |
| Mobiler Knoten | Exzellent | Schlecht | Schlecht |
BLE Mesh gewinnt fuer Asset-Tags in drei Dimensionen: niedrigster TX-Strom (1-Mbps-PHY vs 250 kbps), instantane mobile Knotenanpassung (Flood vs Routing-Konvergenz) und native BLE-Radio-Kompatibilitaet.
11. Gateway-Integration
Ein Mesh-Gateway nimmt am Mesh teil (haelt Network Key) und hat IP-Konnektivitaet (Ethernet, Wi-Fi, Cellular). Es empfaengt Mesh-Nachrichten und leitet sie an die Cloud via MQTT oder HTTPS weiter.
Zwei Designs: (1) Proxy-Gateway ueber GATT-Proxy-Service fuer ad-hoc-Zugriff; (2) Embedded-Gateway (nRF52840 + Wi-Fi) fuer 24/7-Betrieb mit MQTT-Bridge.
Gateway-Dichte: 1 pro 200-500 Mesh-Knoten. Mehrere Gateways bieten Redundanz; die Cloud dedupliziert nach (SRC, SEQ).
Tag --> Relay --> Relay --> Gateway --> MQTT --> Dashboard
End-to-End: 200-800 ms12. Vendor-Mesh-Stack-Vergleich
| Vendor | SDK | SoC | Mesh 1.1 | RX | Hinweise |
|---|---|---|---|---|---|
| Nordic | NCS 2.5+ | nRF52840/nRF5340 | Ja | 5,2 mA | Beste Doku, Zephyr |
| Silicon Labs | GSDK 4.3+ | EFR32BG22/BG24 | Ja | 4,8 mA | Niedrigerer RX, BG24 96KB |
| TI | BLE-STACK 5.x | CC2642R/CC2652R | Teilweise | 5,9 mA | SimpleLink |
| Espressif | ESP-IDF | ESP32-C3/C6 | Nein (1.0) | 8-12 mA | Wi-Fi+BLE-Gateway |
Fuer Asset-Tags ist Nordic nRF52840 der Standard: ausgereifter Stack, beste Dokumentation, niedrigster kombinierter Sleep+Scan-Strom. SiLabs EFR32BG24 ist stark fuer Directed Forwarding (mehr RAM). ESP32-C3/C6 ueberzeugt bei Gateways mit Wi-Fi-Bedarf.
13. Codebeispiele
Relay-Konfiguration (nRF Connect SDK / Zephyr)
#include
static void configure_relay_node(uint16_t addr)
{
int err;
uint8_t count, intvl;
err = bt_mesh_cfg_relay_set(net_key_idx, addr,
BT_MESH_RELAY_ENABLED,
BT_MESH_TRANSMIT(1, 10),
&count, &intvl);
if (err) {
printk("Relay set failed: %d", err);
return;
}
err = bt_mesh_cfg_ttl_set(net_key_idx, addr, 7);
} Sensordaten-Publikation
#define SENSOR_DATA_OP BT_MESH_MODEL_OP_2(0x12, 0x00)
struct __attribute__((packed)) sensor_payload {
int16_t temperature;
uint16_t humidity;
uint16_t battery_mv;
};
static int publish_sensor(int16_t temp, uint16_t hum, uint16_t batt)
{
struct sensor_payload p = { temp, hum, batt };
struct bt_mesh_msg_ctx ctx = {
.addr = 0xC001,
.send_ttl = 7,
.app_idx = app_key_idx,
};
BT_MESH_MODEL_BUF_DEFINE(buf, SENSOR_DATA_OP, sizeof(p));
bt_mesh_model_msg_init(&buf, SENSOR_DATA_OP);
net_buf_simple_add_mem(&buf, &p, sizeof(p));
return bt_mesh_model_publish(&sensor_model);
}Python: Skalierbarkeitssaetzer
class MeshScalability:
def __init__(self, n_nodes, relay_ratio, ttl, msg_interval_s, subnets=1):
self.n = n_nodes
self.relays = int(n_nodes * relay_ratio)
self.ttl = ttl
self.interval = msg_interval_s
self.subnets = subnets
self.capacity = 4800
def relay_amp(self):
return 1 + self.relays * 0.3 * min(self.ttl / 7.0, 1.0)
def total_load(self):
per_subnet = self.n / self.subnets
return (per_subnet / self.interval) * self.relay_amp()
def utilization(self):
return self.total_load() / self.capacity
def loss(self):
u = self.utilization()
if u < 0.04: return u * 0.1
elif u < 0.10: return 0.004 + (u - 0.04) * 0.3
elif u < 0.21: return 0.022 + (u - 0.10) * 0.5
else: return 0.077 + (u - 0.21) * 1.2
m = MeshScalability(500, 0.05, 7, 10)
print(f"Load: {m.total_load():.0f} msgs/s, Loss: {m.loss()*100:.1f}%")14. Debugging und Diagnose
- Mesh-Sniffer: nRF Sniffer fuer Bluetooth LE in Wireshark. Nach Mesh-Advertising-Typ (0x2B) filtern. TTL-Dekrement, Relay-Retransmissions und Cache-Hits inspizieren.
- Heartbeat-Monitoring: Heartbeat-Publikation von Relay-Knoten konfigurieren. Das Ziel erhaelt periodische Nachrichten mit TTL und RSSI fuer Netzwerkgesundheits-Sichtbarkeit.
- Relay-Statistiken: Relay-Count pro Knoten, Cache-Hit-Rate und Retransmissionsfehler verfolgen. Hohe Cache-Hit-Rate zeigt gute Abdeckung; niedrige deutet auf Abdeckungsluecken.
- Haeufige Probleme: TTL-Erschoepfung (TTL erhoehen oder Relays hinzufuegen), Cache-Ueberlauf (Groesse erhoehen), Kanalueberlastung (Publikationsrate reduzieren oder Subnet), Provisioning-Timeout (Batch-Groesse reduzieren).
15. Produktionsdesign-Checkliste
- [ ] Relay-vs-Non-Relay-Verhaeltnis bestimmen (Ziel 3-10%)
- [ ] Energiebudget berechnen: Relay-Knoten benoetigen externe Stromversorgung
- [ ] TTL setzen: 5-7 einzelnes Gebaeude, 10+ Campus
- [ ] Message-Cache konfigurieren: minimum 32 Eintraege (192 Bytes RAM)
- [ ] Subnet-Architektur fuer Deployments >1.000 Knoten planen
- [ ] Batch-Provisioning-Workflow entwerfen (max 20 parallel)
- [ ] Network/App-Key-Hierarchie fuer Multi-Tenant-Isolation konfigurieren
- [ ] Publikationsintervall setzen: 10s Monitoring, 1s Echtzeit (erfordert Subnetting)
- [ ] Stresstest unter Uberlastung: 2x erwarteten Traffic injizieren und Verlust messen
- [ ] Gateway-Dichte planen: 1 pro 200-500 Knoten, mit Redundanz
- [ ] Heartbeat-Monitoring aktivieren
- [ ] Mesh-1.1-Directed-Forwarding-Kompatibilitaet bei >2.000 Knoten pruefen
- [ ] Mobile-Tag-Verhalten testen: Pfadanpassung bei Zonenwechsel verifizieren
- [ ] IV-Update-Verfahren und Key-Refresh-Zeitplan dokumentieren
- [ ] Firmware-OTA planen: Mesh-Modell-Verteilung fuer Massenupdates verwenden
Fazit
BLE-Mesh-Netzwerke transformieren Asset-Tracking von einem Single-Hop-, Gateway-gesaettigten Modell zu einem skalierbaren, selbstheilenden Netzwerk. Die wichtigsten Engineering-Entscheidungen sind: (1) netzbetriebene Infrastruktur fuer Relay-Knoten verwenden, niemals Knopfzellen-Tags; (2) Relay-zu-Tag-Verhaeltnis auf 3-10% je nach physischer Verteilung dimensionieren; (3) Kanalauslastung ueberwachen und vor Ueberschreitung von 1.000 aktiven Knoten subnetzen; (4) Directed Forwarding von Mesh 1.1 fuer Backbone-Skalierbarkeit nutzen; (5) Batch-Provisioning und Gateway-Redundanz fuer Produktionsdeployment planen.
Die Energiebudgetanalyse ist unerbittlich: ein Relay-aktivierter CR2032-Tag haelt 4,6 Tage, waehrend ein Non-Relay-Tag bei 1-Sekunden-Advertising 3,1 Jahre haelt. Dieser 2.400x-Unterschied bestimmt die Architektur: Infrastruktur-Relays mit Netzstrom, Batterie-Tags als Non-Relay-Publisher. Treffen Sie diese Trennung richtig, und das Mesh erledigt den Rest. Ob 50 Tags in einem Lager oder 5.000 in einem Industriecampus - diese Prinzipien helfen Ihnen, ein BLE Tag Mesh-Netzwerk zu architieren, das in der Produktion funktioniert.