01 LTE TDD ERAN11.1 Optional Feature Description 02 (20160730)

(1)

LTE TDD

eRAN11.1

Optional Feature Description

Issue 02

Date 2016-07-30

(2)

i

No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.

All other trademarks and trade names mentioned in this document are the property of their respective holders.

Notice

The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129

People's Republic of China Website: http://www.huawei.com

(3)

Optional Feature Description Contents

ii

1 Change History ... 1

2 Voice & Other Services ... 3

2.1 VoLTE ... 3

2.1.1 TDLOFD-001016 VoIP Semi-persistent Scheduling ... 3

2.1.2 TDLOFD-001017 RObust Header Compression (ROHC) ... 4

2.1.3 TDLOFD-001048 TTI Bundling ... 6

2.1.4 TDLOFD-081229 Voice Characteristic Awareness Scheduling ... 6

2.1.5 TDLOFD-111202 Coverage-based VoLTE Experience Optimization ... 8

2.1.6 TDLOFD-111207 VoLTE Rate Control ... 9

2.1.7 TDLOFD-001022 SRVCC to UTRAN ... 11

2.1.8 TDLOFD-001023 SRVCC to GERAN ... 12

2.2 CSFB ... 14

2.2.1 TDLOFD-001033 CS Fallback to UTRAN ... 14

2.2.2 TDLOFD-001052 Flash CS Fallback to UTRAN ... 15

2.2.3 TDLOFD-001068 CS Fallback with LAI to UTRAN ... 17

2.2.4 TDLOFD-001088 CS Fallback Steering to UTRAN ... 18

2.2.5 TDLOFD-081223 Ultra-Flash CSFB to UTRAN ... 19

2.2.6 TDLOFD-001034 CS Fallback to GERAN ... 21

2.2.7 TDLOFD-001053 Flash CS Fallback to GERAN ... 22

2.2.8 TDLOFD-001069 CS Fallback with LAI to GERAN ... 23

2.2.9 TDLOFD-001089 CS Fallback Steering to GERAN ... 24

2.2.10 TDLOFD-081203 Ultra-Flash CSFB to GERAN ... 25

2.2.11 TDLOFD-001035 CS Fallback to CDMA2000 1xRTT ... 27

2.2.12 TDLOFD-001090 Enhanced CS Fallback to CDMA2000 1xRTT ... 29

2.2.13 TDLOFD-001091 CS Fallback to CDMA2000 1xRTT Based on Frequency-specific Factors ... 30

2.3 Increment Value Service ... 32

2.3.1 TDLOFD-001047 LoCation Services(LCS) ... 32

2.3.2 TDLOFD-001092 CMAS Support... 33

2.3.3 TDLOFD-081222 Dynamic Service-specific Access Control ... 34

2.3.4 TDLOFD-070220 eMBMS Phase 1 based on Centralized MCE Architecture ... 36

2.3.4.1 TDLOFD-07022001 Multi-cell transmission in MBSFN area ... 38

(4)

iii

2.3.4.3 TDLOFD-07022003 Data synchronization ... 40

2.3.4.4 TDLOFD-07022004 Session admission control ... 41

2.3.5 TDLOFD-080210 eMBMS Service Continuity ... 42

2.4 Video Service Optimization ... 43

2.4.1 TDLOFD-111205 Busy-Hour Download Rate Control ... 43

2.4.2 TDLOFD-111206 Video Service Rate Adaption... 44

2.4.3 TDLOFD-110225 Uplink Data Compression ... 45

3 Radio & Performance ... 47

3.1 2-layer Mutil-Antenna ... 47

3.1.1 TDLOFD-001001 DL 2x2 MIMO ... 47

3.1.2 TDLOFD-001030 Support of UE Category 2/3/4 ... 48

3.1.3 TDLOFD-001049 Single Streaming Beamforming ... 49

3.1.4 TDLOFD-001061 Dual Streaming Beamforming ... 50

3.1.5 TDLOFD-001077 MU-Beamforming ... 51

3.1.6 TDLOFD-001005 UL 4-Antenna Receive Diversity ... 53

3.1.7 TDLOFD-001058 UL 2x4 MU-MIMO ... 54

3.1.8 TDLOFD-001062 UL 8-Antenna Receive Diversity ... 55

3.1.9 TDLOFD-081205 UL 2x8 MU-MIMO ... 56

3.2 Interference Handling ... 57

3.2.1 TDLOFD-001012 UL Interference Rejection Combining ... 57

3.2.2 TDLOFD-060201 Adaptive Inter-Cell Interference Coordination ... 58

3.2.3 TDLOFD-001094 Control Channel IRC ... 59

3.2.4 TDLOFD-001075 SFN ... 60

3.2.5 TDLOFD-002008 Adaptive SFN/SDMA ... 62

3.2.6 TDLOFD-001098 Inter-BBP SFN ... 63

3.2.7 TDLOFD-001080 Inter-BBU SFN ... 64

3.2.8 TDLOFD-001081 Inter-BBP Adaptive SFN/SDMA ... 65

3.2.9 TDLOFD-001082 Inter-BBU Adaptive SFN/SDMA ... 66

3.2.10 TDLOFD-070227 PDCCH DCS in SFN ... 67

3.2.11 TDLOFD-081221 PDCCH SDMA in SFN ... 68

3.2.12 TDLOFD-070223 Multi-Cell Interference Randomizing and Coordination ... 69

3.2.13 TDLOFD-080203 Coordinated Scheduling based Power Control ... 70

3.2.14 TDLOFD-081217 Interference Detection and Suppression ... 71

3.2.15 TDLOFD-081219 Interference Based Uplink Power Control ... 72

3.2.16 TDLOFD-081232 Enhanced Uplink Power Control ... 73

3.2.17 TDLOFD-110205 Intra-eNodeB Uplink Coordinated Scheduling ... 74

3.2.18 TDLOFD-110206 Inter-eNodeB Uplink Coordinated Scheduling ... 75

3.2.19 TDLOFD-111208 Uplink Interference Coordination... 76

3.2.20 TDLOFD-111201 Remote Interference Adaptive Avoidance ... 77

3.2.21 TDLOFD-001066 Intra-eNodeB UL CoMP ... 79

(5)

iv

3.3 QoS ... 84

3.3.1 TDLOFD-001026 Optional uplink-downlink subframe configuration ... 84

3.3.1.1 TDLOFD-00102601 uplink-downlink subframe configuration type 0 ... 84

3.3.1.2 TDLOFD-00102602 uplink-downlink special subframe configuration type 4 ... 85

3.3.2 TDLOFD-001006 UL 64QAM ... 89

3.3.3 TDLOFD-110227 Traffic Model Based Performance Optimization ... 90

3.3.4 TDLOFD-001015 Enhanced Scheduling ... 91

3.3.4.1 TDLOFD-00101501 CQI Adjustment ... 91

3.3.4.2 TDLOFD-00101502 Dynamic Scheduling ... 92

3.3.5 TDLOFD-081231 Optimized CFI-Calculation-based MCS Index Selection ... 93

3.3.6 TDLOFD-081233 Optimized Uplink Resource Allocation ... 94

3.3.7 TDLOFD-070222 Scheduling Based on Max Bit Rate ... 95

3.3.8 TDLOFD-001028 TCP Proxy Enhancer (TPE) ... 95

3.3.9 TDLOFD-001027 Active Queue Management (AQM) ... 96

3.3.10 TDLOFD-001029 Enhanced Admission Control ... 97

