Dynamic coding rate based on whether node is mobile

[robekl]

The Proposal

Treat node roles as a mobility proxy and use coding rate (CR) asymmetrically:

• non-mobile (fixed infrastructure, e.g., repeaters/room servers): start at CR5
• mobile (on-person/in-vehicle, low height, moving): start at CR6 or CR7, up to CR8 when needed
• Keep BW/SF/frequency aligned network-wide unless intentionally partitioning networks

Motivation: PR #1923 introduces SNR-driven per-hop CR adaptation for repeater direct forwarding, showing a path toward role/link-aware CR behavior without globally forcing one CR everywhere.

Background

From current upstream/dev behavior:

• Docs already describe CR5 as default and suggest higher CR for weak/intermittent links (docs/faq.md, docs/cli_commands.md)
• MeshCore has heavy airtime-aware timing:
• retransmit delays are derived from estimated airtime (getEstAirtimeFor(...) * tx_delay_factor)
• dispatcher send timeout is scaled from estimated airtime
• airtime budget backoff is based on measured transmit time
• Flood/direct/ACK/path/response behavior is tightly coupled:
• unknown paths and group traffic rely on flood
• direct traffic and ACK/path-return drive path convergence
• PR Add SNR-driven dynamic coding rate selection for repeater retransmits #1923 currently applies dynamic CR mostly to repeater forwarding of direct traffic (not a full network-wide adaptive CR system)

RF context:

• Mobile nodes at ~5 ft often suffer worse Fresnel clearance and more dynamic obstruction than fixed nodes at ~20 ft
• Higher CR can improve decode robustness near margin, but increases airtime and channel occupancy

Benefits / Drawbacks

Benefits

• Better edge reliability for mobile links with poor geometry and frequent fading
• Potentially fewer failed direct attempts and fewer expensive fallback cycles
• Infrastructure links (fixed-to-fixed) keep lower airtime cost with CR5

Drawbacks

• Higher CR increases airtime, so collision risk and queue pressure can rise under load
• Flood traffic cost grows quickly when CR is raised, because many relays retransmit
• ACK/response/path-return latency increases when the sender/forwarder uses higher CR
• If mixed-CR interoperability is imperfect in practice for your radio settings, risk of partial segmentation
• Additional policy state and tuning complexity (role mapping, thresholds, fallback logic)

Complexity To Implement

Low-to-medium for a first pass, medium-to-high for robust behavior.

• Low: static role-based defaults (mobile profile uses higher CR; fixed uses CR5)
• Medium: per-message/per-route policy (e.g., only raise CR for direct retries or weak-neighbor forwarding)
• Medium-high: fully adaptive logic integrating neighbor SNR history, mobility hints, queue load, and hysteresis

PR #1923 already adds important plumbing (_tx_cr, dispatcher CR switching per TX). Gaps for broader strategy include:

• consistent treatment across message classes (flood, ACK, path, control)
• alignment between airtime-based delay estimation and the actual selected per-packet CR
• safe fallback behavior when neighbor quality is unknown/stale

ROI

Likely good ROI in mixed deployments (fixed backbone + mobile clients), but only if tuned carefully.

• Highest upside: mobile reliability at network edges and in motion
• Highest risk: airtime inflation during congestion, especially for flood-heavy periods
• Best ROI path: incremental rollout with metrics and guardrails, not all-at-once policy shifts

Other Things To Consider

• Start conservative:
• fixed nodes at CR5
• mobile nodes at CR6 first, escalate to CR7/8 only with evidence
• Consider alternatives:
• Always CR8 for mobile: simplest, highest reliability bias, highest airtime cost
• Always CR7 for mobile: compromise option
• CR8 only on retry for mobile direct traffic
• SNR-based dynamic CR for repeaters (PR Add SNR-driven dynamic coding rate selection for repeater retransmits #1923 direction), but keep floor/ceiling and hysteresis
• Keep flood policy separate from direct policy:
• direct: more acceptable to raise CR selectively
• flood: be stricter due to network-wide airtime multiplication
• Validate with real metrics before broad rollout:
• delivery success by message type
• ACK RTT and retry counts
• channel busy/cad timeout trends
• flood vs direct packet mix changes
• Clarify interoperability assumptions in lab for your exact radio stack/settings before production rollout