In working on non-zero propagation delay insertion to 5G NR, I hit upon the following issue, which makes it more difficult to compare results between zero-delay simulations and non-zero delay simulations. The issue is that 3GPP channel fading realizations are assigned upon first use, and if some event perturbation changes the first use slightly, the results can shift dramatically even though, conceptually, nothing has changed (or changed much) about the scenario. Claude isolated this problem and wrote up the following, which I reviewed and can confirm. I think that fixing it will aid in future reproducibility/debugging, but it will change existing simulation results (multi-UE scenarios) across releases (although they are just stream differences). ## Summary `ThreeGppChannelModel` draws every link's fading realization (large-scale parameters, cluster delays and powers, angles, ray shuffles, XPR and initial phases) from four random variables shared by all links (`m_normalRv`, `m_uniformRv`, `m_uniformRvShuffle`, `m_uniformRvDoppler`). The draws for a link happen in `GetNewChannel()` the first time that link is requested. The realization a link ends up with therefore depends on how many draws other links consumed before it, i.e. on the order in which the links are first used during the simulation. `ThreeGppChannelConditionModel` has the same structure for its LOS/NLOS draw (`m_uniformVar`). A change that only alters event timing, with the same topology, seed and run number, can reorder the first uses and silently hand every link a different realization. The realizations are equally valid statistically, so this is a reproducibility problem rather than a modeling error, but it defeats any before/after comparison whose radio-level results are expected to be unchanged. ## How it was found In the 5G-LENA `nr` module, work on non-zero propagation delay compares a run without a delay model against the same run with a distance-based delay (`ConstantSpeedPropagationDelayModel`). With two UEs, the first downlink control burst is a broadcast: at zero delay its two receptions are scheduled at the same timestamp and execute in receiver insertion order (node 1, then node 2); with the delay model they execute in distance order (node 2 at 8.835 us, node 1 at 9.194 us). Both links then consume the shared draws in the opposite order and every link's gain changes by several dB in both directions (for example the low-latency UE's two carriers moved from -72.98 / -75.37 dBm to -78.52 / -73.37 dBm), which flipped an RSRP-driven carrier switch and collapsed a saturated flow's throughput. A uniform delay preserves the order and reproduces the zero-delay results bit-for-bit, and the effect is the same at every propagation speed including c, where the differential delay is a few nanoseconds: only the order matters, not the magnitude. The same mechanism affects any timing change in a multi-link scenario (a scheduler change, a different measurement period, an added transmission), not only propagation delay. ## Reproducer (no simulation events needed) ```cpp // Three nodes with ThreeGpp mobility/antennas; one ThreeGppChannelModel. // Order 1: link (a,b) first, then (a,c). auto hAB1 = model->GetChannel(a, b, antA, antB); auto hAC1 = model->GetChannel(a, c, antA, antC); // Fresh model, same seed/run. Order 2: (a,c) first, then (a,b). auto hAC2 = model2->GetChannel(a, c, antA, antC); auto hAB2 = model2->GetChannel(a, b, antA, antB); // hAB1 != hAB2 and hAC1 != hAC2 (element-wise), although topology, seed // and run are identical. ``` The equivalent statement for `ThreeGppChannelConditionModel`: calling `GetChannelCondition()` for two pairs in either order can give each pair the other's LOS draw. ## Why it matters - Any exact before/after comparison over a multi-link 3GPP scenario is only valid if the first-use order is unchanged, which nothing enforces and nothing reports. - Bit-exact regression tests over 3GPP channels are fragile against unrelated timing changes, and a failure looks like a modeling regression rather than a re-roll. - The channel condition variant can flip a link between LOS and NLOS, which is a tens-of-dB change, from a timing change alone. ## Proposed fix (sketch) Make each link's draws come from a stream derived from the link's identity instead of from generators shared across links, so that the realization depends on topology, seed and run only. 1. In `ThreeGppChannelModel`, keep the per-link random variables in the per-link state (`ThreeGppChannelParams` already exists per node pair and carries `m_generatedTime`). On first use of a link, create its normal, uniform and shuffle variables and set their streams to `Derive(base, key, i)`, where `key` is the reciprocal node-pair key the model already computes (`GetKey(a, b)`) and `i` selects the variable. `GetNewChannel()` and the channel-parameter generation then draw from the link's own variables. 2. `Derive()` maps `(base, key, i)` into the deterministic stream range. `RandomVariableStream::SetStream(s)` uses stream index `2^63 + s`; the automatic assigner uses the first `2^63` indices, so any `s` in `[0, 2^63)` is free of automatic collisions. To stay clear of small explicitly assigned indices from other models' `AssignStreams`, fold a 64-bit hash of `(base, key, i)` into `[2^62, 2^63)`. Collisions between links are then negligible and every index is an independent MRG32k3a stream, so no extra state is shared. 3. `base` comes from `AssignStreams(stream)` when the user calls it; if not called, take one automatic index at construction as the base so that the model still participates in the run-to-run variation via `RngRun` and consumes a fixed number of automatic indices (one instead of four). 4. Apply the same pattern to `ThreeGppChannelConditionModel` using its `GetKey(a, b)` for the LOS draw and the O2I draws, and to `ThreeGppPropagationLossModel::GetShadowing()`, which draws each pair's shadowing on first use (and on the correlated update after movement) from one shared normal variable keyed by the same pair. All three models must change together for a fixed topology to be order-invariant; fixing the channel model alone leaves the LOS state and the shadowing value order-dependent. 5. Add a test that generates channels for several links in two different orders and asserts element-wise equality, and the same for channel conditions. What this does not change: realizations still depend on node IDs and therefore on node creation order, as every ns-3 result does. The new property is invariance to event order for a fixed topology. ## Compatibility The change alters the realizations of every existing 3GPP-channel run, so tests that pin expected values (spectrum, propagation, lte, nr downstream) need their expectations regenerated. If a silent change of results is not acceptable, a boolean attribute (for example `PerLinkStreams`, default false for one release, then true) keeps the current behavior selectable; the test above runs with the attribute set. ## Workarounds available today - Use a uniform delay, a single link per channel instance, or a channel model without shared-stream fading when an exact radio-level comparison is required. - Pre-generate all links in a fixed order before `Simulator::Run()`, for example by requesting `GetChannel()` / `GetChannelCondition()` for every pair in device order from a helper. This gives event-order invariance without touching the model, at the cost of generating channels for pairs that may never communicate.