Thread · OTBR · IEEE 802.15.4 · IPv6 mesh · Border Router · 10 min czytania

Uruchamianie sieci Thread: Border Router, OTBR i projektowanie topologii siatki

Thread to energooszczędny protokół sieci mesh IPv6 oparty na IEEE 802.15.4, zapewniający samonaprawiającą się infrastrukturę mesh połączoną z Border Routerem dla urządzeń Matter w budynkach. W przeciwieństwie do Zigbee, Thread jest natywnie IP – każdy węzeł ma adres IPv6 i jest bezpośrednio osiągalny z szkieletu IP przez Border Router, eliminując bramy translacji protokołów.

Podstawy radia i sieci Thread

Thread działa na warstwie fizycznej i MAC IEEE 802.15.4 przy 2,4 GHz z wykorzystaniem 16 kanałów (kanały 11–26, odstęp 5 MHz, 250 kbit/s). Warstwę sieciową stanowi skompresowane IPv6 przez 6LoWPAN. Thread używa zabezpieczeń TCAT opartych na DTLS do uruchamiania oraz AES-128-CCM dla całego ruchu w sieci mesh. Protokół jest utrzymywany przez Thread Group (threadgroup.org), a specyfikacja jest dostępna bezpłatnie dla członków.

Parametr	Wartość	Uwagi
Częstotliwość	Pasmo ISM 2,4 GHz	To samo pasmo co Wi-Fi 2,4 GHz i Zigbee – wymagane planowanie kanałów
PHY / MAC	IEEE 802.15.4-2015	250 kbit/s, DSSS, modulacja OQPSK
Sieć	IPv6 z 6LoWPAN	Kompresja nagłówka redukuje IPv6 do ~40 bajtów w ramce 802.15.4 o rozmiarze 127 bajtów
Bezpieczeństwo sieci mesh	AES-128-CCM	Szyfrowanie warstwy sieciowej, uwierzytelnianie na ramkę
Maks. węzłów	250+ na partycję Thread	Wiele partycji można połączyć za pomocą routera szkieletowego
Typowy zasięg wewnątrz	10–15 m na skok (ściany betonowe)	Linia widzenia: ~50 m; siatka rozszerza zasięg
Maks. skoków	Brak twardego limitu (praktycznie: 10–15)	Każdy przeskok dodaje ~5–10 ms opóźnienia
Prąd uśpienia (SED)	~5–15 µA typowo	Sleepy End Device: budzi się co 10–1000 ms na sondę rodzica

Współistnienie kanałów: Thread w paśmie 2,4 GHz nakłada się na kanały Wi-Fi 2,4 GHz. Użyj kanału Thread 15 lub 20 (wolnego od kanałów Wi-Fi 1, 6 i 11), aby zminimalizować zakłócenia. Jeśli budynek intensywnie korzysta z Wi-Fi 2,4 GHz, przed wyborem kanału Thread wykonaj skan widma (Wireshark + sniffer 802.15.4 lub diagnostyka OTBR).

Role węzłów

Węzły Thread samoorganizują się w role na podstawie możliwości i jakości łącza. Przydział ról jest automatyczny i dynamiczny – Router może zostać zdegradowany, jeśli poprawi się łączność siatki, a Urządzenie końcowe może zostać awansowane, jeśli siatka potrzebuje większej przepustowości routingu. Zrozumienie ról jest niezbędne do planowania topologii, ponieważ rozmiar tablicy routera, interwał uśpienia i przypisanie rodzica bezpośrednio wpływają na powodzenie uruchomienia i niezawodność eksploatacyjną.

