VoIP(eRAN6.0_03)

VoIP Feature Parameter Description

Issue 03

Date 2013-10-30

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

Contents

1 About This Document...1

1.1 Scope...1 1.2 Intended Audience...1 1.3 Change History...2

2 Overview...5

3 VoIP Services...7

3.1 VoIP Traffic Model...7

3.2 VoIP Procedures...8

3.3 VoIP Evaluation...9

3.3.1 QoS Evaluation...9

3.3.2 Voice Quality Evaluation...10

3.3.3 VQM...10

4 Key Technologies...12

4.1 Overview...12

4.2 Admission and Congestion Control...13

4.2.1 Overview...14

4.2.2 Load Monitoring...14

4.2.3 Admission Control...14

4.2.4 Congestion Control...15

4.3 Service-based Inter-RAT or Inter-Frequency Handover...15

4.3.1 Overview...15 4.3.2 Inter-Frequency Handover...15 4.3.3 Inter-RAT Handover...15 4.4 ROHC...16 4.5 Scheduling...16 4.5.1 Overview...16 4.5.2 Dynamic Scheduling...16 4.5.3 Semi-Persistent Scheduling...18

4.6 Power Control...19

4.6.1 Overview...19

4.6.2 Power Control in Dynamic Scheduling...19

4.6.3 Power Control in Semi-Persistent Scheduling...19

4.7 DRX...20

4.8 TTI Bundling...20

5 Related Features...22

5.1 Features Related to Admission and Congestion Control...23

5.1.1 LBFD-002023 Admission Control...23

5.1.2 LBFD-002024 Congestion Control...23

5.2 Features Related to Service-based Handovers...23

5.2.1 LBFD-00201805 Service Based Inter-frequency Handover...23

5.2.2 LOFD-001043 Service based inter-RAT handover to UTRAN...23

5.2.3 LOFD-001046 Service based inter-RAT handover to GERAN...23

5.3 Features Related to LOFD-001017 RObust Header Compression (ROHC)...23

5.4 Features to Related Scheduling...23

5.4.1 LOFD-00101502 Dynamic Scheduling...24

5.4.2 LOFD-001109 DL Non-GBR Packet Bundling...24

5.4.3 LOFD-001016 VoIP Semi-persistent Scheduling...24

5.5 Features Related to Power Control...25

5.5.1 LBFD-002016 Dynamic Downlink Power Allocation...25

5.5.2 LBFD-002026 Uplink Power Control...25

5.6 Features Related to LBFD-002017 DRX...26

5.7 Features Related to LOFD-001048 TTI Bundling...27

6 Network Impact...28

6.1 Admission and Congestion Control...29

6.1.1 LBFD-002023 Admission Control...29

6.1.2 LBFD-002024 Congestion Control...29

6.2 Service-based Handover...29

6.2.1 LBFD-00201805 Service Based Inter-frequency Handover...29

6.2.2 LOFD-001043 Service based inter-RAT handover to UTRAN...29

6.2.3 LOFD-001046 Service based inter-RAT handover to GERAN...30

6.3 LOFD-001017 RObust Header Compression (ROHC)...30

6.4 Scheduling...30

6.4.1 LOFD-00101502 Dynamic Scheduling...30

6.4.2 LOFD-001109 DL Non-GBR Packet Bundling...31

6.4.3 LOFD-001016 VoIP Semi-persistent Scheduling...31

6.5 Power Control...31

6.5.1 LBFD-002016 Dynamic Downlink Power Allocation...31

6.5.2 LBFD-002026 Uplink Power Control...32

6.7 LOFD-001048 TTI Bundling...32

7 Engineering Guidelines...33

7.1 When to Use VoIP...34

7.1.1 Admission and Congestion Control...34

7.1.2 ROHC...34

7.1.3 Dynamic Scheduling...34

7.1.4 When to Use Semi-Persistent Scheduling...34

7.1.5 When to Use Power Control...35

7.1.6 When to Use Dynamic DRX...35

7.1.7 When to Use TTI Bundling...36

7.2 Required Information...36

7.2.1 Admission and Congestion Control...36

7.2.2 ROHC...36 7.2.3 Dynamic Scheduling...36 7.2.4 Semi-Persistent Scheduling...36 7.2.5 Power Control...36 7.2.6 DRX...36 7.2.7 TTI Bundling...37 7.3 Planning...37

7.4 Configuration of Basic Parameters...37

7.4.1 Requirements...38 7.4.2 Data Preparation...38 7.4.3 Precautions...39 7.4.4 Hardware Adjustment...39 7.4.5 Initial Configuration...39 7.4.6 Activation Observation...41 7.4.7 Reconfiguration...43

7.5 Deployment of Admission Control...43

7.6 Deployment of Congestion Control...43

7.7 Deployment of ROHC...43

7.8 Deployment of DL Dynamic Scheduling...44

7.9 Deployment of UL Dynamic Scheduling...45

7.10 Deployment of Semi-Persistent Scheduling...47

7.10.1 Requirements...47 7.10.2 Data Preparation...48 7.10.3 Precautions...50 7.10.4 Hardware Adjustment...50 7.10.5 Activation...50 7.10.6 Activation Observation...52 7.10.7 Reconfiguration...56 7.10.8 Deactivation...56

7.11 Deployment of Power Control in Dynamic Scheduling...56

7.12 Deployment of Power Control in Semi-Persistent Scheduling...57

7.12.1 Requirements...57 7.12.2 Data Preparation...57 7.12.3 Precautions...59 7.12.4 Hardware Adjustment...59 7.12.5 Activation...59 7.12.6 Activation Observation...62 7.12.7 Reconfiguration...65 7.12.8 Deactivation...65 7.13 Deployment of DRX...66

7.14 Deployment of TTI Bundling...66

7.14.1 Requirements...67 7.14.2 Data Preparation...67 7.14.3 Precautions...68 7.14.4 Hardware Adjustment...68 7.14.5 Activation...68 7.14.6 Activation Observation...70 7.14.7 Reconfiguration...72 7.14.8 Deactivation...72 7.15 Performance Monitoring...73

7.15.1 Basic VoIP KPIs...73

7.15.2 Admission Control...77 7.15.3 Congestion Control...77 7.15.4 ROHC...77 7.15.5 Dynamic Scheduling...77 7.15.6 Semi-Persistent Scheduling...77 7.15.7 Power Control...78

7.15.8 Power Control in Semi-Persistent Scheduling...78

7.15.9 DRX...78 7.15.10 TTI Bundling...78 7.16 Parameter Optimization...78 7.17 Troubleshooting...79

8 Parameters...81

9 Counters...152

10 Glossary...153

11 Reference Documents...154

1

About This Document

1.1 Scope

This document describes IMS-based VoIP within a VoIP-capable LTE network, including its technical principles, related features, network impact, and engineering guidelines.

NOTE

IMS is short for IP multimedia subsystem, and VoIP is short for voice over IP.

This document applies to the following types of eNodeBs.

eNodeB Type Model

Macro 3900 series eNodeB Micro BTS3202E and BTS3203E LampSite DBS3900

Any managed objects (MOs), parameters, alarms, or counters described herein correspond to the software release delivered with this document. Any future updates will be described in the product documentation delivered with future software releases.

This document applies only to LTE FDD. Any "LTE" in this document refers to LTE FDD, and "eNodeB" refers to LTE FDD eNodeB.

1.2 Intended Audience

This document is intended for personnel who: l Need to understand the features described herein l Work with Huawei products

1.3 Change History

This section provides information about the changes in different document versions. There are two types of changes, which are defined as follows:

l Feature change

Changes in features of a specific product version l Editorial change

Changes in wording or addition of information that was not described in the earlier version

eRAN6.0 03 (2013-10-30)

This issue includes the following changes.

Change Type Change Description Parameter

Change

Feature change None None

Editorial change Modified the impact of VoIP on LOFD-001016 VoIP Semi-persistent Scheduling and

LAOFD-001001 Carrier Aggregation for Downlink 2CC in 20MHz. For details, see 5.4.3 LOFD-001016 VoIP Semi-persistent

Scheduling.

None

Added the descriptions of LOFD-001048 TTI Bundling and LOFD-001097 Carrier Aggregation Introduction Package. For details, see 5.7 Features Related to LOFD-001048 TTI Bundling.

None

eRAN6.0 02 (2013-08-30)

This issue includes the following changes.

Change Type Change Description Parameter Change

Feature change None None

Editorial change Modified the description of TTI bundling. For details, see 4.8 TTI Bundling.

None

Modified the organizations of 7.16 Parameter Optimization and 7.17 Troubleshooting.

eRAN6.0 01 (2013-04-28)

This issue includes the following changes.

Change Type Change Description Parameter Change

Feature change None None

Editorial change Deleted details on

deployment of the following VoIP-related features: l Admission control l Congestion control l Robust header compression (ROHC) l Power control l DRX

For details regarding deployment of these features, see the corresponding feature parameter descriptions.

None

Added the description of using counters to check the status of semi-persistent scheduling. For details, see

7.10.6 Activation Observation.

None

Added the description of using a counter to check the average number of UEs for which TTI bundling is enabled in a cell. For details, see 7.14.6 Activation Observation.

None

eRAN6.0 Draft A (2013-01-30)

Compared with Issue 03 (2012-12-29) of eRAN3.0, Draft A (2013-01-30) of eRAN6.0 includes the following changes.

Change Type

Change Description Parameter

Change

Feature change

Added the voice quality monitoring (VQM) function. For details, see 3.3.3 VQM.

Change

Type Change Description ParameterChange

Editorial change

2

Overview

2.1 Introduction

VoIP is a voice service over IP networks. Voice over LTE (VoLTE) is a voice service solution for LTE networks, including circuit switched fallback (CSFB), IMS-based VoIP, and single radio voice call continuity (SRVCC).

If an LTE network does not support VoIP, CSFB can be used to provide voice services for LTE users. For details about CSFB, see CS Fallback Feature Parameter Description.

To ensure voice call continuity when users move out of the range of a VoIP-capable LTE network, the LTE network must support single radio voice call continuity (SRVCC). For details about SRVCC, see SRVCC Feature Parameter Description.

IMS-based VoIP is voice sessions set up over IP networks between the UE and the IMS. Unless otherwise specified, VoIP in this document refers to IMS-based VoIP.

Voice services are packet switched (PS) services in the evolved UTRAN (E-UTRAN) but circuit switched (CS) services in the universal terrestrial radio access network (UTRAN) and GSM/ EDGE radio access network (GERAN). If a UE in the E-UTRAN needs to communicate with a UE in the UTRAN/GERAN, the IMS in the LTE network and the mobile switching center (MSC) in the GSM/UMTS network need to process the call from the PS domain to the CS domain.

2.2 Benefits

VoIP provides UEs in the E-UTRAN with voice services, without the need of falling back to GERAN or UTRAN.

2.3 Architecture

Figure 2-1 illustrates the LTE/SAE architecture in non-roaming scenarios. (SAE is short for System Architecture Evolution.) For details about the architectures in roaming and non-roaming scenarios, see section 4.2 Architecture reference model in 3GPP TS 23.401.

Figure 2-1 LTE/SAE architecture in non-roaming scenarios

HSS: home subscriber server PSS: packet-switched streaming service MME: mobility management entity SGSN: serving GPRS support node PCRF: policy and charging rule function UE: user equipment

The operator's IP services shown in Figure 2-1 are implemented using the IMS. The IMS performs session control and multimedia negotiation between the calling and called UEs in compliance with the Session Initiation Protocol (SIP) and Session Description Protocol (SDP). The codec standard used for VoIP is determined by the UE and IMS. For details about the VoIP traffic model under Adaptive Multirate (AMR), see 3.1 VoIP Traffic Model.

For details about VoIP session setup between the calling and called UEs, see 3.2 VoIP Procedures.

For details about VoIP evaluation, see 3.3 VoIP Evaluation.

To provide VoIP services, eNodeBs must support basic/optional features and functions such as admission control, congestion control, and scheduling. For details about these features and functions, see 4 Key Technologies.

3

VoIP Services

3.1 VoIP Traffic Model

3GPP recommends the use of AMR for speech coding. AMR is classified into adaptive multirate wideband (AMR-WB) and adaptive multirate narrowband (AMR-NB). Currently, AMR is widely used in the GERAN and UTRAN as well as in the Huawei LTE VoIP solution.

Figure 3-1 shows the VoIP traffic model under AMR.

Figure 3-1 VoIP traffic model under AMR

There are two VoIP traffic states: l Talk spurts

Talk spurts occur when the user is in conversation. In this state, voice frames are transmitted at intervals of 20 ms, and the packet size is determined by the speech coding rate. l Silent period

During silent periods, the user stops talking. A silence insertion descriptor (SID) frame is transmitted every 160 ms to improve user experience.

3.2 VoIP Procedures

Figure 3-2 shows the procedures for setting up a VoIP session between the calling and called UEs.

Figure 3-2 VoIP session setup procedures

The procedures are as follows:

1. The calling UE sets up a radio resource control (RRC) connection.

2. The calling UE sets up an E-UTRAN radio access bearer (E-RAB) for IMS signaling. The QoS class identifier (QCI) for the E-RAB is 5.

3. The called UE is instructed to set up an RRC connection and an E-RAB for IMS signaling. The QCI for the E-RAB is also 5.

4. The UEs negotiate session information through IMS signaling.

5. After the negotiation, the calling UE and the called UE set up E-RABs with a QCI of 1 for conversational voice. At this time, the entire EPS bearer from the calling UE to the called UE is set up.

6. The called UE sends a ringback tone to the calling UE through IMS signaling. 7. The called UE answers the call and the VoIP conversation begins.

NOTE

Both the UE and the EPC must support the IMS to provide VoIP services.

According to 3GPP, the QCIs for conversational voice and IMS signaling are 1 and 5, respectively. The QCIs are set in StandardQci managed objects (MOs), and the Radio Link Control (RLC) modes for setting up conversational voice and IMS signaling E-RABs are specified by the RlcPdcpParaGroup.RlcMode parameter.

Table 3-1 lists the values for RLC modes recommended in 3GPP.

Table 3-1 Recommended values for RLC modes

QCI Service Type RLC Mode

1 Conversational voice Unacknowledged mode (UM)

5 IMS signaling Acknowledged mode (AM)

For details about QCIs and RLC modes, see QoS Management Feature Parameter

Description.

3.3 VoIP Evaluation

3.3.1 QoS Evaluation

Section 6.1.7 "Standardized QoS characteristics" in 3GPP TS 23.203 (Release 10) lists the standardized QCI characteristics. The QCIs for conversational voice and IMS signaling are 1 and 5, respectively. Table 3-2 lists the standardized characteristics of QCIs 1 and 5.

Table 3-2 Standardized characteristics of QCIs 1 and 5

QCI Resource Type Priority Packet Delay Budget (ms) Packet Error Loss Rate Example Service 1 GBR 2 100 10-2 _Conversatio nal voice 5 Non-GBR 1 100 10-6 _IMS signaling

l The packet delay budget (PDB) defines an upper bound for the time that a packet may be delayed between the UE and the P-GW. The delay from the UE to the P-GW is 100 ms with a confidence level of 98%.

