DTN Overlay Module (FW+)

Zwiększ niezawodność i zasięg dostarczania prywatnych wiadomości poza ograniczenia routingu hop-by-hop

Store-Carry-Forward EXPERIMENTAL

Co to jest DTN?

DTN (Delay-Tolerant Networking) to moduł overlay, który przechwytuje lokalne wiadomości prywatne (DM), pakuje je w ramki DTN i buduje łańcuch opieki (custody_path). Węzły FW+ przekazują "custodię/pakiet dtn" najbliższym sensownym sąsiadom, aż do celu. Stock FW jest tylko warstwą transportu punkt-punkt.

Dzięki mechanizmowi store-carry-forward, wiadomości wędrują nawet przez kilka–kilkanaście minut i wiele skoków, zamiast "znikać", gdy klasyczny routing zawiedzie.

Mechanizm nie rozwiązuje problemów radiowych/sprzętowych, wymaga minimalnie działającej infrastruktury, potrafi odczekać aż eter się zwolni i dokona przerzucenia do innego węzła DTN minimalizując straty miedzy hopami.

Domyślnie Meshtastic działa (a także inne rozwiązania) na bazie "online", rzucony pakiet dąży do celu bez większych refleksji, a nie wiemy czy odległe radio je odbierze, nie znamy jego stanu, każy kolejny hop zmniejsza szansę dostaw, a moduł DTN pozwala na lepsze zarządzanie ruchem i przekazywaniem wiadomości.

Kluczowe korzyści
  • Większy zasięg oparty o TTL (czas)
  • Większa niezawodność dostaw wiadomości
  • Postępy w czasie rzeczywistym (opcja)
  • Odporność na asymetrię tras
  • Środowisko mieszane stock FW & FW+
  • Multi-Hop poprzez węzły DTN
  • Oczekuje faktycznych potwierdzeń dostaw na trasie od nadawcy do celu (nie tylko od odbiorcy, ale pośredników)

DTN vs Stock (bez DTN)

Aspekt Stock (bez DTN) DTN (FW+)
Routing Tylko klasyczny unicast routera, zwykle do 3 skoków, każdy kolejny skok zmniejsza szansę dostawy Przechwytuje DM u źródła i wysyła via custody (magazynuje + ponawia), dynamicznie dobiera sąsiadów
Store-Carry-Forward Brak — gdy ścieżka chwilowo "dziurawa" lub asymetryczna, DM potrafi przepaść Pełna obsługa — wiadomości są przechowywane i przekazywane dalej, gdy topologia pozwala
Potwierdzenia Brak niezawodnych potwierdzeń — aplikacja widzi głównie ACK/NAK, lub ciszę Niezawodne potwierdzenia (receipts) odwrotnym łańcuchem custody nawet gdy routing natywny nie ma powrotu
Telemetria postępów Brak telemetrycznych postępów Postępy (PROGRESSED/milestones), "TRANSMITTED" i finalne "DELIVERED/FAILED/EXPIRED" do UI
Kompatybilność — Zachowuje kompatybilność ze stock: w TTL tail możliwy fallback do natywnego DM, węzły stock nic nie muszą zmieniać

Co wyróżnia to rozwiązanie?

1 Custody Path + Reverse Receipts

Jawnie śledzi łańcuch nosicieli (custody_path) i wymusza powrót potwierdzeń tą trasą, co rozwiązuje klasyczną asymetrię tras routingu.

2 Milestones bez floodu

PROGRESSED są oszczędne, limitowane globalnie/per-źródło/topologicznie; nie zalewają sieci niepotrzebnym ruchem.

3 Koordynacja przez podsłuch

Gdy węzeł "słyszy", że ktoś niesie to samo orig_id, adaptacyjnie opóźnia swoje próby (suppress), aby unikać dublowania.

4 Progresywny relay

Preferuje sprawdzone trasy (direct/handoff), a progressive relay włącza się ostrożnie, tylko gdy trzeba.

Jak to działa?

Przepływ DATA (custody)

1. Źródło przechwytuje DM → kapsułuje jako FWPLUS_DTN DATA z TTL
2. Przekazuje custodię do sąsiadów FW+ zgodnie z topologią i limitami
3. Przy dostawie do celu FW+ rozpakowuje i wstrzykuje lokalnie oryginalny DM

