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
Mon Nov 25 07:24:27 UTC 2013


Holger Hans Peter Freyther wrote:
> Hi,
>
> I have added rate counters to the PCU and noticed that a lot of frames
> in the DL are re-sent without there actually being any NACK or
> transmission errors. 
dear holger,

i can only guess what causes the issues you describe. so i suggest that
we should do a debug session at the congress, if you attend to it and
find the time.

generally there is always a re-send due to delay between pcu and the
radio interface. if all rlc/mac data blocks of an llc frame have been
sent to the phone, a packet downlink ack control block is requested and
scheduled. the pcu repeats all unacknowledged data blocks in a loop
until it receives that requested control block. this way the pcu starts
re-sending data blocks that might got lost, before it actually knows if
and which blocks still need to be resend. (this procedure is described
in TS 04.60.)
> I have also re-produced a "stall" by just using
> ping with a big enough data size and a low enough interval (the PCU
> appears to transmit the ICMP PING but the MS never gets to send a PONG
> packet).
>   
could this be an mtu issue at the phone? does the phone requests an
uplink tbf to send a pong?
> In both cases it could be a scheduling issue (e.g. we don't schedule
> the UL Packet ACK/NACK).
in case of an ongoing uplink tbf, we ack/nack received or timed out
uplink rlc/mac blocks by using a control block. even if there is an
ongoing downlink tbf, all control blocks have priority over data blocks.
> Is any of you aware of it? I had already
> highlighted that the scheduling is not fair. I wonder if we are seeing
> starvation (and will re-factor to be able to unit test this).
>
> In terms of scheduling. For the SBA we are already having a reservation
> that we try to honor in multiple places. Maybe it is time to extend it
> and have more reservations?
>   
uplink control messages are reserved in the tbf object (poll_fn). the
sba control messages are reserved in a separate structure, since sba are
not (or not yet) related to a tbf.

regards,

andreas






More information about the osmocom-net-gprs mailing list