Massive Events Guideline: Huawei Infrastructure

Qualcomm Technologies, Inc.
Claro Peru, March of 2015
Massive Events
Guideline
Huawei Infrastructure
Confidential and Proprietary – Qualcomm Technologies, Inc. | MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION 80-XXXX-X Rev. C 1
Qualcomm Global Services, Inc.
5775 Morehouse Drive
San Diego, CA 92121
U.S.A.
© 2013 Qualcomm Global Services, Inc.

All rights reserved.
NO PUBLIC DISCLOSURE PERMITTED: Please report postings of this document on public servers or websites to: DocCtrlAgent@qualcomm.com.
Restricted Distribution. Not to be distributed to anyone who is not an employee of either Qualcomm or its subsidiaries without the express approval
of Qualcomm’s Configuration Management.
Not to be used, copied, reproduced, or modified in whole or in part, nor its contents revealed in any manner to others without the express written
permission of Qualcomm Global Services, Inc.
Qualcomm is a trademark of QUALCOMM Incorporated, registered in the United States and other countries. All QUALCOMM Incorporated trademarks
are used with permission. Other product and brand names may be trademarks or registered trademarks of their respective owners.
This technical data may be subject to U.S. and international export, re-export or transfer (“export”) laws. Diversion contrary to U.S. and international
law is strictly prohibited.
Massive Events Guideline – Huawei Infrastructure

80-XXXXX-X Rev. X April 2015
ESG Portifolio
ESG Portfolio
Pre-Deployment Deployment & Event Support
Support Optimization
DAS RFP Development Design & Dimensioning Event Preparation &

3G and 4G Parameter Strategy
FFP Response & DAS Development
Vendor Evaluation
Network Optimization
Network Optimization
Design & Optimization & Troubleshooting
& Troubleshooting
Guideline Development
Performance Evaluation Performance Evaluation
Capacity Estimation & Acceptance & Acceptance
Solution
Interference & Interference &
Classroom Training & Intermodulation Intermodulation
Workshop Delivery Analysis & Mitigation Analysis & Mitigation
• Balanced mix of technology expertise and system engineering knowledge uniquely positions ESG
• ESG has extensive knowledge in dimensioning / design venue’s worldwide
Network
Preparation
Network Preparation
Massive Events Considerations
Installed The amount of sites deployed and planned to provide coverage will affect the
Coverage impact on the RNC requiring more or less aggressive parameterization
Installed Hardware capacity shall not be a limiting factor in Massive Events, but its
Capacity limitation my require more or less aggressive parameterization
Traffic Events planned to have sensitive traffic from government staff, press, high level
Sensibility management, etc.. requires more or less aggressive parameterization
Expected Understanding the expected attendance in terms of number of people and
Attendance typical traffic profile will guide the parameter baseline
Optimization The installed network level of physical optimization may require more or less
Level aggressive parameterization
The parameterization aggressiveness is a tradeoff between ensuring KPIs with system stability
against user experience
Network Preparation
Event Impact Area
Installed Coverage Installed Capacity Traffic Sensibility Expected Attendance Optimization Level
RNC Wide Cluster Wide

Massive Events with the following characteristics Massive Events with the following characteristics
are considered RNC Wide: are considered Cluster Wide:
• Large amount of cells affected • Low amount of cells affected
• Aggressiveness Level is High – regardless of the • Aggressiveness Level is Low
amount of cells
• Some important parameters for more
aggressive scenarios are only available at
RNC-level 7
Confidential and Proprietary – Qualcomm Technologies, Inc. | MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION 80-XXXX-X Rev. C
Network Preparation
Overall Timeline
Network Design Network Optimization Early Preparation - Tests
• Plan the macro coverage • Optimize the physical installation • Take any big event to simulate all the end-
• Plan the indoor coverage • Troubleshoot hardware issues to-end aspects
• Plan the required hardware • Focus on DAS elements and macro • Roll in and out the full Event Day baseline
• Full capacity must be ensured coverage contention • Perform Live Monitoring
• Plan the COWs (Cell on Wheels) • Create the baseline for mass events • Trial specific features
• Take notes from the lessons learned
• Roll in the RNC-level parameters to observe
network impact
Early Preparation - Optimization Mass Event Week Mass Event Day

• Based on the results from the test events • Ensure all the hardware and extra structure • Roll the baseline at least 4h prior to the
• Fine tune the baseline is up and running event start
• Fine tune the physical installation • Compile spreadsheets with all the baseline • Roll back the baseline at least 2h after the
• Expand hardware if necessary and its fallback end of the event
• Compile spreadsheets with all the • Update the spreadsheets with new lessons
parameters required for the live monitoring learned
• Plot maps for the indoor system, macro • Share the results with the whole team for
cells and access areas to the venues new ideas and solutions
Network Preparation
Overall Timeline
Network Design The network design is one of the most important steps of a Massive Event
preparation. It will be the reference point to define the aggressiveness level of
• Plan the macro coverage
• Plan the indoor coverage the Parameters Baseline. A design which provides adequate hardware capacity,
• Plan the required hardware adequate cell capacity in terms of subscribers per cell, adequate soft-handover,
• Full capacity must be ensured no overshooters, will ensure not only good performance but especially good user
• Plan the COWs (Cell on Wheels) experience. A bad design can seriously limit the system performance, even with
the most aggressive parameters baseline.
Network Optimization Once the design implementation is done, it is time to optimize the network. The
key point of this stage is to fix any problem in the DAS (if available) that may
• Optimize the physical installation
• Troubleshoot hardware issues impact the RTWP. Uplink is the key limiting factor of UMTS performance. A DAS
• Focus on DAS elements and macro with bad RTWP will compromise the system performance and network KPIs. The
coverage contention second critical point is the Parameters Baseline. If there is anything that can help
• Create the baseline for mass a poor design and bad optimized network, is the Parameters Baseline. It is
events
always a tradeoff between user experience and network performance.
Network Preparation
Overall Timeline
Early Preparation - Tests As soon as the physical installation is ready and the Parameters Baseline is
• Take any big event to simulate all the end- conceived, the Early Preparation must be started. This stage shall be done with
to-end aspects
• Roll in and out the full Event Day baseline
adequate time prior to the Massive Event start. The idea is to fully simulate the
• Perform Live Monitoring Massive Events Routine in order to find any problems masked under no real load;
• Trial specific features familiarize the Engineering team with the process; learn the most problematic
• Take notes from the lessons learned
• Roll in the RNC-level parameters to observe nodes in the network, and most important, evaluate the design and parameters
network impact baseline performance.
Early Preparation - Optimization The Test Events shall give the real idea of how effective the design and the
• Based on the results from the test events parameters baseline were. Based on this, a new round of optimization shall be
• Fine tune the baseline carried. The focus need to be on practical physical changes and parameters
• Fine tune the physical installation
• Expand hardware if necessary baseline adjustment. This step is usually close to the Massive Event, therefore,
• Define a list of known issues the actions must be prioritized and taken effectively.
Network Preparation
Overall Timeline
Mass Event Week The week prior to the massive event shall be used to ensure that all the key
• Ensure all the hardware and extra structure points of the network are working without flaws. Elements with alarms shall be
is up and running
• Compile spreadsheets with all the baseline
investigated, transmission for the COWs shall be tested, etc.. The team that will
and its fallback work in the Massive Event also needs to be comfortable with the Parameter
• Compile spreadsheets with all the
parameters required for the live monitoring Baseline, also comfortable on how to take the actions through the OSS. Maps
• Plot maps for the indoor system, macro cells with the network topology and spreadsheets with the most common parameters
and access areas to the venues
for Live Monitoring, both need to be ready for the action.
Mass Event Day The Massive Event day shall start at least 4h prior to the event. By that time, any
• Roll the baseline at least 4h prior to the RNC-level baseline shall be ran giving proper time to any rollback necessary.
event start
• Roll back the baseline at least 2h after the
Alarms, basic KPIs shall also be checked. If possible, deploy field engineers to
end of the event help with any troubleshooting, logging and tracing needed. More details of the
• Update the spreadsheets with new lessons
learned Massive Event Day will be given later in this presentation.
• Share the results with the whole team for
new ideas and solutions
DAS Design
DAS Design
Estadio Nacional de Lima
Qualcomm has provided an assessment for the “Estadio Nacional de Lima” comparing the design from a 3rd Party Proposal,
with a design made following the same criteria utilized other past projects such as, Sochi Winter Olympics, Super Bowl, etc..
3rd party’s proposal shows capacity issues. According to the analysis, 21 cells will be useful for a market share of 30%, far from
the real 66% Claro’s market share. This will be translated in bad network KPIs and user experience.
DAS Design
Estadio Nacional de Lima
For more information about the Estadio Nacional de Lima design, please refer to the80-XXXX-X
Confidential and Proprietary – Qualcomm Technologies, Inc. | MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
document
Rev. C
XX 15
DAS Design
General Suggestions
Utilization of narrow-beam antennas is crucial
− Sectors covering small portions of the venue will
ensure:
− Minimum overlap between sectors (Soft-Handover
Overhead)
− Well defined best servers in all areas
− Reduced overshooting inside the venue
− Allows to increase the physical sectors without
creating excessive overlapping of coverage
Stadium Design for Operator A