l The packet error loss rate (PELR) defines an upper bound for the rate of service data units (SDUs) that have been processed by the sender of the Automatic Repeat Request (ARQ)

protocol at the data link layer (for example, RLC layer in the E-UTRAN) but are not successfully delivered by the corresponding receiver to the upper layer (for example, PDCP layer in the E-UTRAN).

Counters are used to monitor the statistics of delay, downlink air interface packet loss rate, and downlink PDCP packet loss rate for conversational voice (QCI 1).

3.3.2 Voice Quality Evaluation

Voice quality is the key criterion for voice service.

During a VoIP session, voice quality is affected by delay, delay variation, and packet loss. The mean opinion score (MOS) is primarily used for evaluating voice quality.

The MOS is a common subjective evaluation standard. The MOS for voice services is categorized as five levels by ITU-T G.107 with respective definitions of speech transmission quality and user satisfaction, as detailed in Table 3-3. For the same delay, delay variation, and packet error loss rate, the MOS varies with the speech coding rate.

Table 3-3 MOS for voice service

MOS Speech Transmission

Quality Category User Satisfaction

4.34 Best Very satisfied

4.03 High Satisfied

3.60 Medium Some users dissatisfied

3.10 Low Many users dissatisfied

2.58 Poor Nearly all users dissatisfied

Counters are used to monitor the statistics of user satisfaction for conversational voice (QCI 1).

3.3.3 VQM

Overview

Voice quality monitoring (VQM) is mainly used for network monitoring, network optimization, VIP guarantee, and user complaint handling under AMR speech coding. VQM reduces the necessity of drive tests required for obtaining voice quality. VQM is controlled by the

ENODEBALGOSWITCH.VQMAlgoSwitch parameter and is disabled by default. VQM is not

recommended in scenarios where both AMR and non-AMR speech coding solutions are used. During VQM, the eNodeB monitors the packet error loss rate, delay, delay variation, and handover state. Then, the eNodeB inputs the DL and UL monitoring results to the E-model and voice quality indicator (VQI) model, respectively, to obtain the UL and DL voice quality data on the air interface.

The voice quality is saved in call history records (CHRs) and is used to collect the statistics of cell-level voice quality counters and monitor user-level performance.

NOTE

VQM results, including statistics of cell-level voice quality counters, user-level performance counters, and CHRs do not contain any user privacy information.

Table 3-4 lists the mapping between MOS and user experience.

Table 3-4 Mapping between MOS and user experience

User Experience Bad Poor Accept Good Excellent

MOS MOS ≤ 2.6 2.6 ≤ MOS ≤ 3.1 3.1 ≤ MOS ≤ 3.6 3.6 ≤ MOS ≤ 4 MOS > 4

E-Model

The E-model is used to evaluate DL voice quality.

The E-model was proposed by European Telecommunications Standards Institute (ETSI) and then defined by ITU-T Recommendation G.107. It is widely used in the evaluation of

conversational voice quality.

For the DL, the eNodeB monitors the average DL packet error loss rate and delay on the air interface, inputs the information to the E-model, employs more than 20 default parameters of the E-model, and obtains the voice quality evaluation results. Default parameters include send loudness rating (SLR) and response loudness rating (RLR).

VQI Model

The VQI model is used to evaluate UL voice quality.

As it is difficult for the E-UTRAN to obtain the average UL delay on the air interface, eNodeBs use Huawei VQI model to evaluate UL voice quality by monitoring the frame error rate (FER), long frame error rate (LFER), and handover state. Specifically, the eNodeB monitors the delay variation of each UL packet. If the variation exceeds the threshold (100 ms by default), the eNodeB considers the packet lost.

4

Key Technologies

4.1 Overview

Table 4-1 describes the Huawei eNodeB features involved in VoIP.

Table 4-1 Huawei eNodeB features involved in VoIP Protocol

Layer

Feature Description

RRC layer LBFD-002023 Admission Control

This feature provides admission control policies for VoIP.

For details, see 4.2.3 Admission Control. LBFD-002024

Congestion Control

This feature provides congestion control policies for VoIP.

For details, see 4.2.4 Congestion Control. l LBFD-00201805

Service Based Inter-frequency Handover l LOFD-001043

Service based inter-RAT handover to UTRAN

l LOFD-001046 Service based inter-RAT handover to GERAN

These features implement service-based inter-frequency and inter-RAT handovers.

For details, see 4.3 Service-based Inter-RAT or Inter-Frequency Handover.

PDCP layer LOFD-001017 RObust Header Compression (ROHC)

This feature compresses VoIP headers. For details, see 4.4 ROHC.

Protocol

Layer Feature Description

Media Access Control (MAC) layer

LOFD-00101502 Dynamic Scheduling

This feature provides semi-persistent scheduling mechanism for VoIP.

For details, see 4.5.2 Dynamic Scheduling. LOFD-001109 DL

Non-GBR Packet Bundling

This feature optimizes the DL dynamic scheduling priority when DL dynamic scheduling is used for VoIP.

For details, see DL Dynamic Scheduling. LOFD-001016

VoIP Semi-persistent Scheduling

This feature provides power control policies in uplink (UL) semi-persistent scheduling for VoIP.

For details, see 4.5.3 Semi-Persistent Scheduling.

LBFD-002026 Uplink Power Control

This feature provides power control policies in PUSCH semi-persistent scheduling for VoIP. For details, see UL Semi-Persistent

Scheduling in 4.6.3 Power Control in Semi-Persistent Scheduling.

The power control policies for VoIP in other channels are the same as those for data services.

LBFD-002016 Dynamic Downlink Power Allocation

This feature provides power control policies in PDSCH semi-persistent scheduling for VoIP. For details, see DL Semi-Persistent

Scheduling in 4.6.3 Power Control in Semi-Persistent Scheduling.

The power control policies for VoIP in other channels are the same as those for data services.

LBFD-002017 DRX

This feature provides DRX policies for VoIP. For details, see 4.7 DRX.

Physical layer LOFD-001048 TTI Bundling

This feature enhances UL coverage for VoIP through TTI Bundling.

For details, see 4.8 TTI Bundling.

4.2.1 Overview

This section describes how the basic features LBFD-002023 Admission Control and

LBFD-002024 Congestion Control work for VoIP. For more details about the two features, see

Admission and Congestion Control Feature Parameter Description.

The eNodeB performs admission and congestion control for conversational voice (QCI 1) and IMS signaling (QCI 5) separately.

4.2.2 Load Monitoring

Load monitoring provides decision references for admission and congestion control. The eNodeB monitors various resources in a cell to obtain the usage of physical resource blocks (PRBs), QoS satisfaction rates of GBR services, and resource insufficiency indicators. In this way, the eNodeB can know the current status of a cell.

Conversational Voice (QCI 1)

Load monitoring calculates user satisfaction with the QoS of conversational voice (QCI 1) in a cell as follows:

l Downlink QoS satisfaction rate = Sum of downlink QoS satisfaction rates of all VoIP services in the cell/Number of VoIP services in the cell

l Uplink QoS satisfaction rate = Sum of uplink QoS satisfaction rates of all VoIP services in the cell/Number of VoIP services in the cell

IMS Signaling (QCI 5)

N/A

4.2.3 Admission Control

Admission control determines whether to admit a GBR service (new service or handover service) based on the cell load reported by the load monitoring module. The cell load is represented by the PRB usage, QoS satisfaction rates of GBR services, and resource insufficiency indicators.

Conversational Voice (QCI 1)

The admission control of GBR services with a QCI of 1is performed based on load-based decisions. For details about admission control on conversational voice (QCI 1), see Admission

and Congestion Control Feature Parameter Description.

IMS Signaling (QCI 5)

Admission control for non-GBR services (QCI 5) is not based on load. If SRS and PUCCH resources are successfully allocated, admission control directly admits non-GBR services (QCI 5).

