W-CDMA UA07 HSxPA QoS Analysis and Traffic Load Monitoring - tmo18269D0SGDENI1.0

9300 W-CDMA
UA07 HSxPA QoS Analysis and

Traffic Load Monitoring
TMO18269 D0 SG DEN 1.0
Issue 1.0
STUDENT GUIDE
All Rights Reserved © Alcatel-Lucent 2010
All rights reserved © Alcatel-Lucent 2010

Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent

UA07 HSxPA QoS Analysis and Traffic Load Monitoring - Page 1
Empty page
Switch to notes view!
2 All Rights Reserved © Alcatel-Lucent 2010

9300 W-CDMA
UA07 HSxPA QoS Analysis and Traffic Load Monitoring
This page is left blank intentionally

Terms of Use and Legal Notices
1. Safetyto
Switch Warning
notes view!
Both lethal and dangerous voltages may be present within the products used herein. The user is strongly advised not to
wear conductive jewelry while working on the products. Always observe all safety precautions and do not work on the
equipment alone.
The equipment used during this course may be electrostatic sensitive. Please observe correct anti-static precautions.
2. Trade Marks
Alcatel-Lucent and MainStreet are trademarks of Alcatel-Lucent.
All other trademarks, service marks and logos (“Marks”) are the property of their respective holders, including Alcatel-
Lucent. Users are not permitted to use these Marks without the prior consent of Alcatel-Lucent or such third party owning
the Mark. The absence of a Mark identifier is not a representation that a particular product or service name is not a Mark.
Alcatel-Lucent assumes no responsibility for the accuracy of the information presented herein, which may be subject to
change without notice.
3. Copyright
This document contains information that is proprietary to Alcatel-Lucent and may be used for training purposes only. No
other use or transmission of all or any part of this document is permitted without Alcatel-Lucent’s written permission, and
must include all copyright and other proprietary notices. No other use or transmission of all or any part of its contents may
be used, copied, disclosed or conveyed to any party in any manner whatsoever without prior written permission from
Alcatel-Lucent.
Use or transmission of all or any part of this document in violation of any applicable legislation is hereby expressly
prohibited.
User obtains no rights in the information or in any product, process, technology or trademark which it includes or
describes, and is expressly prohibited from modifying the information or creating derivative works without the express
3written consent of Alcatel-Lucent. All Rights Reserved © Alcatel-Lucent 2010
9300 W-CDMA
4. Disclaimer
In no event will Alcatel-Lucent be liable for any direct, indirect, special, incidental or consequential damages, including
lost profits, lost business or lost data, resulting from the use of or reliance upon the information, whether or not Alcatel-
Lucent has been advised of the possibility of such damages.
Mention of non-Alcatel-Lucent products or services is for information purposes only and constitutes neither an
endorsement, nor a recommendation.
This course is intended to train the student about the overall look, feel, and use of Alcatel-Lucent products. The
information contained herein is representational only. In the interest of file size, simplicity, and compatibility and, in some
cases, due to contractual limitations, certain compromises have been made and therefore some features are not entirely
accurate.
Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-Lucent equipment
and its operation, or contact your nearest Alcatel-Lucent representative for more information.
The Alcatel-Lucent products described or used herein are presented for demonstration and training purposes only. Alcatel-
Lucent disclaims any warranties in connection with the products as used and described in the courses or the related
documentation, whether express, implied, or statutory. Alcatel-Lucent specifically disclaims all implied warranties,
including warranties of merchantability, non-infringement and fitness for a particular purpose, or arising from a course of
dealing, usage or trade practice.
Alcatel-Lucent is not responsible for any failures caused by: server errors, misdirected or redirected transmissions, failed
internet connections, interruptions, any computer virus or any other technical defect, whether human or technical in
nature
5. Governing Law
The products, documentation and information contained herein, as well as these Terms of Use and Legal Notices are
governed by the laws of France, excluding its conflict of law rules. If any provision of these Terms of Use and Legal
Notices, or the application thereof to any person or circumstances, is held invalid for any reason, unenforceable including,
but not limited to, the warranty disclaimers and liability limitations, then such provision shall be deemed superseded by a
valid, enforceable provision that matches, as closely as possible, the original provision, and the other provisions of these
Terms of Use and Legal Notices shall remain in full force and effect.

Blank Page

9300 W-CDMA

Course Outline
1. HSDPA
About Performance Monitoring
This Course 4. Topic/Section is Positioned Here
1. Module 1
Course outline
Technical support
2. HSUPA Performance Monitoring 5. Topic/Section is Positioned Here
Course objectives
1. Module 1
1. Topic/Section is Positioned Here 6. Topic/Section is Positioned Here
Xxx
Xxx 7. Topic/Section is Positioned Here
Xxx
2. Topic/Section is Positioned Here
3. Topic/Section is Positioned Here

9300 W-CDMA

Course Outline [cont.]

9300 W-CDMA

Course Objectives
Welcome to UA07 HSxPA QoS Analysis and Traffic Load Monitoring
Upon completion of this course, you should be able to:
identify why, when, and how to make performance management

define HSPA counters, metrics, and explain how to use metrics,
illustrate the call flows associated with each metric family, identify the counters and locate
them in the call flow procedure
monitor traffic load with KPI.

9300 W-CDMA

Course Objectives [cont.]

9300 W-CDMA

About this Student Guide

Conventions
Switch used
to notes in this guide
view!
Note
Provides you with additional information about the topic being discussed.
Although this information is not required knowledge, you might find it useful
or interesting.
Technical Reference
(1) 24.348.98 – Points you to the exact section of Alcatel-Lucent Technical
Practices where you can find more information on the topic being discussed.
Warning
Alerts you to instances where non-compliance could result in equipment
damage or personal injury.
Where you can get further information

9300 W-CDMA
If you want further information you can refer to the following:

Technical Practices for the specific product
Technical support page on the Alcatel website: http://www.alcatel-lucent.com

About this Student Guide [cont.]

9300 W-CDMA

Self-assessment of Objectives
Contract number :
At the end of each section you will be asked to fill this questionnaire
Course title :
Please, return this sheet to the trainer at the end of the training
Client (Company, Center) :
Language :
Switch to notes view! Dates from : to :
Number of trainees : Location :
Surname, First name :
Did you meet the following objectives ?

Tick the corresponding box
Please, return this sheet to the trainer at the end of the training
Yes (or No (or

Instructional objectives globally globally Comments
yes) no)
1 To be able to XXX
2
9300 W-CDMA

Self-assessment of Objectives [cont.]
Yes (or No (or

Instructional objectives Globally globally Comments
yes) no)

9300 W-CDMA
Other comments
Thank you for your answers to this questionnaire


Do not delete this graphic elements in here:
Section 1
1 HSDPA Performance
Monitoring
Module 1
3JK11652AAAAWBZZA Edition 3.0
9300 W-CDMA
TMO18269 D0 SG DEN Edition 1.0

Section 1 Pager 1
Blank Page

HSDPA Performance Monitoring
9300 W-CDMA UA07 HSxPA QoS Analysis and Traffic Load Monitoring
Document History
Edition Date Author Remarks
01 2008-12-01 El Abed, Jean-Noel First edition
01.1 2009-03-18 Kieslich, Roland Update to Rel. UA06

Debergh, Pierre Draft 3.2
Charneau, Jean-Noel with Deltas between UA05 (Slides ….R5) and
UA06 (Slides … R6)
02 2009-04-10 Charneau, Jean-Noel Few editorial updates
03 2010-04-28 Nolan, Vincent Update to UA07

Section 1 Pager 2
Module Objectives
Upon completion of this module, you should be able to:
Describe HSDPA main KPIs families

Understand the main metrics of HSDPA Accessibility, Retainability, Quality,
Traffic and mobility.


Section 1 Pager 3
Module Objectives [cont.]


Section 1 Pager 4
Table of Contents
Page
1 HSDPA Performance Monitoring 7
1.1 HSDPA Distributed Architecture 8
1.2 Cell Topologies in networks 9
1.3 HSDPA Main KPIs 10
1.4 HSDPA Monitoring main challenges 11
2 HSDPA Accessibility Monitoring 12
2.1 Accessibility Flow Diagrams 13
2.2 RAB Matching and CAC 14
2.3 HSDPA to DCH Fallback 15
2.4 RAB Assignment Success: Counters 16
2.5 CAC dependencies 17
2.6 HSDPA Accessibility: Indicators 18
3 Retainability Monitoring 21
3.1 Call Drop 22
3.1.1 RL Failure detected by RNC 23
3.1.2 RLC Unrecoverable Error detected by UE on SRB 24
3.1.3 Call Drops due to UTRAN generated reasons 25
3.2 HSDPA Call Drop Rate 26
3.3 Exercise - HSDPA Call Drop per Minute of Call 27
4 HSDPA Mobility Monitoring 28
4.1 Outgoing HSDPA Mobility Scenarios 29
4.2 Outgoing HSDPA Mobility Success Rate 30
4.3 Incoming HSDPA Mobility Scenarios 31
4.4 Incoming HSDPA Mobility Success Rate 32
15 4.5 HSDPA/DCH transitions – HDSPAAllPrimary Cell Change
Rights Reserved © Alcatel-Lucent 2010
33
5 HSDPA
9300 W-CDMA Capacity
UA07 HSxPA Monitoring
QoS Analysis and Traffic Load Monitoring 34
5.1 HSDPA Power Monitoring 35
5.2 HSDPA Power: Counter 36
5.3 HSDPA Power: Indicators 37
5.4 HSDPA Codes and Users: Indicators 40
6 HSDPA Traffic Monitoring 41
6.1 HSDPA Calls, Activity, RLC SDU Throughput 42
6.2 User-Perceived Throughput Counter 43
6.3 HSDPA Call Duration, Traffic Penetration 44
6.4 Hsdpa Call Attempts Per Category 45
6.5 HSDPA UE Category Penetration 46
6.6 64 QAM Counters 47
6.7 64 QAM Indicators 48
7 HSDPA Quality Monitoring 49
7.1 HSDPA RLC PDU Mac-d & Mac-hs Throughput, BLER 50
7.2 HSDPA HARQ Feedback Distribution: ACK/NACK/DTX 51
7.3 HSDPA CQI Distribution 52
8 GBR on HSDPA & Fair Sharing 53
8.1 GBR Performance metrics 54
8.2 GBR and Fair Sharing performance troubleshooting 56
8.2.1 Mac-hs GBR fulfilled or not ? 57
8.2.2 HSDPA Cell Throughput Degradation 58
8.2.3 RNC CAC Unsuccess increase 59
Module Summary 60
Self-assessment on the Objectives 61
End of Module 62

Section 1 Pager 5
Table of Contents [cont.]
Page


Section 1 Pager 6
1 HSDPA Performance Monitoring


Section 1 Pager 7
1.1 HSDPA Distributed Architecture
SP128
HS-PDSCH HS-SCCH
Data Transfer (PS I/B) Downlink Transfer Information
(UEid, OVSF,...) Introduction of MAC-hs
SP16 TTI2ms
RNC
Iub
HS-DPCCH
DPCH Feedback Information
Upper Layer Signaling (CQI, ACK/NACK)
New Transport channel New Frame Protocols

HS-DSCH HS-DSCH
RLC RLC
MAC-d MAC-d
HS-DSCH Flow control HS-DSCH
MAC-hs MAC-hs FP FP
L2 L2
PHY Uu PHY L1 Iub L1
UE NodeB RNC
HSDPA is an increment on UTRAN procedures, and is fully compatible with R4 layer 1 and layer 2. It is
based on the introduction of a new MAC entity (MAC-hs) in the Node B, that is in charge of scheduling
/ repeating the data on a new physical channel (HS-DSCH) shared between all users.
This has a minor impact on network architecture. There is no impact on RLC protocol and HSDPA is
compatible with all transport options (AAL2 and IP).
On the Node B side, MAC-hs layer provides the following functionalities:

Fast repetition layer handled by HARQ processes
Adaptive Modulation and Coding
New transport channel High Speed Downlink Shared Channel (HS-DSCH)
Flow control procedure to manage Node B buffering
Some new L1 new functionalities are introduced compared to R4:

3 new physical channels: HS-PDSCH to send DL data, HS-SCCH to send DL control information
relative to HS-PDSCH, and HS-DPCCH to receive UL control information
New channel coding chain for HS-DSCH transport channel and HS-SCCH physical channel

Section 1 Pager 8
1.2 Cell Topologies in networks
3 cell topologies are currently deployed in the networks:
One Frequency with only R99 traffic: R99

Represented in this document by
Do not carry any HSDPA traffic
One Frequency with HSDPA/ R99: R99 / HSDPA

Represented in this document by
R99 and HSDPA traffic are cohabiting on the same frequency
Only 5 OVSF DL SF16 codes statistically booked & mainly 1 PCM deployed
Two Frequencies with HSDPA/ R99: HSDPA HSDPA
Represented in this document by R99 R99 / HSDPA

HSDPA traffic is carried on a dedicated carrier
10 OVSF DL SF16 codes statistically booked & more than 1 PCM generally
deployed
Mostly STSR2 deployed and very few STSR1+1
Assumption: HSUPA is activated wherever HSDPA is activated

