Sieć mesh nie jest radiem o automatycznie większym zasięgu. Jest mechanizmem przekazywania ramek lub pakietów przez węzły pośrednie, gdy bezpośrednia ścieżka nie istnieje albo jest gorsza. Każdy relay zużywa energię, czas antenowy i przepustowość; przy ruchomej topologii trasa może być już nieaktualna, zanim protokół ją rozpowszechni. Mesh ma sens wtedy, gdy jego koszt jest mniejszy niż korzyść z dodatkowych ścieżek, zasięgu lub odporności.

W UAV trzeba rozdzielić topologię radiową, protokół sąsiedztwa i routingu, transport danych oraz logikę lotu. Flight controller nie może zakładać, że istnienie wpisu w tablicy tras oznacza spełnienie deadline'u komendy. Sieć powinna raportować jakość i wiek informacji, a każdy statek zachowywać lokalną autonomię oraz własny failsafe.

Spis treści#

Co oznacza mesh#

W praktyce termin bywa używany dla różnych rzeczy:

określenie rzeczywisty mechanizm
repeater powtarza ruch między dwoma segmentami, czasem bez routingu dynamicznego
bridge mesh L2 przekazuje ramki Ethernet/MAC przez wiele węzłów
routed mesh L3 każdy węzeł routuje prefiksy IP według protokołu MANET
relay aplikacyjny program odbiera wiadomość i publikuje ją dalej
multi-path kilka tras istnieje jednocześnie; nie zawsze są używane równolegle
swarm network pojęcie systemowe; może działać bez mesh lub na kilku różnych łączach

„Self-healing” oznacza co najwyżej, że protokół potrafi wykryć zmianę i obliczyć inną trasę. Nie określa czasu naprawy, utraty pakietów podczas konwergencji ani tego, czy nowa ścieżka ma wystarczający budżet radiowy.

Projekt zaczyna się od grafu łączności. Wierzchołki są radiami/węzłami, krawędzie — kierunkowymi łączami o zmiennym koszcie. Krawędź A→B nie implikuje równie dobrej B→A. Mesh z asymetrycznymi łączami wymaga szczególnej ostrożności, bo wiele protokołów potrzebuje dwukierunkowego sąsiedztwa.

Topologie#

Łańcuch#

GCS ─ A ─ B ─ C

Łańcuch rozszerza zasięg, ale utrata A odcina wszystkie dalsze węzły. Ruch C przechodzi przez B i A, więc węzły bliżej GCS są bardziej obciążone.

Gwiazda z możliwością relay#

      A
      │
B ── GCS ── C
      │
      D

W normalnym stanie każdy UAV łączy się bezpośrednio; relay jest trasą zapasową. To ogranicza narzut, jeśli bezpośrednie linki są dostępne.

Pełny lub częściowy mesh#

W pełnym grafie każdy węzeł słyszy każdy. Routing wieloskokowy nie daje wtedy zysku zasięgu, ale może wybrać lepszą drogę wokół lokalnego zasłonięcia. Wraz ze wzrostem liczby węzłów rośnie contention i ruch kontrolny.

Węzły dedykowane#

Relay na maszcie, pojeździe lub statku o długim czasie lotu oddziela rolę sieciową od payloadu. Pozwala użyć anten kierunkowych albo wielu radii, lecz tworzy węzeł o wysokiej krytyczności.

Warstwa 2 a warstwa 3#

Mesh warstwy 2#

Wygląda dla systemów wyższych jak wspólny segment Ethernet. Ułatwia uruchamianie istniejących aplikacji i przenoszenie dowolnego protokołu, lecz domena broadcastowa może rosnąć, a awaria lub pętla powodować szerokie skutki. Debugowanie trasy jest mniej oczywiste dla aplikacji IP.

Mesh warstwy 3#

