Timer on eNodeB to delete the data for a specific UE

Hi Experts,
In LTE, let’s say that there is a userplane path between UE and a server.
Server is injecting the data but because of a severe radio problem, data is unable to pass the data from eNodeB buffer to the UE.
Then since server goes on to send the data, is there any timer on eNodeB to delete the data for a specific UE since it is not able to send it to destination (I am aware of tcp/udp congestion control part, I am interested in how eNodeB behaves in this specific situation).
Thanks in advance to all.
I am trying to understand behaviour of the network in fact, not only the the timer existence.

Oncoming data rate to eNB from server will be managed by TCP window I guess.
Secondly in packets are in PDCP buffer for longer time then, it will be discarded after discard timer.

Other experts can add here.

What is the PDCP discard timer being used, do you know?

In LTE for non gbr we place high value and for gbr and 100 to 150ms.

Is it possible that eNB discards the data after max retransmission is attempted for this specific data which may be a value lower than pdcp discard timer?

Packet gets lost in pdcp itself if value is low but drawback is delay requirement.
So GBR is low.
High value helps us not to loss excessive pcp packets.
But delay increases so GBR is kept low.
High packet can lead to losses so thats too depend on rf and transmision.

I see @parkarnadeem86, thanks so much.

Do you know what happens if delay requirement (or qos) lets say for VoLTE call cannot be maintained, is the call dropped?

There’s not a single VoLTE call drop in the whole world for packet delay or packet lost.
It will be mute call, or distorsions, or metallic voice, or similar simptoms.
Call is released when IMS RTP packets are missing for 10-15 seconds.
Only then you will see SIP BYE.
It is a GBR bearer VoLTE but RAN is not granting actually any guaranteed bit rate. It’s just naming :slight_smile:
Scheduler works on best effort principle. Even the rate is not assured call is not released but it works with a lower rate.

Then where is the QoS that is promised for VoLTE calls?
I thought that QoS must be provided if not may be there should be SRVCC.
But you said something different from my understanding.interesting.
But very important point, thanks.
Is it possible that coded renegotiation takes place in such cases to lower the data rate?

Possible but not implemented due to high risk of drop call during code change.
There are feature to triggers srvcc when packet loss is higher than 60% for 2 seconds for example.
But this is also not implemented.
There is also interfreq ho triggered by quality and this is also not implemented.
Because it needs gaps and gaps are risky and reduce quality even more.

Yes, I came across this in too many times, rtp timeout case.