-> Configurations using only HSDPA or only HSUPA are not treated

Section 1 Pager 9
1.3 HSDPA Main KPIs
Network
Mobility
Network Network
Accessibility Retainability
HSDPA KPIs
Network
Network Quality
Traffic
Capacity
1 10 All Rights Reserved © Alcatel-Lucent 2010
The following performance domains will be covering:

Accessibility: what is the success rate for the HSxPA RB to access the network resources?
Retainability: what is success rate for the HSxPA RB to end normally? How long time the HSxPA RB can
remain without dropping in a cell?
Mobility: What is the mobility success rate for HSxPA RB?
Capacity: HSxPA could consume high network resources capacity (e.g. high power usage). What is the
part HSxPA radio resources shared?
Traffic: What is the amount of HSxPA traffic and the HSxPA activity duration?
Quality: Key metrics. What is the throughput provided based on radio quality and on limitations?
For all the metrics listed, it is recommended to monitor daily during at least 2 weeks before analyzing
results and take the appropriate actions.

Section 1 Pager 10
1.4 HSDPA Monitoring main challenges
HSDPA is a key technology for operators and then is a key interest for
monitoring
HSDPA is based on a high throughput radio bearer that can lead to

the saturation of radio resources and degradation of RF conditions
Then for the monitoring of HSDPA specific focus will be made on

Capacity
E.g : Power/Code usage
PS Performance
E.g: Throughput
BLER


Section 1 Pager 11
2 HSDPA Accessibility Monitoring


Section 1 Pager 12
2.1 Accessibility Flow Diagrams
UE Node B RNC CN
RRC Connection Request
Radio Link Setup Request
RRC connection
Radio Link Setup Response

RRC Connection Setup
RRC Connection Complete
Measurement Control
Init Direct Transfer
SCCP connection req.
conn.
SCCP
SCCP connection confirm
Security mode command

Security
Security mode command

mode
Common id
Security mode complete
Security mode complete
RAB assignment req.
established
S.R.L.R. Procedure
RAB
Radio Bearer Setup

Radio Bearer Setup Complete RAB assignment response

S.R.L.R. : Synchronized Radio Link Reconfiguration

Section 1 Pager 13
2.2 RAB Matching and CAC
RAB Request RNC
Service = PS? NO
YES
TrafficClass=Str/I/B? NO
YES
HSDPA UE? NO
YES
Primary Cell = HSDPA Cell? NO
YES
HSDPA RAB R99 RAB
HSDPA CAC
In UA6.0, if the Fair Sharing is disabled, the CAC is based on the number of HSDPA users as in the previous releases
(isHsxpaR99ResourcesSharingOnCellAllowed = False):
Any PS Interactive/Background RAB request is admitted on HSDPA until the maximum number of simultaneous
users allowed on HSDPA is reached for the cell.
PS Streaming must be disabled on HSDPA if Fair Sharing is deactivated as GBR can not be guaranteed.
RNC CAC:
maximumNumberOfUsers is the maximum number of HSDPA users per cell. By default this parameter is set to 100
(when the value is set to 100 the RNC CAC is deactivated, i.e. Node-B performs the Call Admission Control). Note
that even if it is different than 100, RNC CAC based on the number of HSDPA users is deactivated when Fair
Sharing feature is enabled (isHsxpaR99ResourcesSharingOnCellAllowed = True).
BTS CAC:
Once the RNC CAC passed, the Node-B is requested for CEM resources allocation through Radio Link
Reconfiguration procedure
The HSDPA CEM resources is handled by the H-BBU function for the iCEM or the M-BBU for the xCEM
If the H-BBU or M-BBU limit is reached, the BTS will send a RL Reconfiguration Failure (meaning NodeB CAC failure)
The BTS limits the number of simultaneous HS-DSCH radio-links because of limited processing capacity. If the limit
is reached, the radio-link setup/reconfiguration is rejected. This leads to a RAB reject by the RNC.
BTS rejects when the current number of HSDPA users managed by the H-BBU is equal to
hsdpaMaxNumberUserHbbu parameter value or when the current number of HSDPA users managed by the xCEM
is equal to hsdpaMaxNumberUserXcem parameter value.
In UA6.0 the hsdpaMaxNumberUserPerNodeB is no more used. It becomes obsolete after introduction of new
capacity licensing parameters.
Any PS RAB with Streaming traffic class with requested DL GBR > 0 is matched to the HSDPA RB configuration if the
mobile is HSDPA capable, the primary cell of the active set supports HSDPA and GBR feature is enabled
(isGbrOnHsdpaAllowed = True).

Section 1 Pager 14
2.3 HSDPA to DCH Fallback
RAB assignment (to establish or to release)
RabAssignment
IU release
Primary cell change Mobility

Incoming Inter-RNC UE involved Hard Handover
Incoming Intra-RNC Alarm Hard Handover
HSDPA RB
#958[all]
to be established
HSDPA CAC unsuccess
No HSDPA to DCH Fallback

CAC OK ?
Success Unsuccess
#957
HSDPA CAC success Yes
HSDPA RB DCH RB RB
established established not established
#1650[15,16] #1601[0,2] #1603[0,1]

RB setup success HSDPA fallback success HSDPA fallback unsuccess

HSPA to DCH fallback feature allows to establish or reconfigure the PS I/B RAB into DCH in case of
HSDPA or HSUPA CAC failure. The following HSxPA CAC failure scenarios trigger such a fallback:
RAB assignment (to establish or to release)
IU release
Primary cell change
Inter-RNC UE involved Hard Handover
Alarm Hard Handover
If for whatever reason the CAC fails when allocating the new radio bearer on HS-DSCH, the RNC will try
to fallback the radio bearer on DCH (this may be deactivated by the operator).
In this case, the RAB matching will be played again on DCH as if the mobile was not HSDPA capable. If
the output of the iRM table is “reject” then the fallback will not be attempted and the RAB will be
rejected.
If the call admission on DCH rejects the fallback then the RAB will be rejected (but the existing ones
will be kept), except if there is another layer, in which case iMCTA (for CAC failure reason) is played.
If the UE has already a PS I/B RAB mapped on HS-DSCH then the RNC will try also to reconfigure this
one to DCH. If the CAC fails on the new configuration only the new RAB will be rejected (iMCTA may
be also played) but the existing ones will be kept.
RNC tries and remaps a call establish “fall-backed to DCH RAB” onto HSDPA or HSUPA in the following
cases:
RAB assignment (to establish or to release a second RAB)
Primary Cell change
Inter-RNC (UE involved or not) HHO
In UA6.0, if Fair Sharing is enabled, HSDPA CAC may be based on resource consumption (power and
codes) in order to guarantee a given HSDPA QoS to each HSDPA user (ranap GBR or minBR). In this
case, HSxPA-to-DCH fallback is not allowed when CAC occurs for shared resources (DL OVSF codes or
DL power).
Section 1 Pager 15
2.4 RAB Assignment Success: Counters
UE Node B RNC CN
FDDCell counter
#1652[15,16] RAB assignment req.
RB Setup request
Internal RRM
decision to assign
resources
S.R.L.R. Procedure
established
RAB
Radio Bearer Setup
Radio Bearer Setup Complete

#1650[15,16]
RB setup success
RNC counter
#1658[0,4-9]
RAB establishment success per
Granted RAB type RAB assignment response

VS.RadioBearerSetupRequest #1652 :
Number of Radio-Bearer establishments to be performed following a valid RAB assignment request
received from the CN. This measurement provides the number of RB to be setup before CAC is carried
out.
•Sub-Counter #15: HSDPA/R99
•Sub-Counter #16: PS I/B or PS Str HSDPA/E-DCH
VS.RadioBearerSetupSuccess #1650: Number of successful Radio-Bearer establishments. This

measurement provides the number of successful RB setup.
•Sub-Counter #15: HSDPA/R99

•Sub-Counter #16: PS I/B or PS Str HSDPA/E-DCH
VS.RabEstablishmentSuccessPerGrantedRabType #1658: Number of successful RAB establishments per

Granted RAB type. This measurement provides the number of successful RAB establishment per RAB type
as granted by the UTRAN.
•Sub-Counter #4: Dl is any low rate PS I/B, Ul is any PS I/B, TC is Interactive

•Sub-Counter #5: Dl is any low rate PS I/B, Ul is any PS I/B, TC is Background
•Sub-Counter #6: Dl is any high rate PS I/B, Ul is any PS I/B, TC is Interactive
•Sub-Counter #7: Dl is any high rate PS I/B, Ul is any PS I/B, TC is Background
•Sub-Counter #8: Dl is any low rate Ps Str and Ul is any PS Str, TC is Streaming
•Sub-Counter #9: Dl is any high rate Ps Str and Ul is any PS Str, TC is Streaming

Section 1 Pager 16
2.5 CAC dependencies
If Fair Sharing is disabled

the only admission control done for HSDPA RB is based on the
maximum number of simultaneous users allowed
a HSDPA RB can not be rejected by the RNC for lack of network
resources (Power, OVSF Codes, Iub ATM (EBR=0))
in case of CAC failure, the feature HSPA to DCH Fallback allows to
setup the RAB using a DCH RB instead of the HS-DSCH RB
If Fair Sharing is enabled

an admission control is performed on
DL OVSF codes
DL power
in case of CAC failure on these shared resources, the HSPA to DCH
Fallback is not allowed


Section 1 Pager 17
2.6 HSDPA Accessibility: Indicators
Reference FDDCell metric UHSDPA002_CR
HSDPA
HSDPACAC
CACFailed Admission == #958.[all]
FailedAdmission #958.[all]
#958.[all]
HSDPA
HSDPACAC
CACFailure
FailureRate
Rate ==
#957 + #958.[all]

VS.HsdpaCACUnsuccessful - #958
Unsuccessful access to the cell for an HSDPA call during mobility or establishment procedure.
A set of sub counters screened on: Reason for the HSDPA CAC failure
• Sub-Counter #0 : Maximum number of HSDPA users exceeded
• Sub-Counter #1 : Maximum number of Streaming HSDPA users exceeded
• Sub-Counter #2 : Maximum Aggregated GBR exceeded
As Streaming service on HSDPA is not implemented in former releases, sub-counters s1 and s2 are equal
to 0.
VS.HsdpaCACSuccess - #957
Successful access to the cell for an HSDPA call during mobility, establishment or reconfiguration from
DCH to HSDPA procedure.

Section 1 Pager 18
2.6 HSDPA Accessibility: Indicators [cont.]
Reference FDDCell metric UHSDPA047_C_HsdpaDch

Successful
SuccessfulFallback
Fallback
#1601.[0]
from HSDPA/DCH =
from HSDPA/DCH
to
toDCH/DCH
DCH/DCH
Reference FDDCell metric UHSDPA047_C_HsdpaEdch

Successful
SuccessfulFallback
Fallback
from HSDPA/EDCH
from HSDPA/EDCH = #1601.[1,2]
to
toDCH/DCH
DCH/DCH
or HSDPA/DCH
or HSDPA/DCH
Reference FDDCell metric UHSDPA046_C

Proportion
Proportion #1601.[0-2]
of
ofHSDPA
HSDPA//HSUPA
HSUPA =
Fallback
Fallback #1650.[15,16] + #1601.[0-2] + #1603.[0,1]

VS.SucHspaToDchFallbackCell - #1601
Number of calls successfully fallbacked from HSPA to DCH on RAB assignment, mobility or reconfiguration
event.
• Sub-Counter #0 : DL:HSDPA/UL:DCH to DL:DCH/UL:DCH
• Sub-Counter #1 : DL:HSDPA/UL:E-DCH to DL:HSDPA/UL:DCH
• Sub-Counter #2 : DL:HSDPA/UL:E-DCH to DL:DCH/UL:DCH
VS.UnsucHspaToDchFallbackCell - #1603
Number of calls unsuccessfully fallbacked from HSPA to DCH on RAB assignment, mobility or reconfiguration
event.
• Sub-Counter #0 : DL:HSDPA/UL:DCH fallback
• Sub-Counter #1 : DL:HSDPA/UL:E-DCH fallback
VS.RadioBearerSetupSuccess - #1650
Number of Radio Bearer setup successfully. The counter should be pegged multiple times for multiple RB
successfully setup in the same procedure. Incremented on the Reference cell of the call.
• Sub-Counter #15: HSDPA/R99
• Sub-Counter #16: PS I/B or PS Str HSDPA/E-DCH

Section 1 Pager 19
2.6 HSDPA Accessibility: Indicators [cont.]
RNC metric URAB022_R_Ps
RAB
RABAssignment
AssignmentSuccess
Success
per
per Granted RABtype
Granted RAB type = #1658.[4-9]
PS calls
PS calls
Reference FDDCell metric URB008_C_HSDPA
Radio
RadioBearer
Bearerto
tobe
beSetup
Setup = #1652.[15,16]
HSDPA
HSDPA
HSDPA #1650.[15,16]
HSDPARadio
RadioBearer
Bearer =
to
to be Setup SuccessRate
be Setup Success Rate #1652.[15,16]
=

