[srslte-users] PDCCH/DCI Blind Searching

Patrick Cutno PCutno at girdsystems.com
Fri May 5 16:51:46 UTC 2017


Thank you Ismael for clearing that up.

What about the variables and array that are created during each call? Can they be moved outside of the function or do they need to be created and kept track of separately from other calls?

Pat
________________________________
From: Ismael Gomez [ismael.gomez at softwareradiosystems.com]
Sent: Friday, May 05, 2017 11:17 AM
To: Patrick Cutno; Tom Tsou
Cc: srslte-users at lists.softwareradiosystems.com
Subject: Re: [srslte-users] PDCCH/DCI Blind Searching

There are no major downsides to switch to integer processing. On the contrary you should see some performance gains. For control we still use floating point processing just for simplicity because the overall performance improvement does not justify the effort of porting to integer right now.

On Thu, 4 May 2017 at 21:58 Patrick Cutno <PCutno at girdsystems.com<mailto:PCutno at girdsystems.com>> wrote:
I know you guys said the DCI search isn't a big compared to everything else but I just had one more question. I noticed "srslte_rm_conv_rx" and "srslte_viterbi_decode_f" had similar functions that use int16_t instead of floats; "srslte_rm_conv_rx_s" and "srslte_viterbi_decode_s".

It looks like those functions are used in srslte/lib/phch/uci.c instead of srslte/lib/phch/pdcch.c where the floating point versions are repeatedly called. Ismael, if you happen to remember, could you tell me what are some of the downsides of switching to the int16_t version?

Also, is it necessary to call "float tmp[3 * NCOLS * NROWS_MAX]" for every call of the srslte_rm_conv_rx? Does the array need to be maintained for different calls? Would it be possible to create it once and reuse it (I haven't looked into this yet)?

Thanks again
Pat
________________________________________
From: Patrick Cutno
Sent: Thursday, May 04, 2017 2:54 PM
To: Tom Tsou
Cc: srslte-users at lists.softwareradiosystems.com<mailto:srslte-users at lists.softwareradiosystems.com>
Subject: RE: [srslte-users] PDCCH/DCI Blind Searching

Tom,

Thank you for input as well.

Pat
________________________________________
From: Tom Tsou [tom at tsou.cc]
Sent: Thursday, May 04, 2017 2:45 PM
To: Patrick Cutno
Cc: srslte-users at lists.softwareradiosystems.com<mailto:srslte-users at lists.softwareradiosystems.com>
Subject: Re: [srslte-users] PDCCH/DCI Blind Searching

Hi Patrick,

On Thu, May 4, 2017 at 10:20 AM, Patrick Cutno <PCutno at girdsystems.com<mailto:PCutno at girdsystems.com>> wrote:
> I have started to look in to what optimizations could be done to the code to
> reduce the CPU usage and the "dci_blind_search" and its subsequent function
> calls are called quite often. I know its not SRS's fault, I actually found
> in my research that everyone implements the search the same way. It was nice
> to find SRS's code implements the common and UE specific search space
> optimization to reduce the number of PDCCH locations, formats, and DCI
> format combinations that need to be searched but I feel this could still be
> improved upon. . .

I know that DCI search seems inefficient, but I'll echo Ismael's
statement that the blind detection is not significant relative to
other loads - mainly turbo decoding. DCI messages have short lengths
and convolutional decoding is non-iterative, so PDCCH load is
comparatively small compared to larger and possibly punctured PDSCH
blocks.

The case where DCI search load goes high is if you want to brute force
the full RNTI search space, but that procedure is intentionally
expensive by design.

  -TT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.softwareradiosystems.com/pipermail/srslte-users/attachments/20170505/327e656b/attachment-0001.html>


More information about the srslte-users mailing list