3.3.10.1 TDLOFD-00102901 Radio/transport Resource Pre-emption ... 97

3.3.11 TDLOFD-001054 Flexible User Steering ... 98

3.3.11.1 TDLOFD-00105401 Camp & Handover Based on SPID ... 98

3.3.11.2 TDLOFD-00105402 WBB Subscriber Identification and Specified QoS Guarantee ... 100

3.3.12 TDLOFD-001059 UL Pre-allocation Based on SPID ... 102

3.3.13 TDLOFD-001109 DL Non-GBR Packet Bundling ... 102

3.4 Smart Phone Optimization ... 103

3.4.1 TDLOFD-001105 Dynamic DRX... 103

3.4.1.1 TDLOFD-00110501 Dynamic DRX ... 103

3.4.1.2 TDLOFD-00110502 High-Mobility-Triggered Idle Mode ... 104

3.4.2 TDLOFD-080202 Intelligent Access Class Control ... 105

3.5 Inter-RAT Mobility Solution ... 106

3.5.1 TDLOFD-001019 PS Inter-RAT Mobility between E-UTRAN and UTRAN ... 106

3.5.2 TDLOFD-001043 Service based Inter-RAT handover to UTRAN ... 109

3.5.3 TDLOFD-001072 Distance based Inter-RAT handover to UTRAN ... 110

3.5.4 TDLOFD-001078 E-UTRAN to UTRAN CS/PS Steering ... 110

3.5.5 TDLOFD-001020 PS Inter-RAT Mobility between E-UTRAN and GERAN ... 111

3.5.6 TDLOFD-001046 Service based Inter-RAT handover to GERAN ... 114

3.5.7 TDLOFD-001073 Distance based Inter-RAT handover to GERAN ... 115

3.5.8 TDLOFD-001021 PS Inter-RAT Mobility between E-UTRAN and CDMA2000 ... 115

3.5.9 TDLOFD-001111 PS Mobility from E-UTRAN to CDMA2000 HRPD Based on Frequency-specific Factors ... 117

3.5.10 TDLOFD-001050 Mobility between LTE TDD and LTE FDD ... 118

3.6 High Speed Mobility ... 119

(6)

v

3.6.2 TDLOFD-080205 Handover Enhancement at Speed Mobility ... 121

3.7 Coverage Enhancement ... 123

3.7.1 TDLOFD-001009 Extended Cell Access Radius ... 123

3.7.2 TDLOFD-001031 Extended CP ... 124

3.8 WBB ... 125

3.8.1 TDLOFD-110223 Specified Service Carrier ... 125

4 Networking & Transmission & Security ... 127

4.1 Transmission & Synchronization ... 127

4.1.1 TDLOFD-001076 CPRI Compression ... 127

4.1.2 TDLOFD-081214 Enhanced CPRI Compression ... 128

4.1.3 TDLOFD-003002 2G/3G and LTE Co-transmission ... 129

4.1.4 TDLOFD-003011 Enhanced Transmission QoS Management ... 130

4.1.4.1 TDLOFD-00301101 Transport Overbooking ... 130

4.1.4.2 TDLOFD-00301102 Transport Differentiated Flow Control ... 131

4.1.4.3 TDLOFD-00301103 Transport Resource Overload Control ... 132

4.1.5 TDLOFD-003012 IP Performance Monitoring ... 133

4.1.5.1 TDLOFD-00301201 IP Performance Monitoring ... 133

4.1.5.2 TDLOFD-00301202 Transport Dynamic Flow Control ... 133

4.1.6 TDLOFD-003018 IP Active Performance Measurement ... 134

4.1.7 TDLOFD-003013 Enhanced Synchronization ... 136

4.1.7.1 TDLOFD-00301302 IEEE1588 V2 Clock Synchronization ... 136

4.1.8 TDLOFD-081213 Inter-BBU Clock Sharing ... 139

4.1.9 TDLOFD-003016 Different Transport Paths based on QoS Grade ... 140

4.1.10 TDLOFD-001134 Virtual Routing and Forwarding ... 141

4.1.11 TDLOFD-003017 S1 and X2 over IPv6 ... 142

4.1.12 TDLOFD-003024 IPsec for IPv6 ... 143

4.2 Security ... 145

4.2.1 TDLOFD-001010 Security Mechanism ... 145

4.2.1.1 TDLOFD-00101001 Encryption: AES ... 145

4.2.1.2 TDLOFD-00101002 Encryption: SNOW 3G ... 145

4.2.1.3 TDLOFD-00101003 Encryption: ZUC ... 146

4.2.2 TDLOFD-003009 IPsec ... 147

4.2.3 TDLOFD-081211 eNodeB Supporting IPsec Redirection ... 148

4.2.4 TDLOFD-003010 Public Key Infrastructure (PKI) ... 150

4.2.5 TDLOFD-081206 eNodeB Supporting Multi-operator PKI ... 152

4.2.6 TDLOFD-003014 Integrated Firewall ... 154

4.2.6.1 TDLOFD-00301401 Access Control List (ACL) ... 154

4.2.6.2 TDLOFD-00301402 Access Control List (ACL) autogeneration ... 154

4.2.7 TDLOFD-003015 Access Control based on 802.1x ... 155

4.2.8 TDLOFD-070211 IPsec Redundancy among Multi-SeGWs ... 156

(7)

vi

4.3 Reliability ... 159

4.3.1 TDLOFD-001018 S1-flex ... 159

4.3.2 TDLOFD-003004 Ethernet OAM ... 161

4.3.2.1 TDLOFD-00300401 Ethernet OAM (IEEE 802.3ah) ... 161

4.3.2.2 TDLOFD-00300403 Ethernet OAM (Y.1731) ... 162

4.3.3 TDLOFD-003005 OM Channel Backup ... 163

4.3.4 TDLOFD-003006 IP Route Backup ... 163

4.3.5 TDLOFD-003007 Bidirectional Forwarding Detection ... 164

4.3.6 TDLOFD-003008 Ethernet Link Aggregation (IEEE 802.3ad) ... 165

4.4 RAN Sharing ... 167

4.4.1 TDLOFD-001036 RAN Sharing with Common Carrier ... 167

4.4.2 TDLOFD-001037 RAN Sharing with Dedicated Carrier ... 168

4.4.3 TDLOFD-081224 Hybrid RAN Sharing ... 170

4.4.4 TDLOFD-001086 RAN Sharing by More Operators ... 172

4.4.5 TDLOFD-001112 MOCN Flexible Priority Based Camping ... 173

4.4.6 TDLOFD-001133 Multi Operators SPID Policy ... 174

4.5 Advance Micro... 175

4.5.1 TDLOFD-001057 Load Balancing based on Transport QoS ... 175

4.5.2 TDLOFD-003022 PPPoE ... 176

5 O&M ... 177

5.1 SON ... 177

5.1.1 TDLOFD-002001 Automatic Neighbour Relation (ANR) ... 177

5.1.2 TDLOFD-002002 Inter-RAT ANR ... 179

5.1.3 TDLOFD-002004 Self-configuration ... 182

5.1.4 TDLOFD-002007 PCI Collision Detection & Self-Optimization ... 184

5.1.5 TDLOFD-110231 Auto Neighbor Group Configuration ... 186

5.1.6 TDLOFD-002005 Mobility Robust Optimization (MRO) ... 187

5.1.7 TDLOFD-081201 Specified PCI Group-based Neighboring Cell Management ... 189

