Documente Academic
Documente Profesional
Documente Cultură
STUDENT GUIDE
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
UA07 HSxPA QoS Analysis and Traffic Load Monitoring
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.
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
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.
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 :
1 To be able to XXX
2
11 All Rights Reserved © Alcatel-Lucent 2010
9300 W-CDMA
UA07 HSxPA QoS Analysis and Traffic Load Monitoring
Other comments
1 HSDPA Performance
Monitoring
Module 1
3JK11652AAAAWBZZA Edition 3.0
9300 W-CDMA
UA07 HSxPA QoS Analysis and Traffic Load Monitoring
TMO18269 D0 SG DEN Edition 1.0
Document History
Page
Switch to notes view!
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
HSDPA Performance Monitoring
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
Page
Switch to notes view!
RNC
Iub
HS-DPCCH
DPCH Feedback Information
Upper Layer Signaling (CQI, ACK/NACK)
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
18 All Rights Reserved © Alcatel-Lucent 2010
HSDPA Performance Monitoring
9300 W-CDMA UA07 HSxPA QoS Analysis and Traffic Load Monitoring
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).
Network
Mobility
Network Network
Accessibility Retainability
HSDPA KPIs
Network
Network Quality
Traffic
Capacity
1 10 All Rights Reserved © Alcatel-Lucent 2010
HSDPA Performance Monitoring
9300 W-CDMA UA07 HSxPA QoS Analysis and Traffic Load Monitoring
HSDPA is a key technology for operators and then is a key interest for
monitoring
PS Performance
E.g: Throughput
BLER
Common id
Security mode complete
Security mode complete
RAB assignment req.
established
S.R.L.R. Procedure
RAB
Service = PS? NO
YES
TrafficClass=Str/I/B? NO
YES
HSDPA UE? NO
YES
YES
HSDPA CAC
1 14 All Rights Reserved © Alcatel-Lucent 2010
HSDPA Performance Monitoring
9300 W-CDMA UA07 HSxPA QoS Analysis and Traffic Load Monitoring
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).
HSDPA RB
#958[all]
to be established
HSDPA CAC 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).
All Rights Reserved © Alcatel-Lucent 2010
3JK11652AAAAWBZZA Edition 3.0
Section 1 Pager 15
2 HSDPA Accessibility Monitoring
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
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
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.
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
RAB
RABAssignment
AssignmentSuccess
Success
per
per Granted RABtype
Granted RAB type = #1658.[4-9]
PS calls
PS calls
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:
• Sub-Counter #15: HSDPA/R99
• Sub-Counter #16: PS I/B or PS Str HSDPA/E-DCH
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
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
rrcReestPSMaxAllowedTimer
expiry
Iu Release Request
#599[6] Iu release request PS “radio connection with UE
lost”
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
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 #1: Signalling Only
• 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
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
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 #2: PS Streaming < 64
• Sub-Counter #3: PS Streaming 64
• Sub-Counter #4: PS Streaming 128
• Sub-Counter #5: PS Streaming 256
• Sub-Counter #6: PS Streaming 384
• Sub-Counter #7: TRB on cell FACH
• Sub-Counter #8: PS I/B < 64
• Sub-Counter #9: PS I/B 64
• Sub-Counter #10: PS I/B 128
• Sub-Counter #11: PS I/B 256
• Sub-Counter #12: PS I/B 384
• Sub-Counter #13: HSDPA
• Sub-Counter #14: xPCH
• Sub-Counter #15: Any CS
#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
1 26 All Rights Reserved © Alcatel-Lucent 2010
HSDPA Performance Monitoring
9300 W-CDMA UA07 HSxPA QoS Analysis and Traffic Load Monitoring
VS.IuAbnormalReleaseRequestPs - #589
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
RNC
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.
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)
RNC
R99/HSDPA
R99 cell
cell
PMaxCell
HS-DSCH #10801
Pavail for Hsdpa
HS-SCCH
#10803
DCH margin Poper #10205.[0]
Pused #10205.[1]
NodeB
E-DCH
DCH
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.
Percentage of #10205.[1].Avg
=
Average Power in Use #10205.[0].Avg
Percentage of #10205.[1].Max
=
Maximum Power in Use #10205.[0].Max
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
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
• Sub-Counter #0 : 0 to 40 pc
• Sub-Counter #1 : 40 to 70 pc
• Sub-Counter #2 : 70 to 80 pc
• Sub-Counter #3 : 80 to 90 pc
• Sub-Counter #4 : 90 to 100 pc
CEM metric
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.
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 #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.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
VS.UserTP.HSDPA
Screenings
The data rate threshold of the screenings can be defined by
the CM attribute PmUserTpConfig.hsdpaThd.
#10805
HSDPA 16QAM Usage =
#10804.[Cum]
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
• Sub-Counter #1: UE Category 2
• Sub-Counter #2: UE Category 3
•…
• Sub-Counter #8: UE Category 17
• Sub-Counter #9: UE Category 18
• Sub-Counter #10: UE Category 19
• Sub-Counter #11: UE Category 20
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
• Sub-Counter #1 : UE Category 2
• Sub-Counter #2 : UE Category 3
•…
• Sub-Counter #8 : UE Category 9
• Sub-Counter #9 : UE Category 10
• Sub-Counter #10 : UE Category 11
• Sub-Counter #11 : UE Category 12
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.
VS.HsdpaTxDataBitPerUEcat
UHSDPA075_CR_Cat13/14/17/18
HsdpaThroughputPerUeCat_HSDPA075_CR_Cat13
HsdpaThroughputPerUeCat_HSDPA075_CR_Cat14
HSDPA throughput
HsdpaThroughputPerUeCat_HSDPA075_CR_Cat17 = per ue category
HsdpaThroughputPerUeCat_HSDPA075_CR_Cat18
1 48 All Rights Reserved © Alcatel-Lucent 2010
HSDPA Performance Monitoring
9300 W-CDMA UA07 HSxPA QoS Analysis and Traffic Load Monitoring
1ST TRANSMITION,
NO RETRANSMTION
INCLUDED
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
Data
ta
Da
CQI + NACK
CK CQ
I +A I +D
CQ TX
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)
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
... ... ... ...
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.
HS-DSCH
Increase number of
users in Streaming !
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
VS.HsdpaMACdPDUAckBits - #10806
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 (1s) that either fulfil their
GBR or that are in starvation (cause external to NodeB).
• Sub-Counter #0: For SPI 0
• Sub-Counter #1: For SPI 1
• Sub-Counter #2: For SPI 2
• Sub-Counter #3: For SPI 3
• ...
• Sub-Counter #13: For SPI 13
• Sub-Counter #14: For SPI 14
• Sub-Counter #15: For SPI 15
• Sub-Counter #16: Number of Sampling periods
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.
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.
If GBR is enabled,
check if Mac-hs GBR is fulfilled (radio congestion)
#10831 #10832
HsdpaFullCode HsdpaGbr
UsageByGbr PowerUsage
#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.
#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)
VS.HsdpaMACdPDUAckBits - #10806
Total number of successfully transmitted MAC-d PDU bits (an ACK has been received for the
corresponding transport block).
VS.HsdpaHSPDSCHCodesPerTTI - #10802
Number of HS-PDSCH codes used per TTI.
VS.RadioBearerEstablishmentUnsuccess - #1629
Number of radio bearer setup not successfully established, with no RADIO BEARER SETUP REQUEST sent.
2 HSUPA Performance
Monitoring
Module 1
3JK11653AAAAWBZZA Edition 3.0
9300 W-CDMA
UA07 HSxPA QoS Analysis and Traffic Load Monitoring
TMO18269 D0 SG DEN Edition 1.0
Document History
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
Page
Switch to notes view!
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
9300 W-CDMA UA07 HSxPA QoS Analysis and Traffic Load Monitoring
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
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.
HSUPA/HSDPA RB
to be established #1603[1]
HSDPA fallback unsuccess
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.
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
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:
• Sub-Counter #16: PS I/B or PS Str HSDPA/E-DCH
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
NBAP or
RNSAP Rab assignment Core
failure Network
Proportion of #1601.[1,2]
=
E-DCH Fallback #1650.[16] + #1601.[1,2]+ #1603.[1]
2 12 All Rights Reserved © Alcatel-Lucent 2010
HSUPA Performance Monitoring
9300 W-CDMA UA07 HSxPA QoS Analysis and Traffic Load Monitoring
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.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
UE Node B RNC CN
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.
Sub-Counter #16: PS I/B or PS Str HSDPA/E-DCH
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
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
UE Node B RNC CN
HSUPA call
Iu Release Request
(abnormal cause)
Iu Release Command
#590.[2]
VS.IuAbnRelReqPsPerULRb
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
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
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
E-DCH Cell to
[2] UHSUPA001_CR_ItaFeDCHneDCH
non-E-DCH Cell
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)
• Sub-Counter #6: E-DCH Call (TTI=10ms) to E-DCH Call (TTI=2ms) (intra frequency mobility)
• Sub-Counter #7: E-DCH Call (TTI=2ms) to E-DCH Call (TTI=2ms) (intra frequency mobility)
• Sub-Counter #8: E-DCH Call (TTI=2ms) to E-DCH Call (TTI=10ms) (intra frequency mobility)
VS.EdchUnsucMobility - #969
Number of unsuccessful E-DCH mobility.
Same screenings as for #968.
Global HSUPA
success rate #968.[2,5]
from E-DCH cell =
to Non E-DCH cell #968.[2,5] + # 969.[2,5]
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)
• Sub-Counter #6: E-DCH Call (TTI=10ms) to E-DCH Call (TTI=2ms) (intra frequency mobility)
• Sub-Counter #7: E-DCH Call (TTI=2ms) to E-DCH Call (TTI=2ms) (intra frequency mobility)
• Sub-Counter #8: E-DCH Call (TTI=2ms) to E-DCH Call (TTI=10ms) (intra frequency mobility)
VS.EdchUnsucMobility - #969
Number of unsuccessful E-DCH mobility.
Same screenings as for #968.
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)
• Sub-Counter #6: E-DCH Call (TTI=10ms) to E-DCH Call (TTI=2ms) (intra frequency mobility)
• Sub-Counter #7: E-DCH Call (TTI=2ms) to E-DCH Call (TTI=2ms) (intra frequency mobility)
• Sub-Counter #8: E-DCH Call (TTI=2ms) to E-DCH Call (TTI=10ms) (intra frequency mobility)
VS.EdchUnsucMobility - #969
Number of unsuccessful E-DCH mobility.
Same screenings as for #968.
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
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
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
VS.CellULload - #10211
The mean UL Load value.
• Total load
• eDCH/HSUPA load
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
VS.eDCHstatus - #10907
The LOAD EXCESS status of the HSUPA cell
BTSCell metric
BTSCell metric
VS.CellULload - #10211
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.
BTSCell metric
BTSCell metric
VS.CellULload - #10211
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.
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
#10903.Cum
HSUPA HARQ BLER =
#10903.NbEvt + #10903.Cum
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
VS.RadioWBandRxMainPwr
#10201 VS.RadioWBandRxDivPwr
#10202
RTWPmeas
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.
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 #8: VS.SIRperSF.SF8.Min
• Sub-Counter #9: VS.SIRperSF.SF8.NbEvt
• Sub-Counter #10: VS.SIRperSF.SF16.Avg
• Sub-Counter #11: VS.SIRperSF.SF16.Cum…….
……..
• Sub-Counter #33: VS.SIRperSF.SF256.Min
• Sub-Counter #34: VS.SIRperSF.SF256.NbEvt
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)
#10905.[2ms].Cum + #10905.[10ms].Cum
HSUPA Activity Factor =
50 x #1667.[16].Cum
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
• Sub-Counter #9: PS I/B 16kbps
• Sub-Counter #10: PS I/B 32kbps
• Sub-Counter #11: PS I/B 64kbps
• Sub-Counter #12: PS I/B 128kbps
• Sub-Counter #13: PS I/B 384kbps
• Sub-Counter #14: PS I/B HSUPA
EdchNumberUsersWithGrant
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
VS.UserTP.EDCH
Screenings