Hi experts, I have a doubt and would appreciate some help.
For RLC AM traffic, PDCP t-Reordering is set to 200ms, while at the RLC level, tPollRetransmit is 40ms with maxRetx set to 32. This means that RLC packet recovery can take up to 1280ms, whereas the PDCP waiting timer is only 200ms.
Does this mean that, to fully utilize the RLC retransmissions, the PDCP timer needs to be increased to 1.3 seconds?
If the RLC retransmission process can take up to 1280 ms, but the PDCP timer is set to 200 ms, there is a mismatch. The PDCP layer may discard packets after 200 ms, even though the RLC layer is still attempting retransmissions.
To align these layers, the PDCP timer should be increased to at least 1280 ms or slightly higher to ensure that the RLC retransmission process completes before PDCP discards packets. This adjustment helps prevent premature packet loss at the PDCP layer due to timer expiration.
Thanks! I’m thinking the same.
The feedback provided here is not entirely accurate. It seems the response assumes the question is about the PDCP discard timer at the transmitter side, not the PDCP reordering timer at receiver side. Aligning the PDCP reordering timer with the total time required to complete all RLC retransmissions could lead to serious issues(disaster) in E2E latency and even throughput performance — especially in scenarios involving multiple TCP streams.
Take care guys, that’s not correct.
This will lead into a network damage if you increased the timer to match the RLC retransmission time.
So, @Mohamedeladawi, what is your view here than? Is it true the statement that 32 RLC retransmissions doesn’t have the point with receiver PDCP t-Reordering set to 200ms?
Also, what is your view about increasing for vonr PDCP discard timer from 150 to 200ms while PDCP t-Reordering is set to 60ms? Should increase 150 to 200ms imply increasing of t-Reordering to higher value also?
Yes, the 32 RLC retransmissions are not directly related to the receiver-side PDCP t-Reordering timer. Typically, the t-Reordering timer is designed only to account for all possible HARQ retransmission attempts, and a value of 200ms is usually more than sufficient. For example, in 4G networks, the reordering timer was often set to just 50 or 60ms.
To explain this with a practical example: imagine a user initiating three TCP connections simultaneously—TCP Stream 0 for an FTP download (a heavy file), TCP Stream 1 for browsing Facebook, and TCP Stream 2 for Instagram. If out-of-sequence data is observed in TCP Stream 0 and that data is held for a long time in the PDCP receiver due to reordering, the application services for the other two TCP streams will also be affected. The user may not be able to access the web at all during this time, as the receiver waits for the RLC retransmission to complete.
In such cases, it is better to allow the PDCP layer to forward the out-of-sequence data instead of holding it indefinitely. TCP is capable of handling retransmissions at the transport layer, and letting it do so helps avoid application-level service delays.
Regarding the second point, you’re referring to VoNR services, which primarily use UDP. As you know, UDP does not perform retransmissions, so there’s no real risk associated with delivering out-of-sequence packets to the UDP layer.
However, increasing the PDCP t-Reordering timer too much for Circuit-Switched (CS) type services may lead to issues such as silent calls—particularly during periods when the PDCP layer is holding data. A timer value of around 60ms is generally sufficient to account for all HARQ retransmissions, and it’s worth noting that VoNR does not use RLC retransmissions.
On the other hand, increasing the PDCP discard timer to 200ms is a reasonable approach, as it aligns with the typical round-trip delay budget for VoNR services.
All of this is based on my personal understanding. However, I can confidently say that matching the PDCP reordering timer with the full RLC retransmission duration, as suggested earlier, can lead to performance issues and missed expectations in the network.