5.1.8 TDLOFD-081209 Automatic Congestion Handling ... 190

5.1.9 TDLOFD-002011 Antenna Fault Detection ... 192

5.1.10 TDLOFD-002012 Cell Outage Detection and Compensation ... 193

5.2 MLB ... 194

5.2.1 TDLOFD-001032 Intra-LTE Load Balancing ... 194

5.2.2 TDLOFD-001123 Enhanced Intra-LTE Load Balancing ... 196

5.2.3 TDLOFD-070215 Intra-LTE User Number Load Balancing ... 197

5.2.4 TDLOFD-081210 Multi-RRU Cell Load Balancing ... 198

5.2.5 TDLOFD-001044 Inter-RAT Load Sharing to UTRAN ... 199

5.2.6 TDLOFD-001045 Inter-RAT Load Sharing to GERAN ... 201

5.3 Power Saving ... 202

5.3.1 TDLOFD-001039 RF Channel Intelligent Shutdown ... 202

(8)

vii

5.3.3 TDLOFD-001041 Power Consumption Monitoring ... 204

5.3.4 TDLOFD-001042 Intelligent Power-Off of Carriers in the Same Coverage ... 204

5.3.5 TDLOFD-001056 PSU Intelligent Sleep Mode ... 205

5.3.6 TDLOFD-001070 Symbol Power Saving ... 206

5.3.7 TDLOFD-001071 Intelligent Battery Management ... 208

5.4 Antenna Management ... 209

5.4.1 TDLOFD-001024 Remote Electrical Tilt Control ... 209

(9)

Optional Feature Description 1 Change History

1

Change History

Issue Date Author Change Description

02 2016-07

-30 Xu Xiaohong This is Issue 02 for GA version.

01 2016-01

-01 Xu Nan This is Issue 01. Draft A 2015-11

-18 Xu Nan This document is based on LTE TDD eRAN11.0 Optional Feature Description. The following

features have been added or enhanced: New features:

 TDLOFD-111207 VoLTE Rate Control  TDLOFD-111202 Coverage-based VoLTE

Experience Optimization

 TDLOFD-111205 Busy-Hour Download Rate Control

 TDLOFD-111206 Video Service Rate Adaption

 TDLOFD-110225 Uplink Data Compression  TDLOFD-111208 Uplink Interference

Coordination

 TDLOFD-111201 Remote Interference Adaptive Avoidance

Enhanced features:

 TDLOFD-081222 Dynamic Service-specific Access Control

 TDLOFD-080202 Intelligent Access Class Control

 TDLOFD-081213 Inter-BBU Clock Sharing  _{TDLOFD-070211 IPsec Redundancy among}

Multi-SeGWs

(10)

2

Issue Date Author Change Description

Detection

 TDLOFD-002001 Automatic Neighbour Relation (ANR)

 TDLOFD-002002 Inter-RAT ANR  TDLOFD-002004 Self-configuration  TDLOFD-110231 Auto Neighbor Group

Configuration

 TDLOFD-081209 Automatic Congestion Handling

 TDLOFD-001032 Intra-LTE Load Balancing  TDLOFD-070215 Intra-LTE User Number

Load Balancing

 TDLOFD-001024 Remote Electrical Tilt Control

(11)

Optional Feature Description 2 Voice & Other Services

3

2

Voice & Other Services

2.1 VoLTE

2.1.1 TDLOFD-001016 VoIP Semi-persistent Scheduling

Availability

This feature was introduced in LTE TDD eRAN2.0.

This feature is applicable to micro eNodeBs from LTE TDD eRAN6.1.

Summary

Semi-persistent scheduling is a technique for efficiently assigning resources for spurts of traffic in a wireless communications system. A semi-persistent resource assignment is valid as long as more data is sent within a predetermined time period after the last data sent, and expires if no data is sent within the predetermined time period. For voice over IP (VoIP) services, a semi-persistent resource assignment may be granted for a voice frame in anticipation of a voice service traffic spurt.

Benefits

This feature is essential to VoIP services and provides the following benefits:

 _{Guarantees the QoS for VoIP services.}

 _{Reduces the control signaling overhead for VoIP transmission.}

 _{Maximizes resource utilization by dynamically activating or deactivating resource}

allocation according to the transition between silent period and talk spurt.

Description

This feature is essential to delivery of the voice service with acceptable quality. E-UTRAN is optimized in terms of packet data transfer, and the core network is purely IP packet-based. The voice service data is transmitted by means of VoIP instead of using the traditional circuit-based method. To ensure voice quality, a semi-persistent scheduling solution is used for VoIP services.

VoIP is a real-time service with small and fixed-length data packets and constant arrival time. VoIP traffic consists of talk spurts and silent periods. The adaptive multirate (AMR) codec can

(12)

4

yield quiet burst voice traffic. During a talk spurt, VoIP packets normally arrive at intervals of 20 ms. During a silent period, silence indicator (SID) packets arrive at intervals of 160 ms. During semi-persistent scheduling, the eNodeB allocates a certain amount of resources (such as resource blocks) for the voice call during the call setup period by using radio resource control (RRC) signaling. The allocation is semi-persistent and does not require a repeat request by using UL/DL control signaling until the call is complete and the resources are released. To maximize resource utilization during a silent period, resource allocation is deactivated by means of explicit signaling exchanged over the physical downlink control channel (PDCCH). When the VoIP call transits from silent period to talk spurt, similar PDCCH signaling is used to activate the semi-persistent resource allocation. The

semi-persistent scheduling significantly reduces the PDCCH overhead and ensures the QoS for VoIP services by reserving resources in a semi-persistent manner. It also improves

resource utilization by dynamically activating or deactivating resource allocation between talk spurt and silent period.

Enhancement

None

Dependency

UEs must support semi-persistent scheduling.

This feature cannot be used with the following features:

 _{TDLOFD-001048 TTI Bundling}  _{TDLOFD-001007 High Speed Mobility}

2.1.2 TDLOFD-001017 RObust Header Compression (ROHC)

Availability

Summary

ROHC provides an efficient and flexible header compression mechanism, which is

particularly important for improving the bandwidth utilization for VoIP services with a small payload.

Benefits

This feature provides the following benefits:

 _{Reduces the IP packet header size}

 _{Significantly increases the ratio of the payload to header for VoIP services with a small}

payload

 _{Shortens the response time to guarantee the high usage of links between eNodeBs and}

(13)

5

Description

As more and more wireless technologies are being deployed to carry IP traffic, the total header size needs to be reduced during transmission because of large packet overhead. This improves bandwidth resource utilization, particularly for services with a small payload (for example, VoIP services).

On an end-to-end transmission path, the entire header information is necessary for all packets in the flow. However, over a radio link (a portion of the end-to-end path), some data in the information is redundant and can be reduced because they can be transparently recovered at the receiving end.

The ROHC protocol provides an efficient, flexible, and future-proof header compression method to compress and decompress IP, UDP, RTP, and ESP packet headers. It is designed to operate efficiently and robustly over various link technologies with different characteristics, especially for wireless transmission.

In an LTE system, ROHC is implemented in Packet Data Convergence Protocol (PDCP) entities associated with user-plane packets. In the UL, the packets are compressed by the UE and decompressed by the eNodeB. In the DL, the packets are compressed by the eNodeB and decompressed by the UE.

The relative gain for specific flows or applications depends on the size of the payload used in each packet. Header compression significantly improves the bandwidth utilization for VoIP services with a small payload.

