[srslte-users] PDCCH/DCI Blind Searching

Ismael Gomez ismael.gomez at softwareradiosystems.com
Fri May 5 15:17:55 UTC 2017


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> 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
> 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
> 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>
> 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/5863c1ef/attachment.html>


More information about the srslte-users mailing list