Incorrect number of RE in tdd while decoding pdsch

[softdev86]

Dear All,
currently I use srsLTE with b200mini device and try to track random access response messages and contention resolution messages for several crnti on real enodeB, but on tdd I frequently got error
ERROR("Error expecting %d symbols but got %d\n", cfg->grant.nof_re, n) from pdsch.c, most of the time on the special subframes 1 and 6. Maybe I'm missing something.

In order to reproduce the error with minimum example I used pdsch_ue for two rnti: p-rnti and c-rnti on same enodeB where I got the error. Crnti correspond to the actually connected to the enodeB phone. The only changes I made in the srsLTE code for this example were in rf_uhd_impl.c to separately set the time source and clock source to external. I used commands
sudo pdsch_ue -a "serial=SEm0001" -f 2325e6 -g 50 -r fffe -G 2 -T 7
sudo pdsch_ue -a "serial=SEm0001" -f 2325e6 -g 50 -r 5f4c -G 2 -T 7

Please find the attached logs.

MIB message was

• Type: TDD
• PCI: 42
• Nof ports: 4
• CP: Normal
• PRB: 50
• PHICH Length: Normal
• PHICH Resources: 1
• SFN: 976

Tdd special config (sf_config = 2, ss_config = 7) was configured according to sib1 message:
50 50 17 0d 30 09 10 44 1f 15 81 a7 19 02 08 20 45 02 c4 ef 20 00

Driver version is 3.13.0. Version of srsLTE is 20.04.2.

pdsch_ue_logs.tar.gz

Best regards

[softdev86]

Hello all,
it looks like function ra_re_x_prb in ra_dl.c incorrectly calculates the number of reference signals for a special subframe. For example, with nports=4, the number of references in slot=1 Nref=12 (per one prb ) is valid only for ss_config = 4. The above problem was solved for me after minor changes:

  // remove references
 if (skip_refs) {
    if (sf->sf_type == SRSLTE_SF_NORM) {
      switch (cell->nof_ports) {
        case 1:
        case 2:
          if ((cp_ == SRSLTE_CP_NORM && nof_symbols >= 5) || (cp_ == SRSLTE_CP_EXT && nof_symbols >= 4)) {
            re -= 2 * (slot + 1) * cell->nof_ports;
          } else if (slot == 1) {
            if (nof_symbols >= 1) {
              re -= 2 * cell->nof_ports;
            }
          }
          break;
        case 4:
          if (slot == 1) {
            if ((cp_ == SRSLTE_CP_NORM && nof_symbols >= 5) || (cp_ == SRSLTE_CP_EXT && nof_symbols >= 4)) {
              re -= 12;
            } else if (nof_symbols >= 2) {
              re -= 8;
            } /*else if (nof_symbols == 1) {
              re -= 4;
            }*/
          } else {
            if ((cp_ == SRSLTE_CP_NORM && nof_symbols >= 5) || (cp_ == SRSLTE_CP_EXT && nof_symbols >= 4)) {
              re -= 4;
              if (nof_ctrl_symbols == 1) {
                re -= 4;
              }
            }
          }
          break;
      }
    }
    if (sf->sf_type == SRSLTE_SF_MBSFN) {
      re -= 6 * (slot + 1);
    }
  }

Hope it helps.

Best regards.

[andrepuschmann]

Thanks for reporting this issue and proposing a solution. We try to reproduce on our side.

[andrepuschmann]

Hey, thanks for the update. Do you mind sending a proper diff or patch for that, or even formatting it correctly here would be enough. Thanks

[softdev86]

yes, here is the diff. I also updated comment above
ra_dl_diff.txt

[andrepuschmann]

Thanks for that. We've cherry-picked it and test now. The fix should be included in the next release. Have you tested srsUE by any chance with the TDD cell you have?

[softdev86]

Hello,
i tried to run srsue, but it didn't work. The Problem is always related to the lack of RAR packet, so srsue stuck in a preamble transmission loop. Relevant log:

18:43:06.519600 [PHY0] [I] [ 2005] SYNC: MIB Decoded: Mode=TDD, PCI=11, PRB=50, Ports=4, CFO=0.8 KHz
................
18:43:07.069540 [RRC ] [I] Proc "Connection Request" - Waiting for RRCConnectionSetup/Reject or expiry
18:43:07.070430 [MAC ] [I] [ 7053] SR: PUCCH not configured. Starting RA procedure
18:43:07.070444 [MAC ] [I] [ 7053] RA: INIT: Starting PRACH by MAC order
18:43:07.070493 [PHY0] [I] [ 7054] PRACH: configIdx=3, rootSequence=690, zeroCorrelationConfig=12, freqOffset=6
................
18:43:07.095421 [MAC ] [I] [ 7078] RA: PDCCH: seq=29, ra-rnti=0x3, ra-tti=7082, f_id=0
18:43:07.095522 [PHY0] [I] [ 7078] PRACH: Transmitted preamble=29, tti_tx=7082, CFO=0.35 KHz, nof_sf=1, target_power=-108.0 dBm

18:43:07.095571 [PHY0] [I] [ 7079] Setting PHICH mi value auto. sf_idx=8, mi=1, idx=0
18:43:07.095672 [PHY0] [I] [ 7079] Decoded CFI=1 with correlation 28.80, sf_idx=8
18:43:07.096283 [PHY0] [I] [ 7079] SYNC TRACK: sf_idx=9, ret=-1, next_state=1
18:43:07.096348 [PHY0] [I] [ 7080] Setting PHICH mi value auto. sf_idx=9, mi=0, idx=1
18:43:07.096460 [PHY0] [I] [ 7080] Decoded CFI=1 with correlation 29.99, sf_idx=9
18:43:07.097307 [RRC ] [I] MEAS: New measurement serving cell: rsrp=-81.22 dBm.
18:43:07.097309 [PHY0] [I] [ 7080] SYNC TRACK: sf_idx=0, ret=-1, next_state=1
18:43:07.097355 [PHY0] [I] [ 7081] Setting PHICH mi value auto. sf_idx=0, mi=0, idx=1
18:43:07.097454 [PHY0] [I] [ 7081] Decoded CFI=1 with correlation 36.33, sf_idx=0
18:43:07.098436 [PHY0] [I] [ 7081] SYNC TRACK: sf_idx=1, ret=1, peak_pos=795, peak_value=17.02, mean_cp_cfo=0.00, mean_pss_cfo=-0.04, total_cfo_khz=-0.6
................
18:43:07.112418 [MAC ] [E] [ 7095] RA response not received within the response window

I can provide a full log if required. Hope it helps.

[andrepuschmann]

Thanks for trying this out. The missing RAR could have many causes. Maybe also the Tx power is too low and you too far away from the cell. Hard to say without full logs, etc. Anyway, thanks again for flagging the issue.