Huawei LTE eNodeBs support profiles 0x0000 to 0x0004 based on both IPv4 and IPv6. Table 2-1 shows the profile identifiers and their associated header compression protocols.

Table 2-1 ROHC profile identifier and header compression protocol

Profile Identifier Header Compression Protocol

0x0000 No compression 0x0001 RTP, UDP, IP 0x0002 UDP, IP 0x0003 ESP, IP 0x0004 IP

Enhancement

None

Dependency

(14)

6

2.1.3 TDLOFD-001048 TTI Bundling

Availability

Summary

When this feature is enabled, cell edge users (CEUs) with a low signal to interference plus noise ratio (SINR) in the uplink can retransmit the same data block in continuous subframe.

Benefits

TTI bundling improves uplink coverage and indoor reception for VoIP services.

Description

The activation and deactivation of TTI bundling transmission is controlled by RRC signaling messages.

If TTI bundling is configured at the RRC layer, TTI_BUNDLE_SIZE specifies the number of TTIs in a TTI bundle. Within a TTI bundle, hybrid automatic repeat request (HARQ)

retransmissions are non-adaptive and are performed without waiting for feedback (for example, NACK or ACK) related to previous transmissions according to

TTI_BUNDLE_SIZE. A feedback for a TTI bundle is only received for a specific TTI

corresponding to TTI_BUNDLE_SIZE. A retransmission of a TTI bundle is also a TTI bundle. TTI_BUNDLE_SIZE is fixed at 4. ACK is short for acknowledgement and NACK is short for negative acknowledgement.

According to 3GPP specifications, only uplink-downlink subframe configuration types 0, 1, and 6 support this feature.

Enhancement

None

Dependency

UEs must support TTI bundling.

 _{TDLBFD-00100701 uplink-downlink subframe configuration type1&2 (type 2 is not}

supported)

 _{TDLOFD-001016 VoIP Semi-persistent Scheduling}  _{TDLOFD-001058 UL 2x4 MU-MIMO}

2.1.4 TDLOFD-081229 Voice Characteristic Awareness Scheduling

Availability

This feature is

(15)

7

 _{Applicable to Micro from LTE TDD eRAN8.1.}  _{Applicable to LampSite from LTE TDD eRAN8.1.}

Summary

This feature is implemented based on uplink delay-based dynamic scheduling and uplink VoLTE volume estimation for dynamic scheduling. This feature adjusts scheduling priorities and estimates uplink volume to be scheduled to improve uplink voice performance in heavy traffic scenarios.

In heavy-traffic scenarios where data and voice services coexist, the eNodeB prioritizes SR scheduling requests. This allows voice services to be preferentially scheduled, which ensures the voice quality.

The independent configuration for voice inactivity timer improves user experiences on voice services.

Benefits

This feature improves uplink voice performance in heavy traffic scenarios.

Description

 _{Uplink delay-based dynamic scheduling}

The eNodeB prioritizes voice packets based on their waiting times; a longer waiting time indicates a higher priority. This way, the eNodeB makes a balance among scheduling queues and improves voice quality, especially the voice quality of UEs at the cell edge where channel conditions are poor.

 _{Uplink VoLTE volume estimation for dynamic scheduling}

The eNodeB estimates uplink VoLTE volume for dynamic scheduling based on the VoLTE model and uplink scheduling intervals:

− During talk spurts, the eNodeB estimates the number of voice packets in the UE

buffer based on their uplink scheduling intervals and then calculates the volume of voice packets based on the size of a voice packet.

− During silent periods, the eNodeB takes the size of a voice packet as the uplink

VoLTE volume for dynamic scheduling.

When a called UE does not answer the call, the calling UE is released after the UE inactivity timer expires. In this case, the calling UE in idle mode may be reselected to a cell that does not support voice services. If the called UE starts to answer the call, the service with QCI of 1 of the calling UE fails to be set up.

With independent configuration for voice inactivity timer, the UEs can distinguish voice and non-voice scenarios. That is, the length of the UE inactivity timer can be independently configured to avoid the preceding negative impact.

Enhancement

 _{eRAN TDD 11.0}

UL Delay-based Dynamic Scheduling is enhanced in eRAN11.0. In heavy-traffic scenarios where data and voice services coexist, the eNodeB prioritizes SR scheduling requests. This allows voice services to be preferentially scheduled, which ensures the voice quality.

(16)

8

Dependency

 _eNodeB None  _eCo None  _UE None  _{Transport network} None  _CN None  _OSS None  _{Other features}

This feature applies only to VoLTE services. This feature requires the following features:

− TDLBFD-002025 Basic Scheduling − TDLOFD-00101502 Dynamic Scheduling  _Others

None

2.1.5 TDLOFD-111202 Coverage-based VoLTE Experience

Optimization

Availability

This feature is:

 _{Available in macro eNodeBs as of LTE TDD eRAN11.1.}  _{Available in LampSite eNodeBs as of LTE TDD eRAN11.1.}  _{Available in micro eNodeBs as of LTE TDD eRAN11.1.}

Summary

The coverage-based VoLTE experience optimization feature performs admission decision on dedicated voice bearers based on the uplink channel quality. The eNodeB identifies UEs in areas with weak coverage and rejects setup of their dedicated voice bearers. The IMS instructs the UEs to retry CSFB-based calls so that voice calls can be made successfully.

Benefits

This feature improves user experience for VoLTE UEs in areas with weak coverage and prevents Before Alerting SRVCC (bSRVCC) call drops.

Description

After this feature is enabled, the eNodeB calculates the uplink path loss (PathLoss) based on the power headroom report (PHR) received from a NE, and measures the uplink SRS

(17)

9

reference signals to obtain the uplink SINR. Then, the eNodeB determines whether the UE is located in an area with weak coverage based on the PathLoss and SINR. The eNodeB rejects setup of the dedicated voice bearers for UEs in areas with weak coverage.

 _{When the call is a mobile originated call, the IMS sends a SIP message (SIP 500/380/503)}

for the UE to trigger the CSFB procedure if setup of the dedicated voice bearer fails.

 _{When the call is a mobile terminated call (MTC), the IMS initiates the MTC procedure}

in the GSM CS domain so that the UE triggers the CSFB procedure.

The IMS enables UEs in areas with weak coverage to trigger the CSFB procedure so that voice calls can be made successfully.

Enhancement

None

Dependency

 _eNodeB None  _eCoordinator None  _UE

The UE must be capable of initiating a CSFB-based call upon receipt of error codes such as SIP 500/380/503.

 _CN

The IMS must be capable of instructing a UE to initiate the CSFB procedure in case of a failed voice service setup.

 _{Other NEs}

None

 _{Other features}

This feature requires any of the following features: TDLOFD-001034 CS Fallback to GERAN

TDLOFD-001053 Flash CS Fallback to GERAN TDLOFD-081203 Ultra-Flash CSFB to GERAN

 _Others

None

2.1.6 TDLOFD-111207 VoLTE Rate Control

Availability

This feature is:

 _{Available in macro eNodeBs as of LTE TDD eRAN11.1.}  _{Available in LampSite eNodeBs as of LTE TDD eRAN11.1.}  _{Available in micro eNodeBs as of LTE TDD eRAN11.1.}

(18)

10

Summary

VoLTE Rate Control adjusts the AMR-NB/AMR-WB rate for uplink voice services depending on the uplink channel quality and voice quality. The feature helps improve the voice quality and LTE uplink coverage.

Benefits

This feature helps improve the voice quality and LTE uplink coverage.