Przepływ RECEIPT (potwierdzenia)

Statusy:

  • DELIVERED — finalne potwierdzenie dostarczenia
  • FAILED — finalne potwierdzenie błędu
  • EXPIRED — finalne potwierdzenie wygaśnięcia TTL
  • PROGRESSED — milestone (postęp pośredni)

Receipty wracają łańcuchem odwrotnym do źródła; TTL receiptów jest osobny i krótki (status-based) oraz "capowany" względem pozostałego TTL oryginału.

Milestones (PROGRESSED)

Węzły pośrednie emitują "przejęte i pchnięte dalej" z reason=via (low byte node ID), jeśli przejdą limity i filtr topologiczny. Źródło wysyła też: DTN_ACCEPTED (custody przyjęte) i TRANSMITTED (poszło w eter na 1. próbie).

Sterowanie ruchem i oszczędność eteru

Suppress po overheard

Widzę cudze DATA tego samego orig_id → opóźniam swoje próby (domyślnie ~35 s, z adaptacją mobilności), mocniejsze tłumienie blisko celu.

Rate limit milestones

Globalny + per-źródło, filtr topologiczny (np. max ring) — ogranicza zalewanie sieci niepotrzebnymi informacjami o postępach.

Per-destination spacing

Minimalny odstęp między próbami do tego samego celu — zapobiega nadmiernemu obciążeniu pojedynczych węzłów.

Max active

Globalny limit równoległych DTN DM — kontroluje całkowite obciążenie sieci przez jednoczesne wiadomości DTN.

Tombstony

Krótkie blokady orig_id (i skrótów receiptów), aby unikać re-capture czy powtórek po give-up. Historia blokad.

TTL i próby

DATA TTL
  • Ustawiane na starcie
  • Dekrement przez czas oczekiwania oraz między próbami
  • Po wygaśnięciu EXPIRED do źródła
RECEIPT TTL
  • Osobne, krótsze i status-based (np. PROGRESSED ~60 s domyślnie)
  • Dodatkowo capowane do (remaining DATA TTL + slack)
  • Nie "żyje" po śmierci oryginału
Backoff prób

Bazowo ~50 s (dynamicznie modyfikowane przez mobilność), zwykle 2–5 prób zależnie od warunków; receipt reverse-path degraduje szybko po 1 nieudanym hopie.

Zalety

  • Wyższa skuteczność i zasięg: dostawy przez 4–6-16 hopów (i więcej), bazuje na czasie TTL, nie hopach. Działa w trybie powolnym w przeciwieństwie do stosckowego push-and-pray, online (nadaj i licz na to, że kolejne nody po drodze nie są zajęte).
  • Lepsze UX: pośrednie postępy i spójne finalne statusy w Androidzie (ACK-owanie DTN)
  • Odporność na asymetrię: reverse custody receipts wrócą do źródła nawet bez natywnego next_hop
  • Oszczędny RF: suppression, spacing, limity, wybór kandydatów DTN, brak broadcastu dla receipts (lub pojedynczy rescue)
  • Omija deduplikacje - każdy przekazany pakiet do innego DTN ma nowe ID, omija deduplikację węzłów stockowych zwiększając skuteczność
  • Tryb mieszany - DTN może działać w trybie mieszanym, gdzie węzły stockowe są używane jako transport punkt-punkt, a węzły DTN są używane jako relay'e

Wady / Trade-offs

  • Więcej stanu: pendingi, custody_path, learning – wymagają RAM/flash i uważnego utrzymania
  • Złożoność: więcej heurystyk i konfiguracji; błędne strojenie może opóźniać dostawy
  • Dodatkowy airtime: w ruchu mieszanym receipt/milestone, koordynacja, narzut, to jednak dodatkowe ramki (minimalizowane limitami)
  • Potrzeba FW+ po drodze: pełne korzyści DTN uzyskasz, gdy łańcuch ma FW+DTN relay'e
  • Nadmiar węzłów DTN - w klastrze jest szkodliwy, nie daje korzyści a generuje ruch, wystarczy jeden węzeł DTN na dany obszar. Węzły DTN koordynują się i powinny być tworzone np. co 3 hopy od innego DTN
  • Wolniej - dostawy wiadości są wolne, korrydnacja wymaga czasu
  • Krótsza wiadomość - ramka DTN niesie dodatkowe atrybuty co ogranicza rozmiar wiadomości