Węzły mają interfejsy/prefiksy i wymieniają informacje routingu. Granice broadcastu są wyraźniejsze, można stosować polityki oraz wiele technologii łącza. Aplikacje muszą jednak poprawnie obsługiwać zmianę ścieżki i adresacji.

Relay aplikacyjny#

Przekaźnik rozumie wiadomość, może usuwać duplikaty, stosować TTL i priorytet. Jest użyteczny dla małej telemetrii, ale nie powinien odtwarzać niepełnego stosu sieciowego bez potrzeby. Każda funkcja relay zwiększa złożoność, stan i powierzchnię błędów.

Wybór nie jest wyłącznie wydajnościowy. Jeśli urządzenia innych producentów mają działać jak w zwykłym LAN, L2 upraszcza integrację. Jeśli wymagane są jawne domeny bezpieczeństwa, kilka gatewayów i kontrola tras, L3 zwykle daje lepszą obserwowalność.

802.11s i HWMP#

IEEE 802.11s definiuje mesh na poziomie MAC dla WLAN. Węzły mesh tworzą Mesh Basic Service Set i przekazują ramki między stacjami. Linux mac80211 udostępnia tryb mesh point, a dokumentacja projektu opisuje implementację i konfigurację 802.11s.

Domyślnym protokołem wyboru ścieżek jest Hybrid Wireless Mesh Protocol. Nazwa „hybrid” wynika z połączenia zachowania reaktywnego i opcjonalnej struktury drzewiastej wokół root mesh. W reaktywnym wariancie źródło inicjuje discovery, gdy nie ma trasy. Root może okresowo rozpowszechniać informacje, tworząc ścieżki proaktywne.

W 802.11s trzeba osobno skonfigurować:

  • identyfikator mesh i kanał;
  • bezpieczeństwo peeringu;
  • częstotliwość odświeżania tras;
  • metric i maksymalny czas życia wpisów;
  • forwarding oraz integrację z bridge/IP;
  • moc, szerokość kanału i regulatory domain.

Samo zestawienie peeringu nie dowodzi, że węzeł jest użytecznym relay. Trasa może wybierać link o wysokim PHY rate, który ma niestabilny goodput pod obciążeniem. Potrzebna jest walidacja metryki dla mobilności UAV.

BATMAN-adv#

BATMAN-advanced działa jako moduł jądra Linuksa w warstwie 2. Tworzy wirtualny interfejs bat0, do którego dołącza się interfejsy typu Ethernet. Dla aplikacji sieć wygląda jak rozproszony przełącznik. To upraszcza IPv4/IPv6 i protokoły wyższe, które nie muszą znać zmiany trasy.

Zaleta jest jednocześnie ryzykiem: broadcast, niezamierzone usługi i błędna konfiguracja mogą przechodzić przez całą domenę. Węzeł UAV powinien filtrować ruch, ograniczać niepotrzebne discovery i nie mostkować bez kontroli interfejsów serwisowych.

Dokumentacja kernela wskazuje, że skrócenie orig_interval przyspiesza reakcję w mobilnym scenariuszu kosztem większego narzutu. To typowy kompromis mesh: świeższa topologia wymaga częstszych transmisji kontrolnych, które same obciążają kanał.

BATMAN-adv może działać nad Wi‑Fi, Ethernetem lub tunelem. Nie naprawia właściwości warstwy fizycznej. Jeśli wszystkie węzły używają jednego kanału half-duplex, relay nadal musi odebrać i ponownie nadać tę samą ramkę.

OLSRv2, Babel i AODV#

OLSRv2#

RFC 7181 opisuje proaktywny Optimized Link State Routing Protocol version 2 dla MANET. Węzły regularnie wymieniają topologię i utrzymują trasy, zanim pojawią się dane. Multipoint relays ograniczają liczbę retransmisji potrzebnych do floodingu informacji oraz redukują ogłaszaną topologię.

Zaletą jest gotowa trasa przy pierwszym pakiecie. Kosztem jest stały ruch kontrolny i stan zależny od liczby węzłów. Interwały HELLO/TC muszą być krótsze przy szybkim ruchu, co zwiększa airtime.

