CS Fallback Issues
CSFB Signalling Flow - Simplified
UE
MME
eNodeB
MSC
RNC
1
RRC: Paging (cn-Domain CS)
S1AP: Paging
3
4
SGsAP: Paging Req
3
SGsAP: Service Reject
RRC: RRC Connection Request
MT Only
2
RRC: RRC Connection Setup
RRC: RRC Connection Setup Complete /
NAS: EXTENDED SERVICE REQUEST
S1AP: Initial UE Message/
NAS: EXTENDED SERVICE REQUEST
SGsAP: Service Request
S1AP: Initial Context Setup (w CS Fallback Indicator)
5 S1AP: Initial Context Setup Response
RRC: RRC Connection Release (Redirection Info)
S1AP: UE Context Release Request (cause Radio Network cs-fallback triggered)
S1AP: UE Context Release Command (cause Radio Network cs-fallback triggered)
S1AP: UE Context Release Complete
Acquire 3G cell & read SIBs
3G RRC Connection Establishment
NAS: CM SERVICE REQUEST or PAGING RESONSE
RAB and Call Setup
MT Only
CSFB Failure points
1.
MSC has to correctly identify the subscriber is SGs associated and Page the MME.
2.
MME may reject the page
3.
4.
MME stats show probably about 1% of SGs pages for CSFB are rejected by MME. Tek probes can
be used to try narrow these rejections down to root cause.
MME may page UE incorrectly due to MME Duplicate IMSI fault. T2 have a workaround
cleaning script running how effectively is this mitigating the fault?
UE may fail to respond to the LTE page for many reasons
5.
6.
7.
8.
We have seen cases where this association is not always correct which may prevent the page
ibeing correctly sent to the MME n the first place
For example, UE is busy doing TAC updates, moving from LTE to 3G or vica-versa, LTE RRC
congestion or poor RF especially in uplink at cell edge, paging congestion etc)
Early NTI testing saw cases where the MME sends a PS-Domain page instead of a CS-Domain
page so UE does not respond with correct message (responds with Service Request instead of
Extended Service Request, which means CSFB is not triggered) unlikely to still happen
Early NTI cases also saw cases where UE was busy transitioning from Idle to Connected Mode
right when the MME was paging the UE. UE did not read the page (an RRC Connected UE is
looking for CS Service Notification message, not paging for CSFB) and MME didnt appear to be
smart enough to recognise this state transition and send CS Service Notification). This would be
reasonably rare but I captured at least two examples during my testing so it does happen.
MME or eNB fail to correctly action the CSFB request (i.e. fail to initiate Redirection)
UE falls off LTE but fails to find a suitable 3G cell to make the call
UE falls back to 3G successfully, fails to respond to page (e.g. 3G RRC Congestion)
UE falls back successfully to 3G, responds to page but then actual Voice call fails to
setup for all the normal reasons of voice congestion.
CSFB Testing
Independent test house Anstel showed Optus CSFB call setup failure rate In
Sydney CSB and metro is higher than Telstra
Optus: 34 call setup failures
Telstra: 15 call setup failures
Initial E2E drive test of CSFB with Samsung Galaxy 3 shows the following
main categories for the voice call failures when the UE is already on LTE:
Failure Category
LTE MT
CSFB request not responded to by
network
UE doesnt receive the page
5
1
LTE MO
1 (4%)
9 (36%)
UE doesnt respond to the page
Modify EPS Bearer Reject
1 (4%)
9 (36%)
5 (20%)
Note: Percentages are the percentage of failures that are due to this cause, not the actual failure rate of the CSFB
In addition, over half of the MT call failures while the UE was classified as being on 3G
were in fact caused by the UE reselecting to LTE at the time the call was being made
Main issues
Over 50% of observed MT failures in Swissqual testing were seen to be
caused by the MT call (page) coming into the LTE UE when the UE was not in
a reachable state, because it had rejected the Modify EPS Bearer Request
procedure
1.
2.
3.
4.
5.
UE has returned from 3G to 4G and successfully
performed a Combined Tracking Area Update
MME initiates a Modify EPS Bearer Context
Request message to update the QOS
parameters from 3G to 4G (e.g. max bit rates)
UE rejects the request still unknown why
MME seems to wait 10s before reacting, and
then Detaches UE asking for it to re-attach why
take so long?
UE takes 10s to initiate new Attach again, why
so long?
UE is unreachable for paging during this
whole 20s period!!!!
Interesting Note
Telstra dont have this issue
as they dont even perform
this procedure question is
with Architect team to figure
CSFB Initiatives
Table below lists some of the initiatives we can undertake to improve various aspects
of CSFB performance
Config / Initiative
Separate redirection targets
from CSFB and coverage based
data redirections
Measurement Based redirection
(with multiple configured target
layers)
CSFB via PS HO
Deferred SIB Reading on 3G
Fast Return back to LTE
NSN
Huawei
Comments
Yes
No
(eRAN3.0)
Allows CSFB to U9 in poor U21 areas and when
U9 is not congested manual area engineer
optimisation
RL40
RL40
Yes
RU40
Yes
Can improve CSFB target layer selection, if
algorithms are intelligent enough (unknown)
Increases delay in call setup
Yes
Reduces CSFB delay, improves reliability of call
setup by reserving call resources in 3G
Requires CN support, most likely not fully
available
RAN14
Speeds redirection based CSFB by allowing UE
to access 3G cell without reading all SIBs (e.g.
skip SIB11)
Telstra are doing this today
RAN14
Allows RNC to redirect LTE capable UE straight
back to LTE when releasing the voice call
(redirection)
Risky with Ericsson and Huawei
implementation as no prior check on LTE
suitability is performed
Telstra are doing this today
Allows eNB to acquire 3G SIB info for target
cells and deliver to UE in RRC Release
