HL1 Parameter Analysis Guideline - VoLTE & SRVCC v1.1

Nokia Multivendor Optimization
Development Project
Parameter Analysis Guideline- VoLTE & SRVCC

Hexamatics Servcomm Sdn Bhd
08-07-2017
1 © 2017 Nokia <Document ID: change ID in footer or remove> <Change information classification in footer>
Parameter Analysis Guideline-
VoLTE & SRVCC
Hexamatics Servcomm Sdn Bhd

08-07-2017
Contents
• Introduction to VoLTE
• VoLTE Radio Resource and Call Flow
• VoLTE Parameters and Counters
• Features related to VoLTE
• Introduction to SRVCC
• SRVCC Architecture and its Elements
• SRVCC Parameters and Counters
• Features related to SRVCC
3 © 2017 Nokia
Introduction to VoLTE
Introduction to VoLTE
What is VoLTE?
• In simple terms, VoLTE is defined as VoIP over the LTE air interface. However, there is a clear difference between carrying VoIP packets from an operator’s
own VoLTE offering vs. VoIP packets carried over the same LTE air interface from an OTT provider like Skype:
• Guaranteed QoS.
• The operator’s VoLTE service will provide continuity of service (e.g.: the same supplementary services) during mobility as the user moves from LTE
technology to other wireless technologies.
• The operator’s VoLTE service is based on the IP Multimedia Subsystem (IMS) service platform that facilitates interworking with other operators’ IMS
services, PSTN interworking, as well as interworking with other wireless networks.
5 © 2017 Nokia
Introduction to VoLTE (Contd.)
• Initial deployments of LTE focused primarily on Internet access, which offered best-effort packet data service for mobile subscribers.
• Since the majority of IP-based applications (email, Web browsing, file transfer, etc.) work well in this environment, this strategy has been very successful.
• With the introduction of real-time services like Voice over IP (VoIP) and video and audio streaming, the LTE network must evolve in order to handle the more
rigorous requirements of these features.
• Voice over LTE (VoLTE) in particular requires the deployment of additional network components and functions in order to properly control and manage these
services; the IP Multimedia Subsystem
• IP Multimedia Subsystem (IMS) architecture is the platform selected to deliver VoLTE and other services to LTE subscribers.
• In addition, since interruptions to real-time content are much more noticeable to subscribers, special care must be taken to interwork LTE with other networks
(such as 2G/3G wireless networks) in order to minimize disruptions to the end users.
6 © 2017 Nokia
IMS VoLTE Enhancement: The following figure shows the
connectivity
Policy Management and QOS:

• The IMS, PCC and LTE networks collaborate in order to establish
the proper QoS for every service. The IMS call servers determine
the particular requirements for each service, and provide that
information to the PCC. The PCC (specifically, the Policy and
Charging Rules Function, or PCRF) uses the QoS policies defined
by the operator and the user’s subscription profile data to identify
what specific rules must be followed for each service. These rules
are passed to the LTE network, which establishes the appropriate
EPS bearer and enables QoS enforcement to ensure that the rules
are followed. The eNB uses the bearer configuration and QoS
requirements when it schedules the air interface resources, so that
the user receives the proper resources for the service.
• Note that QoS is not just the concern of the LTE network. The entire
path between the subscriber and the other end of the service
(another subscriber, a content service, a media gateway, etc.) must
be configured to properly treat each packet in.
7 © 2017 Nokia
General Principles for Voice Policy Selection:
During the UE attach and tracking area update (TAU) period, the MME selects a voice policy based on the UE capability and configuration on the MME side. The
MME then sends the UE voice policy contained in the Attach Accept message. During voice policy selection, the MME selects a voice policy based on these
following principles:
• If the UE supports only CSFB, the corresponding voice policy is CS Voice only.
• If the UE supports only VoLTE, the corresponding voice policy is IMS PS Voice only, that is, VoLTE.
• If the UE supports both CSFB and VoLTE, the voice policy used before negotiation with the MME is one of the following voice policies specified by operators
during UE registration:
• CS Voice only, that is, CSFB.
• IMS PS Voice only, that is, VoLTE.
• Prefer IMS PS Voice with CS Voice as secondary, that is, VoLTE takes precedence over CSFB.
• Prefer CS Voice with IMS PS Voice as secondary, that is, CSFB takes precedence over VoLTE.
8 © 2017 Nokia
VQM:
• 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.
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
QOS Classes in EPS:
9 © 2017 Nokia
Contents
10 © 2017 Nokia
VoLTE Radio Resource and Call
Flow
VoLTE Radio Resource and Call Flow
Radio Resources:
• All LTE radio connections require two signaling radio bearers (SRBs) to carry Radio Resource Control (RRC) and Non-Access Stratum (NAS) messages
between the UE and the LTE network (SRB 1 and SRB 2, respectively).
• Data radio bearer (DRB) is used for Internet access and best-effort services, such as email and Web browsing.
• Another DRB is used for SIP signaling between the UE and the IMS network with QCI 5 and AM.
• If a VoLTE call is established, an additional DRB must be created to the IMS network in order to carry the actual voice traffic.
• Additional DRBs may be added as needed, depending on the types of services being requested and their specific QoS requirements.
12 © 2017 Nokia
VoLTE Radio Resource and Call Flow (Contd.)
UE States for a VoLTE Call:
• When the device is turned on for the first time, it discovers the LTE network and sets up a default bearer to the IMS; at this point, it receives a temporary ID for
use in the LTE network (its GUTI), as well as an IPv6 address that it will use for any communications with IMS. The UE is informed of the P-CSCF it should
use for IMS-based services at this time.
• The UE then uses this bearer to register with the IMS network, identifying itself with its IMSI and MDN; in return, it receives the address of the S-CSCF it is
assigned to, as well as one or more public URIs (Uniform Resource Identifiers) that it is associated with, which may be used to contact the UE for incoming
VoLTE calls and other services.
• Once the UE is registered and configured, the data is stored away and maintained, even after the UE goes idle, so that it is ready whenever the user needs to use
any IMS-based service.
• VoLTE call Setup is done in 3 steps:
1. RRC and E-RAB bearer setup.
2. IMS Registration.
3. SIP Invite.
13 © 2017 Nokia
VoLTE Call Setup Diagram:
• In the RRC connection setup procedure, a radio connection is set up
between a UE and an eNodeB so that the UE can send service requests and
data packets to upper-layer NEs.
• In the EPS bearer setup (QCI 5) procedure, a QCI 5 radio bearer is set up
for signaling exchange between the UE and the IMS.
• After the QCI 5 radio bearer is set up, the calling UE and the IMS perform
Session Initiation Protocol (SIP) negotiation on the speech codec scheme, IP
address, port number, called UE's information, and other information.
• In the EPS bearer establishment (QCI 1) procedure, a QCI 1 radio bearer is
set up to carry voice packets.
14 © 2017 Nokia
Default Bearer setup for IMS:
Figure 1 shows default bearer setup for IMS
Registration:
Figure 2 shows a Registration example
1. The UE sends the initial SIP REGISTER message to the P-CSCF it has been
told to use during the LTE attach process.
2. The P-CSCF queries the DNS server in order to determine the address of the I-
CSCF in the user’s home network.
3. The P-CSCF forwards the SIP REGISTER message to the I-CSCF.
4. The I-CSCF queries the UE’s HSS to determine if the UE is already assigned to Figure 1: Default Bearer Setup
an S-CSCF. If not, it uses the UE’s profile information to select a suitable S-
CSCF in the home network.
5. The I-CSCF forwards the SIP REGISTER message to the S-CSCF.
6. The S-CSCF queries the HSS for authentication parameters and the user’s
service profile.
7. The S-CSCF also registers the user with other application servers (such as the
TAS) and subscribes to event notifications on the UE’s behalf. The list of
application servers to register with is based on the UE’s service profile
retrieved from the HSS
Figure 2: Registration Example
15 © 2017 Nokia
Signaling and Voice Path example is shown below:
16 © 2017 Nokia
VoLTE to PSTN Call example:
17 © 2017 Nokia
Contents
18 © 2017 Nokia
VoLTE Parameters and Counters
VoLTE Parameters
Parameter Setting for VoLTE :
Switch to enable VoLTE
Feature Script Comment

