Key Performance Guarantee Steps For UMTS Swapping V2.0

Security Level:
Key Performance Guarantee

Steps for UMTS Swapping
2013-09-30 www.huawei.com
HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential

Contents
 Abstract
 Panorama of Standard Actions for Swapping Preparations
 Key Steps of Swapping SOP
 Performance Guarantee Deliverables for UMTS Swapping Projects
 Cases of Swapping Project Stalling Due to Poor Implementation of

Performance Guarantee Steps
HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 2

Abstract
This document is intended for customer support engineers and product support
engineers.
This document briefly describes key standard actions of peer vendors for UMTS swapping
and then elaborates performance-related key standard actions, aiming to help customer
support engineers with their high-quality UMTS swapping deliveries.
This document further provides cases to demonstrate the importance and necessity of
implementing swapping standard actions.

Contents
 Abstract
 Overview of Standard Actions for Swapping Preparations
 Tools and Materials for swapping SOP
 Swapping Cases

Panorama of Standard Actions for Swapping Preparations
Network Design for Task
Standard Actions Key Actions
UMTS Swapping ID
1 Swapping contract handshake and review 1. Understand the swapping policies specified in the contract by the customer.
1. Review the power mapping policy and power specifications.
2. Determine whether swapping types (inter-frequency, intra-frequency, cross-Iur swapping).
2 Product solution review 3. Perform networking mapping.
4. Perform capacity mapping.
5. Analyze inter-RAT interference (for inter-frequency swapping).
1. Divide clusters.
Swapping solution 2. Determine swapping sequence.
design (project) 3 Swapping plan
3. Plan swapping time points.
4. Design cluster swapping solutions (procedures, SOW, parameter mapping, and cell data migration).
1. Choose test tools.
2. Finalize DT routes.
4 Determination of acceptance standards 3. Prepare test cases. The first three activities are used to prepare DT tests.
4. Perform KPI mapping.
5. Conduct risk evaluation and re-negotiations.
5 Fallback solution design Work out fallback solutions for swapping.
1. Collect information about the live networks in terms of carriers, feeder loss, power configurations, combiners,
UMTS power mapping
6 Power matching and verification base station types, and others required for power mapping.
(site)
2. Conduct power mapping verification on sites of typical configurations.
7 Cell ID and site ID, and renaming rules 1. Re-plan the cell IDs and site IDs for the swapping.
Swapping area re-design for LA, RA, and RNC
8 1. Re-plan LA, RA, and RNC borders in the swapping area.
borders
Parameter mapping 1. Determine rules for parameter mapping.
and migration (site) 9 Parameter mapping
2. Confirm the parameter mapping rules with the customer.
10 Tool customization for parameter mapping Customize tools for parameter mapping.
1. Generate script files based on parameter mapping results.
11 Parameter data loading
2. Import the script files.
12 Tool customization for neighboring cell mapping Customize tools for neighboring cell conversion based on site conditions
Neighboring cell data
migration (site) 1. Generate script files based on parameter mapping results.
13 Data loading of neighboring cell data
2. Import the script files.
Key Performance Guarantee Steps: risk evaluation and re-negotiation, intra-frequency solution design, KPI mapping, networking mapping, capacity
mapping, power mapping, parameter mapping, and key feature mapping

Contents
 Abstract
 Detailed Analysis of Performance Guarantee Steps of swapping SOP
 Cases of Performance Guarantee Steps of swapping SOP

Key Step 1 for Performance Guarantee: Risk Evaluation and
Re-negotiation
Obtain the performance data of the original network generated within two weeks to a month from the customer, analyze the network
performance by referring to the KPI mapping formulas and compare the analysis results with the baseline KPIs of Huawei or with similar
networks. This helps evaluate the swapping risks in a comprehensive way. Simultaneously gives the method that reduce. The risk
assessment mainly involves the following several aspects: The contractual commitment analysis, project and version plan ,
coverage the risk assessment, interference risk assessment ,approval plan risk assessment, swap SOP step risk assessment , KPI
dimension risk assessment.
Acceptance KPI Monitoring KPI
As an example, if the DPA call drop rate is low, check difference between related features, for example, the DPA compressed
mode algorithm of the Nokia and Siemens Networks (NSN).
Evaluating the performance of the original network requires attention to the following points:
 Difference that may cause KPIs to fail the requirement needs to be specially focused during key feature mapping and parameter mapping.
 Record KPIs that have significant changes after the swapping during traffic analysis and ask the customer about the possible causes,
for example, whether a major network adjustment has been performed or a major event has taken place.
 Seasonal changes or major events are considered to avoid KPI deterioration periods, for example, starting days of a new term for students.
 If it is rather risky to meet the KPI requirements, seek help from the product support engineers.
Risk evaluation and re-negotiation are required throughout a swapping project. KPI risks need to be closely watched out during intra-frequency/inter-
frequency solution design, KPI mapping, parameter mapping, and other key steps.

Key Step 1 for Performance Guarantee: Risk Evaluation and
Re-negotiation
Action Tasks Tools Deliverable References LINK
1. Evaluate KPI requirements, analyze the KPI risks, and record the risky KPIs.
2. If the original KPIs are better than the Huawei KPI baseline or those of the
similar networks, the radio network optimization (RNO) engineers need to:
Discuss the KPI requirements with the customer to lower the KPI expectations.
Explain appropriate KPI ranges to the customer by referring to KPIs of other
tier-1 networks.
Propose KPI priorities and guide the customer to consider important KPIs for
URFSDT0 URFSTG010
acceptance, with other KPIs only for monitoring.
0415-KPI 13-R16
KPI re- Clarify test conditions, methods, and cases to reduce acceptance risks.
- acceptance UMTS KPI link
negotiation 3. Organize meetings with the customer for KPI re-negotiation, focusing on factors
criteria Baseline
that boil down to KPI acceptance. Such factors include:
(Template) Specification
Difference in algorithm and KPI formulas
KPI deterioration caused by capacity difference before and after swapping
KPI deterioration caused by increased network access difficulty due to power
difference before and after swapping (L2V)
Possible KPI deterioration caused by changes in networking policies, for
example, dual-carrier networking to increase network capacity (L2V).
4. Generate the deliverable: URFSDT00415-KPI acceptance criteria (Template).
 KPI re-negotiation helps significantly reduce delivery risks in some cases. For example, a total of 20 plus acceptance KPIs were
narrowed down to only five in a project, which greatly eased delivery workloads and facilitated KPI acceptance.

Key Step 2 for Performance Guarantee: Intra-
frequency/Inter-frequency Swapping Solution Design
Action Input Tools Deliverable References
Information about
Intra-frequency/Inter-frequency Intra-frequency/inter-frequency swapping UMTS Swapping Policy Guide_V3.00
frequencies and network U-Net
swapping solution design solution and Iur interworking policies Iur Interface and Multi-Vendor Internetworking Guide V2.1
coverage of a customer
No. Solution Type Suggestion Priority Condition Advantage Disadvantage

1. Requires no Iur connections with other
vendors during engineering Disadvantages for the customer:
implementation. 1. High-speed PS services are not available to PS users
Inter-frequency
The customer has 2. Avoid interference of the original networks on a GSM network.
swapping without
1 Recommended H sufficient spectral and possible negative impact caused by 2. Users in idle mode are more likely to camp on the
Iur interconnection
resources. Iur interconnections to ensure network GSM network.
requirements
performance. 3. The traffic volume of UMTS cells at the swapping
3. Has slight impact on voice service borders reduces.
experience.
1. The customer has
1. Avoid interference of the original networks
insufficient spectral
Intra-frequency to ensure network performance. 1. Iur interconnection with a peer vendor requires huge
resources.
swapping with Iur 2. Has no impact on traffic KPI of the original workload during implementation.
2 Recommended M 2. The peer vendor is
interconnection network and service experience of users 2. Iur interconnection with a peer vendor introduces
willing to coordinate
requirements if Iur interconnections are properly huge risks to network performance.
with Huawei for
handled.
swapping.
Inter-frequency 1. Has co-channel interference to impair network
swapping with Iur Not Requires no Iur connections with other performance.
3 / 　
interconnection recommended vendors during engineering implementation. 2. KPIs deteriorate at the swapping border due to co-
requirements channel interference.
Inter-frequency 1. Iur interconnection with a peer vendor requires huge
swapping with Iur Not workload during implementation.
4 / 　 None
interconnection recommended 2. Iur interconnection with a peer vendor introduces
requirements huge risks to network performance.
Prepare site-specific intra-frequency/inter-frequency swapping solutions and Iur internetworking policies to lower KPI acceptance risks.