Description

Figure 2-1 Before the feature is enabled

Before the feature is enabled, UEs use a fixed coding rate. As shown in Figure 2-1, a UE uses a high voice coding rate during the access. When the UE moves to a weak coverage area, the coding rate remains unchanged. As a result, the uplink voice coverage is restricted.

Figure 2-2 After the feature is enabled

After this feature is enabled, the eNodeB adjusts the AMR-NB/AMR-WB rate for uplink voice services depending on the uplink channel quality and voice quality, as shown in Figure 2-2.

 _{When the uplink channel quality and voice quality are favorable, a high voice coding}

rate is used to further improve the voice quality.

 _{When the uplink channel quality and voice quality are poor, a low voice coding rate is}

used to improve the uplink voice coverage.

Enchancement

None

Dependency

 _eNodeB

(19)

11

 _eCoordinator

None

 _UE

The UE supports AMR rate adjustment.

 _{Core network}

The CN works with the SBC to support the SBC joint rate adjustment solution.

 _{Other NEs} None  _{Other features} None  _Others None

2.1.7 TDLOFD-001022 SRVCC to UTRAN

Availability

Summary

SRVCC is a solution to provide voice services on LTE networks. During initial LTE network deployment, when UEs running voice services move out of an LTE network, voice services can continue in the legacy circuit switched (CS) domain by means of SRVCC, ensuring voice service continuity.

SRVCC requires the IMS. It is used in specific scenarios on LTE networks.

Benefits

The service interruption period during a handover can be reduced to improve user experience with voice services.

Description

To facilitate session transfer of voice services to the CS domain, the IMS multimedia telephony sessions must be implemented on the IMS.

The procedure for SRVCC from E-UTRAN to UTRAN is as follows

1. The MME receives the handover request from the E-UTRAN with the SRVCC handling indication. The MME then triggers the SRVCC procedure with the mobile switching center (MSC) server enhanced for SRVCC through the Sv interface if the MME has SRVCC STN-SR information for this UE.

2. The MSC server enhanced for SRVCC initiates session transfer to the IMS and coordinates it with a CS handover to the target UTRAN cell.

3. The MSC server enhanced for SRVCC sends a Forward Relocation Response message to the MME, which includes the necessary CS handover command information for the UE to access the UTRAN cell.

(20)

12

4. The MME performs the bearer splitting function to separate the voice bearer from non-voice bearers. Then, the MME initiates a CS handover for the voice bearer to the MSC server and initiates a packet switched (PS) handover for the non-voice bearers to the serving GPRS support node (SGSN).

The MME may suppress the PS handover during the SRVCC procedure. A PS handover is performed by following the inter-RAT handover procedure defined in 3GPP TS 23.401. The MME processes the Forward Relocation Response message from the MSC server during the SRVCC and PS-PS handover procedures.

Figure 2-3 shows the SRVCC from E-UTRAN to UTRAN.

Figure 2-3 SRVCC from E-UTRAN to UTRAN

Enhancement

None

Dependency

This feature requires IMS multimedia telephony and the TDLOFD-001019 PS Inter-RAT Mobility between E-UTRAN and UTRAN feature.

UEs must support SRVCC to UTRAN.

2.1.8 TDLOFD-001023 SRVCC to GERAN

Availability

Summary

SRVCC is a solution to provide voice services on LTE networks. During initial LTE network deployment, when UEs running voice services move out of an LTE network, the voice services can continue in the legacy CS domain by means of SRVCC, ensuring voice service

(21)

13

continuity. SRVCC requires the IMS. It is used in specific scenarios on LTE networks. There are no commercial UEs which can support this feature.

Benefits

When a UE moves from E-UTRAN to GERAN, SRVCC maintains voice call continuity for the UE.

Description

When a UE moves from E-UTRAN to GERAN, SRVCC is used to maintain voice call continuity for the UE.

To facilitate session transfer of voice services to the CS domain, the IMS multimedia telephony sessions must be implemented on the IMS.

The procedure for SRVCC from E-UTRAN to GERAN is as follows: The MME receives the handover request from the E-UTRAN indicating SRVCC handling. The MME then triggers the SRVCC procedure with the MSC server enhanced for SRVCC through the Sv interface if the MME has SRVCC STN-SR information for this UE. The MSC server enhanced for SRVCC initiates session transfer to the IMS and coordinates it with a CS handover to the target GERAN cell. The MSC server enhanced for SRVCC sends a Forward Relocation Response message to the MME, which includes the necessary CS handover command information for the UE to access the GERAN cell.

The MME performs the bearer splitting function to separate the voice bearer from non-voice bearers. The MME may suppress the PS handover during the SRVCC procedure. A PS handover is performed by following the inter-RAT handover procedure defined in 3GPP TS 23.401. The MME processes the Forward Relocation Response message from the MSC server during the SRVCC and PS-PS handover procedures.

Figure 2-4 shows the SRVCC from E-UTRAN to GERAN.

Figure 2-4 SRVCC from E-UTRAN to GERAN

Enhancement

In eRAN8.1, the eNodeB can delete inter-frequency measurements in SRVCC to GERAN handovers.

(22)

14

To facilitate the reporting of GERAN measurements and avoid call drop caused by delayed handover, the following functions are implemented:

 _{If the VoIP service is active, all inter-frequency measurements are deleted when}

coverage-based GERAN measurements are started.

 _{If the VoIP service is initiated after coverage-based GERAN measurements are started,}

deleting all inter-frequency measurements is triggered.

 _{If it is detected that the VoIP service is active after coverage-based GERAN}

measurements are started, inter-frequency measurements are prohibited.

Dependency

UEs must support SRVCC.

This feature requires IMS multimedia telephony and the TDLOFD-001020 PS Inter-RAT Mobility between E-UTRAN and GERAN feature. UEs must support SRVCC to GERAN.

2.2 CSFB

2.2.1 TDLOFD-001033 CS Fallback to UTRAN

Availability

Summary

E-UTRAN cannot provide CS services. When UEs camp in an area overlapped by E-UTRAN and UTRAN coverage, this feature allows users to perform CS services.

Benefits

CS services are available for users when UEs camp in an area overlapped by E-UTRAN and UTRAN coverage.

Description

By using legacy CS infrastructure, this feature allows users to perform voice and other CS services (such as SMS and LCS) when UEs are served by the E-UTRAN. A

CS-fallback-capable UE connected to E-UTRAN may establish one or more CS services in the UTRAN. This feature is available only when the E-UTRAN coverage and UTRAN coverage overlap.

CS fallback and IMS-based services can be used simultaneously in the same operator's network.

(23)

15

Figure 2-5 Network for CS fallback to UTRAN

The MGW is not shown in Figure 2-5 because this feature does not affect user-plane processing.

Enhancement

In LTE TDD eRAN6.0, the CS fallback function based on the UTRAN cell load in this feature is enhanced.

eNodeBs perform CS Fallback to UTRAN based on the UTRAN cell load information, which is shared with E-UTRAN cells by using the RAN Information Management (RIM) procedure. Cell load information shared between a radio network controller (RNC) and an eNodeB is used in target cell selection for CS fallback. This increases the success rate of CS fallback to UTRAN, prevents unnecessary delay and signaling overhead, and improves user experience.

Dependency

UEs must support CSFB.

This feature requires TDLOFD-001019 PS Inter-RAT Mobility between E-UTRAN and UTRAN.