NOTE

Non-GBR services (QCI 5) are admitted based on SRS resource allocation only when the eNodeB is configured with the LBBPc board and SRS resources.

When PreemptionSwitch under the CellAlgoSwitch.RacAlgoSwitch parameter is turned on, IMS signaling cannot be preempted.

4.2.4 Congestion Control

When the network is congested, the eNodeB preferentially releases low-priority GBR services to free up resources for other services.

Conversational Voice (QCI 1)

The eNodeB monitors PRB usage and QoS satisfaction rate to evaluate load status. When the eNodeB determines that a cell is congested, the eNodeB rejects service access requests and triggers congestion control to decrease load.

The congestion threshold is specified the CellRacThd.Qci1CongThd parameter. For details about how to set this parameter, see Admission and Congestion Control Feature Parameter

Description.

IMS Signaling (QCI 5)

N/A

4.3 Service-based Inter-RAT or Inter-Frequency Handover

4.3.1 Overview

This section describes how the following features work for VoIP: l LBFD-00201805 Service Based Inter-frequency Handover l LOFD-001043 Service based inter-RAT handover to UTRAN l LOFD-001046 Service based inter-RAT handover to GERAN

This section describes how inter-RAT handovers and inter-frequency handovers work for VoIP.

4.3.2 Inter-Frequency Handover

To steer VoIP services to a specified frequency, turn on ServiceBasedInterFreqHoSwitch under the ENODEBALGOSWITCH.HoAlgoSwitch parameter.

For details about service-based inter-frequency handovers, see Mobility Management in

Connected Mode Feature Parameter Description.

4.3.3 Inter-RAT Handover

Service-based inter-RAT handovers can preferentially set up services with specified QCIs in another system when the source and target systems have the same coverage.

UtranServiceHoSwitch and GeranServiceHoSwitch under the

ENODEBALGOSWITCH.HoAlgoSwitch parameter specify whether to enable service-based

E-UTRAN to UTRAN and E-UTRAN to GERAN handovers, respectively. The

ServiceIrHoCfgGroup.InterRatHoState parameter determines the handover policies for

To perform VoIP services within the E-UTRAN, perform either of the following operations: l Turn off UtranServiceHoSwitch and GeranServiceHoSwitch under the

ENodeBAlgoSwitch.HoAlgoSwitch parameter.

l Turn on UtranServiceHoSwitch and GeranServiceHoSwitch under the

ENodeBAlgoSwitch.HoAlgoSwitch parameter, and set the

ServiceIrHoCfgGroup.InterRatHoState parameter for QCI 1 and QCI 5 to a value other

than MUST_HO.

If neither of the preceding operations is performed, VoIP services are handed over to another system immediately after being set up.

For details about service-based inter-RAT handovers, see Mobility Management in Connected

Mode Feature Parameter Description.

4.4 ROHC

This section describes how the optional feature LOFD-001017 RObust Header Compression (ROHC) works for VoIP. For more details about ROHC, see ROHC Feature Parameter

Description.

ROHC provides an efficient header compression mechanism for data packets transmitted on radio links to solve the problems of high bit error rates (BERs) and long round trip time (RTT). ROHC helps reduce header overhead, lower the packet loss rate, shorten the response time, and therefore helps improve network performance.

If operators have deployed IMS-based VoIP, operators can enable or disable ROHC by specifying the PDCPROHCPARA.RohcSwitch parameter.

ROHC is an extensible framework consisting of different profiles for data streams compliant with different protocols. Profiles define the compression modes for streams with different types of protocol headers. VoIP uses profiles 0x0001 and 0x0002 for compressing RTP, UDP, and IP headers.

The ROHC compression efficiency varies with the ROHC operating mode and variations in the dynamic part of a packet header at the application layer. A header can be compressed to a size as small as 1 byte, which efficiently reduces the VoIP packet size.

4.5 Scheduling

4.5.1 Overview

This section describes how a Huawei scheduler ensures the QoS and capacity of VoIP services using the following features:

l LOFD-00101502 Dynamic Scheduling

l LOFD-001016 VoIP Semi-persistent Scheduling

4.5.2 Dynamic Scheduling

This section describes how the optional feature LOFD-00101502 Dynamic Scheduling works for VoIP.

Overview

Dynamic scheduling for VoIP requires that the VoIP delay be as short as possible. Therefore, the Huawei scheduler optimizes the handling of VoIP priorities to ensure VoIP QoS. For details about dynamic scheduling, see Scheduling Feature Parameter Description.

Dynamic scheduling is used for VoIP in the following scenarios: l UEs move at high speeds, for example, on high-speed railways. l UEs are in cells with a bandwidth of 1.4 MHz.

l UEs perform other services together with VoIP. l UEs request emergency calls.

It is recommended that semi-persistent scheduling be enabled in scenarios where the increase in the number of VoIP users causes insufficient PDCCH resources.

UL Dynamic Scheduling

When UL dynamic scheduling uses the enhanced proportional fair (EPF) algorithm, the priority of conversational voice (QCI 1) is lower than the priorities of signaling radio bearer 1 (SRB1), SRB2, and IMS signaling (QCI 5), and it is higher than the priorities of other initially transmitted data.

DL Dynamic Scheduling

When dynamic scheduling is used, the scheduling priority is related to whether the feature LOFD-001109 DL Non-GBR Packet Bundling is enabled:

l If the feature LOFD-001109 DL Non-GBR Packet Bundling is not enabled:

When DL dynamic scheduling uses EPF, the priority of conversational voice (QCI 1) is lower than the priorities of common control information, user-specific control information, IMS signaling (QCI 5), data retransmitted in hybrid automatic repeat request (HARQ) mode, and RLC AM state reports, and it is higher than the priorities of other initially transmitted data.

l If the feature LOFD-001109 DL Non-GBR Packet Bundling is enabled:

All data and signaling are prioritized again and the priority of conversational voice may not be higher than the priorities of other initially transmitted data.

When dynamic scheduling is used, the modulation and coding scheme (MCS) selection policy is related to the value of VoipTbsBasedMcsSelSwitch under CellAlgoSwitch.DlSchSwitch: l When VoipTbsBasedMcsSelSwitch is turned on, the eNodeB determines whether the

number of online subscribers and IBLER have affected VoIP services. Selecting an MCS based on transport block size (TBS) takes effect if the number of online subscribers and IBLER meet certain requirements. HARQ retransmission and user delay are reduced if the function takes effect on VoIP services.

l When VoipTbsBasedMcsSelSwitch is turned off, the eNodeB determines the MCS for VoIP services based on the downlink CQI adjustment algorithm. For details about the downlink CQI adjustment algorithm, see Scheduling Feature Parameter Description.

4.5.3 Semi-Persistent Scheduling

Overview

The Huawei scheduler allocates time-frequency resources and transmission rates while activating semi-persistent scheduling, and it allows resource and rate reconfiguration through RRC messages. Semi-persistent scheduling is primarily used for services using periodically transmitted small packets. It can reduce the number of signaling messages. Currently, Huawei schedulers use semi-persistent scheduling only for conversational voice (QCI 1).

Before enabling semi-persistent scheduling, the eNodeB uses dynamic scheduling to schedule VoIP packets.

When enabling semi-persistent scheduling, the eNodeB notifies the UE of the semi-persistently allocated resources through the physical downlink control channel (PDCCH). During periodic scheduling, the eNodeB does not need to indicate the allocated resources through the PDCCH. The period of semi-persistent scheduling is 20 ms. The eNodeB notifies the UE of the period through an RRC message.