Key Step 3 for Performance Guarantee: KPI Mapping
Formulas used by peer Updated URFSDT00155- WCDMA network

KPI
vendors and values of the None UMTS KPI Definitions and performance KPI
mapping
counters Mapping (Template) mapping
Brief description about KPI mapping formulas:

Due to difference in algorithms and implementation methodologies from peer vendors, KPI mapping
between the original network and Huawei-built network cannot be directly performed in most cases.
Otherwise, noticeable KPI acceptance risks are unavoidable. Huawei has accumulated profound experience
in KPI mapping with peer vendors through its global swapping practice and included the experience in
WCDMA Network Performance KPI Mapping to guide KPI mapping in terms of call drops, access, mobility,
and traffic for a swapping project.
Before swapping, guide the customer to adopt Huawei-favorable KPI formulas specified in the KPI
mapping document. This helps facilitate KPI acceptance after swapping.

(Algorithm Difference)
KPI mapping affected by algorithm difference: PS 0k/0k Access of NSN
 Difference description:
With the PS 0k/0k Access feature of NSN, an initial service access is implemented in two steps: A radio bear is first
established on the DCH with an initial rate of 0 kbit/s and then the radio bearer is reconfigured to the DCH or HSPA
channel after an Event 4A is triggered.
Huawei has no similar features. Therefore, a radio bearer is directly established on the DCH or HSPA channel upon
an initial service access.

 Impact analysis:
The PS 0k/0k Access feature helps greatly increase the RAB setup success rate of PS services on the NSN
networks:
1. A 0 kbit/s service requires no service admission, and no admission failure is introduced.
2. Radio bearer setup messages of the 0 kbit/s service decrease by nearly 2/3, which has low channel quality
requirements and pushes up the transmission success rate of radio bearer setup messages over air interfaces.
However, this does not improve user experience while introducing such negative impact as increased access
delays. NSN Huawei
PS 0/0k
PS 0/0k to HSPA Reconfig

 Workaround:
The PS 0k/0k feature is available since NSN RU10. Check whether this feature is activated on the NSN network to be
swapped in either of the following methods:
1. Observing signaling of the NSN network:
Enable a UE to visit a link and trace UE signaling messages on the Probe. If a radio bearer reconfiguration signaling
message is traced immediately after PDP activation, this feature is enabled.
2. Rough evaluation of the NSN network KPIs
If the RAB setup success rate of PS services stands very high (at least 99.9%), this feature is enabled.
Perform the following workarounds for swapping an NSN network with the PS 0k/0k feature enabled:
1. Encourage the customer to disable the feature before preparing benchmark KPIs. In this way, the RAB setup
success rate of PS services can be directly mapped to the baseline KPIs.
2. If the customer refuses to disable this feature, encourage the customer to modify the formula for RAB setup
success rate of PS services in a way that allows KPI mapping. he recommended NSN formula after modification
is as follows:
RB setup success rate = RAB setup success rate of PS services with PS 0k/0k enabled x RB reconfiguration
success rate
For details, see the KPI Mapping table.

Key Step 3 for Performance Guarantee: KPI Mapping (KPI
System Difference)
KPI mapping affected by KPI system difference: PS call drops of NSN include RAB Act Call
and Packet Call.
The number of normal PS call releases and abnormal PS call releases are counted by the
RAB_ACT_FAIL_PS_XXX_XXX and RAB_ACT_REL_PS_XXX_XXX parameters on the original NSN network. The
number of normal PS call releases is the sum of all the values of the RAB_ACT_FAIL_PS_XXX_XXX parameter.
By contrast, Huawei uses the VS.RAB.AbnormRel.PS and VS.RAB.NormRel.PS parameters to count the number of
normal PS call releases and abnormal PS call releases. The VS.RAB.AbnormRel.PS parameter counts all the
abnormal PS call releases.
Analysis of the actual network data and simulation tests can be performed to check whether the
RAB_ACT_FAIL_PS_XXX_XXX counter is used to count PS call drops. The RAB_ACT_FAIL_PS_XXX_XXX counter is
not used to count PS call drops. For details, see the following description.
Packet Call
PS Call and Packet Call is different. Packet call failures can drop into FACH but no count failure in PS calls in the NSN
solution.

System Difference)
and Packet Call.
In some scenarios, PS call abnormal releases are not counted into PS Call Drop Rate.
 PS RAB abnormal release:

 RAB_ACT_FAIL_PS_INTER_RADIO + RAB_ACT_FAIL_PS_BACKG_RADIO = 761
 Cell_DCH switching to Cell FACH RL failure to release PS RAB is counters
(PS_REL_RL_FAIL_XXX_XXX_XXX) x (1 – 58.66%) = 5088 x 41.36% = 2104

 The calculated result is much more than KPI counters counted from above
comparison.
 Above failure statistical result does not include:
 UE side failure: For example UE cannot send cell update message or RNC does not
receive cell update message, this case will cause abnormal release because of timer expiry
for example UE cannot select appropriate cell to send cell update message in weak
coverage area
RAB_ACT_FAIL_PS_XXX_XXX is used to count PS call drops, and abnormal PS releases in some scenarios are not
counted, which helps reduce the PS call drop rate. The Packet Call parameter of Huawei can more accurately reflect
the PS call drop rate of the DCH. The following is an example of calculating the PS call drop rate by using the packet
call:
After the NSN related failure counter is considered, the PS call drop rate reaches 0.99% instead of 0.11%.

System Difference)
and Packet Call.
 Workaround:
Make presentations to encourage the customer to use Packet Call for PS call drop rate acceptance. The PS call
drop rate is calculated by using the following formula:
Sum of [PS_REL_RL_FAIL_HS_E_INT] + [PS_REL_RL_FAIL_HS_E_BGR] + [PS_REL_RL_FAIL_HS_D_INT] + [PS_REL_RL_FAIL_HS_D_BGR] +
[PS_REL_RL_FAIL_D_D_INT] + [PS_REL_RL_FAIL_D_D_BGR] + [PS_REL_OTH_FAIL_HS_E_INT] + [PS_REL_OTH_FAIL_HS_E_BGR] +
[PS_REL_OTH_FAIL_HS_D_INT] + [PS_REL_OTH_FAIL_HS_D_BGR] + [PS_REL_OTH_FAIL_D_D_INT] + [PS_REL_OTH_FAIL_D_D_BGR] +
[PS_REL_RL_FAIL_HS_E_STRE] + [PS_REL_RL_FAIL_HS_D_STRE] + [PS_REL_RL_FAIL_D_D_STRE] + [PS_REL_OTH_FAIL_HS_E_STRE] +
[PS_REL_OTH_FAIL_HS_D_STRE] + [PS_REL_OTH_FAIL_D_D_STRE] + [PS_REL_PRE_EMP_D_D_INT] + [PS_REL_PRE_EMP_D_D_BGR] +
[PS_REL_PRE_EMP_D_D_STRE] + [PS_REL_PRE_EMP_HS_D_INT] + [PS_REL_PRE_EMP_HS_D_BGR] + [PS_REL_PRE_EMP_HS_D_STRE] +
[PS_REL_PRE_EMP_HS_E_BGR] + [PS_REL_PRE_EMP_HS_E_INT] + [PS_REL_PRE_EMP_HS_E_STRE]/Sum of [PS_REL_RL_FAIL_HS_E_INT] +
[PS_REL_RL_FAIL_HS_E_BGR] + [PS_REL_RL_FAIL_HS_D_INT] + [PS_REL_RL_FAIL_HS_D_BGR] + [PS_REL_RL_FAIL_D_D_INT] +
[PS_REL_RL_FAIL_D_D_BGR] + [PS_REL_OTH_FAIL_HS_E_INT] + [PS_REL_OTH_FAIL_HS_E_BGR] + [PS_REL_OTH_FAIL_HS_D_INT] +
[PS_REL_OTH_FAIL_HS_D_BGR] + [PS_REL_OTH_FAIL_D_D_INT] + [PS_REL_OTH_FAIL_D_D_BGR] + [PS_REL_PRE_EMP_D_D_INT] +
[PS_REL_PRE_EMP_D_D_BGR] + [PS_REL_PRE_EMP_D_D_STRE] + [PS_REL_PRE_EMP_HS_D_INT] + [PS_REL_PRE_EMP_HS_D_BGR] +
[PS_REL_PRE_EMP_HS_D_STRE] + [PS_REL_PRE_EMP_HS_E_BGR] + [PS_REL_PRE_EMP_HS_E_INT] + [PS_REL_PRE_EMP_HS_E_STRE]
[PS_REL_NORM_HS_E_INT] + [PS_REL_NORM_HS_E_BGR] + [PS_REL_NORM_HS_D_INT] + [PS_REL_NORM_HS_D_BGR] + [PS_REL_NORM_D_D_INT] +
[PS_REL_NORM_D_D_BGR] + [PS_REL_RL_FAIL_HS_E_STRE] + [PS_REL_RL_FAIL_HS_D_STRE] + [PS_REL_RL_FAIL_D_D_STRE] +
[PS_REL_OTH_FAIL_HS_E_STRE] + [PS_REL_OTH_FAIL_HS_D_STRE] + [PS_REL_OTH_FAIL_D_D_STRE] + [PS_REL_NORM_HS_E_STRE] +
[PS_REL_NORM_HS_D_STRE] + [PS_REL_NORM_D_D_STRE]
For details, see the KPI Mapping table.

