Tmo18269 v2.0 Hspa Qos SG Ua08 Ed1 Ce PDF

Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent
Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

TERMS OF USE AND LEGAL NOTICE
Alcatel-Lucent provides this training course to you subject to these Terms of Use and Legal Notice. Your use of this training
course and/or this site constitutes your acceptance of and agreement to these Terms of Use and Legal Notice. These Terms
of Use and Legal Notice, as well as the contents of this training course, may be updated or amended by Alcatel-Lucent from
time to time without prior notice to you. Your use of the Alcatel-Lucent training materials after such update or amendment
constitutes your acceptance of and agreement to said updated or amended Terms of Use and Legal Notice.
SAFETY WARNING
Alcatel-Lucent training materials can be for products or refer to products that have both lethal and dangerous voltages
present. Always observe all safety precautions and do not work on the equipment alone. The user is strongly advised not to
wear conductive jewelry while working on the products. Equipment referred to or used during this course may be
electrostatic sensitive. Please observe correct anti-static precautions.
PERMISSION TO USE CONTENT

The information, communications, scripts, photos, text, video, graphics, music, sounds, images and other materials provided
in this training course (collectively the "Content"), is intended for the lawful use of employees of Alcatel-Lucent and other
authorized participants in this Alcatel-Lucent training course. You are hereby granted a non-exclusive, non-transferable
permission to access and use the Content solely for your personal training and non-commercial use. This permission may be
terminated by Alcatel-Lucent at any time for any reason or no reason, with or without notice. You must immediately cease
use of the Content upon such termination.
COPYRIGHTS AND TRADEMARKS

The unauthorized copying, displaying or other use of any Content from this training course is a violation of the law and
Alcatel-Lucent’s corporate policies. The Content is protected in France, the U.S. and other countries by a variety of laws,
including but not limited to, copyright laws and treaty provisions, trademark laws, patent laws and other proprietary rights
laws (collectively, "IP Rights"). In addition to Alcatel-Lucent’s IP Rights in the Content, in part and in whole, Alcatel-Lucent,
and any of the third parties who have licensed and/or contributed to the Content, owns a copyright in the formatting and
presentation of the Content.
Alcatel-Lucent does not grant you any permission to use the Content other than the permission expressly stated in these
Terms of Use and Legal Notice. All other use of Content from this training course, including, but not limited to, modification,
publication, transmission, participation in the transfer or sale of, copying, reproduction, republishing, creation of derivative
works from, distribution, performance, display, incorporation into another training course or presentation, or in any other way
exploiting any of the Content, in whole or in part, for uses other than those expressly permitted herein is strictly prohibited
and shall not be made without Alcatel-Lucent’s prior written consent. All characters appearing in this training course are
fictitious. Any resemblance to real persons, living or dead, is purely coincidental.
There may be a number of proprietary logos, marks, trademarks, slogans and product designations found in the
Content. Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logos are trademarks of Alcatel-Lucent. All other trademarks
are the property of their respective owners. Alcatel-Lucent does not grant you a license to use any of the foregoing logos,
marks, trademarks, slogans and product designations in any fashion. Granting of the right to access and use the Content for
training purposes does not confer upon you any license under any of Alcatel-Lucent’s or any third party's IP Rights.
DISCLAIMER
ALCATEL-LUCENT DISCLAIMS ALL WARRANTIES REGARDING THE TRAINING COURSES OR THE CONTENT, EXPRESS OR
IMPLIED, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. THE ALCATEL-LUCENT WILL NOT BE RESPONSIBLE OR LIABLE FOR ANY INJURY, LOSS, CLAIM,
DAMAGE, OR ANY SPECIAL, EXEMPLARY, PUNITIVE, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES OF ANY KIND
(INCLUDING WITHOUT LIMITATION LOSS PROFITS OR LOSS SAVINGS), WHETHER BASED IN CONTRACT, TORT, STRICT
LIABILITY OR OTHERWISE, THAT ARISES OUT OF OR IS IN ANY WAY CONNECTED WITH (A) ANY USE OR MISUSE OF THE
CONTENT OR THE TRAINING COURSES BY YOU, OR (B) ANY FAILURE OR DELAY BY ALCATEL-LUCENT, ITS OFFICERS,
DIRECTORS, AGENTS OR EMPLOYEES IN CONNECTION WITH THE CONTENT OR THE TRAINING COURSES (INCLUDING,
WITHOUT LIMITATION, THE USE OF OR INABILITY TO USE ANY COMPONENT OF THE CONTENT OR TRAINING BY
YOU). SOME JURISDICTIONS LIMIT OR PROHIBIT SUCH EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITIES
AND SO THE FOREGOING EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITY MAY NOT APPLY TO YOU.
GOVERNING LAW
These Terms of Use and Legal Notice are governed by the laws of France. The operation and use of the training course is
governed by the laws of the country that governs your employment contract, if applicable. If any provision of these Terms of
Use and Legal Notice, or the application thereto to a person or circumstance, is held invalid or unenforceable by law, statute
or a court of competent jurisdiction, for any reason, then such provision shall be modified and/or superseded by a provision
that reflects the intent of the original provision as closely as possible. All other provisions of these Terms of Use and Legal
Notice shall remain in full force and effect. You may not assign these Terms of Use or any permission granted hereunder
without Alcatel-Lucent’s prior written consent. Nothing herein shall be deemed an employment agreement or an offer of
employment or an alteration in any way of a user’s terms of employment with or within Alcatel-Lucent.
Copyright © 2011 Alcatel-Lucent. All Rights Reserved

Welcome to UTRAN
9300 W-CDMA HSxPA QoS Analysis and Traffic Load Monitoring
1. HSDPA Monitoring
1. HSDPA Performance Monitoring
2. HSUPA Monitoring
1. HSUPA Performance Monitoring
3. Abbreviations and Acronyms
1. Abbreviations and Acronyms

UTRAN
9300 W-CDMA HSxPA QoS Analysis and Traffic Load Monitoring
Upon completion of this course, you should be able to:
identify why, when and how to do performance management

define counters, metrics and explain how to use metrics, describe the six metrics families
illustrate the call flows associated with each metric family, identify the counters and locate them in
the call flow procedure
analyze UTRAN QoS problem with KPIs: detect problems, identify them using metrics, propose
actions to solve them
monitor traffic load with KPIs
This course is updated with the introduction of the UA08 features
Your feedback is appreciated!

Please feel free to Email your comments to:
training.feedback@alcatel-lucent.com
Please include the following training reference in your email:

TMO18269_V2-SG Edition 1
Thank you!

TMO18269_V2-SG-Ed1 Module 1.1 Edition 1
Section 1 · Module 1 · Page 1
This page is left blank intentionally
Document History
Edition Date Author Remarks
01 YYYY-MM-DD Last name, first name First edition


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 diagram 13
2.2 RAB matching and CAC 14
2.3 RAB assignment success: counters 15
2.4 HSDPA to DCH fallback 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 Exercise - HSDPA call drop per minute of call 26
4 HSDPA mobility monitoring 27
4.1 Introduction 28
4.2 HSDPA to non-HSDPA mobility 29
4.3 HSDPA to DC-HSDPA mobility 31
4.4 Non-HSDPA to HSDPA mobility 32
4.5 HDSPA Primary cell change 35
5 HSDPA capacity monitoring 36
5.1 HSDPA power monitoring 37
5.2 HSDPA power: power not used for HSDPA 38
5.3 HSDPA power: indicators 39
5.4 HSDPA codes and users: indicators 43
6 HSDPA traffic monitoring 44
6.1 HSDPA calls, activity, RLC SDU throughput 45
6.2 User-perceived throughput counter 46
6.3 HSDPA call duration, traffic penetration 48
6.4 HSDPA call attempts per category 49
7 HSDPA quality monitoring 51
7.1 HSDPA cell throughput 52
7.2 HSDPA UE throughput, BLER 53
7.3 HSDPA HARQ feedback: ACK/NACK/DTX 54
7.4 HSDPA CQI 55
7.5 HSDPA modulation 57
8 GBR on HSDPA & fair sharing 59
8.1 GBR performance metrics 60
8.2 GBR and fair sharing performance troubleshooting 62
8.2.1 Mac-hs GBR fulfilled or not? 63
8.2.2 HSDPA cell throughput degradation 64
8.2.3 RNC CAC unsuccess increase 65

Page

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, the 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 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 channels and HS-SCCH physical channels.

A Node B can handle up to 4 HSDPA layers and 4 E-DCH layers.

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 the success rate for the HSxPA RB to end normally? How long can the HSxPA Radio
Bearer (RB) 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 are the amount of HSxPA traffic and the HSxPA activity duration?
Quality: Key metrics. What is the throughput provided based on radio quality and limitations?
For all the metrics listed, it is recommended to monitor daily during at least 2 weeks before analyzing results and
taking the appropriate actions.

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

The Fair Sharing feature is divided in two algorithms: one algorithm at RNC level managing the HSDPA CAC and one
algorithm at Node B level managing the OVSF code tree. The two algorithms need to be activated together in order to have
a correct behavior:
Flag(RNC; NodeB) = (True; True) =
(isHsxpaR99ResourcesSharingOnCellAllowed; hsdpaCodeTreeManagementActivation)
From the RNC point of view, when isHsxpaR99ResourcesSharingOnCellAllowed = True:
At cell setup, the RNC sends to the Node B a PSCR message with the HS-PDSCH code configuration that the mac-hs
scheduler has to use. This PSCR message considers that 15 HS-PDSCH codes can be used by the mac-hs scheduler.
The RNC considers that all the codes not used by R99 or reserved for HSDPA are free.
At cell setup, only ccc are reserved (no R99 and HSDPA call).
No other PSCR message is sent after cell setup.
From the Node B point of view, when hsdpaCodeTreeManagementActivation = True:
At cell setup, the Node B receives from the RNC a PSCR message. The number of HS-PDSCH codes configured
according to this PSCR depends on the RNC algorithm (Fair Sharing: 15; DCTM: 12 with the recommended setting; 5 or
10 if Fair Sharing and DCTM are disabled).
After the cell setup, the number of HS-PDSCH codes available by the scheduler is updated according to the R99
admission or release thanks to the Fair Sharing algorithm.
If a new PSCR message is received (in case of DCTM enabled), the scheduler will use this information to know how
many HS-PDSCH codes are available.
If (True; True) then the behavior is correct, If (False; False) then the behavior is correct.
If (True; False) then the scheduler is not able to update its view of the OVSF code tree occupancy and configure 15 HS-
PDSCH codes whatever the R99 calls admitted by the RNC. This leads to a conflict between R99 codes allocated by the RNC
and the HS-PDSCH codes used by the scheduler. In this case, an increase of the BLER can be observed; If (False, True) then
the Node B is able to update its view of the OVSF code tree occupancy and is able to manage the reception of the PSCR
message. This configuration should not lead to any issue but is not a recommended configuration (the NodeB Fair Sharing
algorithm is not designed to receive several PSCRs).

VS.RadioBearerSetupRequest #1652: the number of Radio Bearer establishments to be performed
following a valid RAB assignment request received from the CN. This measurement provides the number of RBs
to be set up 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: the number of successful Radio Bearer establishments. This

measurement provides the number of successful RB setups.
VS.RabEstablishmentSuccessPerGrantedRabType #1658: the number of successful RAB establishments

per granted RAB type. This measurement provides the number of successful RAB establishments 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

The CAC success and failure scenarios for HSDPA are covered by the following basic indicators:
U958:
The number of unsuccessful attempts to access the cell for an HSDPA call during mobility or RAB
establishment procedure. It is screened based on the maximum number of HSDPA users in the cell,
maximum number of streaming HSDPA users in the cell and maximum aggregated GBR exceeded. The last
two screenings are only pegged when Fair Sharing and GBR features are activated.
U957:
The number of successful HSDPA CACs, during mobility and RAB establishment procedure.
In case of HSPA CAC failure, the HSxPA to DCH fallback feature allows reconfiguring UL and/or DL into DCH.
The fallback procedure is monitored through the following basic indicators:

VS_SucHspaToDchFallbackCell (U1601): the number of calls successfully fallen back from HSxPA to
DCH on RAB assignment, mobility or reconfiguration event. This applies for E-DCH/HS-DSCH to DCH/HS-
DSCH, E-DCH/HS-DSCH to DCH/DCH and DCH/HS-DSCH to DCH/DCH reconfigurations. There is also an
equivalent NRNC basic indicator (U1602).
VS_UnsucHspaToDchFallbackCell (U1603): the number of calls unsuccessfully fallen back from HSxPA
to DCH on RAB assignment, mobility or reconfiguration event. This applies for the same configurations as
above, and there is also an equivalent NRNC basic indicator (U1604).

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 GBRs 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 the DCH to
HSDPA procedure.

VS.SucHspaToDchFallbackCell - #1601
The number of calls successfully fallen back 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
The number of calls unsuccessfully fallen back 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
The number of Radio Bearers set up successfully. The counter should be pegged multiple times for multiple RBs
successfully set up in the same procedure. Incremented on the Reference cell of the call.

VS.RabEstablishmentSuccessPerGrantedRabType - #1658
The number of successful RAB establishments, screened per granted RAB type. Granted should be understood
as after RNC CAC (iRM, etc.). 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 the 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 the IRM algorithm),
therefore could not be pegged in case of CAC rejection. Since CR Q01244717, the counter is pegged accordingly
to the requested Downlink AsConfId, then also allowing pegging in case of CAC rejection.
A set of sub-counters screened on: Target Type of call setup mapping:
The number of Radio Bearers set up successfully. The counter should be pegged multiple times for multiple RBs

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: Signaling 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 HSDPA calls dropped corresponds to sub-counter
VS.IuAbnormalReleaseRequestPs.#13

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: Signaling Only
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 #14: xPCH
Sub-Counter #15: Any CS
Therefore the number of HSDPA calls dropped corresponds to sub-counter

VS.IuAbnormalReleaseRequestPs.#13

Number of HSDPA drops per minute/hour of call, calculated by dividing the number of HSDPA dropped
calls by the call duration in minutes or hours. This is an accurate metric, as it is weighted by traffic and is
independent of mobility and Always-On procedures, since we are not using the number of calls that start within
a cell, but the duration of all the calls that are served by the cell.

As the HSDPA RAB does not support soft or softer handover, the mobility strategy is not the same as for R99
traffic. Therefore, the main procedures to monitor are the following:
HSDPA to non-HSDPA and non-HSDPA to HSDPA mobility, when the UE moves from the HSDPA
coverage to R99 area and vice-versa.
HSDPA primary cell change, when the UE moves within the HSDPA coverage area.

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 so 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 an 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 an 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 an R5 (or later release) mobile sends its connection request in the
non-HSDPA layer, it is redirected to the HSDPA layer.
In UA08.1, the iMCRA Step2 feature provides a powerful programmable RRC redirection action matrix allowing
one to explore Service Segmentation, Sequential Loading, Load Balancing and Offloading capabilities
by their own or in a mixed strategy depending on load conditions. Two different strategies are recommended:
Dynamic Segmentation and Load Balancing and DATA Sequential Loading and CS offloading

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, 4) HSDPA Dual Cell to HSDPA Dual Cell, 5) HSDPA Cell to HSDPA Dual Cell, 6)R99 to HSDPA Dual Cell,
7) HSDPA Dual Cell to HSDPA Cell, 8) HSDPA Dual Cell to R99.
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.
VS_HsdpaMobilitySuccess_HsdpaToHsdpa U950_0
VS_HsdpaMobilitySuccess_NonHsdpaToHsdpa U950_1
VS_HsdpaMobilitySuccess_HsdpaToNonHsdpa U950_2
VS_HsdpaMobilitySuccess_HsdpaToHsdpaInterFreq U950_3
VS_HsdpaMobilitySuccess_NonHsdpaToHsdpaInterFreq U950_4
VS_HsdpaMobilitySuccess_HsdpaToNonHsdpaInterFreq U950_5
VS_HsdpaMobilitySuccess_HsdpaDCToHsdpaDC U950_6
VS_HsdpaMobilitySuccess_HsdpaToHsdpaDC U950_7
VS_HsdpaMobilitySuccess_NonHsdpaToHsdpaDC U950_8
VS_HsdpaMobilitySuccess_HsdpaDCToHsdpa U950_9
VS_HsdpaMobilitySuccess_HsdpaDCToNonHsdpa U950_10
VS_HsdpaMobilitySuccess_HsdpaDCToHsdpaDCInterFreq U950_11
VS_HsdpaMobilitySuccess_HsdpaToHsdpaDCInterFreq U950_12
VS_HsdpaMobilitySuccess_NonHsdpaToHsdpaDCInterFreq U950_13
VS_HsdpaMobilitySuccess_HsdpaDCToHsdpaInterFreq U950_14
VS_HsdpaMobilitySuccess_HsdpaDCToNonHsdpaInterFreq U950_15