Babel#

RFC 8966 definiuje unikający pętli protokół distance-vector odporny zarówno w sieciach przewodowych, jak i bezprzewodowych mesh. Babel oblicza koszt sąsiedztwa na podstawie komunikatów Hello/IHU i używa warunku wykonalności oraz numerów sekwencji do ograniczenia pętli przejściowych. Może przesyłać informacje o prefiksach IPv4/IPv6, a sterowanie działa przez UDP.

Babel jest interesujący w sieci hybrydowej, w której UAV ma Wi‑Fi, Ethernet do payloadu i łącze do gatewaya. Metryka musi jednak reprezentować wymagania UAV: najmniejsza strata pakietów nie zawsze oznacza najmniejsze opóźnienie lub największy wolny airtime.

AODV#

RFC 3561 opisuje eksperymentalny Ad hoc On-Demand Distance Vector. Trasy są odkrywane na żądanie przez RREQ/RREP, a numery sekwencji pomagają ocenić świeżość i uniknąć pętli. Brak okresowego utrzymywania wszystkich tras oszczędza część kontroli, ale pierwsza wiadomość do nowego celu czeka na discovery.

AODV jest ważnym punktem odniesienia historycznego; nie należy utożsamiać opisu RFC z rekomendacją wdrożenia konkretnej implementacji w nowym produkcie. Trzeba ocenić stan projektu, zabezpieczenia i testy interoperacyjności.

Metryki tras#

Najprostsza metryka to liczba skoków. Preferuje trasę A→D nad A→B→D, nawet jeśli link bezpośredni traci połowę pakietów. Dla radia potrzebna jest miara jakości.

ETX#

Expected Transmission Count w prostym modelu:

ETX = 1 / (d_f × d_r)

d_f i d_r są prawdopodobieństwami poprawnego dostarczenia w obu kierunkach. ETX 1 oznacza idealną wymianę; ETX 2 — średnio dwie próby. Metryka ujawnia asymetrię, ale nie uwzględnia bezpośrednio bitrate ani rozmiaru pakietu.

ETT i airtime#

Expected Transmission Time rozszerza koszt o szybkość łącza. Metric airtime próbuje oszacować czas medium zużywany na skuteczne przesłanie ramki, uwzględniając bitrate i prawdopodobieństwo błędu. Jest bliżej rzeczywistej pojemności wspólnego kanału.

Opóźnienie i deadline#

Dla komend ważny jest percentile latency, nie średni throughput. Trasa o większej pojemności może mieć kolejkę wideo i gorszy czas dla małego pakietu. Metryka routingu rzadko zna klasy QoS; potrzebne są osobne kolejki i polityki.

Stabilność#

Wybieranie minimalnie lepszej trasy co sekundę powoduje route flapping. Można dodać histerezę, koszt zmiany i minimalny czas utrzymania. Zbyt duża bezwładność utrzymuje trasę po zerwaniu. Parametry trzeba dopasować do prędkości i geometrii floty.

Koszt wielu skoków#

Na jednym kanale half-duplex węzeł B odbiera pakiet A→B, a potem nadaje B→C. Sąsiednie transmisje nie mogą zawsze zachodzić równocześnie. Idealizowany łańcuch traci pojemność wraz z liczbą skoków, ale dokładny wynik zależy od carrier sense, interferencji, reuse i protokołu.

A --10 Mb/s--> B --10 Mb/s--> C

Nie oznacza to 10 Mb/s end-to-end. Ten sam kanał przenosi co najmniej dwie transmisje danych, potwierdzenia i contention. Przy trzech skokach problem rośnie, a węzły ukryte powodują kolizje.

Każdy relay wnosi:

  • dodatkowy airtime;
  • kolejkę i jitter;
  • ryzyko utraty/retransmisji;
  • koszt CPU i energii;
  • zależność od poprawnego działania węzła;
  • większą powierzchnię bezpieczeństwa.