DAS Design
General Suggestions
The DAS design must ensure that cells from the
same NodeB are contiguous in the bowl area
− Example in the left is a stadium where all sectors
present different NodeBs
− No softer handover areas
Ensure continuity will reduce resource utilization
due to Softer Handover (Iub, CE)
Macro Design
Macro Design
General Suggestions
LAC/URA/RNC borders shall be pushed away from the venue hosting the Massive Event
− Signaling has great impact on the network capacity for massive events
− LAC or URA updates done inside the venue can strongly increase the signaling load
− Minimizing all types of signaling can save important resources
Venues without DAS
− Place the COWs as close as possible to the venue
− Higher the distance, higher the UE transmission power, higher the UL load
− Prefer to deploy multi-beam antennas to extend the COW capacity
− Respect antenna propagation patterns to avoid excessive SHO in the areas close to the COW
− Multi-beam antennas usually have high overlapping areas close to the NodeB
− Excessive SHO can impact the overall venue capacity
− Perform extensive transmission tests to ensure no down times during the events
Example 1: disabling sectors
Macro Design
General Suggestions
Minimum of 10-15 dB isolation between the DAS/macro
− Avoid macro cells invading the venue coverage area
− UEs connected at macro cells will transmit at high power
− It will increase the UL load for the whole venue
− Remove any sector pointing to the venue area Example 2: physical optimization
− If removing it physically is not possible, disable temporarily the cells or
UMTSCOW01 UMTSCOW02
reduce the CPICH to minimum
ESTADBA
Outdoor cells PSC Outdoor cells RSCP
UMSITE03
Hardware Capacity
Hardware Capacity
RNC Boards
The RNC board allocation shall be balanced to avoid overload
− The venue and nearby macro networks have moments of overlapping in terms of high utilization
− During this moment any board imbalance can start a snowball effect of PS rejections
− Excessive amount of RRC attempts will increase the UL noise impacting the overall system performance
− In those scenarios the only way out may be disabling PS services in one or more NodeBs
6000
5000
UEs (DCH+FACH+PCH) [#]
4000
3000
2000
1000
Indoor Outdoor
Hardware Capacity
RNC Boards
XPU Boards are limited in 1200 DCH+FACH and 1800 PCH. Ensuring that important nodes of the Massive Event are
distributedConfidential
over the subsystems will prevent reaching the limit and causing massive80-XXXX-X
and Proprietary – Qualcomm Technologies, Inc. | MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
PS rejections.
Rev. C 23
Hardware Capacity
NodeB Capacity
The NodeBs (indoor, macro or COWs) used for Massive Events shall not be limited in terms
of hardware capacity
− Channel Elements (i.e.: WBBPf4 has the higher capacity compared to other versions)
− Licensed Codes and users (i.e: 15 HS-PDSCH codes per cell, 128 HSDPA users)
− Transmission Capacity
− NBAP processing (i.e. UMTP has higher capabilities than WMPT)
The capacity can be installed temporarily, being “borrowed” from less demanding sites,
during the duration of the event
Close negotiations shall be performed with Huawei to ensure the latest and with highest
capacity hardware to be installed in venues which typically hosts massive events
− Stadiums, Arenas, other venues..
Massive Event Features
Practical
Suggestions
Massive Events Strategy
The Main Actions
Maximum Hardware Capacity Clean Installation

• Ensuring the maximum system capacity is a basic • Guarantee no installation problems for DAS and
requirement for achieving the KPIs and minimum important sites
user perception • Basic to ensure KPIs and minimum user experience
• Insufficient design limits all the other stages of a
Mass Event routine
Events Baseline Live Monitoring

• Optimize UL utilization • Avoid network crash
• Reduce resources consumption • Ensure target KPIs
• Ensure minimum user experience • Ensure minimum user experience
• Utilize as much as possible 3G and 4G
DAS Troubleshooting
DAS Troubleshooting
RTWP – The Main Issue
DAS Performance and optimization is imperative for good user experience

Unloaded RTWP can only be used as reference when UL/DL is balanced
Attenuation in UL to simulate good RTWP should be avoided
PIM (Passive Intermodulation) can impact noise floor; typically caused by poor
components/installation
All Jumpers/cables should be verified for good quality and should be installed properly
High idle RTWP/RSSI is the main issue in a DAS system with UMTS/LTE network
DAS Troubleshooting
PIM with OCNS tools
Passive Intermodulation (PIM) is the result of inter-

modulated frequencies (3rd, 5th and 7th order).
It occurs typically on bad metal-to-metal connections (usually

connectors) and can be due to loose connector, corrosion,
dirty connector and others.
It is specially damaging when the resulting power can be

seen on the UL band, were it will perceived as higher than
Normal RTWP, and its magnitude will increase with DL Load.
OCNS (Orthogonal Channel Noise Simulator) can easily

simulate DL load, thus, allowing quick identification of bad
performing sectors.
DAS Troubleshooting
Passive DAS Troubleshooting
Check if any sector-carrier is having higher than -

105dBm Noise floor (with DAS connected)
Verify the connections and identify DAS route of this

cell: identify tappers, attenuators, connectors, splitters
& combiners, MHA/LNA etc.
Use VSWR measurements or Cable distance to fault

measurements in order to identify faulty element(s)
Health check of identified elements (change faulty

component, etc.)
DAS Troubleshooting
Active DAS Troubleshooting
Similar procedure is done for Active DAS, however,

new hardware is added to the topology
Check if any sector-carrier is having high Noise floor
(with DAS connected): ~ -105dBm
Verify the connections and identify DAS route of this

cell: identify active (MU, RU, POIs, etc..) and passive
(tappers, attenuators, connectors, etc..) elements
Verify the Master Unit (MU) and Remote Unit (RU)

configuration and their physical integrity
DAS Troubleshooting
UL Attenuation
A common procedure to “improve” the RTWP performance, is to increase the

UL attenuation
− Lower RTWP is achieved by the cost of creating UL/DL imbalance
− It hides installation problems such as bad fibers, splitters, diplexers, cables, etc..
DAS Diagram:
DAS Troubleshooting
UL Attenuation
Before introducing UL Attenuation After Introducing UL Attenuation
RSCP: -85dBm RSCP: -85dBm
UL Interference: -77dBm UL Interference: -82dBm (after 5dB Attenuation)
ConstantValue: -27dB ConstantValue: -27dB
PCPICH Power: 33dBm PCPICH Power: 33dBm
StepSize: 2dB StepSize: 2dB
Expected Preamble Ec/No: -27dB Expected Preamble Ec/No: -27dB
RACH Initial Power: RACH Initial Power:
PCPICH – RSCP + UL_Inter.+ConstantValue PCPICH – RSCP + UL_Inter.+ConstantValue
33-(-85) +(-77)+(-27) = 14dBm 33-(-85) +(-82)+(-27) = 9dBm
Access the Network using selected Tx Power: Access the Network using selected Tx Power:
Path Loss: 33dbm – (-85dbm) = 118dB Path Loss: 33dbm – (-85dbm) = 118dB + 5dB (UL ATT) = 123dB
Received Power : 14dBm – 118dB = -104dBm Received Power : 9dBm – 123dB = -114dBm
Ec/No of received Preamble: -104 - (-77dBm) = -27dB OK Ec/No of received Preamble: -114 - (-82dBm) = -32dB NOK
Next Preamble (+2dB) = -30 dB NOK
UE Tx Power for Successful Access: 14dBm Next Preamble (+2dB) = -28 dB NOK
Next Preamble (+2dB) = -26dB OK
UE Tx Power for Successful Access: 9dBm + 3 Preamble (3 * 2dB) =15dBm
UE Tx Power is similar with or without attenuation, even when attenuation produces “lower” RTWP. Attenuation also resulted in 3
Confidential and Proprietaryfailed Preambles
– Qualcomm Technologies, Inc. | that willU.S. add
MAY CONTAIN to overall
AND INTERNATIONAL Noise INFORMATION
EXPORT CONTROLLED Floor 80-XXXX-X Rev. C 34
DAS Troubleshooting
UL Attenuation
Any UE that cannot access the network before the attenuation because required UL Tx
Power is > 24dBm will still not be able to access the network after attenuation
This problem is the same in Close loop Power Control mode since the NodeB will make the
UE power UP until UL is Closed, which now will include extra dBs of Attenuation in the path
loss
High RTWP is a cumulative situation, that starts with small problems like Unbalanced Link
Budget (different UL /DL attenuations), Passive Intermodulation Problems, high RTWP under
no Load, or interference due to poor neighbor planning, Macro Overshooters or network
Parameterizations.
Qualcomm does not recommend under any circumstances to increase UL attenuation, because independent of the
level of RTWP it could only make the problem worse over time due to the increase in preambles.
DAS Troubleshooting
UL/DL Imbalance
Extra UL attenuation also generates imbalance in

DL/UL
It becomes visible on field tests while comparing

different sectors with similar DL configurations but
very different UL TX Power
Not only the presented problems during access will

happen, but will prevail during the whole time,
increasing the UL noise over the whole venue
DL PL= CPICH (SIB5) - RSCPmeas

UL PL= UE TX Power – Receiver Sensitivity
DAS Troubleshooting
Walk Test Procedure
- Scanner for all 2G bands.
Equipment
Required
- Scanner for all 3G bands.

- Scanner for all 4G bands. - Perform three runs on the bowl area with the phone doing
- UE that supports dedicated operation on 2G/3G/4G. extended CS calls
-- First run on the upper part of the bowl, the area more
Recommendations
- Walk in a slow and constant pace. It is crucial to have a good affected by the macro network
Extended CS Calls
resolution of the samples. -- The second run on the middle part of the bowl area
Overall
- Do not use GPS, its measurements may not be reliable. - -- The third run on the lower part of the bow, the area more
Create a logbook with the time starting and ending each affected by overlapping
procedure. Plus, if any anomaly happens, write down on the - Perform one run over all transition areas
log book. -- Transition from macro network to the indoor system
-- Transition from common areas (access, halls, restaurants,
- Perform 20 short calls per physical DAS sector. If there are etc..) to the bowl area
Short CS Calls
more than one remote unit per sector, perform 20 calls per - Perform all tests for 2G and 3G
remote unit. Perform these tests in 2G and 3G.
- Perform 5 CSFB per physical DAS sector. If there are more
than one remote unit per sector, perform 5 CSFB per remote
unit.
DAS Troubleshooting
Walk Test Procedure
- Perform five runs at the bowl area with each technology.
-- First run on the upper part of the bowl, the area more
affected by the macro network.
Scanner Tests
-- The second run on the middle part of the bowl area
-- The third run on the lower part of the bow, the area more
- Perform 5 throughput tests per technology, per physical affected by overlapping
sector. If there are more than one remote unit per sector, -- Fourth and fifth runs between upper-middle and middle-
perform 5 tests per remote unit. lower parts.
Data Calls
- Perform 5 ping tests per technology, per physical sector. If - Perform one run at the common areas, such as, access, halls,
there are more than one remote unit per sector, perform 5 restaurants, VIP areas, etc..
tests per remote unit.
- Before each round of tests per technology, lock the phone - Lock the phone 2G, perform a CS call, change the phone to
on the tested technology. 2G/3G, observe if it reselects to 3G.
Reselection
- Lock the phone 2G, perform a CS call, change the phone to
2G/3G/4G, observe if it reselects to 4G.
- Lock the phone 3G, perform a CS call, change the phone to
2G/3G/4G, observe if it reselects to 4G.
Topology Maps
Topology Maps Site
SITE02 - Estadio Nacional
NodeB
SITE02
UtranCell
U22621
CellID
22621
SITE02 - Estadio Nacional SITE02 U22622 22622
Inter-Cell Relations – Problem Demonstration SITE02 - Estadio Nacional
SITE02
SITE02
U22623
U22624
22623
22624
Events with complex DAS systems or covered by several SITE02 - Estadio Nacional
SITE02
SITE02
U22627
U22628
22627
22628
macro sites can quickly become hard to be managed during SITE02 - Estadio Nacional
SITE02
SITE02
U22629
U45837
22629
45837
live monitoring SITE02 - Estadio Nacional

SITE02
SITE02
U45838
U45839
45838
45839
SITE13 - External COW SITE13 U59831 59831
To quickly react to traffic changes, information of neighbor SITE13 - External COW SITE13 U59833 59833
relations and the configuration of each cell must be easy to SITE13 - External COW
SITE13 - External COW
SITE13
SITE13
U59834
U59835
59834
59835
be retrieved SITE13 - External COW

SITE13
SITE13
U59836
U59837
59836
59837
It can get extremely confusing to perform load balancing SITE13 - External COW SITE13 U41707 41707
actions, traffic redirection, etc.. SITE13 - External COW

SITE13
SITE13
U41708
U41709
41708
41709
SITE12 - Access COW SITE12 U59821 59821
Example for Estadio Nacional SITE12 - Access COW SITE12 U59823 59823
3 NodeBs, 3 sectors each, 4 carriers per sector SITE12 - Access COW
SITE12 - Access COW
SITE12
SITE12
U59825
U59826
59825
59826
36 cells to monitored at the same time SITE12 - Access COW

SITE12 - Access COW
SITE12
SITE12
U59827
U59828
59827
59828
How to quickly determine which cells are neighbors or co- SITE12 - Access COW SITE12 U41687 41687
located? SITE12 - Access COW SITE12 U41689 41689
Topology Maps
Inter-Cell Relations – Problem Solution
The easiest way to manage the information is by compiling detailed maps with the most relevant information
about each sector and providing visual information on how the sectors are related
Confidential and Proprietary – Qualcomm Technologies, Inc. |
to the neighbors
80-XXXX-X Rev. C
MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION 41
Massive Events
Routine
Massive Event Routine
Event Day Actions
T-240 Implementation of Game Day baseline

G
T-225 NW Sanity Verification (Alarms, basic parameters and overall performance) A
M
T-180 Beginning of Live Monitoring and Optimization E
T-60 1st Outdoor CPICH Reduction
S
T-30 2nd Outdoor CPICH Reduction T
A
T-15 3rd Outdoor CPICH Reduction R
T
T-5 COWs and Outdoor offline
Traffic Behavior and Monitoring Actions
Indoor Actions
The main goal of indoor actions are to balance traffic CPICH changes
between sectors and layers
− Balance traffic between carriers of the same DAS sector qOffset changes 3G
Traffic
− Balance traffic between DAS sectors
qQualmin changes Balance
− Offload traffic to co-sector 2G cells
Actions were also taken to contain RTWP increase IFLB changes
− Offload traffic from cells with bad performance
− Block cells bad with average RTWP on idle hours
− Next slide for information qQualmin changes iRAT
Traffic
Redirection to 2G Balance
Cells with Constant Bad RTWP
Cells presenting high levels of RTWP during idle hours shall be disabled before the event
− It is better to lose the capacity of once cell than compromising the whole system
− Once UEs increases its Tx power it starts affecting neighbor cells
− Other UEs in the neighbor cells increase their Tx power to overcome the new added noise
− Snowball effect in the uplink – all cells start to present bad RTWP performance
Good RTWP Good RTWP Bad RTWP

Bad RTWP
Bad RTWP Bad RTWP

Tx Power
Tx Power
Tx Power
Tx Power
Actions per Hour
Total amount of actions performed in the outdoor and indoor stadium area
− 12 NodeBs with 87 cells
Three Qualcomm engineers The first minutes of the game
Monitoring Actions and half-time are when the DAS
40 gets more loaded, increasing
Game Window
35 the amount of action
30
25
Actions [#]
20
15
10
5
0
1 2 3 4 5 6 7 8
Monitoring Hours
The first hour accumulates the The hour prior to the game is the The last hours are
majority of pre-game actions. most demanding. Load balance in mainly rollbacks
Baseline, alarms, parameterization, the macro and indoor, overload
etc.. monitoring, etc.. Game: Brazil xRev.
Colombia 47
Confidential and Proprietary – Qualcomm Technologies, Inc. | MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION 80-XXXX-X C
M2000 and WebLMT
WebLMT is the most effective way to monitor the key metrics The M2000 is where the most part of the scripts are ran and
involved in the Live Monitoring routine where the counters can be quickly retrieved for KPIs
calculation
Massive Events
Baseline
Layer Management
Layer Management
Definitions
Important Definitions for Layer Management Analysis
CORE Cells IF Border Cells IRAT Border Cells

• Core Cells are defined by having • IF Border Cells are defined by • IRAT Border Cells are defined by
contiguous UMTS coverage in the cells where the layer coverage is cells without another UMTS layer
same carrier ended and another UMTS layer is available, only GSM
• For these cells, in connected available • For these cells, in connected
mode, there is no IF handover • For these cells, in connected mode, handover shall be
triggered by EcNo or RSCP mode, handover shall be triggered only for CS/mRAB
• Mobility shall be handled only by triggered only for CS or mRAB • Load sharing features will also be
load sharing features • Load sharing features will also be active at these cells
active at these cells
Fn+1 Fn+1 Fn
CORE CORE IF IF IRAT IRAT
Fn Fn GSM
CORE CORE CORE GSM GSM GSM GSM GSM
Layer Management
Multi-RATs General Strategy
The strategy will keep the LTE->UMTS mobility only to

850MHz. The opposite way, UMTS->LTE, will be allowed for
all UMTS carriers.
To enhance UMTS capacity a new 1900MHz carrier will be

activated. The activation of this carrier will change the
management between layers on the sites where the new layer
is deployed. For the sites without this new layer, the strategy
shall be kept the same.
Mobility between GSM and all UMTS carriers will be allowed

in both ways through reselection and by CS HO only for
UMTS->GSM.
Layer Management
UMTS DCH/HS Strategy
CS Coverage Handovers shall be enabled for:

• 1900MHz to 850MHz at 1900MHz IFHO Borders cells
• 850MHz to 850MHz at 850MHz IFHO Borders cells
• 850MHz to GSM at 850MHz IRATHO Borders cells
Load Balance (DRD) shall be enabled for:

• 1900MHz to 850MHz for all 1900MHz
• 850MHz to 850MHz for all cells
Emergency mechanisms to offload traffic from UMTS to GSM

under congestion are also enabled
Reselection is free between all the UMTS and GSM layers and
shall be unbiased between carriers of the same band
Layer Management
UMTS Reselection Strategy
The newly activated 1900 MHz carrier naturally have better

Ec/No than the 850 MHz band. Smaller overlap, smaller
coverage footprint, thus, smaller interference.
The natural behavior will result in the 1900 MHz being the
better natural choice for the UE camping, increasing the
probability of traffic unbalance and resources starvation in
the 1900 MHz band
To avoid unbalance between the two bands and 1900MHz

congestion, a special reselection parameterization was
developed, using different search triggers and reselection
offsets for each carrier.
Sites without UMTS 1900 MHz, this considerations shall be
ignored
Layer Management
UMTS 1900 MHz Hotspots Cell Reselection
Seach Thresholds Reselection Strategy
1900 MHz EcNo 8 50 MHz EcNo 1900 MHz EcNo 8 50 MHz EcNo
-7 Search In terf requ en cy R1900 R8 50 + 3dB > R1900

-8 Search Intrafrequency
-9 Search Intrafrequency 3dB
-10 Search In terf requ en cy R850 R1900 - 3dB > R8 50
-15 Search IRAT

-16 Search IRAT
-17 Minimum Quality Level
-18 Minimum Quality Level
The strategy is based on different thresholds for inter-frequency search and reselection offsets guiding the UE to select
the 850MHz carrier even with a slightly worst EcNo. In the 850MHz side the parameterization will retain the UEs to avoid
“ping-pong” between the carriers.
Layer Management
Optimization Goals and Drawbacks
Optimization Goals: eliminate/reduce Compressed Mode

• Reduce the DL/UL power utilization
• Reduce the call drop possibility
• Reduce the code utilization
• Achieve better traffic balance between 850MHz and 1900MHz
• Minimize mobility to GSM where the user experience is bad
Possible Drawbacks
• Requires good level of knowledge of the network to correctly define CORE, IF and IRAT cells
• Needs optimized feature configuration
• Load Balance is not as effective when performing balance between different bands as for the same bands
• qOffset fine tuning required
• Increase on 3G utilization
State Transitions and Channel Switching
Overview
UTRAN Connected Mode
Channels: PCH, No Uplink Channels: PCH, No Uplink
Mobility: URA Update URA_PCH CELL_PCH Mobility: Cell Update
Calls: PS (no data transfer) Calls: PS (no data transfer)
DRX Mode DRX Mode
Channels: Downlink DCH, Channels: FACH, RACH

Uplink DCH Mobility: Cell Update
CELL_DCH CELL_FACH
Mobility: Handover Calls: PS
Calls: PS, CS Dedicated logical channels, but
common transport and physical
channels
Release RRC Release RRC
No DRX Mode
Connection Connection
Establish RRC Establish RRC
CELL_DCH Connection Connection
DL/UL R99 with Channels: PCH, No Uplink
Diff data rates Idle Mode Mobility: Location/Routing Area
(Camping on a UTRAN cell) Update
Calls: None, PS call might be in “PDP
DL: HSDPA DL:HSDPA context preserved” state
+ + DRX Mode
UL: R99 UL:HSUPA
State Transitions
State Transitions and DCCC are key points of the Parameters

Baseline. It directly impacts the user experience, resources
consumption and KPIs.
These parameters are available only at RNC-level, therefore,

it`s optimization needs to be done according to the
considerations presented in the “Network Preparation”
section.
The basis for the State Transitions parameterization is the

current configuration of LIMRNC07, with special tuning of
event 4A F2D.
It is essential that the RNCs hosting Massive Events have the

second FACH already expanded
DCCC - Dynamic Channel Configuration Control
For the DCCC optimization unfortunately the parameters are also only
available at RNC level.
For the DCCC optimization, the Massive Events parameterization

increase the 4A buffer size necessary to achieve higher data rates
with PS R99 RABs. 4B is also optimized to obtain a more efficient
downswitch to lower PS R99 RABs.
Optimization Goals: reduce resources consumption on DCH/HS

• Optimize the time spent on FACH, DCH and HS channels
• Reduce the resource consumption in these channels
• Increase the CELL_PCH and URA_PCH utilization
• Slow down the upswitch for PSR99 higher rates
Possible Drawbacks
• Increase on FACH utilization may increase or start the FACH congestion
• Call drop can also be affected
• Higher delay for upswitching on PSR99
• Increase on the amount of State Transitions impacting the RNC signaling load
DL Power and PSR99 Utilization
DPCH Power Offsets
The DL DPCH (Dedicated Physical Channel) carries the

DPDCH and DPCCH, responsible for Data and Control
information, respectively.
On the DL DPCCH, there is a Pilot (PO3) signal used for

DPCH synchronization, Transmit Power Control (TPC)
commands (PO2), and the TFCI (PO1), which specifies the
transport format in use for the data in the 10 ms radio frame.
DPDCH DPCCH DPDCH DPCCH

Optimizing the offsets can guarantee a good compromise
between reliability and power consumption
DPCH
BLER and SIR Target Outer loop feeds the inner loop
WCDMA heavily relies on Power Control for its operation. The

Power Control process can be divided in two branches, Inner
and Outer Loop.
The Outer Loop, located at the RNC, calculates the BLER of

incoming transmissions, compares with the BLERtarget, and
if necessary, adjusts the SIRtarget at the NodeB.
The Inner Loop, located at the NodeB, calculates the SIR of

incoming transmissions, compares with SIRtarget reported by
the RNC and generate the TPC commands to the UE.
Admitting larger BLERtarget and reduced SIRtarget it is

possible to reduce the impact of PSR99 on DL Power and UL
Interference.
RABs Configuration
It is important to disable PS R99 RABs with high data rates
For CS RABs, the 12.2 kbps and 4.75 kbps options shall be enabled
PS RABs shall be enabled according to the following suggestions:

• Downlink: HSDPA and PS R99 up to 64 kbps
• Uplink: HSUPA and PS R99 up to 64 kbps
• 32 kbps is an more aggressive parameterization which can
also be applied
For Multi-RAB (CS+P) RABs, the PS side of the call will follow the
DCCC configuration for PS-only calls. It is necessary to adjust the
RAB assigned to the UE when there is no activity and the maximum
allowed data rate while on mRAB
Optimization Goals: minimize the PSR99 resource consumption
• Reduce the initial and maximum SIR targets
• Increase the BLER target
• Optimize the power allocation for PO1-3
• Limit PSR99 RABs utilization (PS and CS+PS)
• Activate AMR4.75
Possible Drawbacks
• Increase on PSR99 drop probability
• Users will be limit to lower rates on PSR99
HSDPA
HSDPA
HS-PDSCH and HS-SCCH Utilization
HS-SCCHs carries scheduling information for the UEs

allocated in the next TTI. Each allocated UE requires one HS-
SCCH.
HS-PDSCH HS-PDSCH carries the HSDPA data. Per TTI. Saving codes to
HS-SCCH
HS-PDSCH improves the HSDPA performance but may
subjects R99 (PS and CS) to code congestion and increase
on the HSDPA scheduling waiting time
Optimizing the reserved HSDPA codes can save resources for

other types of services
HSDPA
HS-DPCCH Utilization
HS-PDSCH
HS-DPCCH is uplink channel which carries the UE feedback
from the HSDPA transmission on DL
HS-DPCCH The feedback is composed of two parts: ACK or NACK, which
is just an acknowledgement to the HS-DSCH assignment; and
the Channel Quality Indicator (CQI), which is used by the
NodeB scheduler algorithm to define some parameters of the
HSDPA transmission
Reducing the CQI periodicity will reduce the rise over thermal
caused by the HSDPA uplink channel
Introducing the BLER as part of the NodeB scheduler

algorithm can improve the scheduling efficiency in always
changing radio environments
HSDPA
Serving Cell Change
Penalty Time
RSCP
Extra Time The HSDPA mobility (“handover”) procedure is named as

Serving Cell Change (SCC). Differently from HSUPA and
DCH, HSDPA does not support Soft-Handover, therefore, it is
a type of hard handover.
To avoid excessive Serving Cell Changes, it is possible to

slow down the process by adding a “penalty” timer between
each SCC made by the UE
Massive Events typically are a low-mobility scenario.

Optimizing the penalty time can potentially increase the
HSDPA throughput and reduce the signaling involved with
SCC
Time
Cell A Cell B Cell C SCC
** Hysteresis and TTT omitted forandsimplicity
Confidential Proprietary – Qualcomm Technologies, Inc. | MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION 80-XXXX-X Rev. C 71
HSDPA
Codes Allocation
The HSDPA codes allocation can be done in three ways: fixed,

Dynamic at the RNC and Dynamic at the NodeB
The dynamic code allocation done at the RNC works with

minimum and maximum codes that can be allocated to HS-
PDSCH. The capacity of allocating idle DPCH codes is
limited.
The dynamic code allocation done at the NodeB not only
allocates the reserved codes for HS-PDSCH, but it also can
fully allocate the idle codes not used for DPCH.
The dynamic code allocation at the NodeB is more flexible

than the dynamic code allocation at the RNC. It shortens the
code allocation duration and reduces the Iub signaling load
required by code allocation messages
HSDPA
Optimization Goals: optimize the HSDPA resources consumption and mobility

• Reduce the minimum reserved HS-PSDCH codes to prioritize voice
• Reduce the maximum HS-SCCH codes to free codes for voice utilization
• Reduce the frequency of CQI reporting to reduce UL load
• Compensate CQI reports based on measured BLER to optimize the scheduler algorithm
• Enable the Dynamic Code Allocation at NodeB to increase code allocation efficiency and reduce Iub load
• Reduce the amount of SCC in a low-mobility scenario
Possible Drawbacks
• Less resources for HSDPA when the network is under extreme CS utilization
• Impact the DL throughput
• Less HS-SCCH can increase the HSDPA Scheduler queue
• Delaying the SCC can increase the time an UE stays in a bad quality cell
• Can affect the throughput and increase the UL noise
HSUPA
HSUPA
UL Operation (1/3)
Rise-over-Thermal (RoT) is the shared resource in the uplink.
It is crucial to control its rise and limit the impact of each UE
in the overall load
1) When the amount of UEs transmitting increases, the overall

level of interference in the Uplink band
2) The Node B monitors the noise rise
3) The Node B controls the interference level by adjusting the
UE grant assignments according to the current perceived
interference situation
4) The UE receives a new grant, it combines the information
with its power headroom and buffer size
5) The UE transmit the data with the adequate data rate and
power
Controlling the RoT and giving more headroom for the NodeB
scheduler are the main goal of the HSUPA optimization
HSUPA
UL Operation (2/3)
Allowing an extra RoT margin has a direct relation with
allowing a higher load in the Uplink direction, thus, allowing
100% Load more UEs accessing the network, or allowing higher uplink
throughput for those already scheduled,
Load
The maximum allowed Uplink Load is calculated as function
Load Factor
of the Load Factor (dB) plus the BackgroundNoise (dB). The
background noise can be seen as the thermal noise added to
Load Factor
all the other factors that add noise to the uplink (cables,
jumpers, connectors and external interference). Manually
adjusting the BackgroundNoise increases the maximum
Manual Adj. allowed Uplink load.
Other Noise Other Noise Manually adjusting the background noise increases the
Thermal Noise Thermal Noise uplink capacity by increasing the maximum allowed Uplink
Manual
load.
Automatic
BackgroundNoise BackgroundNoise
HSUPA
UL Operation (3/3)
The E-DPDCH carries mainly user plane data. The Physical
Layer control information, TFCI etc., is carried on one E-
DPCCH.
The E-HICH and E-RGCH are dedicated channels and they

share a single channelization, being the first designed to
carry HARQ information and the second to alter the Absolute
Grant provided to the UE.
The Downlink channel E-AGCH (Absolute Grant Channel for

E-DCH) is a common channel shared by all the users in the
UE cell. The addressing on E-AGCH is realized by masking CRC
bits with E-RNTI (RNTI for E-DCH).
NodeB
Reducing the resources (power and codes) allocated to the
HSUPA channels can reduce the overall DL and UL load
HSUPA
Optimization Goals: reduce the UL load and save resources related to HSUPA
• Speedup the inactivity process for HSUPA
• Slow down the process of increasing UL throughput
• Reduce the throughput for UEs in soft-handover
• Increase the power headroom for the NodeB scheduler
• Reduce the initial SIR target for the HSUPA channels
Possible Drawbacks
• Lower user throughput
• Increase on HSUPA call drop
Random Access Procedure
Overview
The Random Access Procedure is started when the UE is

trying to access the desired cell to obtain services.
The UE sends the first preamble at P_PRACH dBm and wait

for the NodeB`s response. If the response doesn`t arrive, it
increases the transmission power in powerOffsetP0 dB and
try again.
This cycle is repeated for a determined (by parameters)

amount of times or until the NodeB responds.
P_PRACH = L_PCPICH + RTWP + constantValueCprach
• L_PCPICH: is the path loss estimated by the UE based on knowing the The Random Access Procedure plays a key role in controlling
transmitted and received PCPICH power.
• RTWP: is the Received Total Wideband Power (UL interference) level the Rise-over-Thermal in a 3G network
measured by the RBS.
• constantValueCprach: is used by the UE to calculate the initial power on
the PRACH.
Not Optimized Configuration
Operator A – Config #2
Operator A – Config #1
24 1.2 24 1.2
14 1 14 1
4 4
RACH Power (dBm)
RACH Power (dBm)

0.8 0.8
-6 0 1000 2000 3000 4000 -6 0 1000 2000 3000 4000
0.6 0.6
M
-16 -16
0.4 0.4
-26 -26
0.2 0.2
-36 -36
-46 0 -46 0
-56 -0.2 -56 -0.2

Time (ms) Time (ms)
Preamble Power M RACH Message Total Power if ACKed Reach NodeB Preamble Power M RACH Message Total Power if ACKed Reach NodeB
Config #1, the full range of the UE TX power is not being used. There Config #2, the UE TX power is saturated at the 24 dBm. Transmitting
is possibility of failure on accessing the network on more loaded at full power continuously increases the UL noise without increasing
scenarios where the UL noise is higher. the probability of the UE being listened by the NodeB.
Suggested Configuration
Suggestion
24 1.2
14 1
4
RACH Power (dBm)
0.8
-6 0 500 1000 1500 2000 2500 3000 3500 4000
0.6
M
-16
0.4
-26
0.2
-36
-46 0
-56 -0.2
Time (ms)
Preamble Power M RACH Message Total Power if ACKed Reach NodeB
The suggested configuration start from a low value and have steps of 2 dB per preamble repetition. On good scenarios the
preamble can be acknowledged earlier, reducing the overall RoT. If necessary the UE will use its full power range, but without
saturation at 24 dBm. Confidential and Proprietary – Qualcomm Technologies, Inc. | MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION 80-XXXX-X Rev. C 83
Optimization Goals: reduce the UL noise caused by RA procedure

• Reduce the initial preamble power
• Reduce the amount of preambles per cycle
• Increase the preamble step
• Increase the amount of RACH signatures
Possible Drawbacks
• Delaying the user access
Full Parameters
Baseline
Full Parameters Baseline
Important Information
About this Baseline
This baseline was developed specifically for Claro Peru considering the current network configuration, for any other use it is
just a reference.
Is important to updated the baseline when new configurations or features are applied to the network, in close future many of
the commands included here may not be necessary.
Before Applying the Baseline

The following procedures/steps must be ALWAYS be executed before rolling in the baseline
• Backup the latest dump or parameters list of each node involved in the Massive Event
• Generate the rollback scripts before running
• In case of any problems the rollback scripts and the original configuration must be quickly accessed
• Ensure the node performance is adequate
• Check if there is no alarms present
• Check all the basic KPIs of the node
• Hidden problems may be wrongly attributed to the baseline
RNC Script Example
SET UCORRMPARA:PERFENHANCESWITCH3=PERFENH_INACTIVE_F2P_SWITCH-1;
SET UUESTATETRANSTIMER:CELLRESELECTTIMER=180, BEF2PSTATETRANSTIMER=3, BED2FSTATETRANSTIMER=2, BEH2FSTATETRANSTIMER=2, RTDH2FSTATETRANSTIMER=180, BEE2FSTATETRANSTIMER=2,
BECPC2FSTATETRANSTIMER=5, RTCPC2FSTATETRANSTIMER=180, BED2EFACHSTATETRANSTIMER=5, BEH2EFACHSTATETRANSTIMER=5, RTDH2EFACHSTATETRANSTIMER=180,
BECPC2EFACHSTATETRANSTIMER=5, RTCPC2EFACHSTATETRANSTIMER=180, BEABNORMH2FSTATETRANSTIMER=31, INACTF2PSTATETRANSTIMER=5;
SET UUESTATETRANS:CELLRESELECTCOUNTER=2, STATETRANSTRAFFREDUNDCOEF=80, D2F2PTVMTHD=D128, D2FTVMTIMETOTRIG=D2560, D2FTVMPTAT=D1000, F2PTVMTIMETOTRIG=D5000,
F2PTVMPTAT=D1000, BEF2DTVMTHD=D1024, BEF2DTVMTIMETOTRIG=D200, BEH2FTVMTHD=D128, BEH2FTVMTIMETOTRIG=D2560, BEH2FTVMPTAT=D1000, BEF2HTVMTHD=D1024,
BEF2HTVMTIMETOTRIG=D200, RTDH2FTVMTHD=D64, RTDH2FTVMTIMETOTRIG=D5000, RTDH2FTVMPTAT=D16000, RTF2DHTVMTHD=D1024, RTF2DHTVMTIMETOTRIG=D240, E2FTHROUMEASPERIOD=50,
E2FTHROUTHD=8, E2FTHROUTIMETOTRIG=2, E2FTHROUPTAT=4, BEF2ETVMTHD=D1024, BEF2ETVMTIMETOTRIG=D200, BEF2CPCHTVMTHD=D1024, BEF2CPCHTVMTIMETOTRIG=D0, RTF2CPCTVMTHD=D1024,
RTF2CPCTVMTIMETOTRIG=D0, BEF2CPCETVMTHD=D1024, BEF2CPCETVMTIMETOTRIG=D0, BEEFACH2DTVMTHD=D1024, BEEFACH2DTVMTIMETOTRIG=D0, BEEFACH2HTVMTHD=D1024,
BEEFACH2HTVMTIMETOTRIG=D0, RTEFACH2DHTVMTHD=D1024, RTEFACH2DHTVMTIMETOTRIG=D0, BEEFACH2CPCTVMTHD=D1024, BEEFACH2CPCTVMTIMETOTRIG=D0, RTEFACH2CPCTVMTHD=D1024,
RTEFACH2CPCTVMTIMETOTRIG=D0, FASTDORMANCYF2DHTVMTHD=D1024, HSDPA4ATVMTHD=D1024, HSUPA4ATHROUTHD=64, TXINTERRUPTAFTERTRIG=D2000, BEF2DHTVMTHDFORFACHCONG=D512,
TVMTHDFORSMARTP2D=51, BASEDTIMEF2DTHD=0, BASEDTIMEF2DPT=10, DLBEABNH2FHIGHTHROUTHD=8, DLBEABNH2FLOWTHROUTHD=8, DLBEABNH2FHIGHTVMTHD=102, DLBEABNH2FLOWTVMTHD=102,
ABNH2FPENALTYLEN=60, H2FHSUPA4ATHROUPAT=2;
SET UCORRMALGOSWITCH:PCSWITCH=PC_RL_RECFG_SIR_TARGET_CARRY_SWITCH-1&PC_OLPC_FASTDOWN_OPTIMIZE_SWITCH-1;
SET UCORRMPARA:PERFENHANCESWITCH=PERFENH_RL_RECFG_SIR_CONSIDER_SWITCH-1;
SET URRCTRLSWITCH:PROCESSSWITCH2=RNC_RBRECFG_DRD_FAIL_ROLLBACK_SWITCH-1&RNC_RBSETUP_DRD_FAIL_ROLLBACK_SWITCH-1;
SET URRCTRLSWITCH:PROCESSSWITCH2=FACH_DTCH_CONGEST_P2D-0;
SET UCORRMPARA:PERFENHANCESWITCH=PERFENH_PSTRAFFIC_P2H_SWITCH-1;
DEA UTYPRAB:RABINDEX=45;
SET URRCESTCAUSE:RRCCAUSE=ORIGSTREAMCALLEST, SIGCHTYPE=DCH_3.4K_SIGNALLING;
SET URRCESTCAUSE:RRCCAUSE=ORIGINTERCALLEST, SIGCHTYPE=DCH_3.4K_SIGNALLING;
SET URRCESTCAUSE:RRCCAUSE=ORIGBKGCALLEST, SIGCHTYPE=DCH_3.4K_SIGNALLING;
SET URRCESTCAUSE:RRCCAUSE=ORIGSUBSTRAFFCALLEST, SIGCHTYPE=DCH_3.4K_SIGNALLING;
SET URRCESTCAUSE:RRCCAUSE=TERMSTREAMCALLEST, SIGCHTYPE=DCH_3.4K_SIGNALLING;
SET URRCESTCAUSE:RRCCAUSE=TERMINTERCALLEST, SIGCHTYPE=DCH_3.4K_SIGNALLING;
SET URRCESTCAUSE:RRCCAUSE=TERMBKGCALLEST, SIGCHTYPE=DCH_3.4K_SIGNALLING;
SET USTATETIMER:RRCCONNREJWAITTMR=6, LOWRRCCONNREJWAITTMR=15;
SET UUESTATETRANS:BEF2DTVMTHD=D4K, BEF2HTVMTHD=D4K, BEF2ETVMTHD=D4K, BEF2CPCHTVMTHD=D4K, BEF2CPCETVMTHD=D4K;
NodeB Script Example

SET NODEBRESALLOCRULE:RULE=CAPAFIRST,SW=ON;
SET ULOCELLALGPARA:RTWPSIRTGTADJSW=ON;
SET ULOCELLMACHSPARA:CQIADJALGOFNONCON=CQI_ADJ_BY_IBLER,IBLERTARGET=10;
SET ULOCELLMACHSPARA:DYNCODESW=OPEN;
Cell Script Example (Part 1/2)

ADD UCELLHSDPCCH: CELLID=11111, CQIFbCk=D40, CQIFbCkforSHO=D40, CQIFBckBaseCsCombServ=D40;
MOD UCELLCAC: CELLID=11111, MaxHsdpaUserNum=96, UlHoCeResvSf=SFOFF, DlHoCeCodeResvSf=SFOFF;
DEA UCELLHSDPA:CELLID=11111;
MOD UCELLHSDPA:CELLID=11111,ALLOCCODEMODE=Manual,HSPDSCHCODENUM=1,HSSCCHCODENUM=2;
ACT UCELLHSDPA:CELLID=11111;
MOD
UCELLLDR:CELLID=11111,DLLDRFIRSTACTION=BERateRed,DLLDRSECONDACTION=CodeAdj,DLLDRTHIRDACTION=NoAct,DLLDRFOURTHACTION=NoAct,DLLDRFIFTHACTION=NoAct,DLLDRBERATEREDUCTIONRABN
UM=10,ULLDRFIRSTACTION=BERateRed, UlLdrSecondAction=NoAct, UlLdrThirdAction=NoAct,
UlLdrFourthAction=NoAct,UlLdrFifthAction=NoAct,ULLDRBERATEREDUCTIONRABNUM=10,CELLLDRSFRESTHD=SF4,ULLDRCREDITSFRESTHD=SF4,DLLDRCREDITSFRESTHD=SF4;
MOD UAICHPWROFFSET:CELLID=11111,AICHPOWEROFFSET=-4;
MOD UPICHPWROFFSET:CELLID=11111,PICHPOWEROFFSET=-5;
ADD UCELLHOCOMM:CELLID=11111,HSPATIMERLEN=2;
MOD UPRACH:CELLID=11111,PHYCHID=4,PREAMBLESIGNATURES=SIGNATURE8-1&SIGNATURE9-1&SIGNATURE10-1&SIGNATURE11-1&SIGNATURE12-1&SIGNATURE13-1&SIGNATURE14-1&SIGNATURE15-1;
MOD UPRACHASC:CELLID=11111,PHYCHID=4,ACCESSSERVICECLASS=ASC0,AVAILABLESIGNATUREENDINDEX=15;
MOD UCELLSIBSWITCH:CELLID=11111,SIBCFGBITMAP=SIB4-1&SIB19-1;
ADD UCELLINTRAFREQHO:RNCID=1011, CELLID=11111, INTRAABLTHDFOR1FECNO=-24, INTRAFREQFILTERCOEF=D3, INTRAFREQMEASQUANTITY=CPICH_EC/NO,PERIODMRREPORTNUMFOR1A=D16,
REPORTINTERVALFOR1A=D1000, PERIODMRREPORTNUMFOR1C=D16, REPORTINTERVALFOR1C=D1000, PERIODMRREPORTNUMFOR1J=D64,REPORTINTERVALFOR1J=D1000, INTRARELTHDFOR1ACSVP=6,
INTRARELTHDFOR1ACSNVP=6, INTRARELTHDFOR1APS=4, INTRARELTHDFOR1BCSVP=12,INTRARELTHDFOR1BCSNVP=12, INTRARELTHDFOR1BPS=8, HYSTFOR1A=0, HYSTFOR1B=0, HYSTFOR1C=8, HYSTFOR1D=8,
HYSTFOR1F=8, HYSTFOR1J=8, WEIGHT=0,TRIGTIME1A=D640, TRIGTIME1B=D1280, TRIGTIME1C=D640, TRIGTIME1D=D640, TRIGTIME1F=D640, TRIGTIME1J=D640, SHOQUALMIN=-24,
MAXCELLINACTIVESET=2,BLINDHORSCP1FTHRESHOLD=-115;
Cell Script Example (Part 2/2)

MOD UCELLCAC:CELLID=11111,MAXHSUPAUSERNUM=60,ULHOCERESVSF=SFOFF,DLHOCECODERESVSF=SFOFF;
MOD UCELLCAC:CELLID=11111,ULNONCTRLTHDFORHO=93,ULCELLTOTALTHD=100;
DEA UCELLHSUPA:CELLID=11111;
MOD UCELLHSUPA:CELLID=11111,EAGCHCODENUM=1,ERGCHEHICHCODENUM=3,MAXTARGETULLOADFACTOR=99;
ACT UCELLHSUPA:CELLID=11111;
MOD UCELLCAC:CELLID=11111,BACKGROUNDNOISE=207,BGNSWITCH=OFF;
MOD UCELLALGOSWITCH:CELLID=11111,NBMULCACALGOSELSWITCH=ALGORITHM_OFF,NBMDLCACALGOSELSWITCH=ALGORITHM_OFF;
MOD UCELLRLPWR:CELLID=11111, CNDOMAINID=PS_DOMAIN, MAXBITRATE=0, RLMAXDLPWR=-50;
MOD UPRACHUUPARAS:CELLID=11111,PHYCHID=4,CONSTANTVALUE=-24,POWERRAMPSTEP=2,PREAMBLERETRANSMAX=20;
MOD UCELLALGOSWITCH:CELLID=11111,NBMLDCALGOSWITCH=UL_UU_LDR-1&DL_UU_LDR-1&CELL_CODE_LDR-1&CELL_CREDIT_LDR-1;
MOD UCELLMEAS:CELLID=11111, INTERFREQINTERRATMEASIND=INTER_FREQ, FACHMEASIND=REQUIRE;
MOD UPCPICHPWR:CELLID=11111,MAXPCPICHPOWER=346,MINPCPICHPOWER=250;
MOD UCELL: CELLID=11111, PCPICHPower=***;
ADD UCELLAMRC: CELLID=11111, GoldMaxMode=NBAMR_BITRATE_4.75K, SilverMaxMode=NBAMR_BITRATE_4.75K, CopperMaxMode=NBAMR_BITRATE_4.75K;
*** Value desired to balance traffic.
LM Script Example Band Comments
MOD UCELLSELRESEL:CELLID=11111,QUALMEAS=CPICH_ECNO,IDLEQHYST1S=1,IDLEQHYST2S=1,TRESELECTIONS=2,QQUALMIN=-18,QRXLEVMIN=-
58,IDLESINTRASEARCH=5,IDLESINTERSEARCH=4,CONNSINTRASEARCH=5,CONNSINTERSEARCH=4,SSEARCHRAT=1,INTERFREQTRESELSCALINGFACTOR=4,INTERRATTRESELS
850
CALINGFACTOR=4,QHYST1SPCH=2,QHYST1SFACH=2,QHYST2SPCH=2,QHYST2SFACH=2,TRESELECTIONSPCH=15,TRESELECTIONSFACH=15,THDPRIORITYSEARCH1=5,THDPRIO
RITYSEARCH2=5;
MOD UCELLSELRESEL:CELLID=11111,QUALMEAS=CPICH_ECNO,IDLEQHYST1S=1,IDLEQHYST2S=1,TRESELECTIONS=2,QQUALMIN=-17,QRXLEVMIN=-
53,IDLESINTRASEARCH=4,IDLESINTERSEARCH=5,CONNSINTRASEARCH=4,CONNSINTERSEARCH=5,SSEARCHRAT=1,INTERFREQTRESELSCALINGFACTOR=4,INTERRATTRESELS
1900Rxlev Min 105
CALINGFACTOR=4,QHYST1SPCH=2,QHYST1SFACH=2,QHYST2SPCH=2,QHYST2SFACH=2,TRESELECTIONSPCH=15,TRESELECTIONSFACH=15,THDPRIORITYSEARCH1=5,THDPRIO
RITYSEARCH2=5;
MOD UINTERFREQNCELL:RNCID=1111, CELLID=11111, NCELLRNCID=1111, NCELLID=11111, IDLEQOFFSET1SN=1, IDLEQOFFSET2SN=1, CONNQOFFSET1SN=1, CONNQOFFSET2SN=1,
850->1900 Rxlev Min 105
SIB11IND=TRUE, SIB12IND=TRUE, INTERNCELLQUALREQFLAG=TRUE,QQUALMIN=-17, QRXLEVMIN=-53;
MOD UINTERFREQNCELL:RNCID=1111, CELLID=11111, NCELLRNCID=1111, NCELLID=11111, SIB11IND=TRUE, IDLEQOFFSET1SN=-5, IDLEQOFFSET2SN=-5, SIB12IND=TRUE,
CONNQOFFSET1SN=-5, CONNQOFFSET2SN=-5, BLINDHOFLAG=TRUE, BLINDHOQUALITYCONDITION=-92, DRDECN0THRESHHOLD=-8, INTERNCELLQUALREQFLAG=TRUE, 1900->850 Blind only to co-sector
QQUALMIN=-18, QRXLEVMIN=-58;
ADD UCELLINTERFREQHOCOV: CELLID=61345, INTERFREQREPORTMODE=EVENT_TRIGGER, INTERFREQFILTERCOEF=D3, HYSTFOR2B=4, HYSTFOR2D=4, HYSTFOR2F=4,
WEIGHTFORUSEDFREQ=0, TIMETOTRIG2B=D0, TIMETOTRIG2D=D320, TIMETOTRIG2F=D1280, INTERFREQCSTHD2DECN0=-15, INTERFREQCSTHD2FECN0=-13,
INTERFREQR99PSTHD2DECN0=-24, INTERFREQHTHD2DECN0=-24, INTERFREQR99PSTHD2FECN0=-22, INTERFREQHTHD2FECN0=-22, INTERFREQCSTHD2DRSCP=-105,
INTERFREQCSTHD2FRSCP=-103, INTERFREQR99PSTHD2DRSCP=-105, INTERFREQHTHD2DRSCP=-105, INTERFREQR99PSTHD2FRSCP=-103, INTERFREQHTHD2FRSCP=-103, 1900HO from 1900 to 850
TARGETFREQCSTHDECN0=-15, TARGETFREQHTHDECN0=-15, TARGETFREQR99PSTHDECN0=-15, TARGETFREQCSTHDRSCP=-100, TARGETFREQHTHDRSCP=-100,
TARGETFREQR99PSTHDRSCP=-100, USEDFREQCSTHDECN0=-15, USEDFREQR99PSTHDECN0=-15, USEDFREQHTHDECN0=-15, USEDFREQCSTHDRSCP=-95,
USEDFREQR99PSTHDRSCP=-95, USEDFREQHTHDRSCP=-95, INTERFREQMEASTIME=60, PERIODFOR2B=1, AMNTOFRPT2B=4, TIMETOINTERFREQHO=0;
MOD UCELLHOCOMM:CELLID=11111, INTERFREQRATSWITCH=SIMINTERFREQRAT, COEXISTMEASTHDCHOICE=COEXIST_MEAS_THD_CHOICE_INTERFREQ,
1900Fast Return
FASTRETURNTOLTESWITCH=PERFENH_PS_FAST_RETURN_LTE_SWITCH-1&HO_UMTS_TO_LTE_FAST_RETURN_SWITCH-1;
MOD UCELLHOCOMM:CELLID=11111, INTERFREQRATSWITCH=SIMINTERFREQRAT, COEXISTMEASTHDCHOICE=COEXIST_MEAS_THD_CHOICE_INTERRAT,
850Fast Return & IRAT
FASTRETURNTOLTESWITCH=PERFENH_PS_FAST_RETURN_LTE_SWITCH-1&HO_UMTS_TO_LTE_FAST_RETURN_SWITCH-1;
Thank you
Follow us on:
For more information on Qualcomm, visit us at:
www.qualcomm.com and www.qualcomm.com/blog

Massive Events Guideline: Huawei Infrastructure

Uploaded by

Document Information

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

Massive Events Guideline: Huawei Infrastructure

Uploaded by

Copyright:

Available Formats

Qualcomm Technologies, Inc.

Claro Peru, March of 2015

© 2013 Qualcomm Global Services, Inc.

Massive Events Guideline – Huawei Infrastructure

DAS RFP Development Design & Dimensioning Event Preparation &

RNC Wide Cluster Wide

Early Preparation - Optimization Mass Event Week Mass Event Day

Stadium Design for Operator A

Maximum Hardware Capacity Clean Installation

Events Baseline Live Monitoring

DAS Performance and optimization is imperative for good user experience

Passive Intermodulation (PIM) is the result of inter-

It occurs typically on bad metal-to-metal connections (usually

It is specially damaging when the resulting power can be

OCNS (Orthogonal Channel Noise Simulator) can easily

Check if any sector-carrier is having higher than -

Verify the connections and identify DAS route of this

Use VSWR measurements or Cable distance to fault

Health check of identified elements (change faulty

Similar procedure is done for Active DAS, however,

Verify the connections and identify DAS route of this

Verify the Master Unit (MU) and Remote Unit (RU)

A common procedure to “improve” the RTWP performance, is to increase the

Extra UL attenuation also generates imbalance in

It becomes visible on field tests while comparing

Not only the presented problems during access will

DL PL= CPICH (SIB5) - RSCPmeas

- Scanner for all 3G bands.

live monitoring SITE02 - Estadio Nacional

be retrieved SITE13 - External COW

actions, traffic redirection, etc.. SITE13 - External COW

36 cells to monitored at the same time SITE12 - Access COW

T-240 Implementation of Game Day baseline

Good RTWP Good RTWP Bad RTWP

Bad RTWP Bad RTWP

Important Definitions for Layer Management Analysis

CORE Cells IF Border Cells IRAT Border Cells

The strategy will keep the LTE->UMTS mobility only to

To enhance UMTS capacity a new 1900MHz carrier will be

Mobility between GSM and all UMTS carriers will be allowed

CS Coverage Handovers shall be enabled for:

Load Balance (DRD) shall be enabled for:

Emergency mechanisms to offload traffic from UMTS to GSM

The newly activated 1900 MHz carrier naturally have better

To avoid unbalance between the two bands and 1900MHz

-7 Search In terf requ en cy R1900 R8 50 + 3dB > R1900

-15 Search IRAT

Optimization Goals: eliminate/reduce Compressed Mode

Channels: Downlink DCH, Channels: FACH, RACH

State Transitions and DCCC are key points of the Parameters

These parameters are available only at RNC-level, therefore,

The basis for the State Transitions parameterization is the

It is essential that the RNCs hosting Massive Events have the

For the DCCC optimization, the Massive Events parameterization

Optimization Goals: reduce resources consumption on DCH/HS

The DL DPCH (Dedicated Physical Channel) carries the

On the DL DPCCH, there is a Pilot (PO3) signal used for

DPDCH DPCCH DPDCH DPCCH

WCDMA heavily relies on Power Control for its operation. The

The Outer Loop, located at the RNC, calculates the BLER of

The Inner Loop, located at the NodeB, calculates the SIR of

Admitting larger BLERtarget and reduced SIRtarget it is

It is important to disable PS R99 RABs with high data rates