Bezpieczeństwo i szyfrowanie

Warstwa siatki (PSK), kanał główny

DATA (ramka DTN) i custody-receipts lecą przez FWPLUS_DTN_APP (PSK kanału głównego); sąsiedzi "słyszą" ramki, lecz nie zdeszyfrują payload

PKI payload (nadawca-odbiorca)

Obsługiwane dla danych end-to-end, nadawca szyfruje payload kluczem publicznym odbiorcy (E2E PKI). Nagłówek DTN jest publiczny dla kontroli węzłow DTN, lecz tylko odbiorca może go odszyfrować. Jeżeli węzły nie wymieniły się kluczami PKI, to payload jest nieszyfrowany. Istnieje szansa, że w przyszłości DTN będzie mógł nieść nie tylko pakiety DM ale także innde (np. NodeInfo z kluczami publicznymi)

Telemetria, UI i mapowanie statusów (Android)

Status Opis
DTN_ACCEPTED Source przyjął do custodi (PROGRESSED reason=0x11)
TRANSMITTED Poszło w eter (PROGRESSED reason=0x00)
PROGRESSED (milestone) "Idzie dalej" od pośrednika (reason=via low-byte)
DELIVERED Finalne potwierdzenie dostarczenia — wycisza pending/duplikaty w UI
FAILED Finalne potwierdzenie błędu — wycisza pending/duplikaty w UI
EXPIRED Finalne potwierdzenie wygaśnięcia — wycisza pending/duplikaty w UI

Fallback i kompatybilność

Stock fallback

Blisko celu lub w TTL tail, gdy DTN nie pomoże – natywny DM (PSK/PKI decyduje Router). Źródło dostaje wtedy FAILED (UX: "wysłane przez Stock / DTN unavailable").

Kontrolny control-plane

Beacony/hello-back to PROGRESSED z reason=FW+ version (id=0), TTL=0 (nie custody) – odkrywanie FW+ w siatce bez "ciężkiego" ruchu.

Beacony (FW+ DTN) — odkrywanie węzłów

Beacony to niskokosztowe ogłoszenia "jestem FW+, mam wersję X" oraz lekkie "hello‑back" do odkrywania i potwierdzania węzłów FW+ bez obciążania kanału custodią.

Forma: to pakiety RECEIPT z status=PROGRESSED, zawsze z origId=0 (control‑plane), z polem reason niosącym numer wersji FW+ (np. v84). Nie są milestones konkretnej wiadomości.

Kluczowe cechy
  • Bez custody (TTL=0)
  • Niski priorytet (tło)
  • Rate-limited

Jak działają beacony

1 Nadawanie przez nas (beacon)
  • Po starcie: jeden szybki beacon, potem "warmup" w odstępach ~15 min (kilka razy), a następnie rzadziej (np. co kilka godzin)
  • Format: FWPLUS_DTN_APP z origId=0, status=PROGRESSED, reason=FW_PLUS_VERSION
  • Transmisja: zwykle broadcast (mały hop_limit), priorytet tła, bez ACK
  • Brak custody: TTL=0 – nie trafiają do kolejki pending
2 Hello‑back (odpowiedź)
  • Gdy usłyszy beacon od nowego/znanego FW+, może odesłać krótki unicast PROGRESSED (origId=0, reason=FW_PLUS_VERSION)
  • Silne ograniczenia:
    • Per‑origin cooldown (minuty/godziny)
    • Globalny limiter (min. kilkadziesiąt sekund)
    • Bramka zajętości kanału
Minimalne "probe"

Opcjonalne, bardzo krótkie PROGRESSED (origId=0, reason=0) do konkretnego węzła – też control‑plane, bez custody.

Co robią u odbiorcy

Odkrywanie FW+

Zapis wersji/obecności w cache (wspomaga decyzje DTN).

Wskazówka kierunku

Na bazie przekaźnika beacona budowany jest hint "kierunku" (który sąsiad prowadzi do danego FW+).

Brak wpływu na pending DATA