MOD ENODEBALGOSWITCH:HOMODESWITCH=EutranVoipCapSwitch-
Enable VoLTE on eNodeB level Enables VoLTE on eNodeB level
1;
Parameters used
Feature/Function Parameters MO Current Values VoLTE Recommended

QCI1 PDCP PdcpSnSize RLCPDCPPARAGROUP PdcpSnsize_7bits(0) PdcpSnsize_12bits(1)
QCI1 RLC UlRlcSnSize RLCPDCPPARAGROUP RlcSnSize_size5(0) RlcSnSize_size10(1)
QCI1 RLC DlRlcSnSize RLCPDCPPARAGROUP RlcSnSize_size5(0) RlcSnSize_size10(1)
QCI1 PDCP DiscardTimer RLCPDCPPARAGROUP DiscardTimer_100 DiscardTimer_100
QCI5 PDCP DiscardTimer RLCPDCPPARAGROUP DiscardTimer_150 DiscardTimer_Infinity

SmartPreallocation PreallocationSize CELLULSCHALGO 80 120
SmartPreallocation SmartPreallocationDuration CELLULSCHALGO 50 160
20 © 2017 Nokia
VoLTE Parameters (Contd.)
PdcpSnSize (MO: NE >> eNodeBFunction >> RlcPdcpParaGroup) Impact Area- VoLTE Packet Loss
Parameter Name: UM PDCP-SN size
GUI Value Range: PdcpSnsize_7bits(7), PdcpSnsize_12bits(12)
Actual Value Range: PdcpSnsize_7bits, PdcpSnsize_12bits
Recommended Value: This parameter can be set by the eNodeB by default. The default value are as follows:
QCI 1: PdcpSnsize_12bits(12)
QCI 7: PdcpSnsize_12bits(12
Feature ID LBFD-002008 / TDLBFD-002008
Feature Name Radio Bearer Management
Guidance Notes: The PDCP sequence number size must be large enough to prevent Hyper Frame Number (HFN) mismatch when a large number of packets are
lost. However, a longer PDCP sequence number results in more PDCP header overhead and lower payload throughput.
21 © 2017 Nokia
UlRlcSnSize (MO: NE >> eNodeBFunction >> RlcPdcpParaGroup) Impact Area- VoLTE Load
Parameter Name: Uplink RLC-SN size
GUI Value Range: RlcSnSize_size5(5), RlcSnSize_size10(10)
Actual Value Range: RlcSnSize_size5, RlcSnSize_size10
QCI1: RlcSnSize_size10(10)
Guidance Notes: The sequence number size specified by this parameter must be large enough to prevent sequence number ambiguity caused by HARQ
retransmissions. However, a large size results in a heavy RLC header load.
22 © 2017 Nokia
DlRlcSnSize (MO: NE >> eNodeBFunction >> RlcPdcpParaGroup) Impact Area- VoLTE Load
Parameter Name: Downlink RLC-SN size
GUI Value Range: RlcSnSize_size5(5), RlcSnSize_size10(10)
Actual Value Range: RlcSnSize_size5, RlcSnSize_size10
QCI 1: RlcSnSize_size10(10)
Guidance Notes:. The sequence number size specified by this parameter must be large enough to prevent sequence number ambiguity caused by HARQ
retransmissions. However, a large size results in a heavy RLC header load.
23 © 2017 Nokia
DiscardTimer (MO: NE >> eNodeBFunction >> RlcPdcpParaGroup) Impact Area-VOLTE Service Throughput
Parameter Name: Discard timer
GUI Value Range: DiscardTimer_50(50), DiscardTimer_100(100), DiscardTimer_150(150), DiscardTimer_300(300), DiscardTimer_500(500),
DiscardTimer_750(750), DiscardTimer_1500(1500), DiscardTimer_Infinity(infinity)
Actual Value Range: DiscardTimer_50, DiscardTimer_100, DiscardTimer_150, DiscardTimer_300, DiscardTimer_500, DiscardTimer_750, DiscardTimer_1500,
DiscardTimer_Infinity
CatType is set to LTE:
QCI 1: DiscardTimer_100(100), QCI 2: DiscardTimer_150(150), QCI 3: DiscardTimer_50(50), QCI 4: DiscardTimer_300(300), QCI 5:
DiscardTimer_Infinity(infinity), QCI 6: DiscardTimer_Infinity(infinity), QCI 7: DiscardTimer_150(150), QCI 8: DiscardTimer_Infinity(infinity), QCI 9:
DiscardTimer_Infinity(infinity), QCI 65: DiscardTimer_100(100), QCI 66: DiscardTimer_100(100), QCI 69: DiscardTimer_Infinity(infinity), QCI 70:
DiscardTimer_Infinity(infinity)
CatType is set to EMTC_MODE_A or EMTC_MODE_B: DiscardTimer_Infinity(infinity)
Guidance Notes:. If this parameter is set to a large value, service delay will not meet QCI requirements. If this parameter is set to a small value, excessive PDCP
data will be discarded, causing a decrease in throughput.
24 © 2017 Nokia
PreallocationSize (MO: NE >> eNodeBFunction >> Cell >> CellPreallocGroup) Impact Area- VOLTE Accessibility
Parameter Name: Data Size of Preallocation
GUI Value Range: 45~1500
Actual Value Range: 45~1500
Recommended Value: 80
Feature ID LBFD-00101502 / TDLBFD-00101502 Feature Name Dynamic Scheduling
Guidance Notes: A larger value of this parameter leads to a shorter delay in UL data transmission, but stronger UL interference and more power consumption for UEs. A
smaller value leads to the opposite effects.
SmartPreAllocationDuration (MO: NE >> eNodeBFunction >> CellUlschAlgo) Impact Area- VOLTE Service Integrity
Parameter Name: Smart pre-allocation duration
Feature ID LBFD-00101502 / TDLBFD-00101502, LBFD-001015 / TDLBFD-001015 Feature Name Dynamic Scheduling, Enhanced Scheduling
Guidance Notes:. A larger value of this parameter leads to a shorter delay in UL data transmission, but stronger UL interference and more power consumption for UEs. A
smaller value leads to the opposite effects. If this parameter is set to 0, uplink preallocation does not take effect. If this parameter value is greater than the interval of the ping
service, the delay of ping services decreases.
25 © 2017 Nokia
VoLTE Parameters and Counters
Performance Monitoring:
The table shows Counters/KPIs used to evaluate VoLTE performance.
Counter Name Description
L.E-RAB.AttEst.QCI.1 Number of EUTRAN-to-WCDMA handover preparation attempts for SRVCC
L.E-RAB.AttEst.QCI.5 Number of EUTRAN-to-WCDMA handover execution attempts for SRVCC

L.E-RAB.SuccEst.QCI.1 Number of successful EUTRAN-to-WCDMA handovers for SRVCC
L.E-RAB.SuccEst.QCI.5 Number of EUTRAN-to-GERAN handover preparation attempts for SRVCC
E-RAB (QCI 1) setup success rate RAB.SuccEst.QCI.1/RAB.AttEst.QCI.1
E-RAB (QCI 5) setup success rate RAB.SuccEst.QCI.5/RAB.AttEst.QCI.5
L.E-RAB.AbnormRel.QCI.1 Number of EUTRAN-to-WCDMA handover preparation attempts for SRVCC
L.E-RAB.AbnormRel.QCI.5 Number of EUTRAN-to-WCDMA handover execution attempts for SRVCC
L.E-RAB.NormRel.QCI.1 Number of successful EUTRAN-to-WCDMA handovers for SRVCC
L.E-RAB.NormRel.QCI.5 Number of EUTRAN-to-GERAN handover preparation attempts for SRVCC
Call drop rate (QCI 1) L.E-RAB.AbnormRel.QCI.1/(L.E-RAB.AbnormRel.QCI.1 + L.ERAB. NormRel.QCI.1)
Call drop rate (QCI 5) L.E-RAB.AbnormRel.QCI.5/(L.E-RAB.AbnormRel.QCI.5 + L.ERAB. NormRel.QCI.5)
26 © 2017 Nokia
Contents
• Features Related to VoLTE
27 © 2017 Nokia
Features Related to VoLTE
Features Related to VoLTE
ROHC:
• This chapter describes how the optional feature LOFD-001017 Robust Header Compression (ROHC) works for VoIP.
• 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.
29 © 2017 Nokia
ROHC
Procedure for starting ROHC upon Initial Access:
If both the compressor and the decompressor support ROHC, ROHC is started by default when a VoIP service bearer is set up but is not started for non-VoIP
services during initial access of a UE.
The EPC sends an E-RAB SETUP REQUEST message over the S1 interface, requesting that the eNodeB set up DRBs for data transmission on the user plane and
start ROHC. Figure 1 shows the procedure for starting ROHC.
30 © 2017 Nokia
ROHC (Contd.)
The table shows Counters/KPIs used to evaluate VoLTE performance.
1. ROHC is enabled by setting CellAlgoSwitch.RohcSwitch or PdcpRohcPara.RohcSwitch to ON(On). You are advised to use CellAlgoSwitch.RohcSwitch,
because PdcpRohcPara.RohcSwitch will be removed from later versions.
2. The ROHC capability of a UE includes the maximum number of concurrent activated contexts (MAX_CID) and the profiles supported by the UE. The UE
informs the EPC about its ROHC capability during the initial registration. The eNodeB can acquire the profiles supported by the UE from the EPC or directly
from the UE. After the RRC connection is set up, the EPC sends an Initial Context Setup Request message over the S1 interface to inform the eNodeB of the
UE's radio capability reported by the UE during initial registration. If the eNodeB fails to obtain the UE’s ROHC capability information from the EPC, the
eNodeB sends a UE Capability Enquiry message over the Uu interface to query the UE's ROHC capability.
3. The eNodeB compares the MAX_CID in the ROHC capability information reported by the UE with the eNodeB-supported maximum number of concurrently
active contexts per UE, and chooses the smaller one as the maximum number of concurrent contexts supported by the UE.
4. The eNodeB identifies the UE-supported profiles using the intersection of the following two profiles:
• UE-supported profiles stored on the eNodeB
• eNodeB-supported profiles specified by the PdcpRohcPara.Profiles parameter
5. The eNodeB reallocates the number of concurrent contexts for each DRB of the UE based on the maximum number of concurrent contexts supported by the
UE. Then, the eNodeB sends the reallocated number of concurrent contexts and the determined profiles as the ROHC parameters to the UE through the Uu
interface.
• Note: The reallocation of the number of concurrent contexts does not lead to a change in the number of concurrent contexts already allocated for the UE's
DRBs. The eNodeB can use an RRCConnectionReconfiguration or RRCConnectionReestablishment message to inform the UE of the negotiated ROHC
parameters.
6. After ROHC is started, the compressor and decompressor operate within the ROHC framework for both the uplink and downlink.
31 © 2017 Nokia
ROHC (Contd.)
System Capacity:
Header field compression for voice packets in the ROHC framework reduces the resource blocks (RBs) used for voice service users in the case of same channel
quality and Adaptive Multirate (AMR) for data transmission. For example, if voice service users with 12.65 kbit/s AMR transmission are evenly distributed in a
cell, the number of RBs used for these users will be reduced by about 20% after ROHC is enabled and will work normally.
The RBs saved by ROHC can be used to increase the data service throughput of the cell or the number of voice service users in the cell. The size of the increase
depends on many factors, such as the following:
• User locations
• User quantity
• Data service models (such as Full buffer and Burst)
• RB usage
• Availability of PDCCH control channel elements (CCEs)
• ROHC operating mode
• ROHC compression efficiency
• Support and compatibility of UEs for ROHC
• AMR used for voice service users
32 © 2017 Nokia
ROHC (Contd.)
The increase in the data service throughput of a cell is positively correlated with the number of RBs used for data service users if the following conditions are met:
• RBs of a cell are limited.
• PDCCH CCEs in the cell are adequate.
• ROHC works normally.
• Users are evenly distributed in the cell.
• Users require a large data service volume.
However, the amount of feedback depends on the ROHC operating mode. More feedback uses more radio resources, which limits system capacity expansion. An
ROHC interoperability test (IOT) indicates that some voice over long term evolution (VoLTE) UEs are incompatible with ROHC. These UEs always transmit
uncompressed IR packets even after ROHC is enabled, the coverage or capacity gains expected for ROHC are not achieved, and the number of RBs used for voice
service users slightly increases.
33 © 2017 Nokia
ROHC (Contd.)
Hardware: NONE
License:
Feature ID Feature Name Model License Control Item NE Sales Unit
LOFD-001 RObust Header LTIS00ROHC00 RObust Header Compression eNodeB Per RRC Connected
Compression (ROHC) (ROHC) (FDD) User
Activation:
Using MML Commands: Run the MOD PDCPROHCPARA and MOD CELLALGOSWITCH commands with ROHC switch set to ON(On) and the ROHC
Highest mode and Compression profiles parameters set as required.
MML Command Examples:
//Enabling ROHC
34 © 2017 Nokia
ROHC (Contd.)
Performance Monitoring:
After ROHC is enabled, monitor the counters listed in the following table.
Counter ID Counter Name Description Principle

1526728522 L.PDCP.UL.RoHC.HdrCompRati Compression rate of headers of all uplink PDCP SDU’s The compression efficiency has a negative correlation
o after the ROHC with the values of these counters
1526728523 L.PDCP.UL.RoHC.PktCompRati Compression rate of all uplink PDCP SDUs (including
o headers and payloads) after the ROHC
1526727349 L.PDCP.DL.RoHC.HdrCompRati Compression rate of headers of all downlink PDCP SDUs
o after the ROHC
1526727350 L.PDCP.DL.RoHC.PktCompRati Compression rate of all downlink PDCP SDUs (including
o headers and payloads after the ROHC
1526745690 L.PDCP.UL.RoHC.FailDecomp.V Number of uplink VoLTE packets that fail to be Decompression failure rate of uplink VoLTE packets
oLTE decompressed in ROHC (L.PDCP.UL.RoHC.FailDecomp.VoLTE/L.PDCP.UL.Ro
HC.TotalDecomp.VoLTE): A smaller counter value
1526746015 L.PDCP.UL.RoHC.TotalDecomp. Number of uplink VoLTE packets that need to be
indicates a higher decompression success rate, and a
VoLTE decompressed in ROHC
larger counter value indicates a higher decompression
failure rate.
1526728524 L.Traffic.User.RoHC.Max Maximum number of UEs on which ROHC takes effect in The number of UEs on which ROHC takes effect has a
a cell positive correlation with the values of these counters.
1526728525 L.Traffic.User.RoHC.Avg Average number of UEs on which ROHC takes effect in a
cell
35 © 2017 Nokia
ROHC (Contd.)
Counter ID Counter Name Description Principle

1526730883 L.ChMeas.PRB.DL.DrbUsed.Avg.VoI Average number of PRBs used by DRBs on These counters are used to observe the
P the PDSCH for downlink VoIP services changes in the number of RBs used in
the downlink and uplink by VoLTE
1526730884 L.ChMeas.PRB.UL.DrbUsed.Avg.VoI Average number of PRBs used by DRBs on users before and after ROHC is
P the PUSCH for uplink VoIP services enabled.
36 © 2017 Nokia
ROHC (Contd.)
Counter ID Counter Name Counter Description Feature ID Feature Name
1526727349 L.PDCP.DL.RoHC.HdrCo Compression rate of headers of all Multi-mode: None RObust Header
mpRatio downlink PDCP SDUs after the GSM: None Compression (ROHC)
ROHC UMTS: None RObust Header
LTE: LOFD-001017, Compression (ROHC)
TDLOFD-001017
1526727350 L.PDCP.DL.RoHC.PktCom Compression rate of all downlink Multi-mode: None RObust Header
pRatio PDCP SDUs (including headers and GSM: None Compression (ROHC)
payloads) after the ROHC UMTS: None RObust Header
TDLOFD-001017
1526728522 L.PDCP.UL.RoHC.HdrCo Compression rate of headers of all Multi-mode: None RObust Header
mpRatio uplink PDCP SDUs after the ROHC GSM: None Compression (ROHC)
UMTS: None RObust Header
TDLOFD-001017
1526728523 L.PDCP.UL.RoHC.PktCom Compression rate of all uplink PDCP Multi-mode: None RObust Header
pRatio SDUs (including headers and GSM: None Compression (ROHC)
payloads) after the ROHC UMTS: None RObust Header
TDLOFD-001017
37 © 2017 Nokia
Contents
38 © 2017 Nokia
Introduction to SRVCC
Introduction to SRVCC
SRVCC (Single Radio Voice Call Continuity) Overview:
• SRVCC is a solution to provide continuous voice services on LTE networks.
• When UEs running voice services move out of an LTE network, the voice services can continue in the legacy circuit switched (CS) domain by means of
SRVCC, ensuring voice service continuity.
• SRVCC requires IMS. It is used in specific scenarios on LTE networks where voice services are enabled.
• After a UE accesses the E-UTRAN, its packet switched (PS) bearers are established by the mobility management entity (MME), serving gateway (S-GW), and
PDN gateway (P-GW).
• Then, this UE can use the PS bearers to access IMS for a voice over IP (VoIP) service. When the UE with an ongoing VoIP session is to be handed over from
the E-UTRAN to the UTRAN or GERAN, the MME initiates a handover request to the mobile switching center (MSC) server, which is responsible for voice
communication, to transfer the session without interruption. This is an SRVCC procedure.
• SRVCC is a mean of inter-RAT handover (RAT stands for radio access technology). It enables a smooth session transfer from VoIP over IMS on the LTE
network to CS services in the UTRAN or GERAN.
40 © 2017 Nokia
Introduction to SRVCC (Contd.)
41 © 2017 Nokia
SRVCC Benefits:
• Before the E-UTRAN is deployed across the operator's coverage areas, SRVCC is used to ensure voice service continuity. At the edge of the E-UTRAN, UEs
running VoIP services can be handed over to the UTRAN or GERAN by means of SRVCC, which transforms the VoIP services into CS services.
• Additionally, SRVCC—by ensuring voice call continuity—satisfies critical requirements for emergency calls.
• Without SRVCC, operators with gaps or weaknesses in LTE coverage (or offering roaming in non-LTE networks) cannot realize the user experience and
network efficiency advantages offered by VoLTE until LTE coverage is built out to match the full geographic range of their subscriber service commitments.
• The main advantage is that the call will not drop - will only be transferred to the CS domain of the legacy networks.
42 © 2017 Nokia
LTE Voice Interworking Strategy among RAT
User Experience will be increased by staying with VoLTE with:
• Increased LTE Coverage by adding sites or use lower frequency.
• Increased VoLTE terminal penetration.
43 © 2017 Nokia
Contents
44 © 2017 Nokia
SRVCC Architecture and Its Elements
SRVCC Architecture and Its Elements
The below figure shows SRVCC network architecture.
46 © 2017 Nokia
SRVCC Architecture and Its Elements (Contd.)
The table shows elements of network architecture.
Element Function
Sv interface Sv interface Supports SRVCC as an interface between the MME and SRVCC MSC server.
E-UTRAN Supports the SRVCC procedure, which is similar to a PS handover procedure. During the SRVCC procedure, the E-UTRAN
E-UTRAN sends an SRVCC indication to the MME, notifying the MME of whether the target cell supports SRVCC and concurrent CS and PS
handovers.
UTRAN/GERAN Supports incoming CS handovers for CS only SRVCC.
• Provides the bearer splitting function to separate the voice bearer from non-voice bearers. Then, the MME initiates a CS handover
procedure for the voice bearer towards the MSC server and initiates a PS handover procedure for the non-voice bearers towards the
serving GPRS support node (SGSN).
MME • Initiates an SRVCC procedure over the Sv interface for an emergency call and includes an emergency indication in the transmitted
message.
• Selects the MSC server that is enhanced for SRVCC (shown as SRVCC MSC server in the figure) based on the domain name server
(DNS) procedures or local configuration.
SRVCC MSC server Processes CS handovers and session transfer.
SGSN Processes PS handovers for PS services that are to be handed over simultaneously using SRVCC.
47 © 2017 Nokia
The table shows elements of network architecture.
Element Function
UTRAN/GERAN Supports incoming CS handovers for CS only SRVCC.
• Is the first contact point for the UE within the IMS.
• Provides the proxy function by accepting and forwarding service requests, but cannot change the Request URI field in
Proxy-call session control function
the INVITE message.
(P-CSCF)
• Provides the user agent (UA) function by terminating and independently creating Session Initiation Protocol (SIP)
sessions when exceptions occur.
• Acts as the control center of the IMS.
• Processes registration and authentication requests from UEs and controls sessions.
Serving-call session control function
• Provides basic session routing for calling and called parties on the IMS.
(SCSCF)
• Routes value-added services to the application server (AS) and performs service control interactions according to the
IMS rules to which users are subscribed.
Interrogating-call session control
• Assigns S-CSCFs to UEs, supports route query, and forwards SIP requests to another IMS domain.
function (ICSCF)
Media gateway control function • Enables interworking between the IMS control plane and legacy CS network.
(MGCF)
Service centralization and continuity • Ensures the centralization and continuity of VoIP services on the LTE network.
application server (SCC AS)
48 © 2017 Nokia
Signaling Procedure:
Below figure shows the signaling procedure for SRVCC from the E-UTRAN to the UTRAN or GERAN.
49 © 2017 Nokia
Signaling Procedure
• After triggering an SRVCC procedure, the eNodeB delivers the inter-RAT measurement configuration to the UE.
• The UE responds to the eNodeB with an RRC Connection Reconfiguration Complete message.
• Upon detecting that a neighboring cell meets the condition for triggering an inter-RAT handover, the UE sends a measurement report to the eNodeB.
• The eNodeB determines to perform a handover and sends a Handover Required message containing an SRVCC HO Indication to the MME.
• The MME separates the voice bearer from non-voice bearers and then sends a Relocation Request message to both the SRVCC MSC server and target SGSN.
• After receiving the Relocation Request message, the SRVCC MSC server identifies the target MSC server based on the target cell ID contained in the message.
Then, the target MSC server instructs the target radio network controller (RNC) or base station controller (BSC) to prepare for a handover. After resources are
ready, the target RNC or BSC responds to the target MSC server. Meanwhile, the target SGSN prepares for a handover of PS services, which is similar to that
for an inter-RAT PS handover procedure. The UE media plane is transferred on the IMS.
• The MME receives a response from the target MSC server or target SGSN, indicating that the handover preparation is complete.
• The MME delivers a handover command to the eNodeB.
• The eNodeB delivers a handover command to the UE.
• After receiving the handover command, the UE accesses the target network.
• The UE sends the target radio access network (RAN) a Handover Complete message, indicating that the handover procedure for SRVCC is complete
50 © 2017 Nokia
SRVCC Algorithm:
SRVCC is an inter-RAT procedure for voice services.
• Triggering
• When a UE is running a voice service, a handover may be required for this UE.
• For the handover, the eNodeB triggers an SRVCC procedure based on the UE capability and related switch
status on the eNodeB.
• Measurement
• The eNodeB delivers the measurement configuration to the UE based on UE capabilities, and the UE starts
measuring the inter-RAT neighboring cells that meet the requirements.
• Decision and execution
• Based on the measurement report sent by the UE, the eNodeB determines the target cell and performs the
handover procedure for SRVCC.
51 © 2017 Nokia
Contents
52 © 2017 Nokia
SRVCC Parameters and Counters
SRVCC Parameters
Parameter Settings:
Parameter Name Technology MO Current Values VoLTE recommend

ADD
INTERRATHOUTRANB1THDECN0 LTE -20 -24
INTERRATHOUTRANGROUP
ADD
INTERRATHOUTRANB1THDRSCP LTE -103 -97
ADD
INTERRATHOUTRANB1HYST LTE 2 2
ADD
INTERRATHOUTRANB1TIMETOTRIG LTE 640ms 320ms
SNonIntraSearch LTE MOD CELLRESEL 9 9 (-110dBm)
8 (-112dBm)
ThrshServLow LTE MOD CELLRESEL 7
CmpSwitch=CMP_IU_IMS_PROC_AS_NORMAL_P
UMTS SET UCORRMALGOSWITCH OFF ON
S_SWITCH
THDTOHIGH UMTS UCELLNFREQPRIOINFO 9 10 (-108 dBm)
54 © 2017 Nokia
SRVCC Parameters (Contd.)
UE Capability Information for SRVCC: LTE RRC
Following is Information Elements showing SRVCC supportability in UE Capability Information message (36.331 v12.03).
[LTE] RRC : Mobility From EUTRA Command

• This message triggers UE switch to WCDMA and inform UE of all the radio bearer setup information to perform CS voice call
[WCDMA] RRC : HANDOVER To UTRAN Complete

• If Handover (SRVCC) is successful, UE send Handover to Utran Complete message from WCDMA Cell.
55 © 2017 Nokia
Conclusion
• VoLTE offers numerous user experience and operator network benefits in the rapidly growing LTE network environments, unachievable in any other way.
SRVCC is a key functionality in the implementation of a stepwise LTE and VoLTE deployment, interoperable with legacy networks.
• Interoperability development and performance testing has shown that VoLTE with SRVCC is operational and capable of meeting the quality of service
performance specifications for voice interruption and call retention.
• The impact on legacy networks is manageable; while software upgrades are required for the LTE/EPC/IMS subsystems, there is limited—or no—impact on the
legacy RAN, and only a fraction of deployed MSC-Ss need to be upgraded.
• Consequently, the second phase of LTE voice evolution— VoLTE with SRVCC in hybrid LTE/2G/3G network environments—is now ready to move toward
operational deployment.
56 © 2017 Nokia
InterRatHoUtranB1ThdEcn0 (MO: NE >> eNodeBFunction >> InterRatHoUtranGroup) Impact Area- Accessibility and Mobility
Parameter Name: CoverageBased UTRAN ECN0 trigger threshold
GUI Value Range: -48~0
Actual Value Range: -24~0
Recommended Value: -24
Feature ID LOFD-001019 / TDLOFD-001019, LOFD-001022 / TDLOFD-001022
Feature Name PS Inter-RAT Mobility between E-UTRAN and UTRAN, SRVCC to UTRAN
Guidance Notes:. A larger value of this parameter results in a lower probability of handovers to UTRAN, and a smaller value results in a higher probability.
57 © 2017 Nokia
InterRatHoUtranB1ThdRscp (MO: NE >> eNodeBFunction >> InterRatHoUtranGroup) Impact Area- Accessibility and Mobility
Parameter Name: CoverageBased UTRAN RSCP trigger threshold
GUI Value Range: -120~-25
Actual Value Range: -120~-25
Recommended Value: -103
58 © 2017 Nokia
InterRatHoUtranB1Hyst (MO: NE >> eNodeBFunction >> InterRatHoUtranGroup) Impact Area- Accessibility and Mobility
Parameter Name: UTRAN handover hysteresis
Guidance Notes:. The entering condition of event B1 is as follows: Mn + Ofn - Hys > Thresh.
Mn is the measurement value of the neighboring cell. Ofn is the frequency-specific offset of the neighboring cell. Thresh is the threshold for event B1. Hys is the
hysteresis for event B1.
A larger value of Hys results in a lower probability of triggering event B1 and therefore a lower probability of handover. A large value may affect user experience.
A smaller value of Hys leads to a higher probability of triggering event B1. A small value may cause handover decision errors and ping-pong handovers.
59 © 2017 Nokia
InterRatHoUtranB1TimeToTrig (MO: NE >> eNodeBFunction >> InterRatHoUtranGroup) Impact Area- Accessibility and Mobility
Parameter Name: UTRAN time to trigger
GUI Value Range: 0ms(0ms), 40ms(40ms), 64ms(64ms), 80ms(80ms), 100ms(100ms), 128ms(128ms), 160ms(160ms), 256ms(256ms), 320ms(320ms),
480ms(480ms), 512ms(512ms), 640ms(640ms), 1024ms(1024ms), 1280ms(1280ms), 2560ms(2560ms), 5120ms(5120ms)
Actual Value Range: 0ms, 40ms, 64ms, 80ms, 100ms, 128ms, 160ms, 256ms, 320ms, 480ms, 512ms, 640ms, 1024ms, 1280ms, 2560ms, 5120ms
Recommended Value: 320ms(320ms)
Feature ID LOFD-001019 / TDLOFD-001019, LOFD-001022 / TDLOFD-001022 Feature Name PS Inter-RAT Mobility between E-UTRAN and UTRAN,
SRVCC to UTRAN
SNonIntraSearch (MO: NE >> eNodeBFunction >> CellResel) Impact Area- Accessibility and Mobility
Parameter Name: Threshold for non-intra frequency measurements
Feature ID LBFD-00201803 / TDLBFD-00201803 / MLBFD-12000237, LBFD-002009 / TDLBFD-002009 / MLBFD-12000229
Feature Name Cell Selection and Re-selection, Broadcast of system information
Guidance Notes:. With other conditions unchanged, a larger value of this parameter leads to a higher probability of triggering inter-frequency or inter-RAT
measurements, and a smaller value indicates a lower probability.
60 © 2017 Nokia
ThrshServLow (MO: NE >> eNodeBFunction >> CellResel) Impact Area- Accessibility and Mobility
Parameter Name: Serving frequency lower priority threshold
Feature ID LBFD-00201803 / TDLBFD-00201803, LBFD-002009 / TDLBFD-002009
Feature Name Cell Selection and Re-selection, Broadcast of system information
Guidance Notes:. A smaller value of this parameter indicates a lower frequency of the reselection to a low priority inter-frequency/inter-RAT cell.
.
61 © 2017 Nokia
Parameter Optimization
Parameter Optimization:
• Thresholds for Triggering Event B1
• In a coverage, service, or load based handover for SRVCC, the measurement configuration contains handover parameters related to event B1
• B1: Inter RAT neighbor becomes better than threshold
• B2: PCell becomes worse than threshold1 and inter RAT neighbor becomes better than threshold2
62 © 2017 Nokia
SRVCC Counters
Performance Monitoring: The table shows Counters/KPIs used to evaluate SRVCC performance.
Counter Name Description
L.IRATHO.SRVCC.E2W.PrepAttOut Number of EUTRAN-to-WCDMA handover preparation attempts for SRVCC
L.IRATHO.SRVCC.E2W.ExecAttOut Number of EUTRAN-to-WCDMA handover execution attempts for SRVCC
L.IRATHO.SRVCC.E2W.ExecSuccOut Number of successful EUTRAN-to-WCDMA handovers for SRVCC
L.IRATHO.SRVCC.E2G.PrepAttOut Number of EUTRAN-to-GERAN handover preparation attempts for SRVCC
L.IRATHO.SRVCC.E2G.ExecAttOut Number of EUTRAN-to-GERAN handover execution attempts for SRVCC
L.IRATHO.SRVCC.E2G.ExecSuccOut Number of successful EUTRAN-to-GERAN handovers for SRVCC
Number of SRVCC-based outgoing handover preparation failures from E-UTRAN to WCDMA network
L.IRATHO.E2W.SRVCC.Prep.FailOut.MME
because of the MME side causes
L.IRATHO.E2W.SRVCC.Prep.FailOut.PrepFailure
because of the response of handover preparation failure from WCDMA network
L.IRATHO.E2W.SRVCC.Prep.FailOut.NoReply
because of no response from WCDMA network
63 © 2017 Nokia
Contents
64 © 2017 Nokia
Features Related to SRVCC
Features Related to SRVCC
The table shows the features for SRVCC.
Feature Script
MOD INTERRATPOLICYCFGGROUP:INTERRATPOLICYCFGGROUPID=0,UTRANHOCFG=SRVCC-1;
SRVCC Policy Configuration MOD STANDARDQCI: Qci=QCI1, InterRatPolicyCfgGroupId=0;
MOD STANDARDQCI: Qci=QCI5, InterRatPolicyCfgGroupId=0;
SRVCC To UTRAN MOD ENODEBALGOSWITCH:HOMODESWITCH=UtranSrvccSwitch-1;
Feature Description
SRVCC Policy Configuration Enables SRVCC on QCI1 & 5 carrying VoLTE traffic
SRVCC To UTRAN Enables UTRAN Measurements and SRVCC
66 © 2017 Nokia
Features related to SRVCC (Contd.)
Name: LOFD-001087 SRVCC Flexible Steering to UTRAN
Requirement for Hardware: None
Requirements for other features: The VoLTE Feature Package has to be configured before this feature is activated.
License: The license controlling this feature has been activated. For details about the license control items and how to activate the license, see License
Management Feature Parameter Description.
LOFD-001087 (SRVCC Flexible Steering to UTRAN): This feature is under license control.
Name: LOFD-001023 SRVCC to GERAN

Requirement for Hardware: None
Requirements for other features: The VoLTE Feature Package has to be configured before this feature is activated.
License: The license controlling this feature has been activated. For details about the license control items and how to activate the license, see License
Management Feature Parameter Description.
LOFD-001023 (SRVCC to GERAN): This feature is under license control.
67 © 2017 Nokia
Features related to SRVCC (Contd.)
General Principles for Voice Policy Selection:
During the UE attach and tracking area update (TAU) period, the MME selects a voice policy based on the UE capability and configuration on the MME side. The
MME then sends the UE the voice policy contained in the Attach Accept message. During voice policy selection, the MME selects a voice policy based on the
following principles:
• If the UE supports only CSFB, the corresponding voice policy is CS Voice only.
• If the UE supports only VoLTE, the corresponding voice policy is IMS PS Voice only, that is, VoLTE.
• If the UE supports both CSFB and VoLTE, the voice policy used before negotiation with the MME is one of the following voice policies specified by operators
during UE registration:
• CS Voice only That is, CSFB.
• IMS PS Voice only That is, VoLTE.
• Prefer IMS PS Voice with CS Voice as secondary, that is, VoLTE takes precedence over CSFB.
• Prefer CS Voice with IMS PS Voice as secondary, that is, CSFB takes precedence over VoLTE.
68 © 2017 Nokia
Copyright and confidentiality
The contents of this document are proprietary and Nokia operates a policy of ongoing development. Nokia This document and the product(s) it describes
confidential property of Nokia. This document is reserves the right to make changes and improvements to are protected by copyright according to the
provided subject to confidentiality obligations of the any of the products and/or services described in this applicable laws.
applicable agreement(s). document or withdraw this document at any time
without prior notice. Nokia is a registered trademark of Nokia Corporation.
This document is intended for use of Nokia’s customers Other product and company names mentioned herein
and collaborators only for the purpose for which this The contents of this document are provided "as is". may be trademarks or trade names of their respective
document is submitted by Nokia. No part of this Except as required by applicable law, no warranties of owners.
document may be reproduced or made available to the any kind, either express or implied, including, but not
public or to any third party in any form or means limited to, the implied warranties of merchantability
without the prior written permission of Nokia. This and fitness for a particular purpose, are made in relation
document is to be used by properly trained professional to the accuracy, reliability or contents of this document.
personnel. Any use of the contents in this document is NOKIA SHALL NOT BE RESPONSIBLE IN ANY
limited strictly to the use(s) specifically created in the EVENT FOR ERRORS IN THIS DOCUMENT or for
applicable agreement(s) under which the document is any loss of data or income or any special, incidental,
submitted. The user of this document may voluntarily consequential, indirect or direct damages howsoever
provide suggestions, comments or other feedback to caused, that might arise from the use of this document
Nokia in respect of the contents of this document or any contents of this document.
("Feedback").
Such Feedback may be used in Nokia products and
related specifications or other documentation.
Accordingly, if the user of this document gives Nokia
Feedback on the contents of this document, Nokia may
freely use, disclose, reproduce, license, distribute and
otherwise commercialize the feedback in any Nokia
product, technology, service, specification or other
documentation.
Revision history and metadata
Document ID: Parameter Analysis Guideline- VoLTE & SRVCC

Document Location: Malaysia
Organization: Hexamatics
Reviewed Approval
Version Description of charges Date Author Owner Status Reviewed by date Approver date
V1.1 Draft 08-07-2017 Hexamatics Nokia -

HL1 Parameter Analysis Guideline - VoLTE &amp; SRVCC v1.1

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

HL1 Parameter Analysis Guideline - VoLTE &amp; SRVCC v1.1

Загружено:

Авторское право:

Доступные форматы

Nokia Multivendor Optimization

Parameter Analysis Guideline- VoLTE & SRVCC

Hexamatics Servcomm Sdn Bhd

Policy Management and QOS:

User Experience Bad Poor Accept Good Excellent

QOS Classes in EPS:

Figure 2: Registration Example

Switch to enable VoLTE

Feature Script Comment

Feature/Function Parameters MO Current Values VoLTE Recommended

QCI1 RLC UlRlcSnSize RLCPDCPPARAGROUP RlcSnSize_size5(0) RlcSnSize_size10(1)

QCI1 RLC DlRlcSnSize RLCPDCPPARAGROUP RlcSnSize_size5(0) RlcSnSize_size10(1)

QCI1 PDCP DiscardTimer RLCPDCPPARAGROUP DiscardTimer_100 DiscardTimer_100

QCI5 PDCP DiscardTimer RLCPDCPPARAGROUP DiscardTimer_150 DiscardTimer_Infinity

The table shows Counters/KPIs used to evaluate VoLTE performance.

Counter Name Description

L.E-RAB.AttEst.QCI.1 Number of EUTRAN-to-WCDMA handover preparation attempts for SRVCC

L.E-RAB.AttEst.QCI.5 Number of EUTRAN-to-WCDMA handover execution attempts for SRVCC

E-RAB (QCI 1) setup success rate RAB.SuccEst.QCI.1/RAB.AttEst.QCI.1

E-RAB (QCI 5) setup success rate RAB.SuccEst.QCI.5/RAB.AttEst.QCI.5

L.E-RAB.AbnormRel.QCI.1 Number of EUTRAN-to-WCDMA handover preparation attempts for SRVCC

L.E-RAB.AbnormRel.QCI.5 Number of EUTRAN-to-WCDMA handover execution attempts for SRVCC

L.E-RAB.NormRel.QCI.1 Number of successful EUTRAN-to-WCDMA handovers for SRVCC

L.E-RAB.NormRel.QCI.5 Number of EUTRAN-to-GERAN handover preparation attempts for SRVCC

Call drop rate (QCI 1) L.E-RAB.AbnormRel.QCI.1/(L.E-RAB.AbnormRel.QCI.1 + L.ERAB. NormRel.QCI.1)

Call drop rate (QCI 5) L.E-RAB.AbnormRel.QCI.5/(L.E-RAB.AbnormRel.QCI.5 + L.ERAB. NormRel.QCI.5)

Feature ID Feature Name Model License Control Item NE Sales Unit

MML Command Examples:

Counter ID Counter Name Description Principle

Counter ID Counter Name Description Principle

SRVCC MSC server Processes CS handovers and session transfer.

SRVCC is an inter-RAT procedure for voice services.

Parameter Name Technology MO Current Values VoLTE recommend

[LTE] RRC : Mobility From EUTRA Command

[WCDMA] RRC : HANDOVER To UTRAN Complete

Counter Name Description

L.IRATHO.SRVCC.E2W.PrepAttOut Number of EUTRAN-to-WCDMA handover preparation attempts for SRVCC

L.IRATHO.SRVCC.E2W.ExecAttOut Number of EUTRAN-to-WCDMA handover execution attempts for SRVCC

L.IRATHO.SRVCC.E2W.ExecSuccOut Number of successful EUTRAN-to-WCDMA handovers for SRVCC

L.IRATHO.SRVCC.E2G.PrepAttOut Number of EUTRAN-to-GERAN handover preparation attempts for SRVCC

L.IRATHO.SRVCC.E2G.ExecAttOut Number of EUTRAN-to-GERAN handover execution attempts for SRVCC

L.IRATHO.SRVCC.E2G.ExecSuccOut Number of successful EUTRAN-to-GERAN handovers for SRVCC

SRVCC Policy Configuration MOD STANDARDQCI: Qci=QCI1, InterRatPolicyCfgGroupId=0;

MOD STANDARDQCI: Qci=QCI5, InterRatPolicyCfgGroupId=0;

SRVCC To UTRAN MOD ENODEBALGOSWITCH:HOMODESWITCH=UtranSrvccSwitch-1;

SRVCC To UTRAN Enables UTRAN Measurements and SRVCC

Name: LOFD-001023 SRVCC to GERAN

Document ID: Parameter Analysis Guideline- VoLTE & SRVCC

V1.1 Draft 08-07-2017 Hexamatics Nokia -

Вам также может понравиться

HL1 Parameter Analysis Guideline - VoLTE & SRVCC v1.1

HL1 Parameter Analysis Guideline - VoLTE & SRVCC v1.1