HSDPA-DC to HSDPA mobility:
SuccessfulHSDPADCtoHSDPAmobilityrate_HSDPA098_CR_Inter_freq
=(( U950_14 ))/(( U950_14 )+( U951_14 ))
SuccessfulHSDPADCtoHSDPAmobilityrate_HSDPA098_CR_Intra_freq
=(( U950_9 ))/(( U950_9 )+( U951_9 ))

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.
VS_HsdpaMobilityUnsuccessful_HsdpaToHsdpa(U951_0) U951_0
VS_HsdpaMobilityUnsuccessful_NonHsdpaToHsdpa(U951_1) U951_1
VS_HsdpaMobilityUnsuccessful_HsdpaToNonHsdpa(U951_2) U951_2
VS_HsdpaMobilityUnsuccessful_HsdpaToHsdpaInterFreq(U951_3) U951_3
VS_HsdpaMobilityUnsuccessful_NonHsdpaToHsdpaInterFreq(U951_4) U951_4
VS_HsdpaMobilityUnsuccessful_HsdpaToNonHsdpaInterFreq(U951_5) U951_5
VS_HsdpaMobilityUnsuccessful_HsdpaDCToHsdpaDC(U951_6) U951_6
VS_HsdpaMobilityUnsuccessful_HsdpaToHsdpaDC(U951_7) U951_7
VS_HsdpaMobilityUnsuccessful_NonHsdpaToHsdpaDC(U951_8) U951_8
VS_HsdpaMobilityUnsuccessful_HsdpaDCToHsdpa(U951_9) U951_9
VS_HsdpaMobilityUnsuccessful_HsdpaDCToNonHsdpa(U951_10) 951_10
VS_HsdpaMobilityUnsuccessful_HsdpaDCToHsdpaDCInterFreq(U951_11) 951_11
VS_HsdpaMobilityUnsuccessful_HsdpaToHsdpaDCInterFreq(U951_12) 951_12
VS_HsdpaMobilityUnsuccessful_NonHsdpaToHsdpaDCInterFreq(U951_13) 951_13
VS_HsdpaMobilityUnsuccessful_HsdpaDCToHsdpaInterFreq(U951_14) 951_14
VS_HsdpaMobilityUnsuccessful_HsdpaDCToNonHsdpaInterFreq(U951_15) 951_15

VS.HsdpaDCHToHsdpaTransSucc - #953 (number of successful DCH to HSDPA transitions)
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 transitions)
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 transitions)
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)
VS.HsdpaToDCHUnsuccessful - #956 (number of unsuccessful HSDPA to DCH transitions)
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)
VS.DlAsConfIdAvgNbrEstablished - #1666 indicates an average of the number of DlAsConfIds established per iRNC,
based on time average over collection 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 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.

VS.HsdpaNonHSDPATxPwr - #10842
Total transmitted power on non-HSDPA codes per TTI.
It is a LOAD counter.
Min/max/linear average (software filtered) total transmitted power per sector and per frequency at the Tx
channelizer.
#0: Operational Max Power (varies at a low frequency)
#1: Power used
It is a LOAD counter.

For the monitoring of the HSDPA power usage, indicator AverageHSDPAPowerused_HSDPA010_CR should be
used. It assesses the percentage of the total power used that is consumed by HSDPA.
This indicator is based on the average power for all allocated HS-PDSCH codes per TTI, average power for all
transmitted HS-SCCH codes per TTI and maximum total transmitted power per sector and per frequency.
Values are highly dependent on traffic. During low traffic hours, or in low loaded cells, values are normally below
10%. During the busiest hours, it is expected to have much higher values.

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

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 the above counters are defined with a set of sub-counters screened on: Power ratio

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 an xCEM is able to manage 2 LCGs, the sum of the 2
LCGs has to be done to get entire xCEM board information.

Number of Radio Bearers set up successfully. The counter should be pegged multiple times for multiple RBs
• 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
• Sub-Counter #16: PS I/B or PS Str HSDPA/E-DCH
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 a 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 SDUs sent downlink for
the reference cell: Sub-Counter #5: PS HSDPA

VS.UserTP.HSDPA - #2503
Distribution of the user perceived throughput for interactive/background traffic in a UMTS cell when using
HSDPA traffic channels in CELL_DCH. The data rate threshold of the screenings can be defined by the CM
attribute PmUserTpConfig.hsdpaThd.
Pegged against the reference cell. For the calculation, the RNC accumulates the RLC payload data which has
been acknowledged by the UE while the UE was in CELL_DCH state using HSDPA and the duration of the data
transfer. This counter is pegged when:
a UE with an I/B RAB mapped to HSDPA is leaving the CELL_DCH state.
the UE with an I/B RAB mapped to HSDPA is reconfigured to another frequency layer.
there is a reconfiguration of the HSDPA transport channel from HSDPA to R99 DCH.
The RNC triggers:
an intra-RNC interfrequency handover,
an inter-RAT handover,
a cell change order procedure for a UE which has an I/B RAB mapped to HSDPA.
Data Rate Range HSDPA
Sub-Counter #0: rate <= hsdpaThd[0]
Sub-Counter #1: hsdpaThd[0] < rate <= hsdpaThd[1]
…
Sub-Counter #19: hsdpaThd[18] < rate