VS.RabEstablishmentSuccessPerGrantedRabType - #1658
the number of successful RAB establishment, screened per granted RAB type. Granted should be understood as
after RNC CAC (iRM..). On reception of a RANAP RAB Assignment Response message.
• Sub-Counter #4: Dl is any low rate PS I/B, Ul is any PS I/B, TC is Interactive
• Sub-Counter #5: Dl is any low rate PS I/B, Ul is any PS I/B, TC is Background
• Sub-Counter #6: Dl is any high rate PS I/B, Ul is any PS I/B, TC is Interactive
• Sub-Counter #7: Dl is any high rate PS I/B, Ul is any PS I/B, TC is Background
• Sub-Counter #8: Dl is any low rate Ps Str and Ul is any PS Str, TC is Streaming
• Sub-Counter #9: Dl is any high rate Ps Str and Ul is any PS Str, TC is Streaming
VS.RadioBearerSetupRequest - #1652
The number of Radio Bearer setup decisions by the RNC, incremented based on reference cell.
It counts based on the requested Downlink AsConfID ((DL Access stratum Configuration) . Before CR Q01244717,
counters was pegged based on targetDlAsconfId (obtained as output of IRM algorithm), therefore could not be
pegged in case of CAC rejection. Since CR Q01244717,
counter is pegged accordingly to the requested Downlink AsConfId, then allowing pegging also in case of CAC
rejection.
A set of sub counters screened on: Target Type of call setup mapping:

Section 1 Pager 20
3 Retainability Monitoring


Section 1 Pager 21
3.1 Call Drop
The objective of the retainability metrics is to evaluate the ability of

the network to provide reliable service to the end user.
If and only if a call is dropped, the RNC sends the RANAP Iu Release
Request message with the field abnormal reasons.
Most of the call drops are due to Radio Problems between UE and
UTRAN


Section 1 Pager 22
3.1 Call Drop
3.1.1 RL Failure detected by RNC
UE Node B RNC CN
Loss of UL synchro FDDCell counter

detected on last RL
Radio Link
Failure Indication
rrcReestPSMaxAllowedTimer
expiry
Iu Release Request
#599[6] Iu release request PS “radio connection with UE
lost”
Reference FDDCell counters Iu Release Command
#589[13] Iu abnormal release request PS
Radio Link Reference FDDCell counters

Question: Deletion Request
What is the difference
Radio Link
between #599 & #589 ? Deletion Response Iu Release Complete
VS.IuReleaseReqPs - #599
A set of sub counters screened on: Release Request Cause PS
• Sub-Counter #0 : User Inactivity
• Sub-Counter #1 : IU User Plane Failure
• Sub-Counter #2 : OAM Intervention
•…
• Sub-Counter #6: Radio cnx with UE lost
• Sub-Counter #9: UL RLC error on SRB
• Sub-Counter #20: UTRAN Paging Failure pegged whenever the number of paging retries reaches zero -
on the FDDcell MO
• Sub-Counter #21: Physical Channel Re-establishment failure pegged on Cell Update cause Radio Link
failure in response to a Cell Update confirm message - on the cell the Cell Update message was received
VS.IuAbnormalReleaseRequestPs - #589
This measurement represents the number of Iu PS release requests due to abnormal conditions.
A set of sub counters screened on: Derived AsConf Screening for PS DlAsConfId:
• Sub-Counter #0: Other type of Call
• Sub-Counter #1: Signalling Only
•
• Sub-Counter #12: PS I/B 384
• Sub-Counter #13: HSDPA
• Sub-Counter #14: xPCH
• Sub-Counter #15: Any CS
Therefore the number of Call drop HSDPA corresponds to sub-counter
VS.IuAbnormalReleaseRequestPs.#13

Section 1 Pager 23
3.1 Call Drop
3.1.2 RLC Unrecoverable Error detected by UE on SRB
UE Node B RNC CN
RLC failure
detected on SRB Reference FDDCell counters
Cell Update
“RLC unrecoverable error, RLC_AM SRB”
Iu Release Request
#599[9] Iu release request PS “UTRAN generated reason”
Iu Release Command
#589[13] Iu abnormal release request PS
Radio Link
Deletion Request
Radio Link
Deletion Response Iu Release Complete

VS.IuReleaseCompleteCs #593: Number of times the RNC sends an Iu release complete on Iu-CS
interface to MSC. It corresponds to all cases of Iu release scenario, normal and abnormal.
Screening: DlAsConfId
A set of sub counters screened on: Derived AsConf Screening for CS DlAsConfId , see also Annex:
T10
• Sub-Counter #0: Other
• Sub-Counter #2: CS speech NB or LR AMR
• Sub-Counter #3: CS speech WB AMR
• Sub-Counter #4: CS data
• Sub-Counter #5: CS Streaming 57.6
• Sub-Counter #6: CS Streaming 14.4
• Sub-Counter #7: Any PS
• VS.IuReleaseCompleteCsNrnc.DlAsCnfOther
• VS.IuReleaseCompleteCsNrnc.DlAsCnfSig
• VS.IuReleaseCompleteCsNrnc.DlAsCnfCsSpeechNbLrAmr
• VS.IuReleaseCompleteCsNrnc.DlAsCnfCsSpeechWbAmr
• VS.IuReleaseCompleteCsNrnc.DlAsCnfCsData
• VS.IuReleaseCompleteCsNrnc.DlAsCnfCsStr57_6
• VS.IuReleaseCompleteCsNrnc.DlAsCnfCsStr14_4

Section 1 Pager 24
3.1 Call Drop
3.1.3 Call Drops due to UTRAN generated reasons
Reference FDDCell counters
Any Iu-PS Release Request message sent, due to an abnormal or normal

cause, when an HSDPA call is established, is counted as for any other
RAB in
VS.IuReleaseReqPs #599
Normal cause screenings:
#0: User inactivity (Always-On to PMM-Idle)
#5: UE generated signaling cnx release BLACKBERRY UE
#15: no remaining RAB
Abnormal cause screenings: any other
All call drops generated by UTRAN are counted each time an Iu-PS
Release Request message is sent due to an abnormal cause, when an
HSDPA call is established, in
VS.IuAbnormRelReqPs #589[13]
Each HSDPA RAB dropped leads to peg this sub-counter

This measurement represents the number of Iu PS release requests due to abnormal conditions.
A set of sub counters screened on: Derived AsConf Screening for PS DlAsConfId:
• Sub-Counter #0: Other type of Call
• Sub-Counter #2: PS Streaming < 64
• Sub-Counter #3: PS Streaming 64
• Sub-Counter #7: TRB on cell FACH
• Sub-Counter #8: PS I/B < 64
• Sub-Counter #13: HSDPA
• Sub-Counter #14: xPCH
• Sub-Counter #15: Any CS
Therefore the number of Call drop HSDPA corresponds to sub-counter

VS.IuAbnormalReleaseRequestPs.#13

Section 1 Pager 25
3.2 HSDPA Call Drop Rate
HSDPA call drop rate at Cell level (can be also computed at RNC level)
Number of Iu abnormal release request PS [HSDPA]

Number of HSDPA RBs released in the cell
HSDPA RAB #589.[13] HSDPA RAB #1647.[15+16] HSDPA RAB

Drop to be established Release
#1743.[1]
#954.[0] HS-DSCH -> DCH
on RAB setup
#954.[1] on RAB release
HS-DSCH -> FACH #1715.[1]
PS:
TRB (FINISHED)
+SRB (NOT YET
FINISHED)
--->> DCH
Number of Iu PS release requests due to abnormal conditions. • Sub-Counter #13: HSDPA
VS.RadioBearerReleaseSuccess - #1647
Number of successful radio bearer releases. • • Sub-Counter #15: HSDPA/R99 / • Sub-Counter #16: PS I/B
or PS Str HSDPA/E-DCH
VS.DownsizingStep1Success - # 1715
Number of downsizing step 1 successes. • Sub-Counter #1 : HSDPA
VS.UpsizingSuccess - #1743
Number of successful upsizings. • Sub-Counter #1: HSDPA

Section 1 Pager 26
3.3 Exercise - HSDPA Call Drop per Minute of Call
Find the formula of the metric:
Nb of HSDPA Call Drops per Minute of Call
Number of HSDPA call drops

Total HSDPA RAB duration
Reference FDDCell metric UIU019_C_HSDPA
Nb of HSDPA Call Drop # 589.[13]

= 600 x
per Minute of Call # 1666[20].Cum


Section 1 Pager 27
4 HSDPA Mobility Monitoring


Section 1 Pager 28
4.1 Outgoing HSDPA Mobility Scenarios
RNC
HSDPA cell HSDPA cell
R99/HSDPA
R99 cell
cell

Traffic Segmentation feature allows to deal with a multi-layer scenario where HSDPA is available in only
one of the layers.
Mobiles are redirected to the right layer at RRC connection establishment in order that mobiles that are
eligible to HSDPA are directed towards the HSDPA layer and that the other ones are directed towards
the non-HSDPA layer. The redirection is based on the twin-cell configuration. The call flow is not
modified compared to a normal call setup, the redirection only consists in indicating a target
frequency in the RRC Connection Setup message (frequency info IE).
Mobiles in idle mode will select a layer according to radio conditions criteria. The cell
selection/reselection algorithm is not governed by HSDPA availability so it is not possible to guarantee
that an HSDPA mobile will select the HSDPA layer (and vice versa a non-HSDPA mobile will select the
non-HSDPA layer).
Segmentation is done by the RNC when a mobile tries to establish a RRC connection. It is based on the
Access Stratum Release Indicator IE present in RRC Connection Request, knowing that R4 mobiles do
not support HSDPA. If a R4 mobile sends its connection request in the HSDPA layer, it is redirected to
the non-HSPDA layer in the RRC Connection Setup message. If a R5 (or later release) mobile sends its
connection request in the non-HSDPA layer, it is redirected to the HSDPA layer.

Section 1 Pager 29
4.2 Outgoing HSDPA Mobility Success Rate
Reference FDDCell metric UHSDPA022_CR_Intra_freq
HSDPA HSDPA Mobility #950.[0]

=
Success Rate (intra-freq) #950.[0] + #951.[0]
Reference FDDCell metric UHSDPA022_CR_Inter_freq
HSDPA HSDPA Mobility #950.[3]

=
Success Rate (inter-freq) #950.[3] + #951.[3]
HSDPA R99 Mobility #950.[2]

=
Success Rate (intra Freq) #950.[2] + #951.[2]
HSDPA R99 Mobility #950.[5]

=
Success Rate (inter Freq) #950.[5] + #951.[5]
VS.HsdpaMobilitySuccess - #950
Number of successful HSDPA mobility: 1) HSDPA Cell to HSDPA Cell, 2) R99 Cell to HSDPA Cell, 3) HSDPA
Cell to R99 Cell. Reference Cell is the new primary cell of the call.
A set of sub counters screened on: Change of primary cell for a PS I/B call that is on HSDPA or will be on
HSDPA.
• Sub-Counter #0 : HSDPA Cell to HSDPA Cell (intra frequency mobility)
• Sub-Counter #1 : non-HSDPA Cell to HSDPA Cell (intra frequency mobility)
• Sub-Counter #2 : HSDPA Cell to non-HSDPA Cell (intra frequency mobility)
• Sub-Counter #3 : HSDPA Cell to HSDPA Cell (inter frequency mobility)
• Sub-Counter #4 : non-HSDPA Cell to HSDPA Cell (inter frequency mobility)
• Sub-Counter #5 : HSDPA Cell to non-HSDPA Cell (inter frequency mobility)
VS.HsdpaMobilityUnsuccessful - #951
Number of unsuccessful HSDPA mobility: 1) HSDPA Cell to HSDPA Cell, 2) R99 Cell to HSDPA Cell, 3)
HSDPA Cell to R99 Cell. Reference Cell is the new primary cell of the call.
A set of sub counters screened on: Change of primary cell for a PS I/B call that is on HSDPA or will be on
HSDPA.
• Sub-Counter #0 : HSDPA Cell to HSDPA Cell (intra frequency mobility)
• Sub-Counter #1 : non-HSDPA Cell to HSDPA Cell (intra frequency mobility)
• Sub-Counter #2 : HSDPA Cell to non-HSDPA Cell (intra frequency mobility)
• Sub-Counter #3 : HSDPA Cell to HSDPA Cell (inter frequency mobility)
• Sub-Counter #4 : non-HSDPA Cell to HSDPA Cell (inter frequency mobility)
• Sub-Counter #5 : HSDPA Cell to non-HSDPA Cell (inter frequency mobility)

Section 1 Pager 30
4.3 Incoming HSDPA Mobility Scenarios
RNC
HSDPA cell HSDPA cell
R99/HSDPA
R99 cell
cell


Section 1 Pager 31
4.4 Incoming HSDPA Mobility Success Rate
R99 HSDPA Mobility #950.[1]

=
Success rate (intra Freq) #950.[1] + #951.[1]
R99 HSDPA Mobility #950.[4]

=
Success rate (inter Freq) #950.[4] + #951.[4]


Section 1 Pager 32
4.5 HSDPA/DCH transitions – HDSPA Primary Cell Change
Nb of HSDPA Primary Cell Change per Minute of Call