(Insufficient KPI Statistics)
KPI mapping affected by insufficient statistics: The NSN method does not count all the RRC call drops.
NSN networks support RRC call drop rate measurement. However, simulation tests at site XX show that only some RRC call drops are counted on
the NSN network, as shown in the following figure:
The RRC connection release measurement (RRC.Rel.Cell) differs from the NSN RRC call drop measurement in statistical dimensions in the following
aspects:
1. The NSN network measures only CS abnormal releases, but the Huawei network measures both CS and PS abnormal releases.
2. Some CS abnormal releases are not measured on the NSN network. As shown in the figure, CS abnormal releases caused by SRB resets triggered by
an RB setup procedure (red circled) and by failed safe mode procedures are no counted. Huawei networks measure all CS and PS abnormal releases
as a whole through the RRC.Rel.Cell counter, without separately counting CS abnormal releases.
Impact analysis and workaround:
The mapping of this KPI between Huawei and NSN cannot be performed. The measurement of this KPI of NSN does not make sense and is useless in
practice. As shown in the red circle, the RRC call drop caused by an SRB reset due to an RB SETUP message delivered from the network side after a
successful RRC connection establishment is not counted. In this case, explain to the customer that the mapping failure is caused by insufficient
measurement of the RRC call drops of the NSN and encourage the customer not to use the RRC call drop rate for swapping acceptance and network
monitoring.

(Incorrect KPI Statistics)
and Packet Call.
The number of normal PS call releases and abnormal PS call releases are counted by the
RAB_ACT_FAIL_PS_XXX_XXX and RAB_ACT_REL_PS_XXX_XXX parameters on the original NSN network. The total
number of normal PS call releases is the sum of all the values of the RAB_ACT_FAIL_PS_XXX_XXX parameter.
By contrast, Huawei uses the VS.RAB.AbnormRel.PS and VS.RAB.NormRel.PS parameters to count the number of
normal PS call releases and abnormal PS call releases. The VS.RAB.AbnormRel.PS parameter counts all the
abnormal PS call releases.
Analysis of the actual network data and simulation tests can be performed to check whether the
RAB_ACT_FAIL_PS_XXX_XXX counter is used to count PS call drops. The RAB_ACT_FAIL_PS_XXX_XXX counter is
not used to count PS call drops. For details, see the following description.
PS Call and Packet Call is different according to NSN, Packet Call failure can drop into FACH but no count failure in
PS Call
Packet Call

Key Step 4 for Performance Guarantee: Networking
Mapping
Scripts of
Guide to Networking Policy Mapping for
original UMTS Networking
Networking SmartR Swapping NSN UMTS Networks
networks policy mapping
mapping NO Guide to Networking Policy Mapping for
(NSN and solution template
Swapping Ericsson UMTS Networks
Ericsson)
The tool supports automatic recognition and error correction of the user camping policy and
service bearer policy of a peer-vendor network. For example, if mutually preferential camping
policy between carriers is adopted on a network built by other vendors, ping-pong reselection
will occur, and power consumption and access success rate will be greatly affected after the
network is swapped. This tool can help swapping engineers recognize and notify them of
such problems.
The SmartRNO supports use of peer-vendor scripts to identify the peer-vendor networking policy.

Key Step 5 for Performance Guarantee: Capacity Mapping
Capacity Data of the SMART Technical Guide to Capacity Design
Capacity Mapping Resolution for Site template
mapping original network RNO for Swapping UMTS Networks
1. Collect peer-vendor
Covers
counter data. \tab 2. Sort out the 3. Import the data.
transmitted Mapping of different data.
carrier power resources requires different Sort out and analyze the data
collected in Step 1 through
(TCP), counter data and methods
the following templates. After
channel for obtaining counters. It is
the collected data is added to
element (CE), good practice to collect data the templates, the tool
Common of the original network
directly uses data in the
NodeB generated within the latest
template for mapping.
Application seven days.
Protocol
(CNBAP), 5. Check the result data.
signaling 4. Perform capacity mapping.
processing
unit (SPU),
data
processing
unit (DPU),
and interface
boards (INT)
This solution uses a capacity mapping tool to calculate the capacity requirements and provide capacity mapping solutions based on traffic volume
and models of the peer-vendor networks. This helps ensure optimum resource configuration and minimum swapping risks for the swapping.

Key Step 6 for Performance Guarantee: Power Mapping
1. Collect information about carriers, feeder loss,
MRF0046_Network Guide to Power
power configurations, combiners, and base station
Power matching Power Mapping Mapping for
types. SmartRNO
and verification Report Template Swapping UMTS
2. Work out typical scenarios of the original network to
20120930(External) Networks
perform power matching and verification.
For example, Ericsson and Huawei adopt different power configuration mechanisms. For Ericsson, the antenna port is the
reference point for power configuration, whereas Huawei uses the cabinet top as the reference point. This difference in
reference points makes it necessary to consider the antenna system loss during power mapping.
The following figure shows a TMA-equipped Ericsson base station and the reference point for power configuration.
Power mapping mainly deals with the mapping of cell power, pilot and common channel power, and radio link power
between the peer vendor and Huawei.

Key Step 7 for Performance Guarantee: Parameter Mapping
Swapping parameter Parameter Mapping Parameter

Peer-vendor scripts SmartRNO
mapping Solutions for Site XX Mapping Table
The Parameter Mapping Table covers load control parameters, power control parameters, channel configuration
parameters, mobility management parameters, terminal compatibility parameters, NE internetworking parameters, new
feature parameters, and methods for matching these parameters. The Parameter Mapping Table uses the following
format:
Mapping description:
Policy Policy description
Recommended: Parameters of this type need to be mapped before swapping by using the mapping rules.
Mandatory Parameters of this type need to be mapped before swapping by using the recommended optimization value.
Optional Parameters of this type need to be mapped before swapping based on the risk evaluation results.
Priority description:
Principle:
1. Parameters for cell selection or reselection of UEs in idle mode and parameters for timers, power control, soft handovers, inter-frequency hard handovers, inter-
RAT handovers, and state transition of UEs in idle and connected modes require high mapping priority and need to be specially focused.
2. Others that need to be explained to the customer before swapping:
 The NSN inter-RAT handover mechanism is more likely to trigger inter-RAT handovers than Huawei's (for details, see the description about NSN inter-RAT
handover mechanisms). The number of inter-RAT handovers may decrease after swapping. The workaround method is to increase the threshold of events 2D
and 2F by one to two dB.
 The Ericsson inter-RAT handover mechanism (based on event measurement) is less likely to trigger inter-RAT handovers than the inter-RAT handover
mechanism of Huawei (based on periodic measurement). This will cause the UMTS network to carry less traffic and the number of inter-RAT handover may
increase as well. The workaround method is to decrease the threshold of events 2D and 2F by one to two dB.

Key Step 7 for Performance Guarantee: Parameter
Mapping (2)
Parameter mapping is a key swapping step and parameters need to be mapped and implemented on the swapped
network in time.
 It is good practice to finish timer parameter mapping before swapping, thereby avoiding repeated explanation to the customer when each step is
performed.
 Parameters for resource control, service radio bearer (SRBs), and directed retry decisions (DRDs) have great influence on access KPIs.
 Parameters for state transition have great influence on access KPIs, call drop rate, and throughput.
The following table gives some parameters that need to be mapped as examples.
Type Parameter ID Parameter Name Parameter Description Recommended Optimization/Mapping Solution

For a BE service that has a low maximum rate, the DCCC algorithm
Uplink bit rate Empirically set to D16 during a swapping. This helps
Resource is not obviously effective yet it increases algorithm processing.
UlDcccRateThd threshold for ease network congestion and increase access
control Therefore, the traffic-based DCCC algorithm is applied to BE
DCCC success rate or HSPA throughput.
services whose maximum UL rate is greater than the threshold.
Recommended mapping solutions are as follows:
Default activation 1. If users are sensitive to the access success rate,
MIDRATERLACTTIME
SRBs time offset of DCH Default activation time offset of DCH 13.6kbit/s RLs set this parameter to 70, which equals 700 ms.
DEFOFFVAL
13.6kbit/s RLs 2. If users are sensitive to access delays, set this
parameter to 40, which equals 400 ms.
When the switch is on, the status of the UE RRC carrying HSDPA
DraSwitch=DRA_HSD services can be changed to CELL_FACH at the RNC. If a PS BE
State HSDPA state For details, see Rules for Mapping Peer-vendor
PA_STATE_TRANS_S service is carried over the HS-DSCH, the switch
transition transition Parameters.
WITCH PS_BE_STATE_TRANS_SWITCH switch should be turned on
simultaneously.
PROCESSSWITCH2= DRD rollback
DRD If the switch is turned on, the RNC supports DRD rollback during
RNC_RBSETUP_DRD during RB setup Set this parameter to 1 in DRD scenarios to increase
Algorithm RB setup. If the switch is turned off, the RNC does not support DRD
_FAIL_ROLLBACK_S (available since the RAB setup success rate.
switch rollback during RB setup.
WITCH RAN13.0)

Key Step 8 for Performance Guarantee: Key Feature
Mapping
 Reference document: Swapping Policy Guide
This document presents the difference in feature algorithm principles between Huawei and peer vendors,
the impact of the difference on swapping, and the preventive solutions for swapping. It can be used for
algorithm clarification and communication with the customer. At present, only swapping policies for
swapping NSN and Ericsson networks are available.

Mapping
Key feature mapping: Automatic neighboring cell addition algorithm of NSN
The NetAct of NSN, similar to the M2000 of Huawei, supports automatic neighboring cell addition, which is
scheduled to be available in RAN15.0. This function is different from Huawei's neighboring cell combination.
As an example, after the RU10 of NSN was swapped for operator WIND in Greece and Italy, a large number of neighboring cells were not
configured, which fails the call drop rate requirements. After other factors that could lead to the problem were excluded, the neighboring
cells were then added and the call drop rate increased to a level comparable to the original network.
Positive gains Negative gains
Automatic neighboring cell addition Improve call drop rates for CS services and other KPIs. Not found
 Workaround:
1. It is good practice to use the SmartRNO to map the neighboring cells of the original NSN network.
2. Use a neighboring cell tool, for example, U-Net, to supplement the neighboring cell configurations before the swapping starts.
3. Use the Nastar to optimize the neighboring cell configurations after the swapping is complete.
4. Provide automatic neighboring cell addition in RAN15.0 of Huawei.

Mapping
Key feature mapping: HSPA compressed mode support of NSN
The implementation principles of HSPA compressed mode are noticeably different between Huawei and NSN:
The implementation principle for the NSN HSPA compressed mode support is as follows:
1. Use event 1F and 1E to start or stop compressed mode.
2. Use the HSDPA Inter-Frequency Handover license item, and the HSDPA Mobility and CMmaster Switch parameters to
control inter-frequency handovers for HSDPA services. If HSDPA Mobility is set to 1 and CMmaster Switch is set to 0 and
77 (HSDPA inter-frequency handover) is used in RNC options, the inter-frequency handovers and the compressed mode
are supported for HSDPA services. If HSDPA Mobility is not set to 1 and CMmaster Switch is not set to 0, and 77 (HSDPA
inter-frequency handover) is not used in RNC options, the HSDPA services fall back to the DCH to allow the UE to use the
compressed mode function. In other words, if an HSDPA UE in the weak coverage area reports an event 1F, the UE will
perform a fallback procedure from a High Speed Downlink Shared Channel (HS-DSCH) to the DCH.
3. Compressed mode for HSUPA service is not supported in RU20 or later. To use the compressed mode function, the
HSDPA services must fall back from the E-DCH to the DCH. In other words, if an HSDPA UE in the weak coverage area
reports an event 1F, it will fall back from an HS-DSCH to the DCH.
4. Simulation tests conducted in Australian shows that the UEs performing the E2D procedure may fall back to the DCH
(0/0k).
The implementation principle for the Huawei HSPA compressed mode support is as follows:
1. Use event 1F and 1E to start or stop compressed mode.
2. Use the HsdpaCMPermissionInd parameter to control the compressed mode for HSDPA services.
3. Use the HsupaCMPermissionInd parameter to control the compressed mode for HSUPA services.
4. Does not support fallback to DCH (0/0k).

Mapping
If the NSN network is configured not to support compressed mode for HSDPA services, UEs in the weak coverage
areas are likely to trigger event 1F, and the HSDPA UEs consequently fall back to the DCH. This decreases the
handover success rate for HSDPA services and other network KPIs, as shown in the following table.
HSDPA HSDPA HSDPA HSDPA Call User
KPI
Throughput Traffic Users Drop Rate Experience
Gain
√ × × √ ×
Evaluation
The Huawei network supports compressed mode for HSDPA services by default, and therefore HSDPA UEs do not trigger
event 1F and fall back to the DCH. As a result, the HSDPA KPIs will easily represent huge difference before and after
swapping.
If the NSN network is configured not to support compressed mode for HSUPA services, UEs in the weak coverage areas are
likely to trigger event 1F, and the HSDPA UEs consequently fall back to the DCH. This decreases the handover success rate
for HSUPA services and other network KPIs, as shown in the following table.
HSUPA HSUPA HSUPA HSUPA Call Drop User
KPI
Throughput Traffic Users Rate experience
Gain
√ × × √ ×
Evaluation
The Huawei network supports compressed mode for HSUPA services by default, and therefore HSUPA UEs do not trigger
event 1F and fall back to the DCH. As a result, the HSDPA KPIs will easily represent huge difference before and after
swapping.
√ denotes a positive gain and ×denotes a negative gain.

Mapping
 Workaround:
Coverage-based E2D, which is already supported by the Huawei-built network, helps increase setup success rates and
decrease call drop rate for PS services. Therefore, instead disabling HSPA compressed mode of Huawei, it is good practice
to use the following workarounds:
1. Explain to the customer the difference in HSPA bearer policies between Huawei and NSN and shift the network evaluation
focus of the customer to overall PS call drop rate, instead to the call drop rate for PS R99 services and HSUPA services.
2. Huawei supports coverage-based E2D since RAN12.0. With this feature, HSUPA UEs in the weak coverage areas can fall
back to the DCH. This helps improve overall PS call drop rate, HSPA and R99 services alike. At the same time, it also
pushes up the call drop rate for R99 services. For details about how to enable coverage-based E2D, contact product
support engineers or R&D engineers. Parameter optimization needs to be performed by referring to the WCDMA RAN13.0
Network Performance Parameters for enabling this function.
3. On an NSN network, HSPA UEs may fall back to the DCH (0/0k). This does not allow data transmission or improve user
experience. On a Huawei-built network, HSPA UEs cannot fall back to the DCH (0/0k). In this case, the original network
performance is not achievable even if the coverage-based E2D is enabled. Therefore, it is good practice to shift the
network evaluation focuses of the customer to the over PS call drop rate.