Rola	Skrót	Charakterystyka	Typowe urządzenie
Lider	L	Jeden na partycję; zarządza tablicą routera, przypisaniami prefiksów, danymi sieciowymi. Wybierany automatycznie.	Każde zasilane sieciowo urządzenie Thread
Router	R	Przekazuje ruch sieci mesh; utrzymuje tablicę sąsiadów; maks. 32 routery na partycję. Tylko zasilane sieciowo.	Inteligentne gniazdka, żarówki, termostaty
Urządzenie końcowe z możliwością bycia routerem	REED	Może stać się routerem w razie potrzeby; zachowuje się jak urządzenie końcowe do czasu awansu.	Urządzenia zasilane sieciowo z ≥48 KB RAM
Pełne urządzenie końcowe	FED	Pozostaje aktywny; ma router nadrzędny; nie rutuje; odbiera bezpośrednie wiadomości.	Czujniki, wyświetlacze zasilane sieciowo
Uśpione urządzenie końcowe	SED	Odpytywanie routera nadrzędnego w konfigurowalnym interwale (10 ms–10 s); radio wyłączone między odpytywaniami.	Czujniki baterii, PIR, styki drzwiowe
Zsynchronizowane urządzenie uśpione	SSED	Skoordynowany sen z rodzicem dla ściślejszej kontroli opóźnień (Thread 1.3+).	Akumulatorowe siłowniki wymagające szybkiej odpowiedzi

Planowanie interwału odpytywania SED: Urządzenie uśpione z 10-sekundowym interwałem odpytywania ma maksymalne opóźnienie polecenia wynoszące 10 sekund (polecenie dociera tuż po odpytywaniu). W przypadku przełączników światła i czujników obecności sterujących oświetleniem należy stosować interwały odpytywania 250 ms lub krótsze – kosztem większego zużycia baterii. W przypadku czujników kontaktu drzwi/okien, gdzie codzienna żywotność baterii jest ważniejsza niż czas reakcji, dopuszczalne są interwały 10-sekundowe.

Border Router: OTBR i komercyjne alternatywy

Router graniczny Thread (Thread Border Router) jest bramą między siecią mesh Thread (802.15.4) a szkieletem IP (Ethernet lub Wi-Fi). Zapewnia NAT64 (dla systemów IPv4), DNS64, DHCPv6-PD oraz routing poza siecią mesh. Sieć Thread wymaga co najmniej jednego routera granicznego, aby umożliwić komisjonowanie Matter z urządzenia podłączonego przez IP oraz aby kontroler fabric Matter mógł dotrzeć do urządzeń tylko Thread.

Router graniczny	Stos Thread	Obsługa fabric Matter	Uwagi
OTBR (Raspberry Pi / Linux)	OpenThread 1.3	Dowolny – integruje się z HA, chip-tool	Pełny dostęp diagnostyczny; zalecany do projektów komercyjnych
Apple HomePod mini (2. generacja)	Apple Thread 1.3	Apple Home fabric	Automatycznie konfigurowane; brak dostępu użytkownika do zbioru danych Thread
Apple HomePod (2. generacja)	Apple Thread 1.3	Apple Home fabric	Tak samo jak HomePod mini; preferowany do dużych pomieszczeń
Apple TV 4K (3. generacja, Ethernet)	Apple Thread 1.3	Apple Home fabric	Połączenie Ethernet preferowane dla stabilności routera granicznego
Google Nest Hub (2. gen.)	Google Thread 1.3	Google Home fabric	Automatycznie skonfigurowany; ograniczony dostęp diagnostyczny
Google Nest Hub Max	Google Thread 1.3	Google Home fabric	Taki sam jak Nest Hub 2. gen.
Nanoleaf Thread Border Router	OpenThread 1.3	Apple + Google przez wspólny zestaw danych	Dedykowany BR; udostępnia interfejs webowy OTBR
Home Assistant SkyConnect USB	OpenThread 1.3	Serwer HA Matter	Klucz USB; działa jako BR, gdy dodatek HA OTBR jest włączony

Tworzenie zestawu danych Thread i konfiguracja OTBR

