You are on page 1of 15

CSFB to wcdma

Failures and checks


AGENDA

 CSFB to WCDMA Feature


 Network Requirements
 Call Flow
 CSFB Flow Chart
 Issues encountered so far for CSFB (in AT&T SFL Market)
CSFB not setup correctly (Incorrect Settings)
CSFB not happening (Incorrect Configuration)
CSFB happening, but not pegging in Counters (Scanner Issues)

Ramprasad Bhupatiraju | Ericsson Internal | 2012-11-15 | Page 2


Csfb to WCDMA fEATURE
The CS Fallback provides a basic mobility between an LTE cell and neighboring WCDMA
cells and requires the UE to fallback from E-UTRAN to WCDMA if it must connect to the
CS domain.

When the LTE terminal requires a CS service, it will transmit an Extended Service
Request message to the serving MME. The MME will respond by ordering the eNB
connected to the terminal to release the terminal and redirect it to a defined WCDMA
frequency.

The eNB makes the frequency selection based on the following criteria:
1)Terminal capabilities.
2) csFallbackPrio [eNB, 3 (UMTS 850); 2 (UMTS 1900) ; 1; 0 (No UMTS csfb to GSM), ,
Local] value of each available frequency relation.

The eNB will select the highest priority frequency relation that is supported by the
terminal and perform a blind Release with Redirect to that frequency.
This decision is only based on information stored in the eNB and the capabilities of the
terminal. No measurements will be performed to determine what IRAT cells the terminal
can hear.

CSFB adds a small delay to the overall call setup and it is typically 1-2 Secs.

Ramprasad Bhupatiraju | Ericsson Internal | 2012-11-15 | Page 3


Network Requirements

The following must be fulfilled at feature activation:

A license for the Coverage-Triggered WCDMA Session Continuity feature is activated


to enable CS fallback to UTRAN FDD.

A license for the CS Fallback to GERAN and UTRAN feature is activated

There must be UTRAN coverage in the area covered by the LTE cell.

The LTE UE must have WCDMA capabilities.

There must be at least one defined frequency relation for mobility. The
UtranFreqRelation MOs represent frequency relations.

Ramprasad Bhupatiraju | Ericsson Internal | 2012-11-15 | Page 4


CSFB Call FLOW
Detailed explanation in the following slides.

Ramprasad Bhupatiraju | Ericsson Internal | 2012-11-15 | Page 5


CALL FLOW
The CS Fallback to GERAN and UTRAN operates as follows:

1) UE is on LTE and needs a CS Service.

2) The UE send an Non-Access Stratum (NAS) extended service request to the MME requesting a CS
fallback. The UE requests the CS service either as a response to a user activity or as a response to a
paging message with a CS fallback flag.

3) The MME sends an S1-AP UE context modification request with a CS fallback indicator to the eNodeB.

4) The eNodeB selects a frequency for the redirection. The selection is based on the following criteria:
UE capabilities
CS fallback frequency priorities defined with the csFallbackPrio parameter for each available
frequency relation
No measurements are ordered to determine what Inter Radio Access Technology (IRAT) cells the UE
can detect. When several possible target frequencies have the same priority, the eNodeB applies a
round robin scheme for the selection. The eNodeB initiates a blind Radio Resource Control (RRC)
connection release with redirection by sending an RRC connection release message directing the UE to
the selected frequency. The eNodeB also sends an S1-AP UE context release request to the MME.

5) The UE changes RAT and starts accessing the new RAT attaching to the indicated target frequency

6) The UE sends a CM service request to the BSC/RNC. Once the request is accepted the UE starts the
CS session.

7) Once the UE is attached to the target RAT it can continue to request packet switched services if those
are available.

8) The UE returns back to E-UTRAN when it goes to RRC_IDLE mode and a cell reselection is initiated.
Ramprasad Bhupatiraju | Ericsson Internal | 2012-11-15 | Page 6
CSFB FLOW CHART

Ramprasad Bhupatiraju | Ericsson Internal | 2012-11-15 | Page 7


Issues seen with csfb
As for the CSFB Issues seen in AT&T SFL Market so far, they fall into 3
categories.

1. CSFB not setup correctly (Incorrect Settings)


2. CSFB not happening (Incorrect Configuration)
3. CSFB happening, but not pegging in Counters (Scanner Issues)

Ramprasad Bhupatiraju | Ericsson Internal | 2012-11-15 | Page 8


1. CSFB not setup correctly (Incorrect Settings)

