B part is latched on 4G, but still fall backs to CSFB when call is received

4G LTE
, , , ,
1

Hello VoLTE Experts.

B part is latched on 4G, but still fall backs to CSFB when call is received.

After 3 paging requests, UE falls back.

Reason for fall back is required.

Thanks for support in advance.

""

Admin note: this post was updated with image below.
B part is latched on 4G, but still fall backs to CSFB when call is received

2

Check the VoLTE profile from HSS site, and that no barring is applied in IMS side for this IMSI (if it’s a single user issue).

Also check from Radio side that this issue is not general for the whole cell/site/band.

3

It’s not a single user issue.

It’s random. Like one time in 10 attempt.

HSS profile is OK.

4

When UE attached, did it attach with IMS or not?

Have you checked Attach Accept and see that it has all bearers?

5

If the call successfully comes to terminating party paging state than it means every thing is OK with IMS registration and bearer setup.

You need to focus on the issue that causing the paging failure.

It is normal that IMS triggers a CS Retry if the B party is not reachable over LTE.

6

I don’t think this way.

Paging in LTE is done over paging channel IMS isn’t involved at all at that stage.

The fact that B party triggers CSFB right after CS Service Notification tells me it doesn’t think it has IMSA and only mechanism to connect to call is CSFB.

Do you have UE logs by any chance?

Suggest do a quick drive test with 2 UEs calling each other back and forth, setup UE trace on NW side for both UEs and see whats been happening.

You can get an MME Trace, eNB trace, and UE logs all at same time.

7

Think about E2E call flow: what is the event triggering that paging and what is the path?

IMS → PGW → SGW → eNodeB

Untill IMS it is signalling.

After IMS it is data payload.

1 Like
8

Thank you all!

We have just found out:

UE did not receive paging request.
UE logs show this.
RF quality has issues.
RSRQ is bad.

1 Like
9

As far as I know, IMS doesn’t have mechanism to ‘page’.

It can only send SIP message to PGW, which then triggers the paging in RAN.

If Party B is in idle mode, then the paging will be network paging to wake up the UE and connect.

In this case RRC Request will be MT.

If Party B is in connected mode, then I believe paginG i.e. call alert comes directly on QCI5 and via IMS.

This is very good breakdown of entire call flow:

In your original post you said “B part is latched on 4G, but still fall backs to cfsb when call is received. After 3 paging requests”

If paging isn’t successful how does UE know it has to fallback to connect to voice call?

Paging and CSFB are 2 separate mechanism.

I think you should still check UE attaching to IMS network fine at initial attach.

If that is correct, then check what is happening after it receives correct paging message.

1 Like
10

Thanks for sharing this is explaining my statement very well.

This :point_up:

And this :point_up:

SIP message is signalling that triggers paging over Packet Core network, because it is a data payload after PGW.

What I say is, if that SIP message is triggered all the call handling is completed on the IMS side and there is a valid IP contact for UE over IMS APN.

I never said IMS has a paging mechanism. :wink: