end-to-end cs fallback to gsm and wcdma system

Ericsson ConfidentialTECHNICAL REPORT 1 (77)

Prepared (also subject responsible if other) No.

CSFB Study Team EAB-10:051539 UenApproved Checked Date Rev Reference

EAB/FZP [Mikael Marklund] 2011-04-29 B

Receiver:Stefan Svensson, BNET Product and Portfolio MgmtKrister Svanbro, BNET S&T Eric Parsons, SPM LTE Sven Gemski, SPM MSSJoerg Ewert, PdM MSSLars Frid, PdM EPCLars Bergenlid, SPM WCDMADavid Bladsjö, SPM GERANAnil Dua, SPM HSSStig Pustinen, LTE/EPC System Project

Authors:Gunnar Rydnell, EPC SMLotta Voigt, DURA SMThodoros Mazarakis, PDU MSS Paul Schliwa-Bertling, PDU GERANGunnar Bergquist, LTE SMHenrik André-Jönsson, LTE SMDevashish Rughwani, PDU OSSJens Poscher, BNET S&T TC

End-to-End CS Fallback to GSM and WCDMA System Impact Study Report

Executive summary

CSFB and SMS over SGs is planned to be supported H1/2011 in EPC and LTE together with first CSFB capable, commercial LTE terminals on the market. BNET MSS support for CSFB and SMS over SGs is planned for H2/2011. These features are already available for BCAM MSS since Q2/2010. There is no direct impact on WCDMA, GSM and Packet Core for the basic CSFB R8 functionality without service characteristics improvements.

To limit the implementation effort of standardized options an alignment was done between two main terminal vendors and Ericsson to support CSFB with enhanced RRC release and redirect with System Information (NACC) for GSM according to 3GPP R9. This alternative provides the best characteristics, The PS handover options might come in a later stage.

For WCDMA optionally CSFB with RRC release and redirect without System Information but together with deferred measurement control reading (DMCR) in UTRAN can be used to limit development cost. For this solution no Radio Information Management (RIM) needs to be developed. This solution has slightly worse characteristic compared to the previous mentioned CSFB option.

The customer favored enhanced CSFB solution with System Information is characterized by a faster call setup time and requires transferring system information of the GSM or WCDMA target cell to the eNB via RAN Information Management procedures (RIM) to be supported in eNB, BSC, RNC, SGSN and MME.





CSFB and SMS over SGs related findings and consequences:

Area Issue Consequence

LTE No firm plans for PSHO to WCDMA for CSFB

Not aligned WCDMA, EPC and LTE roadmap

No plans for RIM support. Missing RIM jeopardizes the promoted enhanced CSFB option to provide system information to eNB to decrease call set/up time. Misaligned RM with LTE, EPC and SGSN-W.

No defined strategy e.g. PSHO back to LTE or RRC release to immediately send back a UE to LTE after CS call completion during ongoing PS sessions (not CSFB specific).

Ongoing PS sessions in WCDMA prevent the UE to go back to LTE. The user might not experience the LTE throughput after CSFB for long.

WCDMA

No MOCN Release 6 support Operators that share WCDMA RAN may find them forced to move their Roaming Incoming Customers to GSM

No MME support of MSC pool yet via SGs.

Impacting the MSS system by having uneven load distribution on MSCs. (assuming a high number of LTE UEs)

PC/EPC

RIM needs to be developed for MME and SGSN-W to relay RIM containers. Only the SGSN-G supports RIM.

Missing RIM jeopardizes the promised and customer wanted CSFB enhancement option to provide system information to eNB to decrease call set/up time.

BNET MSS

No plan to implement "MT call roaming retry". Rel 10 “MT call Roaming Forwarding” is preferred choice.

This implies an increased risk that CSFB call success rate is lower than in legacy networks as long not implemented.

HLR/HSS No support of optional EPS location information in MAP

Service impact for CAMEL based SMS over SGs online charging





via the MSC

BNET MSS

HLR restart is not propagated to MME

In case of inconsistent or lost HLR data after HLR restart the UEs, which are IMSI/EPC attached and camping in LTE, might not be reachable for MT calls or MT SMS until they perform a LU or MO action. This can take some time as no periodic LU is done in LTE.

End to End Solution:

CSFB can have higher call failure rates on the LA borders of different MSCs without MSC pool or “MT call roaming retry/forwarding” deployment.

The introduction of CSFB can have huge impact on the existing customer radio and core network:

CS Core Network:- MSC pool should be rolled out beforehand to prevent that a call fails if the

UE falls back into an MSC LA not served by the paging MSC- MT roaming retry/forwarding, where planned to be developed, needs to

be rolled out into the CN- For networks with specific MSC for GSM and WCDMA access the

development of MT roaming retry/forwarding is recommended or all MSC need reconfiguration for dual radio in case of patchy GSM/WCDMA radio.

- Without MSC pool support in MME the load of specific MSCs in a pool can become uneven distributed because the LA have to be manually distributed over the pooled MSCs. Additionally, the MSC pool redistribution does not work for CSFB supporting terminals registered in MME.

- IP on CP needs to be activated. Additional hardware for security (GESP board) is needed for MSC/VLR nodes.

Packet Core Network:- Mapping of TA lists and LA needs to be done in the DNS to prevent LU

after fall back. A correlation between CS and PS planning is created. LA most probably cannot be changed if CS call routing is connected to LAs.

- Rollout of RIM functionality (for enhanced RRC release with redirect)

Radio Network:





- For not MSC pool aware GSM/WCDMA radio nodes (e.g. older SW or multi vendor) the MSC pool proxy should integrated first if MT roaming retry is not available.

- Rollout of RIM and deferred measurement control in UTRAN (for enhanced RRC release with redirect)

All technical findings are summarized in chapter 3 leading to new functional requirements listed in chapter 8.





Contents

1 Introduction ....................................................................................... 61.1 Scope................................................................................................ 61.2 Purpose............................................................................................. 61.3 Background ....................................................................................... 71.4 Revision Information.......................................................................... 72 CSFB and SMS over SGs ................................................................. 73 Findings........................................................................................... 114 End to End Feature Plan ................................................................. 125 Network Deployment Strategy ......................................................... 145.1 Overlay Approach............................................................................ 145.2 Network Design Recommendations................................................. 206 CSFB and SMS over SGs Use Cases ............................................. 216.1 Combined EPS/IMSI Attach............................................................. 246.2 Combined EPS/IMSI Detach Procedure .......................................... 256.3 Mobility Management ...................................................................... 266.4 Mobile Originated Call ..................................................................... 296.5 Mobile Terminated Call.................................................................... 336.6 UC_R1: Return back to E-UTRAN................................................... 346.7 UC_RS1: MME Restart ................................................................... 356.8 UC_RS2: MSC Restart.................................................................... 356.9 UC_MOSMS1: Mobile Originated SMS, idle Mode .......................... 356.10 UC_MOSMS2: Mobile Originated SMS, active Mode ...................... 366.11 UC_MTSMS1: Mobile Terminated SMS .......................................... 367 End-to-End Solution ........................................................................ 377.1 LTE RAN......................................................................................... 377.2 WCDMA .......................................................................................... 397.3 GSM................................................................................................ 437.4 Evolved Packet Core Solution ......................................................... 447.5 BNET Mobile Softswitch Solution .................................................... 527.6 BCAM Mobile Softswitch Solution.................................................... 647.7 OSS ................................................................................................ 647.8 Terminals ........................................................................................ 647.9 Service Characteristics.................................................................... 657.10 Shared Networks............................................................................. 667.11 Multi Country Support...................................................................... 708 Wanted functionality and requirements............................................ 708.1 UTRAN............................................................................................ 718.2 MSS ................................................................................................ 728.3 EPC................................................................................................. 739 Abbreviations................................................................................... 7310 References...................................................................................... 76





1 Introduction

The CSFB System Impact Study documents the end to end implementation for CS fallback and SMS over SGs according to 3GPP release 23.272 9.3.0.

1.1 Scope

The time frame for functionality covered in the different node road maps is 2010 until 2012.

Missing functionality or improvement proposals are covered in the requirement section.

Included systems: Mobile Soft Switch R12A EPC 2010B, 2011A and 2011B LTE L11B WCDMA W12B (DMCR no RIM) GSM G12A (RIM and fast return to LTE in 12A) BCAM MSS uCore3.2 (former Nortel) OSS 11.2/12.x Terminals

Out of scope: CDMA networks Detailed analysis of RIM (Radio Information Management) procedures [4] Nortel WCDMA (Ericsson has not acquired former Nortel WCDMA) Nortel GSM (Ericsson has not acquired former Nortel GSM outside of North

America)

1.2 Purpose

Purpose of this study is to give an end to end view on CSFB and SMS over SGs to product management detailing:

Overview of all planned functionality

Handshaking and agreeing between all PDUs the required functionality

Time scale for all impacted systems





The document is intended as base for an Ericsson CSFB Solution Guideline targeted to support RCs/Solution Management in customer discussions and tendering.

1.3 Background

One main rational in the development of LTE has been to develop a radio network which is optimized for the transfer of packet data. Therefore, traditional CS-domain services like voice, UDI video and SMS, are just a few among many potential media streams that can be communicated under LTE.

Since industry will not introduce LTE, IMS and All IP overnight, 3GPP also provides solutions for traditional CS-domain services coexisting with LTE. The solution for SMS is called SMS over SGs, which allows the transmission of native SMS from CS infrastructure over the LTE radio network. Thus, SMS over SGs provides SMS service for a terminal while it remains connected through E-UTRAN. The solution for voice is called Circuit-Switched (CS) Fallback. This allows an LTE device to drop back to the legacy WCDMA or GSM network if IMS VoIP capabilities are not supported. CS Fallback, in contrary to the solution for SMS, requires the UE to fallback from E-UTRAN and rather uses either GSM or WCDMA if it must connect to the CS domain. The CS Fallback function is of course only possible to realize in areas where E-UTRAN coverage is overlapped with GSM and WCDMA coverage.

CSFB will be the only option for single radio UEs to provide CS services until VoIP is available and implemented.

1.4 Revision Information

Rev Date Modified by DescriptionA 06.09.2010 Study Team Final VersionB 29.04.2011 Jens Poscher Updated CSFB RM and functionality

changes

2 CSFB and SMS over SGs

With the introduction of commercially available voice capable LTE terminals H1/2011 the CS services (voice, fax, CS data, supplementary services, USSD etc.) can in principle be handled in the PS or CS domain. If MMTel is not implemented in the customer network the CS fallback feature is used to allow theterminal to leave EPS and perform CS services in MSS.





If CS fallback is used to provide CS services in an LTE network prerequisite is overlapping LTE and WCDMA/GSM coverage. The new SGs interface between MSS and EPC is required. It is used for the combined EPC and IMSI attach/detach of the UE, to page a CSFB capable terminal from the MSC via LTE/EPC for an MT call and for sending/receiving SMS.

During CSFB the UE will be ordered to leave LTE and do RAT change to GSM or WCDMA to complete the call. Arriving in the target RAN the UE can do the normal CS procedures to handle the call in MSS. In WCDMA or GSM the call proceeds. After its completion the UE may be sent back to LTE based on implemented WCDMA/GSM mechanisms. Ongoing PS sessions in LTE might be interrupted or suspended, e.g. in non-DTM GSM networks, for and incoming CS call also when the CS call is not taken.

SMS over SGs is handled purely in LTE. No fallback to CS is required.

eNodeB UEMMES1-MME

A or Iu

HSS

HLR MSC

MGw

SGs

RNC/BCS

CS domain

SGSN SG

Gn

S6a

D

Figure 1 CSFB architecture

The target implementation baseline is the 3GPP release 9.3.0 solution with “enhanced release with redirect” to WCDMA or GSM. To optimize service characteristics the eNB may provide system information of the WCDMA/GSM target cells to the UE when it releases the radio bearers and redirects the UE to the other radio technology. This system information may be provided and synchronized between the different radio technologies via RIM procedures.

There are 3 main CSFB procedures:

- Cell Change Order (CCO), not planned to be implemented

- Release with Redirect, first priority





- PSHO, no decision yet if to be implemented

Depending on the CSFB procedure different network elements are affected, which is shown in the following chapters.

2.1.1 Basic CSFB, RRC Release with Redirect

The basic CSFB option is RRC Release with Redirect. The impacted nodes are shown in Figure 2 indicated by the CSFB in the circle.

MMEMMEMME

MSCMSCMSC

SGsSGs

GSMWCDMA

LTELTELTE

CSFBLTELTE

MSCMSCMSC

CSFB CSFB

CSFB

HLRHLRHLR

HSSHSSHSS

2G/3G2G/3G2G/3G

CSFB

Figure 2 Release with redirect

Impacted nodes are UE, eNB, MME and MSC

No impact on GSM or WCDMA.

Characteristics:

Slower call set-up time because SI needs to be fetched by the UE in the target RAN

Long PS outage time for WCDMA or DTM GSM

2.1.2 Enhanced CSFB, RRC Release with Redirect, SI exchange with RIM

The enhanced option uses the standardized RIM procedures to transfer system information (SI) from GSM to LTE. This would require additional impact on the total network. RIM needs to be rolled-out in the source and target RAN as well as for SGSN and MME. SGSN and MME will be needed to route the RIM container to the correct target node.





MMEMMEMME

MSCMSCMSC

SGsSGs

GSMWCDMA

LTELTELTE

CSFBLTELTE

MSCMSCMSC

CSFBCSFB

CSFB

HLRHLRHLR

HSSHSSHSS

CSFB

RIM procedures

SGSNSGSNSGSN

RIM procedures

RIM procedures

RIM

RIM

RIM

BSCBSCBSC

RIM

Figure 3 Automatic system information exchange with RIM

Additional Nodes impacted: RIM support in BSC, eNB, SGSN and MME

Additional Network Impact: RIM to be rolled out in RAN and PCN

Benefit: faster call set-up times compared to the non enhanced solution, see chapter 7.9.

2.1.3 Enhanced CSFB, RRC Release with Redirect, DMCR in UTRAN

RIM is not planned to be implemented in UTRAN. To allow a faster call set-up for CSFB to UTRAN the RAN can allow deferring reading of specific UTRAN SI. The UE will skip reading of SIB11 and 12.

Additional Nodes impacted: DMCR support RNC

Additional Network Impact: DMCR to be rolled out in UTRAN

Benefit: faster call set-up times compared to the non enhanced solution, see chapter 7.9.

2.1.4 PS Handover between LTE and WCDMA for CSFB

Another alternative option to the RRC release is a CSFB based on PSHO. Here the PS bearer is prepared first in the target cell before CSFB takes place. The benefit is a shorter PS service interruption time.





MMEMMEMME

MSCMSCMSC

SGsSGs

GSMWCDMA

LTELTELTE

CSFBLTELTE

MSCMSCMSC

CSFB CSFB

CSFB

HLRHLRHLR

HSSHSSHSS

CSFB

RNCRNCRNC

PSHO

PSHO PSHO

SGSNSGSNSGSN

PSHO

Figure 4 PS handover solution

Additional node impact: Support of PSHO with CSFB from LTE to RNC/BSC

Benefit: Shorter PS outage time during CSFB IRAT handover, see chapter 7.9.

3 Findings

The study has following findings:Area Slogan Impact on Consequence Timeframe ActionEPC/MME No MSC pool support MSC Uneven CP load in an MSC

pool. Manual MSC pool distribution in MME based on LA definition.No MSC pool subscriber distribution procedure for LTE subscribers to free an MSC-S for maintenance

After 2011A RP02 (no date confirmed)

New requirement, see 8.3

EPC/MME RESET message not supported after MME restart towards MSC-S

MSC MSC is not aware of MME restart (optional message in standard)

Not planned Considered acceptable. No action

EPC/MME No global paging MSC If the MSS does not include a LA in the paging the MME will reject it "after a MME restart".

Not planned Customers should not use global paging

LTE RIM support L12AGSM RIM support G12AWCDMA RIM support No plansPC RIM support SGSN-G: ok

SGSN-W: 2011A

EPC RIM support

No automatic update of eNB with system information of GSM/WCDMA target cells. Required for enhanced RRC release with redirect.

MME 2011AWCDMA Deferred

Measurement Control in UTRAN

CSFB call setup time characteristics

Time consuming SI reading by the UE

W12B

Alignment between SPMs needed

GSM Fast return to LTE PS Slow return to LTE. While G12A No action





after CS call completion

characteristics camping in non-DTM GSM the PS services are suspended

needed

WCDMA Return to LTE after CS call completion

PS throughput characteristics

As long as a PS session is active in WCDMA the UE will not be redirected to LTE and customers experience lower throughput. No plan for PSHO back to LTE.

No plan for improvement yet

System study should be triggered in WCDMA RAN

WCDMA MOCN Release 6 support

CSFB target RAT flexibility

Operators sharing WCDMA might need to do CSFB only to GSM

No plan for improvement yet

New requirement, see 8.1

LTE No CSFB to UTRAN TDD

CS service No CSFB based CS services of LTE terminals in WCDMA TDD overlay network

No customer demand yet

No action needed

BNET MSS

Roaming Retry MSC, HLR Calls fail for a UE performing CSFB to different MSC than the one doing the paging

Not planned New requirement, see 8.2

HSS EPS location information

HSS, MSC CAMEL based SMS online charging does not work for SM over the SGs interface.

12A or 13A Follow-up with HSS SPM

MSS Propagate HLR reset to MME

End customer The end customer is not be reachable for MT SMS and calls until next MO transaction of LU

Not planned PDU MSS follows-up

Table 1 Study findings

4 End to End Feature Plan

The committed time plan for CSFB related functionality is shown in Figure 5based on roadmap information from [8][9][10][11][12] and [13].





LTERAN

EPC

WCDMARAN

GSMRAN

First commercial CSFB capable terminals

L11B L12A

2010B 2011A 2011BCSFB

MSC pool sup.RIM in MME

RIM SGSN-W

CSFB w/ SIRIM for GSM

SMSoSGs

CSFB

G12A

11.2

LTE->GSM (RIM)Fast return to LTE

W12BDMCR

(enh. CSFB to 3G)

No impact

Q1 Q2 Q3 Q4Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4

2010 2011 2012Q1 Q2 Q3 Q4Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4Q1 Q2 Q3 Q4Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4

2010 2011 2012

Released CandidateReady for Contract Indicative

No impact

12.0

12A 12BCSFB for MSC-S BC

SMSoSGsCSFB for MSC-S W12B13A13B

MTRF

EnhancedCSFB for 2G

EnhancedCSFB for 3G

3G track

2G track

Basic CSFBRel w/ Rd

(non optimized)

Enhanced CSFBRel w/ Rd

(perf. optimized)

BNETMSS

OSS

BCAM MSS uCore3.2

SMSoSGsCSFB

12.2

Figure 5 CSFB time plan

The non-enhanced basic CSFB with RRC release and redirect without any service characteristics improvements and SMS over SGs is available Q2/2011 with BCAM MSS.

The full end-to-end solution with BNET MSS including enhanced CSFB to GERAN is available Q4/2011.

The corresponding detailed functionality summarizes following table:

H2/2010 H1/2011 H2/2011 H1/2012LTE L11B

CSFB with RRC release and system info (GSM&WCDMA)

RIM

WCDMA No impact (missing RIM and Deferred Measurements) DMCR

GSM No impact (missing RIM) G12A- RIM to LTE- Fast Return

EPC 2010B -- SMS over SGs

2011A- CS Fallback to GSM/WCDMA using Release with Redirect - Suspend/resume

2011B candidate- Support of MSC pool- MME support for RIM for WCDMA/GSM





support- Support of paging based on LA after MME restart

BNET MSS R12A- SMS over SGs-interface- CS Fallback

BCAM MSS

SMS over SGs-interface, LTE to CS Fallback

HLR Candidate R12 or R13:support of EPS location information in MAP for CAMEL based SMS over SGs

online chargingOSS Target RAT and

frequency definition

CSFB Terminals

- WCDMA/GSM single radio solutions for CS Fallback- 3GPP R9 solution based on RRC release and redirect procedure with system info

Table 2 Feature time plan

5 Network Deployment Strategy

The most common introduction scenario for LTE is an overlay scenario with GSM and WCDMA. It is needed to coordinate LTE network planning and radio and CN planning in the GSM/WCDMA systems to optimize the CSFB characteristics and call success rate.

5.1 Overlay Approach

To understand certain CSFB implications on the existing network it is important to understand how LTE radio coverage will be deployed by most customers. The most likely initial deployment for LTE sites is co-locating with an existing GSM/WCDMA RBS network grid to save cost. This predefines the physical location of the antennas. Thus, aligning LTE and GSM/WCDMA cell planning for CSFB depends on cell size of the different systems.

GSM nowadays is mostly not coverage driven but capacity driven because in most countries a full GSM coverage is installed. This means that GSM cells have a tendency now to have smaller cell sizes.





WCDMA still has not reached a full country wide coverage for most operators and by this a patchier network structure. This means that a strategy for CSFB to which RAT a fallback needs to take place has to be defined.

To not get a similar problem with LTE and to fulfill the need of providing LTE access in rural areas for internet access many operators have bought spectrum in the 700-800MHz band. This will give initially large LTE cells for the mobility layer reusing some selected GSM/WCDMA sites. For high speed access in dense populated areas, the spectrum around 1.8-2.6 MHz will be used with small cells for capacity.

For CSFB the eNB is provisioned via OSS or Automatic Neighborship Relation (ANR) with all GSM and WCDMA neighbor cells. For all neighbor cells the SI can be stored. This SI is send from BSC and RNC via MME and SGSN in RIM containers (if supported) to the eNB. In case of CSFB the eNB decides based on the priorities to which RAT and to which frequency the UE should be released to. WCDMA and GSM should have different priorities. Only if the UE is not supporting the priority 1 target RAT the 2nd RAT is chosen. There is no round robin if both priorities for GSM and WCDMA are the same. In this case always the first defined RAT is used. Figure 6 shows a likely LTE overlay scenario. The eNB is aware of 2 target RATs in two different frequencies. For each RAT a neighbor cell list is stored with additional system information. The UE camping in LTE knows its TA and LA and will be provided with the target cell list and SI in case of CSFB.

2321

22

11

12

40 423031 36 41

13

Target cellSI to UE by eNB

GERAN 900MHz

UTRAN 2100 MHZ

3b LTE: 700-800 MHz

35

LA2

eNBeNB

Freq 2100, csFallbackPrio=2, {N1=31, SI1, …, N5=41, SI5…}

Freq 900, csFallbackPrio=1, {N1=13, SI1, ..., N3=22, SI3}

Figure 6 Redirect to target RAT with cell list with system information





Based on the target RAT decision the complete neighbor cell list is sent to the UE up to a supported maximum number of cells if SI is stored in the eNB. The UE will now tune to the target RAN and frequency and select the cell with the best signal. If SI was stored in the UE it can skip reading the SI speeding-up the CSFB procedure.

Figure 7 shows a likely scenario where LTE cells (1a, 1b, 2a) of higher frequency and smaller diameter overlay with a GSM (11-13, 21-23) and WCDMA (30-33, 40-42) radio network. Additionally, LTE may use the 700-800MHz band to cover rural areas with large cells (3a, 3b).

2321

22

11

12

LA 2

MMEMME

LA 1

TA 2

40 42353031 36 41

2a1a1b

LA 3 LA 4

TA 1

MSC-SMSC-S

LA1&3

TA1-3

MMEMME

3536

3233

13


physical location

LA2

GERAN 900MHz

UTRAN 2100 MHZ

LTE: 1,8-2,6 MHz

CSFB from cell 1b

3b3a LTE: 700-800 MHz

LA border between MSCs or MSC pools

MSC-SMSC-S

LA1&3

MSC-SMSC-S

LA2&4

Figure 7 Cell structure for an LTE to GSM/WCDMA overlay scenario

The LTE network is structured in TAs 1-3. TA1 and TA2 cover the high frequency band cells and TA3 covers the larger cells providing coverage.

The GSM and WCDMA network is structured in LAs 1-4, two LAs per RAT. In case of MSC pool all 4 LA can be served by the same MSC of a pool. In case no MSC pool is implemented the 4 LAs might be distributed over multiple MSCs.





A UE performing CSFB form LTE (UE released from cell 1b) will have a LA (LA=2) stored by the MME resulting from TA to LA mapping. The UE receives a target RAT and frequency it shall tune to and can receive a list of target cells with their SI (enhanced RRC release with redirect). The UE freely selects a target cell in the given target frequency and responds to the paging in the LA it has fallen back to. In case the LA is different from the one stored by the eNB into the UE a LAU is performed.

In the following chapters different issues depending on the deployment scenario are described.

5.1.1 MSC Pool Deployed

A UE performing CSFB from cell 1b (Figure 7) with a stored LA=2 has received e.g. a target cell list with SI containing GSM or WCDMA cells of 2 different LAs of the underlying radio network. Based on NRI the RNC or BSC serving the UE selected target cell will direct the paging response to the correct MSC/VLR where the subscriber is stored. A LAU is needed if the target LA is different from the one stored in the UE.

The call is completed.

In case the RNC or BSC is not MSC pool aware a MSC pool proxy is needed, implemented in the M-MGW.

In case there is an MSC pool border between LA1&3 and LA2&4 there is a probability that the call fails because the receiving MSC pool may not be able complete the call without the feature “MT call roaming retry” if not supporting the specific LA.

5.1.2 No MSC Pool and different MSCs serving GSM and WCDMA

A UE performing CSFB from cell 3b is redirected to WCDMA (higher CSfallbackPrio) and has received e.g. a target cell list with SI containing 5 WCDMA cells of 2 different LA3&4 of the underlying WCDMA network as shown in Figure 8.





2321

22

11

12

LA 2

MMEMME

LA 1

TA 2

40 423031 36 41

2a1a2b

LA 3 LA 4

TA 1

TA2&3 map to LA4

MMEMME

13


physical location

GERAN 900MHz

UTRAN 2100 MHZ

LTE: 1,8-2,6 MHz

CSFB from cell 3b

3b4a LTE: 700-800 MHz

LA border between MSCs

MSC-SMSC-S

LA3&4

MSC-SMSC-S

LA1&2

35

LA4

Figure 8 CSFB if GSM/WCDMA served by different MSCs

The MME should map all TA to WCDMA LA if WCDMA is the preferred target RAN. In case the MME maps the TA to a GSM LA all calls will fail if GSM is the preferred target RAN or if the UE supports only GSM without the feature “MT call roaming retry”.

If both WCDMA LA3&4 are served by the same MSC the call will succeed, with a possible LAU. In case LA3 and LA4 belong to different MSCs there is a probability that the call fails because the MSC serving cell 36 cannot complete the call without the feature “MT call roaming retry”.

In case GSM is not DTM enabled the PS bearer will be suspended during the voice call.

If the preferred RAN is GSM all TA shall be mapped to overlaying GSM LAs. But if a LTE UE is not GSM capable or the LTE cell has no full GSM overlay the UE will finally go to WCDMA and cannot complete the call without “MT call roaming retry”.





5.1.3 No MSC Pool and GSM/WCDMA supporting MSC

Combined GSM/WCDMA MSC servers assure that is case of fallback the UE will land in the same MSC independent of whether the UE is redirected to a GSM or WCDMA cell overlapping with the TA. The likelihood that the paging MSC is different from the MSC where the CS call shall proceed is lowered. A LAU might be needed if the LA in the target RAT does not match the LA provided to the UE by the MME.

A UE performing CSFB from cell 3b with a stored LA=2 has received e.g. a target cell list with SI containing 3 GSM cells or 5 WCDMA cells of 2 different LAs of the underlying GSM or WCDMA network as shown in Figure 9. The LA1&3 and LA2&4 are handled by separate MSCs.

2321

22

11

12

LA 2

MMEMME

LA 1

TA 2

40 423031 36 41

2a1a1b

LA 3 LA 4

TA 1

TA1-3

MMEMME

13


physical location

GERAN 900MHz

UTRAN 2100 MHZ

LTE: 1,8-2,6 MHz

CSFB from cell 3b

3c3b LTE: 700-800 MHz

LA border between MSCs

LA2&4MSC-SMSC-S

LA1&3

35

LA2

3a

MSC-SMSC-S

Figure 9 CSFB to GSM/WCDMA from LTE mobility layer

Because of the size of the LTE mobility layer cells in the lower spectrum there is a higher probability of falling back into the wrong MSC.

Key question is how likely these adjacent LA belong to different MSCs. Usually MSC border areas are in low density areas but in case of major cities which cannot be served in total by one MSC (no MSC pool) it can of course be problematic that these MSC borders are overlapped by LTE cells.





5.2 Network Design Recommendations

Following considerations have to be made together with the customer before CSFB integration to optimize MSC load, call success rate, call set-up time and keep existing MSC pool redistribution routines.

5.2.1 SGs Support in all MSCs

To even out the load of all combined EPS/IMSI attached UEs over the operators MSCs, the SGs interface for all MSC should be enabled. If this is not the case MSC pool is a must. Otherwise all calls to LAs served by MSCs without SGs would fail.

5.2.2 MSC Pool

With MSC pool all MSCs serve all LA within the pool. Prerequisite is that all RNC and BSC are pool aware or the pool proxy functionality is activated in the M-MGW.

The areas where a MT roaming retry would be required are limited to the pool border areas. Border areas typically located between regions in low dense areas where large GSM cells are used. The GSM and LTE cells should be aligned at these MSC pool borders.

The SGs-interface can be implemented in one or a few number of MSCs in initial migration steps and then SGs in more MSCs can be added when more capacity is needed.

5.2.3 Steering of CSFB calls to a prioritized target RAT and frequency

The eNB can preferable sent the UE back to GSM or WCDMA depending on the operator setting of CSfallbackPrio. An RRC Release with Redirect is always performed to a specific RAT and frequency (not to cell).

Note: The eNB cannot include a list of allowed cells in the CSFB RRC Release with Redirect to assure that CSFB calls are steered to GSM/WCDMA cells belonging to the MSCs where the subscribers are registered in.

5.2.4 Umbrella Cells

GSM/WCDMA umbrella cells can increase probability that all LTE-border cells are completely covered by cells from the correct MSC (registered MSC). The UE might select these umbrella cells if the signal strength is better than the signal of the other cells. Cell selection is up to the UE.





CGI/SAI 22CGI/SAI 12

E-CGI 01

dB

dBSignal quality/strength:

GSM / WCDMA cell:

LTE cell:

MSC-SMSC-S

CGI/SAI 23 (umbrella cell)

dB

CGI 23

MSC-SMSC-S

“Border LTE cells” can always be covered with umbrella cells from the correct MSC in order to assure a successful CSFB call without LU/MTRR

Figure 10 Umbrella Cells

This cell planning is difficult to do and there is no guarantee that the UE will tune to the right cell.

5.2.5 Mobile Terminating Roaming Retry

MT Roaming (MTRR) retry will allow that the MSC/VLR where the UE is registered will route the call further to the MSC where the UE has fallen back to. The probability is higher that this use case occurs if no MSC pool is deployed (at MSC borders) or when MSC pool is deployed it can occur as MSC pool borders. MTRR affects the HLR, GMSC and MSC.