Mapping
Key feature mapping: call reestablishment of NSN
The RRC Re-establishment for Real Time Services feature, which is similar to the active reestablishment feature of Huawei,
is newly provided in the RU10 of NSN. Following is an excerpt of the NSN feature description:
Feature RAN1730: RRC re-establishment for real time services is automatically available after RU10 software installation if
the T314 parameter is set. The feature is active when the parameter T314 has a value larger than zero.
In a site, the active reestablishment function was activated on the original NSN network. As a result, the call drop rate
decreased from 0.6% to 0.3%.
In version earlier than NSN RU10, the active reestablishment time for CS services is controlled by T313 + T314 + T302 x
n302. A simulation test on Vodafone network in Italy shows that the active reestablishment time of the RN5.0 of the NSN
RU20 is controlled by T313 + T314 + T313. Yet, the active reestablishment time in Huawei RAN13.0 is controlled by the
reserved parameter RsvdPara2.
Impact analysis:
The active reestablishment function helps greatly decrease call drop rate caused by sudden loss of signals. For example,
when a user is driving through a signal-free tunnel, call drop occurs due to transient signals loss in this short period.
However, the active reestablishment can prevent call drops in such scenarios.
At the same time, this function also has some problems:
1. This function prolongs the mute duration for circuit switched (CS) services to about 8 to 16s. Although calls are
reestablished, the end users may terminate the calls due to long mute duration. This is not a common call drop in traffic
measurement, but it does not improve service experience of these users.
2. This function helps decrease the call drop rate caused by transient signal loss. However, transient signal loss may be
caused by network faults. In this sense, this function serves only as a workaround and may cover the real problems. This
is not helpful in network optimization.

Mapping
Key feature mapping: call reestablishment of NSN
 Workaround:
The NSN solution uses T314 and T315 to control call reestablishment. On the original NSN network, if T314 is not set to 0
and RU10 or later is used, active call reestablishment for CS services may be enabled. If T315 is not set to 0 and RAS06 or
later is used, active call reestablishment for PS services may be enabled. If this function is enabled on the original NSN
network, use the following two workarounds:
1. Persuade the customer to disable this function before measuring the benchmark KPIs of the original network. This is
because active call reestablishment not only prolongs mute duration but also covers a real network problem, which affects
network optimizations.
2. HUAWEI support active reestablishment and UE SRB reset reestablishment function, please follow Features documents
to active this function. During network swapping, the Parameter Mapping Table (Ericsson W11, NSNRU20, and ALU
UA5.1-Huawei V900R014_20121031) is required to optimize the configurations of the related parameters.
Points to consider when enabling the active call reestablishment are as follows:
In RN5.0 of NSN RU20, the active call reestablishment time is controlled by T313, T314, and T313. If the customer insists on
the use of active call reestablishment in a swapping project, the active reestablishment timers of Huawei and NSN generally
need to be mapped. The NSN timer (generally about 8s) is shorter than Huawei timer. Simulation tests show that NSN uses
active call reestablishment in more scenarios than Huawei. Therefore, the NSN timer parameters are mapped directly and
the call drop rate may increase after swapping. In this sense, direct mapping is not recommended. For details about the
timer settings, see the Call Re-establishment sheet in the parameter mapping table (Ericsson W11, NSNRU20, and ALU
UA5.1-Huawei V900R014_20121031).

Contents
 Abstract
 Swapping Cases

Templates of Performance Guarantee Deliverables for
UMTS Swapping Projects
Complete and consistent information input is required for common swapping projects and major
swapping projects that require joint guarantee efforts of both customer support engineers and R&D
engineers.
The template of performance guarantee deliverables for UMTS swapping projects is prepared based
on the swapping SOP and the SOP implementation. The implementation of all the key steps is then
analyzed and summarized in accordance with the template. By doing so, a standardized information
platform can be built for R&D swapping guarantee engineers, problem troubleshooting engineers,
and technical researchers. At the same time, the template standardizes problem solving operations
so that all problems are tackled in the most efficient fashion.
U-SwappingPerf
ormanceGuaranteeTemplate

Contents
 Abstract
 Swapping Cases

Swapping Case: Access in KPI Mapping
Case 1: PS RAB setup success Rate Failed to Meet the Requirement Caused by Incomplete Mapping
Due to KPI Algorithm Difference
 Problem description:
In swapping project P, parameter mapping is required between Huawei and NSN. The KPI data provided by the customer
shows that the PS RAB setup success rate of the original NSN network stands as high as 99.9x%. This puts acceptance of
the swapped network at great risks.
 Cause analysis:
The original network uses the NSN RU 20 in which the PS 0k/0k feature is already incorporated. The PS RAB setup
success rate provided by the customer is actually obtained after the PS 0k/0k feature is used.
sum([RAB_ACC_COMP_PS_INTER] + [RAB_ACC_COMP_PS_BACKG])/sum([RAB_STP_ATT_PS_INTER] +
[RAB_STP_ATT_PS_BACKG])
In opposition to the PS RAB setup success rate measured by Huawei, this KPI measured by the NSN does not reflect the
true PS RAB setup success rate. Therefore, a modification of the above formula to the following one is recommended:
<RAB setup success rate of PS services with PS 0k/0k enabled>* <RB reconfiguration success rate>
The PS RAB setup success rate used by NSN and Huawei has different meanings. If mapping were performed by using
the NSN formula, this KPI would fail to meet the requirement after the network is swapped.
 Solution:
Explain to the customer the real meaning of the PS RAB setup success rate measured by NSN and Persuade the
customer to allow mapping based on the modified formula. The customer agreed the mapping based on the modified
formula and to allow a certain margin during acceptance of this KPI.

Swapping Case: Access in Parameter Mapping
In a swapping project G in country Y, the PS RAB setup success rate keeps running at a low level of about 98%, which is
below the required value after the swapping is complete.
 Cause analysis:
Traffic statistics analysis shows that PS RAB access failures are mainly caused by physical channel failures and no replies
of UEs during the RB setup procedure, among which 77% are caused by physical channel failures. Therefore, this problem
is probably caused by the DRD policy. The original NSN network uses the RRC-based DRD policy, which is favorable to
the PS RAB setup success rate. Yet, Huawei networks support only the RAB-based DRD policy, which is not so favorable
to this IKPI.
Then, the RAB DRD statistics are analyzed, finding that the DRD success rate is almost the same as the RAB setup
success rate. Therefore, it is certain that the PS RAB establishment failures are hugely caused by DRD failures.

The RRC-based DRD policy adopted by the NSN is favorable to the PS RAB setup success rate that cannot
be achieved by the RAB DRD policy used by Huawei.
 Solution:
Protective measures for possible RAB DRDs are adopted for the swapped network. If a DRD failure occurs
during the RB setup procedure, DRD rollback is performed and the RB setup is performed again, and the
first DRD failure is not measured as an access failure. This helps increase the PS RAB setup success rate.
Check the status of the DRD rollback switch on the swapped network, finding that this switch is not turned on
(which is inconsistent with the swapping SOP).
The DRD rollback during the RB setup procedure is then enabled. The PS RAB establishment rate increases noticeably
and is even higher than that on the original network.

Case 3: CS/PS RRC/RAB Access KPI Deterioration Due to Incomplete Parameter Mapping
During an Ericsson network swapping project N in country O, the access success rate sharply decreases
from 99.9X% to 2X%-7X% for all services. The customer even warns of a swapping rollback requirement.
 Cause analysis:
Traffic statistics analysis shows that the access success rate deterioration is mainly caused by a large
number of RRC and RAB access failures due to CE congestion in the uplink.
As a solution to easing CE congestion, the guaranteed bit rate (GBR) and the initial access rate are lowered,
the HSPA state transition switch is turned on, and the dynamic CE is enabled. As a result, the peak-hour
access success rate increases to above 99.X%.
The optimized and recommended values for the parameters used in the optimization measures are provided
in the swapping SOP. Unfortunately, these measures are not fully implemented before the swapping,
causing such event-level KPI deterioration.
The swapping SOP are not truly implemented, which invites doubts of the customer on the product
capability and affects follow-up swapping procedures.
 Solution:
Before swapping a network, parameter mapping, especially the parameter optimization, specified in the
swapping SOP must be performed.

Case 4: iPad Disconnected from Network and Failed to Carry PS Services Caused by Incomplete
Parameter Mapping
The customer complains that iPad users at site O, country A are frequently disconnected from the network and
consequently cannot perform any PS service.
 Cause analysis:
Signaling tracing on the RNC and CN sides shows that the CN sends RAU reject messages because the RNC does not
respond to the context request messages from the CN.
Signaling tracing on the RNC side shows that the RNC does not respond to the context request message from the CN
during the RB reconfiguration of CELL_FACH-to-CELL_PCH.
Further analysis shows that the RB reconfiguration timer is set to 60s (RBRECFGRSPTMR=60000), which is far greater
than the baseline value and common value (10s).
 Root cause identification:
In poor coverage scenarios, a UE does not respond to the RB reconfiguration message and the RNC waits for 60s. The
state machine of the RNC stays unstable and does not process the received context requests, causing abnormal timeout
on the CN. At the same time, the RNC does not release the Iu interface for a long time, causing call drop of the UE. Then,
the UE initiates access to the GSM network but is rejected by the CN of GSM.
An inappropriate setting of a common parameter wastes as long as one month to troubleshoot the incurred problem.
 Solution:
Before swapping a network, parameter mapping, especially the parameter optimization, specified in the swapping SOP
must be performed.

Case 5: RRC Establishment Success Rate Failed to Meet the Requirement Due to Algorithm Difference
in Handling Abnormal Terminals
During an NSN network swapping in country N, the onsite engineer reports wide fluctuation of the RRC
access success rate, with low values in certain periods of time, putting the acceptance at risks.
 Cause analysis:
The PCHR analysis for the network shows that there are TOP N terminals that keep sending the RRC
CONNECT REQ messages without responding to the RRC SETUP messages from the network side. As a
result, the RRC success rate stays at a low level at the site with such terminals.

Case 5: RRC Establishment Success Rate Failed to Meet the Requirement Due to Algorithm Difference
in Handling Abnormal Terminals
 Cause Analysis (continued):
Simulation tests are performed by simulating the behaviors of the terminals on the NSN network. The results show that the
NSN network can handle transient, consistent RRC access failures and such a failure is not included in RRC access
attempt data and RRC access failure data. Namely, only consistent RRC access failures that occur within a longer interval
are recorded for KPI calculation. Based on conjecture, the RRC access failures within an interval of 15s are considered as
a single RRC access failure. Instead, RRC access failures of an interval of longer than 15s are counted. Besides, the
interval time can be configured through a waiting timer.
The algorithm for handling such abnormal terminals helps increase the RRC establishment success rate.
 Solution:
Explain to the customer the difference in algorithm for handling abnormal terminals and promise a solution timetable for
this scenario to the customer.

Swapping Case: Call Drop in KPI Mapping
Case 6: PS CDR KPI Risks Caused by Incomplete Mapping Due to Incomplete KPI Statistics
In a swapping project Y, the PS call drop rate of the original NSN network stands at a very high level according to the
formula provided by the customer, which put the project acceptance at risks.
Formula for PS call drop rate on the original NSN network:
PS DCR = 100% x (SUM(RAB_ACT_FAIL_PS_INTER_TRANS + RAB_ACT_FAIL_PS_BACKG_TRANS + RAB_ACT_FAIL_DUE_BTS_PS_INTERA + RAB_ACT_FAIL_DUE_BTS_PS_BACKG +
RAB_ACT_FAIL_PS_DATA_CALL_INTERA_CLASS_DUE_INTEGR_CK + RAB_ACT_FAIL_PS_DATA_CALL_BACKG_CLASS_DUE_INTEGR_CK + RAB_ACT_FAIL_DUE_IU_PS_INTERA +
RAB_ACT_FAIL_DUE_IU_PS_BACKG + RAB_ACT_FAIL_DUE_IUR_PS_INTERA + RAB_ACT_FAIL_DUE_IUR_PS_BACKG + RAB_ACT_FAIL_DUE_RNC_PS_INTERA +
RAB_ACT_FAIL_DUE_RNC_PS_BACKG + RAB_ACT_FAIL_DUE_RADIO_INT_PS_INTERA + RAB_ACT_FAIL_DUE_RADIO_INT_PS_BACKG + RAB_ACT_FAIL_DUE_UE_PS_INTERA +
RAB_ACT_FAIL_DUE_UE_PS_BACKG)/SUM(RAB_ACT_REL_PS_INTER_HHO + RAB_ACT_REL_PS_INTER_ISHO + RAB_ACT_REL_PS_BACKG_HHO + RAB_ACT_REL_PS_BGR_ISHO +
RAB_ACT_FAIL_PS_INTER_TRANS + RAB_ACT_FAIL_PS_BACKG_TRANS + RAB_ACT_FAIL_DUE_BTS_PS_INTERA + RAB_ACT_FAIL_DUE_BTS_PS_BACKG +
RAB_ACT_FAIL_PS_DATA_CALL_INTERA_CLASS_DUE_INTEGR_CK + RAB_ACT_FAIL_PS_DATA_CALL_BACKG_CLASS_DUE_INTEGR_CK + RAB_ACT_FAIL_DUE_IU_PS_INTERA +
RAB_ACT_FAIL_DUE_IU_PS_BACKG + RAB_ACT_FAIL_DUE_IUR_PS_INTERA + RAB_ACT_FAIL_DUE_IUR_PS_BACKG + RAB_ACT_FAIL_DUE_RNC_PS_INTERA +
RAB_ACT_FAIL_DUE_RNC_PS_BACKG + RAB_ACT_FAIL_DUE_RADIO_INT_PS_INTERA + RAB_ACT_FAIL_DUE_RADIO_INT_PS_BACKG + RAB_ACT_FAIL_DUE_UE_PS_INTERA +
RAB_ACT_FAIL_DUE_UE_PS_BACKG + RAB_ACT_REL_DUE_SRNC_RELOC_PS_INTERA + RAB_ACT_REL_DUE_SRNC_RELOC_PS_BACKG +
RAB_ACT_COMP_PS_DATA_CALL_INTERA_CLASS + RAB_ACT_COMP_PS_DATA_CALL_BACKG_CLASS))
 Cause analysis:
The calculation formula is not appropriate
because the call drop rate in some scenarios is
not counted.
This affects the acceptance of PS call drop
rate of the swapped network.
 Solution:
Persuade the customer to agree to calculate
the call drop rate through the Huawei-provided
formula.

Swapping Case: Call Drop in Parameter Mapping
Case 7: HSPA and R99 Call Drop Distribution Changes Caused by Incomplete Parameter Mapping
Due to Algorithm Difference
After an NSN network swapping project O is completed, the call drop rate of HSUPA services increases, but the call
drop rate of PS services decreases in multiple clusters.
 Cause analysis:
The NSN product documentation and simulation tests of existing NSN networks show that HSUPA UEs in the weak
coverage area will fall back to the R99 channel before starting the compressed mode in the NSN RU20. In other
words, the NSN RU20 does not support the compressed mode for HSUPA services, and the call drops of HSUPA
services are considered being contributed by R99 services.
The call drop rate of HSUPA services increases in the weak coverage area of the swapped network.
 Solution:
Explain to the customer the algorithm difference and that the PS call drop rate actually decreases on the swapped
network.
Case 8: Call Drop Rate Increased Due to Algorithm Difference in Composite Service Bearer Policy
After an NSN network is swapped, the CS call drop rate increases in multiple clusters as compared to the original network.
 Cause analysis:
On the NSN network, the rate of composite services is reset to 0 K byte in peak hours and to 384 K bytes in off-peak
hours. It is assumed that certain function is enabled to limit the rate of PS services based on cell loads. After the swapping
is finished, channel fallback for composite services and rate limiting are not used.
The difference in bearer policy of composite services leads to increased CS call drop rate after swapping.
 Solution:
The bearer policy of composite services is changed onsite, and the CS call drop rate decreases by 0.09%.

