[josephnef]

M6 (#260, EPIC #254): the first handovers on the rig with nothing forced. A UE crosses from one cell to the other and back, and the CU's A3 decides at its default thresholds. This closes the "no crossing test" item.

What

• DU, test knob CELL_DU_TX_RAMP=T:DB,…: the DU's TX power offset, piecewise linear in seconds from CELL_DU_TX_RAMP_T0 (unix seconds, so the DUs of one test ramp together; the hosts are NTP-synced) or from service start, and held at the ends. It is applied in 0.5 dB steps via SetTxPowerOffsetQdb and logged as cell.du.txpwr (wanted vs applied). Beacons and DL follow it.
• UE: logs each measurement report it builds (cell.ue.mr: serving cell, sf, RSSI per cell).
• Docs: docs/cell-m6.md gains a section on the emulated crossing. It replaces the two open items ("a moving UE", "no crossing test") with an honest limit: emulated by TX power, uplink path loss unchanged, one UE, one ramp rate.

Rig (testrig scripts/m6_crossing.sh, keyed, one channel, UE1 only)

Cell 1 fades by 16 dB over 15 s while cell 2 rises, they hold, then reverse. The UE's measured margin sweeps from about −13 to +24 dB and back. The A3 runs at its defaults (3 dB offset, 1 dB hysteresis, 640 ms TTT, 2 s dwell).

Crossing 1 → 2 → 1, 3/3 pass: exactly two handovers per run, both triggered by the A3 on the UE's own measurements.

KPI (6 handovers)	min	median	max
UE margin reaching the A3 entry (4 dB) → switch	38 sf	41.5 sf	51 sf
margin at the CU's trigger	7 dB	9.5 dB	13 dB
interruption	1 sf	1 sf	2 sf
uplinks missing at the CU (DAPS)	0	0	0

• Where the time goes: 24 sf of crossing → switch is the handover lead. The rest is the TTT plus the 1 s reporting chain (UE MR, DU F1 report, CU round). At about 2 dB/s of margin, that chain is why the trigger lands 3–9 dB past the entry.
• Each switch passes the TSF-continuity check, is heard in slot ≥ 99 % at the target, and is released by the source.

Hover just under the entry, 3/3 pass: median margin +3 dB (p10–p90 +2 to +4), with 20–23 % of the UE's reports at or above the entry. No handover in any run.

Found on the way: the power-to-RSSI relation isn't linear on the rig. −8 dB of offset reads about −9 dB at the UE, and −9 dB about −12 dB. The cause is not established. The tests judge by the UE-measured margins, not the offsets.

🤖 Generated with Claude Code

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Emulate unforced cell crossings with DU TX-power ramps

✨ Enhancement 📝 Documentation 🕐 20-40 Minutes

AI Description

• Add synchronized DU TX-power ramps to emulate a UE crossing between cells without forcing
 handovers.
• Log UE measurement reports and DU power changes to trace the A3 decision.
• Document crossing and hover rig results, plus the limits of TX-power-based emulation.

Diagram

graph TD
  Schedule["Ramp schedule"] --> DU1["Cell 1 DU"] --> UE["UE measurements"] --> Reports["Measurement reports"] --> A3{"CU A3 decision"} --> Handover["Cell handover"]
  Schedule --> DU2["Cell 2 DU"] --> UE

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Inject synthetic UE measurements

• ➕ Could make crossing cases deterministic without synchronized DU hosts.
• ➖ Would bypass beacon reception and the radio power-to-RSSI behavior this rig run exercises.

2. Move the UE or use a channel emulator

• ➕ Could model uplink path loss and over-the-air fading as well as downlink changes.
• ➖ Requires additional rig hardware or motion control and is beyond this test's stated scope.

Recommendation: Keep the DU power-ramp approach for this first unforced crossing test: it exercises real UE measurements and the existing A3 path on the current rig. Retain the documented limitation that changing downlink transmit power does not emulate a moving UE's uplink path loss.

Files changed (2) +128 / -7

Enhancement (1) +77 / -0

main.cppRamp DU transmit power and log UE measurement reports +77/-0

Ramp DU transmit power and log UE measurement reports

• Parses test-only, piecewise-linear DU power offsets with an optional shared Unix start time, applies them in 0.5 dB steps, and logs requested versus applied power. Logs each nonempty UE measurement report's serving cell, superframe, and per-cell RSSI.

examples/cell/main.cpp

Documentation (1) +51 / -7

cell-m6.mdDocument unforced crossing and hover rig results +51/-7

Document unforced crossing and hover rig results

• Adds the two-cell ramp setup, measured crossing and hover outcomes, and an explanation of reporting-chain delay. Replaces open crossing-test items with explicit limits of the emulation, including unchanged uplink path loss.

docs/cell-m6.md

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Handover rig results omit the source-path failure test ✓ Resolved

Description

The M6 section reports only the crossing and hover runs, so the DAPS results are uplinks-missing
counts during a healthy crossing, not a source-path failure. The ticket's rule requires a
source-path failure run that shows uplinks delivered via the target when the source fails, plus a
reported DAPS gain. The PR text says the crossing 'closes the no crossing test item' but says
nothing about a failure case, so that part of the validation is unaddressed.

---

2. Ramp silently skips on a mistyped anchor ✓ Resolved

Description

ramp_t0_unix is parsed with std::atof from CELL_DU_TX_RAMP_T0, so a malformed or non-numeric
value becomes 0 and the code falls back to service-start timing with no warning. DUs meant to share
one ramp zero would then ramp out of phase, misaligning the crossing the test is meant to measure.

---

3. Refused power writes are never retried ✓ Resolved

Description

After SetTxPowerOffsetQdb(want_qdb) returns, ramp_set_qdb is set to want_qdb regardless of the
return value, so a refused write is not retried until the target moves by another 0.5 dB. The ramp
then stays off on that DU for the rest of the run, and the only trace is a cell.du.txpwr line with
applied_qdb different from want_qdb that no check reads.

---

4. Hover criterion looser than its claim ✓ Resolved

Description

The docs say the hover runs had no handover, but the same paragraph says the test allows one. The
stated pass criterion is therefore looser than the reported result, so a regression that produces
one spurious handover would still pass.

---

Tip of the day

💡 Did you know, you can switch off images and animations for a plain-text comment

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[josephnef]

Qodo review addressed in 2790f8b:

1. Source-path failure (requirement gap): added to the crossing test. DU1 is killed the moment its UE accepts the handover, mid-crossing, with DAPS and without. Uplinks missing from the CU's stream in the crossing window (switch −24 … +20 network sf): 0 / 0 with DAPS vs 11 / 13 without (2 + 2 runs). The standalone DAPS result (m6_daps.sh, source killed, 0/0 vs 11/16 keyed) stays in its own section.
2. Mistyped anchor: CELL_DU_TX_RAMP_T0 is parsed with strtod and an end-pointer check, and must be > 0, or the DU refuses (exit 2). The anchor used is logged as cell.du.txpwr_t0.
3. Refused power writes: a ramp on a radio without runtime TX power control (GetTxPowerCaps().supported false) is refused at start. On Kestrel the call never refuses, it only clamps to the PA window and returns the applied value, so a retry of the same target cannot change it: a clamp now warns once on stderr, and every step logs wanted vs applied.
4. Hover wording: the doc now states the criterion (at most one handover, never back) and the result (0 handovers in all 3 runs) separately.

Also, a CU bug the re-runs exposed: after a switch the target heard the UE in slot only 91–98 %. The CU planned from the DUs' reported positions. Those lag a schedule by RAN_LEAD_SF, which is more than a plan round, so with two equally good layouts it re-issued them in turn every round, one off-slot uplink per swap. It now plans from its own issued schedule. After the fix the crossing set is 3/3, the hover 3/3 and the source failure 2/2, all on the final code; a coordination/handover/DAPS/phase-planning/re-join regression is running.

[josephnef]

On hover criterion looser than its claim: the doc now gives the result (0 handovers in all 3 runs) and the reason the criterion is 'at most one, never back' rather than zero. At a +3 dB hover, the L3-filtered margin can legitimately hold the 4 dB entry for the time-to-trigger. One hover run of the earlier set did exactly that, once, and never switched back. A zero-handover assertion would fail correct A3 behaviour. What the test must catch is ping-pong (a switch back), and it fails on that. (8cf378f)

[josephnef]

CI green; all four Qodo findings resolved. The remaining items are the two high-level alternatives (synthetic UE measurements; moving the UE or a channel emulator), for which Qodo recommends this PR's DU power-ramp approach, with the documented limit that it does not emulate the uplink path loss. Merging with skip-qodo-gate.