Additional delay has to be added for an inter-MSC location update case (2-10 seconds).

6 CSFB and SMS over SGs Use Cases

The following section describes the CSFB and SMS over SGs use cases with their impact on different systems and shows the corresponding signaling flows based on 3GPP TS 23.272 (9.4.0) [1].

LTE/EPC use cases not specific for CSFB are described further in LTE/EPC System Use Cases in EPS 2.0 [16].





Use cases marked “Ok” with a chapter reference have a limitation.

UC Tag Slogan eNB WCDMA GSM MME/SGSN

MSC HSS/HLR

UC_A1 Combined EPS/IMSI Attach Procedure

Ok N.A. N.A. OK1

7.4Ok Ok

UC_D1 Combined EPS/IMSI UE initiated detach

Ok N.A. N.A. Ok Ok Ok

UC_D2 Combined EPS/IMSI MME initiated detach


UC_D3 Combined EPS/IMSI HSS initiated detach


UC_RS_1 MME restart N.A. 2 N.A.2 N.A.2 NOK3 Ok N.A. 2

UC_RS_2 MSC restart N.A. 2 N.A. 2 N.A. 2 Ok Ok N.A. 2

UC_UP1 Combined TA/LA Update Procedure

N.A. N.A. N.A. Ok Ok Ok

UC_RR1 Roaming Retry/Forwarding for CSFB

N.A. N.A. N.A. N.A. NOK7.5.1.8

NOK7.5.1.8

UC_MO1 CSFB using Release with Redirect

OK N.A. N.A. OK OK N.A.

UC_MO3 CSFB using enhanced Release with Redirect

Ok NOK7.2.1 and 7.2.2

Ok SGSN-W: OKSGSN-G: OKMME: OK

N.A. N.A.

UC_MO4 CSFB with PSHO NOK7.1.3

NOK NOK WCDMA: OkGSM: NOK

N.A. N.A.

1 1 Missing MSC pool support2 2 Not CSFB relevant3 3 MSC is not notified and subscriber stays EPS/IMSI attached in VLR until LAU is done. Paging after MME reload done based on LA





UC Tag Slogan eNB WCDMA GSM MME/SGSN

MSC HSS/HLR

UC_MO_5 Emergency Call Ok Ok Ok Ok Ok N.A.

UC_MT1 CSFB using Release with Redirect

Ok N.A. N.A. Ok Ok N.A.

UC_MT3 CSFB using enhanced Release with Redirect

Ok NOK7.2.1 and 7.2.2

Ok SGSN-W: OKSGSN-G: OKMME: OK

N.A. N.A.

UC_MT4 CSFB with PSHO NOK7.1.3

Ok NOK4 WCDMA: OkGSM: NOK

N.A. N.A.

UC_R1 Return back to LTE N.A. NOK7.2.4

Ok N.A. N.A. N.A.

UC_MOSMS1 Mobile Originated SMS, idle Mode


UC_MOSMS2 Mobile Originated SMS, active Mode


UC_MTSMS1 Mobile Terminated SMS


Table 3 Use Cases

The detailed implementation of these use cases are analyzed in chapter 7.

4 4 DTM is not widely deployed in GERAN networks and missing support of PSHO might be acceptable





6.1 Combined EPS/IMSI Attach

6.1.1 UC_A1 Attach Procedure

1. Attach Request

3. Derive VLR number

4. Location Update Request

5. Create SGs association

7. Location Update Accept

UE MME HSSMSC/VLR

2. Step 3 to step 16 of the Attach procedure specified in TS 23.401

6. Location update in CS domain

8. Step 17 to step 26 of the Attach procedure specified in TS 23.401

Figure 11 Attach Procedure

1. The UE initiates the combined EPS/IMSI attach. Network is informed that the UE is capable and configured to use CS fallback and/or SMS over SGs.

2. Step 3 to step 16 of the EPS Attach procedure, no MSC involvement, see [16].

3. VLR update according to combined GPRS / IMSI Attach Procedure. The MME allocates a LAI for the UE. The MME derives a VLR number based on the allocated LAI or on an IMSI hash function (for MSC pool support). The MME starts the location update procedure towards the new MSC/VLR upon receipt of the subscriber data from the HSS.

4. The MME sends a Location Update Request (new LAI, IMSI, MME name, Location Update Type) message to the VLR.

5. The VLR creates an SGs association with the MME by storing MME name.

6. The VLR performs Location Updating procedure in CS domain.

7. The VLR responds with Location Update Accept (VLR TMSI) to the MME.





6.2 Combined EPS/IMSI Detach Procedure

The detach procedure can be initiated by UE, MME and HSS. Details can be found [1] and [16].

6.2.1 UC_D1: UE initiated

1. Detach Request

3a. IMSI Detach Indication

4. Remove SGs association5. Detach Accept

UE MME HSSMSC/VLR

2. Step 2 to step 10 of the UE-initiated Detach procedure for E-UTRAN as specified in TS 23.401

6. Step 12 to step 14 of the UE-initiated Detach procedure for E-UTRAN as specified in TS 23.401

3b. EPS Detach Indication

Figure 12 UE-initiated Detach procedure

6.2.2 UC_D2: MME initiated

3. Remove SGs association

UE MME HSSMSC/VLR

1. Step 1 to step10 of MME-initiated detach as specified in TS 23.401

2b. IMSI Detach Indication

2a. EPS Detach Indication

4. Step 11 to step14 of MME-initiated detach as specified in TS 23.401

Figure 13 MME-initiated Detach procedure





6.2.3 UC_D3: HSS initiated

3. Remove SGs association

UE MME HSSMSC/VLR

1. Step 1a to step 7b of HSS-initiated detach as specified in TS 23.401

2. EPS Detach Indication

4. Step 8a to step 10a of HSS-initiated detach as specified in TS 23.401

Figure 14 HSS-initiated Detach procedure

6.3 Mobility Management

Figure 15 Mobility Management

The SGs interface is required is required for mobility management. The UE registers in both EPS & CS CN. Combined attach/detach and combined TA/LA updates are performed.

If UE, when CSFB takes place, is registered in wrong LA, it must do a LAU (with the penalty of an increases call setup delay)





MSC, at MT call, it must do “Roaming retry for CSFB” (further increases call setup delay) or the call fails without MSC pool deployment

6.3.1 UC_UP1: Combined TA/LA Update Procedure

2. TAU Request

4. Location Update Request

6. Location Update Accept

7. TAU Accept

UE new MME HSSMSC/VLR

5. Location update in CS domain

1. UE determines to perform TAU

old MME

3. Step 4 to step 19 of TAU procedure as specified in TS 23.401

8. TAU Complete

Figure 16 Combined TA/LA Update Procedure

1. UE needs to perform TAU

2. TAU is requested

3. Combined Tracking Area/Location Area Update Request or combined Tracking Area/Location Area Update with IMSI attach Request. "SMS-only" indication possible. Normal part of EPS TAU procedure

4. The MME allocates a LAI for the UE. If the association has to be established or if the LA changed, the new MME sends a Location Update Request (new LAI, IMSI, MME name, Location Update Type) message to the VLR. The MME retrieves the corresponding VLR number from the determined LAI. If multiple MSC/VLRs serve this LAI an IMSI hash function is used to retrieve the VLR number for the LAI.

5. The VLR performs Location Update procedure in CS domain.

6. The VLR responds with Location Update Accept (VLR TMSI) to the MME.





7. The MME sends a TAU Accept (parameters as specified in TS 23.401, LAI, VLR, and TMSI) message to the UE. The LAI indicates to the UE that it is IMSI attached.

6.3.2 UC_RR1: Roaming Retry for CSFB

In this case the MSC paging the UE is different from the MSC (does not belong to the MSC pool) where the UE does CSFB to. Roaming retry is performed5. This use case impacts GMSC, MSC/VLR and HLR and has impact on the call setup time.

5 5 The use of MSC pool allows minimizing the occurrence of MSC change at CS fallback. Only at MSC pool borders a LAU to a new MSC would take place.





GMSC HLR Old VMSC/VLR

New VMSC/VLR

MS

PRN (call ref.,GMSC@, Roaming retry) 2

PRN ACK (MSRN)SRI ACKIAM (MSRN) Paging

LocUpdate

Authentication ProcedureUpdate LocationCancel Location 3

Cancel Location Ack

RCH (call reference, roaming retry) Insert Subscriber Data (multiple)

Insert Subscriber Data (continued)Update Location Ack

Further procedures related to location update. e.g. ciphering, TMSI reallocation.PRN

New VMSC/VLR may delay setup until location update procedure finishes 8

PRN ACK (MSRN) 7

LocUpdate AcceptTMSI Reallocation Complete

Normal MT call procedure follows

Old MSC stops paging timer and inform GMSC

2nd SRI ACK (MSRN) 7

2nd SRI (B, basic call interrogation) 5REL RLCs 4

ACK

HLR delays the sending of PRN until location update procedure finishes 6

SAE/LTE

CSFallback

Setup

SRI (B, GMSC@,call Ref.,Roamingretry) 1

IAM (MSRN)

Call Confirmed

Figure 17 Roaming Retry for CS fallback

6.4 Mobile Originated Call

This procedure is executed in PS active mode when PS HO is not supported. The MO call case in idle mode is based on the active mode call flow.





UE/MS MMEBSS/RNS MSCeNodeB

2. Optional Measurement Report Solicitation

10b. Location Area Update

10a. Service Reject

10c. CS MO call

6. UE changes RAT then LA Update or Combined RA/LA Update or RA Update or LAU and RAU

3a. NACC,

5. S1 UE Context Release

1a. NAS Extended Service Request

SGW/PGW

4. S1-AP: S1 UE Context Release Request

1b. S1-AP UE Context Modification Request with CS Fallback indicator

7a. Suspend (see 23.060)

8. Update bearer(s)

SGSN

7b. Suspend Request / Response

11. Routing Area Update or Combined RA/LA Update

3b, 3c. RRC connection release

If the MSC is changed

1c. S1-AP UE Context Modification Response message

9. CM Service Request 9. A/Iu-cs message (with CM Service Request)

Figure 18 Mobile Originating call in Active Mode – No PS HO support

The UE is E-UTRAN RRC_CONNECTED. The user of the UE decides to perform a mobile originated CS call.

1a) The UE sends an extended service request to the MME.

1b) The MME sends a S1 UE Context Modification indicating CS Fallback required. UE should be moved to UTRAN/GSM.

1c) eNB response

2) eNB may optionally solicit a measurement report from the UE to determine the target GSM/UTRAN cell to which the redirection procedure will be performed.

Depending on licenses and UE capabilities a neighborhood frequency is selected (if in enhanced release with redirect feature a number of neighborhood cells are selected and for each neighborhood cell the System Information is added and sent to the UE).

3a) CCO n.a. in current implementation





3b) If the UE or the network does not support inter-RAT PS handover from E-UTRAN to GSM/UTRAN nor inter-RAT cell change order to GSM or the network does not wish to use these procedures:

The eNodeB can trigger RRC connection release with redirection to GSM or UTRAN.

3c) If the UE and network support "RRC connection release with redirection and Multi Cell System Information to GSM/UTRAN":

The eNodeB can trigger RRC connection release with redirection to GSM or UTRAN and include one or more physical cell identities and their associated System Information. (When RIM is available to provide SI)

4) The eNB sends an S1-AP UE Context Release Request message to the MME. If the target cell is GSM and either the target cell or the UE does not support DTM the message includes an indication that the UE is not available for the PS service.

5) The MME releases the UE Context in the eNodeB as well as all eNodeB related information in the S-GW.

Leaving LTE entering GSM/UTRAN

6a) CCO n.a. in current implementation

6b) if step 3b, RRC release with redirection, was performed:

The UE moves to the target RAT, identifies a suitable cell preferably of the same PLMN as received in LAI IE of combined EPS/IMSI Attach/TAU Accept message, receives the broadcast System Information and when it has the necessary information to access GSM/UTRAN, establishes a radio signaling connection

6c) if step 3c, RRC connection release with redirection and Multi Cell System Information, was performed:

The UE moves to the target RAT and identifies a suitable cell preferably of the same PLMN as received in LAI IE of combined EPS/IMSI Attach/TAU Accept message. The UE uses the NACC information and/or receives the broadcast System Information and when it has all of the necessary information to access GSM/UTRAN, the UE establishes the radio sign0061ling connection

6d) When the UE arrives at the target cell, if target RAT is UTRAN: The UE establishes the radio signaling connection by sending an RRC Initial Direct Transfer message that contains a NAS message. The CN Domain Indicator is set to "CS" in the Initial Direct Transfer message.





If target RAT is GSM A/Gb mode: The UE establishes a radio signaling connection (i.e. UE requests and is assigned a dedicated channel where it sends a SABM containing a NAS message to the BSS and the BSS responds by sending a UA). Upon receiving the SABM (containing the NAS message) the BSS sends a COMPLETE LAYER 3 INFORMATION message (containing the NAS message) to the MSC which indicates CS resources have been allocated in the GSM cell. After the establishment of the main signaling link the UE enters either Dual Transfer Mode or Dedicated Mode.

If the LA of the new cell is different from the one stored in the UE, the UE shall initiate a Location Area Update or a Combined RA/LA Update procedure. The UE shall set the "follow-on request" flag in the LAU Request in order to indicate to the MSC not to release the Iu/A connection after the LAU procedure is complete. Further the UE performs any Routing Area Update.

7) If the target RAT is GSM and DTM is not supported, the UE starts the Suspend procedure. This triggers the SGSN to send a Suspend Request message to the MME.

8) If the S1-AP UE Context Release Request message, received from the eNB in step 4, indicates that the UE is not available for the PS service in the target cell the MME starts the preservation and suspension of non-GBR bearers and the deactivation of GBR bearers towards S-GW and P-GW(s). The MME stores in the UE context that UE is in suspended status.

9) The UE continues with the MO call setup procedure with sending CM Service Request.

10a) If the UE is not registered in the MSC serving the GSM/WCDMA cell or the UE is not allowed in the LA, the MSC shall reject the service request, if implicit location update is not performed.

10b) A UE detecting that the MSC rejected the service request shall perform the Location Area Update or a Combined RA/LA procedure according to existing GSM or UTRAN procedures.

10c) The UE initiates the CS call establishment procedure.

6.4.1 UC_MO1: CSFB using Release with Redirect

Mobile originated call according to the architecture in Figure 2.





6.4.2 UC_MO3: CSFB using enhanced Release with Redirect, RIM

The CSFB handling is enhanced with additional information according to Figure 3. System Information of WCDMA and GSM target cells is automatically provided with the standardized RIM procedures from GSM/WCDMA to the eNB. The eNB signals a list of target cells and the system information to the UE.

6.4.3 UC_MO4: CSFB with PSHO

The CSFB handling is enhanced with additional information according to Figure 4. The resources in the WCDMA and GSM target cells are prepared before CSFB.

6.4.4 UC_MO_5: Emergency Call

When UE is performing CS fallback procedure for Mobile Originating Call for the purpose of emergency call, it shall indicate to the MME that this CS fallback request is for emergency purpose. MME also indicates to the E-UTRAN that this CS fallback procedure is for emergency purpose.

6.5 Mobile Terminated Call

This procedure is executed in PS active mode when PS HO is not supported. The MT call case in idle mode is based on the active mode call flow.





IF THE MSC IS CHANGED

UE/MS MME MSC

3a. CCO/NACC, 3b, 3c. Signalling connection release

eNodeB

2. Optional Measurement Report

9. Paging Response

9c. Location Area Update or Combined RA/LA Update

9b. Signalling Connection Release

S-GW/PGW

1b. NAS Extended Service Request