Mesh jest najbardziej efektywny, gdy relay omija bardzo złą bezpośrednią ścieżkę albo używa osobnego backhaulu. Dodawanie skoków między węzłami, które i tak się dobrze słyszą, może pogorszyć system.

Mobilność i konwergencja#

Topologia UAV zmienia się przez translację, obrót, zasłonięcie kadłubem i teren. Protokół przechodzi przez cykl:

zmiana fizyczna → pomiar jakości → uznanie sąsiada/trasy za złą
              → rozpowszechnienie → obliczenie → instalacja nowej trasy

Czas konwergencji jest sumą tych etapów. Krótki timeout wykrywa awarię szybko, ale może usuwać sąsiada po chwilowym zaniku. Długi timeout stabilizuje tablicę, lecz blackholuje pakiety po realnym zerwaniu.

Przy prędkości względnej 30 m/s obszar dobrej łączności o szerokości 60 m istnieje tylko około 2 s. Jeśli protokół potrzebuje kilku sekund na wykrycie i ogłoszenie, relay jest praktycznie nieużyteczny mimo poprawnego zasięgu chwilowego.

W testach trzeba mierzyć:

  • czas utworzenia pierwszej trasy;
  • czas wykrycia zerwania;
  • liczbę utraconych pakietów podczas zmiany;
  • flapping i pętle;
  • czas powrotu do trasy lepszej;
  • stabilność przy głębokich, krótkich zanikach anteny.

Projekt kanałów i radii#

Jedno radio, jeden kanał#

Najlżejsza konfiguracja, ale backhaul i dostęp lokalny konkurują o to samo medium. Węzeł nie może jednocześnie odbierać i nadawać na typowym half-duplex radio.

Dwa radia, różne kanały#

Jedno radio może obsługiwać połączenie „wstecz”, drugie „wprzód”. Zwiększa to pojemność i pozwala channel reuse, lecz dodaje masę, pobór mocy, anteny i problem współlokacji. Bliskie nadajniki mogą się odczulać mimo różnych kanałów.

Różne pasma#

Sub-GHz dla kontroli/telemetrii i 2,4/5 GHz dla danych daje separację funkcjonalną. Mesh wideo może się zerwać bez utraty niezależnego RC. Trzeba jednak policzyć każdy link budget i zgodność regulacyjną.

Anteny kierunkowe#

Na GCS lub dedykowanym relay zysk kierunkowy jest korzystny. Na ruchomym UAV wymaga śledzenia albo szerokiej wiązki. Utrata orientacji może gwałtownie zerwać kilka tras naraz.

Gatewaye i połączenie z GCS#

Mesh zwykle potrzebuje co najmniej jednego gatewaya do GCS, Internetu/LTE lub sieci przewodowej. Wiele gatewayów zwiększa odporność, ale rodzi pytania:

  • który ogłasza trasę domyślną;
  • jak wybierana jest trasa przy różnych kosztach i opóźnieniach;
  • czy po zmianie gatewaya sesje zachowują adres źródłowy;
  • jak uniknąć pętli między mesh, Ethernetem i VPN;
  • czy ruch wraca tą samą drogą;
  • jak działa DNS, DHCP i synchronizacja czasu podczas partycji.

NAT utrudnia połączenia przy zmianie wyjścia. Routing prefiksów i tunel z jawnie zaprojektowaną mobilnością bywa czytelniejszy. Nie należy mostkować całej sieci zakładowej do mesh UAV tylko dlatego, że L2 na to pozwala.

Gateway jest naturalnym miejscem agregacji logów i polityki, ale nie może być jedynym źródłem decyzji bezpieczeństwa lotu. Każdy UAV musi przeżyć utratę całej infrastruktury.

Broadcast, multicast i telemetria#