HSDPA TO HSDPA 600 x #950.[0,3]
Primary Cell Change =
Per Minute of Call #1666.[20].Cum

VS.HsdpaDCHToHsdpaTransSucc - #953 (Number of successful DCH to HSDPA transition)

Transition happens based on the RAB matching algorithm decision to put the RAB onto HSDPA.
Please note that this counter is also triggered at call establishment when CellDCH is used (that is to say
when there is a transition from DCH to HSDPA at call establishment).
VS.HsdpaToDCHSucc - #954 (Number of successful HSDPA to DCH transition)
This counter is only pegged on RAB establishment or RAB release use cases.
- The RAB establishment use case is applicable to multi-service (i.e PS HSDPA --> PS + (CS or PS))
- The RAB release use case is applicable in mono-service release (i.e. SRB + PS HSDPA --> SRB)
- • Sub-Counter #0 : RAB Setup • Sub-Counter #1 : RAB Release
VS.DCHToHsdpaUnsuccessful - #955 (Number of unsuccessful DCH to HSDPA transition)
- The RAB establishment use case is applicable to mono-service (i.e SRB --> SRB + PS HSDPA)
- The RAB release use case is applicable in multi-service (i.e.PS + (PS or CS) --> PS)
• Sub-Counter #0 : RAB Setup • Sub-Counter #1 : RAB Release
VS.HsdpaToDCHUnsuccessful - #956 (Number of unsuccessful HSDPA to DCH transition)
- The RAB establishment use case is applicable to multi-service (i.e PS HSDPA --> PS + (CS or PS))
- The RAB release use case is applicable in mono-service release (i.e. SRB + PS HSDPA --> SRB)
• Sub-Counter #0 : RAB Setup • Sub-Counter #1 : RAB Release
VS.DlAsConfIdAvgNbrEstablished - #1666 indicates an average of the number of DlAsConfIds established

per iRNC, based on time average over collection period
Sub-Counter #20 : HSDPA
Section 1 Pager 33
5 HSDPA Capacity Monitoring


Section 1 Pager 34
5.1 HSDPA Power Monitoring
The Power used for HSDPA shall be evaluated in order to estimate if

the Power is a limitation resource to reach the target HSDPA
throughput.
PMaxCell
HS-DSCH #10801
Pavail for Hsdpa
HS-SCCH
#10803
DCH margin Poper #10205.[0]
Pused #10205.[1]
NodeB
E-DCH
DCH
OCNS (opt.) OPERATIONAL
CCCNodeB

VS.RadioTxCarrierPwr - #10205
Average value of the total transmitted power - at the Tx channelizer - for each cell (i.e. per sector
and per frequency).
The cumulated value at the end of the observation period and the number of samples are provided.
The minimum and maximum powers during the reporting period are also provided.
Screening:
• Sub-Counter #0 : Operational Max Power
• Sub-Counter #1 : Power used
VS.HsdpaHSPDSCHTxPwr - #10801
Total transmitted power on all allocated HS-PDSCH codes per TTI.
VS.HsdpaHSSCCHTxPwr - #10803
Total power on all transmitted HS-SCCH codes per TTI.

Section 1 Pager 35
5.2 HSDPA Power: Counter
HsdpaNonHSDPATxPwr
Total transmitted power on all SF16 codes

not used for HS-DSCH per TTI ( only available = #10842
for HSDPA cells)


Section 1 Pager 36
5.3 HSDPA Power: Indicators
Find the unit of the first metric below

using the RNC counters catalogue
BTSCell metric UHSDPA010_CR
Average HSDPA #10801.Avg + #10803.Avg

Power Used = 100 *
#10205.[0]
BTSCell metric UPower001_B_Avg
Percentage of #10205.[1].Avg
=
Average Power in Use #10205.[0].Avg


Section 1 Pager 37
5.3 HSDPA Power: Indicators [cont.]
BTSCell metric UPower001_B_Max
Percentage of #10205.[1].Max
=
Maximum Power in Use #10205.[0].Max
[0] [1] [2] [3] [4]

# 307.[i]
0% 40% 70% 80% 90% 100%
FDDCell metric UPower003_CR_over80
Ratio of Total #307.[3,4]

=
Power Usage over 80 % #307.[all]
FDDCell metric UPower003_CR_over90
Ratio of Total #307.[4]

Power Usage over 90 % =
#307.[all]

VS.DistDlTtlPwrRatio - #307
DL TX power ratio P/Pmax received from NBAP common measurement per cell. It details the number of
common measurements, according to their respective ranges and during the reporting period
A set of sub counters screened on: Power ratio

• Sub-Counter #0 : 0 to 40 pc

Section 1 Pager 38
5.3 HSDPA Power: Indicators [cont.]
# 308.[i] [0] [1] [2] [3] [4]

# 309.[i]
# 310.[i] 0% 40% 70% 80% 90% 100%
FDDCell metric UHSDPA070_CR_X_Y
Ratio of R99 only #308.[i]

=
Power Usage in range i #308.[all] + #309.[all] + #310.[all]
Ratio of HSDPA GBR only #309.[i]

=
Ratio of HSDPA non GBR only = #310.[i]


VS.DlTtlTxPwrR99Only - #308
DL TX power (of all codes not used for HS transmission) ratio P/Pmax received from NBAP common
measurement per cell.
VS.DlTtlPwrHsdpaGbrOnly - #309
Ratio between the DL total power reserved for GBR on HSDPA users (according to the reported NBAP
common meas 'HS-DSCH Req power' from NodeB) and Pmax.
VS.DlTtlPwrHsdpaNonGbrOnly - #310
Ratio between the DL total power reserved for non-GBR HSDPA users (the ones for which power self-
tuning is not applied) and Pmax.
All these above counters are defined with a set of sub counters screened on: Power ratio

Section 1 Pager 39
5.4 HSDPA Codes and Users: Indicators
Mean Number of HS-DSCH Codes #10802.Cum

=
Per User per TTI #10804.Cum
BTSCell metric UHSDPA013_C
Mean Number of HS-DSCH Codes #10802.Cum

=
Per TTI #10818
CEM metric
Average Number of HSDPA UE Per H-BBU = #10820.Avg

Maximum Number of HSDPA UE Per H-BBU = #10820.Max
LCG metric
#10820.Avg
Average Number of HSDPA UE Per LCG == #10821.Avg
Maximum Number of HSDPA UE Per LCG == #10821.Max
#10820.Max

VS.HsdpaHSPDSCHCodesPerTTI - #10802
Number of HS-PDSCH codes used per TTI.
VS.HsdpaHSSCCHCodesPerTTI - #10804
Number of HS-SCCH codes used per TTI. It then indicates the number of scheduled UEs in the TTI.
VS.HsdpaTTIsUsed - #10818
Number of TTIs containing at least one scheduled UE
VS.HsdpaUEsPerHBBU - #10820
Number of UEs configured in the H-BBU
VS.HsdpaUEsPerLCG - #10821
Number of HSDPA UEs configured in the LocalCellGroup
As HsdpaUEsPerLCG counter is reported per LCG and a xCEM is capable to manage 2 LCGs, the sum of the
2 LCGs has to be done to get entire xCEM board information.

Section 1 Pager 40
6 HSDPA Traffic Monitoring


