Summary

  • RFC 5148 recommends deliberate random timing variation for MANET control traffic when lower layers do not already prevent simultaneous-transmission collisions effectively.
  • It defines different timing behaviour for periodic generation, externally triggered generation and message forwarding.
  • Periodic timing subtracts jitter from MESSAGE_INTERVAL; triggered and forwarded traffic is delayed by jitter.
  • Random values should be uniform from zero to the applicable MAXJITTER, but a configured bound does not prove the runtime distribution.
  • Periodic MAXJITTER must not exceed half the message interval and should not exceed one quarter.
  • A positive MESSAGE_MIN_INTERVAL creates additional mandatory and recommended bounds.
  • Forwarders may not know the originator's interval, so valid jitter requires agreement, carriage, estimation or another protocol-specific rule.
  • Waiting can cause later same-type messages or triggers to overtake earlier work, leaving discard, coalescing and ordering policy to the applying protocol.
  • Messages from one packet should share one random forwarding delay; drawing many values and taking the minimum distorts the intended distribution.
  • Forwarding delay accumulates by hop, so the network diameter belongs in the worst-case timing budget.
  • Random timing can make selective jamming harder to schedule, but it is not authentication, authorization or comprehensive anti-jamming protection.
  • Collision reduction, transmit attempt, reception, topology agreement, route installation and application delivery are separate evidence layers.

A timing cure aimed at repetition

Wireless neighbours can generate control traffic at the same instant for structural reasons. Periodic schedules may start together. A common topology change may trigger several nodes together. Several forwarders can receive the same broadcast and immediately relay it together. A single collision can therefore reproduce itself instead of remaining a one-off event.

RFC 5148 addresses that narrow failure mode with jitter: a bounded random change to transmission timing. It applies to MANET control protocols where simultaneous transmissions are undesirable and the MAC or physical layer does not already solve the problem effectively. The applicability clause matters. Jitter is not a universal badge of wireless maturity, and adding it where the lower layer already supplies the needed separation can add delay without buying the intended benefit.

The standard is Informational and deliberately asks each applying protocol to specify the details needed for interoperability. Its contribution is a timing discipline and a set of bounds. It is not a radio-performance certificate.

The three clocks do not move the same way

For periodic messages, the interval becomes MESSAGE_INTERVAL - jitter. Subtraction ensures that the next message is not later than the nominal interval, which protects timeout assumptions based on late or missing messages. The next schedule is anchored to the previous actual transmission, not to a fixed wall clock. Repeated independent shifts can therefore separate nodes that began in lockstep.

For an externally triggered message, the operation is the opposite: transmission is delayed by a random duration. Nodes reacting to the same observed change are less likely to answer together. If the event begins or resets a periodic schedule, that schedule should begin from the delayed time so the common event does not silently recreate synchronisation.

Forwarding also adds delay, but the forwarder has an information problem. It may not know the originator's message interval, which helps determine a safe maximum. The applying protocol must establish the interval by prior agreement, include it in the message, estimate it from observations or define another rule. A generic “jitter on” flag cannot demonstrate that the chosen delay was valid.

A maximum is a constraint, not an observation

RFC 5148 recommends uniform selection between zero and MAXJITTER. For periodic generation, the maximum must be non-negative, must not exceed half MESSAGE_INTERVAL, and should not exceed one quarter. When a non-zero MESSAGE_MIN_INTERVAL exists, the maximum must not exceed it and should not exceed half of it.

Those inequalities prevent a configuration from consuming too much of its own schedule. They do not prove that a running random-number generator was uniform, independent across nodes or called at the right event. Nor do they prove that the effective value matched the configured value. A management model can expose HP_MAXJITTER, HT_MAXJITTER, TP_MAXJITTER, TT_MAXJITTER or F_MAXJITTER; it still describes a control surface. Runtime proof needs timestamps, draws, aggregation decisions and packet traces.

The appropriate scale also depends on the medium. The RFC suggests that the maximum should be significantly larger than a MAC frame period—an order of magnitude is an example—while remaining as small as practical because the introduced delay otherwise harms a well-designed protocol. Denser interference neighbourhoods can justify more separation. That trade-off cannot be decided from an RFC default alone.

Waiting changes more than a timestamp

Delay creates state. A new trigger may arrive while an earlier message waits. An implementation that postpones generation can combine both triggers into one fresh message. An implementation that generated immediately must decide whether to discard the earlier message, send both or change timing while preserving order. RFC 5148 properly calls that choice protocol-specific.

Forwarding has the same race. A later message from the same originator and type can arrive before the earlier one is relayed. Jitter may make this more frequent. A trace that shows the later message leaving first is not automatically a scheduler defect; a trace that shows both leaving is not automatically correct. The applying protocol owns the semantics.

Aggregation creates another trap. Messages received in one packet should use one random forwarding delay. Drawing a separate value for each and then choosing the smallest produces a different, lower-mean distribution. When messages from different packets are combined, the earliest independently required send time may govern. Evidence must therefore record the aggregation unit and chosen deadline, not merely the configured range.

Every hop spends the budget

A local delay can look negligible while its path effect is not. A forwarded control message may acquire jitter at each hop. RFC 5148 explicitly connects the chosen maximum to the expected sequential-forwarding count, up to the network diameter, so maximum accumulated delay remains bounded.

Later MANET specifications make that dependency concrete. RFC 6130 separates periodic and triggered HELLO jitter and excludes forwarding jitter because HELLO messages are not forwarded. RFC 7181 separates periodic TC, triggered TC and forwarding jitter. RFC 7183 accounts for per-hop forwarding jitter in validity-time reasoning. These refinements show why one global “jitter” metric is too coarse.

A validity time widened to cover worst-case forwarding delay is still only a budget. It does not say that a particular message traversed the path, that every node accepted it, or that the resulting topology was current.

Probability must not be promoted into receipt

Jitter aims to reduce the likelihood of simultaneous transmission and to stop an accidental synchronisation from persisting. It cannot make collision probability zero. Nodes can draw similar values. Hidden terminals, interference, congestion, fading, queue pressure and implementation defects remain. A successful local transmit call may precede loss on the medium; a link-layer acknowledgement, where one exists, may cover one receiver rather than every intended broadcast neighbour.

The evidence chain is therefore layered. Configuration shows intended bounds. Scheduler logs show an effective delay. Radio traces show a transmission attempt. Receiver traces show reception at particular nodes. Protocol state shows processing and topology inference. Route tables show installed choices. Data-plane probes show forwarding. Application telemetry shows usable delivery. No earlier green light should inherit the authority of the next.

The security observation is equally bounded. Random timing may make selectively scheduled jamming harder because transmission moments are less predictable. RFC 5148 leaves full security analysis to the applying protocol. Weak or correlated randomness, traffic observation, wideband interference and authenticated-message requirements remain separate. Jitter is not a credential.

Sources

  1. RFC 5148, HTML
  2. RFC 5148, text
  3. RFC Editor record for RFC 5148
  4. IETF Datatracker record for RFC 5148
  5. RFC 5148 history
  6. References from RFC 5148
  7. RFC 5148 errata
  8. RFC 6130: NHDP
  9. RFC 7181: OLSRv2
  10. RFC 7183: OLSRv2 metrics
  11. RFC 7939: NHDP-MIB
  12. RFC 7985: MANET terminology
  13. RFC 5444: MANET packet/message format
  14. RFC 3626: OLSR
  15. RFC 3561: AODV
  16. RFC 4271: BGP-4
  17. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  18. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  19. Running-Code Primacy