The PDCP layer determines talk spurts and silent periods for VoIP. During talk spurts, semi-persistent scheduling is activated. During silent periods, semi-semi-persistently allocated resources are released. Then, when a VoIP call transits from a silent period to talk spurts, the eNodeB reactivates semi-persistent scheduling.

eNodeBs use dynamic scheduling in the following scenarios to supplement semi-persistent scheduling:

l Transmission of large packets

l HARQ retransmission for the initial transmission that uses semi-persistent scheduling l Transmission of packets in silent periods

UL Semi-Persistent Scheduling

SpsSchSwitch under the CellAlgoSwitch.UlSchSwitch parameter specifies whether to enable

UL semi-persistent scheduling.

After determining that talk spurts start for a VoIP service, the eNodeB activates semi-persistent scheduling and determines the modulation and coding scheme (MCS) and the number of PRBs based on the packet size and the wideband signal to interference plus noise ratio (SINR). After semi-persistent scheduling is activated, the UE periodically sends data and the eNodeB periodically receives data using the semi-persistently allocated resources.

When the number of empty packets received by the eNodeB in semi-persistent scheduling exceeds the value of CellUlschAlgo.SpsRelThd, the eNodeB automatically releases semi-persistently allocated resources.

DL Semi-Persistent Scheduling

SpsSchSwitch under the CellAlgoSwitch.DlSchSwitch parameter specifies whether to enable

DL semi-persistent scheduling.

DL data transmitted in semi-persistent scheduling mode has a lower priority than common control (such as broadcast and paging) information but has a higher priority than UE-specific

control information and user-plane data. The eNodeB periodically sends data and the UE periodically receives data using the semi-persistently allocated resources.

When semi-persistent scheduling is activated, the eNodeB allocates the MCS and PRBs for a UE based on the size of VoIP packets and the UE-reported wideband channel quality indicator (CQI). The UE and eNodeB then receive and send data on the allocated resources.

After persistent scheduling is activated, the eNodeB determines whether to reactivate semi-persistent scheduling based on the measured IBLER.

4.6 Power Control

4.6.1 Overview

This section describes how the following features work for VoIP when dynamic scheduling and semi-persistent scheduling are used:

l LBFD-002026 Uplink Power Control

l LBFD-002016 Dynamic Downlink Power Allocation

4.6.2 Power Control in Dynamic Scheduling

For details about VoIP power control policies when dynamic scheduling is used for VoIP, see

Power Control Feature Parameter Description.

4.6.3 Power Control in Semi-Persistent Scheduling

This section describes VoIP power control policies when semi-persistent scheduling is used for VoIP.

UL Semi-Persistent Scheduling

When semi-persistent scheduling is used for VoIP in the UL, closed-loop power control for the physical uplink shared channel (PUSCH) can be enabled or disabled by setting

CloseLoopSpsSwitch under the CellAlgoSwitch.UlPcAlgoSwitch parameter.

l If CloseLoopSpsSwitch is turned on, the eNodeB adjusts transmit power for the PUSCH based on the measured IBLER.

l If CloseLoopSpsSwitch is turned off, the eNodeB does not adjust the transmit power for the PUSCH.

The PUSCH TPC commands for multiple UEs in semi-persistent scheduling mode are sent to the UEs in downlink control information (DCI) format 3 or 3A.

DL Semi-Persistent Scheduling

When semi-persistent scheduling is used for VoIP in the DL, power control for the PDSCH can be enabled or disabled by setting PdschSpsPcSwitch under the

l If PdschSpsPcSwitch is turned on, the eNodeB periodically adjusts the PDSCH transmit power for UEs that use the quadrature phase shift keying (QPSK) modulation scheme based on the measured IBLER.

l If PdschSpsPcSwitch is turned off, the eNodeB does not adjust the PDSCH transmit power.

4.7 DRX

This section describes how the basic feature LBFD-002017 DRX works for VoIP. With discontinuous reception (DRX) enabled, UEs enter a dormant state when data is not transmitted. In this way, DRX saves power. DRX typically applies to services with consecutive small packets that are transmitted periodically, for example, VoIP. VoIP does not support short DRX cycles when semi-persistent scheduling is enabled.

The Drx.DrxAlgSwitch parameter specifies whether to enable DRX.

For details about DRX, see DRX and Signaling Control Feature Parameter Description.

NOTE

False detection of the PDCCH might cause packet loss, which further deteriorates VoIP service quality. To reduce the impact of false detection, preallocation can be used. For details about how DRX works with preallocation, see DRX and Signaling Control Feature Parameter Description.

4.8 TTI Bundling

This section describes how the optional feature LOFD-001048 TTI Bundling works for VoIP. Transmission time interval (TTI) bundling enables a data block to be transmitted in consecutive TTIs, which are bound together and treated as the same resource. As shown in Figure 4-1, four TTIs are bound together. Assume that TTI N is the last TTI in a TTI group. Then, the eNodeB sends acknowledgment (ACK) or negative acknowledgment (NACK) at TTI N+4 in the downlink. Based on the received ACK or NACK, the UE determines whether a retransmission is required. If required, the UE retransmits the data in TTI N+13 through TTI N+16 in the uplink.

Figure 4-1 TTI bundling

When the UE's channel quality is poor and the transmit power is limited, enabling TTI bundling improves the cell edge coverage of the PUSCH, reduces fragments at the RLC layer, and lowers signaling overhead.

In the current version, cells with a bandwidth of 1.4 MHz do not support TTI bundling, and TTI bundling is used to improve only the UL edge coverage for VoIP.

TTI bundling is controlled by TtiBundlingSwitch under the CellAlgoSwitch.UlSchSwitch parameter. If TtiBundlingSwitch is turned on, the eNodeB determines whether to activate TTI bundling based on the channel quality and the amount of data to be transmitted. After activating TTI bundling, the eNodeB determines the number of PRBs and selects an MCS based on the channel quality and the amount of data to be transmitted.

According to section 8.6.1 "Modulation order and redundancy version determination" in 3GPP TS 36.213 V10.1.0 (2011-03), a maximum of three PRBs can be used in a bundle of TTIs, the modulation scheme is QPSK, and the highest modulation order is 10.

5

Related Features

5.1 Features Related to Admission and Congestion Control

5.1.1 LBFD-002023 Admission Control

For details about the prerequisite features, mutually exclusive features, and impacted features of LBFD-002023 Admission Control, see Admission and Congestion Control Feature

Parameter Description.

5.1.2 LBFD-002024 Congestion Control

For details about the prerequisite features, mutually exclusive features, and impacted features of LBFD-002024 Congestion Control, see Admission and Congestion Control Feature

Parameter Description.

5.2 Features Related to Service-based Handovers

5.2.1 LBFD-00201805 Service Based Inter-frequency Handover

For details about the prerequisite features, mutually exclusive features, and impacted features of LBFD-00201805 Service Based Inter-frequency Handover, see Mobility Management in

Connected Mode Feature Parameter Description.

5.2.2 LOFD-001043 Service based inter-RAT handover to UTRAN

For details about the prerequisite features, mutually exclusive features, and impacted features of LOFD-001043 Service based inter-RAT handover to UTRAN, see Mobility Management in

Connected Mode Feature Parameter Description.

5.2.3 LOFD-001046 Service based inter-RAT handover to GERAN

For details about the prerequisite features, mutually exclusive features, and impacted features of LOFD-001046 Service based inter-RAT handover to GERAN, see Mobility Management in

Connected Mode Feature Parameter Description.

5.3 Features Related to LOFD-001017 RObust Header

Compression (ROHC)

For details about the prerequisite features, mutually exclusive features, and impacted features of LOFD-001017 RObust Header Compression (ROHC), see ROHC Feature Parameter

Description.

5.4.1 LOFD-00101502 Dynamic Scheduling

