mirror of
https://gitlab.eurecom.fr/oai/openairinterface5g.git
synced 2026-07-13 04:30:28 +00:00
ac6c40b1f2
NR_MAC/PHY: align SRS time_start_position semantics between L2 and L1 Problem nfapi_nr_srs_pdu_t::time_start_position was being interpreted inconsistently between OAI MAC (the producer) and the various L1 consumers: - MAC populated the field with SRS-ResourceMapping.startPosition from the RRC config — the value 3GPP defines as an offset counted backwards from the end of the slot (TS 38.331). - L1 consumers (openair1/PHY/NR_TRANSPORT/srs_rx.c, openair1/SCHED_NR/phy_procedures_nr_gNB.c) and the MAC's own VRB-map consumer (gNB_scheduler_srs.c) all re-derived the absolute symbol index with NR_SYMBOLS_PER_SLOT - 1 - time_start_position. This works for OAI's in-tree soft L1 (every consumer applies the same inversion), but external FAPI L1s (NVIDIA Aerial / cuBB) treat time_start_position as the absolute symbol index per the SCF FAPI 222 PDU semantics. The MAC and external L1 therefore disagreed by one symbol inversion. Net effect: SRS was scheduled on the wrong OFDM symbol, the RU sampled noise instead of the SRS, and the channel-matrix returned in SRS.indication was all zeros for almost every occasion. Fix Move the inversion to the producer side. MAC populates the PDU with the absolute symbol index (NR_SYMBOLS_PER_SLOT - 1 - startPosition), and every consumer uses srs_pdu->time_start_position directly as l0. The two semantics are mathematically equivalent for OAI's soft L1 (l0 = NR_SYMBOLS_PER_SLOT - 1 - startPosition either way), so the symbol index used internally is unchanged on non-Aerial builds. External L1 consumers now receive the value they expect. Testing status - [x] OAI L1 + L2 - [x] Aerial L1 in CAT-B / mMIMO mode - [x] Aerial L1 in CAT-A mode - [x] RFsim / nrUE end-to-end loopback: Reviewed-By: Rúben Soares Silva <rsilva@allbesmart.pt>