Broadcast wydaje się idealny dla stanu „do wszystkich”, lecz w Wi‑Fi często jest wysyłany bez potwierdzeń i przy konserwatywnym bitrate. Każdy węzeł mesh może go retransmitować, co prowadzi do broadcast storm.

Mechanizmy ograniczające:

  • TTL/hop limit;
  • numer sekwencji i pamięć duplikatów;
  • probabilistyczne lub wybrane przekaźniki;
  • agregacja wielu małych rekordów;
  • ograniczenie częstotliwości publikacji;
  • multicast routing zamiast floodingu całej domeny;
  • delta update z okresowym pełnym snapshotem.

Telemetria MAVLink nie powinna być ślepo forwardowana w każdym kierunku. System/component ID, źródło interfejsu i reguły subskrypcji muszą być jawne. Pętla bridge może zwielokrotnić wiadomości i zalać FC.

Każda wiadomość relay powinna mieć identyfikator źródła, sequence, czas oraz limit życia. Po zmianie trasy spóźniony duplikat nie może wykonać starej komendy.

Wideo przez mesh#

Wideo jest obciążeniem trudnym: stałym, wysokim i wrażliwym na opóźnienie. Strumień 5 Mbit/s przez trzy skoki na jednym kanale może zużyć wielokrotnie więcej airtime niż 5 Mbit/s na pojedynczym linku.

Zamiast wysyłać każdy strumień do każdego węzła:

  • routuj unicast tylko do aktywnego odbiorcy;
  • używaj subskrypcji i ogranicz liczbę podglądów;
  • transkoduj tylko w dedykowanym węźle o znanym budżecie energii;
  • przełączaj rozdzielczość/FPS według kosztu end-to-end;
  • zapewnij osobną kolejkę dla routing control i telemetrii;
  • rozważ zapis lokalny pełnej jakości i niski bitrate podglądu.

Multicast radiowy nie daje automatycznie niezawodności dla odbiorców o różnej jakości. Modulation/rate musi odpowiadać najsłabszemu odbiorcy albo system akceptuje różne straty. Feedback od wielu odbiorców może tworzyć implozję.

QoS i kontrola przeciążenia#

Mesh przenosi obciążenie na węzły pośrednie. Lokalny bitrate źródła może wyglądać poprawnie, podczas gdy relay ma dwa razy większy ruch i kolejkę.

Minimalne klasy:

  1. kontrola routingu i bezpieczeństwo sieci;
  2. komendy o krótkim deadline;
  3. stan/failsafe;
  4. telemetria cykliczna;
  5. wideo;
  6. logi i aktualizacje.

Priorytet nie zwiększa pojemności. Gdy źródła sumarycznie przekraczają goodput wąskiego gardła, trzeba ograniczyć bitrate, admission control lub liczbę strumieni. Każdy węzeł powinien znać zajętość kolejki i odrzucać według deadline, a nie zawsze FIFO.

Congestion sygnalizowane jako packet loss może zostać błędnie uznane za słaby RF, co skłoni routing do zmiany trasy i przeniesienia przeciążenia. Diagnostyka musi rozdzielać retry MAC, drop kolejki i brak route.

Synchronizacja i identyfikacja#

Adres IP, MAC, identyfikator routingu, system ID autopilota i numer seryjny to różne przestrzenie. Ich mapowanie powinno być zapisane w rejestrze floty. Losowy konflikt po sklonowaniu obrazu systemu może powodować niestabilne trasy albo skierować telemetrię do złego pojazdu.

Mesh potrzebuje czasu do:

  • timestampów i wygaszania danych;
  • korelacji logów z wielu węzłów;
  • certyfikatów/rotacji kluczy;
  • pomiarów one-way latency;
  • planowania kanałów, jeśli system jest synchronizowany.

GNSS może dostarczać czas, ale sieć musi działać także bez niego. Zegar monotoniczny obsługuje timeouty, a synchronizacja sieciowa mapuje logi. Cofnięcie zegara ściennego nie może przedłużyć ważności komendy.

