SRSue Large Number of HARQ NACKs in Presence of Other UEs

[davidlwhite]

Issue Description

I am seeing SRSue receive an unusually large number of HARQ NACKs from the eNB whenever a commercial UE is attached and actively transmitting/receiving on the same cell...

I ran tests with two different commercial UEs (a Pixel4 and a OnePlus N200) with similar results.

Is this a known issue / limitation? Any ideas how to fix/get around this?

Setup Details

I used the latest in the master branch (commit sha: eea87b1d893ae58e0b08bc381730c502024ae71f). SRSue is running on Ubuntu 22.04.3 LTS, using a USRP B210, and UHD_4.1.0.5-3. eNB is a commercial eNB. Other details are in the logs attached.

Expected Behavior

Few to no MAC NACKs.

Actual Behaviour

Large number of HARQ NACKs from eNB to SRSue.

Steps to reproduce the problem

• I used the latest in the master branch (commit sha: eea87b1d893ae58e0b08bc381730c502024ae71f)
• Attach the commercial UE to commercial eNB, get UE's IP.
• Ping commercial UE.
• Run SRSue, attach and get its IP.
• Ping SRSue.
• Watch NACK count in ue.log rack up.

Additional Information

Attached are two sets of debug level logs and pcap files:

• oneUE_lotsOfNACKs: Setup as above, shows issue. Grepping for keyword "Adapt" (printed whenever a NACK is received) shows 13345 NACKs.

  >> grep -c "Adapt" oneUE_lotsOfNACKs/ue.log
  13345

• noUEs_noNACKs: Similar setup as above, but commercial UE is kept in Airplane mode. Grepping for keyword "Adapt" shows 0 NACKs.

  >> grep -c "Adapt" noUEs_noNACKs/ue.log
  0

    SRSue config file is also attached.

noUEs_noNACKs.tar.gz oneUE_lotsOfNACKs.tar.gz

[davidlwhite]

I solved this issue with the following patch:

diff --git a/lib/src/phy/phch/ra_ul.c b/lib/src/phy/phch/ra_ul.c
index 8ca825f54..1bb3b0928 100644
--- a/lib/src/phy/phch/ra_ul.c
+++ b/lib/src/phy/phch/ra_ul.c
@@ -189,6 +189,9 @@ static int ra_ul_grant_to_grant_prb_allocation(srsran_dci_ul_t*      dci,
     INFO("n_rb_pusch: %d, prb1: %d, prb2: %d, L: %d", n_rb_pusch, grant->n_prb[0], grant->n_prb[1], grant->L_prb);
     grant->freq_hopping = 1;
   }
+ 
+  // Copy n_dmrs (DMRS Cyclic Shift)
+  grant->n_dmrs = dci->n_dmrs;
   if (grant->n_prb[0] + grant->L_prb <= nof_prb && grant->n_prb[1] + grant->L_prb <= nof_prb) {
     return SRSRAN_SUCCESS;

[joaquim-srs]

Hi there,

Thank you for reporting this issue and taking the time to create a patch.

This issue is challenging to reproduce, as it requires using a commercial ENB instead of srsENB, with two COTS SIMs from the network provider. Nonetheless, I managed to observe that, when doing traffic with srsUE on a commercial ENB, in some instances the PUSCH DM-RS cyclic shift selected by the commercial ENB differs from 0.

I verified that srsUE would still used a cyclic shift of 0 to generate the PUSCH DM-RS in this instance, and that your patch solves the issue.

The fix will be included in the next release.