Thread Operational Dataset (OTDS) to zestaw parametrów sieciowych definiujących partycję Thread. Wszystkie urządzenia w tej samej sieci Thread muszą mieć ten sam Active Operational Dataset. W przypadku korzystania z OTBR na Linuksie (Raspberry Pi lub odpowiednik) zestaw danych jest tworzony podczas inicjalizacji OTBR i można go przeglądać oraz eksportować za pomocą interfejsu REST API OTBR lub narzędzia wiersza poleceń ot-ctl.

Instalacja OTBR i tworzenie zestawu danych (Ubuntu / Raspberry Pi OS)

# Install OTBR (automated script — pulls Docker image or builds from source)
curl -sL https://raw.githubusercontent.com/openthread/ot-br-posix/main/script/bootstrap   | sudo bash -s -- --no-mdns
sudo INFRA_IF_NAME=eth0 ./script/setup

# Or via Docker (recommended for reproducible builds):
docker run --sysctl "net.ipv6.conf.all.disable_ipv6=0   net.ipv4.conf.all.forwarding=1 net.ipv6.conf.all.forwarding=1"   -p 8080:80 --dns=127.0.0.1 -it openthread/otbr:latest   --radio-url spinel+hdlc+uart:///dev/ttyUSB0

# Generate a new Thread dataset via ot-ctl:
sudo ot-ctl dataset init new
sudo ot-ctl dataset channel 15          # Set channel (avoid Wi-Fi overlap)
sudo ot-ctl dataset networkname PanelCraft-Thread
sudo ot-ctl dataset commit active
sudo ot-ctl ifconfig up
sudo ot-ctl thread start

# Verify dataset:
sudo ot-ctl dataset active              # Shows full OTDS in TLV format
sudo ot-ctl state                       # Should show: leader

# Export dataset as hex (for import into other Border Routers):
sudo ot-ctl dataset active -x

Interfejs webowy OTBR — kluczowe pola

OTBR web UI accessible at: http://<border-router-ip>:80

Thread Network Configuration page shows:
  Network Name:     PanelCraft-Thread
  Extended PAN ID:  6c32fcf3fe56e68b   (random 8 bytes — unique per network)
  Network Key:      d3aba6ca7f1d8e12... (128-bit AES key — keep confidential)
  PAN ID:           0x4f2b              (16-bit, random)
  Channel:          15
  On-Mesh Prefix:   fd11:22::/64       (ULA prefix assigned by Leader)

Status page shows:
  Role:             Leader / Router / Detached
  RLOC16:           0x2000             (16-bit routing locator)
  Ext Address:      ba:c7:3a:01:...    (64-bit IEEE extended address)
  Neighbours:       3 routers, 5 end devices

Projektowanie topologii: rozmieszczenie routerów brzegowych i zasięg routerów

Siatka Thread jest samonaprawialna, ale nie samooptymalizująca się pod kątem początkowego rozmieszczenia. Złe rozmieszczenie routerów brzegowych i routerów prowadzi do podzielonych siatek, nadmiernej liczby skoków oraz urządzeń uśpionych, które nie mogą znaleźć stabilnego rodzica. Poniższe zasady dotyczą wdrożeń w budynkach komercyjnych.

Zasady rozmieszczania routerów brzegowych

Umieść co najmniej 2 routery brzegowe na piętro dla nadmiarowości – jeśli jeden ulegnie awarii, siatka pozostaje połączona z szkieletem IP
Podłącz routery brzegowe przez Ethernet, a nie Wi-Fi – eliminuje podwójne opóźnienie bezprzewodowe i poprawia stabilność
Zlokalizuj blisko centrum klastra urządzeń Thread, które obsługują, a nie na skraju sieci IP
Minimum 1 BR na 500 m² otwartej przestrzeni; 1 BR na 250 m² ze ścianami z betonowym rdzeniem
Routery brzegowe nie muszą być w zasięgu RF siebie nawzajem – łączą się przez szkieletowy router Ethernet

