eRAN
VoIP
Feature Parameter Description
Copyright © Huawei Technologies Co., Ltd. 2013. All rights reserved.
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.
Contents
1 Introduction
1.1 Scope 1.2 Intended Audience 1.3 Change History2 Overview of VoIP
2.1SRVCC Architecture Based on IMS 2.2
Procedure for VoIP Call Establishment and Conversation 2.3
Common Speech Coding/Decoding Standards 2.4
VoIP QoS Configurations 2.5
VoIP Performance Evaluation Criteria 2.5.1 Delay and Packet Error Loss Rate 2.5.2 VoIP Capacity
2.5.3 Voice Quality
3 Handling of VoIP in eNodeB Features
3.1 ROHC 3.2 VoIP Scheduling 3.2.1 Dynamic Scheduling 3.2.2 Semi-Persistent Scheduling 3.3 TTI Bundling 3.4 Power Control3.4.1 UL Power Control in Dynamic Scheduling Mode 3.4.2 DL Power Control in Dynamic Scheduling Mode
3.4.3 Closed-Loop Power Control for the PUSCH in Semi-Persistent Scheduling 3.4.4 Power Control for the PDSCH in Semi-Persistent Scheduling
3.5
RLC Transmission Mode Configuration 3.6
Admission and Congestion Control 3.6.1 Admission Control 3.6.2 Congestion Control 3.7 DRX
4 Related Features
4.1 Required Features 4.2Mutually Exclusive Features 4.3
Affected Features
5 Impact on the Networks
5.1
Impact on System Capacity 5.2
6 Engineering Guidelines
6.1When to Use VoIP 6.1.1 ROHC
6.1.2 VoIP Scheduling 6.1.3 TTI Bundling 6.1.4 Power Control
6.1.5 RLC Transmission Mode Configuration 6.1.6 Admission and Congestion Control 6.1.7 DRX 6.2 Information to Be Collected 6.2.1 ROHC 6.2.2 VoIP Scheduling 6.2.3 TTI Bundling 6.2.4 Power Control
6.2.5 RLC Transmission Mode Configuration 6.2.6 Admission and Congestion Control 6.2.7 DRX 6.3 Network Planning 6.4 Deploying ROHC 6.4.1 Deployment Requirements 6.4.2 Data Preparation 6.4.3 Initial Configuration 6.4.4 Activation Observation 6.4.5 Reconfiguration 6.4.6 Performance Optimization 6.4.7 Troubleshooting 6.5
Deploying Dynamic Scheduling 6.5.1 Deployment Requirements 6.5.2 Data Preparation 6.5.3 Initial Configuration 6.5.4 Activation Observation 6.5.5 Reconfiguration 6.5.6 Performance Optimization 6.5.7 Troubleshooting 6.6
Deploying Semi-Persistent Scheduling 6.6.1 Deployment Requirements 6.6.2 Data Preparation
6.6.3 Initial Configuration 6.6.4 Activation Observation 6.6.5 Reconfiguration
6.6.6 Performance Optimization 6.6.7 Troubleshooting
6.7
Deploying TTI Bundling
6.7.1 Deployment Requirements 6.7.2 Data Preparation 6.7.3 Initial Configuration 6.7.4 Activation Observation 6.7.5 Reconfiguration 6.7.6 Performance Optimization 6.7.7 Troubleshooting 6.8
Deploying Power Control in Dynamic Scheduling Mode 6.9
Deploying Power Control in Semi-Persistent Scheduling Mode 6.9.1 Deployment Requirements 6.9.2 Data Preparation 6.9.3 Initial Configuration 6.9.4 Activation Observation 6.9.5 Reconfiguration 6.9.6 Performance Optimization 6.9.7 Troubleshooting
6.10 Deploying RLC Transmission Mode Configuration 6.10.1 Deployment Requirements 6.10.2 Data Preparation 6.10.3 Initial Configuration 6.10.4 Activation Observation 6.10.5 Reconfiguration 6.10.6 Performance Optimization 6.10.7 Troubleshooting
6.11 Deploying Admission and Congestion Control 6.12 Deploying DRX
7 Parameters
8 Counters
9 Glossary
1 Introduction
1.1 Scope
This document describes voice over IP (VoIP) in terms of basic principles, feature implementation, feature dependencies, network impact, and engineering guidelines.
Any managed objects (MOs), parameters, alarms, or counters described in this document correspond to the software release delivered with this document. In the event of updates, the updates will be described in the product documentation delivered with the latest software release.
1.2 Intended Audience
This document is intended for:Personnel who need to understand VoIP
Personnel who work with Huawei Long Term Evolution (LTE) 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:
Feature change: refers to a change in the VoIP feature of a specific product version.
Editorial change: refers to a change in wording or the addition of information that was not described in
the earlier version.
Document Issues
The document issue is as follows:
03 (2012-12-29) 02 (2012-09-20) 01 (2012-05-11)
03 (2012-12-29)
Compared with issue 02 (2012-09-20) of eRAN3.0, 03 (2012-12-29) of eRAN3.0 includes the following changes:
Change Type Change Description Parameter
Change
Feature change None None
Editorial change Revised the description of TTI bundling. For details, see
section 3.3 "TTI Bundling." None Revised the description of DRX. For details see
Change Type Change Description Parameter Change
Revised the description of RB allocation during semi-persistent scheduling. For details, see chapter 3 "Handling of VoIP in eNodeB Features."
None
Modified the deployment suggestion for TTI bundling. For details,
see 6.1.3 "TTI Bundling." None Modified the information to be collected before feature
deployment. For details, see section 6.2 "Information to Be Collected."
None
Revised the description of activation observation for UL and DL semi-persistent scheduling. For details, see
section 6.6.4 "Activation Observation."
None
02 (2012-09-20)
Compared with issue 01 (2012-05-11) of eRAN3.0, issue 02 (2012-09-20) includes the following changes.
Change Type Change Description Parameter
Change
Feature change None None
Editorial change Modified the table that provides standardized QCI characteristics.
For details, see section 2.5.1 "Delay and Packet Error Loss Rate." None Improved the figure that shows the LTE/SAE architecture. For
details, see chapter 2 "Overview of VoIP."
Revised the descriptions of the following contents: SRVCC architecture based on IMS. For details, see
section2.1 "SRVCC Architecture Based on IMS." DRX. For details, see section 3.7 "DRX."
Activation observation for dynamic scheduling. For details, see section 6.5.4 "Activation Observation."
Activation observation for semi-persistent scheduling. For details, see section 6.6.4 "Activation Observation."
Activation observation for power control in semi-persistent scheduling mode. For details, see section 6.9.4 "Activation Observation."
01 (2012-05-11)
2 Overview of VoIP
LTE adopts all-IP architecture with the evolution of the wireless network. However, voice services remain a basic service type in wireless communications. Accordingly, two questions arise before the LTE network can be deployed:
How can the network provide voice services with quality of service (QoS) requirements fulfilled? How can the network provide voice services that are continuous during movement between
UTRAN/GERAN and E-UTRAN
−UTRAN: universal terrestrial radio access network −GERAN: GSM/EDGE radio access network
−E-UTRAN: evolved universal terrestrial radio access network
LTE/SAE is the prospect of the wireless network evolution. SAE stands for System Architecture
Evolution. Figure 2-1 shows the LTE/SAE architecture for VoIP. For details of the network architecture, see 3GPP TS 23.401.
Figure 2-1 LTE/SAE architecture
HSS: home subscriber server MME: mobility management entity PCRF: policy and charging rule function PDN: packet data network SGSN: serving GPRS support node UE: user equipment
Operator's IP services, which are specified as IP multimedia subsystem (IMS) in LTE, are responsible for session control based on IP. They use the Session Initiation Protocol (SIP) and Session Description Protocol (SDP) for session control and media negotiation, and therefore support multimedia services based on IP.
VoIP mentioned in this document refers to VoIP based on IMS in the LTE network.
When the UE exits the coverage of the E-UTRAN, single radio voice call continuity (SRVCC) is used to ensure continuity of voice services. The E-UTRAN, consisting of eNodeBs, ensures fulfillment of QoS requirements of VoIP services by providing the following functions:
Establishment, management and release of control-plane and user-plane bearers Management of some radio resources
This document covers the following aspects of VoIP:
System architecture and performance evaluation criteria −SRVCC architecture based on the IMS
−Procedure for VoIP call establishment and conversation −Common speech coding/decoding standards
−QoS configurations
−Performance evaluation criteria
Handling in the following features of Huawei eNodeB: −LOFD-001017 RObust Header Compression (ROHC) −LBFD-002025 Basic Scheduling
−LOFD-001016 VoIP Semi-persistent Scheduling −LOFD-001048 TTI Bundling
−LBFD-002026 Power Control −LBFD-002023 Admission Control −LBFD-002024 Congestion Control
−LBFD-002017 Discontinuous Reception (DRX)
2.1 SRVCC Architecture Based on IMS
SRVCC is an inter-RAT handover policy (RAT stands for radio access technology). It smoothly transfers UEs running VoIP services from E-UTRAN to UTRAN or GERAN. After the transfer, the VoIP services become legacy voice services and service continuity is therefore ensured.
For details about inter-RAT handovers, see Mobility Management in Connected Mode Feature Parameter Description.
Figure 2-2 shows the architecture for SRVCC from E-UTRAN to UTRAN. The architecture for SRVCC from E-UTRAN to GERAN is similar. For details, see 3GPP TS 23.216.
Figure 2-2 Architecture for SRVCC from E-UTRAN to UTRAN
If a UE with an ongoing VoIP call moves from the E-UTRAN to the coverage area of the UTRAN or GERAN, the MME sends a handover request to the mobile switching center (MSC) server. If the MSC server accepts this request, the UE is then transferred using SRVCC to the UTRAN or GERAN, and the VoIP call is not interrupted. The MSC server is primarily responsible for call processing in the circuit switched (CS) domain.
2.2 Procedure for VoIP Call Establishment and Conversation
If a UE attempts to originate a VoIP call, both the calling UE and the called UE establish radio resource control (RRC) connections and E-UTRAN radio access bearers (E-RABs).Figure 2-3 Procedure for VoIP call establishment and conversation
The procedure is as follows:
1. The calling UE establishes an RRC connection.
2. The calling UE establishes an E-RAB for IMS signaling.
3. The called UE is instructed to establish an RRC connection and also an E-RAB for IMS signaling. 4. The calling UE and the called UE exchange information through IMS signaling.
5. The calling UE and the called UE establish an E-RAB for VoIP voice data packets. 6. The called UE sends a ringback tone to the calling UE through the IMS signaling. 7. The called UE answers the call and the VoIP conversation begins.
8. The scheduler in each eNodeB chooses dynamic scheduling or semi-persistent scheduling based on the scheduling policy to schedule the VoIP service.
2.3 Common Speech Coding/Decoding Standards
Common speech coding/decoding standards include the adaptive multirate (AMR) standard stipulated by the 3rd Generation Partnership Project (3GPP) and the G.7XX standards stipulated by the International Telecommunication Union-Telecommunication Standardization Sector (ITU-T).
AMR is an audio data compression scheme optimized for speech coding. It was adopted as a standard speech coding technology by 3GPP in October 1998 and is now widely used in Global System for Mobile Communications (GSM) and Universal Mobile Telecommunications System (UMTS). AMR is classified into adaptive multirate wideband (AMR-WB) and adaptive multirate narrowband (AMR-NB), and the speech coding rate can be adjusted to 17 different values. AMR can change the speech coding rate based on the radio channel conditions and cell loads to improve the voice quality and increase the VoIP capacity. Figure 2-4 shows the VoIP traffic model under AMR
Figure 2-4 VoIP traffic model under AMR
Transient state is an unstable period in the early phase after a service is set up. In this state, the packet
size is relatively large.
Talk spurts are a state in which the user is in conversation. In this state, data is transmitted at intervals of
20 ms, and the packet size is determined by the speech coding rate.
Silent period refers to a period where a user pauses during a call. In this period, a short silence insertion
descriptor (SID) is transmitted every 160 ms. An SID is a noise frame that is sent to improve user experience.
The widely used G.7XX standards include G.711, G.729, and G.726.
G.711, also known as pulse code modulation (PCM), is primarily used in telephony. It supports a coding
rate of 64 kbit/s.
G.729, known for the high voice quality and low delay, is widely used in various domains of data
communications. It supports a coding rate of 8 kbit/s.
G.726 is a speech coding/decoding algorithm working on a bit rate of 16 kbit/s to 40 kbit/s. The most
commonly used rate is 32 kbit/s. In actual application, the interval of voice packets is usually 20 ms.
2.4 VoIP QoS Configurations
This section describes the Huawei QoS configuration policy for VoIP services.
Voice and IMS signaling (SIP/SDP) in a VoIP service use two different E-RABs: one with a QCI of 1 for voice and the other with a QCI of 5 for IMS signaling. Real-Time Transport Control Protocol (RTCP) data is usually multiplexed with RTP-processed VoIP voice data onto one E-RAB and shares one radio bearer with the data. (RTP is short for Real-Time Transport Protocol.) Figure 2-5 shows the VoIP service flow and protocol stack.
Figure 2-5 VoIP service flow and protocol stack
AM: acknowledged mode PDCP: Packet Data Convergence Protocol RLC: Radio Link Control UDP: User Datagram Protocol
UM: unacknowledged mode
2.5 VoIP Performance Evaluation Criteria
This section describes the protocol-recommended performance evaluation criteria for VoIP services. The performance evaluation criteria for VoIP services include the delay, packet error loss rate, VoIP capacity, and voice quality.
2.5.1 Delay and Packet Error Loss Rate
Table 2-1 describes standardized QCI characteristics stipulated in 3GPP TS 23.203.
Table 2-1 Standardized QCI characteristics
QCI Resource Type Priority Packet Delay Budget Packet Error Loss Rate Example Services
QCI Resource Type Priority Packet Delay Budget Packet Error Loss Rate Example Services
2 4 150 ms 10-3 Conversational video (live
streaming)
3 3 50 ms 10-3 Real-time gaming
4 5 300 ms 10-6 Non-conversational video
(buffered streaming)
5 Non-GBR 1 100 ms 10-6 IMS signaling
6 6 300 ms 10-6 Video (buffered streaming),
TCP-based (for example, www, e-mail, chat, FTP, P2P file sharing, and progressive video)
7 7 100 ms 10-3 Voice, video (live streaming),
interactive gaming
8 8 300 ms 10-6 Video (buffered streaming),
TCP-based (for example, www, e-mail, chat, FTP, P2P file sharing, and progressive video)
9 9
GBR: guaranteed bit rate
The packet delay budget (PDB) is 100 ms for both VoIP voice with a QCI of 1 and IMS signaling with a QCI of 5. That is, the delay from the UE to the PDN gateway (P-GW) is 100 ms with a confidence level of 98%.
The packet error loss rate (PELR) defines the maximum rate of service data units (SDUs) that have been processed by the sender of the link-layer Automatic Repeat Request (ARQ) protocol but that are not successfully delivered by the corresponding receiver to the upper layer. The PELR requirement for VoIP voice with a QCI of 1 is 10-2, and that for IMS signaling with a QCI of 5 is 10-6.
2.5.2 VoIP Capacity
As defined in 3GPP TS 36.814, the VoIP capacity of a cell is the number of VoIP users in the cell when 95% of the total number of users are satisfied. A user is regarded as satisfied if the delay of its voice packets is less than or equal to 50 ms for 98% or more of the VoIP talk spurts.
2.5.3 Voice Quality
Voice quality is the key factor of service quality in networks providing voice services. The service quality of VoIP services is affected by delay, jitters, and packet loss. The mean opinion score (MOS), a common subjective evaluation standard, is primarily used for evaluating voice quality. The MOS for voice services is categorized as five levels by ITU-T G.107 with corresponding speech transmission quality category and user stratification, as detailed in Table 2-2.
Table 2-2 Voice quality levels
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
3 Handling of VoIP in eNodeB Features
This chapter describes the impacts of the following features on VoIP services or the special handling of VoIP, and relevant parameters:
LOFD-001017 ROHC
LBFD-002025 Basic Scheduling
LOFD-001016 VoIP Semi-persistent Scheduling LOFD-001048 TTI Bundling
LBFD-002026 Power Control LBFD-002023 Admission Control LBFD-002024 Congestion Control LBFD-002017 DRX
3.1 ROHC
Robust header compression (ROHC) is a packet header compression scheme designed for radio links, on which bit error rates (BERs) are high and the round trip time (RTT) is long. ROHC improves the network performance by downsizing the packet headers, reducing packet loss, and shortening the response time. This section focuses on the impacts of ROHC on VoIP. For more details about ROHC, see ROHC Feature Parameter Description.
The PdcpRohcPara.RohcSwitch parameter controls whether the eNodeB supports ROHC. The eNodeB
supports ROHC when this parameter is set to ON(On), and does not when this parameter is set to OFF(Off).
ROHC is a 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. Each profile is identified by a profile ID. Profile 0x0001 is used for VoIP. Table 3-1 describes the mapping between profile IDs and protocols.
Table 3-1 Mapping between profile IDs and protocols
Profile ID Protocol
0x0001 RTP, UDP, and IP
0x0002 UDP and IP
0x0003 Encapsulating Security Payload (ESP) and IP
0x0004 IP
ROHC can significantly compress packet headers, to 1 byte for the best. This can effectively downsize the VoIP packets and therefore reduce the number of resource blocks (RBs) required for VoIP.
After ROHC is enabled, sizes of compressed packets vary because the ROHC operating mode and the dynamic part of packet headers at the application layer change according to different rules. The number of RBs allocated by semi-persistent scheduling depends on the sizes of packets that have been compressed.
3.2 VoIP Scheduling
This section describes how Huawei schedulers process VoIP services to meet QoS requirements and increase the VoIP capacity.
SpsSchSwitch(SpsSchSwitch) under the CellAlgoSwitch.UlSchSwitch parameter controls whether the
eNodeB supports uplink (UL) semi-persistent scheduling. The eNodeB supports UL semi-persistent scheduling when SpsSchSwitch(SpsSchSwitch) is turned on, and does not
whenSpsSchSwitch(SpsSchSwitch) is turned off.
SpsSchSwitch(SpsSchSwitch) under the CellAlgoSwitch.DlSchSwitch parameter controls whether the
eNodeB supports downlink (DL) semi-persistent scheduling. The eNodeB supports DL semi-persistent scheduling when SpsSchSwitch(SpsSchSwitch) is turned on, and does not
whenSpsSchSwitch(SpsSchSwitch) is turned off.
3.2.1 Dynamic Scheduling
When dynamic scheduling is used for VoIP, Huawei schedulers perform special treatment for the priorities of VoIP services so that the QoS requirements (short delay) can be met for the VoIP services.
UL Dynamic Scheduling
To improve system performance and satisfy QoS requirements, UL scheduling can also use the enhanced proportional fair (EPF) algorithm. Huawei schedulers use this algorithm by default.
VoIP services have relatively high priorities in scheduling. VoIP voice packets with a QCI of 1 have lower priorities than signaling radio bearer (SRB) 1, SRB 2, and IMS signaling with QCIs of 5, but higher priorities than other initially transmitted packets.
DL Dynamic Scheduling
The EPF algorithm helps meet QoS requirements in an end-to-end manner by using service scheduling priorities and service rate guarantee. Huawei schedulers use this algorithm by default.
When the EPF algorithm is used, VoIP voice packets with a QCI of 1 have lower priorities than common control information, UE-specific control information, IMS signaling with a QCI of 5, hybrid automatic repeat request (HARQ) retransmission, and RLC AM state reports, but higher priorities than other initially
transmitted packets.
3.2.2 Semi-Persistent Scheduling
Semi-persistent scheduling is primarily used for services using periodically transmitted small packets. It can reduce the number of signaling messages at layer 1 and layer 2. Currently, Huawei schedulers use semi-persistent scheduling only for VoIP voice with a QCI of 1.
Dynamic scheduling is used for VoIP in the following scenarios:
Ultra-high-speed mobility 1.4 MHz cell bandwidth Hybrid services
Emergency calls
Semi-persistent scheduling is not supported in the preceding scenarios.
The PDCP layer determines the talk spurts and silent periods for VoIP. Semi-persistent scheduling is activated during talk spurts, and semi-persistently allocated resources are released when silent periods
arrive. Semi-persistent scheduling is reactivated when a VoIP service transits from a silent period to talk spurts.
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. In the UL, the UE periodically transmits data over semi-persistently allocated resources. In the DL, the eNodeB periodically transmits data and the UE periodically receives data over semi-persistently allocated resources. The period of semi-persistent scheduling is set by the eNodeB for the UE through an RRC message. The period is 20 ms in the current version.
UL Semi-Persistent Scheduling
Before semi-persistent scheduling is activated, dynamic scheduling is used for VoIP.
After semi-persistent scheduling is activated, dynamic scheduling is used in the following scenarios to supplement semi-persistent scheduling:
Transmission of large packets
HARQ retransmission corresponding to the initial transmission
When a silent period arrives, semi-persistently allocated resources are released and dynamic scheduling is used for data packets.
After determining that a VoIP service is in talk spurts, the eNodeB activates semi-persistent scheduling and determines the modulation and coding scheme (MCS) and the number of RBs based on the packet size and the wideband signal to interference plus noise ratio (SINR).
DL Semi-Persistent Scheduling
The scenarios for DL semi-persistent scheduling are the same as those for UL 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 a higher priority than UE-specific control information and user-plane data.
When semi-persistent scheduling is activated, the eNodeB allocates the MCS and RBs for a UE based on the size of VoIP packets and the UE-reported wideband channel quality indicator (CQI). The MCS remains unchanged during talk spurts, but the initial block error rate (IBLER) still increases for some UEs due to variations in channel conditions. To maintain the IBLER for semi-persistently scheduled UEs to be within a certain range, the eNodeB determines whether to reactivate semi-persistent scheduling based on the IBLER value.
3.3 TTI Bundling
TtiBundlingSwitch under the CellAlgoSwitch.UlSchSwitch parameter controls whether to enable TTI
bundling. The eNodeB supports TTI bundling when TtiBundlingSwitch is turned on, and does not when TtiBundlingSwitch is turned off.
TTI bundling shortens the RTT and enhances UL coverage by transmitting the same transport block (TB) in consecutive TTIs and making full use of the combining gain provided by HARQ. For details about TTI bundling, see Scheduling Feature Parameter Description.
TTI bundling applies only to VoIP services. For VoIP services with small packets but a high demand on delay, TTI bundling reduces the number of VoIP fragments, downsizes headers, and increases the success rate of initial transmissions. TTI bundling also shortens the delay and decreases the error rate. These improve the VoIP coverage at cell edges.
3.4 Power Control
3.4.1 UL Power Control in Dynamic Scheduling Mode
When dynamic scheduling is used for VoIP, no special processing is performed on UL power control.For details about power control, see Power Control Feature Parameter Description.
3.4.2 DL Power Control in Dynamic Scheduling Mode
When dynamic scheduling is used for VoIP, no special processing is performed on DL power control.For details about power control, see Power Control Feature Parameter Description.
3.4.3 Closed-Loop Power Control for the PUSCH in Semi-Persistent
Scheduling
When semi-persistent scheduling is performed in the UL for VoIP, the transmit power for the physical uplink shared channel (PUSCH) is adjusted based on the difference between the measured initial block error rate (IBLER) and IBLERTarget if the CloseLoopSpsSwitch check box under
theCellAlgoSwitch.UlPcAlgoSwitch parameter is selected. If the measured IBLER is greater than IBLERTarget, the eNodeB sends a transmit power control (TPC) command to the UE, ordering an increase in the transmit power. If the measured IBLER is less than IBLERTarget, the eNodeB sends a TPC command to the UE, ordering a decrease in the transmit power.
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 DCI format 3A. In this way, signaling overheads on the PDCCH are reduced, increasing the VoIP capacity.
3.4.4 Power Control for the PDSCH in Semi-Persistent Scheduling
When semi-persistent scheduling is performed in the DL for VoIP, the transmit power for the physical downlink shared channel (PDSCH) is adjusted for VoIP UEs using the quadrature phase shift keying (QPSK) modulation scheme based on the difference between the measured IBLER and IBLERTarget if the PdschSpsPcSwitch check box under the CellAlgoSwitch.DlPcAlgoSwitch parameter is selected. If the measured IBLER is less than IBLERTarget, the eNodeB decreases the PDSCH transmit power.Otherwise, the eNodeB increases the PDSCH transmit power.
3.5 RLC Transmission Mode Configuration
Set the UM for VoIP voice on bearers with QCIs of 1. Set the AM for IMS signaling on bearers with QCIs of 5. Table 3-2 lists the QCI information and the corresponding RLC transmission modes (denoted by
RLC-SAP in the table).
Table 3-2 RLC transmission mode settings for different QCIs
QCI Service Type Packet Delay Budget Packet Loss Error Rate RLC-SAP
1 Conversational voice 100 ms 10-2 UM
3.6 Admission and Congestion Control
3.6.1 Admission Control
Admission control for VoIP voice, which is carried on bearers with QCIs of 1, considers the satisfaction rate of services with QCIs of 1. The satisfaction rate is equal to the number of satisfied VoIP services in a cell divided by the total number of VoIP services in the cell. Whether a service is satisfied depends on the proportion of its number of packets with delay requirements fulfilled to its total number of packets. The admission control also considers the resource usage. For details about admission control, see Admission
and Congestion Control Feature Parameter Description.
Admission control for IMS signaling, which is carried on bearers with QCIs of 5, always admits IMS signaling services. The admission control does not consider the setting of
theCellRacThd.MaxNonGBRBearerNum parameter.
3.6.2 Congestion Control
No special processing is performed on congestion control for VoIP voice and IMS signaling services. For details about congestion control, see Admission and Congestion Control Feature Parameter Description.
3.7 DRX
This section describes the discontinuous reception (DRX) configuration policies for VoIP services. If the DRX switch Drx.DrxAlgSwitch is set to ON(On) for an eNodeB, the eNodeB allows all the served UEs to use DRX. If the parameter is set to OFF(Off), the eNodeB prohibits the use of DRX by any served UEs.
Typically, DRX applies to UEs running services with periodically and consecutively transmitted small packets, for example, VoIP services. With DRX, UEs enter the sleep time when data is not transmitted. As a result, DRX saves power. It is important to note that short DRX cycles do not apply to VoIP services. For details about how to configure DRX for VoIP services, see DRX Feature Parameter Description.
4 Related Features
This chapter describes the dependencies between VoIP-related features and other features and the impact of VoIP-related features.
4.1 Required Features
None4.2 Mutually Exclusive Features
VoIP services in the E-UTRAN are exclusive to LBFD-00201805 Service Based Inter-frequency Handover. Either of the following conditions must be met before VoIP services can be provided in the E-UTRAN:
UtranServiceHoSwitch(UtranServiceHoSwitch) andGeranServiceHoSwitch(GeranServiceHoSwitc
h) under theENodeBAlgoSwitch.HoAlgoSwitch parameter are turned off.
The ServiceIrHoCfgGroup.InterRatHoState parameter in the ServiceIrHoCfgGroup managed objects
(MOs) for QCIs 1 and 5 is not set to MUST_HO.
If neither of the conditions is met, an inter-RAT handover will be triggered immediately after a UE initiates a VoIP service.
LOFD-001048 TTI Bundling is exclusive to the following features:
LBFD-002017 DRX
LOFD-001105 Dynamic DRX
LOFD-001097 Carrier Aggregation Introduction Package
4.3 Affected Features
After ROHC is enabled, sizes of compressed packets fluctuate because the radio channel quality varies and the ROHC operating mode and the dynamic part of packet headers at the application layer change according to different rules. This affects semi-persistent scheduling because dynamic scheduling may be triggered in the semi-persistent scheduling period. For details about the impact, see section 5.1 "Impact on System Capacity."
The MCS remains unchanged during semi-persistent scheduling but the channel conditions vary, and consequently the IBLER may not converge. Closed-loop power control on the PUSCH in semi-persistent scheduling mode can be used to enable the IBLER to converge.
5 Impact on the Networks
This chapter describes the impact of the VoIP-related features on the network.
5.1 Impact on System Capacity
VoIP packets are generally small, and VoIP capacity is primarily determined by PDCCH resources before semi-persistent scheduling is enabled. 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-persistent scheduling resources are released. Therefore, enabling semi-persistent scheduling can increase VoIP capacity.
When semi-persistent scheduling is used, the MCS to use cannot exceed 15. This restriction may increase the number of required RBs for semi-persistently scheduled UEs near the cell center. In hybrid-service scenarios including VoIP UEs, the increase in the number of RBs required by VoIP UEs will cause a decrease in the number of RBs available to other UEs, and consequently the cell throughput will decrease. When ROHC is used, the variation in the sizes of compressed VoIP packets affects semi-persistent scheduling. If the sizes vary to a large extent, the allocated RBs may be insufficient or redundant for semi-persistent scheduling. Either case affects VoIP capacity and cell throughput as follows:
If the allocated RBs are insufficient, dynamic scheduling is triggered temporarily. This causes a waste of
PDCCH resources and RBs for transmission, and also an increase in scheduling delays due to fragmented VoIP packets.
If the allocated RBs are redundant, some RBs are wasted, and the cell throughput in hybrid-service
scenarios decreases.
Power control in semi-persistent scheduling mode enables the IBLER to converge and accordingly the MOS to increase for VoIP UEs.
When DRX is used, delays of VoIP services increase due to the introduction of the sleep time. Inappropriate DRX parameter settings affect the VoIP capacity.
Admission control and congestion control policies will affect the MOS of VoIP UEs and the VoIP capacity.
5.2 Impact on Network Performance
When ROHC is used, UL coverage on cell edges improves because IP headers are effectively compressed to downsize VoIP packets.
When TTI bundling is used, UL coverage on cell edge also improves because VoIP fragments are reduced and HARQ gains are increased.
6 Engineering Guidelines
This chapter describes engineering guidelines for VoIP.
6.1 When to Use VoIP
This section describes when to use VoIP.
6.1.1 ROHC
For details about the application scenarios of ROHC, see ROHC Feature Parameter Description.
6.1.2 VoIP Scheduling
Dynamic Scheduling
Dynamic scheduling is recommended when there are only a few of VoIP services and users in the following scenarios:
UEs move at high speeds, for example, on high-speed railways. UEs are in cells with a bandwidth of 1.4 MHz.
UEs perform other services in addition to VoIP. UEs request emergency calls.
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.
6.1.3 TTI Bundling
TTI bundling is recommended when poor UL coverage leads to one of the following problems:
The PDCCH overhead of VoIP services is high. The UL voice quality is poor.
The call drop rate is high.
6.1.4 Power Control
UL Power Control in Dynamic Scheduling Mode
When dynamic scheduling is used for VoIP, no special processing is performed on UL power control. For details about the application scenarios of UL power control in dynamic scheduling mode, seePower Control Feature Parameter Description.
DL Power Control in Dynamic Scheduling Mode
When dynamic scheduling is used for VoIP, no special processing is performed on DL power control. For details about the application scenarios of DL power control in dynamic scheduling mode, seePower Control Feature Parameter Description.
UL Power Control in Semi-Persistent Scheduling Mode
For details about the application scenarios of UL power control in semi-persistent scheduling mode,
see Power Control Feature Parameter Description.
DL Power Control in Semi-Persistent Scheduling Mode
For details about the application scenarios of DL power control in semi-persistent scheduling mode,
see Power Control Feature Parameter Description.
6.1.5 RLC Transmission Mode Configuration
eNodeBs configure RLC transmission modes based on the QCIs of services.
6.1.6 Admission and Congestion Control
Admission Control
For details about the application scenarios of admission control, see Admission and Congestion Control Feature Parameter Description.
Congestion Control
For details about the application scenarios of congestion control, see Admission and Congestion Control Feature Parameter Description.
6.1.7 DRX
DRX is recommended if VoIP users expect to reduce battery power consumption.
6.2 Information to Be Collected
6.2.1 ROHC
For information to be collected for ROHC, see ROHC Feature Parameter Description.
6.2.2 VoIP Scheduling
The information to be collected for VoIP scheduling includes the phone number allocation policy of the operator, traffic models of users on the live network, and resource usages of control channels and traffic channels.
6.2.3 TTI Bundling
The information to be collected for TTI bundling includes the coverage of the live network. TTI bundling is recommended when UL coverage is poor.
For detailed information to be collected for TTI bundling, see Scheduling Feature Parameter Description.
6.2.4 Power Control
6.2.5 RLC Transmission Mode Configuration
None6.2.6 Admission and Congestion Control
For information to be collected for admission and congestion control, see Admission and Congestion Control Feature Parameter Description.
6.2.7 DRX
The information to be collected for DRX includes the operator's requirements, UE types, and traffic models of users on the live network.
For detailed information to be collected for DRX, see DRX Feature Parameter Description.
6.3 Network Planning
None
6.4 Deploying ROHC
6.4.1 Deployment Requirements
Requirements for the Operating Environment
UEs must support ROHC and VoIP, and the evolved packet core (EPC) must support IMS.
Requirements for Transmission Networking
N/A
Requirements for Licenses
Operators must purchase and activate the following license.
Feature License Control Item Name
LOFD-001017 RObust Header Compression (ROHC) RObust Header Compression (ROHC)
6.4.2 Data Preparation
For details about data preparation for ROHC, see ROHC Feature Parameter Description.
6.4.3 Initial Configuration
For details about initial configuration for ROHC, see ROHC Feature Parameter Description.
6.4.4 Activation Observation
UL VoIP
To verify ROHC for UL VoIP, perform the following steps:
Step 1 Run the MOD PDCPROHCPARA command to enable ROHC.
Step 2 Enable a UE to access a cell, trigger the setup of a bearer with a QCI of 1, and perform UL VoIP with a codec of G.729.
Step 3 Check on the M2000 whether ROHC has been activated.
ROCH has been activated if one of the values of L.PDCP.DL.RoHC.HdrCompRatio and L.PDCP.DL.RoHC.PktCompRatio is less than 1.
Step 4 Start a traffic measurement task.
The UL RLC throughput in bit/s after ROCH is activated should be less than that before ROHC is activated, as shown in Figure 6-1.
Figure 6-1 UL VoIP traffic measurement
----End
DL VoIP
To verify ROHC for DL VoIP, perform the following steps:
Step 1 Run the MOD PDCPROHCPARA command to enable ROHC.
Step 2 Enable a UE to access a cell, trigger the setup of a bearer with a QCI of 1, and perform DL VoIP with a codec of G.729.
Step 3 Check on the M2000 whether ROHC has been activated, using the same adjustment method as that for UL VoIP.
The DL RLC throughput in bit/s after ROCH is activated should be obviously less than that before ROHC is activated, as shown in Figure 6-2.
Figure 6-2 DL VoIP traffic measurement
----End
6.4.5 Reconfiguration
N/A6.4.6 Performance Optimization
N/A6.4.7 Troubleshooting
N/A6.5 Deploying Dynamic Scheduling
6.5.1 Deployment Requirements
Requirements for the Operating Environment
UEs must support VoIP, and the EPC must support IMS.
Requirements for Transmission Networking
N/A
Requirements for Licenses
6.5.2 Data Preparation
For details about data preparation for dynamic scheduling, see Scheduling Feature Parameter Description.
6.5.3 Initial Configuration
For details about the initial configuration of dynamic scheduling for VoIP, see the description of the initial configuration of enhanced scheduling in Scheduling Feature Parameter Description.
6.5.4 Activation Observation
UL Dynamic Scheduling
UL dynamic scheduling is enabled by default. To verify UL dynamic scheduling for VoIP, perform the following steps:
Step 1 Run the LST CELLALGOSWITCH command to check whether UL dynamic scheduling has been activated.
If SpsSchSwitch under Uplink schedule switch is Off, UL dynamic scheduling has been activated.
Step 2 Enable a UE to access a cell from a position close to the eNodeB, trigger the setup of a bearer with a QCI of 1, and perform UL VoIP with a codec of G.729.
Step 3 Start a task on the M2000 to monitor MCS-specific scheduling statistics.
1. On the M2000, choose Monitor > Signaling Trace > Signaling Trace Management.
2. In the left pane of the displayed window, choose User Performance Monitoring > MCS Count
Monitoring. Set the tracing duration, to-be-traced MME ID, and UE TMSI, as shown in the following
3. Check the MCS-specific scheduling statistics. If the UL MCS indexes are greater than 15 and less than or equal to 24 or 28 (24 for a category 3 UE, and 28 for a category 5 UE), dynamic scheduling is performed for UL VoIP. Note that the highest MCS index in semi-persistent scheduling is only 15.Figure 6-3 shows an example — the UE is scheduled with MCS 22 in most cases.
Figure 6-3 UL MCS-specific scheduling statistics
----End
DL Dynamic Scheduling
DL dynamic scheduling is enabled by default. To verify DL dynamic scheduling for VoIP, perform the following steps:
Step 1 Run the LST CELLALGOSWITCH command to check whether DL dynamic scheduling has been activated.
If SpsSchSwitch under DL schedule switch is Off, DL dynamic scheduling has been activated.
Step 2 Enable a UE to access a cell, trigger the setup of a bearer with a QCI of 1, and perform DL VoIP with a codec of G.729.
Step 3 Start a task on the M2000 to monitor MCS-specific scheduling statistics.
1. On the M2000, choose Monitor > Signaling Trace > Signaling Trace Management.
2. In the left pane of the displayed window, choose User Performance Monitoring > MCS Count
Monitoring. Set the tracing duration, to-be-traced MME ID, and UE TMSI, as shown in the following
3. Check the MCS-specific scheduling statistics. If the DL MCS indexes for the UE are greater than 15 and less than or equal to 28, dynamic scheduling has been performed for DL VoIP. Note that the highest MCS index in semi-persistent scheduling is only 15.
Figure 6-4 DL MCS monitoring results
----End
6.5.5 Reconfiguration
N/A6.5.6 Performance Optimization
N/A6.5.7 Troubleshooting
N/A6.6 Deploying Semi-Persistent Scheduling
6.6.1 Deployment Requirements
Requirements for the Operating Environment
UEs must support semi-persistent scheduling and VoIP, and the EPC must support IMS.
Requirements for Transmission Networking
N/A
Requirements for Licenses
Operators must purchase and activate the following license.
Feature License Control Item Name
LOFD-001016 VoIP Semi-persistent Scheduling VoIP Semi-persistent Scheduling
6.6.2 Data Preparation
This section describes generic data and scenario-specific data to be collected. Generic data is necessary for all scenarios and must always be collected. Scenario-specific data is collected only when necessary for a specific scenario.
There are three types of data sources:
Network plan (negotiation required): Parameters are planned by operators and negotiated with the EPC
or peer transmission equipment.
Network plan (negotiation not required): Parameters are planned and set by operators. User-defined: Parameters are set as required by users.
Generic Data
The following table describes the parameter that must be set in the Cell MO to set semi-persistent scheduling.
Parameter
Name Parameter ID Source Setting Description
Local cell ID CellDrxPara.LocalCellId Network plan (negotiation not required)
Set this parameter based on the network plan. This parameter specifies the local ID of the cell. Ensure that this parameter has been set in the related Cell MO.
Scenario-specific Data
The following table describes the parameter that must be set in the CellAlgoSwitch MO to set UL semi-persistent scheduling.
Parameter
Name Parameter ID Source Setting Description
Uplink schedule switch
CellAlgoSwitch.UlSchSwitch Network plan (negotiation not required)
TheSpsSchSwitch(SpsSchSwitch)check box under this parameter specifies whether to enable semi-persistent scheduling for UL VoIP.
In scenarios described in section6.1.2 "VoIP Scheduling", you are advised to select this check box. In other scenarios, you are advised to clear this check box.
The following table describes the parameter that must be set in the CellAlgoSwitch MO to set DL semi-persistent scheduling.
Parameter
Name Parameter ID Source Setting Description
DL schedule switch
CellAlgoSwitch.DlSchSwitch Network plan (negotiation not required)
TheSpsSchSwitch(SpsSchSwitch)check box under this parameter specifies whether to enable semi-persistent scheduling for DL VoIP.
In scenarios described in section6.1.2 "VoIP Scheduling", you are advised to select this check box. In other scenarios, you are advised to clear this check box.
6.6.3 Initial Configuration
Configuring a Single eNodeB Using the GUI
Configure a single eNodeB using the Configuration Management Express (CME) graphical user interface (GUI) based on the collected data described in section 6.6.2 "Data Preparation." For details, see the procedure for configuring a single eNodeB using the CME GUI described in eNodeB Initial Configuration Guide.
Configuring eNodeBs in Batches
To configure eNodeBs in batches, perform the following steps:
Step 1 On the GUI, set the parameters listed in Table 6-1 and save the parameter settings as a user-defined template.
The parameters are the same as those described in section 6.6.2 "Data Preparation."
The parameter settings in the user-defined template will be applied to the eNodeBs after you import the summary data file into the CME.
----End
Table 6-1 Parameters related to semi-persistent scheduling
MO Parameter Group Name Parameter
CELLALGOSWITCH CellAlgoSwitch LocalCellID, Uplink schedule switch, DL schedule switch
Configuring a Single eNodeB Using MML Commands
To enable UL semi-persistent scheduling, run the MOD CELLALGOSWITCH command. To enable DL semi-persistent scheduling, run the MOD CELLALGOSWITCH command.
6.6.4 Activation Observation
UL Semi-Persistent Scheduling
To verify UL semi-persistent scheduling for VoIP, perform the following steps when there is only one UE in a cell:
Step 1 Run the MOD CELLALGOSWITCH command to enable UL semi-persistent scheduling.
Step 2 After the UE accesses the cell, trigger the setup of a bearer with a QCI of 1, and perform UL VoIP with a codec of G.729. Ensure that the UE is in the talk spurts state.
Step 3 Start a task on the M2000 to monitor MCS-specific scheduling statistics.
1. On the M2000, choose Monitor > Signaling Trace > Signaling Trace Management.
2. In the left pane of the displayed window, choose User Performance Monitoring > MCS Count
3. Check the MCS-specific scheduling statistics. If the UL MCS indexes are less than or equal to 15 and the number of UL scheduling times is about 50, UL semi-persistent scheduling is activated for the UE. If the UE has satisfactory uplink channel quality, the number of UL scheduling times is about 50. If the UE is far from the eNodeB, the number may be greater than 50 due to packet segmentation because semi-persistent scheduling may not be activated for the UE.
Figure 6-5 UL MCS-specific scheduling statistics
4. In the left pane of the Signaling Trace Management window, choose Cell Performance
Monitoring > DCI Statistic Monitoring. Set the tracing duration and to-be-traced NE.
5. View the tracing result. If the number of PDCCH DCI format 0 scheduling times decreases greatly, UL semi-persistent scheduling is activated for the UE.
If the UE is close to the eNodeB, the decrease is obvious. If the UE is far from the eNodeB, the decrease may not be obvious because semi-persistent scheduling may not be activated for the UE.
Figure 6-6 PDCCH DCI format 0 scheduling
The number of PDCCH control channel elements (CCEs) used in UL semi-persistent scheduling greatly decreases, compared with dynamic scheduling. If the UE is far from the eNodeB and semi-persistent scheduling is not activated for the UE, the decrease is not obvious or there is no decrease.
----End
DL Semi-Persistent Scheduling
To verify DL semi-persistent scheduling for VoIP, perform the following steps when there is only one UE in a cell:
Step 1 Run the MOD CELLALGOSWITCH command to enable DL semi-persistent scheduling.
Step 2 After the UE accesses the cell, trigger the setup of a bearer with a QCI of 1, and perform DL VoIP with a codec of G.729.
Step 3 Start a task on the M2000 to monitor MCS-specific scheduling statistics.
1. On the M2000, choose Monitor > Signaling Trace > Signaling Trace Management.
2. In the left pane of the displayed window, choose User Performance Monitoring > MCS Count
Monitoring. Set the tracing duration, to-be-traced MME ID, and UE TMSI, as shown in the following
3. Check the MCS-specific scheduling statistics.
If the DL MCS indexes are less than or equal to 15 and the number of DL scheduling times is about 50 for a UE with satisfactory downlink channel quality, DL semi-persistent scheduling has been performed for the UE.
Figure 6-7 DL MCS-specific scheduling statistics
4. In the left pane of the Signaling Trace Management window, choose Cell Performance
5. View the tracing result. If the number of PDCCH DCI format 2A scheduling times decreases greatly, DL semi-persistent scheduling is activated for the UE.
Figure 6-8 PDCCH DCI format 2A scheduling
The number of PDCCH CCEs used in DL semi-persistent scheduling greatly decreases, compared with dynamic scheduling. ----End
6.6.5 Reconfiguration
N/A6.6.6 Performance Optimization
N/A6.6.7 Troubleshooting
N/A6.7 Deploying TTI Bundling
6.7.1 Deployment Requirements
Requirements for the Operating Environment
UEs must support TTI bundling and VoIP, and the EPC must support IMS.
Requirements for Transmission Networking
Requirements for Licenses
Operators must purchase and activate the following license.
Feature License Control Item Name
LOFD-001048 TTI Bundling TTI Bundling
6.7.2 Data Preparation
For details about data preparation for TTI bundling, see Scheduling Feature Parameter Description.
6.7.3 Initial Configuration
Configuring a Single eNodeB Using the GUI
Configure a single eNodeB using the Configuration Management Express (CME) graphical user interface (GUI) based on the collected data described in section 6.7.2 "Data Preparation." For details, see the procedure for configuring a single eNodeB using the CME GUI described in eNodeB Initial Configuration Guide.
Configuring eNodeBs in Batches
To configure eNodeBs in batches, perform the following steps:
Step 1 On the GUI, set the parameters listed in Table 6-2 and save the parameter settings as a user-defined template.
The parameters are the same as those described in section 6.7.2 "Data Preparation."
Step 2 Fill in the summary data file with the name of the user-defined template.
The parameter settings in the user-defined template will be applied to the eNodeBs after you import the summary data file into the CME.
----End
Table 6-2 Parameters related to TTI bundling
MO Parameter Group Name Parameter
CELLALGOSWITCH CellAlgoSwitch LocalCellID, Uplink schedule switch
Configuring a Single eNodeB Using MML Commands
Run the MOD CELLALGOSWITCH command to enable TTI bundling.
6.7.4 Activation Observation
To verify TTI bundling for UEs far from the eNodeB, perform the following steps:
Step 2 Start a Uu tracing task on the M2000. Select test cells when creating the task.
Step 3 Enable a UE to access a cell, trigger the setup of a bearer with a QCI of 1, and perform UL VoIP with a codec of G.729.
Step 4 Enable the UE to be away from the eNodeB until the RRC_CONN_RECFG and
RRC_CONN_RECFG_CMP messages are present in the Uu tracing result. Check the IEs mac-MainConfig > ul-SCH-Config > ttiBundling in the RRC_CONN_RECFG message. The value TRUE (as shown in Figure 6-7) indicates that TTI bundling has been activated for UL VOIP.
Figure 6-9 RRC_CONN_RECFG message (indicating that TTI bundling has been activated)
Step 5 Enable the UE to be close to the eNodeB. Check the IEs mac-MainConfig > ul-SCH-Config > ttiBundling in the RRC_CONN_RECFG message. The value FALSE (as shown in Figure 6-8) indicates that TTI bundling has been deactivated for UL VoIP.
Figure 6-10 RRC_CONN_RECFG message (indicating that TTI bundling has been deactivated) ----End
6.7.5 Reconfiguration
N/A6.7.6 Performance Optimization
N/A6.7.7 Troubleshooting
N/A6.8 Deploying Power Control in Dynamic Scheduling Mode
For VoIP, no special processing is performed on UL and DL power control in dynamic scheduling mode. For details, see Power Control Feature Parameter Description.
6.9 Deploying Power Control in Semi-Persistent Scheduling
Mode
6.9.1 Deployment Requirements
Requirements for the Operating Environment
UEs must support semi-persistent scheduling, VoIP, and closed-loop power control. The EPC must support IMS.
Requirements for Transmission Networking
N/A
Requirements for Licenses
Operators must purchase and activate the following license.
Feature License Control Item Name
LOFD-001016 VoIP Semi-persistent Scheduling VoIP Semi-persistent Scheduling
6.9.2 Data Preparation
Generic Data
Parameter
Name Parameter ID Source Setting Description
Local cell ID Cell.LocalCellId Network plan (negotiation not required)
Set this parameter based on the network plan. This parameter specifies the local ID of the cell. Ensure that this parameter has been set in the related Cell MO.
Scenario-specific Data
The following table describes the parameter that must be set in the CellAlgoSwitch MO to set UL power control in semi-persistent scheduling mode.
Parameter
Name Parameter ID Source Setting Description
Uplink power control algorithm switch
CellAlgoSwitch.UlPcAlgoSwitch Network plan (negotiation not required)
The CloseLoopSpsSwitchcheck box under this parameter specifies whether to enable UL power control in PUSCH semi-persistent scheduling mode for UL VoIP. For setting suggestions, see
The following table describes the parameter that must be set in the CellAlgoSwitch MO to set DL power control in semi-persistent scheduling mode.
Parameter
Name Parameter ID Source Setting Description
Downlink power control algorithm switch
CellAlgoSwitch.DlPcAlgoSwitch Network plan (negotiation not required)
The PdschSpsPcSwitchcheck box under this parameter specifies whether to enable DL power control in PDSCH semi-persistent scheduling mode for DL VoIP. For setting suggestions, see
section 6.1.4 "Power Control."
6.9.3 Initial Configuration
Configuring a Single eNodeB Using the GUI
Configure a single eNodeB using the Configuration Management Express (CME) graphical user interface (GUI) based on the collected data described in section 6.9.2 "Data Preparation." For details, see the procedure for configuring a single eNodeB using the CME GUI described in eNodeB Initial Configuration Guide.
Configuring eNodeBs in Batches
To configure eNodeBs in batches, perform the following steps:
Step 1 On the GUI, set the parameters listed in Table 6-3 and save the parameter settings as a user-defined template.
The parameters are the same as those described in section 6.9.2 "Data Preparation."
Step 2 Fill in the summary data file with the name of the user-defined template.
The parameter settings in the user-defined template will be applied to the eNodeBs after you import the summary data file into the CME.
----End
Table 6-3 Parameters related to power control in semi-persistent scheduling mode
MO Parameter Group Name Parameter
CELLALGOSWITCH CellAlgoSwitch LocalCellID, Uplink schedule switch, Uplink power control algorithm switch, DL schedule switch, Downlink power control algorithm switch
Configuring a Single eNodeB Using MML Commands
To enable closed-loop power control in PUSCH semi-persistent scheduling mode, run the MOD
To enable power control in PDSCH semi-persistent scheduling mode, run the MOD
CELLALGOSWITCH command.
6.9.4 Activation Observation
UL Power Control in Semi-Persistent Scheduling Mode
To check whether UL power control in PUSCH semi-persistent scheduling mode can be activated and whether the IBLER values can converge at the target value, perform the following steps:
Step 1 Run the MOD CELLALGOSWITCH command to enable UL semi-persistent scheduling and closed-loop power control in PUSCH semi-persistent scheduling mode.
Step 2 Enable a UE to access a cell, trigger the setup of a bearer with a QCI of 1, and perform UL VoIP with a codec of G.729.
Step 3 Start a task on the M2000 to monitor IBLER values.
1. On the M2000, choose Monitor > Signaling Trace > Signaling Trace Management.
2. In the left pane of the displayed window, choose User Performance Monitoring > BLER Monitoring. Set the tracing duration and MME ID, as shown in the following figures.
3. Check on the M2000 whether the IBLER values converge at the target value. If the values ofUplink
IBLER(Permillage) fluctuate around 100, the IBLER values converge at 10%.
Figure 6-11 UL IBLER monitoring results
DL Power Control in Semi-Persistent Scheduling Mode
To check whether DL power control in semi-persistent scheduling mode can be activated for UEs far from the eNodeB and whether the IBLER values can converge at the target value, perform the following steps:
Step 1 Run the MOD CELLALGOSWITCH command to enable DL semi-persistent scheduling and DL power control in semi-persistent scheduling mode.
Step 2 After a UE accesses a cell, trigger the setup of a bearer with a QCI of 1, and perform DL VoIP with a codec of G.729. Enable the UE to be far from the eNodeB, and enable the MCS index to be less than 9.
Step 3 Start a task on the M2000 to monitor IBLER values.
1. On the M2000, choose Monitor > Signaling Trace > Signaling Trace Management.
2. In the left pane of the displayed window, choose User Performance Monitoring > BLER Monitoring. Set the tracing duration and MME ID, as shown in the following figures.
3. Check on the M2000 whether the IBLER values converge at the target value. If the values ofDownlink
IBLER(Permillage) fluctuate around 100, the IBLER values converge at 10%.
Figure 6-12 DL IBLER monitoring results
----End
6.9.5 Reconfiguration
N/A6.9.6 Performance Optimization
N/A6.9.7 Troubleshooting
N/A6.10 Deploying RLC Transmission Mode Configuration
6.10.1 Deployment Requirements
Requirements for the Operating Environment
UEs must support VoIP, and the EPC must support IMS.
Requirements for Transmission Networking
N/A
Requirements for Licenses
N/A
6.10.2 Data Preparation
Generic Data
None
Scenario-specific Data
Different QCIs require different RLC transmission modes. eNodeBs support 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 Source Setting Description
QoS Class Indication StandardQci.Qci Network plan (negotiation not required)
N/A
RLC PDCP parameter
group ID StandardQci.RlcPdcpParaGroupId 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 transmission mode.
Parameter Name Parameter ID Source Setting Description
RLC-UM or RLC-AM
mode RlcPdcpParaGroup.RlcMode Network plan (negotiation not required)
6.10.3 Initial Configuration
Configuring a Single eNodeB Using the GUI
Configure a single eNodeB using the Configuration Management Express (CME) graphical user interface (GUI) based on the collected data described in section 6.10.2 "Data Preparation." For details, see the procedure for configuring a single eNodeB using the CME GUI described in eNodeB Initial Configuration Guide.
Configuring eNodeBs in Batches
To configure eNodeBs in batches, perform the following steps:
Step 1 On the GUI, set the parameters listed in Table 6-4 and save the parameter settings as a user-defined template.
The parameters are the same as those described in section 6.10.2 "Data Preparation."
Step 2 Fill in the summary data file with the name of the user-defined template.
The parameter settings in the user-defined template will be applied to the eNodeBs after you import the summary data file into the CME.
----End
Table 6-4 Parameters related to RLC transmission mode configuration
MO Parameter Group Name Parameter
StandardQci StandardQci Qci, RlcPdcpParaGroupId; RlcPdcpParaGroup RlcPdcpParaGroup RlcPdcpParaGroupId, RlcMode
Configuring a Single eNodeB Using MML Commands
Configure RLC transmission modes using the default parameter values.
6.10.4 Activation Observation
eNodeBs can configure RLC transmission modes based on QCIs. The following describe the procedure for checking whether the RLC transmission mode for VoIP services (QCI 1) is UM and that for IMS signaling (QCI 5) is AM:
Step 1 Enable a UE to access a cell, and trigger the setup of the bearers with QCIs of 1 and 5. Check the QCIs in the dedicated bearer request messages using a drive test tool or by starting an S1 tracing task on the M2000, and ensure the QCIs are correct.
Step 2 Check the Uu tracing results. If the RLC transmission mode for QCI 1 is UM and that for QCI 5 is AM, the configurations are correct.
----End
6.10.5 Reconfiguration
N/A6.10.6 Performance Optimization
N/A6.10.7 Troubleshooting
N/A6.11 Deploying Admission and Congestion Control
For details about how to deploy admission and congestion control, see Admission and Congestion Control Feature Parameter Description.