For details about the prerequisite features, mutually exclusive features, and impacted features of LOFD-00101502 Dynamic Scheduling, see Scheduling Feature Parameter Description.

5.4.2 LOFD-001109 DL Non-GBR Packet Bundling

Prerequisite Features

None

Mutually Exclusive Features

None

Impacted Features

This feature affects the VoIP service quality.

When UEs are processing non-GBR services and VoIP services, enabling feature LOFD-001109 DL Non-GBR Packet Bundling has the following impact:

l The VoIP service quality may slightly decrease, while still being satisfactory.

l The DL non-GBR throughput increases if the non-GBR service scheduling probability was low before this feature is enabled because VoIP services take precedence and occupy more PDCCH resources.

The non-GBR DL throughput increases with the number of users with satisfactory VoIP quality. The throughput increase also depends on the non-GBR user distribution, traffic volume, system bandwidth, and other factors.

5.4.3 LOFD-001016 VoIP Semi-persistent Scheduling

Prerequisite Features

None

Mutually Exclusive Features

None

Impacted Features

l LOFD-001036 RAN Sharing with Common Carrier

VoIP services have a high scheduling priority and are sensitive to scheduling delays. Therefore, UL and DL semi-persistent scheduling does not consider the configured proportions of PRBs that can be allocated to different operators.

l LBFD-002026 Uplink Power Control

During UL semi-persistent scheduling, the MCS remains unchanged but channel conditions vary. Consequently, the IBLER may not converge on a target value. To solve this problem, closed-loop power control can be enabled to adjust UE transmit power for the PUSCH.

l LBFD-002005 DL Asynchronous HARQ

HARQ process information is not included in the PDCCH grant message for semi-persistent scheduling. Consequently, the retransmitted data and initially transmitted data fail to be combined because the eNodeB cannot identify the HARQ process for the retransmitted data. To solve this problem, the eNodeB reserves HARQ processes for semi-persistent scheduling and sends the number of reserved HARQ processes to the UE through an RRC message according to 3GPP TS 36.321.

l LAOFD-001001 Carrier Aggregation for Downlink 2CC in 20MHz

According to section 5.10 "Semi-Persistent Scheduling" in 3GPP TS 36.321, semi-persistent scheduling can only be configured on the primary component carrier for CA UEs.

5.5 Features Related to Power Control

5.5.1 LBFD-002016 Dynamic Downlink Power Allocation

Prerequisite Features

None

Mutually Exclusive Features

None

Impacted Features

LBFD-002016 Dynamic Downlink Power Allocation affects the following features: l LBFD-002025 Basic Scheduling

l LOFD-00101502 Dynamic Scheduling l LOFD-00101501 CQI Adjustment

l LOFD-001016 VoIP Semi-persistent Scheduling

l LBFD-00202201 Downlink Static Inter-Cell Interference Coordination l LOFD-00101401 Downlink Dynamic Inter-Cell Interference Coordination l LOFD-060201 Adaptive Inter-Cell Interference Coordination

This section describes only the impact on LOFD-001016 VoIP Semi-persistent Scheduling. For details about the impact on other features, see Power Control Feature Parameter Description. The downlink VoIP semi-persistent scheduling algorithm provides the achieved downlink BLER as an input to the downlink semi-persistent power control algorithm. The BLER is a prerequisite for enabling PDSCH power adjustment in semi-persistent scheduling.

5.5.2 LBFD-002026 Uplink Power Control

Prerequisite Features

Mutually Exclusive Features

None

Impacted Features

LBFD-002026 Uplink Power Control affects the following features: l LBFD-002025 Basic Scheduling

l LOFD-00101502 Dynamic Scheduling

l LOFD-001016 VoIP Semi-persistent Scheduling l LBFD-002010 Random Access Procedure

This section describes only the impact on LOFD-001016 VoIP Semi-persistent Scheduling. For details about the impact on other features, see Power Control Feature Parameter Description. The uplink VoIP semi-persistent scheduling algorithm provides the achieved uplink BLER as an input to the uplink power control algorithm. The BLER is a prerequisite for enabling PUSCH power adjustment in semi-persistent scheduling. If uplink semi-persistent scheduling is enabled, it is recommended that CloseLoopSpsSwitch under the CellAlgoSwitch.UlPcAlgoSwitch parameter be turned on to ensure the convergence of uplink IBLER.

5.6 Features Related to LBFD-002017 DRX

Prerequisite Features

None

Mutually Exclusive Features

None

Impacted Features

DRX affects LOFD-001048 TTI Bundling as follows:

l If a UE is in the TTI bundling state, the eNodeB instructs the UE to enter the DRX mode only when the UE needs to perform ANR measurement.

l If a UE is in DRX mode, the eNodeB instructs the UE to exit the DRX mode after activating TTI bundling. An exception is that if the UE is performing ANR measurement in DRX mode, the eNodeB does not instruct the UE to exit the DRX mode.

DRX also affects features such as scheduling, connection management, mobility management in connected mode, measurement, channel quality indicator (CQI), and timing control. For details about the impact, see DRX and Signaling Control Feature Parameter Description.

5.7 Features Related to LOFD-001048 TTI Bundling

Prerequisite Features

None

Mutually Exclusive Features

None

Impacted Features

LOFD-001048 TTI Bundling affects the following features: l LBFD-002017 DRX

l LOFD-001105 Dynamic DRX l LAOFD-001001 LTE-A Introduction

If a UE is in the TTI bundling state, the eNodeB instructs the UE to enter the DRX mode only when the UE needs to perform ANR measurement.

If a UE is in DRX mode and not performing ANR measurement, the eNodeB instructs the UE to exit the DRX mode when activating TTI bundling.

According to 3GPP TS 36.331, TTI bundling cannot be configured if a CA UE performs data transmission in the uplink. When a CA UE is configured with TTI bundling, the secondary cell (SCell) of this UE will be automatically deleted.

6

Network Impact

6.1 Admission and Congestion Control

6.1.1 LBFD-002023 Admission Control

System Capacity

Admission control maximizes the system capacity while providing users with satisfied QoS, which can be indicated by the VoIP MOS.

Network Performance

No impact.

6.1.2 LBFD-002024 Congestion Control

System Capacity

Congestion control maximizes system capacity while preferentially providing satisfied QoS for high-priority users. The priority refers to the allocation/retention priority (ARP). Congestion control ensures a high satisfaction rate of VoIP users in congested cells.

Network Performance

No impact.

6.2 Service-based Handover

6.2.1 LBFD-00201805 Service Based Inter-frequency Handover

System Capacity

No impact.

Network Performance

No impact.

6.2.2 LOFD-001043 Service based inter-RAT handover to UTRAN

System Capacity

No impact.

Network Performance

6.2.3 LOFD-001046 Service based inter-RAT handover to GERAN

System Capacity

No impact.

Network Performance

No impact.

6.3 LOFD-001017 RObust Header Compression (ROHC)

System Capacity

ROHC reduces the overhead of IP headers and increases the coverage and system capacity for VoIP users as follows:

l Decreases the size of VoIP packets to be transmitted, which in turn improves uplink edge coverage.

Higher compression efficiency leads to better cell coverage.

l Reduces required PRB resources and increases system capacity, given the same channel quality.

Higher compression efficiency leads to higher system capacity.

When ROHC is used, the variation in the sizes of compressed VoIP packets affects semi-persistent scheduling. If the sizes vary greatly, the allocated PRBs may be insufficient or excessive for semi-persistent scheduling. Either case affects VoIP capacity and cell throughput. l If the allocated PRBs are insufficient, dynamic scheduling is triggered temporarily. This

causes a waste of PDCCH resources and PRBs and increases scheduling delays due to VoIP packet segmentation.

l If the allocated PRBs are excessive, some PRBs are wasted, and the cell throughput in hybrid-service scenarios decreases.

