← Blog IoT

Bluetooth Mesh w IoT: architektura sieci i zastosowania

Bluetooth Mesh w IoT to rozszerzenie standardu Bluetooth Low Energy, które zamienia dziesiątki lub tysiące pojedynczych urządzeń w jedną, samonaprawiającą się sieć mesh o zasięgu całego budynku. Zamiast łączyć każdy czujnik czy oprawę z centralną bramką, węzły przekazują wiadomości między sobą, tworząc topologię wiele-do-wielu (many-to-many). Dla projektów z zakresu inteligentnego oświetlenia, automatyki budynkowej i hotelarstwa Bluetooth Mesh to często najtańsza droga do niezawodnej, pozbawionej pojedynczego punktu awarii łączności.

W skrócie: Bluetooth Mesh w IoT to warstwa sieciowa nad BLE, w której setki węzłów komunikują się metodą zarządzanego rozgłaszania (managed flooding), obsługując do 32 767 urządzeń w jednej sieci, z szyfrowaniem AES-CCM 128-bit na każdej warstwie i zasięgiem rozszerzanym przez węzły relay.

Diagram sieci Bluetooth Mesh w IoT — węzły przekazujące (relay) rozgłaszające wiadomości między oprawami oświetlenia i czujnikami
Zarządzane rozgłaszanie w sieci Bluetooth Mesh — wiadomość propaguje się przez węzły relay do wszystkich odbiorców

Czym jest Bluetooth Mesh?

Bluetooth Mesh to specyfikacja sieciowa opublikowana przez Bluetooth SIG w 2017 roku, która działa na warstwie fizycznej i łącza danych Bluetooth Low Energy. W odróżnieniu od klasycznego BLE, opartego na połączeniach punkt-punkt między urządzeniem a bramką (opisanym szerzej we wpisie o Bluetooth Low Energy w IoT), mesh pozwala każdemu węzłowi nadawać i odbierać wiadomości od wielu sąsiadów jednocześnie.

Sieć nie ma centralnego kontrolera ani routera — inteligencja jest rozproszona. Każdy węzeł może pełnić jedną lub kilka ról: zwykłego węzła, węzła relay (przekazującego), proxy (mostkującego do smartfona przez klasyczne BLE), friend oraz low power node. Ta ostatnia para umożliwia zasilanym bateryjnie czujnikom spanie przez większość czasu, podczas gdy sąsiedni węzeł friend buforuje dla nich wiadomości.

Jak działa zarządzane rozgłaszanie (managed flooding)?

Zarządzane rozgłaszanie to metoda propagacji, w której węzeł nadaje wiadomość, a każdy węzeł relay w zasięgu retransmituje ją dalej, aż dotrze do celu. To prostsze i bardziej odporne niż routing tablicowy stosowany w Zigbee, bo nie wymaga utrzymywania tras ani odbudowy topologii po awarii węzła.

Aby rozgłaszanie nie zalało sieci, standard stosuje trzy mechanizmy kontrolne: pole TTL (Time To Live, maks. 127 przeskoków) ograniczające liczbę retransmisji, message cache odrzucający wiadomości już widziane, oraz losowe opóźnienia nadawania redukujące kolizje. W praktyce dobrze zaprojektowana sieć ustawia TTL na wartość równą maksymalnej liczbie przeskoków plus margines — typowo 4–7 dla pojedynczego piętra.

  • Zasięg: pojedynczy przeskok BLE to 10–30 m w budynku; łańcuch relay rozszerza go do setek metrów.
  • Opóźnienie: propagacja przez kilka przeskoków to zwykle 20–100 ms — wystarczająco szybko dla sterowania oświetleniem.
  • Skalowalność: jedna sieć obsługuje adresowo do 32 767 węzłów unicast.

Architektura warstw i modele Bluetooth Mesh

Stos Bluetooth Mesh dzieli się na siedem warstw: model, foundation model, access, upper transport, lower transport, network i bearer. Ta warstwowość oznacza, że deweloper firmware operuje na modelach — gotowych definicjach zachowania — bez ręcznego składania pakietów.

Model to standaryzowana definicja funkcji urządzenia, na przykład Generic OnOff Model (włącz/wyłącz), Generic Level Model (ściemnianie) czy Light Lightness Model. Dzięki temu oprawa jednego producenta rozumie polecenia z przełącznika innego — interoperacyjność zbliżona do tej, jaką oferuje standard Matter i Thread. Komunikacja odbywa się przez publish/subscribe do adresów grupowych, co przypomina model znany z protokołu MQTT, ale realizowany w całości na brzegu sieci, bez brokera w chmurze.