1d. S1-AP UE Context Modification Request with CS Fallback indicator

1c. CS Paging Reject

7a. Suspend (see TS 23.060)

8. Update bearer(s)7b. Suspend Request / Response

9b. CONNECTION REJECT

1A. CS SERVICE NOTIFICATION 1A. PAGING REQUEST

SGSN

6.UE changes RAT then, LAU OR COMBINED RA/LA UPDATE OR RA UPDATE OR LAU AND RAU

5. S1 UE CONTEXT RELEASE

BSS/RNS

4. S1-AP: S1 UE CONTEXT RELEASE REQUEST

1A. SERVICE REQUEST

1e. S1-AP UE Context Modification Response message

9a. Establish CS connection

Figure 19 Mobile Terminating call in Active Mode - No PS HO support

6.5.1 UC_MT1: CSFB using Release with Redirect

See 6.4.1.

6.5.2 UC_MT3: CSFB using enhanced Release with Redirect, RIM

See 6.4.2.

6.5.3 UC_MT4: CSFB with PSHO

See 6.4.3.

6.6 UC_R1: Return back to E-UTRAN

No specific CSFB mechanisms are needed to steer the UE back to LTE. If the EPS bearers were suspended they are now continued.





MMEeNodeB

1. NAS message

3. Handling NAS message

S-GW/P-GW

2. Resume/Modify Bearers

UE/MS

Figure 20 Return to LTE

6.7 UC_RS1: MME Restart

MME restarts. After restart the MSC is informed about the restart.

6.8 UC_RS2: MSC Restart

MSC restarts. After restart the MME is informed about the restart.

6.9 UC_MOSMS1: Mobile Originated SMS, idle Mode

For SMS over SGs no CSFB is needed. Instead the UE forwards the SMS via the MME to the MSC. From there the SMS handling is done according to legacy procedures.





MS/UE MME MSC/VLR HLR/HSS SMS-IWMSC SC

1. EPS/IMSI attach procedure

3. Uplink NAS Transport4. Uplink Unitdata

5. Forward Short Message

6. Message transfer

7. Delivery report8. Delivery report

9. Downlink Unitdata

10. Downlink NAS Transport

2. UE triggered Service Request

4a. Downlink Unitdata

4a. Downlink NAS Transport

11. Uplink NAS Transport

12. Uplink Unitdata

13. Release Request

Figure 21 Mobile originating SMS in Idle Mode

6.10 UC_MOSMS2: Mobile Originated SMS, active Mode

The procedure is identical with the idle mode procedure leaving out step 1 and 2.

6.11 UC_MTSMS1: Mobile Terminated SMS

SMS-

2. Message transfer 3. Send Routeing Info For Short Message

4. Forward Short Message5. Paging 6. Paging7. Paging

9b. Downlink NAS Transport9c. Uplink NAS Transport

13. Delivery report 12. Delivery report

8. Service Request

MS/UE eNodeB MSC/VLR HLR/HSS SMS-MME SMS-GMSC SC

1. EPS/IMSI attach procedure

8a. Service Request

9d. Uplink Unitdata

10. Uplink NAS Transport 11. Uplink Unitdata

14. Downlink Unitdata

16. Release Request

15. Downlink NAS Transport

9a. Downlink Unitdata





Figure 22 Mobile terminating SMS in idle mode

7 End-to-End Solution

The following chapters describe the planned and missing functionality of the different products until 2012. The intention is to cross-check if the specific features needed for CSFB and SMS over SGs and their optimization fit from an end-to-end perspective and to define new requirements for any mismatch.

7.1 LTE RAN

CSFB is supported from LTE TDD/FDD and can be performed to GSM and WCDMA and CDMA. CSFB to CDMA needs special UEs with dual radios and is not covered in this study, see [17].

The operator will have to make sure that suitable IRAT neighbor cells are defined in the LTE model so that the eNB can select suitable target IRAT cells for CSFB. In case it is possible to perform CSFB to both WCDMA and GSM the operator will have the ability to determine what RAT should have priority over the other. This information will then be used by the eNB when the set of possible target cells are selected. Note that CSFB can only be performed to one RAT at a time.

7.1.1 Targeted 3GPP Use Cases

The following sequences from [1] are planned to be implemented, "Mobile Terminating Call in idle mode", "Mobile Terminating call in active mode - no PS HO Support", "Mobile Originating call in active mode - no PS HO Support" and "Mobile Originating call in idle mode".

7.1.2 CSFB by RRC Connection Release with Redirect

CSFB will be performed by the LTE eNB sending the UE a release with redirect RRC message directing the UE to another RAT. There are different ways available to improve access times in other RATs, e.g. UTRAN Deferred Measurements or by supplying the target RAT system information to the UE.

Possible target IRAT cells will be modeled in the eNB, either manually by the operator or automatically by the ANR feature. Control of preferred CSFB IRAT will be controlled by the operator.





7.1.2.1 CSFB by RRC Connection Release with Redirect with System Information available in LTE

By making the WCDMA/GSM system information available to the eNB it is possible to reduce the setup times necessary for the CSFB by allowing the eNB to transmit this information to the UE in the Release with Redirect message so that the UEs don’t have to retrieve this information from the target RAT.

It is important for CSFB that the target IRAT system information is correct since faulty system information would cause the UE to return back to LTE, thus causing the CSFB to fail. So in order for this approach to work there must be a reliable system information delivery mechanism that makes it possible for the eNB to always have correct system information. This can e.g. be done by the 3GPP specified RIM procedures. This would enable the eNB to supply the correct system information to the UE and this would enable the UE to access the target RAT without having to read the target system information and be able to access the target RAT more quickly.

Note that since reducing the call setup time is important for CSFB the eNB will not initiate any measurements from the UE to determine what IRAT cell should be selected so all possible IRAT cell candidates needs to be included in the RRC message. This might be an issue if there are many external neighborhood cells. This would result in a very large RRC Release with Redirect message. If the UE is in bad LTE coverage very large RRC messages might result in that the UE is lost resulting in a failed CSFB.

7.1.2.2 RIM

As mentioned above, it is important that the system information for the target IRAT that is transmitted from the eNB is correct because it is vital for CSFB that the system information is correct. There exist a 3GPP specified solution, RIM procedures, that allows an eNB to create a logical connection to an external GSM/WCDMA cell. When the eNB has created the connection to the external GSM/WCDMA cell the RNC/BSC responsible for that cell will automatically notify the eNB whenever the system information for the external cell is changed.

This requires support in both the eNB, MME, SGSN, RNC and BSC. The RNC/BSC is responsible for creating and distributing the system information to the eNB and the MME/SGSN are responsible for routing the RIM messages correctly in the network.

RIM has not yet been studied in LTE





7.1.3 CSFB with PSHO

CSFB with PSHO has not been studied in LTE yet since the call setup times in CSFB with PSHO are longer than those based on RRC Release with Redirect with system information. Also it is questionable if the operator would rollout another option of CSFB after RRC release with redirect. Still PSHO has a better performance for PS sessions with a shorter interruption time.

7.1.4 Return to LTE

Once the UE is moved to the target RAT it is up to that RAT to release the UE back to LTE. Once the UE becomes idle it will perform a cell reselection and, if possible, reconnect to LTE. If the UE do not become idle after the CS session has been terminated, because additional PS services have been acquired in the other RAT, it is not clearly defined when the UE is returned to LTE. For GERAN a solution exists.

7.1.5 CSFB for Emergency calls

LTE will not handle emergency calls in a different way. The eNB will preserve any emergency call flags, if any, received from the UE so that the core network can handle the emergency calls as quickly as possible. Emergency call setup is being studied in a parallel LTE study.

7.1.6 Non-CS speech CSFB

CSFB has only been investigated for CS voice services in LTE.

7.2 WCDMA

7.2.1 CSFB by RRC Connection Release with Redirect

CSFB by RRC Release with Redirect will work without any impact on WCDMA. To improve the CSFB call setup time either of two functions may be introduced that substantially decreases the time to read system information in WCDMA. These are “Deferred measurement control UTRAN support” and to make WCDMA system information available in LTE through the RIM procedure.





7.2.1.1 Deferred Measurement Control

To decrease CSFB call setup time one possible improvement would be to decrease the time to read system information in WCDMA. This could be done in different ways. One option is to avoid reading SIBs with information that can be received at another occasion. Such information is included in SIB11 and 12. The SIB 11 includes measurement control and neighboring cell list. As soon as a call is setup in Ericsson WCDMA, intra frequency measurements are started and the information in SIB11 information is retransmitted to the UE. The information in SIB12 regards traffic volume measurements and is only used in CELL_FACH, where SIB12 also may be read.

To tell the UE that it is OK to skip reading SIB11 and 12 an indication is needed in SIB3, stating that this WCDMA NW supports “Deferred Measurement Control”. The maximum time for reading system information without this indication is 1280ms; omitting SIB11 and 12 would decrease this worst case time to 640ms.

Today it takes 1280ms to read all SIBs. If indicating the support of “Deferred Measurement Control” in SIB3 the reading of SIB11 and 12 can be omitted. That would from W11 mean that the time to read system information may be decreased to 640ms.

7.2.2 CSFB by RRC Connection Release with Redirect with System Information available in LTE

7.2.2.1 UTRA SI RIM application

Another way to decrease the CSFB call setup time is to avoid reading all system information. With the UTRA SI RIM application it would be possible to send system information of WCDMA to LTE to be stored in the eNodeB. The system information may then be included in the RRC Connection Release with redirect to UTRAN, message. The UE would only need to read SIB7 when arriving to WCDMA, all other SIBs may be omitted and the complete CS call setup time would be reduced.

The system information of WCDMA would be sent in transparent System Information Container messages from the RNC to the eNodeB at the request from eNodeB. If requested all updates to WCDMA system information may be sent automatically.

The aim in 3GPP is to include a complete specification of the UTRA SI RIM application for CSFB in 3GPP release 9.

The UTRA SI RIM application is currently not part of the WCDMA product roadmap.





7.2.3 CSFB with PSHO

7.2.3.1 General IRAT LTE to WCDMA PSHO

The IRAT PS handover feature introduces procedures in WCDMA to reserve resources for a PS data stream in the target WCDMA cell, while the UE is still connected to LTE, thereby minimizing the PS data interruption time.

The IRAT PS handover function consists of a preparation phase and an execution phase. In the preparation phase handover evaluation is done in LTE system and resources are reserved in WCDMA. In the execution phase the UE disconnects from LTE and reconnects in WCDMA using the configuration signaled by the network.

There is no a priori knowledge in WCDMA of the allowed combinations of the PS bearers in LTE. The mapping between WCDMA RABs and EPS bearers is performed by the CN. WCDMA may accept the IRAT PS HO request even if no PS resources are available, only the SRB will then be accepted for HO.

7.2.3.2 CSFB by PS HO

Incoming IRAT PSHO from LTE to WCDMA is currently in the prestudy phase in WCDMA [15] and planned for W12. So is also the usage of PSHO for CSFB.

After the PSHO the CSFB UE attempts to establish CS speech.

From the point when the UE sends the signal “HO to UTRAN Complete” to the RNC, in the HO Execution phase, the rest of the CSFB procedure according to 23.272 and the IRAT PSHO sequence according to 23.401 are done in parallel without any synchronization between the PS and the CS domain.

The cause code “CS Fall back triggered” sent to the RNC in the Relocation Request message in the handover preparation phase. Here the RNC get’s the information that this handover is due to CSFB. This makes it possible for the RNC to treat the PSHO in a special way if that may enhance performance. The PSHO can be prioritized and admitted even if the PS resources in the WCDMA cell are scarce, in order to make it possible to establish the CS call. The CS call setup will be admitted by the same rules as any other WCDMA CS call. If CS speech cannot be set-up the UE re-tries.

A prioritization of RABs included in RANAP Relocation Request will be required in order to find a “best-possible” RAB combination if not all RABs may be accepted. ARP values will be used as priority measure. A PSHO outcome can thus be partially successful, but even so the CSFB call can be set up.





7.2.4 Return to LTE

If the UE has an active PS connection in Cell_DCH or Cell_FACH in WCDMA it will stay there as long as there is an ongoing communication. When the PS connection becomes inactive the UE goes to URA_PCH or Idle and returns to LTE by Idle Mode Cell Reselection, given that LTE has been set as the preferred RAT in the broadcast information in WCDMA.

UTRAN E-UTRA

Con

nect

ed m

odes

CELL_DCH

CELL_FACH

URA_PCH

Idle mode

RRC Connected

RRC Idle

Packet Switched Handover from

LTE

Idle Mode Cell Reselection

Figure 23. UE states and transitions between states from WCDMA to LTE

Inactivity timers are regulating the UE states when the PS connection becomes inactive. These are operator configurable and typical values seen today are 2 seconds for down switch to Cell_FACH and 10-30 seconds for down switch from Cell_FACH to URA_PCH. This could mean that it could take 12-32 seconds of PS inactivity before the UE can return to LTE. However it is expected that operators that deploy LTE will use short inactivity timer in Cell_FACH.

One way to improve this is to have separate inactivity timers for LTE capable UEs. Then the time in CELL_FACH and if needed also in CELL_DCH could be substantially shortened and the UE would return faster to LTE.

To send the UE back to LTE when still having an active PS connection there are several options, but only the PSHO back to LTE minimizes the PS outage. The PSHO from WCDMA to LTE is not planned in the WCDMA and LTE product road map.





Another possibility to send the UE back as soon as possible is to simply release the RRC Connection and then the UE will go to idle and return by Idle Mode Cell Reselection. This would however cause a PS outage of maybe 500ms. RRC connection Release with Redirect back is almost the same option. The question is if it is the PS outage when moving could always be compensated by the higher bitrates available in E_UTRA, or could it in some cases be better to wait for inactivity, e.g. at a video sequence.

None of these features are planned within the WCDMA roadmap.

A new trigger would be needed to trigger either RRC Connection Release with or without Redirect or IRAT PSHO back to LTE. This trigger is preferably based on the ending of the CS call in combination with the LTE capability of the UE. However this may impact future load sharing solutions between WCDMA and LTE and has therefore to be further studied.

7.2.5 CSFB for Emergency calls

It is assumed that no special procedures are applied to support CSFB for Emergency calls. A CSFB emergency called will be prioritized in the same way as a native WCDMA CS emergency call.

7.2.6 Non-CS speech CSFB

CSFB is mainly intended for CS speech but 3GPP (TS 23.272) does not exclude fallback for other CS services, i.e. CS Conversational 64/64. Such set-up attempts will be treated according to legacy, regarding to allowed RAB combinations etc. No separate treatment.

7.3 GSM

7.3.1 RIM from GSM to LTE

This feature introduces the transfer of the relevant System Information from GSM to LTE via the core network. This feature has been introduced in the Rel-8 GSM specifications (see 3GPP TS 48.018). Support in the product is planned to be introduced in G12A.





7.3.2 Fast Return to LTE

This feature enables a faster re-selection to LTE at TCH/SDCCH release, i.e. when a service over a CS connection is terminated. Support for this functionality has been introduced in the Rel-8 GSM specifications (see 3GPP TS 44.018 and 3GPP TS 45.008)). It is currently planned to be introduced in the product in G12A.

In case that the CS connection of the DTM operation is released then the MS will automatically drop the PS connection. This means that the MS will obey a redirection information if provided at TCH release. Hence the behavior is very similar to the ordinary case of a plain CS connection release.

7.4 Evolved Packet Core Solution

7.4.1 Features description from the MME perspective

The features supported are the CSFB from LTE to GSM/WCDMA and SMS over SGs. The CSFB to 1xRTT will be implemented prior to GSM/WCDMA Fallback in the MME, though it is not the subject for this study.