Network Performance

No impact.

6.4 Scheduling

6.4.1 LOFD-00101502 Dynamic Scheduling

System Capacity

VoIP voice packets are generally small. If semi-persistent scheduling is disabled, VoIP capacity is mainly determined by PDCCH resources. If the continuous increase of VoIP users causes PDCCH resources to become insufficient firstly, the cell capacity decreases.

Network Performance

No impact.

6.4.2 LOFD-001109 DL Non-GBR Packet Bundling

System Capacity

l When cell load is light

In this scenario, the downlink control and traffic channels have sufficient resources and therefore the eNodeB does not trigger this feature, which means this feature does not affect system capacity.

l When cell load is heavy

In this scenario, the resources for control channels are insufficient and therefore the eNodeB triggers this feature. Enabling this feature improves the distribution of scheduling wait time for downlink packets and increases the GBR and non-GBR hybrid service capacity. Improving the distribution of scheduling wait time for downlink packets will increase VoIP service scheduling wait time while meeting the QoS requirements.

Network Performance

No impact.

6.4.3 LOFD-001016 VoIP Semi-persistent Scheduling

System Capacity

After semi-persistent scheduling is enabled, PDCCH resources do not hinder VoIP capacity because PDCCH resources are consumed only when semi-persistent scheduling is initially activated or reactivated or when semi-persistently allocated resources are released. Therefore, enabling semi-persistent scheduling can increase the number of supported VoIP users. During semi-persistent scheduling, the MCS index cannot exceed 15. This restriction may increase the number of PRBs allocated to semi-persistently scheduled UEs near the cell center. In hybrid-service scenarios (where VoIP UEs and other UEs coexist in a cell), the increase in the number of PRBs allocated to VoIP UEs will cause a decrease in the number of PRBs available to other UEs, and consequently the cell throughput will decrease.

Network Performance

No impact.

6.5 Power Control

6.5.1 LBFD-002016 Dynamic Downlink Power Allocation

For details about the impact of this feature on system capacity and network performance, see

6.5.2 LBFD-002026 Uplink Power Control

For details about the impact of this feature on system capacity and network performance, see

Power Control Feature Parameter Description.

6.6 LBFD-002017 DRX

System Capacity

DRX increases VoIP delays because it introduces the sleep time. If DRX parameter settings are inappropriate, VoIP capacity will decrease.

Network Performance

No impact.

6.7 LOFD-001048 TTI Bundling

System Capacity

No impact.

Network Performance

TTI bundling improves the cell edge coverage of the PUSCH. However, TTI bundling increases signaling exchanges in the cell because the RRC layer needs to trigger the activation and deactivation of TTI bundling.

7

Engineering Guidelines

7.1 When to Use VoIP

This section describes when to use VoIP.

7.1.1 Admission and Congestion Control

When a network becomes congested with an increasing number of users and higher QoS requirements, eNodeBs need to perform radio resource management so that QoS requirements of ongoing services can be fulfilled and differentiated services can be provided.

When radio resource congestion occurs (for example, QoS requirements cannot be fulfilled or radio bearers cannot be set up), activate admission control to relieve congestion and provide service-priority-based access services. When congestion increases so that QoS requirements still cannot be fulfilled, activate congestion control to enable low-priority service release.

7.1.2 ROHC

The ROHC feature is recommended when the operator provides the IMS-based VoIP services in LTE network.

7.1.3 Dynamic Scheduling

Scheduling Policies

Enhanced scheduling uses EPF as the scheduling policy. This policy takes scheduling fairness, cell capacity, and QoS satisfaction into consideration.

Enhanced scheduling is recommended if there is no capacity restriction due to control channel resource restriction.

Resource Allocation

Huawei eNodeBs support two DL resource allocation modes: frequency diversity scheduling and frequency selective scheduling. Huawei eNodeBs use frequency selective scheduling by default.

Frequency selective scheduling considers the differences in channel quality for UEs and brings gains. Frequency selective scheduling is not recommended in the following situations:

l UEs are moving at a high speed. l The UL load is high.

7.1.4 When to Use Semi-Persistent Scheduling

Semi-persistent scheduling is recommended if operators expect to reduce the PDCCH resources used for VoIP scheduling and to improve VoIP capacity.

Semi-persistent scheduling is not recommended if UEs move at high speeds (for example, on high-speed railways) or UEs are in cells with a bandwidth of 1.4 MHz.

If UL semi-persistent scheduling is enabled, it is recommended that UL power control for UL semi-persistent scheduling be enabled.

7.1.5 When to Use Power Control

For details on the use of dynamic power control, see Power Control Feature Parameter

Description.

It is recommended that power control for the PDSCH in semi-persistent scheduling mode be disabled.

It is recommended that power control for the PUSCH in semi-persistent scheduling mode (controlled by CloseLoopSpsSwitch) be enabled or disabled depending on the following circumstances:

l Enable power control if uplink semi-persistent scheduling is enabled. In this situation, TPC commands are adjusted based on the accuracy of the received initial-transmission data packets to decrease the IBLER, improving VoIP service performance.

l Disable power control if uplink semi-persistent scheduling is disabled.

NOTE

If any of the power control schemes described in this section is enabled, it is recommended that inner-loop power control for the PUSCH in dynamic scheduling mode also be enabled.

7.1.6 When to Use Dynamic DRX

It is recommended that dynamic DRX be activated in the following scenarios: l Scenario 1

Operators attach importance to UE power saving and expect to reduce the UE power consumption using dynamic DRX.

l Scenario 2

Signaling storms occur and operators expect to solve the signaling storm problem using dynamic DRX.

It is recommended that dynamic DRX not be activated when UEs moving at high speeds exist in the cell or UE power saving is not the main concern. When the

CellAlgoSwitch.HighMobiTrigIdleModeSwitch parameter is set to ENABLE(Enable), it is

recommended that dynamic DRX be activated to prevent negative signaling gains caused by too many handovers.

In scenario 1, UEs enter the out-of-synchronization state, and therefore the number of signaling messages increases. A larger difference between the values of

RrcConnStateTimer.UeInactivityTimerDynDrx and

RrcConnStateTimer.UlSynTimerDynDrx results in lower UE power consumption.

In scenario 2, it is recommended that dynamic DRX be disabled if the ratio of the number of handovers in the network to the number of E-RAB setup times is greater than 50%. Handover signaling is the main cause of the signaling storm and it is recommended that handovers be optimized first.

When dynamic DRX is enabled, to improve UE power saving effect, it is recommended that the

CellDrxPara.FddEnterDrxThd and CellDrxPara.FddExitDrxThd parameters be set to 1000

and that the CellDrxPara.DrxInactivityTimerUnsync parameter be set to PSF200(200

PDCCH subframes).

The configuration of the UE Inactivity Timer may have compatibility problems with UEs. Contact Huawei engineers before activating this feature.

7.1.7 When to Use TTI Bundling

To improve the cell edge coverage of the PUSCH, TTI bundling is recommended in the following scenarios:

l The UL coverage is poor and the UE's transmit power is limited.

l An eNodeB is installed outdoors but expected to provide indoor coverage.

7.2 Required Information

7.2.1 Admission and Congestion Control

For both admission control and congestion control, collect the QoS satisfaction rates and uplink PRB usage of cells.

7.2.2 ROHC

7.2.3 Dynamic Scheduling

7.2.4 Semi-Persistent Scheduling

7.2.5 Power Control

7.2.6 DRX

The RrcConnStateTimer.UeInactivityTimerDynDrx parameter specifies the length of the inactivity timer for UEs that support DRX, and the RrcConnStateTimer.UeInactiveTimer parameter specifies the length of the inactivity timer for UEs that do not support DRX. Before deploying dynamic DRX, collect information about the

