Feature #6108
closed
Feature #5500: MS-Side GPRS RLC/MAC implementation
libosmo-gprs-rlcmac: Bug in CV calculation ending with last message as CV=1
Added by pespin 10 months ago.
Updated 10 months ago.
Description
I just spotted a case where the CV calculation ends up with CV=1 in the last message BSN=9, and hence osmo-pcu keeps asking for more packets (the last one) and "modem" app keeps resending the last BSN=9 one (which is CV=1, not 0).
So it seems the algo calculating the number of packets ahead based on llc queue has a bug not counting properly in that case. I'm attaching a pcap file with the scenario and the packets being sent.
It seems the algo estimates a number of packets needed higher than the one actually needed. May be related to the congestion resolution not requiring TLLI transmission anymore? we need to check if we are recalculating in that scenario.
the CS requested by Imm Ass is CS4 and we are using CS4 all the time. Maybe somehow the PCU updates the tx CS in the middle? it show up in the pcap file.
Files
- Status changed from New to In Progress
From the pcap it can be seen the LLC PDUs, but it doesn't print the radio prio nor SAPI:
55 14:20:03.820090877 Jul 21, 2023 16:20:03.820090877 CEST 127.0.0.1 36634 127.0.0.1 4729 GSMTAP 205 TBF(UL:NR-41:TLLI-e2c4feea) Entering Countdown procedure CV=10
56 14:20:03.820111695 Jul 21, 2023 16:20:03.820111695 CEST 127.0.0.1 36634 127.0.0.1 4729 GSMTAP 196 TBF(UL:NR-41:TLLI-e2c4feea) Dequeue next LLC (len=94)
99 14:20:03.864028302 Jul 21, 2023 16:20:03.864028302 CEST 127.0.0.1 36634 127.0.0.1 4729 GSMTAP 196 TBF(UL:NR-41:TLLI-e2c4feea) Dequeue next LLC (len=94)
155 14:20:03.899222766 Jul 21, 2023 16:20:03.899222766 CEST 127.0.0.1 36634 127.0.0.1 4729 GSMTAP 196 TBF(UL:NR-41:TLLI-e2c4feea) Dequeue next LLC (len=94)
194 14:20:03.921779777 Jul 21, 2023 16:20:03.921779777 CEST 127.0.0.1 36634 127.0.0.1 4729 GSMTAP 196 TBF(UL:NR-41:TLLI-e2c4feea) Dequeue next LLC (len=94)
260 14:20:03.981266758 Jul 21, 2023 16:20:03.981266758 CEST 127.0.0.1 36634 127.0.0.1 4729 GSMTAP 196 TBF(UL:NR-41:TLLI-e2c4feea) Dequeue next LLC (len=94)
I submitted this patch to improve logging what's enqueued in the llc_queue:
https://gerrit.osmocom.org/c/libosmo-gprs/+/33887 rlcmac: Log LLC PDUs enqueued in llc_queue
Also some small fixes/improvements:
remote: https://gerrit.osmocom.org/c/libosmo-gprs/+/33888 rlcmac: ul_tbf: Move logic selecting proper queue to helper function [NEW]
remote: https://gerrit.osmocom.org/c/libosmo-gprs/+/33889 rlcmac: Avoid discard packets when in Countdown procedure [NEW]
What I think really needs to be done before fixing this issue:
- Recalculate CV (or get out of Countdown procedure, is that possible?) whenever we receive a change of tx CS (I don't even think that's implemented yet?)
- Recalculate CV whenever we succeed over contention resolution (right now we have gprs_rlcmac_ul_tbf_in_contention_resolution() which checks different stuff, but we don't have any code path being triggered when any of those conditions happen, aka when contention resolution succeeds).
- Status changed from In Progress to Resolved
- Assignee set to pespin
- % Done changed from 0 to 100
I haven't seen this problem since I implemented the 2 recalculate options mentioned above.
Closing the ticket.
Also available in: Atom
PDF