Jak zabezpieczyć sieć: provisioning i szyfrowanie

Bezpieczeństwo w Bluetooth Mesh jest obowiązkowe i wielowarstwowe — nie ma trybu bez szyfrowania. Każda wiadomość jest chroniona algorytmem AES-CCM z kluczem 128-bit, a standard rozdziela klucze sieciowe (NetKey) od kluczy aplikacyjnych (AppKey), więc węzeł relay może przekazywać ruch, nie mając dostępu do jego treści.

Dołączenie nowego urządzenia to provisioning — proces, w którym provisioner (zwykle aplikacja mobilna lub bramka) uwierzytelnia węzeł i przekazuje mu klucze, wykorzystując wymianę Diffie-Hellman na krzywych eliptycznych (ECDH P-256) oraz OOB (out-of-band) do potwierdzenia tożsamości. Dobrą praktyką jest łączenie tego z tożsamością sprzętową urządzenia, podobnie jak przy wdrażaniu systemów IoT w hotelarstwie, gdzie każdy węzeł musi być jednoznacznie zaufany. Kluczowe mechanizmy bezpieczeństwa to:

  1. Rozdział NetKey/AppKey — izolacja warstwy sieci od warstwy aplikacji.
  2. Key Refresh Procedure — rotacja kluczy po usunięciu skompromitowanego węzła.
  3. Numery sekwencyjne i IV Index — ochrona przed atakami powtórzeniowymi (replay).

Bluetooth Mesh vs Zigbee vs Thread — kiedy wybrać?

Bluetooth Mesh wygrywa tam, gdzie liczy się wdrożenie i konfiguracja ze smartfona bez dedykowanej bramki oraz gęste sieci oświetleniowe. Sieć mesh oparta na Zigbee, opisana we wpisie o protokole Zigbee, oferuje niskie zużycie energii i dojrzały routing, ale wymaga koordynatora. Thread stawia na natywne IP (IPv6/6LoWPAN) i integrację z Matter.

Praktyczna zasada: dla sterowania oświetleniem komercyjnym i konfiguracji telefonem wybieraj Bluetooth Mesh; dla rozbudowanej automatyki z wieloma typami czujników i centralnym hubem rozważ Zigbee; dla ekosystemu smart home zgodnego z Matter — Thread.

Najczęściej zadawane pytania (FAQ)

Ile urządzeń obsługuje sieć Bluetooth Mesh?

Pojedyncza sieć Bluetooth Mesh adresuje do 32 767 węzłów unicast oraz dodatkowe adresy grupowe i wirtualne. W praktyce testowane wdrożenia komercyjne obejmują tysiące opraw oświetleniowych na jednej sieci, a limitem bywa nie adresacja, lecz gęstość ruchu i konfiguracja TTL.

Czy Bluetooth Mesh zużywa dużo energii?

Węzły relay muszą stale nasłuchiwać i dlatego zwykle są zasilane sieciowo. Urządzenia bateryjne działają jako low power node w parze z węzłem friend, który buforuje dla nich wiadomości — dzięki temu czujnik może spać i osiągać wieloletnią żywotność baterii, mimo że sama sieć nadaje intensywnie.

Czy Bluetooth Mesh potrzebuje internetu lub bramki?

Nie do działania lokalnego. Sieć funkcjonuje w pełni autonomicznie na brzegu — sterowanie i automatyka działają bez chmury. Bramka lub węzeł proxy są potrzebne dopiero, gdy chcemy zdalnego dostępu, telemetrii w chmurze lub integracji z systemami nadrzędnymi.

Podsumowanie i najważniejsze wnioski

Bluetooth Mesh w IoT to sprawdzona technologia dla gęstych, lokalnych sieci sterowania — zwłaszcza oświetlenia i automatyki budynkowej. Jej siłą jest zarządzane rozgłaszanie bez centralnego routera, obowiązkowe szyfrowanie AES-CCM, skalowalność do dziesiątek tysięcy węzłów i możliwość konfiguracji ze smartfona. Kluczowe kompromisy dotyczą zużycia energii węzłów relay oraz projektowania TTL, które trzeba dostroić do topologii budynku.

W FSS Technology projektujemy takie rozwiązania od strony sprzętu, firmware i chmury — od schematu PCB i stosu Bluetooth Mesh, przez provisioning i bezpieczeństwo, po integracje z systemami budynkowymi i hotelowymi. Jeśli planujesz wdrożenie sieci mesh dla oświetlenia, budynku lub obiektu hotelowego, poznaj naszą ofertę projektowania urządzeń podłączonych (connected devices) i porozmawiajmy o Twoim projekcie.