Hi mirc84,
do you have ISR (Idle mode signalling reduction) activated?
br!
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,
do you have ISR (Idle mode signalling reduction) activated?
br!
Hi again,
one more question: do you have PS HO in parallel with CS fallback?
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
1. No, I don't think we have ISR activated.
2. Currently our network does not support PS HO but we have redirection.
3.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!
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.
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.
Bookmarks