Section 1 Pager 41
6.1 HSDPA Calls, Activity, RLC SDU Throughput
Number of HSDPA RB
= #1650.[15,16]
to be setup successes
Reference FDDCell metric UTraffic022_CR_HSDPA
#1566.[5]
HSDPA RAB Activity Factor =
#1666.[20].Cum x 100
#10818
HSDPA Activity Rate =
#10803.NbEvt
RNC metric * TO CHANGE IT BIT UTraffic024_R_HSDPA
#1544.[5] PER BYTE
HSDPA DL RLC HSDPA Throughput = 80 x
∑cell(#1666.[20].Cum)
Reference FDDCell metric UTraffic028_C_HSDPA
#1556.[5]
DL RLC SDU HSDPA Throughput = 80 x
SIGNAL DATA UNIT ∑cell(#1666.[20].cum
• Sub-Counter #0: Other combinations • Sub-Counter #1: CS Speech NB or LR AMR
• Sub-Counter #2: CS Speech WB AMR • Sub-Counter #3: CS Data
• Sub-Counter #4: CS Streaming • Sub-Counter #5: PS Streaming < 64
• Sub-Counter #6: PS Streaming 64 • Sub-Counter #7: PS Streaming 128
• Sub-Counter #8: PS Streaming 256 • Sub-Counter #9: PS Streaming 384
• Sub-Counter #10: PS I/B < 64 • Sub-Counter #11: PS I/B 64
• Sub-Counter #12: PS I/B 128 • Sub-Counter #13: PS I/B 256
• Sub-Counter #14: PS I/B 384 • Sub-Counter #15: HSDPA/R99
VS.DedicatedDownlinkActivityRlcRefCell - #1566 - Time that RAB is actively transmitting data in the

downlink: • Sub-Counter #5 : PS HSDPA
VS.DlAsConfIdAvgNbrEstablished - #1666 - Average of the number of DlAsConfIds established per iRNC,
based on time average over collection period: • Sub-Counter #20 : HSDPA
VS.HsdpaTTIsUsed - #10818: Number of TTIs containing at least one scheduled UE.

VS.HsdpaHSSCCHTxPwr - #10803: Total power on all transmitted HS-SCCH codes per TTI.
VS.DedicatedDownlinkKbytesRlc - #1544 - Total count of downlink RLC payload (SDU) sent on dedicated
channels (Traffic Radio Bearers and Signaling Radio Bearers): • Sub-Counter #5 : PS HSDPA
VS.DedicatedDownlinkKbytesRlcReferenceCell - #1556 - Number of Kbytes of SDU sent on downlink for
the reference cell: • Sub-Counter #5: PS HSDPA

Section 1 Pager 42
6.2 User-Perceived Throughput Counter
VS.UserTP.HSDPA
Distribution of the user perceived

throughput for interactive/background = #2503
traffic in a UMTS cell when using HSDPA
traffic channels in CELL_DCH.
Screenings
The data rate threshold of the screenings can be defined by
the CM attribute PmUserTpConfig.hsdpaThd.
[0] [1] [2] [3] [18] [19]

………………………….
Thd0 Thd1 Thd2 Thd3 Thd17 Thd18


Section 1 Pager 43
6.3 HSDPA Call Duration, Traffic Penetration
10 MS FRAME
DURATION
Reference FDDCell metric UHSDPA040_C
#1666.[20].Cum
HSDPA Mean Call Duration =
10 x (#957 - #1743.[1])
#10805
HSDPA 16QAM Usage =
#10804.[Cum]

VS.DlAsConfIdAvgNbrEstablished - #1666 indicates an average of the number of DlAsConfIds established

per iRNC, based on time average over collection period.
• Sub-Counter # 20 : HSDPA
VS.HsdpaCACSuccess - #957 - Number of HSDPA CAC
VS.UpsizingSuccess - #1743 - Number of successful upsizing from always on step1 for communication which
reference cell is on serving RNC. This counter is screened according to the target downlink ASConfId
• Sub-Counter # 1 : HSDPA
VS.Hsdpa16QAMUsage - #10805 - Number of scheduled mobiles using 16QAM.

VS.HsdpaHSSCCHCodesPerTTI - #10804 - Number of HS-SCCH codes used per TTI. It then indicates the
number of scheduled UEs in the TTI.
VS.DedicatedDownlinkActivityRlcRefCell - #1566 - Time that RAB is actively transmitting data in the

downlink. Downlink Traffic Counter Screenings:
• Sub-Counter #0: Other Dl • Sub-Counter #5: PS HSDPA
• Sub-Counter #6 – #9 : PS Str • Sub-Counter #10 - #16: PS I/B

Section 1 Pager 44
6.4 Hsdpa Call Attempts Per Category
Reference FDD Cell metric UHSDPA054_C_CatX
Number of Call Attempts

= #1622.[X - 1]
per UE Category X
RNC metric UHSDPA054_R_CatX
Number of Call Attempts

= NZ(# 1622.[X - 1]) + NZ(# 668.[X - 1])
per UE Category X

VS.CellAttWithUeCatPerCell - #1622
Number of call attempts, with each UE category number (#1~20), per cell
A set of sub counters screened on UE Category:
• Sub-Counter #0: UE Category 1
•…
VS.CallAttemptsUeCat_UA05 - #668
Number of call attempts, with each UE category number (#1~12), per RNC
A set of sub counters screened on: UE Category
• Sub-Counter #0 : UE Category 1
•…

Section 1 Pager 45
6.5 HSDPA UE Category Penetration
RNC metric UHSDPA052_R_CatX
Proportion of Call Attempts #1622.[X - 1]

=
for UE Category X #1622.[all]
HS-DSCH Category HS-PDSCH Max Number Inter-TTI Min Interval Modulation Max Peak Rate
Category 1 5 3 QPSK & 16-QAM 1.2 Mbps
Category 11 5 2 QPSK only 0.9 Mbps

• QPSK mandatory for HSDPA capable UE
Category 12 5
• 16/64-QAM optional 1 QPSK only 1.8 Mbps

VS.CellAttWithUeCatPerCell - #1622
Number of call attempts, with each UE category number (#1~20), per cell
UE categories are specified for HSDPA UEs according to the value of several parameters among which are
the following:
Maximum number of HS-DSCH codes that the UE can simultaneously receive (5, 10 or 15)
Minimum inter-TTI interval, which defines the minimum time between the beginning of two
consecutive transmissions to this UE. If the inter-TTI interval is one, this means that the UE can
receive HS-DSCH packets during consecutive TTIs, i.e. every 2 ms. If the inter-TTI interval is two, the
scheduler needs to skip one TTI between consecutive transmissions to this UE.
Supported modulations (QPSK only or both QPSK and 16QAM/64QAM)
Maximum peak data rates at the physical layer (number of HS-DSCH codes x number of bits per HS-
DSCH / Inter-TTI interval).
These categories provide a much more coherent set of capabilities as compared to R99 which gives UE
manufacturers freedom to use completely typical combinations.
New UE categories have been introduced to support the 64QAM :

- 13 and 14 (64-QAM only),
- 17 and 18 (64-QAM or MIMO)
These UE categories are MAC-ehs capable
MIMO is not supported in UA7
The UE category “64QAM capable” deployed in Live is Cat.14

Section 1 Pager 46
6.6 64 QAM Counters
The 64 QAM feature can be evaluated with these counters:
VS.CallAttWithUeCatPerCell
Number of call attempts, with each UE = #1622

category number (#1~20), per cell
HsdpaModulationType
Number of scheduled mobiles transmitting = #10841

with QPSK, 16QAM or 64QAM
VS.HsdpaTTIperUEcat
Number of TTI for which there is data to be = #10825

transmitted, per UE category
VS.HsdpaTxDataBitPerUEcat
Number of transmitted bits, per UE category = #10826

(only first transmissions are considered)

Section 1 Pager 47
6.7 64 QAM Indicators
The 64 QAM feature can be evaluated with these indicators:
UHSDPA052_CR_Cat13/14/17/18
DistributionCallAttempts_HSDPA052_C_Cat13
Distribution by UE category of the
= potential HSDPA call attempts -
DistributionCallAttempts_HSDPA052_C_Cat17 Category X
UHSDPA050_CR_64QAM_ONB
Percentage of mobiles scheduled using
HSDPA64QAMUsage_HSDPA050_CR = 64QAM modulation
UHSDPA075_CR_Cat13/14/17/18
HsdpaThroughputPerUeCat_HSDPA075_CR_Cat13
HSDPA throughput
HsdpaThroughputPerUeCat_HSDPA075_CR_Cat17 = per ue category
1ST TRANSMITION,
NO RETRANSMTION
INCLUDED

Section 1 Pager 48
7 HSDPA Quality Monitoring


Section 1 Pager 49
RLC= 320
USEFULBIT
+16HEADER
7.1 HSDPA RLC PDU Mac-d & Mac-hs Throughput, BLER
BTSCell metric 1/(2ms) UHSDPA008_CR_RLC
320 # 10806.Cum
RLC PDU HSDPA Throughput Per Cell = 500 x x
(if Dynamic Mac-d PDU size disabled) 336 #10818
BTSCell metric UHSDPA008_CR_MACd
# 10806.Cum
MAC-d HSDPA Throughput Per Cell = 500 x
#10818
BTSCell metric UHSDPA007_C

# 10808.Cum
MAC-hs HSDPA Throughput Per Cell = 500 x
#10818
Reference FDDCell metric UBLER006_CR_HSDPA

# 1559.[5] RETRANS
Residual BLER at RLC Layer =
# 1558.[5] =1ST TRANS
+RETRANS
VS.HsdpaMACdPDUAckBits - #10806
Total number of successfully transmitted MAC-d PDU bits (an ACK has been received for the
corresponding transport block).
VS.HsdpaTxDataBitsMAChs - #10808
Total number of data bits (transport block size) first transmitted by the MAC-hs. The retransmissions are
then not taken into account, meaning that a block retransmitted several times is only taken into
account once at the first transmission.
VS.HsdpaTTIsUsed - #10818
Number of TTIs containing at least one scheduled UE. It allows new statistics to be derived for some
previous counters.
VS.DedicatedDownlinkRetransmittedPdusRlcReferenceCell - #1559
Number of downlink RLC PDUs retransmitted on the reference cell. This counter is not applicable to CS
Radio Bearers (only applicable to AM RBs).
• Sub-Counter #5: PS HSDPA
VS.DedicatedDownlinkPdusRlcReferenceCell - #1558
Number of RLC PDUs sent on downlink for the reference cell
• Sub-Counter #5: PS HSDPA

Section 1 Pager 50
7.2 HSDPA HARQ Feedback Distribution:
ACK/NACK/DTX
Data
ta
Da
CQI + NACK
CK CQ
I +A I +D
CQ TX

#10812
DTX RATIO =
#10810 + #10811 + #10812
#10810
ACK RATIO =
#10810 + #10811 + #10812
#10811
NACK RATIO =
#10810 + #10811 + #10812

VS.HsdpaNbrACKRcv - #10810
Number of acknowledged transport blocks ('ACK' received for a transmitted transport block).
Remark: ACK + NACK + DTX = Total number of transmitted transport blocks.
VS.HsdpaNbrNACKRcv - #10811
Number of negatively acknowledged transport blocks ('NACK' received for a transmitted transport block).
VS.HsdpaNbrDTX - #10812
Number of DTX detected (neither 'ACK' nor 'NACK' received for a transmitted transport block)

Section 1 Pager 51
7.3 HSDPA CQI Distribution
BTSCell metrics UHSDPA053_CR_XtoY
Category 6 UE CQI Mapping Table
Proportion of # 10819.[x-y] CQI Value HS-PDSCH Number RLC Throughput Modulation
Received CQI = 0
1 1
out of range
0 kbps QPSK
from X to Y # 10819.[all] 2 1 0 kbps QPSK
3 1 0 kbps QPSK
4 1 0 kbps QPSK
UHSDPA053_CR_NotDetected 5 1 144 kbps QPSK
6 1 144 kbps QPSK
Proportion of #10819.[31] 7 2 144 kbps QPSK
=
Not Detected CQI #10819.[all]
8 2 288 kbps QPSK
9 2 288 kbps QPSK
10 3 432 kbps QPSK
CQI Distribution for Site OutDoor example
11 3 576 kbps QPSK
CQI
Distribution%10to14
CQI CQI 12 3 720 kbps QPSK
Distribution%NotDetected CQI Distribution%15to17
CQI
Distribution%0to9 CQI 13 4 864 kbps QPSK
Distribution%26to30 Distribution%18to20
14 4 1008 kbps QPSK
15 5 1296 kbps QPSK
CQI CQI 16 5 1440 kbps 16-QAM
Distribution%23to25 Distribution%21to22
... ... ... ...
CQI Distribution%0to9 CQI Distribution%10to14 CQI Distribution%15to17 29 5 3024 kbps 16-QAM

CQI Distribution%18to20 CQI Distribution%21to22 CQI Distribution%23to25
CQI Distribution%26to30 CQI Distribution%NotDetected
30 5 3024 kbps 16-QAM

DISTRIBUTION OF RECEIVED CQI

Metric definition:
Distribution of Received CQI from 0 to 9= #10819.[0-9]/ #10819
Distribution of Received CQI from 10 to 14= #10819.[10-14]/ #10819
Distribution of Received CQI from 15 to 17 = #10819.[15-17]/ #10819
Distribution of Received CQI not detected = #10819.[31]/ #10819
The distribution of received CQI will depend only on radio conditions. When the distribution of Received
CQI below 15 is important, then the HSDPA Throughput is highly impacted.

Section 1 Pager 52
8 GBR on HSDPA & Fair Sharing


Section 1 Pager 53
8.1 GBR Performance metrics
Streaming, Interactive, Background
HS-DSCH
Ratio of GBR on HSDPA #10830.[1]

=
to total HSDPA Throughput #10806.Cum
Increase number of
users in Streaming !
HSDPA streaming users vs R99 streaming users

GBR over HSDPA management in UTRAN increases the sustainable number of streaming users versus
streaming over Release 99
VS.HsdpaMACdPDUAckBitsForGbr - #10830
Total number of successfully transmitted MAC-d PDU bits (an ACK has been received for the corresponding
transport block) for flows configured with a non null GBR.
Sub-Counter #0: Number of TTI
Sub-Counter #1: Number of ACKed bits
Number of successfully transmitted MAC-d PDU bits (an ACK has been received for the corresponding
transport block).

Section 1 Pager 54
8.1 GBR Performance metrics [cont.]
HSDPA average throughput

=
per GBR flow
#10830.[1]
#10833.[all SPI].NbEvt + #10834.[all SPI]
Average Number #10833.[all SPI].NbEvt + #10834.[0-15]

=
of GBR flows
#10834.[Nb of Periods]
VS.HsdpaGbrDeficitRatioPerSpi - #10833 - This counter represents the observed throughput deficit over a
given period (1s) due to radio congestion, expressed as a percentage of configured GBR for all unsatisfied
GBR flows.Distibution per SPI:
VS.HsdpaGbrDeficitRatioPerSpi.SPIx.Avg
VS.HsdpaGbrDeficitRatioPerSpi.SPIx.Cum
VS.HsdpaGbrDeficitRatioPerSpi.SPIx.Max
VS.HsdpaGbrDeficitRatioPerSpi.SPIx.Min
VS.HsdpaGbrDeficitRatioPerSpi.SPIx.NbEvt
VS.HsdpaGbrSatisfiedFlows - #10834 - Number of flows per sampling period (1s) that either fulfil their
GBR or that are in starvation (cause external to NodeB).
• Sub-Counter #0: For SPI 0
• ...
• Sub-Counter #16: Number of Sampling periods

Section 1 Pager 55
8.2 GBR and Fair Sharing performance troubleshooting
GBR and Fair Sharing performance troubleshooting:
With the introduction of GBR, the OVSF Code shortage and the Power
limitation must be monitored
With the Fair Sharing and GBR, the overall HSDPA Cell throughput is
likely to decrease.

HSDPA cell throughput may be degraded for 2 reasons:
1- Due to R99 Users : with Fair Sharing, there is no more minimum number of HS-PDSCH codes reserved
globally for HSDPA
potential impact may be that a minimum QoS for non MAC-hs GBR can not be guaranteed by
reserving, for example, 5 HS-PDSCH codes
consequence may be a throughput degradation for non MAC-hs GBR flow
this case may appear only if R99 traffic is high (for example, more than four concurrent PS384 calls)
2- Due to MAC-hs GBR Users : The MAC-hs GBR users are scheduled with a higher priority whatever their RF
condition is. In the case of high GBR traffic the overall cell throughput can fall short of expectations due
to former releases.

Section 1 Pager 56
8.2.1 Mac-hs GBR fulfilled or not ?
If GBR is enabled,
check if Mac-hs GBR is fulfilled (radio congestion)
10833 = 0% #10833 10833 > 0%

HsdpaGbrDeficit
RatioPerSpi
Mac-hs GBR is not fulfilled

Due to codes or power ?
#10831 #10832
HsdpaFullCode HsdpaGbr
UsageByGbr PowerUsage
Mac-hs GBR Review the parameter setting

is fulfilled 10831 > 0 minBr/GBR value too high? 10832 = 100%

#10833 - VS.HsdpaGbrDeficitRatioPerSpi: This counter represents the observed throughput deficit over a
given period (1s) due to radio congestion, expressed as a percentage of configured GBR for all
unsatisfied GBR flows.
#10831 - VS.HsdpaFullCodeUsageByGbr: Number of TTI with no remaining HS-PDSCH code after

scheduling
#10832 - VS.HsdpaGbrPowerUsage: Percentage of available HSDPA power used for GBR flows (note that
available HSDPA power is continuously updated and corresponds to unused power by DCH and CTCH)

Section 1 Pager 57
8.2.2 HSDPA Cell Throughput Degradation
If Fair Sharing is enabled, check if there
is HSDPA cell throughput degradation
HSDPA cell throughput is lower

#10806 HsdpaMACdPDUAckBits compared to former releases
#10830 HsdpaMACdPDUAckBitsForGbr
No
If GBR enabled
HSDPA cell throughput is
Yes
equal or higher High R99 traffic
compared to former releases
Average number of HS-PDSCH

codes used is lower
compared to former releases
Mac-hs GBR (scheduled with

a higher priority) may be in #10802
OK bad RF condition VS.HsdpaHSPDSCHCodesPerTTI
Total number of successfully transmitted MAC-d PDU bits (an ACK has been received for the
corresponding transport block).
VS.HsdpaMACdPDUAckBitsForGbr - #10830 - Total number of successfully transmitted MAC-d PDU bits

(an ACK has been received for the corresponding transport block) for flows configured with a non null
GBR.
number of TTIs and number of acked bits
Sub-Counter #0: Number of TTI
Sub-Counter #1: Number of ACKed bits
VS.HsdpaHSPDSCHCodesPerTTI - #10802
Number of HS-PDSCH codes used per TTI.

Section 1 Pager 58
8.2.3 RNC CAC Unsuccess increase
If Fair Sharing is enabled,

check if Radio Bearer Establishment unsuccess increases
Screening <<unavailable Screening <<unavailable

dl power resources>> dl code resources>>
increase increase
#1629
Nb of Radio Bearer Establishment Unsuccess
Power limitation Codes limitation

VS.RadioBearerEstablishmentUnsuccess - #1629
Number of radio bearer setup not successfully established, with no RADIO BEARER SETUP REQUEST sent.
Sub-Counter #1: unavailable dl code resources

Sub-Counter #2: unavailable dl power resources

Section 1 Pager 59
Module Summary
Having completed this section, you should know
the HSDPA main KPIs families and

the main metrics of HSDPA Accessibility, Retainability, Quality, Traffic and
mobility.


Section 1 Pager 60
Self-assessment on the Objectives
Please be reminded to fill in the form

Self-Assessment on the Objectives
for this module
The form can be found in the first part
of this course documentation


Section 1 Pager 61
End of Module
Module 1


Section 1 Pager 62
Do not delete this graphic elements in here:
Section 2
2 HSUPA Performance
Monitoring
Module 1
9300 W-CDMA
TMO18269 D0 SG DEN Edition 1.0

Section 2 Pager 1
Blank Page

HSUPA Performance Monitoring
Document History
Edition Date Author Remarks
01 2008-12-01 El Abed, Jean-Noel First edition
01.1 2009-03-18 Kieslich, Roland Update to Rel. UA06

Debergh, Pierre Draft 3.2
Charneau, Jean-Noel with Deltas between UA05 (Slides ….R5) and
UA06 (Slides … R6)
02 2009-04-10 Charneau, Jean-Noel •HSUPA call drop radio counter #962 renamed
to VS.EdchCellDeletion
•Add #590.[2] VS.IuAbnRelReqPsPerULRb
counter to count all HSUPA call drops
•Add Average Thermal Noise computation
from VS.UplinkRssi #303 counter
03 2010-04-28 Nolan, Vincent Update to Rel. UA07

Section 2 Pager 2
Module Objectives
Upon completion of this module, you should be able to:
Describe HSUPA main KPIs families

Understand the main HSUPA Accessibility, Retainability, Quality, Traffic and
mobility metrics.
Describe the HSUPA performance monitoring impact due to the new HSDPA
features introduction.


Section 2 Pager 3
Module Objectives [cont.]

HSUPA Performance Monitoring This page is left blank intentionally

Section 2 Pager 4
Table of Contents
Page
1 HSUPA Performance Monitoring 7
1.1 Transport & Physical Channels 8
2 HSUPA Accessibility Monitoring 9
2.1 Number of CAC reject on E-DCH cell 10
2.2 Successful rate DCH to HSUPA transitions 11
2.3 Proportion of HSUPA Fallback 12
3 HSUPA Retainability Monitoring 13
3.1 HSUPA Mobility Call Drop Rate 14
3.2 HSUPA Radio Call Drop Rate 15
3.3 HSUPA Call Drops 16
3.4 HSUPA Call Drop per Minute of Call - Exercise 17
4 HSUPA Mobility Monitoring 18
4.1 HSUPA Primary Cell Change per Minute of Call 19
4.2 HSUPA Mobility Success: indicators 20
5 HSUPA Capacity Monitoring 23
5.1 HSUPA Common Channels Power 24
5.2 UL Cell Load 25
5.3 UL Cell Overload 26
5.4 Average Thermal Noise – Exercise 27
5.5 HSUPA Rise over Thermal (RoT) 29
5.6 Number of HSUPA Users 30
6 HSUPA Quality Monitoring 31
6.1 HSUPA HARQ BLER & Average Mac-d Throughput 32
6.2 UL Radio Quality – RSSI 33
25
6.3 UL Radio Quality - SIR All Rights Reserved © Alcatel-Lucent 2010
34
6.4 ULMonitoring
HSUPA Performance HSUPA Traffic Quality – RLC SDU Throughput 35
7 HSUPA Traffic Monitoring 36
7.1 HSUPA Traffic Activity & Penetration Factors 37
7.2 HSUPA Traffic Volume metrics 38
7.3 User-Perceived Throughput Counter 39

Section 2 Pager 5
Table of Contents [cont.]
26 This page AllisRights

left blank intentionally
Reserved © Alcatel-Lucent 2010

Section 2 Pager 6
1 HSUPA Performance Monitoring


Section 2 Pager 7
1 HSUPA Performance Monitoring
1.1 Transport & Physical Channels
Uplink:
E-DPCCH: for signaling data (SF 256)
E-TFCI, RSN, happy bit
E-DPDCH: for traffic data (SF 2, 4, …, 256)
Traffic data, scheduling information
DP CCH
Downlink
H
DP
DC
E-AGCH: Absolute Grant Channel (SF256)
E-
E-RNTI, grant index information
E-
E- -AG ICH
E-HICH: HARQ Indicator Channel (SF 128)
CH H
RG C
E -H
ACK/NACK information
E
E-RGCH: Relative Grant Channel (SF 128)
+1/0/-1 from RLS

A specific E-DCH transport channel is defined. As the classical DCH transport channel it allows to offer
transport services to higher layers.
The E-DCH transport channel is defined by the following characteristics:
Only for UL
Two possible TTI : 10ms and 2ms.
Transport block size and Transport Block set size are free attributes of the transport format.
Possibility of HARQ process with retransmission procedures applied at Node B. Max number of
retransmission must be defined. Each transmitted blocks are numbered.
Two HARQ types can be used: Chase Combining (CC) and Incremental Redundancy (IR)
Possibility of smart redundancy management at Rx. The Redundancy Version (RV) used for the
transmission must be managed in order to apply Chase combining or Incremental Combining
mechanisms
RV always = rv0 in case of CC
RV = any rvindex of the RV table in case of IR
Turbo coding with rate 1/3 is used
CRC is 24 bits length
E-TFCI (Transport Format Combination Indication for E-DCH) indicates which format is currently used
for the UL transmission.

Section 2 Pager 8
2 HSUPA Accessibility Monitoring


Section 2 Pager 9
2.1 Number of CAC reject on E-DCH cell
RAB assignment (to establish or to release) RabAssignment
IU release
Primary cell change
Incoming Inter-RNC UE involved Hard Handover Mobility
Incoming Intra-RNC Alarm Hard Handover
HSUPA/HSDPA RB
to be established #1603[1]
HSDPA fallback unsuccess
No HSUPA to DCH Fallback

CAC OK ?
Steps
#1650[16]
RB setup success Yes #1601[1,2] MultiStep MonoStep
HSDPA fallback success
HSUPA/HSDPA RB DCH/HSDPA RB DCH/DCH RB
established to be established to be established
Failure
Number of E-DCH CAC reject = # 963.[0]

Reference FDDCell metric
VS.EdchIuRelAbnormal (#0963)
Number of Iu release requested by e-DCH call after CAC reject or a Mobility procedure failure
Screening 0: CAC reject on the e-DCH call
Screening 1: Mobility procedure failure (CAC or Mobility)
Recommendation:
The metric defined with this counter has to be monitored on the areas (group of cells/ RNC’s) where HSUPA
has been activated. It represents the number of Iu release requested by e-DCH call after CAC reject.
Expected result:
It should be low in most of HSUPA cells.

Section 2 Pager 10
2.2 Successful rate DCH to HSUPA transitions
UE Node B RNC MSC

R A N A P / R A B A s s ig n m e n t R e q u e s t (R A B p a r a m , b in d in g I d )
N B A P / R a d io L in k R e c o n f ig u r a t io n P r e p a r e (
E -D P C H in f o , E -D C H F D D in f o , E -D C H m a c -d f lo w t o a d d , S e r v in g T h e R a d io L in k is re c o n fig u re d to a d d th e E -
E -D C H R L , E -D C H R L in d ic a t io n = E -D C H , E -D C H S p e c if ic I n f o … .) D P C H in u p lin k in th e se rv in g c e ll. (T h e H S -
D S C H p a r t is n o t sh o w n )
N B A P / R a d io L in k R e c o n f ig u r a t io n R e a d y (E -D C H F D D in f o R e s p o n s e , E -D C H F D D D L
C ontrol C h annel …
N B A P / R a d io L in k R e c o n f ig u r a t io n C o m m it (
CFN)
T h e U E is p ro v id e d w ith th e n e w ra d io lin k
R R C / R B S e t u p (E -D C H in f o , E -R N T I ,
c o n fig u ra tio n . A n e w R A B (c o rre s p o n d in g to th e
CFN) n e w D T C H ) is a d d e d to th e c u rre n t c o n fig u ra tio n
R R C / R B S e t u p C o m p le t e
Reference FDDCell metric URB007_C_HSUPA

# 696.[0]
Successful
HSUPA rate DCH to E-DCH = #1650.[16]
HSUPARadio
Radio Bearer
Bearer = # 696.[0] + # 697.[0]
to
tobe
beSetup
SetupSuccess
SuccessRate
Rate #1652.[16]
VS.RadioBearerSetupRequest - #1652
The number of Radio Bearer setup decisions by the RNC, incremented based on reference cell.
It counts based on the requested Downlink AsConfID ((DL Access stratum Configuration) . Before CR
Q01244717, counters was pegged based on targetDlAsconfId (obtained as output of IRM algorithm),
therefore could not be pegged in case of CAC rejection. Since CR Q01244717,
counter is pegged accordingly to the requested Downlink AsConfId, then allowing pegging also in case of
CAC rejection.
A set of sub counters screened on: Target Type of call setup mapping:

Section 2 Pager 11
2.3 Proportion of HSUPA Fallback
The following HSxPA CAC failure scenarios trigger such a fallback
Primary cell change Max users

HSU or HSD
NBAP or
RNSAP Rab assignment Core
failure Network
Inter RNC HHO

Alarm HHO
failure! Internal to RNC: reach the maximum number of HSDPA or HSUPA users
External to RNC: NBAP or RNSAP failure
Reference FDDCell metric UHSUPA005_R
Proportion of #1601.[1,2]
=
E-DCH Fallback #1650.[16] + #1601.[1,2]+ #1603.[1]
VS.SucHspaToDchFallbackCell - #1601 - Number of calls successfully fallbacked from HSPA to DCH on RAB
assignment, mobility or reconfiguration event.
Sub-Counter #0 : DL:HSDPA/UL:DCH to DL:DCH/UL:DCH
Sub-Counter #1 : DL:HSDPA/UL:E-DCH to DL:HSDPA/UL:DCH
Sub-Counter #2 : DL:HSDPA/UL:E-DCH to DL:DCH/UL:DCH
VS.UnsucHspaToDchFallbackCell - #1603 - Number of calls unsuccessfully fallbacked from HSPA to DCH on

RAB assignment, mobility or reconfiguration event.
Sub-Counter #0 : DL:HSDPA/UL:DCH fallback
Sub-Counter #1 : DL:HSDPA/UL:E-DCH fallback
VS.RadioBearerSetupSuccess - #1650 - Number of Radio Bearer setup successfully. The counter should be
pegged multiple times for multiple RB successfully setup in the same procedure. Incremented on the
Reference cell of the call.
Sub-Counter #16: PS I/B or PS Str HSDPA/E-DCH

Section 2 Pager 12
3 HSUPA Retainability Monitoring


Section 2 Pager 13
3.1 HSUPA Mobility Call Drop Rate
UE Node B RNC CN
E-DCH mobility Failure

(NBAP or RRC)
Iu Release Request
Iu Release Command
#963[1]
VS.EdchIuRelAbnormal
Radio Link
Deletion Req
Radio Link
Deletion Resp Iu Release Complete

VS.EdchIuRelAbnormal - #0963
Number of Iu release requested by e-DCH call after CAC reject or a Mobility procedure failure
Screening 0: CAC reject on the e-DCH call
Screening 1: Mobility procedure failure (CAC or Mobility)
VS.RadioBearerSetupSuccess - #1650 - Number of Radio Bearer setup successfully. The counter should be
pegged multiple times for multiple RB successfully setup in the same procedure. Incremented on the
Reference cell of the call.

Section 2 Pager 14
3.2 HSUPA Radio Call Drop Rate
UE Node B RNC CN
Loss of UL synchro
detected on E-DCH RL
Radio Link
Iu Release Request
Failure Indication “radio connection with UE lost”
Iu Release Command
#962.[1]
VS.EdchCellDeletion
Reference FDDCell metric UHSUPA013_R

HSUPA Radio #962.[1]
=
Call Drop Rate #1650.[16]

VS.EdchCellDeletion - #962 - Number of E-DCH Cell Deletion

• Sub-Counter #0 : Deletion during Active Set Update
• Sub-Counter #1 : Deletion due to Radio Link failure

Section 2 Pager 15
3.3 HSUPA Call Drops
UE Node B RNC CN
HSUPA call
Iu Release Request
(abnormal cause)
Iu Release Command
#590.[2]
VS.IuAbnRelReqPsPerULRb
HSUPA Call Drop = #590.[2]

VS.IuAbnRelReqPsPerULRb - #590 - Number of Iu abnormal release request that increments whenever RNC
requests Iu release due to abnormal conditions. Reference cell on the serving RNC
• Sub-Counter #0: Other
• Sub-Counter #1: R99
• Sub-Counter #2: E-DCH

Section 2 Pager 16
3.4 HSUPA Call Drop per Minute of Call - Exercise
Nb of HSUPA Call Drops per Minute of Call
Number of HSUPA call drops

Total HSUPA RAB duration
Reference FDDCell metric UIU019_C_HSUPA
Nb of HSUPA Call Drop # 590.[2]

= 600 x
per Minute of Call # 1667[16].Cum


Section 2 Pager 17
4 HSUPA Mobility Monitoring


Section 2 Pager 18
4.1 HSUPA Primary Cell Change per Minute of Call
UE target Node B source Node B RNC
Primary cell change

RL Reconfiguration Prepare
RL Reconfiguration Ready
RL Reconfiguration Prepare
RL Reconfiguration Ready
RL Reconfiguration Commit (Activation CFN)
RB Reconfiguration (Activation CFN, new E-RNTI,

Serving E-DCH RL, E-AGCH info, E-HICH info)
Measurement Control (new neighboring list)
Activation CFN
RB Reconfiguration Complete
Reference FDDCell metric UHSUPA006_CR
E-DCH Primary Cell Change #968.[0,2,3,5-8]

= 600 x
per Minute of Call #1667.[16].Cum
VS.EdchSucMobility - #968 - Number of successful E-DCH mobility.

Sub-Counter #0: E-DCH Call (TTI=10ms) to E-DCH Call (TTI=10ms) (intra frequency mobility)
Sub-Counter #1: non-E-DCH Call to E-DCH Call (intra frequency mobility)
Sub-Counter #2: E-DCH Call to non-E-DCH Call (intra frequency mobility)
Sub-Counter #3: E-DCH Call to E-DCH Call (inter frequency mobility)
Sub-Counter #4: non-E-DCH Call to E-DCH Call (inter frequency mobility)
Sub-Counter #5: E-DCH Call to non-E-DCH Call (inter frequency mobility)
VS.UlAsConfIdAvgNbrEstablished - #1667
Average of the number of UlAsConfIds established per iRNC, based on time average
over collection period
Sub-Counter #16 : PS I/B or PS Str HSUPA

Section 2 Pager 19
4.2 HSUPA Mobility Success: indicators
Reference FDDCell metric UHSUPA001_CR_mobilityType
HSUPA Mobility # 968.[mobilityType]

Success Rate =
Per mobilityType # 968.[mobilityType] + # 969.[mobilityType]
#968 metric reference
mobilityType and
#969
TTI=10ms -> TTI=10ms [0] UHSUPA001_CR_ItaFeDCH10_10

E-DCH Cell TTI=10ms -> TTI=2ms [6] UHSUPA001_CR_ItaFeDCH10_2
to
E-DCH Cell TTI=2ms -> TTI=10ms [8] UHSUPA001_CR_ItaFeDCH2_10
intra
frequency TTI=2ms -> TTI=2ms [7] UHSUPA001_CR_ItaFeDCH2_2
mobility
non-E-DCH Cell
[1] UHSUPA001_CR_ItaFneDCHeDCH
to E-DCH Cell
E-DCH Cell to
[2] UHSUPA001_CR_ItaFeDCHneDCH
non-E-DCH Cell
E-DCH Cell to E-DCH Cell [3] UHSUPA001_CR_ItrFeDCHeDCH

inter
frequency non-E-DCH Cell to E-DCH Cell [4] UHSUPA001_CR_ItrFneDCHeDCH
mobility
E-DCH Cell to non-E-DCH Cell [5] UHSUPA001_CR_ItrFeDCHneDCH

VS.EdchSucMobility - #968
Number of successful E-DCH mobility (Primary cell change).
• Sub-Counter #0: E-DCH Call (TTI=10ms) to E-DCH Call (TTI=10ms) (intra frequency mobility)
• Sub-Counter #1: non-E-DCH Call to E-DCH Call (intra frequency mobility)
• Sub-Counter #2: E-DCH Call to non-E-DCH Call (intra frequency mobility)
• Sub-Counter #3: E-DCH Call to E-DCH Call (inter frequency mobility)
• Sub-Counter #4: non-E-DCH Call to E-DCH Call (inter frequency mobility)
• Sub-Counter #5: E-DCH Call to non-E-DCH Call (inter frequency mobility)
VS.EdchUnsucMobility - #969
Number of unsuccessful E-DCH mobility.
Same screenings as for #968.

Section 2 Pager 20
4.2 HSUPA Mobility Success: indicators [cont.]
Reference FDDCell metric UHSUPA001_CR_eDCHeDCH
Global HSUPA #968.[0,3,6-8]

success rate =
from E-DCH cell #968.[0,3,6-8] + #969.[0,3,6-8]
to E-DCH cell
Reference FDDCell metric UHSUPA001_CR_eDCHneDCH
Global HSUPA
success rate #968.[2,5]
from E-DCH cell =
to Non E-DCH cell #968.[2,5] + # 969.[2,5]


Section 2 Pager 21
4.2 HSUPA Mobility Success: indicators [cont.]
Reference FDDCell metric UHSUPA001_CR_neDCHeDCH
Global HSUPA #968.[1,4]

success rate =
from Non E-DCH cell #968.[1,4] + #969.[1,4]
to E-DCH cell
Reference FDDCell metric UHSUPA001_CR_ItaFeDCHeDCH
Global HSUPA #968.[0,6-8]

success rate
from E-DCH cell =
to E-DCH cell #968.[0,6-8] + #969.[0,6-8]
(Intra Frequency)


Section 2 Pager 22
5 HSUPA Capacity Monitoring


Section 2 Pager 23
5.1 HSUPA Common Channels Power
ICH
E-H GCH
E-A
ICH
H
E-H
GC
E-HICH
DCH
E-AGC
E-A
E-AGCH
H
# 10901
E-HICH
OCNS ( opt.)
Poper # 10205[0]
CCC RNC
BTSCell metric UHSUPA007_CR
Proportion of DL Power used # 10901.Cum

for DL HSUPA Common Channels = 100 x 10904.NbEvt x #10205.[0].Max

UHSUPA007_CR : Ratio of total power used by E-DCH DL channels, relative to PA power (averaged over
periods for which at least one E-DCH UE is active in the considered cell)
VS.eDCHcommonChannelsTxPower - #10901
Total Transmitted power on all allocated e-AGCH and e-HICH/ e-RGCH channels per 2 ms period.
VS.RadioTxCarrierPwr - #10205
Average value of the total transmitted power - at the Tx channelizer - for each cell (i.e. per sector and per
frequency).
The minimum and maximum powers during the reporting period are also provided.
• Sub-Counter #0 : Operational Max Power
• Sub-Counter #1 : Power used
VS.eDCHdataBitRec - #10904
The number of bits (before channel decoding) received at each e-DCH TTI for all active connections.
• Sub-Counter #0: VS.eDCHdataBitRec.Avg
• Sub-Counter #1: VS.eDCHdataBitRec.Cum
• Sub-Counter #2: VS.eDCHdataBitRec.Max
• Sub-Counter #3: VS.eDCHdataBitRec.Min
• Sub-Counter #4: VS.eDCHdataBitRec.NbEvt

Section 2 Pager 24
5.2 UL Cell Load
RTWPmeas
RTWPref + TotalRotMax
CH RTWPmeas
E-D
E-DCH
traffic
Max cell load
H cell load
E-DCH
DC
R99 traffic
+
Interference
RTWPref
Thermal
Noise
BTSCell metrics
UULOAD001_CR_Avg
Average Total Uplink Cell Load = #10211[0].Cum / (#10211[0].NbEvt X 1000)

UULOAD006_CR_Avg
Average EDCH Uplink Cell Load = #10211[1].Cum / (#10211[1].NbEvt X 1000)

VS.CellULload - #10211
The mean UL Load value.
• Total load
• eDCH/HSUPA load

Section 2 Pager 25
5.3 UL Cell Overload
RTWPmeas
CH
E-D
cell overload
E-DCH
DC
BTSCell metrics
VS.eDCHstatus
Number of Load Excess Status = #10907
Maximum Total Uplink Cell Load = #10211.[0].Max/1000 UULOAD001_CR_Max
Maximum HSUPA Uplink Cell Load = #10211.[1].Max /1000 UULOAD006_CR_Max

VS.eDCHstatus - #10907
The LOAD EXCESS status of the HSUPA cell

Section 2 Pager 26
5.4 Average Thermal Noise – Exercise
Find the formula of the Average Thermal Noise metric expressed in
dBm and not in mill Watts, knowing that
#10211 has no unit
#10201 and #10202 unit is 10-12mW
BTSCell metric
Average Thermal Noise (1- #10211.[0].Avg) x #10201.Avg + #10202.Avg

in 10-12mW =
1000 2
BTSCell metric
Average Thermal Noise

in dBm = -120 + 10xlog10(1- #10211.Avg
-120+10LOG10(1-
)
#10211.AVG / (1000))
1000 #10202AVG)/2)
+ 10LOG10 ((#10201.AVG+
+10xlog10
#10201.Avg + #10202.Avg
2
( )
Mean UL Load value.
Note: The load corresponds to the whole traffic in the cell, non-EDCH + EDCH traffic.
VS.RadioWBandRxMainPwr - #10201
Average wide-band received power on the main antenna - at the Rx main channelizer - for each cell (per
sector and per frequency).
VS.RadioWBandRxDivPwr - #10202
Average wide-band received power on the diversity antenna - at the Rx diversity channelizer - for each cell
(per sector and per frequency) on the observation period.

Section 2 Pager 27
5.4 Average Thermal Noise – Exercise [cont.]
Find the formula of the Average Thermal Noise metric expressed in
dBm and not in mill Watts, knowing that
#10211 has no unit
#303 unit is 10-11.2mW
BTSCell metric
Average Thermal Noise (1- # 10211.[0].Avg) x

= #303.Avg
in 10-11.2mW 1000
BTSCell metric
Average Thermal Noise == -112 + 10xlog10(1- #10211.Avg )

in dBm
-110+10LOG10(1- #10211.AVG / 1000
(1000))
+ 10LOG10+10xlog #303.Avg
((#303.AVG)
10 ( )
Mean UL Load value.
Note: The load corresponds to the whole traffic in the cell, non-EDCH + EDCH traffic.
VS.RadioWBandRxMainPwr - #10201
Average wide-band received power on the main antenna - at the Rx main channelizer - for each cell (per
sector and per frequency).
VS.RadioWBandRxDivPwr - #10202
Average wide-band received power on the diversity antenna - at the Rx diversity channelizer - for each cell
(per sector and per frequency) on the observation period.

Section 2 Pager 28
5.5 HSUPA Rise over Thermal (RoT)
RTWPmeas
RTWPref + TotalRotMax RTWPref + TotalRotMax
RTWPmeas E-DCH
E-DCH traffic #10907
traffic #10906
RoT RoT
R99 traffic R99 traffic
+ +
Interference Interference
RTWPref RTWPref
Thermal Thermal
Noise Noise
Find the unit of each of the metrics below

BTSCell metrics
HSUPA Rise Over Thermal = (#10906.Min or .Max or .Avg)/100

UL overload Duration = #10907.Cum x 0,1

VS.eDCHriseOverThermal - #10906
The RoT (rise over thermal) evaluated every 100ms
VS.eDCHstatus - #10907
The LOAD EXCESS status of the HSUPA cell,
means the number of period (equal to 100ms) where RTWPmeas > RTWPmax

Section 2 Pager 29
5.6 Number of HSUPA Users
LCG metric
Average Number of HSUPA UE Per LCG = #10820.Avg

= #10921.Avg
Maximum Number of HSUPA UE Per LCG = #10820.Max
= #10921.Max
#10835 VS.HsdpaUsersCapacity UA6.0: one counter per iBTS

UA7.0: Counter is provided on a
#10836 HsdpaThroughputCapacity per HSxPA #10820.Avg
= resource basis
where resource id is equivalent
#10909 eDCHUsersCapacity to H/E BBU in#10820.Max
case of ICEM
= case of XCEM.
board in
#10910 eDCHThroughputCapacity
screen id Screen Name Suffix 3GPP
0 Number of events NbEvt
1 Sum of HW installed values CumHWcapacity
2 Sum of Licensing values CumLicensing
3 Sum of used values CumUsed
4 Number of successes AllocSuccess
5 Number of refusals or restrictions due AllocLicensingRefusa
to the license l
6 Number of refusals due to the AllocHWfail
hardware capacity

VS.eDCHUEsPerLCG - #10921: Number of HSUPA UEs configured in the LocalCellGroup
VS.HsdpaUsersCapacity - #10835: HSPDA users capacity installed, licencied and used

• Sub-Counter #0: Number of events
• Sub-Counter #1: Sum of HW installed values
• Sub-Counter #2: Sum of Licensing values
• Sub-Counter #3: Sum of used values
• Sub-Counter #4: Number of successes
• Sub-Counter #5: Number of refusals or restrictions due to the license
• Sub-Counter #6: Number of refusals due to the hardware capacity
VS.HsdpaThroughputCapacity - #10836: HSPDA throughput capacity installed, licencied and used

Same screenings as for #10835
Screening3 / Screening0 indicator will provide the average throughput during observation period.
Screening 5 & Screening 6 will provide the number of active TTI periods (2ms or 10 ms) during which the scheduler
restricted the HSDPA throughput because the license or HW throughput limit was reached (time of max throughput)
VS.eDCHUsersCapacity - #10909: eDCH/HSUPA users capacity installed, licencied and used

VS.eDCHThroughputCapacity - #10910: eDCH/HSUPA throughput capacity installed, licencied and used

Screening3 / Screening0 indicator will provide the average throughput during observation period.
Screening 5 & Screening 6 will provide the number of active TTI periods (2ms or 10 ms) during which the scheduler
restricted the HSUPA throughput because the license or HW throughput limit was reached (time of max throughput)

Section 2 Pager 30
6 HSUPA Quality Monitoring


Section 2 Pager 31
6.1 HSUPA HARQ BLER & Average Mac-d Throughput
Explain what the two metrics below really represent
BTSCell metrics UHSUPA004_CR
#10903.Cum
HSUPA HARQ BLER =
#10903.NbEvt + #10903.Cum
BTSCell metrics UHSUPA009_CR
Average HSUPA Mac-d 500 x #10902 .Cum

=
Throughput per User #10905.[1].Cum + #10905.[2].Cum
Find the unit of the UHSUPA009_CR metric

VS.eDCHretransBlocks - #10903
A-Description
Total number of necessary retransmissions for acknowledged Transport blocks (0 means the block has
been correctly received after the first transmission). The blocks discarded due to the maximum
number of retransmissions reached are not taken into account.
Block received correctly (ACK received)
B-Collection
Value
C-Condition (Event)
Block received correctly (ACK received)
VS.eDCHdataBitSentToRNC - #10902
Total number of data bits sent to RNC. It corresponds to the bits of all the MAC-d PDUs sent in
every FP data frame.
VS.eDCHactiveUsers - #10905
Number of active users for a cell is collected every 2ms (it correspond to users that have been received a
grant and currently transmitting an eDPDCH part).
user type:
• 2ms
• 10ms

Section 2 Pager 32
6.2 UL Radio Quality – RSSI
VS.RadioWBandRxMainPwr
#10201 VS.RadioWBandRxDivPwr
#10202
RTWPmeas
(#10201 + #10202) Traffic

2
+
Interference
UL RSSI
RTWPref
Noise Factor
+
Thermal Noise
BTSCell metric
RRC connection
UL RSSI==-120dBm
ULRSSI -120dBm++10xlog
10xlog1010((#
((#10201.Avg
10201.Avg++##10202.Avg)
10202.Avg)//2)
2)

VS.RadioWBandRxMainPwr (#10201):
min/ max/ linear average wide-band received power per sector, per frequency, at the Rx main
channelizer (sampled every 100 ms)
VS.RadioWBandRxDivPw (#10202):
min/ max/ linear average wide-band received power per sector, per frequency, at the Rx diversity
channelizer (sampled every 100 ms)
The Node-B estimates the total UL Radio Load as the linear average between the UL RX Signal Level
measure at bit Main and Diversity antennae.
According to typical values of Thermal Noise and Noise Factor of the Node-B and Rx aerials chain, this
indicator should be not less that –112dBm; typical minimum value should be between –106dBm and –
105dBm.
As the maximum allowed Rot is driven by a parameter lower than 8dB, the maximum value of UL RSSI
should not be over –98dBm = -106dBm + 8dB
The value of this metric should be between -109 dBm and -102 dBm typically.
Max and Min values can also be considered for radio problem investigation.
Delta between Main and Div UL RSSI measurement are also to be considered.

Section 2 Pager 33
6.3 UL Radio Quality - SIR
BTSCell metrics
#10206.[0] = Avg #10206.[5] = Avg #10206.[30] = Avg

#10206.[1] = Cum #10206.[6] = Cum #10206.[31] = Cum
#10206.[2]
#10206.[3]
#10206.[4]
=
=
=
Max
Min
Nb_Evt
#10206.[7]
#10206.[8]
#10206.[9]
=
=
=
Max
Min
Nb_Evt
… #10206.[32]
#10206.[33]
#10206.[34]
=
=
=
Max
Min
Nb_Evt
SF4 SF8 SF256

Minimum SIR for SF2 i+2 = #10206.[5i+3].Min
Average SIR for SF2 i+2 = #10206.[5i].Avg
Maximum SIR for SF2 i+2 = #10206.[5i+2].Max
VS.SIRperSF - #10206
Average UL signal to interference ratio for all communications with one SF (UpLink). Min and Max UL SIR are
also provided per SF value.
Sub-Counter #0: VS.SIRperSF.SF4.Avg
• Sub-Counter #1: VS.SIRperSF.SF4.Cum
• Sub-Counter #2: VS.SIRperSF.SF4.Max
• Sub-Counter #3: VS.SIRperSF.SF4.Min
• Sub-Counter #4: VS.SIRperSF.SF4.NbEvt
• Sub-Counter #5: VS.SIRperSF.SF8.Avg
• Sub-Counter #6: VS.SIRperSF.SF8.Cum
• Sub-Counter #7: VS.SIRperSF.SF8.Max
• Sub-Counter #10: VS.SIRperSF.SF16.Avg
• Sub-Counter #11: VS.SIRperSF.SF16.Cum…….
……..

Section 2 Pager 34
6.4 UL HSUPA Traffic Quality – RLC SDU Throughput
Find the unit of the two metrics below
FDDCell metrics UTraffic032_C_HSUPA
80 x #1555.[14]
RLC SDU HSUPA Throughput =
#1667.[16].Cum
RNC UTraffic025_R_HSUPA
80 x #1543.[14]
RLC SDU HSUPA Throughput =
Σcell(#1667.[16].Cum)

VS.DedicatedUplinkKbytesRlcReferenceCell - #1555 - Number of Kbytes of SDU sent on uplink for the

reference cell.
• Sub-Counter #14: PS I/B HSUPA
VS.UlAsConfIdAvgNbrEstablished - #1667 indicates an average of the number of UlAsConfIds established

• Sub-Counter #16: PS I/B or PS Str HSUPA
VS.DedicatedUplinkKbytesRlc - #1543 - Number of Kbytes of SDU payload received on dedicated uplink

RLCs (from RLC counter: DCH_UL_SDU_TRAFFIC)
VS.UlAsConfIdAvgNbrEstablished - #1667 indicates an average of the number of UlAsConfIds established

• Sub-Counter #16: PS I/B or PS Str HSUPA

Section 2 Pager 35
7 HSUPA Traffic Monitoring


Section 2 Pager 36
7.1 HSUPA Traffic Activity & Penetration Factors
Explain what the two metrics below really represent
Cell metrics UHSUPA010_CR
#10905.[2ms].Cum + #10905.[10ms].Cum
HSUPA Activity Factor =
50 x #1667.[16].Cum
FDDCell metrics UHSUPA011_CR

RAB ACTIVE
#1567.[14]
HSUPA Penetration Factor =
#1567.[0,5-14] RAB ASSIGNED

VS.eDCHactiveUsers - #10905 - Number of active users for a cell is collected every 2ms (it correspond to
users that have been received a grant and currently transmitting an eDPDCH part).
user type
• 2ms
• 10ms
VS.UlAsConfIdAvgNbrEstablished - #1667 - Average of the number of UlAsConfIds (UL calls) established per
iRNC, based on time average over collection period (100ms)
• Sub-Counter #16 : PS I/B or PS Str HSUPA
VS.DedicatedUplinkActivityRlcRefCell - #1567
Time that RAB is actively transmitting data in the uplink
• Sub-Counter #0: Other Ul
• Sub-Counter #1: Any SRB
• Sub-Counter #2: CS speech
• Sub-Counter #3: CS 64 conversational
• Sub-Counter #4: CS streaming
• Sub-Counter #5: PS Str 16
• Sub-Counter #6: PS Str 64
• Sub-Counter #7: PS Str Other
• Sub-Counter #8: PS I/B 8kbps

Section 2 Pager 37
7.2 HSUPA Traffic Volume metrics
BTSCell metric
Average Number of = # 10905.[2ms].Avg + #10905[10ms].Avg

HSUPA Active Users
Reference FDDCell metric URB013_CR_ULHSUPA
Average Number of HSUPA RB = #1667.[16].Avg
Amount of HSUPA Traffic

= #1555.[14]
(RLC SDU kbytes)
EdchNumberUsersWithGrant
The number of users in a cell

= #10914
that have received a grant

VS.eDCHactiveUsers - #10905
Number of active users for a cell is collected every 2ms (it correspond to users that have been received a
grant and currently transmitting an eDPDCH part).
user type
• 2ms
• 10ms
VS.UlAsConfIdAvgNbrEstablished - #1667
indicates an average of the number of UlAsConfIds established per iRNC, based on time average over
collection period
• Sub-Counter #16 : PS I/B or PS Str HSUPA
VS.DedicatedUplinkKbytesRlcReferenceCell - #1555
Number of Kbytes of SDU sent on uplink for the reference cell.
• Sub-Counter #14: HSUPA

Section 2 Pager 38
7.3 User-Perceived Throughput Counter
VS.UserTP.EDCH
Distribution of the user perceived

throughput for interactive/background
traffic in a UMTS cell when using EDCH = #2502
traffic channels in CELL_DCH.
Screenings
The data rate threshold of the screenings can be defined by

the CM attribute PmUserTpConfig.edchThd.
[0] [1] [2] [3] [18] [19]

………………………….
Thd0 Thd1 Thd2 Thd3 Thd17 Thd18


Section 2 Pager 39
Please be reminded to fill in the form

for this module
The form can be found in the first part
of this course documentation


Section 2 Pager 40
End of Module
Module 1


Section 2 Pager 41
Last But One Page
1 All Rights Reserved © Alcatel-Lucent @@YEAR

@@PRODUCT
@@COURSENAME
All Rights Reserved © Alcatel-Lucent @@YEAR

@@COURSENAME - Page 1
Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent
All Rights Reserved © Alcatel-Lucent @@YEAR
@@COURSENAME - Page 2

W-CDMA UA07 HSxPA QoS Analysis and Traffic Load Monitoring - tmo18269D0SGDENI1.0

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

W-CDMA UA07 HSxPA QoS Analysis and Traffic Load Monitoring - tmo18269D0SGDENI1.0

Diunggah oleh

Hak Cipta:

Format Tersedia

9300 W-CDMA

UA07 HSxPA QoS Analysis and

All Rights Reserved © Alcatel-Lucent 2010

All rights reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

2 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

All rights reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

4 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

2. Topic/Section is Positioned Here

3. Topic/Section is Positioned Here

5 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

6 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

Welcome to UA07 HSxPA QoS Analysis and Traffic Load Monitoring

Upon completion of this course, you should be able to:

identify why, when, and how to make performance management

7 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

8 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

9 All Rights Reserved © Alcatel-Lucent 2010

Where you can get further information

If you want further information you can refer to the following:

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

10 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Did you meet the following objectives ?

Yes (or No (or

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

Yes (or No (or

12 All Rights Reserved © Alcatel-Lucent 2010

Thank you for your answers to this questionnaire

All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

12 All Rights Reserved © Alcatel-Lucent 2010

Edition Date Author Remarks

01 2008-12-01 El Abed, Jean-Noel First edition

01.1 2009-03-18 Kieslich, Roland Update to Rel. UA06

02 2009-04-10 Charneau, Jean-Noel Few editorial updates

03 2010-04-28 Nolan, Vincent Update to UA07

All Rights Reserved © Alcatel-Lucent 2010

Upon completion of this module, you should be able to:

Describe HSDPA main KPIs families

13 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

14 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

16 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

17 All Rights Reserved © Alcatel-Lucent 2010

12 All Rights Reserved © Alcatel-Lucent 2010

13 All Rights Reserved © Alcatel-Lucent 2010

14 All Rights Reserved © Alcatel-Lucent 2010

16 All Rights Reserved © Alcatel-Lucent 2010

17 All Rights Reserved © Alcatel-Lucent 2010

1 11 All Rights Reserved © Alcatel-Lucent 2010

1 12 All Rights Reserved © Alcatel-Lucent 2010

1 13 All Rights Reserved © Alcatel-Lucent 2010

1 15 All Rights Reserved © Alcatel-Lucent 2010

1 16 All Rights Reserved © Alcatel-Lucent 2010

If Fair Sharing is disabled

If Fair Sharing is enabled

1 17 All Rights Reserved © Alcatel-Lucent 2010

1 18 All Rights Reserved © Alcatel-Lucent 2010

1 19 All Rights Reserved © Alcatel-Lucent 2010

1 20 All Rights Reserved © Alcatel-Lucent 2010

1 21 All Rights Reserved © Alcatel-Lucent 2010

1 22 All Rights Reserved © Alcatel-Lucent 2010