RrcConnStateTimer.UeInactiveTimer and RrcConnStateTimer.UlSynTimer parameter

values. Assume that the values of the RrcConnStateTimer.UeInactiveTimer and

RrcConnStateTimer.UlSynTimer parameters are a and b, respectively.

Perform either of the following operations to ensure the accuracy of KPIs:

l If operators do not use dynamic DRX to reduce signaling, perform the following operations to avoid fluctuations in KPIs:

1. Set the RrcConnStateTimer.UeInactivityTimerDynDrx parameter to a. 2. Set the RrcConnStateTimer.UlSynTimerDynDrx parameter to b.

If power saving is required, set the RrcConnStateTimer.UlSynTimerDynDrx parameter to a value less than the value of the RrcConnStateTimer.UeInactivityTimerDynDrx

parameter. This configuration does not increase the number of UEs in RRC_CONNECTED mode.

l If operators use dynamic DRX to reduce signaling, perform the following operations to ensure the calculation accuracy of KPIs:

1. Set the RrcConnStateTimer.UlSynTimerDynDrx and

RrcConnStateTimer.UlSynTimer parameters to a.

2. Set the RrcConnStateTimer.UeInactivityTimerDynDrx and

RrcConnStateTimer.UeInactiveTimer parameters to a value greater than a, and

ensure that the values of RrcConnStateTimer.UeInactivityTimerDynDrx and

RrcConnStateTimer.UeInactiveTimer are the same.

After the preceding operations are complete, the values of the

RrcConnStateTimer.UeInactivityTimerDynDrx and

RrcConnStateTimer.UeInactiveTimer parameters are greater than a and the number of

UEs in RRC_CONNECTED mode increases.

For example, if the value of the RrcConnStateTimer.UeInactiveTimer parameter is 20, set the RrcConnStateTimer.UeInactivityTimerDynDrx and

RrcConnStateTimer.UeInactiveTimer parameters to 200; set the

RrcConnStateTimer.UlSynTimerDynDrx and RrcConnStateTimer.UlSynTimer

parameters to 20. Then, the value of the

RrcConnStateTimer.UeInactivityTimerDynDrx parameter is greater than that of the RrcConnStateTimer.UlSynTimerDynDrx parameter.

7.2.7 TTI Bundling

7.3 Planning

RF Planning

Networking Planning

An IMS server needs to be deployed to support VoIP.

If the E-UTRAN cannot provide continuous coverage and it requires the UTRAN/GERAN to provide continuous voice services, you must configure inter-RAT neighboring cells and set voice service handover switches must be set according to the UTRAN/GERAN voice service policies.

Hardware Planning

None

7.4.1 Requirements

Operating Environment

UEs must support VoIP, and the EPC must support IMS.

Transmission Networking

N/A

License

N/A

7.4.2 Data Preparation

This section describes the data that you need to collect for setting parameters. Required data is data that you must collect for all scenarios. Collect scenario-specific data when necessary for a specific feature deployment scenario.

There are three types of data sources:

l Network plan (negotiation required): parameter values planned by the operator and negotiated with the EPC or peer transmission equipment

l Network plan (negotiation not required): parameter values planned and set by the operator l User-defined: parameter values set by users

Required Data

None

Scenario-specific Data

Different QCIs require different RLC modes. The eNodeB supports adaptive configuration based on QCIs.

The following table describes the parameters that must be set in the StandardQci MO to modify a standardized QCI.

Parameter Name Parameter ID Data Source Setting Notes

QoS Class Indication StandardQci.Qci Network plan (negotiation not required) N/A RLC PDCP parameter group ID StandardQci. RlcPdcpParaGrou-pId Network plan (negotiation not required) N/A

The following table describes the parameter that must be set in the RlcPdcpParaGroup MO to configure an RLC mode.

Parameter Name Parameter ID Data Source Setting Notes UM or RLC-AM mode RlcPdcpParaGrou p.RlcMode Network plan (negotiation not required) N/A

7.4.3 Precautions

7.4.4 Hardware Adjustment

7.4.5 Initial Configuration

Using the CME to Perform Batch Configuration for Newly Deployed eNodeBs

Enter the values of the parameters listed in Table 7-1 in a summary data file, which also contains other data for the new eNodeBs to be deployed. Then, import the summary data file into the Configuration Management Express (CME) for batch configuration. For detailed instructions, see section "Creating eNodeBs in Batches" in the initial configuration guide for the eNodeB. The summary data file may be a scenario-specific file provided by the CME or a customized file, depending on the following conditions:

l The MOs in Table 7-1 are contained in a scenario-specific summary data file. In this situation, set the parameters in the MOs, and then verify and save the file.

l Some MOs in Table 7-1 are not contained in a scenario-specific summary data file. In this situation, customize a summary data file to include the MOs before you can set the parameters.

Table 7-1 Parameters related to RLC modes

MO Sheet in the Summary Data

File Parameter Group Remarks

StandardQci StandardQci QOS Class Indication, RlcPdcpParaGroupId; User-defined sheet RlcPdcpParaGrou p RLC and PDCP Parameter Group Configuration RlcPdcpParaGroupId, UM or RLC-AM mode User-defined sheet

Using the CME to Perform Batch Configuration for Existing eNodeBs

Batch reconfiguration using the CME is the recommended method to activate a feature on existing eNodeBs. This method reconfigures all data, except neighbor relationships, for multiple eNodeBs in a single procedure. The procedure is as follows:

Step 1 Choose CME > Advanced > Customize Summary Data File, or choose Advanced > Customize

Summary Data File, to customize a summary data file for batch reconfiguration.

NOTE

For context-sensitive help on a current task in the client, press F1.

Step 2 Choose CME > LTE Application > Export Data > Export Base Station Bulk Configuration

Data, or choose LTE Application > Export Data > Export Base Station Bulk Configuration Data, to export the eNodeB data stored on the CME into the customized summary data file.

Step 3 In the summary data file, set the parameters in the MOs listed in Table 7-1 and close the file.

Step 4 Choose CME > LTE Application > Import Data > Import Base Station Bulk Configuration

Data, or choose LTE Application > Import Data > Import Base Station Bulk Configuration Data, to import the summary data file into the CME.

Step 5 Choose CME > Planned Area > Export Incremental Scripts, or choose Area Management >

Planned Area > Export Incremental Scripts, to export and activate the incremental scripts.

----End

Using the CME to Perform Single Configuration

On the CME, set the parameters listed in the 7.4.2 Data Preparation section for a single eNodeB. The procedure is as follows:

Step 1 In the planned data area, click Base Station in the upper left corner of the configuration window. Step 2 In area 1 shown in Figure 7-1, select the eNodeB to which the MOs belong.

Figure 7-1 MO search and configuration window

Step 3 On the Search tab page in area 2, enter an MO name, for example, CELL.

Step 4 In area 3, double-click the MO in the Object Name column. All parameters in this MO are

displayed in area 4.

Step 5 Set the parameters in area 4 or 5.

Step 6 Choose CME > Planned Area > Export Incremental Scripts, or choose Area Management > Planned Area > Export Incremental Scripts, to export and activate the incremental scripts. ----End

Using MML Commands

Step 1 Run the MOD RLCPDCPPARAGROUP command to set the RLC/PDCP parameter group. Step 2 Run the MOD STANDARDQCI command to set parameters related to standardized QCIs.

----End

MML Command Examples

MOD RLCPDCPPARAGROUP: RlcPdcpParaGroupId=0, RlcMode=RlcMode_UM, PdcpSnSize=PdcpSnsize_12bits;

MOD STANDARDQCI: Qci=QCI1, InterRatPolicyCfgGroupId=0;

7.4.6 Activation Observation