ERICSSON VoLTE Mobility Design Solution Document TE-RAN 2/2/2016 Contents 1 Mobility Design ................................................................................................................... 1 1.1 Service Motivation........................................................................................................ 1 1.2 Scope .......................................................................................................................... 2 1.3 Inputs........................................................................................................................... 2 1.4 Outputs ........................................................................................................................ 2 1.5 Strategy ....................................................................................................................... 2 1.5.1 Intra-frequency Intra-frequency LTE HO Strategy.......................................................................... 3 1.5.2 Inter-frequency Inter-frequency LTE HO Strategy.......................................................................... 3 1.5.3 SRVCC HO Strategy............................................................................................12 1.6 1 Responsibility Responsibility matrix ...................................................................................................17 Mobility Design Description: The objective of this service module is to provide a low-level design for new mobility features for VoLTE introduction as well as modifications to existing mobility features to cater for VoLTE introduction In a pre-VoLTE LTE network, an optimized mobility strategy dealing with both coverage-based and load-based mobility features will be deployed. This mobility strategy is more than likely driven by only mobile broadband (MBB) traffic. The objective of this service module is to provide a low-level design for new mobility features for VoLTE introduction as well as modifications to existing mobility features to cater for VoLTE introduction. 1.1 Service Motivation Currently in most networks, where LTE is deployed with underlying WCDMA or GSM RATs, the LTE coverage footprint will likely still be lower than more the more mature technologies. This means that VoLTE coverage will not be contiguous across a whole network. Therefore the mobility of a VoLTE call between other LTE frequencies and the transition of VoLTE to a CS call on either WCDMA or GSM is of great importance as to maintain retainability and end user experience. The operators current mobility strategy must be assessed and the potential impact from VoLTE specific mobility features need to be discussed with the customer. By using the service specific mobility features as outlined below, the legacy mobility functionality for MBB traffic can be maintained and different thresholds applied for VoLTE traffic. 1.2 Scope This solution document will focus on VoLTE mobility design recommendations only for radio network consisting of Ericsson eNodeBs. 1.3 Inputs 1. Network Topology including number of carriers per site per technology 2. Site Database 3. Parameter Settings 4. Activated Features 1.4 Outputs 1. Intra-frequency Intra-freq uency LTE HO strategy: Features and Parameter Settings 2. Inter-frequency Inter-freq uency LTE LTE HO strategy : Features and Parameter Settings 3. SRVCC HO strategy: Features and Parameter Settings 1.5 Strategy VoLTE deployment does not need a change in the legacy CSFB configuration. CSFB to be maintained in areas where VoLTE yet to be deployed and also in VoLTE areas for non-VoLTE capable UEs. VoLTE and CSFB can co-exist depending on the existing VoLTE deployment scenario as shown below: 1. VoLTE deployed in certain areas of LTE network A. In VoLTE activated activated area area VoLTE enabled UEs will perform VoLTE and then SRVCC in poor coverage Non-VoLTE capable UEs will still use CSFB in VoLTE area B. In non-VoLTE activated area CSFB still needed for ALL users 2. VoLTE deployed network wide A. VoLTE enabled enabled UEs will perform VoLTE VoLTE and then SRVCC SRVCC in poor poor coverage B. Non-VoLTE capable UEs will still need to use CSFB in VoLTE area VoLTE VoLTE Mobil Mobility ity Design Flowchart. Flowchart. pdf 1.5.1 Intra-frequency Intra-fr equency LTE HO Strategy No changes need to be made to the existing Intra-Frequency LTE handover strategy for VoLTE mobility. The impact from the introduction of VoLTE for IntraFrequency LTE handover deals with the features FAJ 121 0490 Data Forwarding at Intra-LTE Handover and FAJ 121 1800 Packet Forwarding at S1 Handover. With the enabling of feature FAJ 121 0891 RLC in UM in a VoLTE network, which is a mandatory feature, it is important to ensure that the data forwarding for RLC UM is also enabled. This is done by ensuring the parameter QciProfilePredefined=qci1:: dataFwdPerQciEnabled=TRUE. UE Level Oscillating Handover Minimization can be activated to decrease the number of unnecessary handover, and thus decrease the signaling load and potentially increase throughput. Please note that this feature is not specific to QCI 1 only. RECOMMENDATION: If the features FAJ 121 0490 Data Forwarding at LTE Handover and FAJ 121 1800 Packet Forwarding at S1 Handover are enabled, ensure that the parameter QciProfilePredefined=qci1:: dataFwdPerQciEnabled=TRUE. This helps to improve packet loss during handovers leading to better MOS. 1.5.2 1.5.2.1 Inter-frequency Inter-fr equency LTE HO Strategy Coverage-Triggered Coverage-T riggered Mobility Mobility between LTE frequencies is only possible for VoLTE calls, QCI1 traffic, if the feature FAJ 121 0877 Coverage Triggered Inter-Frequency Handover is active in the network. If the feature FAJ 121 0797 Coverage-Triggered InterFrequency Session Continuity is only used in the network, then VoLTE calls will not be able to perform any LTE Inter-Frequency Handover. In this case QCI1 connection would remain on the source LTE frequency in poor coverage and eventually drop. RECOMMENDATION: For a multi-LTE frequency network FAJ 1210 977 Coverage Triggered Inter-Frequency Handover must be activated to allow Inter-Frequency VoLTE mobility. FAJ 121 0797 Coverage-Triggered Inter-Frequency Session Continuity alone will not enable Inter-Frequency Mobility for VoLTE calls. To prioritize different RATs and LTE frequencies when poor coverage is triggered, the parameter connectedModeMobilityPrio is defined per frequency relation. With the introduction of VoLTE, a new priority parameter, voicePrio is used. In case of only one frequency, VoicePrio can be set to highest priority (7) in order to maintain the UE in LTE as long as possible.In case of multi-layer network deployment, voicePrio can be used to prioritize different frequencies based on existing coverage (spotty or continuous) and operator inputs so as to maintain seamless coverage for the VoLTE user. A frequency can be excluded by setting voicePrio to -1. Voiceprio can use the same settings as connectedModeMobilityPriority if voice call priorities have to be kept same as existing MBB priorities. The two events for coverage triggered inter-frequency mobility, namely Event A2 and A5 can have QCI specific offsets applied to them using the feature Service Triggered Mobility. Using the feature Multi-Layer Service-Triggered Mobility, events A2 and A5 can have different threshold offset values for QCIs as well as for different frequency relations. This feature overrides the Service Triggered Mobility feature when both features are activated.These offsets can be either positive or negative giving flexibility in where VoLTE mobility would be performed compared to MBB mobility. 1.5.2.1.1 FAJ 121 1747 Service Triggered Mobility For a comprehensive mobility strategy for VoLTE deployment, it is strongly recommended to deploy the feature FAJ 121 1747 Service Triggered Mobility. This feature enables coverage-triggered mobility based on the Quality of Service (QoS) defined for the User Equipment (UE) bearers. The feature applies dynamic levels of coverage thresholds based on the QoS Class Identifier (QCI) profiles of the bearers. Each QCI profile holds offsets for the thresholds for Event A1, Event A2, Event A5, and Event B2. This makes it possible to have different coverage triggered mobility thresholds for different traffic types. The below equations show the offsets the Service Triggered Mobility introduce and how these affect normal coverage threshold events. Note: In the below equations the RSRP thresholds are only referenced however the same applies if RSRQ thresholds are used. E vent A 2 Threshold: Threshold: Without Service Triggered Mobility All QCI profiles: + ℎ2 ℎ2 < 2ℎℎ 2ℎℎ With Service Triggered Mobility QCI Profile 1 (VoLTE Traffic): Traffic) : + ℎ ℎ2 2 < 2ℎℎ 2ℎℎ + E vent A 5 Threshold: Threshold: Without Service Triggered Mobility All QCI Profiles: + ℎ5 < 5ℎℎ1 5ℎℎ1 − ℎ5 > 5ℎℎ2 5ℎℎ2 With Service Triggered Mobility QCI Profile 1: + ℎ ℎ5 5 < 5ℎℎ1 + − ℎ ℎ5 5 > 5ℎℎ2 + 1.5.2.1.2 FAJ 121 4124 Multi-Layer Service-Triggered Service-Tr iggered Mobility (L15B) The main benefit of this feature is the possibility to tune different services and frequency relations with different threshold offset values for A2 and A5 events. This feature overrides the Service Triggered Mobility feature when both features are activated. By configuring thresholds per target frequency relation, this feature can differentiate bad coverage behavior on target frequency. UE’s A1A2Search threshold, when the Multi -Layer Service-Triggered Service-Triggered Mobility feature is activated, is calculated in accordance with the following: A1A2SearchThreshol A1A2SearchThresholdXQCI=Repo dXQCI=ReportConfigS rtConfigSearch.a1a earch.a1a2SearchTh 2SearchThresholdX resholdX + ReportConfigSearch. qciA1A2ThrOffsets<qci> .a1a2ThrXQciOffset Where X = RSRP or RSRQ If an operator does not want to tune different service with different QCI specific threshold offset, the threshold offset parameter, in this example, a1a2ThrXQciOffset in each QCI profile instance qciA1A2ThrOffsets can be set to 0 as default value. UE’s event A5 threshold1, when the Multi -Layer Service-Triggered Mobility feature is activated, is calculated in accordance with the following: A5Threshold1XQCI A5Threshold1XQCI = ReportConfigA5.a5Th ReportConfigA5.a5Threshold1X reshold1X + EUtranFreqRelation.a5Thr1XFreqOffset + EUtranFreqRelation.eutranFreqToQciProfileRelation<qci>.a5Thr1XFreqQciOffset Calculation formulae for the A2 and A5 thresholds are shown below: It has been seen in live test results that the voice service area in a new VoLTE network can be smaller than that of MBB service area. It is expected that the service triggered mobility offsets could get set to a positive value in the range of 2 to 6 dB based on drive test measurements in the tuning phase of the VoLTE deployment. But in early stages of network it is recommended to set these offsets to 0 and then tune from there based on network performance after VoLTE launch. RECOMMENDATION: Set the Service Specific Mobility thresholds to 0 initially for QCI 1 and then tune to a positive value in the range of 2 to 6 dB based on drive test measurements and network performance. 1.5.2.1.3 FAJ 121 3013 Mobility Control at Poor Coverage VoLTE connections will not be subject to the critical threshold in Mobility Control at Poor Coverage in that the connection will not be released and redirected at the critical threshold unlike MBB connections. However, if Mobility Control at Poor Coverage is enabled in a pre-VoLTE LTE network, then the Event A1 and Event A2 threshold threshold parameters parameters are replaced replaced by the search search thresholds thresholds as introduced introduced by Mobility Control at Poor Coverage. These thresholds will be subject to Service Triggered Mobility offsets. It is important to be aware of this when designing the mobility strategy. E vent A 2 Without Mobility Control at Poor Coverage QCI Profile 1 (VoLTE Traffic): Traffic) : + ℎ ℎ2 2 < 2ℎℎ 2ℎℎ + 2ℎℎ 2ℎℎ With Mobility Control at Poor Coverage QCI Profile 1 (VoLTE Traffic): Traffic) : + ℎ ℎ2 2 < + 2ℎℎ 2ℎℎ If the UE has an active bearer with QCI1 indicating a voice bearer, a release of the UE is not allowed and the eNodeB takes no further action, that is, the UE remains in the cell and waits for another Target Good Enough, Good Coverage, Critical Coverage or possibly Search Zone measurement report. This can be changed by setting parameter allowReleaseQci1 to TRUE, but this parameter only has any effect when feature SRVCC Handover to UTRAN is not OPERABLE. Note that if the eNodeB performs a release with redirect, the default behavior in a Core Network is to remove the voice connection . 1.5.2.2 Load Based Mobility The purpose of inter-frequency load balancing is to manage uneven distribution of traffic load between different carrier frequencies. It enables efficient use of network resources on multiple carrier frequencies and achieves similar user experience independent of the carrier in use 1.5.2.2.1 FAJ 121 3009 Inter-Frequency Inter-F requency Load Balancing Load balancing is achieved by relocation of User Equipment (UE) in connected mode to carriers that are underused compared with the carrier in use. This feature distributes radio traffic load between inter-frequency cells with overlapping coverage and reduces the risk of blocking and allows more UE in an area where multiple carrier frequencies are used. VoLTE Considerations Load balancing occurs when the following conditions are met ∆ ∆ > ℎℎ > 5ℎℎ2 Where ∆ ∆ = − = 9] [ [9 ∗ In a pre-VoLTE LTE network where only one QCI profile is present, the subscription ratio is only affected by one QCI type’s contribution. Also the parameters qciSubscriptionQuanta and cellSubscriptionQuanta are probably optimized for MBB traffic only. With the introduction of VoLTE, the subscriptionRatio will change to: [ [ ∗ ] + [9 ∗ 9] = The contribution of VoLTE traffic will now affect when the load balancing condition will be met i.e. as VoLTE traffic increases, the load balancing condition will be entered earlier if no modification to the existing qciSubscriptionQuanta and cellSubscriptionQuanta parameters is made. Choosing the values of qciSubscriptionQuanta and cellSubscriptionCapacity are quite subjective depending on the behavior required in a customer network. The value of qciSubscriptionQuanta for QCI=1 (conversational voice) depends on the typical voice codec in use. For QCI=5 (default for IMS signaling), the expected bit rate is typically very low (not exceeding 3 kbps), so it can be even excluded from the calculations. The following parameter settings could be used as a starting point: Set QCI QCI 1 qciSubscriptionQuanta qciSubscriptionQuanta to a value of 100, 100, mirroring the minimum minimum expected throughput for that service at high cell load. Set QCI 9 qciSubscriptionQuanta qciSubscript ionQuanta to a value of 200, mirroring mirrori ng the minimum expected throughput for that service at high cell load. For a 10MHz frequency set cellSubscriptionCapacity cellSubscri ptionCapacity to 20000, mirroring mirrori ng an achievable downlink cell bit rate at high load. Alternatively, Alternatively, it could be decided decided to remove remove the contribution contribution of QCI 1 traffic from the load balancing calculation. This can be achieved by setting qciSubscriptionQuanta=0. When load balancing condition is entered, any UE that qualifies for load balancing will only move to the target frequency when the target cell’s RSRP is greater than a5Threshold2Rsrp. To avoid ping-pong though from load balancing and then nor mal coverage-triggered inter-frequency handover, it is recommended to set this threshold at least 10dB higher than that of a2ThresholdRsrp. In case of combination with the Automated Cell Capacity Estimation feature, the functionality of the attribute cellSubscriptionCapacity can be replaced by the Automated Automated Cell Capacity Capacity Estimation Estimation feature, which automatically determines and configures the cell capacity. The principle of configuring qciSubscriptionQuanta will then be changed. The operator can choose whether to use Automated Cell Capacity Estimation feature in Load Management features by setting useEstimatedCellCap. If the operator chooses to use this feature in Load Management features, these features will use the attribute dynCellSubscrCap (EUtranCellFDD.dynCellSubscrCap or EUtranCellTDD.dynCellSubscrCap) instead of cellSubscriptionCapacity to assess the subscription ratio. Setting the lbThreshold to a low value will prevent large bursts of load balancing. It is recommended to keep this at the default value of 3%. RECOMMENDATIONS: - Set qciSubscripti qciSubscriptionQuanta onQuanta and cellSubscript cellSubscriptionCapacity ionCapacity to values mirroring the minimum expected throughputs per service and the achievable cell but rate at high cell load. - If a QCI type is to be ignored from the load balancing calculation then set qciSubscriptionQuanta=0 - Set a5Thresho a5Threshold2Rsr ld2Rsr to a value at least 10db reater than A2 threshold When the load balancing condition is met for Inter-Frequency Load balancing, UEs are randomly selected to be moved to the target frequency. However, if we want to exclude QCI1 from performing any load based handover, the feature Service Specific Load Management can be activated. 1.5.2.2.2 FAJ 121 3047 Service Specific Load Management Using thuis feature, we can inhibit either QCI 1 or QCI9 (MBB) connections from performing a load based handover. This is controlled by the struct EUtranFreqRelation::eutranFreqToQciProfileRelation. In this struct the parameter lbQciProfileHandling will instruct which QCI profiles are allowed or not allowed for load balancing action. This parameter can have the following values: ALLOWED: If a QCI profile is configured as ALLOWED then a UE may use it (but does not have to) in order to qualify for load balancing to the target frequency. FORBIDDEN: If a QCI profile is configured as FORBIDDEN then UEs using it are not qualified for load balancing to the target frequency. REQUIRED: If one or more QCI profiles are configured as REQUIRED then only UEs using one or more of them are qualified for load balancing to the target frequency. For example, if it is required that only QCI 9 traffic is subjecedt to a load based handover then its profiles lbQciProfileHandling value would be set to REQUIRED and all other QCI profiles would be set to FORBIDDEN. Initially it would be recommended to forbid QCI1 UEs from performing excessive handover between LTE frequencies. Then in tuning and optimization stage this could be reviewed . As with Service Service Triggered Triggered Mobility, Mobility, Service Specific Specific Load Managemen Managementt introduces introduces the possibility to apply an offset to the a5ThresholdRsrp using the parameter lbA5Threshold2RsrpOffset. If QCI 1 traffic is selected as being allowed for load based handover then it’s recommended to apply the same degree of offset to lbA5Threshold2 as a2ThresholdRsrpPrimOffset. RECOMMENDATIONS: - If Service Specific Load Management is to be deployed, it’s recommended to forbid QCI 1 traffic from performing load based handover and then review this strategy in optimization phase. This is achieved by setting lbQciProfileHandling=FORBIDDEN for QCI1 profile - If Service Specific Load Management is to be deployed, and QCI 1 profile is allowed to perform load based handover, then it’s recommende d to set the value lbA5Threshold2RsrpOffset to the same value as a2ThresholdRsrpPrimOffset. 1.5.3 SRVCC HO Strategy The SRVCC Handover features enables the eNodeB to use handover as the mechanism to transfer User Equipment (UE) with voice bearers from LTE to either WCDMA or GSM; with the voice bearers being handed over to the Circuit Switched (CS) domain. 1.5.3.1 FAJ 121 2027 SRVCC to UTRAN & FAJ 121 3014 SRVCC to GERAN SRVCC Handover to UTRAN and GERAN is only to be deployed in VoLTE network. It uses the same thresholds that are used for Coverage-Triggered Session Continuity from LTE to another RAT, namely Event A2 and Event B2. Events A2 and B2 which are used for SRVCC can have QCI specific offsets applied to them using the feature Service Triggered Mobility. If the feature MultiLayer Service-Triggered Mobility is activated, events A2 and A5 can have different threshold offset values for QCIs as well as for different frequency relations. relations. This feature overrides the Service Triggered Mobility feature when both features are activated.These offsets can be either positive or negative giving flexibility in where VoLTE mobility would be performed compared to MBB mobility Event B2 Threshold (Mobility to UTRAN only shown here as example): Without Service Triggered Mobility All QCI Profiles: RSRPvng + hysteresisB2 < b2Threshold1Rsrp AND RSCPg − hysteresisB2 > b2Threshold2RscpUtra b2Threshold2RscpUtra With Service Triggered Mobility QCI Profile 1: RSRPvng + hysteresis hysteresisB2 B2 < b2Threshol b2Threshold1Rsr d1Rsrpp + b2Threshol b2Threshold1Rsr d1RsrpUtr pUtraOffs aOffset etQI AND RSCPg − hysteresi hysteresisB2 sB2 > b2Threshold2RscpUtra b2Threshold2RscpUtra + b2Threshold2RscpUtraOffset b2Threshold2RscpUtraOffsetQI Calculation formulae for the A2 and B2 thresholds With Multi-Layer Service Triggered Mobility: RECOMMENDATION: Set the Service Specific Mobility thresholds to 0 initially for QCI 1 and then tune to a positive value in the range of 2 to 6 dB based on drive test measurements and network performance. Impact on Automated Neighbour Relations for UTRAN and GERAN In networks where Release with Redirect is the mobility mechanism for IRAT mobility for MBB traffic, the UE is disconnected from LTE and redirected to the target UTRAN or GERAN frequency. SRVCC to UTRAN or GERAN will perform a handover directly to a target cell and directs the voice call to a specific cell. SRVCC to UTRAN and ANR To aid in SRVCC optimization, it is recommended to enable ANR for UTRAN with the introduction of SRVCC to UTRAN if this is not already enabled. This is done by setting the parameter AnrFunctionUtran::anrStateUtran=ACTIVATED . For SRVCC to an ExternalUtranCellFDD to be allowed, the parameter ExternalUtranCellFDD::srvccCapability must be set to either CS_ONLY_SUPPORTED or PS_AND_CS_SUPPORTED PS_AND_CS_SUPPORTED.. However, by default, an ANR created ExternalUtranCellFDD is configured as NOT_SUPPORTED. NOT_SUPPORTED . To control this behavior, a new parameter is introduced in L14A, AnrFunctionUtran::srvccPolicy.. This can be set to NOT_SUPPORTED, AnrFunctionUtran::srvccPolicy NOT_SUPPORTED , CS_ONLY_SUPPORTED or PS_CS_SUPPORTED PS_CS_SUPPORTED,, the same as ExternalUtranCellFDD::srvccCapability . Any ANR created ExternalUtranCellFDD will then its srvccCapability set the same as the value AnrFunctionUtran::srvccPolicy. Note that the value PS_AND_CS_SUPPORTED is only available if full WCDMA IRAT Handover is supported in the LTE, EPC and underlying WCDMA networks RECOMMENDATION: Enable ANR for UTRAN with the introduction of SRVCC by setting the value AnrFunctionUtran::anrStateUtran=ACTIVATED. Ensure the parameter AnrFunctionUtran::srvccPolicy is set to the appropriate action for SRVCC capability. It is recommended that this is set to at least CS_ONLY_SUPPORTED. Features to be activated in LTE RAN: SRVCC Handover to UTRAN (CS HO) Coverage-Triggered WCDMA IRAT Handover (PS HO) In order to enable PS HO to WCDMA during SRVCC, both of the above features need to be activated. Below is a case study regarding SRVCC failure due to wrong setting of srvccCapability parameter: SRVCC Failure Troubleshooting.pptx Inter-RAT offload feature can be used to hand over traffic load above a configured threshold from an over-utilized E-UTRAN cell to a configured set of UTRAN-FDD cells with extra capacity. The amount of offload to a specific target UTRAN cell is proportional proportional to the lbUtranCellOffloadCapacity parameter of that target UTRAN cell .This feature is an add-on to feature Inter-frequency Load Balancing. These two features can either be operated stand-alone, or one at a time or in combination to attain simultaneous inter-frequency load balancing and inter-RAT offload. SRVCC to GERAN and ANR If SRVCC to GERAN is to be deployed, it is recommended to enable ANR for GERAN to aid in optimization. This is done by setting the parameter AnrFunctionGeran::anrStateGsm=ACTIVATED. By default, all ExternalGeranCells are capable of at least CS support for SRVCC. PS Handover to GSM is not supported. RECOMMENDATION: If SRVCC to GERAN is to be used then it is recommended to enable ANR to GERAN. This is done by setting the parameter AnrFunctionUtran::anrStateGsm=ACTIVATED. Features and Associated Parameters: Feature s Paramete rs Data Forwarding at I ntra-LTE Handover Packet Forwarding at S1 Handover dataFwdPerQciEnabled SRVCC Handover to UTRAN/GERAN UTRAN/GERAN and and Cover Coverag age e Trigg Triggere ered d IFHO IFHO voic voicepr eprio, io,sr srvc vccC cCap apab abilit ility y ANR srvccpol icy,anrState Utran,anrStateGsm Service Triggered Mobility a1ThresholdRsrpSecOffset,a1ThresholdRsrqPrimOffset,a1ThresholdRsrqSecOffset,a2Thres holdRsrpPrimOffset,a2ThresholdRsrpSecOffset,a2ThresholdRsrqPrimOffset,a2ThresholdRs rqSecOffset,a5Threshold1RsrpOffset,a5Threshold1RsrqOffset,a5Threshold2RsrpOffset,a5T hreshold2RsrqOffset,b2Threshold1RsrpUtraOffset,b2Threshold1RsrpCdma2000Offset,b2Th reshold1RsrpGeranffset,b2Threshold1RsrqUtraOffset,b2Threshold1RsrqCdma2000Offset,b2 Threshold1RsrqGeranOffset,b2Threshold2Cdma2000Offset,b2Threshold2GeranOffset,b2Th reshold2EcNoUtraOffset,b2Threshold2RscpUtraOffset Multi-Layer Service Triggered Mobility Mobility Control at Poor Coverage Inter-Frequency Inter-Frequency Load Load Balancing Balancing Service Specific Load Management Management a1a2ThrRsrpQciOffset,a1a2ThrRsrqQciOffset,a5Thr1RsrpFreqOffset,a5Thr1RsrqFreqOffset,a 5Thr2RsrpFreqOffset,a5Thr2RsrqFreqOffset,a5Thr1R 5Thr2RsrpFreqOffset,a5Thr2RsrqFreqOffset,a5Thr1RsrpFreqQciOffset, srpFreqQciOffset, a5Thr1RsrqFreqQc a5Thr1RsrqFreqQciOf iOf fset,a5Thr2RsrpFreqQciOffse fset,a5Thr2RsrpFreqQciOffse t,a5Thr2RsrqFreqQciOffset,b2Thr1RsrpU t,a5Thr2RsrqFreqQciOffset,b2Thr1RsrpUtraFreqOffset,b traFreqOffset,b 2Thr1R 2Thr1R srqUtraFreqOff srqUtraFreqOff set,b2Thr2EcNoUtr set,b2Thr2EcNoUtraFreqOffse aFreqOffse t,b2Thr2RscpU t,b2Thr2RscpUtraFreqOffset, traFreqOffset, b2Thr1RsrpUtr b2Thr1RsrpUtraFr aFr eqQciOffse t,b2Thr1RsrqUtr t,b2Thr1RsrqUtraFreqQciOffset, aFreqQciOffset, b2Thr2EcNoU b2Thr2EcNoUtraFreqQciOffset,b2Thr2Rsc traFreqQciOffset,b2Thr2RscpUtraFr pUtraFr eqQciOffset,b2Thr1RsrpUtraFreqOffset,b2Thr1RsrqUtraFreqOffset,b2Thr2RscpUtraFreqOffs et,qciB2ThrOffsets,b2Thr1RsrpUtraFreqQc et,qciB2ThrOffsets,b2Thr1Rsr pUtraFreqQciOffse iOffse t,b2Thr1RsrqUtr t,b2Thr1RsrqUtraFreqQciOffset,b aFreqQciOffset,b 2Thr2EcN 2Thr2EcN oUtraFreqQciOffse oUtraFreqQciOffse t,b2Thr2RscpU t,b2Thr2RscpUtraFreqQciOffset,b2Thr1RsrpCdma2 traFreqQciOffset,b2Thr1RsrpCdma2000 000FreqOffse FreqOffse t,b2Thr1 RsrqCdma2000Fr RsrqCdma2000FreqOff eqOff set,b2Thr2Cdma200 set,b2Thr2Cdma2000FreqOffset,q 0FreqOffset,q ciB2ThrOffsets,b ciB2ThrOffsets,b 2Thr1RsrpCdma2 2Thr1RsrpCdma20 0 00FreqQciOffse 00FreqQciOffse t,b2Thr1RsrqCdma20 t,b2Thr1RsrqCdma2000Fr 00FreqQciOffse eqQciOffse t,b2Thr2Cdma20 t,b2Thr2Cdma2000Fr 00FreqQciOffse eqQciOffse t,b2Thr 1RsrpCdma20001xFreqOffset,b2Thr1RsrqCdma20001xFreqOffset,b2Thr2Cdma20001xFreqOf fset,b2Thr1RsrpGeranFreqOffset,b2Thr1RsrqGeranFreqOffset,b2Thr2GeranFreqOffset,qciB 2ThrOffsets,b2Thr1RsrpGeranFreqQciOffset,b2Thr1RsrqGeranFreqQciOffset,b2Thr2GeranFr eqQciOffset a1a2SearchThresholdRsrp,a1a2SearchThresholdRsrq,hysteresisA1A2SearchRsrp,hysteresisA 1A2SearchRsrq,searchEffortTime,timeToTriggerA1Search,timeToTriggerA2 1A2SearchRsrq,searchEffortTime,timeToTriggerA1Search,timeToTriggerA2Search,a2Critical Search,a2Critical ThresholdRsrp,a2CriticalThresholdRsrq,hysteresisA2CriticalRsrp,hysteresisA2CriticalRsrq,ti meToTriggerA2Critical,ueMeasurementsActiveIF,ueMeasurementsActiveUTRAN,ueMeasur ementsActiveGERAN,ueMeasurementsActiveCDMA2000 lbThreshold,lbceiling,qc lbThreshold,lbceiling,qciSubscr iSubscriptionQua iptionQuanta,c nta,cellSubscr ellSubscriptionCapa iptionCapacity city lbQciProfileHandling lbQciProfileHandling ,lbA5Threshold2 ,lbA5Threshold2Rsrp RsrpOffset Offset Parameter Settings: Settings : Parameter hysteresisA2Prim a2ThresholdRsrpPrim a2ThresholdRsrpPrimOffset hysteresisA5 Default 10 -140 0 10 AT&T GS 10 -110 to -118 0 10 Unit 0.1 dB dBm dBm 0.1dB a5Threshold1Rsrp a5Threshold2Rsrp a5Threshold1RsrpOffset a5Threshold2RsrpOffset hysteresisB2 b2Threshold1Rsrp -140 -136 0 0 10 -140 -95 to -116 -95 to -112 0 0 10 -110 to -118 dBm dBm dBm dBm 0.1dB dBm b2Threshold2RscpUtra b2Threshold1RsrpUtraOffset b2Threshold2RscpUtraOffset a1a2ThrRsrpQciOffset a5Thr1RsrpFreqOffset a5Thr1RsrpFreqQciOffset a5Thr2RsrpFreqOffset a5Thr2RsrpFreqQciOffset b2Thr1RsrpUtraFreqOffset b2Thr1RsrpUtraFreqQciOffset b2Thr2RsrpUtraFreqOffset b2Thr2RsrpUtraFreqQciOffset dataFwdPerQciEnabled_QCI1 srvccCapability srvccPolicy anrStateUtran anrStateGsm a1a2SearchThresholdRsrp lbThreshold a4ThresholdRsrp qciSubscriptionQuanta_QCI1 qciSubscriptionQuanta_QCI5 qciSubscriptionQuanta_QCI9 cellSubscriptionCapacity lbQciProfileHandling -115 0 0 0 0 0 0 0 0 0 0 0 TRUE NOT_SUPPORTED CS_ONLY_SUPPORTED DEACTIVATED DEACTIVATED -134 30 -140 1 1 1 -115 0 0 -110 to -116 0 0 0 0 0 0 0 0 TRUE CS_ONLY_SUPPORTED CS_ONLY_SUPPORTED ACTIVATED DEACTIVATED -100 to -114 60 -140 50 2 100 1000 ALLOWED 40000 (20MHz) 30000 (15MHz) 20000 (10MHz) ALLOWED dBm dBm dBm dB dB dB dB dB dB dB dB dB dBm dBm Important Parameter Settings: The following parameters should have same values for QCI 1 in the source and target cells in order to avoid volte handover failures or call drops: rlcSNLength pdcpSNLength Below is a case study regarding VoLTE HO failure issue due to the discrepancy in these parameter settings. VoLTE VoLTE HO from Huawei to Ericsson.p 1.6 Responsibility matrix Activity Input Data Provision Intra-frequency Intra-frequ ency LTE HO Strategy Design Inter-frequency Inter-frequ ency LTE HO Strategy Design SRVCC HO Strategy Design Responsible Customer/Region Customer/Regi on Team GSC India GSC India GSC India
