Ask Your Question

Decoding LTE MAC Scheduling Request (SR) packets

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

mozart gravatar image

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

Guy Harris gravatar image

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

2 Answers

Sort by ยป oldest newest most voted

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

MartinM gravatar image

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

I have uploaded and merged

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 more


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 gravatar imageMartinM ( 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 gravatar imagedmouscher ( 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 gravatar imageMartinM ( 2018-07-26 16:59:10 +0000 )edit

answered 2018-07-25 06:42:53 +0000

Pascal Quantin gravatar image

Hi, No there is no way to do this without recompiling as this OOB events is not supported by the UDP framing protocol right now.

I will add a new tag when I'm back from vacation (in two weeks from now).

edit flag offensive delete link more


I will try to add it before then.

MartinM gravatar imageMartinM ( 2018-07-25 20:17:10 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


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

Seen: 597 times

Last updated: Jul 26 '18