Case 9: CS and PS Call Drop Rate Failed to Meet the Requirement Caused by Absence of Matching and
Verification of Power Parameters
After an Ericsson network is swapped in project M, the CS and PS call drop rate does not meet the requirement and the
HSPA traffic increases sharply.
 Cause analysis:
The original network has been subject to elaborate optimization by Ericsson for about 5 to 6 years. As a result, the pilot
power and maximum transmit power, measured at the cabinet top, are different among cells. During parameter mapping, a
generalized mapping policy is used, which leads to increases in the pilot power and maximum transmit power.
Due to improper power mapping, the transmit power of cells increases, which pushes up the PS traffic. As a result, the
CS and PS call drop rates are affected.
 Solution:
Match the pilot power and cell power of the original network.

Swapping Case: Data Transmission in KPI Mapping
Case 10: HSDPA Traffic Decreased After the Swapping Caused by Incomplete Parameter Mapping Due
to KPI System Difference
After an Ericsson network is swapped in project N, the traffic monitoring for HSDPA, HSUPA, and R99 services shows that
the HSDPA traffic decreases by 10% to 15% in POC clusters.
 Cause analysis:
The formula of the original and swapped networks is applicable to traffic calculation at the MAC and RLC layers,
respectively. Iub-based calculation formula is not used to map the KPIs between Huawei and Ericsson (which does not
meet the requirements of the swapping SOP).

Case 10: HSDPA Traffic Decreased After the Swapping Caused by Incomplete Parameter Mapping Due
to KPI System Difference
Take for HSUPA services as an example. Analysis of traffic data of the original network shows that the HSUPA traffic
measured at the MAC-e layer is 6.3% higher than that measured at the Iub interface. Further analysis shows that the Iub-
collected traffic is 9.9% higher than that measured at the RLC layer. Therefore, the HSUPA traffic is measurably lower than
the original network.
 Solutions:
1. Explain to the customer the difference of measurement points, and map the parameters between the original and
swapped networks by using the Iub-based calculation method as required by the swapping SOP.
2. Use the Iub-based formula to calculate the traffic again, showing that the HSDPA traffic is slightly higher and the total
traffic of HSDPA and downlink R99 services are at the same level as compared to the original network.

Case 11: HSDPA MAC-hs Efficiency Decreased After the Swapping Caused by Incomplete Parameter
Mapping Due to KPI System Difference
After an Ericsson network is swapped in a project, the HSDPA MAC-hs efficiency is about 10% lower than the original
Ericsson network.
 Cause analysis:
The statistic scenario of this counter is different between Huawei and Ericsson, which is unfavorable to the counter values
of Huawei.
Formula of Ericsson:
(100% x pmNoActiveSubFramesSpiXX)/(pmNoActiveSubFramesSpiXX + pmNoInactiveRequiredSubFramesSpiXX)
In this formula, an XX stands for an SPI ranging from 00 to 15.
Formula of Huawei:
(VS.DataTtiRatio.Mean –VS.HSDPA.InactiveDataTtiRatio.Mean)/VS.DataTtiRatio.Mean
In the Ericsson formula, the pmNoInactiveRequiredSubFrames counter only measures HSDPA UE queues in the
scheduling candidate set. The MAC-hs scheduler does not schedule the HSDPA UEs in the 16 scenarios (identified
together with the customer). Therefore, these UEs are not measured for calculating the MAC-hs HSUPA efficiency, among
which the HSUPA UEs with unreliable uplink quality are included.

Case 11: HSDPA MAC-hs Efficiency Decreased After the Swapping Caused by Incomplete Parameter
Mapping Due to KPI System Difference
In RAN13.0, the ratio of the time when at least one HSDPA UE in a cell has data stored to transmit in the queue buffer to
the total time within a measurement period is measured, and the HSUPA UEs that are not in the scheduling candidate set
are counted. Therefore, the statistical method is unfavorable to Huawei. Analysis of the live network data shows that above
80% HSUPA UEs are not scheduled due to unreliable uplink quality.
 Solutions:
1. Explain to the customer the difference and perform KPI mapping by strictly following the swapping SOP.
2. The VS.HSDPA.ScheInactiveDataTtiRatio.Mean counter is added and the following formula is used in RAN14.0 to match
the Ericsson calculation method.
HSDPA efficiency = (VS.DataTtiRatio.Mean – VS.HSDPA.InactiveDataTtiRatio.Mean)/(VS.DataTtiRatio.Mean –
VS.HSDPA.InactiveDataTtiRatio.Mean + VS.HSDPA.ScheInactiveDataTtiRatio.Mean)

Swapping Case: Data Transmission in Parameter Mapping
Case 12: Retransmission Rate on the Air Interface for HSDPA Services Increased After Swapping Due to
Algorithm Difference
After an Ericsson network is swapped in project N, the retransmission rate on the air interface for HSDPA services is about
5% to 6% higher than the original Ericsson network.
 Cause analysis:
1. The KPI calculation formulas are matched.
2. Algorithm difference 1:
According to the Ericsson document description, if the available power is greater than that required for the transport format
and resource combination (TRFC) of the HS-PCSCH, the remaining power will be allocated to the HSDPA channels that
are already used by the scheduled UEs to transmit data. This algorithm helps better control the BLER, but is not
available before RAN14.0 of Huawei.
3. Algorithm difference 2:
The TFRC policy adopted by Ericsson is more conservative than that of Huawei. Therefore, the transport block of a smaller
size is more likely to be selected, which helps better control the BLER. However, this policy may be not the optimum to
maximize the throughput. Simulation tests conducted in Hungary have shown that the transport block selected for has a
smaller size in Ericsson's TFRC policy than that in Huawei's TFRC policy.
Vendor

Case 12: Retransmission Rate on the Air Interface for HSDPA Services Increased After Swapping Due to
The TFRC policy adopted by Ericsson is more favorable to control the BLER, but may be not the most favorable to the
throughput.
 Solutions:
1. Explain to the customer that the difference in HSDPA retransmission rate is caused by the TFRC algorithm difference.
2. Explain to the customer that the BLER is an intermediate counter and that a high HSDPA retransmission rate does not
necessarily mean low HSDPA throughput. In this sense, a direct HSDPA retransmission comparison has little bearing. It
is good practice to ask the customer to focus on the counter that directly boils downs to the ultimate result.

Case 13: HSDPA Throughput Failed to Meet the Requirement Due to Incomplete Parameter Mapping and
After an ALU network is swapped in project V, the HSDPA throughput of cells in above 50% clusters is decreased. In some
clusters, the difference goes as far as about 10%.
 Cause analysis:
