[srslte-users] Unstable SIB detection

Nedelin Rusev nedelin.rusev at gmail.com
Wed Jul 29 05:55:03 UTC 2020


Solved.
For the problematic points, listed in the previous mail-
5.1 and 5.2: I used better antenna + external amp + software gain(50) to
get stable signal.
5.3: I abandoned the shown implementation in the previous mail and did
something far simpler(just as described in the LTE documentation TS36.331,
section 5.2.3):
- for each item in the SIB1 schedule list:
1. T = get periodicity from SIB1's schedule list
2. x = (index in SIB1's schedule list) * (SI Window Length from SIB1)
3. a = x % 10
4. if ( (SFN % T == x /10) && (sub-index == a) ) then we have found a SIB
message

But the major problem I had was caused by srslte_ue_dl_find_and_decode().
There we find the following piece of code:

    // Calculate RV if not provided in the grant and reset softbuffer
    for (int i = 0; i < SRSLTE_MAX_CODEWORDS; i++) {
      if (pdsch_cfg->grant.tb[i].enabled) {
        if (pdsch_cfg->grant.tb[i].rv < 0) {
          uint32_t sfn              = sf->tti / 10;
          uint32_t k                = (sfn / 2) % 4;
          pdsch_cfg->grant.tb[i].rv = ((uint32_t)ceilf((float)1.5 * k)) % 4;
        }
        srslte_softbuffer_rx_reset_tbs(pdsch_cfg->softbuffers.rx[i],
(uint32_t)pdsch_cfg->grant.tb[i].tbs);
      }
    }

which is responsible for setting the "rv" value, if it has invalid value at
this point. My analysis showed that "rv" will have invalid value (-1) when
the PDCCH uses Format1C. Also, it turned out that whenever "rv" is
different then 0, the SIB message decoding performed by
asn1::rrc::bcch_dl_sch_msg_s::unpack() failed. So I had to brute-force "rv"
to be 0 and I did so by setting uint32_t tti = ((sfn / 2) % 4) ? 0 : sfn *
10 + sf_idx;.
Not the cleanest solution, but it worked and for now I am able to read all
SIBs without any troubles.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20200729/0a74dccc/attachment.htm>


More information about the srsran-users mailing list