Feature #2410
closedallow disabling of "preemptive acknowledgements"
0%
Description
Normally, when a MS is sending Uplink Blocks to the PCU, the PCU only needs to acknowledge one the countdown value (CV) reaches 0. As per spec, CV=0 triggers a PACKET-UPLINK-ACK-NACK in the downlink direction.
OsmoPCU however already transmits PACKET-UPLINK-ACK-NACK when receiving blocks with CV>0, causing way more PACKET-UPLINK-ACK-NACK occupying downlink blocks than needed for signaling. It is also doubtful if they server much purpose, given that the MS cannot retransmit any missing blocks any faster, as it is still busy performing the initial/first transmission of each RLC-block of one LLC-PDU as fast as it can, given the USF allocations.
Furthermore, it is conceivable some phones might react strangely to such early preemptive ACKs. I have no evidence, but a switch to disable this feature would be something we could try whenever we see strange behavior of certain MS.
Finally, they make protocol traces significantly harder to read.
So IMHO, at least there should be an option to disable those preemptive acknowledgements.
Updated by laforge over 6 years ago
- Status changed from New to Rejected
I think my observation was wrong. We send the acknowledgements in the case I was looking at because the MS was including the TLLI in uplink. The network is required to send an UL-ACK-NACK in such cases as part of the contention resolution.
The important part learned is:- single-phase assignments reduce latency but cost more as they include TLLI (reduce RLC block size) and lead to many more UL-ACK messages in downlink
- two-phase assignment has higher latency, but improves throguhput (no TLLI, less UL-ACK).
