Hi LTE Huawei Expert.
Are cells fully utilized PRBs for VoLTE users or is there is parameter to reserve PRBs for data users?
UlVoipPreAllocationSwitch: Indicates whether to perform preallocation for VoLTE UEs during talk spurts when the number of RRC_CONNECTED UEs exceeds 50 in a cell. Voice preallocation is performed only if this option is selected.
Thanks for your response.
Can we set ratio threshold between LTE Data & VoLTE UE, based on PRB?
VoLTE is GBR.
Guaranteed bit rate.
That means eNodeB always schedule first VoLTe and remaining PRBs ( if any) will go for data
One cannot reserve PRBs for data as long as there are VoLTE UEs unscheduled.
I think you already agree that GBR is just for name sake.
On congested NW GBR UE startvation is one of big issue causing voice muting.
Basically, its not like first all GBR candidates will be scheduled and then NGBR.
But there are scheduling priorities defined per service type.
Like first GBR retrans > SRB retrans > GBR initial > SRB Initial > UL grant for SR > HAQR retrans > Initial NGBR.
Furthermore, this priority flow can be altered on specific congestion scenario
Idea is that GBR does not guarantee a rate. But it will guarantee scheduling for all VoLTE UEs.
As long as admission control let the UE in, they will be scheduled.
Now think about what happens if all UEs move from good RF into bad RF requiring more PRBs.
Some GBRs will have to be dropped but for sure NGBR will still not be scheduled.
This is also debatable point.
Scheduling delay is as higher as 400ms in few congested NW.
Still scheduler will work scheduling 100 percent of PRBs for VoLTE.
Nothing for data.
If New UE enter/connected on VoLTE Call then they will get PRBs from existing Data PRB not VoLTE UEs PRB.
I dont think its 100%.
SRB retransmisison have higher scheduling priority than GBR initial transmission.
And its logically correct.
SRB retransmission is not data, we were discussing about data scheduling.
Umm… OK
Samsung implementtaion is:
Even though its 100% congested situation, of TTI can allocate 16 users , 8 allocation are reserved for GBR, remaining for NGBR/SR.
I never observed TTI with all 16 candidates from GBR.
Like I said, I would like to see a parameter that reserves PRBs for data while VoLTE is in congestion lacking PRBs.
I do not think that parameter exists.
Read it this way: if 8 GBR VoLTE consumes all PRBs each TTI would you schedule any data?
Practically, GBR users do not starve because of PRB starvation, but they starve because lack of CCEs.
It depends if VoLTE users are in good RF or bad RF.
I agree that AL8 is demanding for PDCCH.
Scheduler want to utilise max CCE and pRB capacity.
If there are 50 CCE available for example, contrbuting 20% PRB utilization, scheduler can skip few VoLTE users for upcoming TTIs, and can add good RF data users to maximise PRB utilization.
That means VoLTE scheduling is not a must at that TTI for some VoLTE users and so there is no congestion concept in this case.
CCE congestion is there. But scheduler decide to delay scheduling for some VoLTE users , to increase PRB utilization, and hence spectral efficiency.
It all depend upon vendor implementtaion.
For some vendors, whatever you are saying may be correct.
Imagine this: you have max 8 GBR users per TTI.
Imagine that every 1 msec you have to schedule for volte different 8 users.
With 20msec RTP periodicity it means the scheduler can handle theoretically 160 VoLTE users.
Where would be room for data in this case?
I agree that this is a particular case but scheduler can be in trouble even with 7 VoLTE users per TTI or even with 6 VoLTE users per TTI.
I have not seen any parameter to book PRBs for data while VoLTE would be starving.
I have seen such cases also at the public events.
Scheduler never allocate all GBR candidates in a TTI.
And VoLTE scheduling delay is introduced by scheduler.
This is to maintain spectral efficiency.
There is trade off here.
Right. We cannot book PRBs to data.
But we can give upper limit to voice user booking.