The main impact for implementing these functions in the EPC is in the MME, though also the SGW and PGW have impacts. It is assumed that PCC is not impacted. In order that deployment of LTE with CSFB shall be possible without updates to the installed GPRS NW, it is a basis for the specification of the feature that the Gn/Gp SGSN will not be impacted. There may be impacts to SGSN-W due to RIM/NACC (UTRA SI) to WCDMA, which may be used independently of CSFB. SGSN-G already supports RIM/NACC. For the S4-SGSN there will be impacts to CSFB when combined with the Idle Mode Signaling Reduction (ISR) feature.

SMS over SGs is implemented first and used as a basis for CSFB implementation for the MME.





7.4.2 SMS over SGs

7.4.2.1 Function description

The SMS over SGs function enables SMS to the UE in LTE without CSFB needed while keeping the radio access in LTE. The UE registers to CS domain via MME and MSC using combined EPS/IMSI attach procedure. The MME updates and maintains the UE location towards the MSC. The UE may send or receive Mobile originated (MO) or terminated (MT) SMS in idle or active mode (active PS bearer) through the MME via the SGs interface and using S1-NAS transport. Paging is required for mobile terminated SMS (DL) if the UE is in idle mode.

The SMS over SGs function is implemented in the MME before CSFB to GSM/WCDMA.

7.4.2.2 Procedures affecting the EPC for SMS over SGs

7.4.2.2.1 Attach (UC_A1)At combined Attach or TAU a LAU procedure towards the MSC is performed and the SGs association is created. MME will have support on the SGs only for LTE-SMS purpose. A combined attachment will be accepted if it includes support for SMS from the UE, e.g. indicated through “SMS-only”- indication to the MME for IMSI registration and the MME will respond with ‘SMS-only’.

For a UE not previously associated to an MSC the MME needs to perform a Location update to the selected MSC.

7.4.2.2.2 Detach (UC_D1, UC_D2)

Once associated to an MSC the UE will remain associated until either EPS Detached or IMSI Detached.

7.4.2.2.3 MT SMS (UC_MTSMS1)

MT SMS according to 3GPP is performed.

The MME specifics for MT SMS in IDLE and ECM_CONNECTED states, in addition to what is described in section 6.11 above, are:

The MME receives a Paging (IMSI, VLR TMSI, Location Information, Service Indicator=SMS indicator) message.





After receiving the Serving Request from the UE, the MME sends a Service Request message to the MSC and adds the IMEISV, the local time zone, the Mobile Station Classmark 2, and the UE’s current TAI and E-CGI.

The MME receives the SMS message in a Downlink Unit data message from the MSC/VLR.

MME forwards the UE acknowledge receipt of the SMS to the MSC/VLR.

After the last part of the SMS the MME forwards the delivery report to the MSC/VLR in an Uplink Unit data message, which acknowledges receipt of the delivery report to the UE.

The MME receives from MSC a Release Request message, indicating that no more NAS messages need to be tunneled.

If an SGs based MT SMS delivery attempt fails, the MSC/VLR shall send an SGs interface Alert Request message to the MME, causing the Non-EPS Alert Flag, NEAF to be set. Subsequently, if the UE makes radio contact with the MME, the MME sends an SGsAP UE-Activity-Indication message to the MSC/VLR (and resets the NEAF).

The MME will reject incoming voice calls for UEs attached for SMS-only.

7.4.2.2.4 MO SMS (UC_MOSMS1, UC_MOSMS2)

MO SMS according to 3GPP is performed.

The MME specifics for MO SMS in IDLE and ECM_CONNECTED states are:

After receiving the SMS from the UE, the MME forwards the SMS message to the MSC/VLR in an Uplink Unit data message. The MME adds the IMEISV, the local time zone, the Mobile Station Classmark 2, and the UE’s current TAI and E-CGI.

The MME receives the received delivery report associated with the UE in a Downlink Unit data message.

After receiving delivery report ACK from the UE, the MME forwards it to the MSC.

The MME expects that the MSC/VLR indicates to the MME that no more NAS messages need to be tunneled by sending a Release Request message.





7.4.2.2.5 TAU/RAU (UC_UP1)

Configuration of multiple MSCs, MSC-LA and TA-LA mapping will be supported in 2010B:

Handling of combined TAU and MSC selection

Interfering cases e.g. change of LA during LA Update

MSC Pool is not supported before 2011A at earliest.

7.4.2.2.6 MSC/VLR restart handling

To be able to maintain the UEs SGs associations, refresh of these are required in case of restart of the serving MSC i.e. MME must handle and act upon a reset signal from the MSC/VLR. Possibly this is also the case of an HSS restart.

7.4.3 CSFB

7.4.3.1 Function description

The CSFB function allows a UE in LTE to fall back to GSM/WCDMA to perform a CS call. The UE attaches to the CS domain (VLR) via the MME. The MME finds the MSS (from IMSI inspection and configuration) and forwards the attach to the MSC over the SGs interface. When the UE is attached it can be paged from the MSC over SGs for MT call. The UE may also initiate MO call using CSFB to GSM/WCDMA. When doing the MO or MT call the UE switches from LTE access to GSM/WCDMA access. The UE may access the GSM/WCDMA radio cell using different levels of NW support. The target GSM/WCDMA system and the UE both need to support DTM else the access in the target system will be non-DTM. In case of DTM, PS services may continue in the target system. For non-DTM access in the target system, the PS services are suspended. After the CS call is finished, the UE may switch back to LTE or remain in GSM/WCDMA. In case of non-DTM, the PS service resumes. When the UE moves around in LTE in active or idle mode, the MME needs to do location update towards the MSC.

The 3GPP Rel 9 specification allows for several options. It is clarified which options are applicable to be implemented. Note that CSFB as specified in 3GPP Rel 8 is not complete and can’t be used as a basis or products.

Function Comments

CSFB to WCDMA (Idle





mode)

CSFB to GSM (No DTM Support)

MME will deactivate the PDN Connections in the EPC (Idle, Active Mode); (no 3GPP support for Suspend/Resume in first version; Suspend/Resume is planned for 2011A)6,

CSFB to GSM (DTM Support) ;

CSFB to WCDMA with NACC (Idle, Active Mode);

Today no support for RIM in SGSN-W.RIM/NACC in SGSN-W and in MME planned for 2011A

CSFB to GSM with NACC (DTM support);

Today already support for RIM in SGSN-G;RIM/NACC in MME planned for 2011A

Table 4 MME priorities for supporting the CSFB solution.

The SGs interface in MME needs to be enhanced from supporting only SMS to full CS Fallback functionality. The protocol for SGs is SGsAP/SCTP/IP.

7.4.3.2 Procedures affecting the EPC for CSFB

7.4.3.2.1 Attach (UC_A1)

The MME secures and maintains dual registration in LTE and WCDMA/GSM CS over SGs. It supports combined procedures at Attach, the Combined EPS and IMSI attach. The MME derives a VLR number and LAI from the GUTI received from the UE or from a default LAI (NOTE: the MSC must receive a correct LAI for CSFB). MSC selection and maintaining of SGs association towards MSC/VLR for EPS/IMSI attached UE is performed.

Operator controlled configuration of network provision of “SMS-Only” or “CSFB Not Preferred” is not supported. Hence the option that the MME can respond with “CSFB Not Preferred” is not supported, i.e. for CSFB the MME includes no parameter in the response

7.4.3.2.2 Detach (UC_D1, UC_D2)

Initiating IMSI detach at EPS detach and support for combined procedures at Detach. All Detach procedures supported.

6 6 If the UE is deactivated or if the MME does nothing in the non-DTM CSFB case is subject to operator policy





7.4.3.2.3 MT/MO CSFB (UC_MO1, UC_MT1)

Handling Extended Service Request from UE with CS Fallback Indicator and sending CS Fallback Indicator to eNB.

Operator controlled TA List Strategy configuration is not supported. Currently the MME supports the normal usage of “the tracking area list” concept according to TS 23.272 9.3.0; this means that the TAI list allocation is not verified or adjusted in the MME for CS fallback mobiles to provide "TAI lists that do not span multiple LAs" i.e. a TAI-list provided to the UE may cross an LA boundary! However, the operator constructs the lists in DNS configuration, and can make sure the TAI-lists don’t cross the LA border.

Suspend for Non-DTM case is not supported in first release; MME uses Detach without UE involvement. Suspend/Resume in MME is planned for 2011A. See discussion below.

When Suspend/Resume will be used, the SGW/PGW needs to implement suspend and resume functions. SGW remembers that the UE is suspended, and needs to resume the PGW also when implicit resume is done by the MME.

S4-SGSN and Gn/GP SGSN implements new support for NACC (both for WCDMA and GSM, see [5])

In addition, for MT CSFB, MME may initiate paging procedure towards eNodeB when MSC pages the UE for CS services depending if the UE is IDLE or CONNECTED. The MME may receive the LA from the MSC in the Page message, but it is actually not used by the MME except after a restart, see below. The MME pages the UE in the TAs of the TA list. The MME receives CLI information (A-number) in the Page request from the MSC. Depending if the UE is in IDLE or CONNECTED state the CLI will be sent to the UE (in IDLE the UE is paged and can not receive the CLI).

7.4.3.2.4 TAU/RAU procedures (UC_UP1)

Support of combined procedures at TA/LA Update

MME communicates with MSC and in this performs TA/LA mapping and finds MSC by information configured in the MME and transfers mobility information, Location Update to MSC (LAU). The LA is included in the LAU, since it is needed by the MSC for TMSI allocation.

7.4.4 SGs messages





Necessary SGs message

Comment

SGsAP-ALERT-ACKSGsAP-ALERT-REJECTSGsAP-ALERT-REQUESTSGsAP-DOWNLINK-UNITDATASGsAP-EPS-DETACH-ACKSGsAP-EPS-DETACH-INDICATIONSGsAP-IMSI-DETACH-ACKSGsAP-IMSI-DETACH-INDICATIONSGsAP-LOCATION-UPDATE-ACCEPTSGsAP-LOCATION-UPDATE-REJECTSGsAP-LOCATION-UPDATE-REQUESTSGsAP-MM-INFORMATION-REQUEST Will not be supported, such request

will be ignored.SGsAP-PAGING-REJECTSGsAP-PAGING-REQUESTSGsAP-RESET-ACKSGsAP-RESET-INDICATION Not sent to MSC, but when

received from MSC it is usedSGsAP-SERVICE-REQUESTSGsAP-STATUSSGsAP-TMSI-REALLOCATION-COMPLETESGsAP-UE-ACTIVITY-INDICATIONSGsAP-UE-UNREACHABLESGsAP-UPLINK-UNITDATASGsAP-RELEASE-REQUEST

Table 5 SGs messages in MME

7.4.5 Other Issues

7.4.5.1 LA/TA mapping:

LA/TA mapping will be configured in the MME. The UE may move inside a group of TAs included in the TA list without performing TAU. A number of TAs will be mapped to a LA. The TAs or the TA lists should not intersect the LA border. In this way several benefits are gained: the LAU may be done when the UE performs TAU; the paging in TAs will be done inside the LA; the UE will be in the correct MSC when doing CSFB, thus minimizing the need for Roaming Retry.

The LA/TA mapping will be introduced step-wise:





After the ‘SMS over SGS’ ph2 feature, a mapping between an LA and limited number of TAs exist thus implying paging possibility in a smaller area.

MME shall support 64 VLRs. From 2010B multiple MSC as well as multiple LAs will be supported.

TA-LA-VLR node (IP) address mapping will be done. Only one MSC per LA will be supported (i.e. no support for MSC pool, MSC

pool will be supported after 2011B). Mapping of several LAs per MSC. Mapping of one or several TAs per LA (but

only one LA per TA), i.e. a strict hierarchical structure of MSCs, LAs and TAs will be implemented.

7.4.5.2 MME Restart: At restart of MME no reset indication will be sent to the MSC hence no

specific handling of MME reset for the SGs interface and SGs associations. (Due to 3GPP TS 29.118, CR34, sending reset from MME to MSC is no longer mandatory). At restart of the MME, the UE will perform a re-attach as soon as the UE tries periodic update or Service request and the LAU will be sent to the MSC. Prior to that the MME will (from 2011A or 2010B when multiple LAs are supported) IMSI page the UE in the LA, if LAI is received from the MSC. If the LAI is not included the Page Request will be rejected, i.e. global page is not supported in the MME.

7.4.5.3 Data Forwarding for PS HO: Support for indirect data forwarding is currently not planned for the MME. EPC control signaling is required also to achieve direct forwarding, except for

X2-HO, which applies to LTE only. In principle, the control signaling is supported for S1-based HO (within LTE). However, there are limitations that makes direct forwarding not work (reflected by 36.413 SoC).When support for IRAT handover is implemented it should be possible to remove this limitation.

Bi-casting from SGW may be used as an alternative function when data forwarding is not implemented. Unlike Data Forwarding, bi-casting is not specified by 3GPP. At the moment, bi-casting is not in the EPC roadmap.

7.4.5.4 Suspend/resume:

Suspend/Resume towards SGW/PGW is done for non-GBR bearers in case of CSFB with non-DTM support in the target system. In order for the MME to be able to suspend the UE it is crucial to rely on the Cause code received from the eNB. The cause code can take 2 values, see table Table 6.

Cause value MME interpretation CSFB triggered UE does CSFB and DTM will be used





in the target system UE not available for PS Service UE does CSFB and non-DTM is used

in the target system (MME needs to do suspend/deactivate of bearers)

Table 6 Cause codes

7.4.5.5 ISR:

According to the EPC Road Map, ISR will be implemented in the MME in 2012B. If CS Fallback shall be supported at the same time as ISR, additional MME functionality may be required. However, a recent 3GPP update to 23.272 indicates that the UE shall deactivate ISR after doing RAU or combined RA/LA Update to an SGSN.

7.4.5.6 PS Handover:

PS HO with CSFB is planned in the MME in 2012B.

7.5 BNET Mobile Softswitch Solution

In MSS CS Fallback consists by two separate features “SMS over SGs-interface” “LTE to CS Fallback”.

The features “SMS over SGs-interface” and “LTE to CS Fallback” are supported in node types MSC/VLR, MSC-S DB and MSC-S BC. In MSC/VLR additional hardware (GESP board) is needed to be able to support these features. To use IP on CP for SGsAP on monolithic MSC/VLR nodes, each MSC/VLR has to be enhanced to support the IP connectivity from CP to the site. This mandates for security reasons to introduce one additional GESP board as demarcation line between the node and the site. The MSC/VLR (with IPonCP support) is able to support up to 80 MME nodes.

The features “SMS over SGs-interface” and “LTE to CS Fallback” are applicable for all markets.

The implementation of both features is based on 3GPP Release 9 standards.

The assumed design base release is MSC R14.1. The assumed target release is MSC 12 A.





7.5.1 SGs interface

A prerequisite for CS Fallback is that the UE is registered in the MSC while being attached to E-UTRAN and registered in the MME. This is achieved by using combined Mobility Management procedures for EPS and CS.

For this purpose a specific interface is used between the MSC and the MME, called SGs-interface. The protocol used on the SGs-interface is called SGsAP and it uses SCTP over IP for transport.

The SGsAP protocol provides procedures for Mobility Management, Paging and SMS. SGsAP is based on the BSSAP+ protocol used at the Gs-interface, which connects the MSC and SGSN. In contrast to BSSAP+, the SGsAP support procedures for SMS. Another difference is the type of transport.

Additionally, 3GPP has specified a special SMS handling. SMS can be sent via the SGs-interface without doing a fallback to CS. UEs that are interested in SMS but not in other CS services (e.g. Laptop cards) have the possibility to attach with an SMS only option to E-UTRAN. Such a UE is able to use the special SMS handling without the need to support the fallback to CS. This was the driver for commercially separating the CS fallback in the two features mentioned above.

