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