In UA07.1, the HSDPA User Perceived Throughput counter (#2503) was introduced, so the HSDPA User
Perceived Throughput per range (defined by OA&M parameter hsdpaThd ) can be monitored.
In UA08, the HSDPA Volume and Time per UE Category are introduced (#2505 and #2506).

VS.DlAsConfIdAvgNbrEstablished - #1666 indicates an average of the number of DlAsConfIds established
per iRNC, based on time average over a collection period.
Sub-Counter # 20 : HSDPA
VS.HsdpaCACSuccess - #957 - Number of HSDPA CACs
VS.UpsizingSuccess - #1743 - Number of successful upsizings 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.DedicatedDownlinkKbytesRlcActiveCells - #1554 - Number of kbytes of SDUs sent downlink for each

cell of the active set
Sub-Counter #5: PS HSDPA
VS.DedicatedDownlinkActivityRlcRefCell - #1566 - Time that RAB is actively transmitting data in the

downlink. Downlink Traffic Counter Screenings:
Sub-Counter #0: Other Dl
Sub-Counter #6 – #9: PS Str
Sub-Counter #10 - #16: PS I/B
ErlangHsdpa_Traffic057_C_hsdpa = CumulatedNumberOfDLBearersEstablished_RB021_CR_HSDPA /36000

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:
VS_CallAttWithUeCatPerCell_UeCategory1(U1622_0)

Dual-Cell HSDPA UE categories: Cat21, Cat22, Cat23, Cat24

VS.HsdpaMACdPDUAckBits - #10806
Total number of successfully transmitted MAC-d PDU bits (an ACK has been received for the corresponding
transport block).
VS.HsdpaTTIsUsed - #10818
Number of TTIs containing at least one scheduled UE. It allows new statistics to be derived for some previous
counters.
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.HsdpaTxDataBitsSchedTotal - #10809
Number of data bits (transport block size) scheduled any TTI, taking into account the retransmissions. Any time
a block is retransmitted, its bits are added.

VS.HsdpaTxDataBitPerUEcat - #10826
Number of transmitted bits, per UE category (only first transmissions are considered).
distribution according to the UE category
Sub-Counter #0: For UE category 1
......
VS.HsdpaTTIperUEcat - #10825
number of TTIs for which there is data to be transmitted, per UE category
Same screenings as for #10826
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).
VS.DedicatedDownlinkPdusRlcReferenceCell - #1558
Number of RLC PDUs sent downlink for the reference cell.

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 DTXs detected (neither 'ACK' nor 'NACK' received for a transmitted transport block).

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

U10851_0: VS_HsdpaTrafficModType_QPSK
HSDPA traffic used per modulation type.
Screening: Traffic on QPSK
Trigger: Every 2 ms TTI
3GPP Counter: VS.HsdpaTrafficModType.QPSK
U10851_1: VS_HsdpaTrafficModType_16QAM
Screening: Traffic on 16QAM
3GPP Counter: VS.HsdpaTrafficModType.16QAM
U10851_2 : VS_HsdpaTrafficModType_64QAM
Screening: Traffic on 64-QAM
3GPP Counter: VS.HsdpaTrafficModType.64QAM

GBR over HSDPA management in UTRAN increases the sustainable number of streaming users versus streaming
over Release 99.
VS.HsdpaMACdPDUAckBitsForGbr - #10830
transport block) for flows configured with a non-null GBR.
Sub-Counter #0: Number of TTIs
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).

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 (1 s) that either fulfill their
GBR or that are in starvation (cause external to Node B).
Sub-Counter #0: For SPI 0
...
Sub-Counter #16: Number of sampling periods

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 cannot 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.

#10833 - VS.HsdpaGbrDeficitRatioPerSpi: This counter represents the observed throughput deficit over a given
period (1 s) due to radio congestion, expressed as a percentage of configured GBRs for all unsatisfied GBR
flows.
#10831 - VS.HsdpaFullCodeUsageByGbr: Number of TTIs with no remaining HS-PDSCH code after scheduling.
#10832 - VS.HsdpaGbrPowerUsage: Percentage of available HSDPA power used for GBR flows (note that the
available HSDPA power is continuously updated and corresponds to unused power by DCH and CTCH).

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 TTIs
Sub-Counter #1: Number of ACKed bits
VS.HsdpaHSPDSCHCodesPerTTI - #10802
Number of HS-PDSCH codes used per TTI.

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

Document History


Page
1 HSUPA performance monitoring 7

1.1 Recall 8
2 HSUPA accessibility monitoring 9
2.1 HSUPA CAC 10
2.2 HSUPA fallback 13
2.3 Overall E-DCH accessibility 16
3 HSUPA retainability monitoring 19
3.1 HSUPA mobility call drop rate 20
3.2 HSUPA radio call drop rate 21
3.3 HSUPA call drops 22
3.4 HSUPA call drop per minute of call - exercise 23
4 HSUPA mobility monitoring 24
4.1 HSUPA primary cell change per minute of call 25
4.2 HSUPA mobility success: indicators 26
5 HSUPA capacity monitoring 30
5.1 HSUPA common channels power 31
5.2 UL cell load 32
5.3 UL cell overload 33
5.4 Average thermal noise - exercise 34
5.5 HSUPA Rise over Thermal (RoT) 36
5.6 Number of HSUPA users 38
6 HSUPA quality monitoring 40
6.1 HSUPA HARQ BLER & Average mac-d throughput 41
6.2 UL radio quality - RSSI 42
6.3 UL radio quality - SIR 43
6.4 UL HSUPA traffic quality - RLC SDU throughput 44
7 HSUPA traffic monitoring 45
7.1 HSUPA traffic activity & penetration factors 46
7.2 HSUPA traffic volume metrics 47
7.3 User-perceived throughput counter 48


