Hi Gents,
Recently we have enabled service based handover for VoLTE services from TDD to FDD carriers, and as my understanding this HO will be made at initial context.
In this case we should have zero VoLTE traffic on TDD carrier? (Please correct me if I am wrong)
But we still have few traffic carried.
Any idea why we still have some traffic?
What do you mean by “few traffic carried”?
I mean few VoLTE traffic.
It’s reduced by almost 85% after service based HO.
Have you considered multi RAB situation?
But service based will make the HO whenever there is request for QCI 1.
Even if there is multi RAB.
What are the SB HO threshold you configured?
2 reason can be there.
- Even though service based HO parameters are configured at initial context, actual HO may take some time. Depend upon time for UE reporting MR and HO preparation time.
- For some users, HO preparation may get failed due so many reasons like CAC faulure, nbr blacklisted etc. So volte traffic may exist in TDD.
We have configured below set of THDs:
- A4 RSRP -103
- A4 waiting timer 10000 ms
If taget FDD do not satisfy A4 threshold HO will not happen.
So VoLTE call continues in TDD.
Try making A4 more relax value like -110 dBm?
Not tried. I will try it for some cells and let you know.
If you want, i can give one more solution but it is bit risky:
Instead of service based HO, implement service based redirection.
Here VoLTE traffic becomes alsmost zero.
But here, you must have sufficient coverage of redirected carrier.
Service Based HO may not clear up 100% of the traffic.
You may not find a suitable neighbor to redirect the traffic, and you may have incomingo HO as well.
For both, usually the feature try again periodically to perform the HO.
Be aware you will likely to increase VoLTE drop with SBHO.
Or at least, increase reestablishments and etc… causing MOS impact.
Thank You, this would be great also.
And in term of coverage our TDD coverage relatively less than FDD which will not be an issue.
What do you mean by Service Based REDIRECTION?
Yes got it, Thanks.
Once initial context established.
Make redirection to taget FDD.
GBR bearer is preserved in this case.
For drop it didn’t affected too much as we don’t have much traffic before.
Once the UE establishes the QCI1, the eNB will send a rrc release with the target carrier?
Wouldn’t this severely impact the call setup?
Not at all.
Once QCI -1 is established your call is already setup.
You are waiting for sending or receving SIP 200 OK.
That you can easily get once you are connected.
I did not observe any call setup delay or failure.
Not really, vast majority of the operators I’ve worked at work with preconditions, QCI1 comes right after the Trying/Session Progress.
It will take a loooong time between QCI1 be established and the call being connected (200 OK for INVITE).
Something like this for MO:
Early media is also a key factor for early establishment of QCI 1.
That’s why I asked about call setup impact, you may screw up everything that comes after QCI1 establishment, resulting in either lost and/or delayed SIP messages.
If you have this logs in tool you can see that SIP messages followed by QCI-1 are received in very short time.
If UE release before they arrive at UE, they are buffered and send to UE after it gets connected.
Now average delay in getting relased with redirect and getting connected again is not more than 300ms as per my field test.
So actual call setup delay is negligible.
But as i said above, there is risk in this implementation.