CsfbToGsmWcdma Check if the License is Enabled and Feature is activated.


Wcdmasessioncontinuity Check if License is Enabled and Feature is activated.
UtranFreqRelations should be defined from the EUtranCells to each of the required
UTRAN Frequencies.

Ramprasad Bhupatiraju | Ericsson Internal | 2012-11-15 | Page 9


2. CSFB not happening (Incorrect Configuration)

1) TAC on LTE Site not matching the LAC on the underlying UMTS Site as defined
by the Customer mapping. This usually happens after Rehomes and can be checked
by RAN.

2) Although LAC/TAC mapping is correct, the corresponding mapping (LAC) in one


or several MMEs is pointing to an incorrect MSC (than what the underlying UMTS
RNC is connected to). This usually happens after Rehomes to a newly introduced
RNC and it can be checked by the MME Support group.

Ramprasad Bhupatiraju | Ericsson Internal | 2012-11-15 | Page 10


EXAMPLE ISSUE BACKGROUND
In this case, on 10/02/12, 4 UMTS Sites in South Florida Market
(FLMFU0619/FLMFU0630/FLMFU0658/FLMFU0697 were rehomed from OJUS7 RNC to OJUS16 RNC
which was newly brought into Service. TAC on the corresponding 4 LTE Sites was updated by the Rehome
Group.
However we noticed the next morning that the Stats on those 4 LTE Sites were severely degraded and the
Issue began at 12:00AM the exact time as the completion of rehome.
Accessibility took a hit due to RAB Succ Rate degradation.
Handover Success dropped due to failures in Execution Stage.
CSFB stopped happening.

Ramprasad Bhupatiraju | Ericsson Internal | 2012-11-15 | Page 11


EXAMPLE ISSUE RESOLUTION

After verifying all the eNB/Freq relation level settings are correct, we ensured that the customer defined
LAC/TAC Mapping is in place.
After engaging, AT&T ATS (Advanced Technical Support) and Translations group, the Issue was found.
There were 8 MMEs Live in the Pool and defined for each of these eNBs.
Out of these 8 MMEs, 2 of the MMEs had the LAC in question pointing to an incorrect MSC (in this case to
PRRN ATCA instead of OJUS ATCA).
The Correction was made by the Translations Group to point the LAC in those 2 MMEs also to OJUS ATCA

After 2PM on 10/2/12, all the degraded KPIs have recovered.

Official explanation given was there is what is essentially an Operator Configured Lookup table in each
individual MME which maps a TA to an LA and then points it to an appropriate MSC. This is so the paging will
go to and from the correct MSC when performing CSFB. If this table is not updated correctly when
reconfiguring the RAN, CSFB will fail because the MME will be sending the info to the wrong MSC.

Note Although only 2 MMEs had the incorrect settings and the other 6 MMEs in the pool were ok, we
werent sure why there werent any CSFB calls happening at all on the LTE Sites.
What about the calls that were routed to the 6 MMEs that had correct settings? Although we initiated this
question back to AT&T ATS and E///, we havent received a definitive response that explained the behavior.

Ramprasad Bhupatiraju | Ericsson Internal | 2012-11-15 | Page 12


3. CSFB happening, but not pegging
in Counters (Scanner Issues)

Currently in LTE, there are 2 Scanners that should always be Active on all the Live eNodeBs.
System Defined Statistics Profiles -> System ERBS Primary (PREDEF.STATS)
User Defined Statistics Profiles -> National_PM_Stadard_NodeB_SW Version

Ramprasad Bhupatiraju | Ericsson Internal | 2012-11-15 | Page 13


CSFB happening, but not pegging
in Counters (Scanner Issues)
If you are aware of a particular eNB is having CSFB but its not being reflected in the
Counters/BO, check the following

1) Login to the eNB and use pst which will list all the PM Scanners and their Status on that Node.
2) Ensure both the below highlighted Scanners show the Status as Active.
3) If either one of them shows the state as SUSPENDED it will cause multiple Counters to not peg
on those Sites. In that case use the Command pdeb Proxy# on the Node, for example pdeb 1
in this case to activate the Scanner. All the required Counters should be pegging in the following
ROP.

Note The list of Issues that caused CSFB Failures discussed in this presentation are the ones seen in one Market (SFL)
only, there might be other Markets that saw CSFB fail due to other reasons. If you came across different Issue/resolution,
please feel free to add them in the Comments Section for this presentation on the Knowledge Base Link.
Ramprasad Bhupatiraju | Ericsson Internal | 2012-11-15 | Page 14