CS fallback based on the UTRAN cell load requires the core network and RNC to support RIM-based load information transfer to E-UTRAN.

 _{TDLOFD-001035 CS Fallback to CDMA2000 1xRTT}

 _{TDLOFD-001090 Enhanced CS Fallback to CDMA2000 1xRTT}

2.2.2 TDLOFD-001052 Flash CS Fallback to UTRAN

Availability

Summary

(24)

16

Flash CS fallback to UTRAN can be performed when the RAN Information Management (RIM) procedure is supported by UEs, core networks, and RANs in both LTE and UMTS systems.

If the networks and UEs do not support 3GPP R9 specifications, flash CS fallback to UTRAN can also be accomplished by using blind CS fallback.

Benefits

This feature decreases CS service access delay to improve user experience. The delay in flash CS fallback to UTRAN is about 1 second shorter than CS fallback defined in 3GPP R8 specifications, and approximates the delay in UMTS calls.

Description

The RIM procedure is accomplished with the MME and the UMTS core network, which transparently forwards the request to the target UMTS cell. Then, the target cell encapsulates the system information and sends it back to the LTE cell.

The eNodeB can obtain system information for neighboring UMTS cells with the RIM procedure based on 3GPP R9 specifications. The system information can be sent to the UE during flash CS fallback so that the procedures of requesting and updating the system information can be omitted or partially omitted. As a result, the delay is reduced during CS fallback.

A UE can benefit from blind CS fallback regardless of whether the UE complies with 3GPP R9 specifications. When a neighboring cell supporting blind handover has been configured for an LTE cell, blind handover significantly decreases measurement and SI access delay.

Enhancement

In LTE TDD eRAN6.0, the following functions are enhanced:

 _{Enhanced blind handover}

In an LTE/UMTS multimode base station, the E-UTRAN uses a different antenna system from the UTRAN. The LTE cell edge may not be included in the UMTS cell coverage. If the LTE frequency band is lower than the UMTS frequency band, the LTE cell coverage is greater than the UMTS cell coverage. In this scenario, the handover success rate for CS fallback of CEUs is low, which deteriorates user experience.

To address this issue, eRAN6.0 introduces adaptive blind handover for CS fallback. Event A1 is used to distinguish between cell center users (CCUs) and CEUs. The eNodeB applies blind handovers and measurement-based handovers to CCUs and CEUs, respectively. This conserves CCU inter-RAT measurement time and increases the CSFB success rate for CEUs.

 _{Enhanced redirection}

As defined in 3GPP specifications, UEs do not preferentially select a target cell whose SIBs have been delivered by the eNodeB, but instead follow general cell selection rules. If a target cell whose SIBs have been delivered by the eNodeB is selected, UEs do not need to obtain its SIBs after fallback. The greater the number of such cells, the higher the probability that flash CS fallback succeeds. However, this also increases the size of RRCConnectionRelease messages over the air interface. If the signal quality is poor, these messages may be lost.

To enhance redirection for flash CS fallback in eRAN6.0, a parameter has been added to specify the maximum number of GSM cells whose SIBs can be delivered by the eNodeB

(25)

17

during redirection. Operators can specify an appropriate value for this parameter based on their network performance.

Dependency

The core network and UEs must support CSFB.

This feature requires TDLOFD-001033 CS Fallback to UTRAN. This feature cannot be used with the following features:

2.2.3 TDLOFD-001068 CS Fallback with LAI to UTRAN

Availability

Summary

By using the newly defined LAI IE, the eNodeB can resolve the difference between the target RATs selected by the eNodeB and MME and the selected target cells due to the discrepancy between the tracking area (TA) and (location area) LA. The optimized CS fallback process prevents unnecessary location area update (LAU) procedures and reduces the CS fallback E2E latency.

If an operator only deploys LTE networks, CS fallback depends on the UMTS network deployed by other operators. The optimized CS fallback process prevents incorrect PLMN selection in such a multi-PLMN scenario.

Benefits

During CS fallback from E-UTRAN to UTRAN, this feature reduces the LAU possibility, and therefore shortens the CS fallback delay due to unnecessary LAU procedures. In multi-PLMN scenarios, this feature prevents CS fallback failures due to PLMN updates.

Description

In the GSM/UMTS/LTE coexistence scenario, the operator selects the combined MME/UMTS MSC attach policy when the MME receives the attach request from a

GSM/UMTS/LTE or UMTS/LTE multi-mode terminal because the MME does not recognize the UE capability. The MME maintains the mapping relationships between the TA and LA. The LA belongs to the attached UMTS MSC.

The MME sends the LA to the eNodeB by using the newly defined LAI IE in S1AP. When receiving the CSFB indication and location area identity (LAI), the eNodeB can select the proper RAT and neighboring cell.

Enhancement

(26)

18

Dependency

UEs must support CS fallback.

The core network must support the LAI IE.

This feature cannot coexist with following features: TDLOFD-001035 CS Fallback to CDMA2000 1xRTT

TDLOFD-001090 Enhanced CS Fallback to CDMA2000 1xRTT

2.2.4 TDLOFD-001088 CS Fallback Steering to UTRAN

Availability

Summary

Huawei eNodeBs support CS fallback steering to UTRAN based on the UE status, target RAT priorities, target UTRAN frequency priorities, and CS fallback mechanism priorities.

Benefits

With this feature, operators who have deployed both an E-UTRAN and a UTRAN can achieve CS fallback of UEs to a specified RAT or inter-RAT frequency based on the network plan and load balancing requirements.

Description

CS fallback steering to UTRAN can be performed based on the following configurations:

 _{UE status, including idle (supporting CS only) and active (supporting CS and PS)}  _{Priorities of RATs, including GERAN and UTRAN}

 _{Priorities of UTRAN frequencies, including R99 and High Speed Packet Access (HSPA)}  _{Priorities of CS fallback mechanisms, including PS handover, PS redirection, and flash}

CS fallback

The preceding configurations can be modified.

Enhancement

None

Dependency

This feature requires the following:

 _{TDLOFD-001033 CS Fallback to UTRAN}

 _{TDLOFD-001078 E-UTRAN to UTRAN CS/PS Steering}

(27)

19

If TDLOFD-001068 CS Fallback with LAI to UTRAN is activated, CS fallback steering to UTRAN considers the LAI during target RAT selection.

2.2.5 TDLOFD-081223 Ultra-Flash CSFB to UTRAN

Availability

This feature is:

 _{Available in macro eNodeBs and LampSite eNodeBs as of LTE TDD eRAN8.1.}  _{Not available in micro eNodeBs.}

Summary

This feature applies to areas where UTRAN and LTE networks are deployed and LTE networks do not support VoIP services.

When a UE initiates a CS service setup request in an LTE cell, this feature enables the RNC to prepare CS resources before a CS fallback through the SRVCC handover procedure. This shortens the access delay for the CS fallback and improves user experience.

Benefits

This feature shortens the access delay for CS fallbacks by around 1 second and improves user experience.

Description

This feature works as follows:

1. When a UE initiates a CS service setup request in an LTE cell, the eNodeB triggers an LTE-to-UTRAN SRVCC handover.

2. Upon identifying the proprietary SRVCC-based CS fallback procedure, the CN sends the RNC a RELOCATION REQUEST message that includes parameter indications

instructing the RNC to prepare CS resources before a CS fallback.

3. Based on the indications, the RNC prepares the required CS resources. The RNC then performs special operations to ensure that the CS fallback succeeds.

