UL/DL Mode, statistic logs, error protection, subtree srsRAN

[bstevens777]

Dear @hdtuanss,
Sorry, this took so long to get set up.

This is @cellular777 I had to do this on a work account (bstevens777).

There are some things you likely will not want. I subtree'd LTESniffer, srsRAN etc.
This led me to need to rebase off v2.0.0 which is where I made these changes.

Let me know what you may need help with. I will reach out on twitter shortly.

cellular777/bstevens777

[hdtuanss]

Hi @bstevens777,
No problem, the wait is worth it. I appreciate your significant contributions to improving LTESniffer.
I have reviewed your pull request and will work on it this weekend, as I am currently occupied with other tasks. I will contact you soon.
Thank you

[bstevens777]

@hdtuanss no worries. I also reached out to you on X so let me know if you need something there if it is easier.

I saw you are doing Ph.D studies. I just finished my doctorate a few months ago. I wish you the best of luck. It is a grind.

review again

[hdtuanss]

merge to develop branch

[alphafox02]

Builds fine on 22.04 with stock gcc11, but with gcc12 there’s a few errors preventing it from building. Confused me for a second till I switched over to another Pc with gcc11 and then I realized what was going on. I plan to test the develop build with an x310 asap.

[cellular777]

I found a few issues:

I ended up turning API off, as that was working but I was not getting UL/DL stuff. This is the command I am running:
./src/./LTESniffer -a clock_source=external,time_source=external -A 2 -W 16 -f 1982.5e6 -u 1902.5e6 -C -m 2

• File Timestamps: I highly recommend adding the date/timestamp to the file name that was in the pull request. So you can go back and see results from different runs.

• RNTI Lock: Originally I had suggested RNTIManager.cc to have locks around accessing the manager, with these in place no DL/UL results are found. Thought the API stuff does get tracked correctly. I am unsure why, but I think the manager starts missing things when it has locking involved. I recommended changing the manager to a "map" and that seems to stop the majority of the segfaults but keeps the detections happening. I would remove those rnti lock checks
  Essentially going from:

            --------------------------------------------------------------------------------------
[19:25:15]: Num  RNTI     Max Mod     Active   Success  SNR(dB)  DL-UL_delay(us)   Other_Info
            --------------------------------------------------------------------------------------
            --------------------------------------------------------------------------------------
[19:25:15]: Num  RNTI     Max Mod     Active   Success  SNR(dB)  DL-UL_delay(us)   Other_Info

[256Tracking] Total:      0 RNTIs are 64QAM table,      0 RNTIs are 256QAM table,     0 RNTIs are Unknown 

to:

            --------------------------------------------------------------------------------------
[19:31:48]: Num  RNTI     Max Mod     Active   Success  SNR(dB)  DL-UL_delay(us)   Other_Info
            --------------------------------------------------------------------------------------
            --------------------------------------------------------------------------------------
[19:31:48]: Num  RNTI     Max Mod     Active   Success  SNR(dB)  DL-UL_delay(us)   Other_Info
            1    871      Unknown     1        0        1.74     +2.77             0        
            2    4469     Unknown     2        0        1.18     +2.74             0        
            3    4726     Unknown     10       0        1.41     -1.03             0        
            4    7542     Unknown     1        0        1.1      +2.62             0        
            5    11123    Unknown     3        0        1.34     -0.691            0        
            6    14904    Unknown     3        0        1.22     -0.159            0        
            7    16752    Unknown     6        0        1.35     -1.43             0        
            8    18250    Unknown     18       0        1.23     -2.48             0        
            9    20035    Unknown     1        0        1.5      +6.38             0        
            10   25947    Unknown     14       0        1.3      -0.178            0        
            11   28472    Unknown     11       0        1.35     +0.503            0        
            12   29007    Unknown     9        0        1.17     +1.4              0        
            13   33836    Unknown     267      0        1.26     +0.437            0        
            14   44126    Unknown     7        0        1.3      -2.82             0        
            --------------------------------------------------------------------------------------
[256Tracking] Total:      0 RNTIs are 64QAM table,      0 RNTIs are 256QAM table,     14 RNTIs are Unknown 

• In PDSCH, if the 2x lines "if (pdu.get()->is_sdu() && pdu.get()->get_sdu_lcid() == 0)", I get stack smashing when the second condition occurs. I have to change it to if (pdu.get()->is_sdu()) to stop that from happening after running about 10 seconds. There is likely a better way to fix this, but I do not understand the code added for "lcid"
  Error I get