Bezpieczeństwo routingu#

Szyfrowanie linku nie wystarcza, jeśli dowolny uwierzytelniony węzeł może ogłosić najlepszą trasę do wszystkiego. Zagrożenia obejmują:

  • fałszywe ogłoszenie niskiego kosztu/blackhole;
  • replay starej topologii;
  • Sybil — wiele tożsamości jednego urządzenia;
  • zalewanie route requests lub broadcastów;
  • przekierowanie przez nieautoryzowany gateway;
  • podsłuch informacji kontrolnej ujawniającej strukturę sieci.

RFC 8966 zaleca ochronę ruchu Babel mechanizmem aplikacyjnym; wskazuje Babel-MAC i Babel over DTLS jako rozwiązania o różnych właściwościach. Uwierzytelnienie pakietu routingu nie dowodzi, że metryka zgłoszona przez legalny, ale uszkodzony węzeł jest prawdziwa.

Projekt kluczy powinien umożliwiać:

  • unieważnienie jednego UAV bez wymiany całej floty;
  • kontrolowany onboarding i zmianę właściciela;
  • rotację w obecności partycji;
  • rozdzielenie kluczy routingu, zarządzania i payloadu;
  • ochronę pamięci kluczy i secure boot;
  • audit zmian polityki.

Identyfikatory i routing control mogą ujawniać obecność oraz relacje węzłów nawet przy szyfrowanym payloadzie. Jest to ograniczenie architektoniczne, nie błąd jednego algorytmu.

Partycje i ponowne łączenie#

Sieć UAV może podzielić się na dwie grupy, z których każda działa lokalnie. Należy zaprojektować:

  • które usługi kontynuują bez gatewaya;
  • jak przechowywane są wiadomości store-and-forward;
  • jaki jest TTL danych;
  • jak rozwiązywane są sprzeczne aktualizacje po połączeniu;
  • czy polecenie z jednej partycji jest nadal ważne;
  • jak raportować operatorowi niepełny obraz floty.

Ponowne połączenie może wywołać burst: routing updates, synchronizację czasu, logi i oczekujące dane. Bez limitów ruch kontrolny konkuruje z aktualnym stanem. Kolejki powinny preferować świeże dane, a archiwum przesyłać stopniowo.

System dowodzenia nie powinien interpretować braku telemetrii jako potwierdzenia wykonania. Po scaleniu stan jest rekoncyliowany na podstawie jawnej wersji, czasu i źródła.

Integracja z autopilotem#

Najbezpieczniejszy podział:

mesh router / companion computer
        │ wersjonowany, limitowany interfejs
        ▼
flight controller ─ lokalna stabilizacja i failsafe

Router mesh nie powinien bezpośrednio sterować aktuatorami. Dostarcza wiadomości z identyfikatorem, autoryzacją, sequence i deadline. FC weryfikuje stan systemu i odrzuca komendę przeterminowaną, powtórzoną lub niedozwoloną.

Zmiana next hop nie może resetować sesji sterującej w sposób, który ponownie wykonuje polecenie. Keepalive sieciowy nie jest heartbeat funkcjonalnym autopilota. Heartbeat musi potwierdzać właściwe źródło i świeżość na końcu aplikacji.

Companion powinien móc się zresetować bez destabilizacji lotu. Watchdog, limit CPU/RAM i osobne zasilanie/ochrona zapobiegają propagacji awarii dużego stosu Linux do FC.

Obserwowalność#

Każdy węzeł powinien rejestrować:

  • sąsiadów i jakość obu kierunków;
  • aktualne trasy, metric, next hop i czas instalacji;
  • powody zmiany i liczbę flappingów;
  • pakiety kontrolne/s, ich airtime i błędy uwierzytelnienia;
  • per-interface PHY rate, retry, noise/RSSI i channel utilization;
  • kolejki oraz dropy według klasy;
  • opóźnienie/stratę end-to-end do kluczowych węzłów;
  • obciążenie CPU, pamięci, temperaturę i resety;
  • stan gatewaya i partycji.

Centralny log GCS nie wystarcza, bo pakiet diagnostyczny może nie dotrzeć dokładnie podczas awarii. Każdy UAV przechowuje lokalny ring buffer, który można pobrać po locie. Zsynchronizowane znaczniki czasu pozwalają zrekonstruować, czy najpierw pogorszył się RF, zmieniła trasa, czy przepełniła kolejka.

Wizualizacja grafu powinna pokazywać krawędzie kierunkowe i metric w czasie. Jedna statyczna mapa „połączony/niepołączony” ukrywa asymetrię i oscylacje.

Plan testów#

Emulacja przewodowa#

Uruchom routery w przestrzeniach sieciowych/kontenerach i emuluj opóźnienie, stratę, bitrate, reorder oraz awarie linków. Sprawdź pętle, konwergencję, prefiksy i polityki bez zmienności RF.

Test RF na stole#

Połącz węzły przez kontrolowane tłumiki lub ekranowane środowisko. Wymuś topologie łańcucha, pierścienia i dwa gatewaye. Mierz control overhead i goodput end-to-end dla 1–N skoków.

Mobilność#

Zmiana tłumienia powinna odtwarzać zbliżanie/oddalanie i krótkie zaniki. Potem wykonaj kontrolowane próby terenowe:

  1. statyczny łańcuch;
  2. ruch jednego węzła relay;
  3. przecięcie dwóch możliwych tras;
  4. utrata gatewaya;
  5. partycja i połączenie;
  6. wszystkie węzły w ruchu z realnym payloadem.

Obciążenie#

Testuj małą telemetrię, jeden i wiele strumieni wideo, log transfer i ruch broadcast. Źródła powinny generować realistyczny burst, nie stały strumień syntetyczny.

Awarie i bezpieczeństwo#

Wymuś reset relay, pełną kolejkę, błędny zegar, duplikat ID, fałszywy/stary update i węzeł bez poprawnego klucza. Sprawdź, czy awaria routingu nie przekracza granicy do kontrolera lotu.

Kryteria odbioru#

obszar przykładowe kryterium
konwergencja 99. percentyl czasu naprawy po utracie węzła poniżej limitu
utrata w zmianie maksymalna seria utraconych pakietów dla klasy krytycznej
overhead ruch kontrolny i broadcast zajmują mniej niż przydzielony airtime
skalowanie wymagania spełnione dla maksymalnej liczby węzłów i strumieni
wieloskok goodput i latency zmierzone dla każdej dopuszczalnej liczby hopów
stabilność brak flappingu powyżej limitu przy granicznej jakości linków
partycja lokalne funkcje działają, a stare komendy wygasają
bezpieczeństwo nieautoryzowany routing update jest odrzucany i logowany
gateway zmiana wyjścia nie tworzy pętli ani nie zaciemnia stanu operatora
FC reset/zalanie mesha nie narusza deadline pętli lotu i failsafe

Mesh kwalifikuje się jako system, nie jako suma poprawnie zestawionych peerów. Test musi obejmować topologię, obciążenie, ruch i awarie występujące jednocześnie.

Powiązane tematy#

