Tak, jak do złożenia działającego sprzętu, nie potrzeba większej filozofii, tak budowanie sprawnie działającej sieci, nie jest już procesem banalnym i wymaga niestety minimum fundamentalnej wiedzy związanej z jej działaniem. Istotne jest rozumienie procesów, a nie wiara w "święte słowo lokalnych misjonarzy", którzy bezrefleksyjnie opierając się na złudnych, częściowych, podobieństwach do sieci Internet, tworzą w głowach nowicjuszy, fikcyjne modele łączności "mesh od morza po góry".
Temat globalizacji sieci mesh powoduje powstawanie "lokalnych klanów", powstają kościoły wyznawców/misjonarzy różnych sposobów łączenia gór z morzem i odwrotnie, dlatego warto zwrócić uwagę na możliwości techniczne, dlaczego mesh w kontekście wielkoobszarowym nie ma szansy na poprawne działanie. Skupimy się głównie na technicznych aspektach łączności, nie zagłębiając się w naturę aplikacji MeshCore/Meshtastic. Lokalne grupy użytkowników szukają różnych sposobów na zwiększenie przepustowości sieci, jednak przy braku rozumienia fundamentów działania, podejmowane działania, co najwyżej pozwalają tylko na przesunięcie w czasie, momentu degradacji i zapaści sieci.
- pl_s_.png (126.06 KiB) Przejrzano 2231 razy
Należy rozważyć w tym kontekście abstrakcyjny warstwowy Model OSI* (link dla dociekliwych, na końcu artykułu)
W przypadku sieci Internet, mamy do dyspozycji tzw. pełny stos warstw:
- vs1_s.jpg (47.76 KiB) Przejrzano 2231 razy
- 3. dokąd wysłać, czyli globalne adresowanie i routing między sieciami
- 4. jak nie zalać sieci i nie pogubić danych?
- 5–7. co to za usługa?
Internet działa globalnie, bo warstwa 3 (IP) umożliwia hierarchiczny routing między milionami podsieci, a warstwy 4–7 zapewniają niezawodność, skalowalność i usługi.
W przypadku sieci Mesh, występują w pełni tylko warstwy 1 i 2, natomiast 3 jest nieporównywalnie prymitywna w stosunku do modelu Internetowego
- vs2_s.jpg (33.39 KiB) Przejrzano 2231 razy
- 4. (brak warstwy usługowej) brak portów, brak kontroli przeciążenia
- 3. (brak warstwy IP) brak inteligentnego wyboru trasy
- 5–7. brak usług jak w Internecie
Formalnie można powiedzieć, że „warstwa 3 istnieje”, ale jest tak prymitywna, że nie spełnia funkcji Internetowego IP.
Dlaczego mesh LoRa to tylko sieć lokalna, porównajmy parametry?
1. Prędkość transmisji (fizyka)
Światłowód Tb/s
Ethernet przewodowy setki Gb/s
Wi-Fi setki Mb/s
LTE/5G dziesiątki–setki Mb/s
LoRa (mesh) 0.3–50 kb/s
2. Brak skalowalnego routingu (warstwa 3)
Internet:
BGP między operatorami
OSPF/IS-IS wewnątrz sieci
Hierarchia adresów IP
Agregacja tras
Mesh LoRa:
Brak hierarchii
Każdy węzeł potencjalnie musi znać każdego
Często flooding zamiast routingu
To działa dla dziesiątek / setek węzłów, nie dla tysięcy itd
3. Brak warstwy transportowej (TCP)
Internet:
Kontrola przeciążenia
Kontrola przepływu
Retransmisje
Kolejkowanie
Mesh:
Proste ACK albo brak
Brak mechanizmów zapobiegania przeciążeniu
Przy większym ruchu sieć się zatyka.
4. Brak warstw 5–7 (usługi)
Dlaczego mesh nie potrafi obsłużyć zbyt dużych obszarów?
To nie kwestia rozwoju software, tylko twarde bariery leżące u podstaw zaprojektowanej technologii.
- Bariera 1 – Prawo radiowe
LoRa działa w pasmach ISM z limitem czasu nadawania (duty cycle).
Nie wolno non-stop nadawać.
- Bariera 2 – Przepustowość
Globalna sieć wymaga transmisji równoległych milionów strumieni danych.
Mesh LoRa: jedna transmisja blokuje w okolicy eter dla wszystkich.
- Bariera 3 – Routing
Internet: ruch idzie przez wybrane trasy
Mesh flooding: ruch idzie wszędzie.
Ruch trasowany jest minimalny, moża przyjąć, że pomijalny w stosunku do ruchu flood.
Problem zbieżności i flooding (najważniejsza bariera)
Zbieżność to, obrazowo i ogólnie, parametr określający, jak szybko sieć potrafi ustalić optymalną drogę od nadawcy do odbiorcy.
Mesh LoRa fundamentalnie używa mechanizmu „Nie wiem gdzie odbiorca → wyślę do wszystkich”
To powoduje Broadcast Storm (burza rozgłoszeniowa) - przeciążenie sieci
Przykład z życia?
Wyobraźmy sobie, że znajdujemy się na we w Gdańsku i chcemy wysłać prywatną wiadomość do użytkownika w Zgorzelcu. Nasz nod chce ustalić trasę do Zielonej Góry. Wysyła pakiet flood do najbliższego RPT, ten rozsyłą dalej, we wszystkich kierunkach, kolejne RPT robią to samo. Jeśli bazujemy na ograniczeniu domyślnym 64 hop, fala rozchodzi się po całej Polsce. Słyszy to Szczecin, Warszawa, Suwałki, Wrocław, Kraków, Lublin itd. Każde przyjmowanie danych blokuje RPT dla innych transmisji. Tymczasem nasz odbiorca znajduje się w Zielonej Górze. Nawet, jeśli znajdzie docelowego noda, to informacja o trasie musi wrócić do nadawcy. Jeśli wysyłasz pierwsza prywatną wiadomość nawet 1-2 hopy dalej, to uzyskamy szybko trasę bezpośrednia, ale sztorm mimo to rozchodzi się po całej Polsce. Nie trzeba większej wyobraźni, żeby uzmysłowić sobie, że taki ruch szybko sparaliżuje sieć i jest absurdalny. Ratunek w tej sytuacji? W Internecie TTL, a w Mesh limit ilości hopów. Zmiana presetu pomoże tylko na jakiś czas, zwiększając pojemność lokalną sieci i jej prędkość, zmniejszając jednak dystans direct.
Dlaczego w sieci mesh (np. Meshtastic/LoRa) robi się tłok i giną pakiety?
Brak warstwy 4 (transportowej) = brak „organizera ruchu”
Node nie ma „portów”, czyli: nie rozróżnia wielu niezależnych rozmów — to po prostu strumień radiowych komunikatów.
Jeden node, w obszarze direct, może „słuchać” tylko jednego nadawcy na raz
czyli node:
- nie ma wielu kanałów odbioru
- nie buforuje dużej ilości ruchu
- nie rozdziela transmisji
Jeśli dwie osoby nadają w tym samym czasie w okolicy direct, pakiety się nakładają → kolizja → dane przepadają.
Algorytm jest stratny: "jak nie weszło - przepadło"
Co się dzieje przy większym ruchu?
Załóżmy, że kilkadziesiąt węzłów chce coś wysłać
Efekt:
- Wiele nodeów nadaje jednocześnie
- Kolizje radiowe
- Pakiety giną
- Niektóre są retransmitowane
- Jeszcze większy tłok
- Sieć praktycznie przestaje działać
To nazywa się zatkanie sieci (congestion collapse)
Gdy zaczniemy powiększać sieć bez umiaru ("model od morza do gór"), prędzej czy poźniej pojawi się moment krytyczny, kiedy nastąpi degradacja sieci.
Zjawisko jest doskonale widoczne podczas okresów wzmożonej propagacji, kiedy pakiety z ogromnych obszarów potrafią docierać setki kilometrów.
Na lista pojawiają się tzw "pokemony" czyli węzły, które zostały rozgłoszone przez burzę rozgłoszeniową.
Występuje też zjawisko głuchego telefonu, czyli otrzymujemy wiadomości bez kontekstu z odległych miejsc, na które trudno odpowiedzieć.
Pokemony i głuchy telefon nie mają żadnej wartości, poza emocjonalną "butelki z wiadomością z końca świata". Niestety ceną tych dalekosiężnych emocji, jest zablokowanie naszego lokalnego ruchu, a więc przestają nam latać np wiadomości lokalne przez 1-2 hopy.
Jak sobie radzić z problemem wielkości sieci lokalnej?
Poza powyższymi fundamentalnymi ograniczeniami, jest jeszcze wiele czynników dodatkowych wpływających na wybór rozwiązań, ale wszystkie niestety opierają się na powyższej bazie, determinującej ograniczenia.
Oprogramowanie może jedynie zmniejszać dokuczliwość ograniczeń, ale nigdy ich nie wyeliminuje. Ustawienie właściwego presetu radia może zwiększyć pojemność i szybkość sieci na określonym obszarze, jednak nie spowoduje zwiększenia zasięgu, przy określonej gęstości węzłów. Jest jednak zawsze granica, której przekroczyć się nie da.
Rozsądnym mechanizmem wydaje się ustawienie parametru maksymalnej liczby hopów. Pozwala to ja ubijanie ruchu śmieciowego z odległych nodów, a jednocześnie pozwala na sprawną komunikacje na założonym lokalnym obszarze. Przy odpowiednich założeniach przykładowy "polski preset" może być ustawiony w całym kraju i osoby przemieszczające się, zawsze będą w zasięgu obszarowo ograniczonej sieci lokalnej, bez potrzeby zmiany presetów w większości obszaru kraju.
Zdaję sobie sprawę, że ze powyższe opracowanie może być trudne w zrozumieniu dla mniej technicznych osób, ale wplatałem w tekście wyjaśnienia "obrazowo i po ludzku", więc liczę, że te fragmenty pomogą zrozumieć obszar ograniczeń i ostudzi zapały niektórych budowniczych sieci, próbujących realizować absurdalne projekty.
*Model OSI >>> https://pl.wikipedia.org/wiki/Model_OSI