To nie jest milestone danej wiadomości; nie wpływa na TTL czy custody konkretnego DM.

Ochrona eteru (anti‑flood)

Rate‑limity
  • Globalny: między wszystkimi beaconami/probami
  • Per‑origin: hello‑back (cooldown)
  • Bramka zajętości kanału: sprawdza dostępność przed wysłaniem
Inne mechanizmy
  • Brak custody: beacony/hello‑back nie tworzą pendingów, nie są ponawiane
  • Broadcast z głową: mały hop_limit i priorytet tła, by nie wypierać ruchu użytkowego
Co zobaczysz w logach/UI

Android/Router: "RECEIPT PROGRESSED (status=4) origId=0, reason=FW+ version". To nie milestone wiadomości, tylko sygnał control‑plane o wersji/zdolności FW+.

Wybór tras i decyzje DTN

Moduł DTN korzysta z wielu sygnałów, aby zdecydować komu przekazać custody i jak utrzymać wiadomość w ruchu, gdy klasyczny routing jest niepewny. Poniżej skrót najważniejszych elementów procesu decyzyjnego.

Sygnały wejściowe
  • Confidence i hops z DV‑ETX (czy Router ma pewną trasę)
  • Topologia lokalna (lista sąsiadów FW+, ich hops_away)
  • Link health i historyczne sukcesy/porażki
  • Relay hints z beaconów/hello‑back (kierunki)
  • Limity: channel util gate, per-destination spacing, max_active, suppression
Decyzje DATA
  • Direct: jeśli Router zna pewną trasę – jedna próba do celu
  • Handoff: wybierz świeżego sąsiada FW+ bliżej celu (cache + walidacja)
  • Progressive relay: gdy brak pewnych tras – rotacja edge-node'ów (3–5 kandydatów), kontrola pętli i duplikatów
  • Pośrednicy: forwardują, jeśli mają trasę; w przeciwnym razie stosują ostrożny progressive relay
Custody i pamięć
  • Preferuj handoff do węzłów DTN bliżej celu (cache per-destination)
  • Odrzucaj kandydatów: my sami / cel / ostatni carrier
  • Tombstony blokują recapture i duplikaty po give-up/delivery
  • Suppression po podsłuchu orig_id odkłada kolejne próby
Koordynacja i limity

Per-destination spacing, globalny max_active i bramka zajętości kanału ograniczają tempo generowania ruchu. Suppressions oraz kontrola progressive relay zapobiegają pętlom i nadmiarowym TX, a tombstony utrzymują historię prób.

Potwierdzenia i fallback

Receipty (DELIVERED/FAILED/EXPIRED) wracają determinantnie po custody_path i szybko degradują, gdy hop jest nieświeży. Milestones PROGRESSED informują „idzie dalej” (rate-limit). W ogonie TTL źródło może wykonać late fallback do stock DM.

Uczenie i adaptacja
  • Traceroute podbija confidence do celu (z cooldownami)
  • Beacony/hello-back odkrywają świeże węzły FW+ i kierunki
  • Link health/path reliability aktualizowane po każdej próbie – unikanie słabych ścieżek
  • Adaptacja mobilności: zmiana backoff, spacing i okien retry dla ruchomych węzłów

Ustawienia modułu DTN, opis parametrów

Zalecane wartości produkcyjne (ogólne)

Parametr Wartość Uwagi
enabled false Domyślnie wyłączony
ttl_minutes 6 Minuty
initial_delay_base_ms 8000 8 sekund
retry_backoff_ms 50000 50 sekund
max_tries 2 Silnik rozszerza do 5 przy trasach unknown/bez next_hop
late_fallback_enabled false Wyłączony
fallback_tail_percent 20 Procent TTL
milestones_enabled false Włączony (opcjonalny), pomaga w informacji o postępach i wyciszaniu się pośrednich węzłów (wiedza DTN)
per_dest_min_spacing_ms 60000 60 sekund
max_active_dm 1 lub 2 1 dla słabszych MCU/gęstych sieci, 2 dla mocniejszych węzłów/czystszego kanału
probe_fwplus_near_deadline false Wyłączony

Szczegółowy opis parametrów

Enabled

Domyślnie: false

Włącza/wyłącza moduł DTN. OFF = zachowanie stock (bez DTN).

