umts to lte fast reselection

[mirc84]

Hello,

When the UE initiates a CS call in LTE and CSFB to wcdma after the call is ended, the umts instructs the ue to measure the lte freq.
If the call is initiated in wcdma the release message does not contain the lte freq.
This means that UMTS (RNC probably) knows that the call came from LTE. How? Which is the message (IE) ue sets to inform rnc that it came from lte?
Could you tell me in which 3GPP TS is this procedure described (on utran side, the lte side I know: 23.272)

I found RRC CONNECTION REQUEST could set CSFB indicator IE but this is from 3GPP TS 25.331 V9.10 and the phone I used did not sent this IE but the network still knew to send the lte freq at call release.

Thank you!

[incoincov]

Hi mirc84,

do you have ISR (Idle mode signalling reduction) activated?

br!

[incoincov]

Hi again,

one more question: do you have PS HO in parallel with CS fallback?

[incoincov]

What about RAN container?
RAN container is the information which comes originally from eNB that is encapsultated in a container to be deliverd to the RNC with some detailed information

[mirc84]

1. No, I don't think we have ISR activated.
2. Currently our network does not support PS HO but we have redirection.
3.
What about RAN container?
RAN container is the information which comes originally from eNB that is encapsultated in a container to be deliverd to the RNC with some detailed information
Could you tell me what exactly are you talking about?

Extract from TS 25.413 CR1148
• For MO call the UE indicates to the MSC in the 3GPP 24.008 CM SERVICE REQUEST message that this MO call is triggered due to CSFB.
• For MT call, the UE that is subject to paging is camped on LTE, MME sends the SGs SERVICE REQUEST message to the MSC as part of the CSFB procedure.
• For the case that the UE performs CSFB to a different MSC there are flags in the LAU message indicating CSFB MO or CSFB MT call.
SA2 agreed CR0710 on 23.272 (S2-114637) at thier #87 meeting. The agreed CR transfers the knowledge of CSFB triggered call to UTRAN where it can be utilized to make a decision whether a UE at CS call release shall be pushed (back) to E-UTRAN or not.

The change proposed in this CR is to align with the agreed SA2 CR and transfer the knowledge of CSFB triggered call over Iu interface to UTRAN at release of the Iu CS connection, where it can be utilized to make a decision whether a UE shall be pushed (back) to E-UTRAN or not.
It is proposed to add a new IE (end of CSFB) in the IU RELEASE COMMAND message that if included indicates that the Iu CS connection beeing released was initiated due to CSFB.

I found the changes in 24.008 V10.6.1 and the Iu release command with cause End of CSFB in 25.413 V10.6.0.
But I could not find the IEs in the traces I took. Never the less the CSFB with Fast Return works fine. :)
Maybe the RNC has a 6th sense like whirlpool products. :):)

Thanks for your time!

[mirc84]

I want to add that in HEDEX (huawei) I found:
The RNC first determines that a UMTS/LTE UE is a CSFB UE if it meets either of the following conditions:
- PS handover with RELOCATION REQUEST containing IE “CS Fallback triggered” or a CSFB information IE whose value is “CSFB” of “CSFB High Priority”
We do not have PS Handover, only redirection so this does not apply
- RRC Connection Request message does not contain Pre-redirection IE.
I did some calls and even if the mobile is calling without CSFB still the pre-redirection IE is not sent.
- RRC connection Request with CSFB indication
I noticed that only IPhone 4 sends this indication. I didn’t notice it for any other phone (HTC one Samsung s3 s2LTE).
- IU Release command with End of CSFB IE.
RANAP_Iu_Release_Command does not contain this IE. I checked the RNC trace and CN INET trace.

[ninjafine]

Hello,

When the UE initiates a CS call in LTE and CSFB to wcdma after the call is ended, the umts instructs the ue to measure the lte freq.
If the call is initiated in wcdma the release message does not contain the lte freq.
This means that UMTS (RNC probably) knows that the call came from LTE. How? Which is the message (IE) ue sets to inform rnc that it came from lte?
Could you tell me in which 3GPP TS is this procedure described (on utran side, the lte side I know: 23.272)

I found RRC CONNECTION REQUEST could set CSFB indicator IE but this is from 3GPP TS 25.331 V9.10 and the phone I used did not sent this IE but the network still knew to send the lte freq at call release.

Thank you!

Hi Mirc84!
Looks you are using 3G feature "Release with redirect to LTE".
There is an option when it may triggers to LTE after CSFB at channel switch from DCH to FACH or at CS release from state Sp0 or state Speech.

[mirc84]

Thanks ninjafine,

I know about the option. And it works fine.
My problem is, whatever the switch setting, how does the RNC know that my mobile came from LTE so I can send the release message containing the UARFCN and get back to LTE.

In the end I noticed that the Location update contains some information. The reason why I was hard for me to seeit is that the Huawei RNC traces DOES NOT DECODE the hole message. Please see the attached picture. I found this while tracing the same call in INET, which showed me the hole information.

