[srslte-users] pdsch_ue question

[Ismael Gomez]

Hi amr,

On Tue, 17 May 2016, 20:22 amr adel, <amr.adelnasr at gmail.com> wrote:

> Hi Ismael,
>
> I am using pdsch_ue and was trying to capture all uplink grants (DCI0
> messages) sent by the enodeB
> For that, I have done the following modifications:
>
> 1-In ue_dl.c I added the definitions for the 2 structures:
> "srslte_ra_ul_dci_t" and "srslte_ra_ul_grant_t"
> 2-In the same file I used the 2 functions: "srslte_ue_dl_find_ul_dci" and
> "srslte_dci_msg_to_ul_grant"
> 3-Since I don't know the specific CRNTIs in advance, I added a for loop in
> pdsch_ue to scan all UE CRNTIs range from: 0x003D - 0xFFF3
>
> I have the following observations:
>
> 1-When going through the UE specific search space, aggregation level 8
> (L=3) was not showing
> I found that in pdcch.c in the function: srslte_pdcch_ue_locations in the
> for loop going through l=0:3, the 3 was preceded by a less than symbol. So,
> I had to modify it to less than or equal to include (L=3) --> aggregation
> level 8
>

We just spotted that earlier today and updated the master branch in github.
Thanks for spotting that though.


> 2-Two different CRNTIs had the same uplink grant as follows:
>
> [INFO]:  Attempting DL decode System Frame = 0, Sub-frame = 2 , RNTI =
> 17193
> [INFO]:  Decoded CFI=1 with correlation 44.51, sf_idx=2
> Decoded DCI: nCCE=0, L=0, msg_len=28, mean=1.388349, crc_rem=0x4329
> [INFO]:  prb1: 49, prb2: 49, L: 6
>  - Resource Allocation Type 2 mode : Localized
>    + Frequency Hopping: No
>    + Resource Indicator Value: 549
>    + VRB Assignment: 6 VRB starting with VRB 49
>  - Modulation and coding scheme index: 2
>  - New data indicator: Yes
>  - Redundancy version: 0
>  - TPC command for PUCCH: --
>  - Number of PRBs: 6
>  - Modulation type: QPSK
>  - Transport block size: 256
>
> and
>
> [INFO]:  Attempting DL decode System Frame = 0, Sub-frame = 2 , RNTI =
> 5188
> [INFO]:  Decoded CFI=1 with correlation 44.51, sf_idx=2
> Decoded DCI: nCCE=0, L=1, msg_len=28, mean=1.347141, crc_rem=0x4329
> Decoded DCI: nCCE=2, L=1, msg_len=28, mean=1.399216, crc_rem=0xe313
> Decoded DCI: nCCE=4, L=1, msg_len=28, mean=1.385574, crc_rem=0x3d56
> Decoded DCI: nCCE=6, L=1, msg_len=28, mean=1.331550, crc_rem=0x9724
> Decoded DCI: nCCE=0, L=2, msg_len=28, mean=1.373178, crc_rem=0x4329
> Decoded DCI: nCCE=4, L=2, msg_len=28, mean=1.358562, crc_rem=0x4be2
> Decoded DCI: nCCE=0, L=3, msg_len=28, mean=1.365870, crc_rem=0x1444
> [INFO]:  prb1: 49, prb2: 49, L: 6
>  - Resource Allocation Type 2 mode : Localized
>    + Frequency Hopping: Yes
>    + Resource Indicator Value: 549
>    + VRB Assignment: 6 VRB starting with VRB 49
>  - Modulation and coding scheme index: 2
>  - New data indicator: Yes
>  - Redundancy version: 0
>  - TPC command for PUCCH: --
>  - Number of PRBs: 6
>  - Modulation type: QPSK
>  - Transport block size: 256
>
> Also, can you explain what does "[INFO]:  prb1: 49, prb2: 49" prb1 and
> prb2 refer to ?
>
> 3-Further more I inspected the binary dci messages of the reported CRNTIs
> with DCI0 messages, and found some of them don't make sense. For example
> one CRNTI had the following reported DCI0 binary message
> : 0010110010111110000111101111
> It is 28 bits in length which is fine. The bandwidth is 20 MHz so the last
> bit in this message should be a padding bit (i.e. should be a 0)
> This way I think that going through the whole CRNTI range and trying to
> extract the DCI0 messages might give unrealistic ones. Hence, I believe I
> should add a check to discard such messages
>


Yes, there is a fundamental problem with the way you are trying to
implement the sniffer (by brute force). In principle any CRC can be a valid
RNTI because both have the same size. Thus you need to know if an rnti is
active in the cell before attempting to decode a dci message. This is why
you are seeing invalid grants. You can add a check as you mentioned, but
you will still find lots of false positives.

If you are looking for an LTE sniffer that gives grants in real time
contact me in private and we might be able to help you.



> 4-One last thing, I could not go through the whole range of CRNTI in the
> pdsch_ue. I was monitoring RAM usage and I notice that memory consumption
> would grow linearly with iterations. I tried to include the command
> "srslte_ue_dl_free(&ue_dl);"  at the end of each iteration but still wasn't
> successful (RAM consumption would grow to 100% and the pc would freeze
> before ending the RNTI range). Any ideas what is so memory consuming and
> that grows with iterations ?
>

Thanks for spotting that again. In general, only the functions *_init()
allocate memory so you shouldnt use them in the loop. If you send me your
code I'll look into it more carefully.


> Thank you,
>
>
> --
> Amr Abdelnasser
>

Cheers

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20160517/eb7c23d1/attachment.htm>