Decoding LTE MAC Scheduling Request (SR) packets

asked 2018-07-24 15:55:56 +0000

mozart
3 ●1

updated 2018-07-24 17:25:54 +0000

Guy Harris
19890 ●3 ●660 ●207

How could one decode Scheduling Request (SR) packets on wireshark thorugh mac_lte_logger.c? I have been modifying the mac_lte_logger.c file and there does not seem to be a tag through packet-mac-lte.h that I can use to show if a scheduling request event has been made. The closest one I could find was the MAC_LTE_SEND_PREAMBLE_TAG which shows the RACH and RAPID values, but I would like to see the physical layer scheduling request. Is there a workaround that would allow me to do this without recompiling the packet-mac-lte.c file with a new case for a new tag?

Thank you for your help!

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2018-07-25 21:54:27 +0000

MartinM
197 ●15 ●10

updated 2018-07-26 10:10:37 +0000

I have uploaded and merged https://code.wireshark.org/review/#/c...

Could you either try it, or send me a capture file? The format after the tag is <num_items> followed by a pair of <ueid> <rnti> for each entry. All fields are 2 bytes, network-order.

edit flag offensive delete link

Comments

Updated/fixed after a comment from Pascal.

The other thing to bear in mind about the SR event in the dissector, is that it was originally added to mean the request from MAC to start the procedure, rather than individual PHY transmissions at the configured periodicity/offset. You could log it for every transmission, if that is known, but bear in mind that the dissector has a state-machine that might then output some surprising/confusing expert info.

The SR Indication event (also not supported by this framing method) is intended as an indication from the physical layer that the schedule of transmissions was tried but still no grants were received.

MartinM ( 2018-07-26 07:56:35 +0000 )edit

HI Martin, thank you for your help on this. (I'm working on the same project as the OP.)

I'm getting some of that odd expert info that you were mentioning, so I'm mainly wondering right now how to go about avoiding those errors. It seems that the first time I send a packet with an SR tag, I get the error that "SR results in neither a grant nor a failure indication," and that for every subsequent SR packet with the same RNTI, I'm told by Wireshark that this is an invalid SR event since the first request is still outstanding.

Looking at packet-mac-lte.c (and more specifically in the TrackSRInfo function where the first error seems to be happening) I don't see how one would indicate that there has been either a PDCCH grant or a failure at the same as the request itself ...(more)

dmouscher ( 2018-07-26 16:06:37 +0000 )edit

You could disable the preference 'Track status of SRs within UEs', which is on by default.

The SR/grant tracking was useful at the time for checking if our UE implementation was doing anything crazy, and also for showing the UL latency and reduced TCP throughput that a long SR cycle can easily cause.

MartinM ( 2018-07-26 16:59:10 +0000 )edit

add a comment