A specific E-DCH transport channel is defined. As the classical DCH transport channel, it allows one to offer
transport services to higher layers.
The E-DCH transport channel is defined by the following characteristics:
Only for UL
Two possible TTIs: 10 ms and 2 ms.
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. The maximum number
of retransmissions 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 the Chase combining or Incremental Combining
mechanism:
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-bit length
Transport Format Combination Indication for E-DCH (E-TFCI) indicates which format is
currently used for the UL transmission.

The specific Call Admission functions for E-DCH are based on several criteria: the RNC controls the number
of E-DCH users per cell, the Node B controls the number of E-DCH users per CEM board and the Channel
Element decoding resource availability.
The RNC E-DCH CAC success and failure events are covered by the following basic indicators:
VS.HsupaCACUnsuccess (U1090): the number of unsuccessful accesses to the cell for an HSUPA
call during the mobility or establishment procedure.
VS.HsupaCACSuccess (U1089): the number of successful accesses to the cell for an HSUPA call
during the mobility or establishment procedure.
If the RNC E-DCH CAC fails for a 2-ms TTI and further succeeds as 10-ms TTI (2 ms to 10 ms fallback),
then the #1090 is not incremented: only the #1089 is incremented.

U10909_EDCH_6:
if the Node B E-DCH CAC for a 2-ms TTI or a 10-ms TTI fails on the maximum capacity 128, this counter is
incremented. If it fails for a 2-ms TTI on the configurable capacity called ‘credits’, refer to TMO18488 UA07-
UA08 Telecom Evolution. This counter is not incremented.
U10909_EDCH_6:
E-DCH/HSUPA users capacity installed, licensed and used
Screening: the number of refusals or restrictions due to the hardware capacity
Trigger: a sampling event generated by the CCM CallP every 5 seconds (for screenings #0/1/2/3)
3GPP Counter: VS.eDCHUsersCapacity.AllocHWfail
U38_11: VS_RadioLinkSetupUnsuccess_NotEnoughUserPlaneProcessingResources
Trigger: unsuccessful management of radio link setups (RADIO_LINK_SETUP_FAILURE OR TIME
OUT) (counted per (failed) radio link and not per message)
U40_10:
VS_RadioLinkReconfigurationPrepareUnsuccess_NotEnoughUserPlaneProcessingResources
Trigger: unsuccessful management of radio link reconfiguration preparations (RADIO_LINK_REC
ONFIGURATION_FAILURE OR TIMEOUT or Rrm Refusal) (counted per radio link and not per me
ssage)
U41_11: VS_RadioLinkFirstSetupFailure_NotEnoughUserPlaneProcessingResources
Trigger: reception of NBAP RL Setup Response/Failure related to the first radio link of a call or re
jection due to a lack of resources (RRM refusal).
Since UAà7.1.3.8, the screening “NodeBCEMLackL1Rsrc” is used instead of

“NotEnoughUserPlaneProcessingResources” for the 2-ms TTI CAC failures on the credits.

VS.SucHspaToDchFallbackCell - #1601 – the number of calls successfully fallen back 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 – the number of calls unsuccessfully fallen back 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 – the number of Radio Bearers set up successfully. The counter
should be pegged multiple times for multiple RBs successfully set up in the same procedure. Incremented
on the Reference cell of the call.

When a fallback from 2-ms TTI to 10-ms TTI is performed during the RAB Establishment or RB Setup
procedure, the E-DCH RAB Success Rate and E-DCH RB Setup Success Rate is not impacted since the RB
remains E-DCH anyway.

VS.EdchIuRelAbnormal - #0963 – the number of Iu releases requested by the 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 – the number of Radio Bearers set up successfully. The counter
should be pegged multiple times for multiple RBs successfully set up in the same procedure. Incremented
on the Reference cell of the call.

VS.EdchCellDeletion - #962 – the number of E-DCH Cell Deletions
Sub-Counter #0: Deletion during Active Set Update
Sub-Counter #1: Deletion due to Radio Link failure
The number of Radio Bearers set up successfully. The counter should be pegged multiple times for multiple
RBs successfully set up in the same procedure. Incremented on the Reference cell of the call.
VS.RadioBearerSetupSuccessNeighbRnc - #1651
The number of Radio Bearers successfully set up (from serving iRNC) when the reference Cell of the call
belongs to a drift RNC. The counter should be pegged multiple times for multiple RBs successfully set up in
the same procedure.

VS.IuAbnRelReqPsPerULRb - #590 – The number of Iu abnormal release requests 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

VS.EdchSucMobility - #968 - the number of successful E-DCH mobility.
Sub-Counter #0: E-DCH Call (TTI=10 ms) to E-DCH Call (TTI=10 ms) (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 a collection
period.
Sub-Counter #16: PS I/B or PS Str HSUPA

VS.EdchSucMobility - #968
Number of successful E-DCH mobility (Primary cell change).
Sub-Counter #7: E-DCH Call (TTI=2 ms) to E-DCH Call (TTI= 2 ms) (intra frequency mobility)
VS.EdchUnsucMobility - #969
Number of unsuccessful E-DCH mobility.
Same screenings as for #968.



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.
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

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

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

Mean UL Load value.
Note: The load corresponds to the whole traffic in the cell, non-E-DCH + E-DCH traffic.
VS.RadioWBandRxMainPwr - #10201
Average wideband received power on the main antenna - at the Rx main channelizer - for each cell (per
sector and per frequency).
VS.RadioWBandRxDivPwr - #10202
Average wideband received power on the diversity antenna - at the Rx diversity channelizer - for each cell
(per sector and per frequency) on the observation period.

Mean UL Load value.
Note: The load corresponds to the whole traffic in the cell, non-E-DCH + E-DCH traffic.
VS.RadioWBandRxMainPwr - #10201
Average wideband received power on the main antenna - at the Rx main channelizer - for each cell (per
sector and per frequency).
VS.RadioWBandRxDivPwr - #10202
Average wideband received power on the diversity antenna - at the Rx diversity channelizer - for each cell
(per sector and per frequency) on the observation period.

VS.eDCHriseOverThermal - #10906
The Rise over Thermal (RoT) evaluated every 100 ms
VS.eDCHstatus - #10907
The LOAD EXCESS status of the HSUPA cell means the number of periods (equal to 100 ms) where
RTWPmeas > RTWPmax
The counter eDCHstatus(#10907) indicates the load excess status of the HSUPA cell. The cell is considered
as loaded if the measured RoT is above the maximum RoT configured for the cell.
Before UA08.1 release, the overload was triggered when the RoT exceeded a fixed value of 6 dB regardless
of the total RoT max setting.
In UA08.1, this behavior is corrected and now the overload is triggered (eDCHstatus = 1) only if the
measured RoT exceeds the configured total RoT max.

VS.eDCHUEsPerLCG - #10921: the number of HSUPA UEs configured in the LocalCellGroup.
VS.HsdpaUsersCapacity - #10835: HSPDA users capacity installed, licensed 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, licensed and used.

Screening3 / Screening0 indicator will provide the average throughput during the observation period.
Screening 5 & Screening 6 will provide the number of active TTI periods (2 ms 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: E-DCH/HSUPA users capacity installed, licensed and used

VS.eDCHThroughputCapacity - #10910: E-DCH/HSUPA throughput capacity installed, licensed and

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

On the Node B, the Channel Element boards have a certain capacity regarding the number of connected E-
DCH 2-ms TTI and 10-ms TTI users.
From UA07.1.3.8 and from UA08.1.3 onwards, it is possible to monitor the maximum number of 2-ms TTI
users and the maximum number of 10-ms TTI users reached on a given board.
These metrics have been defined in spare counters (temporary solution). They are displayed per cell but
actually they work per board. They usually only show up on one cell, other cells in the same Node B
will report N/A or 0 (except if some events like cell Lock/Unlock occurred, in that case two different cells
may show values).
The consequence of this byte-style mapping is that the direct VS_SpareBTS counters aggregation done by
NPO cannot work properly.
A way to use them is:
1. Collect the counters #11001 to #11006 for all the cells under one iBTS
2. Remove the cells with all counters being 0 or N/A
3. Perform the byte extraction:
byte1 = INT(counter1100x / 16777216)
byte2 = MOD( INT(counter1100x / 65536); 256 )
byte3 = MOD( INT(counter1100x / 256); 256 )
byte4 = MOD( counter1100x; 256 )
4. if pmObservationPeriod in the iBTS is 60 minutes, you need to export data hourly.
5. if pmObservationPeriod in the iBTS is 15 minutes, you need to export data quarterly.

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 the 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 collected every 2 ms (it corresponds to users who have been received a
grant and who are currently transmitting an E-DPDCH part).
User type:
2 ms
10 ms

VS.RadioWBandRxMainPwr (#10201):
min/ max/ linear average wideband received power per sector, per frequency, at the Rx main
channelizer (sampled every 100 ms)
VS.RadioWBandRxDivPw (#10202):
min/ max/ linear average wideband 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 aerial chain, this
indicator should be not less than –112 dBm. Typical minimum value should be between –106 dBm and –
105 dBm.
As the maximum allowed Rot is driven by a parameter lower than 8 dB, the maximum value of UL RSSI
should not be over –98 dBm = -106 dBm + 8 dB.
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.

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 #7: VS.SIRperSF.SF8.Max
...

VS.DedicatedUplinkKbytesRlcReferenceCell - #1555 - Number of kbytes of SDUs sent uplink for the
reference cell.
• Sub-Counter #14: PS I/B HSUPA
VS.UlAsConfIdAvgNbrEstablished - #1667 indicates an average of the number of UlAsConfIds

established per iRNC, based on time average over a collection period.
• 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 the RLC counter: DCH_UL_SDU_TRAFFIC)

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

VS.eDCHactiveUsers - #10905 - Number of active users for a cell collected every 2 ms (it corresponds
to users who have been received a grant and who are currently transmitting an E-DPDCH part).
User type:
• 2 ms
• 10 ms
VS.UlAsConfIdAvgNbrEstablished - #1667 - Average of the number of UlAsConfIds (UL calls)

established per iRNC, based on time average over a collection period (100 ms).
• 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 8 kbps
• Sub-Counter #15: PS Str HSUPA

VS.eDCHactiveUsers - #10905
Number of active users for a cell collected every 2 ms (it corresponds to users who have been received a
grant and who are currently transmitting an E-DPDCH part).
User type:
2 ms
10 ms

Sub-Counter #16: PS I/B or PS Str HSUPA
VS.DedicatedUplinkKbytesRlcActiveCells - #1553
Number of kbytes of SDUs sent uplink for each cell of the active set.
Sub-Counter #14: PS I/B HSUPA
Sub-Counter #15: PS Str HSUPA
VS.eDCHNumberUsersWithGrant - #10914
The number of E-DCH users in a cell who have been received a grant. Counted only for the serving cell.
This is a LOAD counter.

VS.UserTP.EDCH - #2502
Distribution of the user perceived throughput for interactive/background traffic in a UMTS cell when using E-DCH traffic
channels in CELL_DCH. The data rate threshold of the screenings can be defined by the CM attribute
PmUserTpConfig.edchThd pegged against the reference cell. For the calculation, the RNC accumulates the RLC payload
data which has been acknowledged by the UE while the UE has been in CELL_DCH state using an R99 E-DCH DCH and
the duration of the data transfer. This counter is pegged when:
1) a UE with an I/B RAB mapped to E-DCH is leaving the CELL_DCH state.
2) the UE with an I/B RAB mapped to E-DCH is reconfigured to another frequency layer.
3) there is a reconfiguration of the E-DCH transport channel from E-DCH to R99 DCH.
4) the RNC triggers:
an intra-RNC interfrequency handover, or
an inter-RAT handover, or
a cell change order procedure for a UE which has an I/B RAB mapped to E-DCH.
Data Rate Range E-DCH