“SMS over SGs-interface” covers the support of the SGs-interface, the Mobility Management procedures and the SMS handling for EPS attached subscribers.

“LTE to CS Fallback” covers the support of Calls, Call Independent Supplementary Services (CISS) and Location Services (LCS) for EPS attached subscribers.

The activation of “SMS over SGs-interface” is a prerequisite for the activation of “LTE to CS Fallback”. Both features have to be activated to have full support of CS Fallback according to 3GPP.

If only “SMS over SGs-interface” is activated and “LTE to CS Fallback” is not available or activated, then the MSC will reject mobile terminating Call, CISS and LCS transactions for EPS attached subscribers

All SGsAP messages according to Table 5 are supported.





7.5.1.1 Common procedures for “SMS over SGs-interface” and “LTE to CS Fallback”

7.5.1.1.1 Location Update for non-EPS services

The procedure Location Update for non-EPS services7 is a general procedure used by CS Fallback capable UEs and by UEs requesting SMS delivery via the CS core network. If the procedure is successfully executed, a SGs association is established between the MME and the MSC for the applicable UE. Then this UE registered in the MME and in the MSC and it is reachable for CS services.

This procedure allows the UE and MME to perform: Combined IMSI attach for EPS and non-EPS (CS) services Combined IMSI attach for EPS and SMS only service8

IMSI attach for non-EPS (CS) services, if the UE is already attached for EPS services

IMSI attach for SMS only service, if the UE is already attached for EPS services

Combined Tracking Area/Location Update procedure, if the UE is attached to both, EPS and non-EPS (CS) services

Combined Tracking Area/Location Update procedure, if the UE is attached to both, EPS and SMS only service

Allocation of a new TMSI

The different types of IMSI attach in the first four bullets can not be distinguished by the MSC. In all four cases the subscriber will be marked as EPS attached (and IMSI attached) in the MSC/VLR.

Security related functions like authentication, ciphering and IMEI check are completely performed in EPS.

If a UE is successfully registered for EPS and non-EPS (CS) services or SMS only service, then periodic Location Update is not performed. Only periodic Tracking Area Updates are initiated by the UE. Therefore, the MSC does not initiate any time supervision for implicit detachment and automatic deregistration for EPS attached subscribers.

If a Location Update for non-EPS (CS) services has been initiated, the MME sends the SGsAP LOCATION UPDATE REQUEST message to the MSC.

On reception of the SGsAP LOCATION UPDATE REQUEST message, the MSC performs the Location Update in the same way as it is done for A- or Iu-interface.

7 7 The term “non-EPS services” is used in 3GPP specifications and means “CS services” in this context.8 8 SMS only service is a subset of non-EPS (CS) services, only using the SMS mechanism towards the CS domain.





If the Location Update is accepted by the MSC, it stores the received LAI in the MSC/VLR updates the SGs association by storing the MME name in the VLR marks the subscriber as IMSI attached and EPS attached in the VLR stops the time supervision for implicit detachment and automatic

deregistration replies to the MME with the SGsAP LOCATION UPDATE ACCEPT message

If the subscriber is marked as GPRS attached, then the MSC removes the Gs association and marks the subscriber as GPRS detached in the MSC/VLR. EPS and GPRS attachments are mutually exclusive.

Then the MSC/VLR updates the HLR with the new VLR address by sending MAP UPDATE LOCATION message. The HLR sends the subscriber data trough the use of MAP INSERT SUBSCRIBER DATA message and acknowledges the location update process by sending MAP UPDATE LOCATION ACK. The update location of the HLR is in any way differentiated from the update location triggered from A or Iu access.

If the Location Update is not accepted by the MSC, it sends the SGsAP LOCATION UPDATE REJECT message to the MME. The SGs association is removed and the subscriber is marked as EPS detached in MSC/VLR.

The MSC/VLR depending on exchange parameter settings may perform TMSI reallocation and TMSI de-allocation. If a new TMSI is allocated, the MSC includes the TMSI (in “New TMSI, or IMSI” IE) in the LOCATION UPDATE ACCEPT message and wait for the SGsAP TMSI REALLOCATION COMPLETE message from the MME. If the TMSI has been de-allocated, the MSC shall include the IMSI (in “New TMSI, or IMSI” IE) in the LOCATION UPDATE ACCEPT message.

On reception of the SGsAP TMSI REALLOCATION COMPLETE message the TMSI Reallocation is considered as successfully finished.

In case that the MSC/VLR receives a Location Update from A-, Iu- or Gs-interface for a subscriber that is marked EPS attached, then the MSC marks subscriber as EPS detached in VLR removes the SGs association starts the time supervision for implicit detachment and automatic

deregistration stops any possible ongoing Location Update at SGs-interface





7.5.1.1.2 EPS MME initiated Detach procedure

The MME sends the SGsAP EPS DETACH INDICATION to the MSC to inform that the UE has been detached from EPS services. The UE may be detached from EPS services for the following reasons: The MME receives a detach for EPS from the UE. The MME performs a network initiated EPS detach. The combined Tracking Area/Location Update procedure is rejected by the

MME.

On reception of the EPS DETACH INDICATION message, the MSC removes the SGs association and marks the subscriber as EPS detached. The subscribers remains IMSI attached in this case. Furthermore, the MSC starts the time supervision for implicit detachment and automatic deregistration.

The MSC replies to the MME with the SGsAP EPS DETACH ACK message.

7.5.1.1.3 IMSI UE initiated detach procedure

The MME sends the SGsAP IMSI DETACH INDICATION to the MSC to inform that the UE has been detached from non-EPS (CS) services. The IMSI detach can be of type “explicit” or “implicit”. The explicit IMSI detach is triggered at the MME by the reception of an IMSI Detach Request from the UE. The implicit IMSI detach is triggered by a MME internal timer mechanism.

On reception of the IMSI DETACH INDICATION, the MSC removes the SGs association and mark the subscriber as IMSI detached and EPS detached. Furthermore, the MSC starts the time supervision for automatic deregistration.

The MSC replies to the MME by sending the SGsAP IMSI DETACH ACK message.

7.5.1.1.4 MM information procedure

The MM information procedure is used by the MSC to forward MM related information to the UE. Through the SGs-interface this procedure is used to send the network identity and time zone information to the UE.

So after a successful SGs Location Update the MSC sends the SGsAP MM INFORMATION REQUEST message to the MME, if the following two conditions are met: the Location Update is of type “IMSI Attach” or the subscriber is new in the

MSC the NITZ function is active and the network identity and/or time zone

information is available





7.5.1.1.5 Error handling procedure

The SGsAP STATUS message is used to inform the other peer entity about detected errors. The MSC sends the STATUS message to the MME if a protocol error is detected.

If the MSC receives a STATUS message as response to a SGsAP message, which has been sent by the MSC before, then the relevant procedure is stopped and is treated as unsuccessful.

7.5.1.2 Alert initiated by MSC

The EPS Alert procedure may be used by the MSC to request from the MME an indication when an activity from the UE is detected. Similar as for the Gs-interface it is proposed to use this mechanism in case of unsuccessful SMS delivery. As soon as the MSC is informed about signaling activity of the UE, the SMS service center is informed to repeat the SMS sending.

The MSC sends the SGsAP ALERT REQUEST message to the MME if a subscriber is not reachable for SMS transfer over the SGs-interface.

The MME sends the SGsAP ALERT ACK message, if the request is accepted.

The MME sends the SGsAP ALERT REJECT message, if the request is not accepted. On reception of the ALERT REJECT message removes the SGs association and mark the subscriber as EPS detached. Furthermore, the MSC starts the time supervision for implicit detachment and automatic deregistration.

The MME sends the SGsAP UE ACTIVITY INDICATION message, if a signaling activity of the UE is detected, which does not result in a dedicated procedure towards the MSC. On reception of the UE ACTIVITY INDICATION message or any other SGsAP message confirming radio contact with the UE, the MSC initiates the delivery of SMS by informing the HLR.

7.5.1.3 Alert initiated by HLR

In case of the HLR restart the MSC only starts a restoration timer. During that period the HLR is updated if a UE had 2G/3G radio contact. The MME is not informed per single UE that in case of LTE radio contact, the MSC should do an HLR update. Thus a radio contact in LTE is not propagated to the MSC to update the HLR information.





In case of inconsistent or lost HLR data after HLR restart the UEs, which are IMSI/EPC attached and camping in LTE, might not be reachable for MT calls or MT SMS until they perform a LU or MO action. This of course can take some time as no periodic LU is done in LTE.

7.5.1.3.1 Reset procedure

The Reset procedure is used by the MSC and MME to inform the other peer entity about a failure which resulted in loss of SGs association information. The SGsAP RESET INDICATION message is used for this purpose. The RESET INDICATION message is acknowledged by the receiving entity with the SGsAP RESET ACK.

MSC reset usage

If the MSC looses the information about the SGs associations due to a restart, then the MSC sends the RESET INDICATION message including the own VLR name to all connected MME nodes.

This handling is not applicable for MSC-S BC node types. The MSC-S BC does not send the RESET message because of a blade restart. In case of single blade restart, the MSC buddy blade still maintains the SGs associations. In case of multiple blade restart and loss of SGs association information on primary and buddy blade, the MSC-S BC sends the paging not via SGs-interface until a Location Update is received from the MME and the SGs association is re-established. Instead the Paging will be sent via A- or Iu-interface.

MME reset usage

On reception of the RESET INDICATION message from a connected MME node the MSC marks all subscribers with SGs association related to the sending MME as EPS detached. The SGs association is removed and the time supervision for implicit detachment and automatic deregistration is started.

The MSC confirms the completion of reset procedure by sending the RESET ACK message to the MME including the own VLR name.

7.5.1.3.2 Paging

An EPS attached subscriber first is paged through the SGs-interface. If the first paging is unsuccessful, then a second paging is performed based on the EPS state of the subscriber and operator settings. Furthermore, at the SGs-interface it is possible to initiate paging in one LA only or to initiate global paging.





Upon reception of a mobile terminating transaction (call, Supplementary Services or Location Services), the MSC pages the UE by sending the SGsAP PAGING REQUEST message to MME from which the EPS attachment was previously performed. In the PAGING REQUEST message the LAI stored in MSC/VLR is included. The conditions for paging a subscriber over SGs-interface are the existence of EPS attachment and that the LA is administered in the MSC/VLR. If a second paging has to be performed as global paging, then the MSC sends a PAGING REQUEST message without LAI to all connected MME nodes.

7.5.1.4 Mobile terminating SMS over SGs-interface

The SGs-interface supports dedicated procedures for the transport of SMS between the MSC and the MME. This means the UE can stay attached to the E-UTRAN access while sending/receiving SMS to/from the CS core network without performing a fallback to CS in that case.

After reception of the PAGING REQUEST message for SMS, the MME replies with the SGsAP SERVICE REQUEST message to indicate towards the MSC that a NAS signaling connection with the UE exists. If the UE is in idle mode, then the MME pages the UE and sends the SERVICE REQUEST after a successful response from the UE. If the UE is in connected mode, then the MME immediately sends the SERVICE REQUEST message to the MSC.

On reception of the SERVICE REQUEST message indicating “SMS call”, the MSC reads and stores the IEs “IMEISV”, “TAI”, “E-CGI”, “UE time zone” and “Mobile Station Classmark 2”. Then the MSC completes the Paging procedure and sends the DOWNLINK UNITDATA message to the MME. The SMS related DTAP/NAS messages are included in the NAS message container of the DOWNLINK UNITDATA message.

The MME forwards the acknowledgement of the SMS transfer and the delivery report from the UE to the MS/VLR included in separate UPLINK UNITDATA messages. On reception of the delivery report, the MSC shall forward the delivery report to the SMS-GMSC. Then the MSC/VLR sends the DOWNLINK UNITDATA message including the acknowledgement to the delivery to the MME.

If the SMS transaction is successfully completed or if the SMS handling has been aborted (unsuccessful case, like e.g. timer expiry, faulty message received), the MS/VLR sends the RELEASE REQUEST message to the MME.





In case of multiple terminating SMS the MSC sends the subsequent SMS in subsequent DOWNLINK UNITDATA message(s). The MME forwards the acknowledgement of each SMS transfer to the MSC/VLR in separate UPLINK UNITDATA messages. Finally upon completion of the SMS delivery the MME forwards the delivery report from the UE to the MS/VLR included in a separate UPLINK UNITDATA message. On reception of the delivery report, the MSC shall forwards the delivery report to the SMS-GMSC. Then the MSC/VLR sends the DOWNLINK UNITDATA message including the acknowledgement to the delivery to the MME.

On reception of the UPLINK UNITDATA message including a subsequent SMS (instead of an acknowledgement), the MSC/VLR sends the SMS to the SMS-IWMSC as it is done for single SMSs.

In case of multiple terminating SMSs case the MSC sends a RELEASE REQUEST message to the MME, if either the final SMS has been handled (successful case), or if the SMS handling has been aborted (unsuccessful case).

7.5.1.5 Mobile originating SMS over SGs-interface

On reception of the UPLINK UNITDATA message for an EPS attached subscriber, the MSC extracts the DTAP/NAS message including the SMS from the NAS message container. In addition the MSC reads and stores the IEs “IMEISV”, “TAI”, “E-CGI”, “UE time zone” and “Mobile Station Classmark 2”. The SMS is forwarded to the SMS-IWSMSC through the use of FORWARD SHORT MESSAGE. The SMS procedure towards SMS-IWSMSC and consequently towards the Service center is identical to procedure applies for SMSs that are originated from A or Iu interface.

The MSC/VLR includes the acknowledgement of the SMS in the SGsAP DOWNLINK UNITDATA and sends it to the MME. In case of a fault the MSC includes the respective DTAP/NAS failure message in the in DOWNLINK UNITDATA message.

The MSC/VLR upon reception of the delivery report from Service center forwards it to the associated MME with another SGsAP DOWNLINK UNITDATA message in order the MME to encapsulate it in a NAS message and send it to the MS/UE.

Then MSC/VLR receives the acknowledgement of the delivery report included in the UPLINK UNITDATA message from the associated MME.

In case that the MSC receives the UPLINK UNITDATA and the subscriber is not marked as EPS attached, then the MSC/VLR ignores the message. Additionally, the MSC shall send the SGsAP STATUS message with a relevant SGs cause (e.g. IMSI unknown).





If the SMS transaction is successfully completed or if the SMS has to be rejected or the SMS handling is aborted (unsuccessful cases like timer expiry, faulty message received, rejection due to Telecommunication Analysis, etc), the MS/VLR sends the SGsAP RELEASE REQUEST message to the MME. This indication is used to tell the MME that SMS transaction is completed and that NAS connection may be released if not needed for other purposes.

In case of multiple originating SMS the UE sends the subsequent SMS instead of the acknowledgement for the delivery report. On reception of the UPLINK UNITDATA message including a subsequent SMS (instead of an acknowledgement), the MSC/VLR sends the SMS to the SMS-IWMSC as it is done for single SMSs.

In case of multiple originating SMS cases the MSC sends a RELEASE REQUEST message to the MME, if either the final SMS has been handled (successful case), or if the SMS handling has been aborted (unsuccessful case).

7.5.1.6 Call handling (general)

If a call shall be established to/from a CSFB capable UE, then this UE requests the fallback to CS, if the subscriber is registered with combined procedures to EPS and non-EPS (CS) services. The fallback is completely handled within EPS domain. There are no dedicated procedures defined on the SGs-interface. The MSC will experience the CSFB call like a normal call, which is received from A-or Iu-interface.