Zasady gęstości routerów

Thread automatycznie awansuje REEDy do routerów, gdy w partycji jest mniej niż 16 routerów
Cel: każde SED powinno mieć co najmniej 2 routery w zasięgu jednego skoku – brak zależności od jednego rodzica
W gęstych wdrożeniach czujników (50+ SED na pomieszczenie): zapewnij co najmniej 4 routery zasilane sieciowo na 100 m²
Inteligentne gniazdka i sieciowe sterowniki oświetlenia to idealni kandydaci na routery – zawsze włączone, dobrze rozmieszczone
Maksymalnie 32 routery na partycję Thread – w razie potrzeby projektuj duże budynki jako wiele partycji

Ryzyko podziału partycji:Jeśli urządzenia Thread na piętrze stracą kontakt ze wszystkimi routerami podłączonymi do routera granicznego, utworzą oddzielną partycję z własnym liderem, ale bez łączności internetowej/IP. Polecenia Matter z kontrolera tkaniny przekroczą limit czasu. Rozwiązanie: dodaj urządzenie z możliwością routera na granicy lub popraw ścieżkę sygnału. Wykrywaj partycje za pomocą widoku topologii OTBR (pokazuje izolowane klastry węzłów).

Diagnostyka: narzędzia OTBR i kontrole stanu siatki

Stan siatki Thread powinien być weryfikowany po pierwszym uruchomieniu i okresowo podczas użytkowania budynku. OTBR udostępnia REST API i interfejs CLI ot-ctl do diagnostyki; interfejs webowy OTBR zapewnia graf topologii do inspekcji wizualnej.

Kluczowe polecenia diagnostyczne ot-ctl

# Network state and role
sudo ot-ctl state          # leader / router / child / detached / disabled
sudo ot-ctl channel        # Current operating channel
sudo ot-ctl panid          # 16-bit PAN ID

# Router and neighbour table
sudo ot-ctl router table   # All routers in partition: RLOC16, ext addr, link quality
sudo ot-ctl neighbor table # Direct neighbours: role, RLOC16, link margin, RSSI

# Link quality (RSSI) to specific neighbour
sudo ot-ctl neighbor linkinfo <rloc16>
# Look for: link margin >10 dBm is good; <5 dBm is marginal

# End device child table (children of this router)
sudo ot-ctl child table    # Shows: child ID, mode (SED/FED), poll interval, age

# Partition info
sudo ot-ctl partitionid    # Partition ID — should be same on all nodes
sudo ot-ctl leaderdata     # Leader RLOC, partition weight, data version

# Network topology (via OTBR REST API)
curl http://localhost:8080/api/v1/node/rloc16
curl http://localhost:8080/api/v1/topology  # Full mesh topology JSON

# Ping a Thread node by IPv6 address
sudo ot-ctl ping fd11:22::1  # Replace with node's mesh-local EID

Metryka diagnostyczna	Wartość prawidłowa	Działanie w przypadku odchylenia
Margines łącza do rodzica (SED)	> 10 dBm	Dodaj router pośredni lub przesuń urządzenie bliżej routera
Liczba tabel routera	2–32	< 2 Routers: add mains-powered device; > 32: split partition
Spójność identyfikatora partycji	Taki sam na wszystkich węzłach	Różne identyfikatory: podział partycji – sprawdź lukę w zasięgu RF
Interwał odpytywania urządzenia podrzędnego (SED)	250 ms – 10 s (zależnie od aplikacji)	< 100 ms: excessive battery drain; > 30 s: unacceptable latency
Ping RTT w sieci mesh	< 100 ms	> 200 ms: excessive hop count or congestion — review topology

Powiązane przewodniki

Matter & Thread

Przegląd protokołu Matter 1.3: Architektura i uruchamianie

Matter & Thread

Matter Bridge to KNX Integration

Solutions

Technologies

Knowledge

Company