Sub-Counter #0: rate <= edchThd[0]
Sub-Counter #1: edchThd[0] < rate <= edchThd[1]
...
Sub-Counter #19: edchThd[18] < rate

Document History

# HS-SCCH High-Speed Shared Control Channel
3G Third Generation HSUPA High-Speed Uplink Packet Access
A
AAL2 ATM Adaptation Layer 2 I
ARP Address Resolution Protocol IE Information Element
ATM Asynchronous Transfer Mode IP Internet Protocol
IR Incremental Redundancy
B
BLER Block Error Ratio K
BTS Base Transceiver Station KPI Key Performance Indicator
C L
CAC Connection Admission Control LCG Local Cell group
CC Chase Combining
CEM Channel Element Module M
CN Core Network MAC Medium Access Control
CQI Channel Quality Indicator
CS Circuit Switching O
CTCH Common Traffic Channel OA&M Operation, Administration and
Maintenance
D OCNS Orthogonal Channel Noise Simulator
DCH Dedicated Channel OVSF Orthogonal Variable Spreading Factor
DL Downlink
DPCH Dedicated Physical Channel P
DTX Discontinuous Transmission PDU Packet Data Unit
PS Packet Switching
E
EBR Enhanced Bit Rate R
E-AGCH Enhanced Access Granted Channel RAB Radio Access Bearer
E-DCH Enhanced DCH RANAP Radio Access Application Part
E-DPCCH Enhanced Dedicated Physical Control RAT Radio Access Technology
Channel RB Radio Bearer
E-DPDCH Enhanced Dedicated Physical Data RF Radio Frequency
Channel RLC Radio Link Control
E-HICH Enhanced HARQ Indicator Channel RNC Radio Network Controller
E-RGCH Enhanced Relative Grant Channel RoT Rise over Thermal
E-RNTI Enhanced Radio Network Temporary RRC Radio Resource Control
Identity RRM Radio Resource Management
E-TFCI Enhanced Transport Format Combination RSSI Received Signal Strength Indication
Indication for E-DCH RTWP Received Total Wideband Power
RV Redundancy Version
F Rx Reception
FDD Frequency Division Duplex
FR Full Rate S
SDU Signaling Data Unit
G SIR Signal-to-Interference Ratio
GBR Guaranteed Bit Rate SRB Signaling Radio Bearer
STSR Sector Transmit Sector Receive
H
HARQ Hybrid Automatic Request T
HSDPA High-Speed Downlink Packet Access TC Traffic Class
HS-DPCCH High-Speed Dedicated Physical Control TTI Transmission Timing Interval
Channel TX Transmission
HS-PDSCH High-Speed Physical Downlink Shared
Channel