TTL

Domyślnie: 6 minut

Bazowy TTL (minuty) dla DTN DATA (custody). Większy = dłuższe okno dostawy przez wiele hopów, ale dłuższe wiszenie pendingów. Wszystkie węzły go używają po drodze i "wypalają"

Initial delay base

Domyślnie: 8000 ms

Opóźnienie bazowe przed pierwszą próbą (slotting/election). Mniejsze = szybszy start, większe = więcej "oddechu" dla sąsiadów i routera (mniej kolizji).

Retry backoff

Domyślnie: 50000 ms

Odstęp (backoff) między kolejnymi próbami. Większy = mniej obciążenia eteru, wolniejsze przekazywanie; mniejszy = szybsze retriale kosztem airtime.

Max tries

Domyślnie: 2

Maksymalna liczba prób dla jednego id (poza ograniczeniami TTL). Więcej prób pomaga przy długich, niestabilnych trasach; za dużo = ryzyko nadmiarowych TX. Silnik rozszerza do 5 przy trasach unknown/bez next_hop.

Late fallback enabled

Domyślnie: false

Zezwala na late fallback (natywny DM) blisko końca TTL (gdy DTN "nie rokuje"). Utrzymuje kompatybilność ze stock i ratuje dostawę blisko celu.

Fallback tail percent

Domyślnie: 20%

Odsetek TTL (ogon), w którym rozważany jest fallback. Większy % = wcześniejsze przejście na alternatywę kosztem mniejszej szansy DTN na domknięcie.

Milestones

Domyślnie: false

Włącza emisję PROGRESSED (milestones) – informację "idzie dalej". Pomaga w informacji o postępach, inne nody DTN używają tej informacji (np. do wyciszania się). Milestones powinny trafiać do nadawcy. Nie są wymagane.

Per-dest min spacing

Domyślnie: 60000 ms

Minimalny odstęp między próbami do tego samego celu. Większy = łagodniejszy ruch i mniejsze ryzyko kolizji, kosztem opóźnień.

Max active DM

Domyślnie: 1 lub 2

Limit równoległych aktywnych DTN DM. Niższy = oszczędny airtime i RAM; wyższy = większa przepustowość przy mocniejszym węźle/kanale. 1 dla słabszych MCU/gęstych sieci, 2 dla mocniejszych węzłów/czystszego kanału.

Probe FW+ near deadline

Domyślnie: false

Lekki probe (PROGRESSED, bez custody) blisko końca TTL, aby wykryć FW+ u celu/pośredników i zwiększyć szanse finalnej dostawy lub właściwego fallbacku. Włącz tylko, gdy faktycznie pomaga w Twojej topologii.

Route confidence i traceroute: DTN używa tylko traceroute dla zbudowania confidence (projekt nie używa ping).

Use-cases

Sieci rozproszone i mobilne

Idealne dla sieci z okresowym brakiem tras, gdzie klasyczny routing może zawieść.

Scenariusze 4–7+ hopów i dalej

Szczególnie przydatne przy "kruchym" DV-ETX (NextHop), gdzie standardowy routing ma ograniczenia, a sieć zaczyna się znacznie rozwijać.

Mieszane środowiska

Działa w środowiskach stock + FW+ – bez konieczności aktualizacji wszystkich węzłów. Jest to znaczna zaleta, nie trzeba posiadać DTN na węzłach kluczowych typu backbone, np. routerów. Węzeł DTN może być obok i spełniać swoje zadanie.

Podsumowanie

Co to jest

DTN overlay zapewniający opportunistic store–carry–forward dla prywatnych DM, z niezawodnymi potwierdzeniami odwrotną ścieżką i oszczędnym systemem milestones.

Dlaczego powstał

Klasyczny routing bywa niepewny przy wielu hopach/asymetrii; DTN utrzymuje wiadomości "w ruchu" i dostarcza je, gdy topologia pozwala.

Co wyróżnia

Custody_path, reverse receipts, suppression po podsłuchu, ostrożny progressive relay, kompatybilność stock.

Co zyskujesz

Wyższy delivery rate, lepszą obserwowalność postępów, mniej "znikających" DM.

Na co uważać

Strojenie limitów/TTL, obserwacja airtime, pamięć i stan pendingów.