A prerequisite for a fallback to CS is to have E-UTRAN coverage overlapping with either GSM or WCDMA coverage. The MME has to be able to select the MSC based on the LA during combined IMSI Attach or combined Tracking Area/Location Update.

Therefore, the operator has to correlate the GSM/WCDMA LAs with the EPS TAs and Tracking Area (TA) lists. The TA list is assigned by the MME and it defines the TAs that the UE can enter without performing a Tracking Area Update. The TAs in a TA list assigned by the MME to a CSFB capable UE shall geographically belong to the same LA.

7.5.1.6.1 Mobile originating call

The UE starts the sequence of a mobile originating call by sending a Service Request with CSFB indicator to the MME, if it is EPS/CS attached and it is not able to initiate an IMS voice session.

Since the MSC is not involved in the actual CS Fallback procedure, the selection of one of the CS Fallback options does not directly impact the MSC.





After the fallback the call setup continues via A- or Iu-interface. As usual the BSC forwards the CM Service Request to the MSC as part of the BSSMAP COMPLETE LAYER 3 INFORMATION message. The RNC encapsulates the CM Service Request in the RANAP INITIAL UE message.

So upon reception of the CM Service Request that is included (depending on the type of access) either in BSSMAP COMPLETE LAYER 3 INFORMATION or in the RANAP INITIAL UE message, the MSC shall continue with the call setup as before the introduction of CSFB.

If the MSC only supports SMS over SGs, then the MSC rejects the CM Service Request by sending a CM Service Reject message with Reject Cause “IMSI unknown in VLR”.

7.5.1.6.2 Mobile terminating call

For mobile terminating calls the CS Fallback indirectly impacts the MSC, because the time between Paging Request and Paging Response might be increased. The amount of increase depends on the selected method for the fallback.

After the fallback the call setup continues via A- or Iu-interface. The Paging Response is forwarded to the MSC with the BSSMAP COMPLETE LAYER 3 INFORMATION message or the RANAP INITIAL UE message.

If the fallback to CS fails, then the MSC is not informed about this event. Thus, the MSC will experience paging timer expiry.

If the incoming call is not accepted by the subscriber, then the MSC receives a Paging Reject message with a relevant cause code.

7.5.1.7 Support of MSC in pool

If MSC pool configuration is not used, the MME will derive the VLR name during the combined Attach Request or combined Tracking Area/Location Update based on the LA.

If an LA is served by multiple MSCs in a pool configuration, the MME has to derive the VLR name based on IMSI hash tables in the same way as specified for the SGSN in 3GPP TS 23.236.

The CN based redistribution in an MSC pool configuration has to be initiated from the MME in the same way as specified for the SGSN in 3GPP TS 23.236. Consequently EPS attached subscribers are not subjected to MSC pool redistribution that the operator might initiate in the MSC/VLR





Finally the MSC includes in SGsAP PAGING REQUEST message the Global CN ID, if IMSI paging should be applied and MSC in pool configuration is used.

7.5.1.8 Roaming retry for Mobile terminating call during CSFB

The roaming retry function is not supported by the MSC/VLR and still there are no plans in the future to support it. The roaming retry is not considered as a functionality of CSFB but as a stand alone functionality that could be enhanced to serve the CSFB requirements.

The lack of Roaming retry support by the MSC/VLR may lead to the following problematic case:

The UE is registered on MSC1/LAI-1 via SGs. The LAI is determined thanks to the MME TAI/LAI mapping table.

During the time that fallback is triggered, the eNB decides to send the UE to a target cell that is associated to a different location area from the one used during EPS attachment which might belong to another MSC (MSC2/LAI-2).

This case might occur for two reasons:

1. In many operators networks the WCDMA and GSM accesses are served by different MSCs and consequently different LAIs. As the TAI can only be mapped to one single LAI, the preferred RAT should be configured by the operator in the MME. In case the LAI-1 (mapped from TAI-1) in the MME is in RAT-A (GSM access) but at the time of CSFB the radio coverage is better in RAT-B (WCDMA access) then the call (paging response message will be sent to an another MSC (MSC2) from the one that EPS attachment was performed (MSC1) and without the support of Roaming Retry this call will fail.

2. The TAI-1 border is not fully aligned to LAI-1, as this is difficult in practice. This misalignment may occur if for example the mapping of TAIs to LAIs is not accurate in the MME or due to imperfect LTE/WCDMA radio alignment because of different Radio Frequencies. So in case that TAI-1 in reality covers more than one LAI then we may end up to the situation described above where the subscriber during speech call initiation, due to CSFB, is moved to a different MSC than the one that was EPS attached.

Without the support of roaming retry in MSC/VLR the solution to case 1) is the use dual access MSCs and the solution to the case 2) is the use of MSC in Pool configuration.

Of course the main drawback to this proposal is that the operator should be willing to accept these changes in his network.





7.6 BCAM Mobile Softswitch Solution

The BCAM MSS supporting CSFB and SMS over SGs has already been delivered to AT&T and testing has started at the customer lab.

MT roaming retry is required by AT&T. BCAM provides the solution since Oct 2010.

IOT is starting up in Dallas with the BNET MME and BCAM MSS.

BCAM MSS also supports MSC pool which was not tested yet against a BNET MSS pool configuration.

7.7 OSS

OSS will provide neighbor cell management support for LTE Circuit Switch Fallback (CSFB) and Session Continuity to GSM and WCDMA by means of Release with Redirect without NACC information. This will include managing Master External cells (GSM/WCDMA) in the OSS sub network manager managing LTE nodes and managing cell relations pointing to the external cells from EUtranCells

ISHO data (cells) is exported from GSM and WCDMA systems.

They are loaded in the OSS managing the LTE network. This involves transforming the data in a format which LTE OSS supports i.e. Bulk CM.

OSS will not be required to distribute System Information to the eNB.

GSM/WCDMA Neighbors are defined in the LTE OSS.

7.8 Terminals

7.8.1 WCDMA/GSM

For new terminals supporting LTE together with GSM and WCDMA access the optimized single radio receiver (1 Tx, 1Rx) solution based on enhanced RRC release with redirect is planned by ST Ericsson and Nokia according to 3GPP Rel 9. In some initial LTE deployments, handheld terminals supporting voice only via CSFB must be used.

However, based on customer enquiries, evaluation of dual radio devices might be done for 3GPP markets.





First commercial terminals are expected in H1/11.

There might be terminals supporting 3GPP Rel 8 with RRC release and redirect.

7.8.2 CDMA

In contrast to combined LTE/GSM/WCDMA terminals using single receiver for 3GPP networks, main terminal vendors promote simultaneous voice LTE (SVLTE) terminals with dual radio (2 Tx, 2Rx) or dual receivers (1 Tx, 2 Rx) for 3GPP2 networks.

7.9 Service Characteristics

The CS call setup time for a call made by CSFB depends on the CSFB method chosen. To WCDMA, RRC Connection Release with Redirect and non-blind PSHO gives approximately the same CS call setup time if the system information can be provided to the UE already in LTE in the RwR case. To GSM, CSFB there is a substantial gain in using RRC Connection Release with Redirect to all other alternatives also here provided that System Information is available to the UE already in LTE. The CS call setup times for all different alternatives are estimated in Table 7.

5.1MO 0.8MT 0.8

MO 3.1MT 3.5

RRC Connection Release with Redirect to UTRAN, Deferred measurement control UTRAN support

No DTMMO 2.7MT 2.4

MO 5.2MT 5.6

Release with Redirect to GERAN, no DTM

4.6MO 0.3MT 0.3

MO 2.6MT 3.0

RRC Connection Release with Redirect to UTRAN, with UTRAN Sys Info available in LTE

No DTMMO 1.7/0.4MT 1.4/0.1

MO 4.2/2.9MT 4.6/3.3

CCO with NACC to GERAN, without DTM, non-blind/blind

No DTM

<0.2*

5.8

<0.2

PS Outage (s)

MO 1.5MT 1.5

MO 3.8MT 4.2

RRC Connection Release with Redirect to UTRAN, SysInfo read in UTRAN

MO 0.7MT 0.4

MO 3.2MT 3.6

Release with Redirect to GERAN, GERAN SysInfo available in LTE

MO 1.9/0.6MT 1.6/0.3

MO 4.4/3.1MT 4.8/3.5

PSHO to GERAN, with DTM non-blind/blind

MO 0.5/-0.4MT 0.5/-0.4

MO 2.8/1.9MT 3.2/2.3

PS HO to UTRAN, non-blind/blind

Additional call setup delay compared to CS Call setup in each RAT (s)Call setup times by CSFB (s)

MO: mobile o fixed MT: fixed to mobile

5.1MO 0.8MT 0.8

MO 3.1MT 3.5


No DTMMO 2.7MT 2.4

MO 5.2MT 5.6

Release with Redirect to GERAN, no DTM

4.6MO 0.3MT 0.3

MO 2.6MT 3.0


No DTMMO 1.7/0.4MT 1.4/0.1

MO 4.2/2.9MT 4.6/3.3

CCO with NACC to GERAN, without DTM, non-blind/blind

No DTM

<0.2*

5.8

<0.2

PS Outage (s)

MO 1.5MT 1.5

MO 3.8MT 4.2


MO 0.7MT 0.4

MO 3.2MT 3.6

Release with Redirect to GERAN, GERAN SysInfo available in LTE

MO 1.9/0.6MT 1.6/0.3

MO 4.4/3.1MT 4.8/3.5

PSHO to GERAN, with DTM non-blind/blind

MO 0.5/-0.4MT 0.5/-0.4

MO 2.8/1.9MT 3.2/2.3

PS HO to UTRAN, non-blind/blind



Table 7 CSFB characteristics summary





The PS outage figure for PSHO to GSM corresponds to what can be achieved with Enhanced DTM functionality, which is currently not included in the product. Without Enhanced DTM functionality, the PS outage time will be ~5s for PSHO to GSM.

For more information on the assumptions for the above calculations on CSFB call setup times see [14].

Following measurements in a lab environment with pre-commercial terminals have been done in March 2011:

MO 1.0MT 1.0

MO 3.7MT 5.0


MO 2.1MO 5.5Release with Redirect to GERAN, no DTM

MO 0.6MT 0.6

MO 3.4MT 4.7


MO 2.7MT 2.7

MO 5.4MT 6.7


MO 0.9MO 4.3Release with Redirect to GERAN, GERAN SysInfo available in LTE



MO 1.0MT 1.0

MO 3.7MT 5.0


MO 2.1MO 5.5Release with Redirect to GERAN, no DTM

MO 0.6MT 0.6

MO 3.4MT 4.7


MO 2.7MT 2.7

MO 5.4MT 6.7


MO 0.9MO 4.3Release with Redirect to GERAN, GERAN SysInfo available in LTE



Table 8 CSFB performance measurements

7.10 Shared Networks

The intention with this chapter is to provide a brief overview of shared network solutions and to identify any issues and specific requirements for CSFB when applied to shared networks. Network sharing is an agreement between operators and shall be transparent to the user. The operators deciding to share networksshall have the same opportunities to provide efficient CS Fallback solutions as operators that do not share. The user experience while UE is performing its actions related to CS Fallback in a network employing shared network functions should be no worse than what users experience in a non-shared network.

Even though there are many different scenarios for network sharing, the predominant one is one which shares only the RAN. There is currently no support for shared core in Ericsson core network products and this study does not propose to add any shared core network requirements additional to those already proposed by Ref.[7].





The “Multi Operator Core Network” (MOCN) is the accepted name of a scenario where two or more operators (aka “CN operators”) share only the RAN. All relevant core network nodes (e.g. MME/SGSN/MSC, SGW, PGW, HSS etc) are in the operators’ own networks. The MOCN is a standardized scenario for network sharing (3GPP TS 23.251) and is supported for LTE and WCDMA.

Figure MOCN (Multi-Operator Core Network) example with LTE RAN

Since CS Fallback implies moving the UE from a LTE RAN to another RAN (WCDMA RAN or GSM), the combinations of what parts are shared are several. The source LTE RAN might or might not be shared, and/or the target RAN might or might not be shared.

7.10.1 Shared LTE RAN

The first and early releases of the LTE RAN (“RBS”) does not have shared network support (neither does it have support for CSFB). The shared network support is currently planned as a L12A deliverable and comes as a feature which can use the eNB in either a MOCN (shared RAN) or a GWCN (shared RAN and shared core) configuration.

In LTE networks all UE have the capability to read shared network information.

TNSGWPGW

T2SGWPGW

T2MME

TNMME

Op 1MME

Op 2MME

eNB eNB

Op 1SGWPGW

Op 2SGWPGW

Common RAN operator

Operator 1 Operator 2

Op 1PLMN-ID

Op 2PLMN-ID

Op 1PLMN-ID

Op 2PLMN-ID

DNS DNS

DNS





Much due to that fact, ‘Shared LTE RAN’ does not come in conflict with CSFB. The issues with CSFB when the LTE RAN is shared are not very much different than the issues that exist for any inter-RAT mobility from shared LTE RAN. Each of the operators that share the LTE RAN would like to have their own strategies with regards to PLMN (stay in same or move to an equivalent) and frequency priorities imposed to the UEs. Each operator will of course have the ultimate scope to maintain control of the UE in the target RAN.

7.10.2 Shared WCDMA RAN

The WCDMA RAN (“RNC/RBS”) and WCDMA core network comes already now with shared network support, however presently excluding support for ‘MOCN Release 6’. This means that both ‘supporting UEs’ and ‘non-supporting UEs’ will be handled in the same way (see Ref.[2] for the terminology used by standard specifications). The PLMN selection in networks using Ericsson equipment at this feature level will always be done by functions and configurations in the network (contrary to standard intentions where ‘supporting UEs’9 are expected to select core network operator itself).

Since there is no support for ’multiple PLMN lists‘ (comes with ‘MOCN Release 6’), the ‘supporting UEs’ are not ever offered a choice. Instead, the operators of a shared network with Ericsson parts must agree on and use a ‘common’ PLMN identity in the radio interface and decide on an alternative way to split the traffic. A typical solution to achieve a fair sharing is to engage ‘CS/PS coordination’10

and split the country in different geographical areas of operation (e.g. one of the operators care for the operation in the North part and another in the South). The ‘CS/PS coordination’ in RNC/MSC/SGSN will firstly make sure to connect home subscribers to the CS/PS domain of their respective home. Secondly, visiting subscribers will be connected to the CS/PS domain corresponding to the respective area of operation, unless it is a subscriber that belongs to the other operator (by explicit roaming agreement). The redirection of that last-mentioned category of visiting users will not work well with CSFB.

A solution recommended in the standard to achieve CS/PS coordination is to use combined procedures + the Gs interface, but this is not supported for Ericsson WCDMA core network yet, only planned (see Ref.[2]).

9 9 A ‘supporting UE’ is an UE that have the capability to receive shared network information and indicate to the RAN which of these it has selected.10 10 ‘CS/PS coordination’ is described in Ref. [3] as ‘PS and CS domain registration coordination in UTRAN’).





7.10.2.1 Issues with CS Fallback by Release with redirect to WCDMA

The issue discussed below concerns only visiting subscribers and only those which are based in a PLMN from which there is an explicit roaming agreement with just one of the shared network operators. The problem occurs whenever CS Fallback occurs and when such a user roams in a part of the network which is operated by the other operator.