U
UE User Equipment
UL Uplink
UMTS Universal Mobile Telecommunications
System
UTRAN Universal Terrestrial Radio Access
Network

All Rights Reserved © Alcatel-Lucent @@YEAR
@@COURSENAME - Page 1
All rights reserved © Alcatel-Lucent
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

Tmo18269 v2.0 Hspa Qos SG Ua08 Ed1 Ce PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Tmo18269 v2.0 Hspa Qos SG Ua08 Ed1 Ce PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Passing on and copying of this document, use and communication of its

contents not permitted without written authorization from Alcatel-Lucent

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

PERMISSION TO USE CONTENT

COPYRIGHTS AND TRADEMARKS

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

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

identify why, when and how to do performance management

This course is updated with the introduction of the UA08 features

Your feedback is appreciated!

Please include the following training reference in your email:

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Edition Date Author Remarks

01 YYYY-MM-DD Last name, first name First edition

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

1 HSDPA performance monitoring 7

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Some new L1 functionalities are introduced compared to R4:

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

VS.RadioBearerSetupSuccess #1650: the number of successful Radio Bearer establishments. This

VS.RabEstablishmentSuccessPerGrantedRabType #1658: the number of successful RAB establishments

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

The fallback procedure is monitored through the following basic indicators:

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Therefore the number of HSDPA calls dropped corresponds to sub-counter

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

A set of sub-counters screened on: Power ratio

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

VS.HsdpaTTIsUsed - #10818: Number of TTIs containing at least one scheduled UE.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

VS.DedicatedDownlinkKbytesRlcActiveCells - #1554 - Number of kbytes of SDUs sent downlink for each

VS.DedicatedDownlinkActivityRlcRefCell - #1566 - Time that RAB is actively transmitting data in the

ErlangHsdpa_Traffic057_C_hsdpa = CumulatedNumberOfDLBearersEstablished_RB021_CR_HSDPA /36000

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.