Now, I have another question. I noticed that on some networks, the first RRC connection request message cause is registration and after this the mobile does a location update. While on other networks, the first RRC connection request message cause is originating conv call. Why??

[ninjafine]

Thanks ninjafine,

I know about the option. And it works fine.
My problem is, whatever the switch setting, how does the RNC know that my mobile came from LTE so I can send the release message containing the UARFCN and get back to LTE.

In the end I noticed that the Location update contains some information. The reason why I was hard for me to seeit is that the Huawei RNC traces DOES NOT DECODE the hole message. Please see the attached picture. I found this while tracing the same call in INET, which showed me the hole information.

Now, I have another question. I noticed that on some networks, the first RRC connection request message cause is registration and after this the mobile does a location update. While on other networks, the first RRC connection request message cause is originating conv call. Why??

Hi Mirc84! Don't see any attachment, anyway let's assume 2 scenarios:
Call in LTE -> CSFB -> Call End in 3G -> 3G RRC request originating conv. call (no LAU),
Call in LTE -> CSFB -> Call End in 3G -> 3G RRC request registration for LAU.

First scenario may happens e.g. for MO call. Any MO CS calls the UE fall backs towards the legacy network and discovers a "real" LA. This triggers a LA update before the call is set up. So you don't need LAU after call is ended in 3G.

Second scenario may indicate so calling Inter Working Function for CSFB (MO & MT).
The IWF provides a number of advantages. At the most basic level it is an interface between the MME and the legacy CS network. At the same time it provides a VLR function where all the LTE UEs are registered against. This is done by creating a "virtual" LA and updating the HLR accordingly. Any MT calls are thus routed to the IWF. At the same time it eliminates the need for TA - LA planning as all TAs can point towards this one "virtual" LA.
There is however one drawback with the IWF and that is that every call (MO & MT) requires a LAU before the call is set up. This adds approx. 1 to 2 seconds on the overall setup time. After call ends Ue discovers a "real" LA. This triggers a LA update.

Second scenario may also indicate classic MT CSFB. With the classic MT CSFB, there is an option when LAU is not performed and as such faster call setup times can be achieved. Here you need LAU after call is ended in 3G.

[lq182]

Hello,

When the UE initiates a CS call in LTE and CSFB to wcdma after the call is ended, the umts instructs the ue to measure the lte freq.
If the call is initiated in wcdma the release message does not contain the lte freq.
This means that UMTS (RNC probably) knows that the call came from LTE. How? Which is the message (IE) ue sets to inform rnc that it came from lte?
Could you tell me in which 3GPP TS is this procedure described (on utran side, the lte side I know: 23.272)

I found RRC CONNECTION REQUEST could set CSFB indicator IE but this is from 3GPP TS 25.331 V9.10 and the phone I used did not sent this IE but the network still knew to send the lte freq at call release.

Thank you!
What tool are you using to decode the L3 message? It might be that the tool does not decode that IE since it is quite a new IE. I know that this issue happened on TEMS and XCAL. Just ask your tool support.

[mirc84]

What tool are you using to decode the L3 message? It might be that the tool does not decode that IE since it is quite a new IE. I know that this issue happened on TEMS and XCAL. Just ask your tool support.

We are using Huawei LMT for traces. We noticed that inside the Initial_UE_Message for LAU there are some fields which are not decoded which refer to CSFB MO/MT. Nevertheless, this message is transparent for RNC so it is not this one.
Regarding the other IEs mentioned above it seems they are indeed not sent by the network (upgrade is necessary).

In the end we solve it together with Huawei suport. They are using a smart trick to recognize the CSFB calls.
For us it seemed reasonable. We also re-tested and it seems that the phone does not send the pre-redirection IE if it is forced in UMTS. If it is not forced in UMTS, it actually sends the pre-redirection IE.

"Pre-redirection" is a optional IE, it is firstly imported in 3GPP R8.6.0,3GPP R9.4.0 protocol describes it as follows:
-The way that recognize the CSFB users through this "Pre-redirection" IE should satisfy three conditions :
- The UE supports LTE
- UE sends RRC CONNECTION REQUEST with V860 Structure, but without "pre-redirection" IE.（we can think the user is redirected from LTE to UMTS ,if without "pre-redirection" IE ）
- UE can build CS service in 10s after building RRC connection successfully

Because the Pre-redirection is a optional IE, so some CSFB UEs don't support this way to be recognized, which results in CSFB identify failure. UL fast return is ineffective to the UE.

In future releases (and after network upgrade :)) there are other IE which could easily recognize the CSFB calls. Please see other posts for details.
I hope this helps everybody.

ninjafine, thanks for the explanation, I'll look into IWF details these days. We actually found the problem, an incorrect mapping between LAC and TA in MME. :)

[siyed80]

- RRC connection Request with CSFB indication
I noticed that only IPhone 4 sends this indication. I didn’t notice it for any other phone (HTC one Samsung s3 s2LTE).
hi,
can you confirm that the behavior occurs with an iphone 4. the iphone 4 does not support the LTE !!