4. After the CS fallback, the UE and CN skip the authentication and encryption procedures required by the standard CS fallback procedure.

(28)

20

Figure 2-6 Working principle of CSFB based on SRVCC

Enhancement

None

Dependency

 _eNodeB None  _UE

UEs must support the LTE-to-UTRAN SRVCC handover procedure.

 _{Transport Network}

None

 _CN

The MME and MSC are provided by Huawei and both support this feature.

 _OSS

None

 _{Other Features}

This feature requires the following features:

− TDLOFD-001033 CS Fallback to UTRAN  _Others

(29)

21

2.2.6 TDLOFD-001034 CS Fallback to GERAN

Availability

Summary

E-UTRAN cannot provide CS services. When UEs camp in an area overlapped by E-UTRAN and GERAN coverage, this feature allows users to perform CS services.

Benefits

CS services are available for users when UEs camp in an area overlapped by E-UTRAN and GERAN coverage.

Description

By using legacy CS infrastructure, this feature allows users to perform voice and other CS services (such as SMS and LCS) when UEs are served by the E-UTRAN. A

CS-fallback-capable UE connected to E-UTRAN may establish one or more CS services in the GERAN. This feature is available only when the E-UTRAN coverage and GERAN coverage overlap.

CS fallback and IMS-based services can be used simultaneously in the same operator's network.

CS fallback to GERAN requires the SGs interface between the MSC server and MME.

Figure 2-7 Network for CS fallback to GERAN

The MGW is not shown in Figure 2-7 because this feature does not affect user-plane processing.

Enhancement

None

Dependency

(30)

22

This feature requires TDLOFD-001020 PS Inter-RAT Mobility between E-UTRAN and GERAN.

The enhancement of CS fallback to GERAN requires support for Huawei GERAN network elements (NEs) and eCoordinator.

2.2.7 TDLOFD-001053 Flash CS Fallback to GERAN

Availability

Summary

Flash CS fallback to GERAN complies with 3GPP R9 specifications.

Flash CS fallback to GERAN can be performed when the RIM procedure is supported by UEs, core networks, and RANs in both LTE and GSM systems.

If the networks and UEs do not support 3GPP R9 specifications, flash CS fallback to GERAN can also be accomplished by using blind CS fallback.

Benefits

This feature decreases CS service access delay to improve user experience. The delay in flash CS fallback to GERAN is about 2 seconds shorter than CS fallback defined in 3GPP R8 specifications, and approximates the delay in GSM calls.

Description

The RIM procedure is accomplished with the MME and the GSM core network, which transparently forwards the request to the target GSM cell. Then, the target cell encapsulates the system information and sends it back to the LTE cell.

The eNodeB can obtain system information for neighboring GSM cells with the RIM procedure based on 3GPP R9 specifications. The system information can be sent to the UE during flash CS fallback so that the procedures of requesting and updating the system information can be omitted or partially omitted. As a result, the delay is reduced during CS fallback.

A UE can benefit from blind CS fallback regardless of whether the UE complies with 3GPP R9 specifications. When a neighboring cell supporting blind handover has been configured for an LTE cell, blind handover significantly decreases measurement and SI access delay.

Enhancement

In LTE TDD eRAN6.0, the following functions are enhanced:

 _{Enhanced blind handover}

In an LTE/GSM multimode base station, the E-UTRAN uses a different antenna system from the GERAN. The LTE cell edge may not be included in the GSM cell coverage. If

(31)

23

the LTE frequency band is lower than the GSM frequency band, the LTE cell coverage is greater than the GSM cell coverage. In this scenario, the handover success rate for CS fallback of CEUs is low, which deteriorates user experience.

To address this issue, eRAN6.0 introduces adaptive blind handover for CS fallback. Event A1 is used to distinguish between CCUs and CEUs. The eNodeB applies blind handovers and measurement-based handovers to CCUs and CEUs, respectively. This conserves CCU inter-RAT measurement time and increases the CSFB success rate for CEUs.

 _{Enhanced redirection}

As defined in 3GPP specifications, UEs do not preferentially select a target cell whose SIBs have been delivered by the eNodeB, but instead follow general cell selection rules. If a target cell whose SIBs have been delivered by the eNodeB is selected, UEs do not need to obtain its SIBs after fallback. Therefore, the greater the number of such cells, the higher the probability that flash CS fallback succeeds. However, this also increases the size of RRCConnectionRelease messages over the air interface. If the signal quality is poor, these messages may be lost.

To enhance redirection for flash CS fallback in eRAN6.0, a parameter has been added to specify the maximum number of GSM cells whose SIBs can be delivered by the eNodeB during redirection. Operators can specify an appropriate value for this parameter based on their network performance.

Dependency

This feature requires TDLOFD-001034 CS Fallback to GERAN. This feature cannot be used with the following features:

2.2.8 TDLOFD-001069 CS Fallback with LAI to GERAN

Availability

Summary

By using the newly defined LAI IE, the eNodeB can resolve the difference between the target RATs selected by the eNodeB and MME and the selected target cells due to the discrepancy between the TA and LA. The optimized CSFB process prevents unnecessary LAU procedures and reduces the CS fallback E2E latency.

If an operator only deploys LTE networks, CS fallback depends on the GSM network deployed by other operators. The optimized CS fallback process prevents incorrect PLMN selection in such a multi-PLMN scenario.

Benefits

During CS fallback from E-UTRAN to GERAN, this feature reduces the LAU possibility, and therefore shortens the CS fallback delay due to unnecessary LAU procedures. In multi-PLMN scenarios, this feature prevents CS fallback failures due to PLMN updates.

(32)

24

Description

In the GSM/UMTS/LTE coexistence scenario, the operator selects the combined MME/GSM MSC attach policy when the MME receives the attach request from a GSM/UMTS/LTE or GSM/LTE multi-mode terminal because the MME does not recognize the UE capability. The MME maintains the mapping relationships between the TA and LA. The LA belongs to the attached GSM MSC.

The MME sends the LA to the eNodeB by using the newly defined LAI IE in S1AP. When receiving the CSFB indication and LAI, the eNodeB can select the proper RAT and neighboring cell.

Enhancement

None

Dependency

The core network must support the LAI IE.

2.2.9 TDLOFD-001089 CS Fallback Steering to GERAN

Availability

Summary

Huawei eNodeBs support CS fallback steering to GERAN based on the UE status, target RAT priorities, and CS fallback mechanism priorities.

Benefits

With this feature, operators who have deployed both an E-UTRAN and a GERAN can achieve CS fallback of UEs to a specified RAT or inter-RAT frequency based on the network plan and load balancing requirements.

Description

CS fallback steering to GERAN can be performed based on the following configurations:

 _{UE status, including idle (supporting CS only) and active (supporting CS and PS)}  _{Priorities of RATs, including GERAN and UTRAN}

 _{Priorities of CS fallback mechanisms, including PS handover, PS redirection, cell change}

order/network assisted cell change (CCO/NACC), and flash CS fallback The preceding configurations can be modified.

(33)

25

Enhancement

None

Dependency

This feature requires TDLOFD-001034 CS Fallback to GERAN.

If operators require prioritization of GERAN and UTRAN frequencies for CS fallback steering, TDLOFD-001088 CS Fallback Steering to UTRAN must be activated.

If TDLOFD-001069 CS Fallback with LAI to GERAN is activated, CS fallback steering to GERAN considers the LAI during target RAT selection.

2.2.10 TDLOFD-081203 Ultra-Flash CSFB to GERAN

Availability