1. Parameter mapping
 The HSDPA parameters for the dual-carrier networking are not appropriately mapped (the HSDPA is disabled in the
cell using carrier F1 on the original network, but is enabled on the swapped network.
 The power mapping does not strictly follow the cell-level mapping principle (the Alcatel-Lucent uses the antenna port
as the power reference point, yet Huawei uses the cabinet top as the power reference point).
2. Algorithm difference:
 Difference in the State Transition Algorithm
The customer-provided information demonstrates that the Alcatel-Lucent uses the throughput as a criterion
for state transition of UEs. Following is an excerpt of the customer-provided information.
When UE is in the DCH state, RNC monitors UL and DL throughput with sliding window of 500 milliseconds; if
throughput is below 8 kbit/s, low activity is pointed out; if low activity persists for 10 sec in case of DCH-DCH, 16 sec in
case of DCH-HSDPA and 25 sec in case of EDCH-HSDPA, RNC reconfigures UE to cell FACH state.

Case 13: HSDPA Throughput Failed to Meet the Requirement Due to Incomplete Parameter Mapping and
Algorithm difference:
 HSDPA remaining power appending algorithm (not available in RAN14.0)
 RLC processing difference at Layer 2
With the RLC processing mechanism used by Huawei, if RLC polling is triggered before the POLL Prohibit Timer expires,
a packet data unit (PDU) is immediately retransmitted and the bit is set to POLL after the POLL Prohibit Timer expires if
the RLC polling is not confirmed. The RLC processing mechanism of Alcatel-Lucent rules that a POLL bit is directly
attached to a PDU, regardless of the status of the POLL Prohibit Timer.
 Solutions:
1. Parameter mapping is performed by strictly following the principle of cell-level mapping before the swapping.
2. Explain to the customer the difference in the state transition and HSDPA remaining power appending algorithms.
Optimize the parameter configurations of the swapped network to match the original network as much as possible (1%-
3%) and promise to provide similar algorithms in a future version.
3. Explain to the customer the difference in RLC processing mechanism. Disable the POLL Prohibit Timer to match the
original network configurations as much as possible (2%-4%).
The preceding methods can be used to help the cell HSDPA throughput to meet the requirement.

Case 14: Number of HSUPA UEs Increased Sharply After Swapping Due to Incomplete Parameter
Mapping and Algorithm Difference
After an Ericsson network is swapped in project N, the number of HSUPA UEs increases by about 70% based on cluster-
level statistics.
 Cause analysis:
1. The maximum number of HSUPA UEs is set to 16 on the original network (maxNumEulUsers), but it is set to 40 on the
swapped network (MaxHsupaUserNum).
2. The trigger mechanism for state transition from HS-DSCH to FACH is difference before and after swapping. For details,
see the Algorithm Difference section.
3. The state transition timer parameters (BeH2FStateTransTimer and BeE2FStateTransTimer) are mapped to the original
network.
A sharp increase in the number of HSUPA UEs results in excessive uplink resources, which imposes excessive heavy
loads on the uplink and consequently affects the network KPIs and HSUPA throughput.
 Solutions:
1. Perform parameter mapping according to the swapping SOP to match the parameter configurations of the original
network as much as possible.
This helps make the number of HSUPA UEs on the swapped network comparable to the original network.

Swapping Case: Mobility in KPI Mapping
Case 15: Inter-RAT Handover Success Rate Risky to Meet the Requirement Caused by Incomplete KPI
Mapping Due to Incorrect KPI Statistics of the Original Network
After an NSN network is swapped at a site, the inter-RAT handover success rates for CS and PS services, which are
obtained through the customer-provided formulas, put the acceptance at risks.
 Cause analysis:
The KPI formula of the NSN is as follows:
Inter-RAT handover success rate for CS services of the original NSN network = 100% x
sum(SUCC_IS_HHO_UL_DCH_Q_RT + SUCC_IS_HHO_UE_TRX_PWR_RT + SUCC_IS_HHO_DL_DPCH_PWR_RT +
SUCC_IS_HHO_CPICH_RSCP_RT + SUCC_IS_HHO_CPICH_ECNO_RT + SUCC_IS_HHO_IM_IMS_RT +
SUCC_IS_HHO_EMERG_CALL + SUCC_IS_HHO_LB_CAPA_DL_RT + SUCC_IS_HHO_LB_CAPA_UL_RT +
SUCC_IS_HHO_LB_PRX_TOT_RT + SUCC_IS_HHO_LB_PTX_TOT_RT + SUCC_IS_HHO_LB_RES_LIM_RT +
SUCC_IS_HHO_LB_RSVR_SC_RT + SUCC_IS_HHO_SB_RT + SUCC_IS_HHO_WPS_RT + SUCC_GANHO_AMR_RT +
SUCC_ISHO_CELL_SHUTDOWN_RT + SUCC_ISHO_CELL_BLOCK_RT)/sum(IS_HHO_ATT_UL_DCH_Q_RT
+IS_HHO_ATT_UE_TRX_PWR_RT +IS_HHO_ATT_DPCH_PWR_RT +IS_HHO_ATT_CPICH_RSCP_RT
+IS_HHO_ATT_CPICH_ECNO_RT +IS_HHO_ATT_IM_IMS_RT + IS_HHO_ATT_EMERG_CALL
+IS_HHO_ATT_LB_CAPA_DL_RT + IS_HHO_ATT_LB_CAPA_UL_RT +IS_HHO_ATT_LB_PRX_TOT_RT +
IS_HHO_ATT_LB_PTX_TOT_RT + IS_HHO_ATT_LB_RES_LIM_RT + IS_HHO_ATT_LB_RSVR_SC_RT +
IS_HHO_ATT_SB_RT +IS_HHO_ATT_UL_DCH_WPS_RT +ATT_GANHO_AMR_RT +
ATT_ISHO_CELL_SHUTDOWN_RT +ATT_ISHO_CELL_BLOCK_RT – IS_HHO_ATT_2ND_BEST_CELL_RT -
IS_HHO_ATT_3RD_BEST_CELL_RT)

Swapping Case: Mobility in KPI Mapping
Case 15: Inter-RAT Handover Success Rate Risky to Meet the Requirement Caused by Incomplete KPI
Mapping Due to Incorrect KPI Statistics of the Original Network
According to the NSN counter documents, the IS_HHO_ATT_2ND_BEST_CELL_RT and
IS_HHO_ATT_3RD_BEST_CELL_RT counters measure the number of attempts to hand over to the second and third
cells, respectively, after the attempt to hand over to the first cell fails in an inter-RAT MR that contains three cells.
However, the number of inter-RAT handover attempts and successful inter-RAT handovers triggered in various conditions
are counted according to the signaling procedure. Therefore, the number of attempts to hand over to the second and third
cells is counted repeatedly.
 Solution:
The KPI formula used by NSN is modified so that the inter-RAT handover KPIs are successfully accepted.

Swapping Case: Mobility in Parameter Mapping
Case 16: Success Rate of HSPA Serving Cell Changes Failed to Meet the Requirement Due to Algorithm
Difference and Incomplete Parameter Mapping
After an Ericsson network is swapped at site N, the success rate of HSDPA serving cell changes is 99.85%, lower than the
original 99.97%.
 Cause analysis:
According to the Ericsson feature document, the HSPA serving cell change is triggered by the RSCP. In the Huawei's
solution, it is triggered by the Ec/No. The Ec/No is more volatile than the RSCP.
 Solution:
The HYSTFOR1D parameter is reconfigured from 8 to 4 and the TRIGTIME1D parameter is reconfigured from 640 to 1280.
Success rate of serving cell changes

Note
The privacy-related information may be anonymity for user's privacy protection

Thank you
www.huawei.com

Key Performance Guarantee Steps For UMTS Swapping V2.0

Uploaded by

Copyright:

Available Formats

You might also like

Key Performance Guarantee Steps For UMTS Swapping V2.0

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Key Performance Guarantee Steps For UMTS Swapping V2.0

Uploaded by

Copyright:

Available Formats

Security Level:

Key Performance Guarantee

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential

 Panorama of Standard Actions for Swapping Preparations

 Key Steps of Swapping SOP

 Performance Guarantee Deliverables for UMTS Swapping Projects

 Cases of Swapping Project Stalling Due to Poor Implementation of

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 2

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 3

 Panorama of Standard Actions for Swapping Preparations

 Overview of Standard Actions for Swapping Preparations

 Tools and Materials for swapping SOP

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 4

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 5

 Panorama of Standard Actions for Swapping Preparations

 Detailed Analysis of Performance Guarantee Steps of swapping SOP

 Performance Guarantee Deliverables for UMTS Swapping Projects

 Cases of Performance Guarantee Steps of swapping SOP

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 6

Acceptance KPI Monitoring KPI

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 7

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 8

No. Solution Type Suggestion Priority Condition Advantage Disadvantage

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 9

Formulas used by peer Updated URFSDT00155- WCDMA network

Brief description about KPI mapping formulas:

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 10

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 11

PS 0/0k to HSPA Reconfig

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 12

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 13

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 14

 PS RAB abnormal release:

(PS_REL_RL_FAIL_XXX_XXX_XXX) x (1 – 58.66%) = 5088 x 41.36% = 2104

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 15

For details, see the KPI Mapping table.

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 16

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 17

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 18

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 19

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 20

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 21

Swapping parameter Parameter Mapping Parameter

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 22

Type Parameter ID Parameter Name Parameter Description Recommended Optimization/Mapping Solution

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 23

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 24

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 25

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 26

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 27

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 28

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 29

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 30

 Panorama of Standard Actions for Swapping Preparations

 Detailed Analysis of Performance Guarantee Steps of swapping SOP

 Performance Guarantee Deliverables for UMTS Swapping Projects

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 31