The UE is registered in the MSC while being attached to E-UTRAN and registered in the MME. The LTE RAN releases the UE with redirection information to WCDMA. The UE reselects and connects to a WCDMA cell. RNC receives and forwards the Location Update Request to the MSC which are engaged in the CS Fallback procedure. In case of the current shared network implementation, the RNC also sets the redirect attempt flag and expects the MSC to either accept the NAS procedure or initiate a redirection. By comparing the IMSI with the roaming agreements of the CN operator(s), the MSC discovers that roaming is not endorsed (or that roaming is allowed but CS/PS coordination is required). The Location Update procedure is aborted and the user is redirected to the RNC for a new selection of CN node based on additional information. A message is sent back to the RNC with two NAS messages, the reject message and the original request message received from the UE. The IMSI is also included in the message. The signaling connection between RNC and the MSC which is engaged in the CS Fallback is released and the RNC performs CS/PS coordination based on the received IMSI. The user may in this way be redirected to the other CS/PS domain. But in that domain the user is not known and the location update and also the CSFB will fail.

Operators of Ericsson’s current shared network solutions employ special configurations which will force the above-mentioned category of visiting terminalsto always be redirected away from their current domain. For these subscribers, the CS Fallback using the method of release with redirect will always fail.

These ‘CS/PS coordination problems’ can be decreased by decreasing the need for UE to perform Location Update at CS Fallback. But it is hard to accomplish a perfect mapping between LA and TA since radio conditions differ between the technologies. There are methods which minimizes the problems, e.g. implementing small enough TAs so that they are contained within a much larger LA. However, radio occasionally propagates over very large distances, so no method completely removes the problem.

In light of this it might appear more beneficial for some operators to the operators have roaming UEs always unconditionally fallback to GSM (since that is not ever shared and redirection to another operators CS/PS domain will not be engaged). Of course, such a solution may not be feasible if the higher bitrates in WCDMA are required.





7.10.2.2 Issues with CS Fallback by PS Handover to WCDMA

The LTE RAN handovers the UE to WCDMA.

The problem discussed in the previous subchapter will not occur since the network will handover the connection and NAS Node Selection with CS/PS coordination will not occur.

The problem which is specific to shared networks is here the opposite compared to the previous section. There will be no CS/PS coordination. One problem with that is of course that the UE is moved to WCDMA with no respect to the roaming agreements between the operators. Another problem is that the UE might either directly (after RA Update) or eventually move into a situation where it is connected to different CN operators in different CN domains.

7.10.3 Shared GSM

‘Shared networks’ is a new study item in 3GPP and there is currently no standardized support for shared networks. Similar issues as those discussed above are foreseen to occur.

7.11 Multi Country Support

Consider a scenario where some of the nodes involved in CSFB (e.g. MME+ SGW11, and LTE RAN) are located in one country while the remaining nodes (e.g. MSC and either of WCDMA RAN or GSM) in another.

There is no clear statement in the 3GPP standard whether such a scenario is supported or not. In this study all parts of RAN and all parts of CN are assumed to be located in the same country (see e.g. the architecture reference models in TS 23.401).

8 Wanted functionality and requirements

Following requirements define missing functionality not covered in any roadmap relevant for CSFB and SMS over SGs. The requirements shall be integrated into product planning and used to follow-up with PdM.

11 11 The SGW is selected by the MME based on the location of the UE, that is, by the use of TA information from the shared LTE. Each SGW supports a specific Service Area, defined as a geographical group of TAs. Hence, based on the current location of the UE, the most appropriate SGW is chosen. The MME performs a DNS query to retrieve the suitable SGW IP address.





8.1 UTRAN

8.1.1 Requirement: MOCN Release 6 support

Explanation: The UE that arrives in the CS domain by CS Fallback with Release with Redirect to WCDMA RAN will arrive directly in the correct PLMN. When the UE reselects to a shared WCDMA cell, the AS will indicate multiple PLMN identities to the NAS. The UE (Release 6 compliant) will select one of these PLMNs. If the registered PLMN is available among these, the UE shall not choose a different PLMN.

Consequences if not implemented: Operators that share WCDMA RAN may find them forced to move their RIC subscribers (Roaming Incoming Customers) to GSM while only each operators own and SRIC subscribers (single RIC) can be moved to WCDMA. Another consequence if not implemented is that the same operators can not receive the gain of removing the currently required CS/PS coordination and hence each operators SRIC subscribers will not experience the reduced call setup time (this is in order of 3-4 seconds which is a considerable part of the current total access time in shared networks ala Ericsson RNC and Ericsson SGSN/MSC)12. The MOCN Release 6 support has previously been postponed on basis of the limited market for shared WCDMA RAN (NORDIC markets: Telia+Tele2, "3" + Telenor: AUS: Hutch+"3" + Telstra, SPAIN: Vodafone + Orange + Telefonica).

Affected network elements: WCDMA, SGSN, LTE RAN

8.1.2 Requirement: RIM Support

Explanation: Radio Information Management procedures between GSM/WCDMA and LTE can be used to provide neighbor cell System Information to the eNB. This SI is sent by the eNB to the UE during the CSFB with RRC release and redirect procedure. The UE afterwards can skip reading this SI in the target RAN allowing a faster call set-up time at CSFB. RIM support is needed in RNC, SGSN-W, MME and eNB to ensure data consistency. Another method can be the UTRAN deferred measurement function. One of the two alternatives should be implemented to match the customer expectation on CSFB characteristics, see Table 7.

12 12 HOME subs will not experience any quicker mobility thanks to REl-6 support, since the CN (SGSN and MSC) never executes CS/PS-coordination for a HOME subscriber.





Consequences if not implemented: The customer expects with the introduction of LTE together with CSFB similar CS service characteristics as in the legacy network. Without any CSFB enhancement for WCDMA the call set-up performance is worse compared to legacy call set-up times. For GSM this functionality is already planned.

Affected network elements: WCDMA, SGSN-W, MME, LTE RAN

8.1.3 Requirement: Deferred Measurement Control

Explanation: The CSFB Call setup time to UTRAN can also be improved by only reading SIBs needed for CS call setup in UTRAN. This is possible with support for Deferred Measurement Control in UTRAN.

Consequences if not implemented: The customer expects with the introduction of LTE together with CSFB similar CS service characteristics as in the legacy network. Without any CSFB enhancement for WCDMA the call set-up performance is worse compared to legacy call set-up times.

Affected network elements: WCDMA, Terminal

8.2 MSS

8.2.1 Requirement: Mobile Terminated Roaming Retry

Explanation: MT RR is standardized in [1].

Consequences if not implemented: If in case of a mobile terminated call the UE is paged from an MSC via SGs and falls back into a LA of another MSC the call establishment fails and the call is lost. Probably the UE will return to LTE and a new CSFB might fail again especially in a non MSC pool CN.

Affected network elements: MSS, HLR

8.2.2 Requirement: HLR reset indication to MME

Explanation: If the MME does not know about an HLR reset the MSC cannot know about radio contact of an UE after HLR reset during the restoration time interval. Therefore, the MSC cannot update the HLR information for these subscribers like for GSM/WCDMA subscribers.

Consequences if not implemented: The UE is not reachable for MT calls and SMS.





Affected network elements: MSS

8.3 EPC

8.3.1 Requirement: MSC pool support

Explanation: Handling of the MSC pool is not fully supported in the MME. The selection of the MSC is based on the current TA which is mapped to an LA. For each LA always the same MSC in the MSC Pool is selected, There is only one SGs associated MSC per LA (no support for MSC Pool via SGs).

Consequence if not supported: Uneven CP load in an MSC pool may result. Also the MSC pool re-distribution function will not be possible to be applied for EPS attached subscribers, which has to be initiated by the MME.

Affected network elements: MME

9 Abbreviations

ANR Automatic Neighborship Relation AS Access StratumCAPEX Capital expenditureCGI Cell Global IdentityCLI Caller Line IdentificationCM Configuration ManagementCN Core Network CS Circuit SwitchedCSFB CS FallbackDMCR Deferred Measurement Control ReadingDN Domain NameDNS Domain Name SystemDRB Data Radio BearerDTM Dual Transfer ModeECGI E-UTRAN Cell Global IdentifierE-CGI Enhanced CGIEPC Evolved Packet CoreEPS Evolved Packet SystemEUTRAN Evolved UTRANFDD frequency-division duplexFQDN Full Qualified Domain NameGERAN GSM EDGE RANGGSN Gateway GPRS Support NodeGMSC Gateway MSC





GPRS General Packet Radio ServicesGTP GPRS Tunneling ProtocolGTP-U GTP User (3GPP TS 29.281)GUMMEI Globally Unique MME IdentifierGW GatewayGWCN Gateway CNHLR Home Location RegisterHPLMN Home PLMNHRL Handover Restriction ListHSS Home Subscriber ServerIE Information ElementIMEISV International Mobile Equipment Identity Software VersionIMSI International Mobile Subscriber IdentityIP Internet ProtocolIPsec IP SecurityIRAT Inter RATISR Idle Mode Signaling ReductionL2 Layer 2L3 Layer 3LA Location AreaLAC Location Area CodeLAI Location Area IdentifierLAN Local Area NetworkLAU Location Area UpdateLBS Location Based ServicesLEA Law Enforcement Agency LI Lawful InterceptionLTE Long Term EvolutionMAC Media Access Control (herein not Medium Access Control)MCC Mobile Country CodeMM Mobility ManagementMME Mobility Management EntityMMEC MME CodeMMEGI MME Group IDMMTEL Multimedia TelephonyMNC Mobile Network CodeMO Mobile OriginatedMOCN Multi-operator CNMSC Mobile Switching CenterMSIN Mobile Station Identification NumberMT Mobile TerminatedM-TMSI MME TMSI (TMSI for services provided through the MME)NACC Network Assisted Cell ChangeNAS Non-Access StratumNMS Network management system





NRI Network Resource IndicatorOAM Operation and MaintenanceOPEX Capital expenditurePCC Policy Control and ChargingPDCP Packet Data Convergence ProtocolPDN GW Public Data Network GatewayPDU Product Development UnitPDU Protocol Data UnitPGW Packet GatewayPLMN Public Land Mobile NetworkPM Performance ManagementPS Packet SwitchedPSHO PS HandoverP-TMSI Packet TMSI (TMSI for services provided through the SGSN)PTT Postal, Telegraph, and Telephone service (Swedish “PTS”)QCI QoS Class IdentifierQOS Quality of ServiceRAB Radio Access BearerRAC Routing Area Code (not Radio Access Control)RAN Radio Access NetworkRAT Radio Access TechnologyRAU Routing Area UpdateRBS Radio Base StationRC Regional CentreRFSP RAT/Frequency Selection Priority'RIM RAN Information ManagementRN Radio NetworkRNC Radio Network ControllerROP Recording Output PeriodRRC Radio Resource ControlRRM Radio Resource ManagementSAE System Architecture EvolutionSGSN Serving GPRS Support Node (SGSN)SGW Serving GatewayS-GW Serving GWSIB System Information BlockSIM Subscriber Identity ModelSPID Subscriber Profile IDSPM Strategic Product ManagerS-TMSI (SAE) TMSISW SoftwareTA Tracking AreaTAC Tracking Area CodeTAI Tracking Area IdentityTAU Tracking Area Update





TDD Time-division duplexTEID Tunnel Endpoint Identifier TMSI Temporary Mobile Subscriber IdentityTN Transport NetworkUDI Unrestricted Digital InformationUE User EquipmentUMTS Universal Mobile Telecommunications SystemUSSD Unstructured Supplementary Service DataUTRA UMTS Terrestrial Radio AccessUTRAN UTRA NetworkVLR Visitor Location RegisterVPLMN Visiting PLMNWCDMA Wideband Code Division Multiple Access

10 References[1] 3GPP TS 23.272 Circuit Switched (CS) fallback in Evolved Packet

System (EPS) (9.4.0); Stage 2http://www.3gpp.org/ftp/Specs/html-info/23272.htm

[2] 3GPP TS 23.251 Network sharing; Architecture and functional description http://www.3gpp.org/ftp/Specs/html-info/23251.htm

[3] 3GPP TS 23.236 Intra-domain connection of RAN nodes to multiple CN nodeshttp://www.3gpp.org/ftp/Specs/html-info/23236.htm

[4] 3GPP TS 23.401 General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) accesshttp://www.3gpp.org/ftp/Specs/html-info/23401.htm

[5] 3GPP TS 44.901 External Network Assisted Cell Change (NACC)http://www.3gpp.org/ftp/Specs/html-info/44901.htm

[6] 3GPP TS 44.018 Mobile radio interface layer 3 specification; RadioResource Control (RRC) protocolhttp://www.3gpp.org/ftp/Specs/html-info/44018.htm

[7] Shared Networks EAB-09:062430

[8] Mobile Soft switching (MSS) Roadmap, Rev AMhttp://gask2web.ericsson.se/pub/picov/get?DocNo=2/224+01-FGB+101+189

[9] Packet Core Roadmap, March 2011http://gask2web.ericsson.se/pub/picov/get?DocNo=224 01-FGB 101 256

http://www.3gpp.org/ftp/Specs/html-info/23272.htm






http://gask2web.ericsson.se/pub/picov/get?DocNo=2/224+01-FGB+101+189

http://gask2web.ericsson.se/pub/picov/get?DocNo=2/224+01-FGB+101+189





[10] LTE RAN Roadmap, Rev Xhttp://gask2web.ericsson.se/pub/picov/get?DocNo=224%2001-FGB%20101%20469%20

[11] WCDMA RAN Roadmap, March 2011http://gask2web.ericsson.se/pub/picov/get?DocNo=1/224 01-FGB 101 135

[12] GSM RAN Roadmap, Rev AMhttp://gask2web.ericsson.se/pub/picov/get?DocNo=2/224 01-FGB 101 097

[13] Mobile OSS Roadmap, Rev E1http://gask2web.ericsson.se/service/get?DocNo=22401-FGB101798

[14] CSFB Call Set-up Timeshttp://anon.ericsson.se/eridoc/component/eriurl?docno=EAB-11:024486Uen

[15] NDS: Incoming PS HO from LTE, EAB-10:051539 Uen

[16] LTE/EPC System Use Cases in EPS 2.0, EAB-09:082060 Bhttps://eridoc.ericsson.se/eridoc/component/eriurl?docno=EAB-09:082060Uen&objectId=09004cff83bc00d8&format=msw8

[17] LTE/EPC - cdma2000 Interworkinghttps://eridoc.ericsson.se/eridoc/component/eriurl?docno=EAB-10:022599Uen&objectId=09004cff83becd6c&action=current&format=msw8

http://gask2web.ericsson.se/pub/picov/get?DocNo=224%2001-FGB%20101%20469%20

http://gask2web.ericsson.se/pub/picov/get?DocNo=224%2001-FGB%20101%20469%20

http://gask2web.ericsson.se/pub/picov/get?DocNo=1/224%2001-FGB%20101%20135




http://gask2web.ericsson.se/service/get?DocNo=22401-FGB101798

http://anon.ericsson.se/eridoc/component/eriurl?docno=EAB-11:024486Uen&objectId=09004cff848e182b&action=current&format=ppt8

http://anon.ericsson.se/eridoc/component/eriurl?docno=EAB-11:024486Uen&objectId=09004cff848e182b&action=current&format=ppt8

https://eridoc.ericsson.se/eridoc/component/eriurl?docno=EAB-09:082060Uen&objectId=09004cff83bc00d8&format=msw8

https://eridoc.ericsson.se/eridoc/component/eriurl?docno=EAB-09:082060Uen&objectId=09004cff83bc00d8&format=msw8

https://eridoc.ericsson.se/eridoc/component/eriurl?docno=EAB-10:022599Uen&objectId=09004cff83becd6c&action=current&format=msw8



end-to-end cs fallback to gsm and wcdma system

Documents

csfb specific

csfb capable

mss system

enhanced csfb solution

lte throughput

system information nacc

wcdma ran

csfb study team eab