Thread 5 "LTESniffer" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffd6450700 (LWP 33023)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) trace
Tracepoint 1 at 0x7ffff677de87: file ../sysdeps/unix/sysv/linux/raise.c, line 51.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff677f7f1 in __GI_abort () at abort.c:79
#2  0x00007ffff67c8837 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff68f5869 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007ffff6873b31 in __GI___fortify_fail_abort (need_backtrace=need_backtrace@entry=false, msg=msg@entry=0x7ffff68f5847 "stack smashing detected")
    at fortify_fail.c:33
#4  0x00007ffff6873af2 in __stack_chk_fail () at stack_chk_fail.c:29
#5  0x0000555555609561 in PDSCH_Decoder::run_decode (this=<optimized out>, mimo_ret=<optimized out>, cur_format=<optimized out>, cur_ran_dci_dl=<optimized out>, 
    cur_grant=<optimized out>, cur_rnti=49255, table=..., RNTI_name=..., tti=<optimized out>) at /home/test/LTESniffer/src/src/DL_Sniffer_PDSCH.cc:360
#6  0x0000000000000000 in ?? ()

After changing these things the program runs for hours and correctly get DL/UL statistics, along with API stats.

[cellular777]

as a follow on, with main I can lock the RNTIManager like you did, unsure why this works but dev doesn't. But if I get enough RNTIs then the manager starts getting locked and I start dropping subframes. The more processing or RNTIs that occur the worse things start to drop out.

--------------------------------------------------------------------------------------
[21:04:14]: Num  RNTI     Max Mod     Active   Success  SNR(dB)  DL-UL_delay(us)   Other_Info
--------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------
[21:04:14]: Num  RNTI     Max Mod     Active   Success  SNR(dB)  DL-UL_delay(us)   Other_Info
            1    14651    Unknown     166      0        1.26     -0.256            0        
            2    14904    Unknown     3        0        1.08     +2.01             0        
            3    16752    Unknown     9        0        1.2      +1.01             0        
            4    26968    Unknown     73       0        1.25     +0.872            0        
            5    33347    Unknown     11       0        1.41     -0.421            0        
            6    34607    Unknown     27       0        1.27     +1.69             0        
            7    36416    Unknown     3        0        1.43     -2.61             0        
            8    41809    Unknown     7        0        1.42     -1.21             0        
            9    45379    Unknown     1        0        1.07     -9.25             0        
            10   47173    Unknown     195      0        1.27     -0.251            0        
            11   52311    Unknown     1        0        1.05     -1.15             0        
            12   53573    Unknown     1        0        1.18     +8.68             0        
            13   53830    Unknown     1        0        1.31     +17.8             0        
            14   58480    Unknown     357      0        1.29     +0.16             0        
            15   59507    Unknown     360      0        1.3      -0.123            0        
            16   62292    Unknown     1        0        1.27     +10.4             0        
--------------------------------------------------------------------------------------
[256Tracking] Total:      0 RNTIs are 64QAM table,      0 RNTIs are 256QAM table,     16 RNTIs are Unknown 

[New Thread 0x7fffceb12700 (LWP 54834)]
[Thread 0x7fffceb12700 (LWP 54834) exited]
[21:04:15] Processed 1000/1000 subframes
Skipped subframe: 2693 / 281007
Skipped subframes: 2693 (0.96%)
[21:04:16] Processed 988/1000 subframes
Skipped subframe: 2705 / 282007
Skipped subframes: 2705 (0.96%)
[21:04:17] Processed 1000/1000 subframes
Skipped subframe: 2705 / 283007
Skipped subframes: 2705 (0.96%)
[21:04:18] Processed 1000/1000 subframes
Skipped subframe: 2705 / 284007
Skipped subframes: 2705 (0.95%)
[21:04:19] Processed 997/1000 subframes
Skipped subframe: 2708 / 285007
Skipped subframes: 2708 (0.95%)
[21:04:20] Processed 918/1000 subframes
Skipped subframe: 2790 / 286007
Skipped subframes: 2790 (0.98%)

However, if I do the RNTI locks like main and use a map this issue doesnt happen. Was the below for 5 minutes. maps have faster access and it just requires a few call changes that are list based.

Skipped subframe: 92 / 277016
Skipped subframes: 92 (0.03%)