Summary of osmo-pcu failures/defects

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-net-gprs@lists.osmocom.org/.

Andreas Eversberg andreas at eversberg.eu
Wed Nov 27 07:49:17 UTC 2013


Holger Hans Peter Freyther wrote:
> Here is the starvation theory for the ping:
>
> We have a LLC frame (or many queued up)... we schedule the polls and
> at the final_ack indicate we decide to re-use the TBF. This means that
> we will schedule another PACKET DOWNLINK ASSIGNMENT. But at the same
> time we either want to honor the "rh->si" or want to schedule the ACK
> due SEND_ACK_AFTER_FRAMES.
>   
the idea behind priority of PACKET DOWNLINK ASSIGNMENT is that i do not
want the phone to switch back to idle mode. if i would ACK all uplink
blocks, the MS might switch back to idle mode immediately and will never
receive the PACKET DOWNLINK ASSIGNMENT.

when there was an ongoing downlink tbf, the phone keeps in transfer mode
until T3193 fires, so in case of a tbf re-use we can safely schedule a
PACKET UPLINK ACK/NACK prior PACKET DOWNLINK ASSIGNMENT.
> So we more or less want to send "PACKET DOWNLINK ASSIGNMENT" and the
> "PACKET UPLINK ACK" at the same time (with more DL tbfs/traffic this
> is getting more likely) but currently we will always prefer the PACKET
> DOWNLINK ASSIGNMENT. This means that the uplink will starve (e.g. the
> window stalled, rh->si means that the uplink will starve (the window
> will stall, rh->si being set, etc).
>   
once we sent PACKET DOWNLINK ASSIGNMENT we can ACK the uplink blocks
right afterwards. this should resolve the stalled window just a bit
later. this is my theory, but your tests showed that this does not work
as i would expect.






More information about the osmocom-net-gprs mailing list