UrbanMesh — odporne miejskie sieci IoT
Sześć kierunków w niskoenergetycznych sieciach czujnikowych działających bez internetu i zasilania sieciowego.
Koch Laboratory — UrbanMesh: badania nad odpornymi miejskimi sieciami IoT
Obok badań nad komunikacją odporną na metadane, Koch Laboratory prowadzi program UrbanMesh — badania nad odporną, niskoenergetyczną infrastrukturą czujnikową dla miast: urządzeniami, które działają także wtedy, gdy nie ma internetu ani zasilania sieciowego. Wspólny wątek z resztą laboratorium: system ma być odporny na awarie i oszczędny w zaufaniu — pojedynczy tani węzeł łączy trzy technologie radiowe, a dane przetrwają utratę łącza. Kierunki opisane niżej rozwiązują konkretne, nierozwiązane problemy techniczne, dla których nie ma gotowego rozwiązania „z półki”. Kontekst wdrożeniowy: platforma NearStadt (lokalny handel).
Metodyka. Każdy kierunek prowadzimy jako proces: sformułowanie problemu → hipoteza → prototyp firmware → pomiar w terenie → ewaluacja → rewizja. Wersjonowany firmware (historia FIRMWARE_VERSION), protokoły pomiarowe i testy backendu utrzymują wynik przez kolejne iteracje.
1. Współistnienie trzech radiów na jednym węźle (LoRa + BLE + WiFi)
Pytanie badawcze. Czy można prowadzić jednocześnie ciągły nasłuch LoRa (868 MHz), rozgłaszanie BLE-iBeacon i okresowy uplink WiFi na jednym tanim układzie (ESP32-S3), skoro WiFi i BLE dzielą pasmo 2,4 GHz, a stos WiFi jest blokujący?
Dlaczego to trudne. Łączenie z WiFi, synchronizacja czasu i wysyłka HTTP zajmują sekundy — w tym czasie urządzenie staje się „głuche” na LoRa. Otwarte: nieblokujący schemat czasowy utrzymujący nasłuch mesh podczas fazy WiFi, bez resetów watchdoga.
Podejście. Nieblokujący polling radia zamiast delay(), kontrolowana sekwencja przełączania BLE↔WiFi, pomiar strat pakietów podczas okien uplinku. (Wzorce nieblokujące są dobrą praktyką inżynierską — publikujemy poziom ogólny; ewentualne nieoczywiste optymalizacje sekwencji traktujemy oddzielnie.)
Status: zaimplementowane; walidacja terenowa w toku.
2. Sieć mesh odporna na offline (store-and-forward)
Pytanie badawcze. Jak dostarczyć dane do zaplecza, gdy węzeł traci internet lub zasilanie — przez węzły sąsiednie, z gwarantowaną (na tyle, na ile to możliwe) dostarczalnością? Dlaczego to trudne. Dostarczalność zależy od nieznanej, zmiennej gęstości węzłów; trzeba tłumić kolizje, chronić bufor przed przepełnieniem (DoS) i przetrwać restart bez utraty ani duplikacji danych. Podejście (stan techniki). Zalewanie z limitem TTL, deduplikacja (okno 30 wiadomości), adaptacyjny backoff przekazywania (50–150 ms), persystencja bufora w pamięci nieulotnej (NVS) przez restart — techniki znane, publikowane. Konstrukcja trasowania uwzględniającego klasę zasilania węzła: wstrzymana (otwarta opcja patentowa — kierunek wskazany jako wrażliwy). Status: zaimplementowane; walidacja przy zmiennej gęstości węzłów w toku.
3. Priorytetowy alarm bezpieczeństwa w sieci „best-effort”
Pytanie badawcze. Czy w sieci z założenia zawodnej można dostarczyć alarm bezpieczeństwa (przycisk paniki) z niską, przewidywalną latencją i wyprzedzeniem ruchu zwykłego? Dlaczego to trudne. Mesh LoRa jest niedeterministyczny; alarm musi „przeskoczyć” ruch zwykły, nie zalewając sieci. Autentyczność źródła trzeba zapewnić bez PKI, a mechanizm zabezpieczyć przed nadużyciem/replayem. Kryterium sukcesu. Niska, przewidywalna latencja alarmu z wyprzedzeniem ruchu zwykłego, autentyczność źródła bez PKI, odporność na nadużycie i replay. Konstrukcja (preempcja, dystrybucja zaufania, tor awaryjny): wstrzymana (otwarta opcja patentowa). Status: zaimplementowane (firmware v2.1.0); pomiar latencji pod obciążeniem w toku.
4. Hybrydowa autentykacja na urządzeniach bez zegara (TOTP↔HOTP)
Pytanie badawcze. Jak generować kryptograficznie wiarygodne kody jednorazowe (TAN kasowy) na urządzeniu bez zegara czasu rzeczywistego i bez stałego łącza? Dlaczego to trudne. Bez czasu z sieci trzeba przełączyć się na kody licznikowe (HOTP); licznik dryfuje offline, więc serwer musi go resynchronizować oknem w przód — bez otwierania okna na atak powtórzeniowy. Podejście (stan techniki). HMAC-SHA1 na urządzeniu (RFC 4226/6238), płynne przełączanie czas↔licznik zależnie od synchronizacji, serwerowa resynchronizacja licznika oknem w przód — konstrukcje standardowe, publikowane. (Ewentualne nieoczywiste elementy provisioningu sekretu traktujemy oddzielnie.) Status: zaimplementowane i przetestowane.
5. Analityka obecności z ochroną prywatności (mimo randomizacji MAC)
Pytanie badawcze. Czy z obserwacji radiowych (sąsiedzi mesh, detekcje BLE, RSSI) da się wyprowadzić wiarygodną, zagregowaną miarę natężenia ruchu pieszego — bez danych osobowych i mimo randomizacji adresów MAC? Dlaczego to trudne. Randomizacja MAC (BLE/WiFi) psuje naiwne zliczanie unikalnych urządzeń; potrzebny jest odporny estymator bez stałej tożsamości, walidowany względem zliczania referencyjnego, w pełni zgodny z RODO. Kryterium sukcesu. Zagregowana miara natężenia ruchu bez danych osobowych, odporna na randomizację MAC i walidowana względem zliczania referencyjnego; jawna ocena RODO. Konstrukcja estymatora i anonimizacji: wstrzymana (otwarta opcja patentowa). Status: prace projektowe (dziś dostępne jest tylko zliczanie aktywnych sąsiadów; warstwa estymacji to projekt).
6. Autonomia energetyczna a dostępność sieci mesh
Pytanie badawcze. Jak zmaksymalizować czas pracy na baterii, jednocześnie utrzymując dostępność węzła jako przekaźnika mesh? Dlaczego to trudne. Więcej snu = mniejsza dostępność jako relay; optymalny punkt pracy jest nieznany i zależny od obciążenia. Dodatkowo szacowanie stanu baterii bez dedykowanego układu (tylko ADC) musi być odporne na obciążenie i temperaturę. Podejście (stan techniki). Adaptacyjny duty-cycling, skalowanie taktowania CPU (80 MHz), deep-sleep/smart-standby, model baterii z ADC, bezpieczne stany przy ładowaniu i wyłączaniu bez utraty bufora — techniki znane, publikowane. Konstrukcja sprzężenia stanu energii z decyzją o dostępności/trasowaniu (klasa zasilania jako parametr): wstrzymana (otwarta opcja patentowa — kierunek wskazany jako wrażliwy). Status: częściowo zaimplementowane; optymalizacja w toku.