CSFB_Failures_and_checks.pdf

(1)

CSFB to wcdma

(2)

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)

(3)

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.

(4)

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.

(5)

CSFB Call FLOW

(6)

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.

(7)

CSFB FLOW CHART

(8)

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)

(9)

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.

(10)

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.

(11)

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.

(12)

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 weren’t sure why there weren’t 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 haven’t received a definitive response that explained the behavior.

(13)

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

(14)

CSFB happening, but not pegging

in Counters (Scanner Issues)

› If you are aware of a particular eNB is having CSFB but it’s 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.

(15)