This feature is:

 _{Available in macro eNodeBs and LampSite eNodeBs as of LTE TDD eRAN8.1.}  _{Not available in micro eNodeBs.}

Summary

When a UE initiates a voice service request in a VoIP-incapable E-UTRAN cell within the overlapping area between the E-UTRAN and a GERAN, this feature triggers a single radio voice call continuity (SRVCC) procedure to have circuit switched (CS) resources prepared in the GERAN.

Benefits

This feature decreases the CS fallback (CSFB) delay by about 1.5s and improves user experience.

Description

(34)

26

Figure 2-8 Procedure for ultra-flash CSFB to GERAN

When the core network identifies the Huawei proprietary SRVCC procedure for CSFB, it sends the BSC a handover request message that contains CS-related parameters. As instructed by the message, the BSC prepares CS resources.

Compared with standard CSFB procedures, this CSFB procedure does not require

authentication, ciphering, or CS bearer setup after the UE is handed over to the GERAN. As a result, the CSFB delay decreases.

Enhancement

None

Dependency

 _eNodeB None  _UE

UEs must support SRVCC from E-UTRAN to GERAN.

 _{Transport network}

None

 _{Core network}

MMEs and MSCs must be Huawei equipment and support ultra-flash CSFB.

 _OSS

(35)

27

 _{Other features}

This feature requires the feature TDLOFD-001034 CS Fallback to GERAN.

 _Others

None

2.2.11 TDLOFD-001035 CS Fallback to CDMA2000 1xRTT

Availability

Summary

E-UTRAN cannot provide CS services. When UEs camp in an area overlapped by E-UTRAN coverage and CDMA2000 1x radio transmission technology (CDMA2000 1xRTT) coverage, CS fallback to CDMA2000 1xRTT helps to provide CS services for UEs.

eNodeBs support the following functions related to CS fallback:

 _{Redirection-based CS fallback (Release 8)}

 _{Transmission and reception of short messages for UEs in the LTE network without}

fallback to CDMA2000 1xRTT

Benefits

CS services are available for users when UEs camp in an area overlapped by E-UTRAN and CDMA2000 1xRTT coverage.

Description

By using legacy CS infrastructure, this feature allows users to perform CS services when UEs are served by the E-UTRAN. A CS-fallback-capable UE connected to E-UTRAN may establish one or more CS services. This feature is available only when the E-UTRAN coverage and UTRAN coverage overlap.

CS fallback and IMS-based services are available in the same operator's network.

CS fallback to CDMA2000 1xRTT requires the S102 interface between the Circuit Switched Fallback Interworking Solution Function for 3GPP2 1xCS (1xCS IWS) and MME.

The S102 interface provides a tunnel between the MME and the 1xCS IWS to transfer 3GPP2 1xCS signaling messages.

(36)

28

Figure 2-9 Network for CS fallback to CDMA2000 1xRTT

The media gateway (MGW) is not shown in Figure 2-9 because this feature does not affect user-plane processing.

Enhancement

None

Dependency

The core network must support CS fallback.

The 1xCS IWS must support CS fallback and enhanced CS fallback. The 1xCS IWS may be integrated into an NE, such as a CBSC newly deployed in the CDMA2000 1xRTT network. UEs must support CS fallback.

 _{TDLOFD-001033 CS Fallback to UTRAN}  _{TDLOFD-001034 CS Fallback to GERAN}  _{TDLOFD-001052 Flash CS Fallback to UTRAN}  _{TDLOFD-001053 Flash CS Fallback to GERAN}  _{TDLOFD-001068 CS Fallback with LAI to UTRAN}  _{TDLOFD-001069 CS Fallback with LAI to GERAN}  _{TDLOFD-001078 E-UTRAN to UTRAN CS/PS Steering}  _{TDLOFD-001088 CS Fallback Steering to UTRAN}  _{TDLOFD-001089 CS Fallback Steering to GERAN}

(37)

29

2.2.12 TDLOFD-001090 Enhanced CS Fallback to CDMA2000

1xRTT

Availability

Summary

If an operator has deployed a CDMA2000 1xRTT network and an E-UTRAN, UEs in the overlapping area preferentially camp in the E-UTRAN. However, the operator often requires that the CDMA2000 1xRTT network and E-UTRAN provide CS and PS services for UEs, respectively. To meet such requirements, enhanced CS fallback has been designed to ensure that UEs are handed over to the CDMA2000 1xRTT network when initiating CS services in the overlapping area.

Benefits

With enhanced CS fallback, UEs can be quickly handed over from the E-UTRAN to the CDMA2000 1xRTT network to initiate or receive CS services. This quick handover improves user experience. For example, when a UE is handed over to the CDMA2000 1xRTT network to receive a CS service, the enhanced CS fallback procedure takes only 2 to 3 seconds, which is faster than the normal CS fallback procedure.

Description

Enhanced CS fallback in the EPS helps to provide CS services for UEs in the E-UTRAN by reusing legacy CS infrastructures. After enhanced CS fallback to CDMA2000 1xRTT, a UE can establish one or more CS services. This feature is only available when CDMA2000 1xRTT coverage overlaps with E-UTRAN coverage.

Enhanced CS fallback and IMS-based services are available in the same operator's network. Enhanced CS fallback in the EPS is implemented using the S102 interface between the 1xCS IWS and the MME. The S102 interface provides a tunnel between the MME and the 1xCS IWS to transfer 3GPP2 1xCS signaling messages.

(38)

30

The MGW is not shown in Figure 2-10 because this feature does not affect user-plane processing. During an enhanced CS fallback procedure, the eNodeB hands over the UE to the target CDMA2000 1xRTT network to perform CS services. If the UE is performing PS services in the E-UTRAN, the eNodeB redirects the ongoing PS services to the evolved high rate packet data (eHRPD) network.

Enhancement

None

Dependency

This feature requires TDLOFD-001035 CS Fallback to CDMA2000 1xRTT and TDLOFD-001021 PS Inter-RAT Mobility between E-UTRAN and CDMA2000. If TDLOFD-001021 PS Inter-RAT Mobility between E-UTRAN and CDMA2000 is not enabled, enhanced CS fallback with concurrent non-optimized PS handover cannot work and other functions in TDLOFD-001090 Enhanced CS Fallback to CDMA2000 1xRTT are not affected.

The CDMA2000 1xRTT network must support CS Fallback and enhanced CS fallback. NEs on the network include the 1xCS IWS, CBSC, and CBTS.

The MME must support CS Fallback and enhanced CS fallback. UEs must support CS Fallback and enhanced CS fallback.

If CS fallback to CDMA2000 1xRTT is enabled, eNodeBs do not support CS fallback to GERAN or CS fallback to UTRAN. If CS fallback to GERAN or UTRAN is enabled, eNodeBs do not support CS fallback to CDMA2000 1xRTT.

 _{TDLOFD-001033 CS Fallback to UTRAN}  _{TDLOFD-001034 CS Fallback to GERAN}  _{TDLOFD-001052 Flash CS Fallback to UTRAN}  _{TDLOFD-001053 Flash CS Fallback to GERAN}  _{TDLOFD-001068 CS Fallback with LAI to UTRAN}  _{TDLOFD-001069 CS Fallback with LAI to GERAN}  _{TDLOFD-001078 E-UTRAN to UTRAN CS/PS Steering}  _{TDLOFD-001088 CS Fallback Steering to UTRAN}  _{TDLOFD-001089 CS Fallback Steering to GERAN}