Przypisy#

  1. IEEE, IEEE 802.11-2024: Wireless LAN MAC and PHY Specifications, https://standards.ieee.org/ieee/802.11/10548/ (dostęp: 15 sierpnia 2026).
  2. Linux Wireless, IEEE 802.11s, https://wireless.docs.kernel.org/en/latest/en/developers/documentation/ieee80211/802.11s.html (dostęp: 15 sierpnia 2026).
  3. IETF, RFC 7181: The Optimized Link State Routing Protocol Version 2, https://www.rfc-editor.org/info/rfc7181/ (dostęp: 15 sierpnia 2026).
  4. IETF, RFC 8966: The Babel Routing Protocol, https://www.rfc-editor.org/info/rfc8966/ (dostęp: 15 sierpnia 2026).
  5. IETF, RFC 3561: Ad hoc On-Demand Distance Vector Routing, https://www.rfc-editor.org/info/rfc3561/ (dostęp: 15 sierpnia 2026; dokument ma status Experimental).
  6. Linux kernel documentation, batman-adv, https://docs.kernel.org/networking/batman-adv.html (dostęp: 15 sierpnia 2026).
  7. IETF, RFC 8085: UDP Usage Guidelines, https://www.rfc-editor.org/info/rfc8085/ (dostęp: 15 sierpnia 2026).

Powiązane tematy

Wi‑Fi jako łącze UAVWi‑Fi jako współdzielone łącze IP UAV: tryby AP/station/mesh, budżet radiowy, airtime, MCS i retransmisje, QoS, transport telemetrii oraz wideo, zabezpieczenia, anteny, obserwowalność, failsafe i testy end-to-end.Budżet łącza radiowego UAVPraktyczna metodyka budżetu łącza UAV: jednostki dB/dBm/dBi, EIRP, strata wolnej przestrzeni, horyzont i Fresnel, czułość z bilansu szumu, interferencja, polaryzacja, anteny w kadłubie, margines statystyczny, uplink/downlink oraz plan pomiarów.Transmisja wideo UAVKompletny tor wideo UAV: kamera i rolling shutter, kodowanie H.264/H.265, GOP i obrazy referencyjne, packetization RTP, utrata pakietów, FEC kontra retransmisja, adaptacja bitrate, zabezpieczenia, pomiar opóźnienia glass-to-glass i testy w locie.LoRa w UAVLoRa jako odporna energetycznie telemetria o małej przepustowości: modulacja CSS, SF/BW/CR, time-on-air, sensitivity i link budget, LoRaWAN Classes/ADR, regionalne ograniczenia, payload design, bezpieczeństwo, anteny oraz failsafe.Wi‑Fi, LTE i 5G jako łącze UAVAktualizacja koncepcji sterowania przez GSM: stabilizacja zawsze lokalna, a sieć komórkowa przenosi misję, telemetrię i opcjonalnie wideo.MAVLink — architektura protokołuDokumentacyjny opis MAVLink 2: format on-wire, system/component ID, CRC_EXTRA, podpisywanie oraz semantyka usług parametrów i misji.Failsafe jako maszyna stanówFailsafe jako deterministyczny system decyzji: źródła faultów, persistence i hysteresis, priorytety reakcji, konflikty RC/GNSS/baterii, latch, recovery oraz macierz testowa.Telemetria satelitarna UAVTelemetria satelitarna UAV od geometrii LEO/GEO, Dopplera i opóźnienia przez antenę w ruchomym kadłubie, usługi krótkich wiadomości i IP, kolejki store-and-forward, minimalny payload, koszty, uwierzytelnianie, failsafe oraz kwalifikację.

Źródła z centralnego rejestru

  1. IEEE 802.11-2024 — Wireless LAN MAC and PHY Specifications [standard techniczny]
  2. Linux Wireless: IEEE 802.11s mesh networking [dokumentacja projektu]
  3. IETF RFC 7181: Optimized Link State Routing Protocol Version 2 [standard internetowy]
  4. IETF RFC 8966: The Babel Routing Protocol [standard internetowy]
  5. IETF RFC 3561: Ad hoc On-Demand Distance Vector Routing [eksperymentalny RFC]
  6. Linux kernel documentation: batman-adv layer-2 mesh [dokumentacja projektu]
  7. IETF RFC 8085: UDP Usage Guidelines [Best Current Practice]
  8. Sumit Sharma, „Drone Development from Concept to Flight” [książka]
  9. Ty Audronis, „Drony. Wprowadzenie” [książka]