HSDPA Performance Management - Page 1All Rights Reserved © 2007, Alcatel-Lucent
All rights reserved © 2007, Alcatel-Lucent
Alcatel-Lucent W-CDMA - HSDPA Performance Management
Alcatel-Lucent W-CDMAHSDPA Performance
Management
TRAINING MANUAL
3FL12855AAAAWBZZAEdition 2
Copyright © 2007 by Alcatel-Lucent - All rights reservedPassing on and copying of this document, use and
communication of its contents not permitted without written authorization from Alcatel-Lucent
HSDPA Performance Management - Page 2All Rights Reserved © 2007, Alcatel-Lucent
All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA
HSDPA Performance Management
2
Legal Notice
� Switch to notes view!Safety Warning
Both lethal and dangerous voltages are present within the equipment. Do not wear conductive jewelry
while working on the equipment. Always observe all safety precautions and do not work on the
equipment alone.
Caution
The equipment used during this course is electrostatic sensitive. Please observe correct anti-static
precautions.
Trade Marks
Alcatel and MainStreet are trademarks of Alcatel.
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
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.
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 Canadian or other
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 written consent of Alcatel-Lucent.
Alcatel-Lucent, The Alcatel-Lucent logo, MainStreet and Newbridge are registered trademarks of Alcatel-
Lucent. All other trademarks are the property of their respective owners. Alcatel-Lucent assumes no
responsibility for the accuracy of the information presented, which is subject to change without notice.
© 2007 Alcatel-Lucent. All rights reserved.
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 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.
Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-
Lucent equipment and its operation.
HSDPA Performance Management - Page 3All Rights Reserved © 2007, Alcatel-Lucent
All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA
HSDPA Performance Management
3
Table of Contents
� Switch to notes view! Page
Section 1: Introduction
Section 2: Performance Management: Definitions and MethodologySummary 7Counters 8Counters: Definition 9Types of Counters and Period of Time 10Counter Specification: Collection Method 11Exercise 12Counter Locations: FddCell & RNC Counters 13Counter Locations: Reference FddCell Counters 14Counter Locations: Neighboring RNC Counters 15Counter Screening 16Counter Example: Number of RRC Connection Requests 17
Metrics 18Metrics: Definition 19Metric Format 20Example: RRC Connection Success 21Example: RRC Connection Success 22Page with Lines for “Student Notes” 23
Reports 24Report Definition 25Process 26Performance Management Process 27Page with Lines for “Student Notes” 28
Section 3: HSDPA KPIsRadio Resource Allocation 7HSDPA Channel Operation 8HSDPA Channel Configuration 9OVSF Code Tree Reservation 10NodeB Role 11Interface Configuration 12ATM VCC numbering 13UE Categories 14UE Capabilities and Max Bit Rates 15Activation Flags 16Main Parameters 17Accessibility Flow Diagrams 19Principles 20HSDPA CAC success rate 21RAB Assignment Flow 22RAB Assignment Success Rate 23HSDPA Case 24RB Set-up success rate 25Traffic Segmentation 26Procedure description 27Parameters 28Accessibility 29Network Retainability Performance 31Total number of RABs 32Abnormal Release Caused by RL Failure 33Call Abnormal Release 34Call Drop Rate at RNC Level 35Call Drop Rate per RAB established 37Call drop rate per released calls - cell level 38Number of drops per minute of RAB 39Average Number of calls 41Uplink/ Downlink PS Traffic 42
HSDPA Performance Management - Page 4All Rights Reserved © 2007, Alcatel-Lucent
All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA
HSDPA Performance Management
4
Table of Contents [cont.]
� Switch to notes view!
Page
Section 3: HSDPA KPIs [con’t]
Throughput DL per Combined DL/UL max bit rate at RNC level 43HSDPA DL Kbytes ( SDU payload) 44First Stage Principles 46Second Stage Principles 47SPI Configuration 48Traffic 49CQI Reporting Principles 52CQI Modification Principles 53DL HSDPA radio traffic 54MAC-HS throughput and Cell throughput 55Mac-d Throughput per cell 56HSDPA Power Management Principles 58First Tx Power Allocation Principles 59Retransmission Principles 60HSDPA Retransmission rate 61
HSDPA Performance Management - Page 5All Rights Reserved © 2007, Alcatel-Lucent
All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA
HSDPA Performance Management
5
Course Objectives
� Switch to notes view!
Welcome to HSDPA Performance Management
After successful completion of this course, you should understand :
� Define the counters, the metrics and explain how to use the metrics
� Describe HSDPA main metrics:
• Describe HSDPA Power Control Metrics
• Explain Always On KPIs for HSDPA
• Understand the main HSDPA accessibility, Traffic and mobility metrics.
HSDPA Performance Management - Page 6All Rights Reserved © 2007, Alcatel-Lucent
All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA
HSDPA Performance Management
6
Course Objectives [cont.]
� Switch to notes view!
This page is left blank intentionally
HSDPA Performance Management - Page 7All Rights Reserved © 2007, Alcatel-Lucent
All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA
HSDPA Performance Management
7
About this Student Guide
� Switch to notes view!Conventions used in this guide
Where you can get further information
If you want further information you can refer to the following:
� Technical Practices for the specific product
� Technical support page on the Alcatel website: http://www.alcatel-lucent.com
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.
WarningAlerts you to instances where non-compliance could result in equipment
damage or personal injury.
HSDPA Performance Management - Page 8All Rights Reserved © 2007, Alcatel-Lucent
All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA
HSDPA Performance Management
8
About this Student Guide [cont.]
� Switch to notes view!
This page is left blank intentionally
HSDPA Performance Management - Page 9All Rights Reserved © 2007, Alcatel-Lucent
All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA
HSDPA Performance Management
9
Self-Assessment of Objectives
� At the end of each section you will be asked to fill this questionnaire
� Please, return this sheet to the trainer at the end of the training
�
Switch to notes view!
Instructional objectives Yes (or globally yes)
No (or globally no)
Comments
1 To be able to define the counters, the
metrics and explain how to use the metrics
2 To be able to describe HSDPA main metrics:
•Describe HSDPA Power Control Metrics •Explain Always On KPIs for HSDPA •Understand the main HSDPA accessibility, Traffic and mobility metrics.
Contract number :
Course title :
Client (Company, Center) :
Language : Dates from : to :
Number of trainees : Location :
Surname, First name :
Did you meet the following objectives ?
Tick the corresponding box
Please, return this sheet to the trainer at the end of the training
����
HSDPA Performance Management - Page 10All Rights Reserved © 2007, Alcatel-Lucent
All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA
HSDPA Performance Management
10
Self-Assessment of Objectives [cont.]
� Switch to notes view!
Thank you for your answers to this questionnaire
Other comments
����
2-1
HSDPA Performance Management3FL12855AAAAWBZZA Ed 2 September, 2006
Performance Management: Definitions and Methodology
Section 2
2-2
September, 20062-2HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Objectives
After this course, you will be able to
> Define the counters• Define counters• Describe the counter format• Define subcounters and screening
• Relate subcounters to RAB, RRC, and interfaces
> Define the metrics• Define the metrics• Describe the metric format
• Define the metrics families
> Explain how to use the metrics• List Alcatel-Lucent reports• Describe a performance management process
2-3
September, 20062-3HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Content
Counters> Counters: Definition> Types of Counters and Period of Time> Counter Specification: Collection Method> Counter Locations: FddCell & RNC Counters> Counter Locations: Reference FddCell Counters> Counter Locations: Neighboring RNC Counters> Counter Families> Counter Screening> Counter Example: Number of RRC Connection RequestsMetrics> Metrics: Definition> Metric Format> Example: RRC Connection SuccessReports> Report DefinitionProcess> Performance Management Process
2-4
Student notes
2-5
September, 20062-5HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Page
Summary 7Counters 8Counters: Definition 9Types of Counters and Period of Time 10Counter Specification: Collection Method 11Exercise 12Counter Locations: FddCell & RNC Counters 13Counter Locations: Reference FddCell Counters 14Counter Locations: Neighboring RNC Counters 15Counter Screening 16Counter Example: Number of RRC Connection Requests 17Metrics 18Metrics: Definition 19Metric Format 20Example: RRC Connection Success 21Example: RRC Connection Success 22Page with Lines for “Student Notes” 23Reports 24Report Definition 25Process 26Performance Management Process 27Page with Lines for “Student Notes” 28End of Module 29
2-6
September, 20062-6HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Table of Contents [cont.]
> The subscriber evaluates the performance/quality of service of the network through 4 criteria.
4. Call Drop
3. Quality
2. Successful Call Set Up Rate
1. Extend of coverage
Criteria
> Can be assessed by the system through monitoring.
> Can be assessed by BLER (CS and PS) measurements.
> Can be assessed by air interface measurements.
> Can be approached by system monitoring.
> Can be assessed by the system through monitoring.
> Cannot be assessed by the system.
> Can be assessed by:• Air interface measurements,
• Subscriber complaints.
Possible assessment / monitoring
This page is left blank intentionally
2-7
September, 20062-7HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Summary
To measure and analyze the performance of a network one needs:
4. Call Drop
3. Voice Quality
2. Call Set Up
1. Coverage
Criteria
>Can be assessed by the system through monitoring.
>Can be assessed by air interface measurements.
>Can be approached by system monitoring.
>Can be assessed by voice quality analyzers.
>Can be assessed by the system through monitoring.
>Cannot be assessed by the system.
>Can be assessed by:— Air interface measurements,— Subscriber complaints.
Possible assessment / monitoring
���!
1. Data collection:1. Counters2. Metrics:> {counter1, counter2, …}
> f(counter1, counter2, …)
> …
3. Measurements
4. Reports
2. Process and methodology
3. … And experience!
2-8
HSDPA Performance Management3FL12855AAAAWBZZA Ed 2 September, 2006
Counters
2-9
September, 20062-9HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Counters: Definition
• Counters measure a number of specific events (occurring in an entity of the UTRAN), during a period.
• These counter values are stored in the performance server.
The wording “counter and “measurement” are often equally used in the documentation for identifying the same concept.
Usually, Alcatel-Lucent prefers to use the term “counter” to distinguish a counter from a “(radio) measurement”. A counter is periodically elaborated on periods expressed in minutes or hours, e.g. 30 min, while a measurement is elaborated on periods expressed in milliseconds, e.g. 500 ms.
3GPP Performance Management specifications preferably considers “measurements”. When the context refers to 3GPP specifications “measurement” is used, while “counter” is used is more Alcatel-Lucent specific part, but both wordings are equivalent.
Periods of counter
It is the duration of the events counting in the selected entity of the network. It can be modified. The QoS monitoring daily and hourly periods are used.
• Busy hour corresponds to the hour of the day when the traffic is the highest. It allows to analyze performances of the cells, when the traffic is higher. It is really important for congestion/capacity analysis and also forecasting.
• Daily period gives global information on the day. To compare busy hour and daily data, is necessary to check the influence of the traffic.
• Weekly period
• Monthly period
• RNC counters are uploaded every 15 min.
• BTS counters are uploaded every hour (minimum).
2-10
September, 20062-10HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Types of Counters and Period of Time
X2X1 X3 X4 X5 Xi Xn
Granularity Period
Initiation
Avg
Min
Max
NbEvt
Cumul
The default granularity period are 60 minutes for BTS and 15 min for RNC. They are configurable. The following rules shall be followed for temporal aggregation.
Rtotal applies to CC counters
X.cum = X1.cum + X2.cum + …+ Xn.cum
Rload / Rval applies to some LOAD and VAL counters
X.cum = X1.cum + … + Xn.cum
X.nbevt = X1.nbevt + … + Xn.nbevt
X.avg = (X1.cum + .. + Xn.cum) / (X1.nbevt + .. +X2.nbevt)
X.min = min (X1.min, .., Xn.min)X.max = max (X1.max, .., Xn.max)
Rload applies to some LOAD counters
Same result as previous Rload but resulting X.cum has no “physical” meaning due to the nature of the measurement (like percents..) and shall not be interpreted but is necessary for intermediate computations.
2-11
September, 20062-11HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Counter Specification: Collection Method
Counter type
Cumulative
Value
Load
Collection method
CC
GAUGE
DER
SI
Collection Method
•CC (Cumulative Counter);
•GAUGE (dynamic variable), used when data being measured can vary up or down during the period of measurement;
•DER (Discrete Event Registration), when data related to a particular event are captured every nth event is registered, where n can be 1 or larger;
•SI (Status Inspection).
2-12
September, 20062-12HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Exercise
#660 indicates an average of the number of “RABs*” established per RNC, based on time average over collection period.
It is load counter i.e is incremented by a value sampled on the sampling event occurrence (100ms) and gives 5 information:
• Cumulated value• Number of events• Minimum value• Maximum value• Averaged value = Cumulated value / Number of events
Based on this counter propose a “formula” to calculate the Time of RAB allocation
* number of DlAsConfIds established per RNC
Time of RAB allocation =
2-13
September, 20062-13HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Counter Locations: FddCell & RNC Counters
> FddCell counter• A “FddCell” counter is incremented for each FddCell of the serving RNC on
which the mobile is connected to when the event occurs (ex.: RL counters).
> RNC counter• A “RNC” counter is incremented when an event occurs on the serving RNC of
a connection (ex: Iu connection counters, traffic counters).
ServingRNC
DriftRNC
Iur
IuCore
2-14
September, 20062-14HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Counter Locations: Reference FddCellCounters
> Reference FddCell counter• A “Reference FddCell” counter is incremented only for the FddCell identified
as the reference FddCell of the connection when the event occurs (ex: Radio Bearer counters).
• Such a counter is only incremented if the reference FddCell belongs to the serving RNC on the connection.
• (Reference FddCell: FddCell with the best Ec/No).
ServingRNC
DriftRNC
Iur
IuCore
2-15
September, 20062-15HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Counter Locations: Neighboring RNC Counters
> Neighboring RNC counter• A “Neighboring RNC” counter is incremented for events:
• occurred on a neighboring RNC (ex: Iur connection counters),• related to FddCells that belong to the neighboring RNC (ex: RB setup
counters).
ServingRNC
DriftRNC
Iur
IuCore
2-16
September, 20062-16HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Counter Screening
> Screening refers to subcounters.> Screening are given in the counter definition. See example on the following page.
> The most common screenings are the following:• DlRbConf: Downlink (DL) Radio bearer (RB) set configurations (conf) made of RB
types:• Conversation, interactive/background, or streaming
• UlAsConf and DlAsConf: Uplink (UL) and DL Access Stratum (AS) configurations (conf). Can be filtered per:
• Containing CS, PS, or speech• Pure CS, PS, or SRB• Multi-service (PS+CS)
• RabConf Radio Access Bearer (RAB) configurations (conf) made of RAB type:• Traffic class• UL and DL bitrate
• RRC connection establishment causes includes:• Originating and terminating calls (conversational, streaming, interactive, background)• Emergency call• Registration• Detach• Originating and terminating signaling• Call re-establishment
> Some counters have their own and specific screenings.
See appendix of this course and the counter document referenced for detailed information.
2-17
September, 20062-17HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Counter Example: Number of RRC Connection RequestsA. This measurement provides the number of RRC connection requests screened by
establishment cause.
B. CC
C. Reception by the RNC of a RRC CONNECTION REQUEST message.
D. An integer value for each establishment cause.Screening: Sub-counter # i --> Establishment cause # i as in TS 25.331 (c.f. Annex)
E. RRC.AttConnEstab.<0..31>
F. FDDCell
G. Valid for circuit switched and packet switched traffic.
H. 3GPP specified counterAlcatel-Lucent #0409Counter introduced in V 2.0e
I. Message flowUE UTRAN
RRC Connection Establishment, network accepts RRC connection
RRC connection request
RRC connection setup
RRC connection setup complete
When vendor specific, the ‘VS’ prefix is addede.g. VS.RadioLinkSetupSuccess
The counters are specified according the “Measurement definition template” defined in the 3GPP specification.
C.x.y. Measurement Name (section header): descriptive name of the measurement type.A. Description contains an explanation of the measurement operation.B. Collection Method contains the form in which this measurement data is obtained.C. Condition contains the condition which causes the measurement result data to be updated. It is
defined by identifying protocol related trigger events for starting and stopping measurement processes, or updating the current measurement result value. Where no precise condition is available the conditional circumstances leading to the update are stated.
D. Measurement Result (measured value(s), Units) contains a description of expected result value(s).
E. Measurement Type contains a short form of the measurement name specified in the header, which is used to identify the measurement type in the result files (XML) on the Inteface-N. When vendor specific (VS) a counter starts with “VS.”, e.g. VS.RadioLink SetupSuccess.
F. Measurement Object Instance: the “measObjInstId” field identifies the measured object class and its instance, e.g. trunk1 means object class is trunk and instance #1 is being measured. The object class and instance values used for this purpose shall be in accordance with 3GPP TS 32.106 [3], i.e. the NE/resource object model (defined in the Basic CM IRP Information Model -3GPP TS 32.106-5) and naming conventions (defined in the Name Convention for Managed Objects - 3GPP TS 32.106-8). This parameter, if applicable, shall be provided in the measurement job.
G. Switching Technology contains the Switching domain(s) this measurement is applicable to (CS or PS).
H. 3GPP compliance states on the compliance of the Alcatel-Lucent measurement with the 3GPP specification (“3GPP specified counter” or “Alcatel-Lucent specified counter”). When not fully compliant with the 3GPP, the section explains how the counter is not fully compliant and the reason why.
Are provided: Alcatel-Lucent internal number, software version (the counter introduced s/w version).I. Comments: optional section provides additional information when necessary e.g. message flows
when counters are attached to protocol messages.
2-18
HSDPA Performance Management3FL12855AAAAWBZZA Ed 2 September, 2006
Metrics
2-19
September, 20062-19HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Metrics: Definition
Metric ={counter1, counter2, …}
Metric = f (counter1, counter2, …)
Composed of one or several counters
A formula composed of one or several counters.
For instance: ∑ RRC.SuccConnEstab [RRC screenings]
• Metric definitions may include counter screening such as voice, video, or data.• Some counters screened by As Conf Id (DL or UL), or RRC establishment causes.• Other counters are provided with screening details.
To interpret data coming from the counters, it is necessary to define some metrics.
A metric is composed of one or several counters.
These counters can be screened for some specific metrics:
• Counters screened by As Conf Id (DL or UL), or RRC establishment causes.The screening is detailed in the annexes.
• Other counters with screening details.The screening value used in the metric is directly set with the counter.
Note that if no screening details are given (no brackets), all screenings of the counter must be used for the metric.
The screening is identified as followed:
• Downlink As Conf Id = DL_AsConfId_Screenings (screened by SRB, CS, PS, Combined, PS 8, PS 32, PS 64, PS 128, PS 256, PS 384, CS 14.4, CS 57.6, CS 64, Voice)
• Uplink As Conf Id = UL_AsConfId_Screenings
• RRC release = RRC_Release_Screenings (specific screening for RRC Failures)
• RRC establishment causes = RRC_Screenings (screened by Call, CS, PS, Identification)
• RAB = RAB_Screenings (screened by CS, PS)
2-20
September, 20062-20HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Metric Format
Optional: Comment or monitoring recommendation Comment
Counter: #Counter Id = Name of the counter [all possible screenings]
Associated counters
Metric formula with counter name, or metric id with specific screenings used
Metric formula
����
NetworkRNCGroup of
cellsCell
NC
ApplicabilityMetric
history
Metric NameMetric Id
Metric Id allows to identify the metric. It is expressed as Subfamily-xxx where:
• subfamily is the family of the counters composing the metrics (RRC, Iu, RL…),
• xxx is the number of the metric inside the subfamily.
Metric history can be either
• NEW, the metric has been created for the given release,
• UPDATE, the metric existed in the previous release but counters have been modified,
• NC, No change, the metric existed in the previous release and stays as it is in the current one.
Applicability: Level at which the metric can be computed.
Metric formula is expressed with counter external names.
When it is composed of the sum of all the screenings of one counter it will be expressed as the following example:
∑Counter_name [List_screenings]
Ex.: Total number of RRC attempts = ∑(VS.RRC.AttConnEstab [RRC screenings])
The list of the RRC screenings can be found in the appendix of the document.
• When the metric is composed of the sum of some screenings of one counter but not of the entire list it will be expressed as follow:
Counter_name [screening1 + screening3 + screening 8]
Ex.1: Number of RRC attempts for CS calls = VS.RRC.AttConnEstab[0 + 1 + 5 + 6 + 9]
Ex.2: Average Iu SCCP established = VS.IuAvgNbrSccpCnx [WithCoreNetworkCs.Avg+WithCoreNetworkPs.Avg]
2-21
September, 20062-21HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Example: RRC Connection Success
Necessary for the calculation of RRC Connection success rate, this metric allows also to see the call distribution in terms ofsuccess of the request.
Indeed, this metric can be computed per RRC establishment cause:• Calls: RRC call screenings• CS calls: RRC CS call screenings• PS calls: RRC PS call screenings• Registration: RRC identification screenings
Monitoring recommendation
#0403 RRC.SuccConnEstab (RRC establishment causes )Associated Counters
∑ (RRC.SuccConnEstab [RRC screenings] )Metric formula
Number of RRC connection success (sum of all causes)Meaning
����
NetworkRNCGroup of cellsCellNC
ApplicabilityMetric history
RRC connection success RRC001
The first phase of a call establishment (speech or data) is the RRC connection. One RRC connection can lead to:
• several Iu SCCP connections ( multi service CS+PS, simultaneous CS + PS attach/detach, CS location update during a PS call)
• no RAB in case of signaling connections
• 1 (or several RAB) in case of one call (multi service).
2-22
September, 20062-22HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Security mode command success
BLER PSQuality
BLER CS
Mean RB Blocking rateCongestion
DL PS Traffic per RNC
Traffic
RAB establishment success rate
UL PS Traffic per RNC
Average number of Video calls per day
Average number of Voice calls per day
3G-2G HHO CS execution failure rate (3G side)
3G-2G HHO CS execution failure rate (2G side)
3G-2G HHO CS preparation success rate
Global 3G-2G CS HHO success rate
3G-2G HHO PS execution failure rate (2G)
Voice Call Drop rate at RNC
Video Call Drop rate at RNC
Mean Sector Per User
Mobility
PS call drop rate at RNC
Retainability
SCCP connection success rate
RRC connection success rate (calls only)
UTRAN Call set up success indicator
Accessibility
RNC PanelUTRAN metric families
This report, named RNC Panel, is built using high level metrics, in order to give an overview of the performance of the network. These metrics are associated to the main phases of a call:
• RRC connections setup• IU SCCP connections setup• Radio Access Bearers establishment• Call Drops• Mobility efficiency• Congestion detection• Quality of the bearer• Traffic
This report has to be used at network level or RNC level => easy to geographically investigate an area when there is an issue.It reflect the quality of actual network.It leads to deeper investigations with additional metrics.
The Network Accessibility analysis aims at evaluating the accessibility performance results at network level and at RNC level and is based on the accessibility metrics belonging to the RNC PANEL report In case of degradation of CSSR (Call Setup Success Rate) then identify the accessibility bottlenecks by correlating with the other accessibility metrics:
• RRC Connection success rate• Iu SCCP Connection success rate• RAB Assignment success rate
2-23
Student notes
2-24
HSDPA Performance Management3FL12855AAAAWBZZA Ed 2 September, 2006
Reports
2-25
September, 20062-25HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Report Definition
> A report is a set of metrics.• Report can be from high level to a low level to help
investigate/analyze from general to specifice.g. network level report -> RNC level report -> FddCell level report
• Some reports are pre-defined, others are created/customized by the user.
> Types of reports:• Evolution report• Top N report
• Alarm detection report
> Alcatel-Lucent proposes pre-defined reports
A report consists of a set of metrics going from a high level view to a low level (from a network view to a network element view, i.e. Network -> RNC -> Fddcell):
• Set of reports at executive level.
• Detailed reports (evolution and top N reports).
• Reports based on alarm generation.
The format of the report is a graph or a table.
In order to be efficient it’s recommendable to name the reports with prefixes that indicates what level they are referring to (RNC, fddcell) followed by the report name.
Several types of reports can be used:
• Evolution report: the objective of the evolution reports is to show and compare the statistics related to a set of NEs, over a period of time.
• Top N report: the objective of top N reports is to filter the N worst (or best) NEs according to a specific criterion. Such reports are run over a set of NEs and for a single date.
• Alarm detection report: every report can be complemented with reports coming from alarm detection based on thresholds.
2-26
HSDPA Performance Management3FL12855AAAAWBZZA Ed 2 September, 2006
Process
2-27
September, 20062-27HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Performance Management ProcessData retrieving
definition
Criteriadefinition
Observation
!Analysis
Correction
Validation
Engineering
O&M
O&M
Mon
itorin
g se
tup
Mon
itorin
g pr
oces
s• Counters• Metrics• Reports
• Hourly / busy hours, daily, weekly• Alarm detection• NEs (RNCs, FddCell, …)
Tools(PrOptima, scripts…)
The basic method for monitoring is based on a detection method: a problem or a need of improvement is detected when, part of the network doesn’t fit the “required performances” e.g.:
• Performances not in accordance with the operator’s needs or expectations,
• Difference of performances with the rest of the network,
• Sudden degradation of performances.
Performances could be defined as rates of operations completion or usage of the resources.
Network monitoring process is based on:
Network observation Analysis of the problem
Correction proposal Verification
It means that the operator has to "translate" the subscriber feeling of the quality in a mathematics formula based on indicators. These indicators are obtained from:
Interfaces measurements NE counters
Subscriber complaints
And they are collected and showed out using:
Protocol analyzers Trace functions
Optimization and monitoring tools
2-28
Student notes
2-29
September, 20062-29HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
End of Module
3-1
September, 2006HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
HSDPA KPIs
Section 3
3-2
September, 20063-2HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Objectives
After this section, you will be able to
> Describe HSDPA main metrics
> Describe HSDPA Power Control Metrics
> Explain Always On KPIs for HSDPA
> Understand the main HSDPA accessibility, Traffic and mobility metrics.
3-3
September, 20063-3HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Contents> Introduction> What’s HSDPA?> Radio Resource Allocation> HSDPA Channel Operation> HSDPA Channel Configuration> OVSF Code Tree Reservation> NodeB Role > Interface Configuration> ATM VCC numbering> UE Categorieses> Activation Flags> Main Parameters> Accessibility Flow Diagrams> Principles> HSDPA CAC success rate > RAB Assignment Flow> RAB Assignment Success Rate> HSDPA Case> RB Set-up success rate> Traffic Segmentation> Multi-carrier HSDPA traffic segmentation> Accessibility> Call Drop Rate at RNC Level> Call Abnormal Release> Call Drop Rate at RNC Level
> Call Drop Rate at RNC Level> Call drop rate per released calls - cell level> Number of drops per minute of RAB> Uplink/ Downlink PS Traffic> Throughput DL per Combined DL/UL max bit rate at
RNC level> Traffic> SPI Configuration> Traffic> CQI Reporting Principles> CQI Modification Principles> HSDPA specific traffic metrics > HSDPA Power Management Principles> First Tx Power Allocation Principles> Retransmission Principles> HSDPA Retransmission rate> Iub Bandwidth Limitation> Downlink BLER PS> Uplink BLER PS> Congestion> Principles> Always – On metrics> Multiservices
3-4
Student notes
3-5
September, 20063-5HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
3-6
September, 2006HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Table of Contents [cont.]
What’s HSDPA?
Page
Iub Bandwidth Limitation 62Iub Bandwidth Limitation - Principle 63Iub Bandwidth Limitation – F. A. 64Downlink BLER PS 65Uplink BLER PS 66Uplink BLER PS 67Uplink BLER PS 68HS-SCCH Power Control Activation 69Congestion 70Congestion 71Principles 72Activation 73Always – On metrics 74Always – On metrics 75Principles 76Principles 77Principles 78Principles 79
3-7
September, 20063-7HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Radio Resource Allocation
Shared Channel
Dedicated Channel
Dedicated Channel
Dedicated Channel
UMTS R4
HSDPA
The WCDMA system normally carries user data over dedicated transport channels, or DCHs, which brings maximum system performance with continuous user data. The DCHs are code multiplexed onto one RF carrier. In the future, user applications are likely to involve the transport of large volumes of data that will be bursty in nature and require high bit rates.
HSDPA introduces a new transport channel type, High Speed Downlink Shared Channel (HS-DSCH) that makes efficient use of valuable radio frequency resources and takes into account packet data services burstiness.
This new transport channel shares multiple access codes, transmission power and use of infrastructure hardware between several users. The radio network resources can be used efficiently to serve a large number of users who are accessing bursty data. To illustrate this, when one user has sent a data packet over the network, another user gets access to the resources and so forth. In other words, several users can be time multiplexed so that during silent periods, the resources are available to other users.
3-8
September, 20063-8HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
HSDPA Channel Operation
HS-SCCHDownlink Transfer Information(UEid, OVSF,...)
HS-PDSCHData Transfer
(PS I/B)
DPCHUpper Layer Signaling
2ms
UE #1UE #2UE #3UE #4UE #5
OVSFcodes
HS-DPCCH Feedback Information
(ACK/NACK, CQI)
DPCHUpper Layer Signaling
HS-DPCCH Feedback Information(ACK/NACK, CQI)
HSDPA operation requires three new physical channels to be introduced:
• The HS-PDSCH (DL) on which is mapped the HS-DSCH. It carries only the data payload. The SF is equal to 16 and up to 15 codes can be reserved to HS-PDSCH per cell. One HS-DSCH can be mapped onto one or several HS-PDSCH (the maximum number of codes is given by UE capabilities).
• The HS-SCCH (DL) that carries the HS-PDSCH associated signaling. The SF is fixed to 128. It indicates to which UE data is intended to, on which codes and with which parameters. There are as many HS-SCCH transmitted during a TTI as scheduled user number.
• The HS-DPCCH (UL) that carries feedback information (ACK/NACK/CQI) to handle retransmissions (SF=256).
HSDPA operation also requires to use already existing R4 physical channels:
• The DPCH (UL/DL) is needed to carry the higher layers signaling. Dedicated physical channel is also required in UL to carry the corresponding user data (PS I/B) as HS-PDSCH is DL only.
3-9
September, 20063-9HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
HSDPA Channel Configuration
Layer 1
HS-SCCH HS-DPCCH
TransportChannels
LogicalChannels
PhysicalChannels
DCCH
DCH
DPCH
DTCH
HS-DSCH
HS-PDSCH
DTCH
DCH
DPCCH
DCCH
DCH
DPDCH
From a Radio Bearer perspective, a HSDPA data session implies:
• A HS-DSCH transport channel supported by a variable number of HS-PDSCH SF16 physical channels. The HS-DSCH transport channel is used to transport the downlink data packets between UE and UTRAN, i.e. packets associated to the DTCH logical channel
• An associated DCH. This dedicated transport channel is used to transport the signalling messages, including the signalling exchanged at the RRC level and the signalling exchanged between the UE and the Core Network (e.g. all SM and GMM layer messages). The associated DCH also transports the packet data in the uplink direction.
HS-SCCH and HS-DPCCH physical channels only exist for the Layer 1 of the radio interface. They have the following purpose:
• HS-SCCH (SF128) is used for UE addressing (i.e. indicating a specific UE that data packets are being sent on the HS-PDSCH), and provides the UE with necessary information to decode the data packets (UE id, modulation scheme, HS-PDSCH code set, redundancy version attributes). There are as many HS-SCCH transmitted during a TTI as scheduled user number.
• The HS-DPCCH (SF256) is used to carry UE feedback information used for link adaptation (CQI) and HARQ process (ACK/NACK).
3-10
September, 20063-10HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
OVSF Code Tree Reservation
SF4
SF8
SF16
SF32
SF64
SF128
SF256
cmCH
. . .
HS-PDSCH
HS-SCCH
. . .
. . .
. . .
SF4
SF8
SF16
SF32
SF64
SF128
HS-PDSCH
HS-SCCH
HSDPA + R4HSDPA + R4
HSDPAHSDPA
The configuration of the OVSF code tree can provide up to 15 SF16 codes allocated to HS-PDSCH and up to 4 SF128 codes for HS-SCCH.
All the R4 common channels (CPICH, P-CCPCH, S-CCPCH) are allocated in the top of the tree and take the equivalent of a SF32 code. All remaining OVSF codes can be used for non-HSDPA services (speech, multi-RABs...)
In Alcatel-Lucent implementation, the HS-PDSCH SF16 codes are allocated and reserved by the RNC at the bottom of the tree. Immediately above, the HS-SCCH SF128 codes are allocated. These codes are allocated at cell setup and cannot be used or preempted for other services.
All the remaining codes are therefore contiguous and left for further DCH allocations. This includes associated DCH as well as any other calls mapped on DCH (e.g. speech calls, streaming, etc).
Note that the maximum configuration (15 HS-PDSCH codes and 4 HS-SCCH codes) leaves no room in the OVSF tree for DCH (due to common channels occupancy) so it is not even possible to allocate associated SRB for HSDPA calls.
3-11
September, 20063-11HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
NodeB Role
SchedulerFills the TTIs with one or more users based on their
priority and feedback information
HARQ ProcessesRetransmissions handling, TFRC selection, AMC…
Queue IDs
Radio TransmissionFeedback Reception
Capacity Request
Control FP
Capacity AllocationControl FP
Data FP
Flow ControlDynamically fills the Queues of each
UE
RNC
The main architectural shift with respect to R4 is the introduction of an ARQ scheme for error recovery at the physical layer (which exists independently of the ARQ scheme at the RLC layer). This fast retransmission scheme is of paramount importance for TCP as generally TCP has not performed well in a wireless environment.
This architectural evolution gives a new importance to the role of the NodeB in the UTRAN. It then necessarily goes together with the introduction of some new functions managed by the NodeB among which:
- Flow Control: new control frames are exchanged in the user plane between NodeB and RNC to manage the data frames sent by the RNC,
- Scheduler: it determines for each TTI which users are going to be served and how many data bits they are going to receive,
- Hybrid Automatic Repeat Query: retransmissions management,
- Adaptive Modulation and Coding: new channel coding stages and radio modulations schemes are introduced to provide data throughput flexibility,
- Feedback demodulation and decoding in UL..
3-12
September, 20063-12HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Interface Configuration
AAL2
� DS� NDS� HSDPA
PCM
ATM
AAL5
� OAM� CP� CCP
INVccGroup
VCC OAM
VCC DS traffic
VCC NodeBCP
VCC CCP
VCC NDS traffic
VPi/VCi
VPi/VCi
VPi/VCi
VPi/VCi/PathId/QoSId
VPi/VCi/PathId/QoSId
RNC
VCC HSDPA traffic VPi/VCi/PathId/QoSId
• New VCC• New ATM Profile• New QoSId
PCM link (1 up to 8 with IMA)
As HSDPA is a system evolution limited to UTRAN, HSDPA activation have no impact beyond the RNC.
As HSDPA is not supported over Iur interface, the only interface modifications are related to Iub.
HSDPA activation does not impact UTRAN interfaces Control Plane configuration. As mentioned earlier there is just a moderate evolution of the NBAP messaging. Evolution of RRC messaging does not impact the interface configuration needs for DS VCC.
In fact the major evolution triggered by HSDPA introduction is the definition of a new type of VCC dedicated to HS-DSCH operation.
There is just one HSDPA VCC per Iub, the configuration of this new VCC requires the definition of a dedicated ATM Profile together with the intriduction of a new AAL2 QoS.
The support of IMA with multi-PCM is necessary in order to be able to provide high user data rates, otherwise this may constitute the first bottleneck. Up to 8 PCM links can be managed by a single NodeB.
3-13
September, 20063-13HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
ATM VCC numbering
> 0.32
> x.34
> x.35 – x.40
> x.41 – x.48
> x.49 – x.55
> x.56
OAM
CP
CCP
DS
NDS
HSDPA
3-14
September, 20063-14HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
UE Categories
• QPSK mandatory for HSDPA capable UE
• 16-QAM optional
1.8 MbpsQPSK only15Category 12
0.9 MbpsQPSK only25Category 11
14.4 MbpsQPSK & 16-QAM115Category 10
10.2 MbpsQPSK & 16-QAM115Category 9
7.3 MbpsQPSK & 16-QAM110Category 8
7.3 MbpsQPSK & 16-QAM110Category 7
3.6 MbpsQPSK & 16-QAM15Category 6
3.6 MbpsQPSK & 16-QAM15Category 5
1.8 MbpsQPSK & 16-QAM25Category 4
1.8 MbpsQPSK & 16-QAM25Category 3
1.2 MbpsQPSK & 16-QAM35Category 2
1.2 MbpsQPSK & 16-QAM35Category 1
Max Peak RateModulationInter-TTI Min IntervalHS-PDSCH Max NumberHS-DSCH Category
Twelve new categories have been specified by Release 5 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),
• Maximum peak data rates at the physical layer (number of HS-DSCH codes x number of bits per HS-DSCH / Inter-TTI interval).
These twelve categories provide a much more coherent set of capabilities as compared to R4 which gives UE manufacturers freedom to use completely atypical combinations.
3-15
September, 20063-15HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
UE Capabilities and Max Bit Rates
-10 -8 -6 -4 -2 0 2 4 6 8 1010
15
20
25
C/I (dB)
softCQI
S oft CQI vs C/I - Pedes trian_a 1 RX
Category 6 UE CQI Mapping Table
16-QAM3024 kbps530
16-QAM3024 kbps529
............
16-QAM1440 kbps516
QPSK1296 kbps515
QPSK1008 kbps414
QPSK864 kbps413
QPSK720 kbps312
QPSK576 kbps311
QPSK432 kbps310
QPSK288 kbps29
QPSK288 kbps28
QPSK144 kbps27
QPSK144 kbps16
QPSK144 kbps15
QPSK0 kbps14
QPSK0 kbps13
QPSK0 kbps12
QPSK0 kbps11
out of range0
ModulationRLC Throughput
HS-PDSCH Number
CQI Value
Target BLER ≤ 10%
The maximum achievable data rate depends on the UE category but also on the instantaneous
radio conditions it is exposed to. Each UE category has therefore a reference table specifying the supported combinations between the reported CQI values, the number of codes and the radio modulation (QPSK or 16-QAM).
Instantaneous radio channel conditions are known at the UTRAN level thanks to the periodical decoding of the Channel Quality Indicator sent by the UE to the NodeB onto the HS-DPCCH. The UE first estimates the Carrier over Interference ratio (C/I). From this estimate the UE then determines a CQI (with a maximum HS-DSCH BLER target of 10%) and then it sends this indication back to the NodeB. The NodeB takes this input into consideration in order to adapt the throughput to the UE.
Note: a UE reporting a CQI value of 0 is not scheduled by the NodeB.
3-16
September, 20063-16HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Activation Flags
RNC/RadioAccessService� isHsdpaAllowed (TRUE, FALSE)
RNC/NodeB/FDDCell� hsdpaActivation (TRUE, FALSE)
BTSEquipment/BTSCell� hsdpaResourceActivation
(TRUE, FALSE)
RNC
NodeB
FDDCell
0..200
1..6
0..*
RadioAccessService
1..1
BTSEquipment
BTSCell1..12
0..3000
The parameters involved in HSDPA activation at RNC side are:isHsdpaAllowed: Customer Class 3, rec. = TRUE,
hsdpaActivation: Customer Class 3 , rec. = TRUE.
The parameter involved in HSDPA activation at BTSEquipment side are:
hsdpaResourceActivation: Customer Class 0 , rec. = TRUE.
HSDPA activation main switch is located at RNC level, under the Radio Access Service subtree. If the value of isHsdpaAllowed is set to TRUE, then all the new MOIsrequired for HSDPA operation should be defined in the RNC configuration.
Activation consists in:
• at BTS level, set hsdpaResourceActivation to TRUE.• at RNC level, set isHsdpaAllowed to TRUE and then hsdpaActivation to TRUE.
Note that HSDPA needs to be activated at BTS level first, and that prior to the activation on a BTS, a new VCC shall be created on the corresponding Iub link to carry HSDPA traffic.
Deactivation can be performed at two levels:
• deactivation at RNC level: setting isHsdpaAllowed to FALSE deactivates HSDPA and leaves the HSDPA dedicated resources preserved,
• deactivation at cell level: setting hsdpaActivation and hsdpaResourceActivation to FALSE completely deactivates HSDPA.
3-17
September, 20063-17HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Main Parameters
RNC/RadioAccessService/HsdpaCellClass� maximunNumberOfUsers [0..50]
� numberOfHsPdschCodes [0..15]
� numberOfHsScchCodes [0..4]
� minimumPowerForHsdpa [0..50]
BTSEquipment/BTSCell/HsdpaConf� dchPowerMargin [0..100]
� harqType (mirType, pirType, ccType)
� harqNbMaxRetransmissions [0..31]
� hsdpaResourceId [0..5]
. . .
HS-PDSCH
HS-SCCH
. . .
. . .
. . .
cmCHs
HS-PDSCHHS-SCCH
DPCH
SHO
MCPAPower
Below are some of parameters controlling the behavior of the main HSDPA aspects illustrated in this course.
RNC/RadioAccessService/HsdpaCellClass parameters.
maximunNumberOfUsers: Customer Class 0, rec. = 20.
numberOfHsPdschCodes: Customer Class 0, rec. = 10.
numberOfHsScchCodes: Customer Class 0, rec. = 2.
minimumPowerForHsdpa: Customer Class 0, rec. = 0dB.
BTSEquipment/BTSCell/HsdpaConf.
dchPowerMargin: Customer Class 3, rec. = 20%.
harqType: Manufacturer Class 3, value = mirType.
harqNbMaxRetransmissions: Customer Class 3, rec. = 15
hsdpaResourceId: Customer Class 0.
3-18
September, 20063-18HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Accessibility KPIs
3-19
September, 20063-19HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Accessibility Flow DiagramsUE
RRC Connection Request
RRC Connection CompleteRRC Connection Setup
Radio Link Setup RequestRadio Link Setup Response
Measurement ControlInit Direct Transfer
RNCNode B SGSN
SCCP connection confirm
SCCP connection req.
Security mode command
Security mode complete
Security mode command
Security mode completeCommand id
RAB assignment req.
Radio Bearer SetupRadio Bearer Setup Complete
RAB assignment resp.
S.R.L.R. Procedure
RR
C c
onne
ctio
nS
CC
Pco
nn.
Sec
urity
mod
eR
AB
esta
blsh
t
3-20
September, 20063-20HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Principles
HSDPA RAB
Traffic Class = I/B?
Multi-Service?
R99 RAB
YES
NO
YES
RAB Request
NO
YES
NO
RNCRNC
HSDPA UE?
Primary Cell = HSDPA Cell?
YES
NO
maximunNumberOfUsers (HsdpaCellClass )
RadioAccessService
RNC
HsdpaCellClass
hsdpaMaxNumberUser (BTSEquipment )
hsdpaMaxUserPerNodeB (BTSEquipment )
Any PS RAB request with Interactive or Background traffic class is matched to the HSDPA Radio Bearer configuration if the mobile is HSDPA capable and the primary cell of the active set supports HSDPA. If it is not the case, the request is mapped on DCH as usual (iRM CAC is performed).
In this implementation, the admission process in the RNC for HSDPA admits any I/B RAB request on HSDPA until the maximum number of simultaneous users allowed on HSDPA is reached (maximumNumberOfUsers). In this version there is no other admission criteria.
The BTS will limit 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.
hsdpaMaxNumberUser represents the maximum number of HSDPA user (logical channel) allowed per hsdpaResource (H-BBU) 0 meaning maximum user allowed by software and hardware Default value = 0 (no limit except software and hardware limit).
3-21
September, 20063-21HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
HSDPA CAC success rate
#0957 / (#0957 + #0958 )
This metric characterizes the success of HSDPA Call Admission Control during call establishment or mobility.
It is based on counters
• VS.HsdpaCACSuccess: Number of HSDPA CAC (Successful access to the cell for an HSDPA call during mobility or establishment procedure)
• VS.HsdpaCACUnccessful: Number of HSDPA CAC failures(Unsuccessful access to the cell for an HSDPA call during mobility or establishment procedure)
This metric is at cell level
3-22
September, 20063-22HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
RAB Assignment Flow
UE Node B RNC CN
RAB assignment req.
SRLR procedure
Radio Bearer Setup
Radio Bearer Setup Complete
RAB assignment resp.
#0622 RAB assignment success per req RAB type#0623 RAB assignment success per granted RAB type
#0621 RAB assignment request (UA04.0)
Internal RRM decision to assign
resources
#0601 RB setup success#0602 RB setup unsuccess
RA
Bes
tabl
sht
#0631 RB Establishment Unsuccess
#xxx ?
#601: Number of successful Radio-bearer establishme nts per cell. This measurement provides the number of successful radio bearer establishment procedures, for each cell controlled by the RNC which is the reference cell. Screening: DlAsConf Id
#602: Number of failed Radio-bearer Establishments per cell. This measurement provides the number of RB establishment procedures failures, screened by establishment failure cause, for each cell controlled by the RNC which is the primary cell.During such a procedure, the measurement attached to a given cell is incremented if the cell is in the primary cell of the active set of the involved UE. Screening:
• #0 ---> Time-out expired without reception of a RADIO BEARER SETUP COMPLETE message or a RADIO BEARER SETUP FAILURE message.
• #1 ---> Reception of a RRC RADIO BEARER SETUP FAILURE message
#603: Number of refused Radio-bearer Establishments per cell. This measurement provides the number of RB establishment refusals before any sending of RRC RADIO BEARER SETUP, screened by establishment refusal cause, for each cell controlled by the RNC which is the reference cell. Screening:
• #0 --> Invalid RB parameter value #1 --> Unavailable downlink code resources
• #2 --> Unavailable downlink power resources #3 --> Unspecified
#604: Number of successful RAB establishments. This measurement provides the number of successful Radio Access Bearer establishments, screened by traffic class. Screening:
• #0 --> Traffic Class 0, i.e. Conversational #1 --> Traffic Class 1, i.e. Streaming
• #2 --> Traffic Class 2, i.e. Interactive #3 --> Traffic Class 3, i.e. Background
#605: Number of failed RAB establishments. This measurement provides the nb of unsuccessful Radio Access Bearer establishments, screened by traffic class. Screening: same as #604.
#621: Number of RAB Establishments Requests per RAB type. This measurement provides the number of RAB establishment attempts. Screening: by requested RAB Type (Traffic Class, UL bitrate, DL bitrate).
#0622: Number of RAB establishments success per requested RAB type. This measurement provides the number of successful RAB establishment, screened per requested RAB type (requested should be understood to be after RAB matching).
3-23
September, 20063-23HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
RAB Assignment Success Rate
Voice RAB Assignment = (#0622.[1]) / (#0621.[1])success rate
Voice RAB Assignment = (#0622.[1]) / (#0621.[1])success rate
Video RAB Assignment = (#0622.[2]) / (#0621.[2])success rate
Video RAB Assignment = (#0622.[2]) / (#0621.[2])success rate
PS RAB Assignment = (#0622.[0, 5-42]) / (#0621.[0, 5-42] )success rate
PS RAB Assignment = (#0622.[0, 5-42]) / (#0621.[0, 5-42] )success rate
This metric is Impacted by HSDPA but can not be computed for HSDPA as HSDPA RAB is not requested by the Core Network .
3-24
September, 20063-24HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
HSDPA Case
> For HSDPA we will use RB setup success rate instead or the volume of RAB granted:
HSDPA RAB assignment success per granted HSDPA RAB = (∑#0623[43- 50])
VS.RabEstablishmentSuccessPerGrantedRabType - #623
This measurement provides the number of successful RAB establishment, screened per granted RAB type. Granted should be understood as after RNC CAC (iRM..).
3-25
September, 20063-25HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
RB Set-up success rate
RB Setup success rate = RB setup success / RB set u p request
Pure Voice RB Setup success rate success rate = (# 0601.[2]) / (#0625.[2]) Pure Video RB Setup success rate success rate = (# 0601.[1]) / (#0625.[1]) Pure PS RB Setup success rate success rate = (∑#0601.[2,4,6,7,11,12,23,24,25]) / (∑#0625 .[2,4,6,7,11,12,23,24,25]) Combined RB Setup success rate success rate = (∑#0601.[9,10,15,16,17,18,21,22,26,28,29,30]) / (∑#0625 .[9,10,15,16,17,18,21,22,26,28,29,30]
HSDPA RB setup success rate = #0601.[27] / #0625 .[ 27]
This metric is the counterpart of RAB assignment success rate but at cell level
It is based on counters
• #0601 VS.RadioBearerSetupSuccess : Number of Radio Bearers successfully setup
• #0625 VS.RadioBearerSetupRequest : Number of Radio bearer setup decisions by the RNC (leading or not to a RB SETUP, ie. even if Call Admission Control rejects the setup)
3-26
September, 20063-26HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Traffic Segmentation
R4 cell R4 cell
RRC Connection Setup(Redirection to F1)
HSDPA cell
RNC
RRC Connection Setup(Redirection to F2)
RRC Connection Request(AS release indicator = R4 or absent)
RRC Connection Request(AS release indicator = R5)
HSDPA 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.
3-27
September, 20063-27HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
DCH or HSDPA(i.e. no re-direction)Terminating – cause unknown
DCH or HSDPA(i.e. no re-direction)Terminating Low Priority Signalling
DCH or HSDPA(i.e. no re-direction)Terminating High Priority Signalling
DCH or HSDPA(i.e. no re-direction)Call re-establishment – PS case
DCH or HSDPA(i.e. no re-direction)Call re-establishment – CS case
DCH or HSDPA(i.e. no re-direction)Originating Low Priority Signalling
HSDPAOriginating High Priority Signalling
DCH or HSDPA(i.e. no re-direction)Detach
HSDPARegistration
DCH or HSDPA(i.e. no re-direction)Inter-RAT cell change order
DCH or HSDPA(i.e. no re-direction)Inter-RAT cell re-selection
DCH or HSDPA(i.e. no re-direction)Emergency Call
HSDPATerminating Background Call
HSDPATerminating Interactive Call
DCHTerminating Streaming Call
DCHTerminating Conversational Call
HSDPAOriginating Subscribed traffic Call
HSDPAOriginating Background Call
HSDPAOriginating Interactive Call
DCHOriginating Streaming Call
DCHOriginating Conversational Call
Suitable layerSuitable layerSuitable layerSuitable layerEstablishment CauseEstablishment CauseEstablishment CauseEstablishment Cause
Multi-carrier HSDPA traffic segmentationProcedure description
Static mapping perfomed by the RNC between the Establishment Cause and the suitable layer (DCH or HSDPA):
3-28
September, 20063-28HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Multi-carrier HSDPA traffic segmentation Parameters
FalseBooleanC3isRedirectionBasedOnEstablishmentCause
(FddCell.InterFreqHho)
TrueBooleanC3isRedirectionForTrafficSegmentation(FddCell.InterFreqHho)
ValueRange & UnitClassParameter
(Object)
*The twin cell is considered HSDPA if declared such as the parameter under FddCellhsdpaActivation is equal to True.
**The value of isRedirectionBasedOnEstablishmentCause is taken into account only if isRedirectionForTrafficSegmentation is set to true.
3-29
September, 20063-29HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Accessibility
On the source cell:
#0138 VS.IntraRncOutInterFreqHoAttempt
screening R5 mobile to HSDPA layer
On the target cell:
#0140 VS.IntraRncIncInterFreqHoAttempt
screening R5 mobile to HSDPA layer
Number of R5 mobiles outgoing redirections toward a HSDPA layer
This metric gives the number of R5 mobiles (supporting HSDPA) that were redirected toward a HSDPA layer during the RRC connection establishment.
By choosing others screenings we can monitor also
• the number of R5 mobiles (supporting HSDPA) that were redirected toward a non-HSDPA layer during the RRC connection establishment. This case occurs when a R5 mobile tries to establish a RRC connection for non PS traffic purpose on a HSDPA layer and that traffic segmentation is activated.
• the number of non-R5 mobiles (not supporting HSDPA) that were redirected toward a non-HSDPA layer during the RRC connection establishment. This case occurs when a non- R5 mobile tries to establish a RRC connection on a HSDPA layer and that traffic segmentation is activated.
3-30
September, 20063-30HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Retainability
3-31
September, 20063-31HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Network Retainability Performance
> The objective of the retainability metrics is to evaluate the ability of the network to provide reliable service to the end user.
> If and only if a call is dropped , the RNC sends the RANAP Iu Release Request message with the field abnormal reasons.
> A good part of the calls dropped are originated by a Radio Link Failure Indication message (this is not the case for the calls dropped after a RLC reset).
3-32
September, 20063-32HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Total number of RABs
UE
RAB assigt resp*
(…)
(…)
RNCNode B
RRC Connection Setup
MSC
RANAP/RAB assigt req
RRC Connection Complete
#0622 RAB establishtsuccess
*RANAP/RAB assigt resp.: can be several responses.
Radio access bearer
assignment procedure
#0533: Number of Abnormal RELEASE Requests on Iu CS. This measurement represents the number of Iu CS release requests due to abnormal conditions. Screening: by DLAsConf.
Condition = on RNC requests Iu CS release due to abnormal conditions:
• O&M intervention
• Repeated integrity check failure
• Radio connection lost
• Relocation timeout (corresponding to timeout of TrelocoverallExpiry and TrelocCompleteExpiry)
• Unspecified failure
#0622: Number of RAB Establishments SUccess Per Requ ested RAB type. This measurement provides the number of successful RAB establishment, screened per requested RAB type (requested should be understood to be after RAB matching). Screening by RAB Type. Screening: by requested RAB Type.
3-33
September, 20063-33HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Abnormal Release Caused by RL Failure
Node B RNC CN
Radio Link Failure Indication
Radio Link Deletion Resp
Iu Release Req
#0533 Iu abnormal release request CS#0534 Iu abnormal release request PS
#0505 Iu release command CS#0506 Iu release command PS
#0013 Dropped Last Radio Links
Iu Release Command
Radio Link Deletion Req
Iu Release Complete
#0013: Number of dropped calls on last radio-link r elease. This measurement provides the number of dropped calls (on last radio-link release), for each cell controlled by the RNC. Screening: by DlAsConf.#0505: Number of RELEASE COMMANDs on Iu CS. This measurement provides the number of RANAP IU RELEASE COMMAND messages received by the RNC on Iu CS.#0506: Number of RELEASE COMMANDs on Iu PS. This measurement provides the number of RANAP “IU RELEASE COMMAND” messages received by the RNC on Iu PS.#505 & #506 screening:
• #0 --> Normal end of communication
• #1 --> Successful 3G/2G or 3G/3G relocation (3GPP RANAP cause 11)• #2 --> UTRAN generated reason (3GPP RANAP cause 15) or Iu_release_request sent by RNC
before
• #3 --> Other cause (all other 3GPP RANAP causes)
• #4 --> Relocation Cancelled (3GPP RANAP cause 10)
• #5 --> O&M Intervention (3GPP RANAP cause 113)
• #6 --> Unspecified Failure (3GPP RANAP cause 115)• #7 --> User Inactivity (3GPP RANAP cause 16)
• #8 --> No Remaining RAB (3GPP RANAP cause 31)#0533: Number of Abnormal RELEASE Requests on Iu CS. This measurement represents the number of Iu CS release requests due to abnormal conditions. Screening by DlAsConf (DL AS configuration). Screening: by DlAsConf.#0534: Number of Abnormal RELEASE Requests on Iu PS. This measurement represents the number of Iu PS release requests due to abnormal conditions. Screening by DlAsConf (DL AS configuration). Screening: by DlAsConf.
3-34
September, 20063-34HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Call Abnormal Release
#0540 Iu release request CS (cell)#0541 Iu release request PS (cell)#0546 Iu abnormal release request CS (cell)#0547 Iu abnormal release request PS (cell)
#0505 Iu release command CS#0506 Iu release command PS
Node B RNC CN
Radio Link Deletion Response
Iu Release Request
Iu Release Command
Radio Link Deletion Request
Iu Release Complete
#0544 Iu release complete CS#0545 Iu release complete PS
Issue detected
New counterCounters screenings updatedNo change
#540 (#541): This measurement provides the number of RANAP IU_RELEASE_REQUEST sent by RNC to Core Network CS (PS).
• Sub-Counter #0 : Release due to OAM intervention
• Sub-Counter #1 : Iu User-plane failure
• Sub-Counter #2 : Unspecified failure
• Sub-Counter #3 : Repeated Integrity protection check failure
• Sub-Counter #4 : Release due to UE
• Sub-Counter #5 : Radio connection lost with UE
• Sub-Counter #6 : Relocation too long (timer on relocation expiry).
• Sub-Counter #8 : DL RLC error on SRB
• Sub-Counter #9 : UL RLC error on SRB
• Sub-Counter #10 : DL RLC error on TRB
• Sub-Counter #11 : UL RLC error on TRB
#546 (#547): Number of Iu abnormal release request that increments whenever RNC requests Iurelease due to abnormal conditions to CS (PS) CN. Instance FDDCell / DlAsConf (Reference).
Dropped call KPIs will only be calculated on calls with an AsConfId (Q01158696-01). Some counters already exist for IU release requests: counters 540 and 541 (VS.IuReleaseRequestCs. And VS.IuReleaseRequestPs.) These ones are incremented for all cases (normal or abnormal); the normal cases are: - release due to UE generated signnaling connection relaese (abnormal TBC) - user inactivity (in case of always on) - Last remaining RAB all other cases are considred as abnormal. The abnormal cases currently covered are the following ones: - OandM intervention - Repeated integrity check failure -Radio connection lost - Relocation timeout (corresponding to timeout of TrelocoverallExpiry and TrelocCompleteExpiry) - Unspecified failure
3-35
September, 20063-35HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Call Drop Rate at RNC Level
> Separation of services (voice, video and data calls) => to facilitate the troubleshooting based on user behavior.
> Signaling is not considered anymore.
> The metric available in UA4.0 as defined is useful at RNC level or at network level but not at cell level.
> The main retainability issues detected by this issue: DL/ UL RF conditions, HW instability at PCM level and at RNC level.
3-36
September, 20063-36HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Call Drop Rate at RNC Level
Voice call drop rate = Voice call drop rate = ∑ #0533.[1,5,9,10,15,16,17,18]
∑ #0622.[1]
Video call drop rate = Video call drop rate = ∑ #0533.[0]
∑ #0622.[2]
Data ‘call’drop rate*
Data ‘call’drop rate*
∑ #0534.[2,4,6,7,9,10,11,12,15,16,17,18]
∑ #0622.[5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25]
=
*RAB drop rate
#0533: Number of Abnormal RELEASE Requests on Iu CS. This measurement represents the number of Iu CS release requests due to abnormal conditions by DL Access Stratum Configuration.
Screening: Downlink Access Stratum configurations:
• Containing CS: As Conf Id = {0, 1, 5, 8, 9, 10, 14, 15, 16, 17, 18}
• Containing PS: As Conf Id = {2, 4, 6, 7, 9, 10, 11, 12, 15, 16, 17, 18, 19, 20}
• Containing Speech: As Conf Id = {1, 5, 9, 10, 15, 16, 17 ,18}
• Pure CS: As Conf Id ={ 0, 1, 5, 8, 14 }
• Pure PS: As Conf Id ={ 2, 4, 6, 7, 11,12, 19, 20 }
• Multi-service (PS+CS): As Conf Id = {9, 10, 15, 16, 17, 18}
• Pure SRB: As Conf Id = {3, 13}
Note
While ‘containing PS’ includes screening [19] & [20], they are not in the data call drop rate because [19] = cellFACH and [20] =interworking V2.
#0622: Number of RAB Establishments Success Per Req uested RAB type. This measurement provides the number of successful RAB establishment, screened per requested RAB type (requested should be understood to be after RAB matching).
3-37
For CS domain: separation of voice and video results to easily identify the CS service the most impacted
For PS domain: the PS Retainability results are dependant on the number of PS RAB and so the results could be impacted by changing the Always-On Parameters
On RNC requests Iu CS release due to abnormal condit ions :
• O&M intervention
• Repeated integrity check failure
• Radio connection lost
• Relocation timeout (corresponding to timeout of TrelocoverallExpiry and TrelocCompleteExpiry)
• Unspecified failure
September, 20063-37HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Call Drop Rate per RAB established
Call drop Rate = Number of drops / Number of RAB su ccess per granted RAB type CS CDR = (∑#0546.[0,1,5,9,10,15,16,17,18,21,22,26,28,29,30])/∑#0623.[1,4]) Voice CDR = (∑#0546.[1,5,9,10,15,16,17,18,22,26,28])/∑#0623.[1]) Video CDR = (∑#0546.[0,21,29,30])/∑#0623.[2]) PS RAB Drop Rate = (#0547.[2,4,6,7,8,9,10,11,12,14,15,16,17,18,21,22,23,24,26,27,28,29,30])/(∑#0623.[0,5-50])
Update since 4.1 : new screenings
HSDPA Call drop rate = ( ∑#0547[27] / (∑#0623 .[43-50]
3-38
September, 20063-38HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Call drop rate per released calls - celllevel
Call drop rate per released calls = Number of drops / (Number of normalyand abnormaly terminated calls)
CS Call drop rate at cell level =Iu abnormal release requests CS / Iu release complete CS= ∑#0546 ( CS DlAsConfid) / ∑#0544 ( CS Dl AsConfid)
PS Call drop rate at cell level =Iu abnormal release request PS / (Iu abnormal release r equests PS + Downsizing Step 2 ( PS Dl ASConfid) + Radio Bearer re lease success ( PS + FACH) )
= ∑ #0547 ( PS Dl Asconfid) / ( ∑ #0547 ( PS DlAsConfId) + ∑ #1105 ( PS DlAsConfId) + ∑ #0608 ( PS + Fach) )
Update since 4.1 : new screenings
Impacted by HSDPA
Included in PS metric
Top N worst cells can be evaluated with the number of call dropped at cell level building on the counter
Number of Iu CS/PS release requests due to abnormal conditions (#0546/0547)
3-39
September, 20063-39HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Number of drops per minute of RAB
Number of drops per mn of RAB =
Iu abnormal release requests / Allocation time of the RAB60*10* (∑∑∑∑ VS.IuAbnormalReleaseRequestCs /PS [CS/PS DlAsConfIdscreenings] / ∑∑∑∑ VS.DlAsConfIdAvgNbrEstablished. CUM [CS/PS DlAsConfIdscreenings])
Number of drops per mn of HSDPA Call = 600*#0547[27] / #0660.Cum [27]
Update since 4.1 : new counter
This metric allows to count the number of drops versus the duration of the RAB. It isbased on
• #0546 / #0547 Iu abnormal release requests CS/ PS at reference cell level
• #0660 VS.DlAsConfIdAvgNbrEstablished: Average number of DlAsConfIdsestablished per iRNC at reference cell level
3-40
September, 20063-40HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Traffic
3-41
September, 20063-41HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Average Number of calls
> The average number of calls is based on the counter: • average number of established RAB in the RNS, per TC+UL/DL Bit rate, during a
reporting period. (#0627)
• This metric can only be monitored at RNC level
> At Cell Level the metric is based on• Average number of DlAsConfId (#0660 in DL, #0661 in UL ) and is screened per
AsConfId
Average number of Voice calls = #0627. Avg[1] Average number of video calls = #0627.Avg[2] Average number of PS calls = #0627.Avg[0,5-42]
Update since 4.1 : new screenings, new counter at cell level
Average number of Voice calls = #0660. Avg[ 1,5,9,10,15,16,17,18,22,26,28] Average number of video calls = #0660.Avg[ 0,21,29,30] Average number of pure PS calls =#0660.Avg [2,4,6,7,8,9,10,11,12,14,15,16,17,18,21,22,23,24,26,28,29,30]
Average number of HSDPA calls = #0627.Avg[43-50]
Average number of HSDPA calls = #0660.Avg[27]
3-42
September, 20063-42HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Uplink/ Downlink PS Traffic
DL PS Traffic per RNC = ∑#1443.[0,5,6,7,8,9,10,11,12,13,15,16,17,18,19,20]
UL PS Traffic per RNC = ∑#1442.[0,5,6,7,8,9,10,11,12,13,15,16,17,18,19,20]DL PS Traffic per reference cell = ∑#1459.[0,5,6,7,8,9,10,11,12,13,15,16,17,18,19,20]UL PS Traffic per reference cell = ∑#1458.[0,5,6,7,8,9,10,11,12,13,15,16,17,18,19,20]
Update since 4.1 : new screenings
Available for HSDPA
The Downlink PS Traffic metric and Uplink PS Traffic metric aim at providing the amount of data traffic
This global information is interesting to correlate with eventual decrease of network performance results (e.g. congestion)
These metrics are based on the following counters :the number of downlink/uplink RLC payload in kbytes on dedicated channels at RNC level (#1443/ #1442)
the total count of downlink/uplink RLC payload in kbytes on dedicated channels at reference cell level (#1459/ #1458)
the total count of downlink/uplink RLC payload in kbytes on dedicated channels for each cell of the active set (#1457/ #1456)
The amount of traffic can be monitored per UL/DL Bit rate and so identify the main bearers which convey the main traffic
3-43
September, 20063-43HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Throughput DL per Combined DL/UL max bit rate at RNC level
Troughput DL /UL per Combined DL/ UL max bit rate at RNC level (Kb/s)=8*1.024*10* [ ΣΣΣΣ VS.DedicatedDown /UplinkKbytesRlc( UL/DL Bit rate) / ΣΣΣΣVS.NumberOfRabEstablished.Rab. Cum (UL/DL Rab type)]
Update since 4.1 : new screenings
Available for HSDPA
Throughput metrics are necessary to assess the quality of the network and can becorrelated to congestion resultsThese metrics are based on the following counters
Number of Kbytes of SDU payload received/sent on dedicated uplink/downlink RLCs (#1442 / #1443 )Time that CS/PS RAB is allocated (#0627 * observation time)
Throughput can be monitored per UL/DL Bit rate at RNC level
3-44
September, 20063-44HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
HSDPA DL Kbytes ( SDU payload)
1459.RabPsIBHsdpa_32U+1459.RabPsIBHsdpa_64U+1459.RabPsIBHsdpa_128U+1459.RabPsIBHsdpa_384U
The HSDPA traffic carried from a RNC perspective on the primary cell can be monitor with the counter
#1459 VS.DedicatedDownlinkKbytesRlcReferenceCell
The retransmissions are not counted
3-45
September, 20063-45HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
NodeB Scheduler
3-46
September, 20063-46HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
First Stage Principles
Credits Computation
Cost Function Evaluation
PQ0 PQ15
QId0 QId1 QIdN QId0 QId1 QIdN
PQ0 COST PQ15 COST
Lowest Cost PQ Selection
already transmitted bitscreditsCOST =
Function of:• QIds number• PQ weight (priority)• number of active PQs• total bandwidth
The aim of the scheduler is to dynamically share available DL bandwidth among users, in order to optimize the overall throughput, and fulfill network and UE criteria. In order to separately manage the two aspects, the scheduler is divided into two stages:
The first stage deals with priorities (CmCH-PI) assigned by higher layers on the different queues for choosing queues which will be served in the coming transmission interval.
The selection and change of priority queue is based on a cost function for each priority queue. These cost functions will determine what is the queue to be serviced first in the next TTI. The queue with the lowest cost function is selected. Cost functions simply rely on two parameters, the credits of the queue and the total number of PDUs already transmitted during past rounds.
3-47
September, 20063-47HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Second Stage Principles
QId0 QId1 QIdN
Retransmissions First
New Transmissions
Round Robin Fair CQI Proportional Fair
UE Capabilities Available Power & Codes ACK/NACK/CQI Previously Transmitted PDUs
UE #0• power• codes• number of bits
UE #1• power• codes• number of bits
UE #N• power• codes• number of bits
The second stage takes care of radio conditions and UE capabilities to determined what users belonging to the selected queue will get access to radio resources in the coming transmission interval.
A preliminary allocation phase consists in scheduling retransmissions before allocating resources to new transmissions. In case retransmissions are scheduled in the coming TTI, the amount of power available for transmissions of new transport blocks is reduced accordingly.
For new transmissions, the decision of the scheduler is based on a cost function. UE selection is a tradeoff between the throughput optimization and the equity among UEs.
3-48
September, 20063-48HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
SPI Configuration
priorityLevel (SpiConfiguration)
backgroundSpi (SpiConfiguration)
interactiveSpi (SpiConfiguration)
RadioAccessService
RNC
HsdpaRncConf
SpiConfiguration
SpiConfiguration
SpiConfiguration
PQ0 PQ15
QId0 QId1 QIdN QId0 QId1 QIdN
SecondStage
FirstStage
NodeB Scheduler
Background Interactive
gold 15 15
silver 7 7
bronze 0 0
OLSUMTS TRAFFIC CLASS
Before entering the scheduler, the Mac-d PDUs for each queue of each user are classified according to their corresponding priority (CmCH-PI). Every TTI, the scheduler is launched in order to efficiently assign the available resources (number of codes and remaining power) to the different users.
The selection of a priority queue is based on a cost function that takes into account credits assigned to each priority queue and the number of Mac-d PDUs already transmitted in the last TTI for these queues.
The aim is to provide some throughput per queue according to its priority (SPI): the higher the priority (the higher the SPI), the higher the allocated bandwidth.
3-49
September, 20063-49HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Traffic
#10804.CUM / #10818
Average number of scheduled UE
The average number of scheduled UE is based on the counters
• #10804 VS.HsdpaHSSCCHCodesPerTTI : Number of HS-SCCH codes used per TTI ( then gives the number of UEs in the TTI)
• #10818 VS.HsdpaTTIsUsed : Number of TTIs containing at least one scheduled UE.
3-50
September, 20063-50HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Traffic
During one hour
(VS.HsdpaTTIsUsed*0.0020) / 3600.0)
HSDPA activity rate
The HSDPA activity rate allows to compute the rate of TTI containing at least one scheduled UE.
This metric is used to see the rate of usage of HSDPA resources on the node B.
This metric is based on counter
#10818 VS.HsdpaTTIsUsed : number of TTI which have scheduled at least one UE
HSDPA activity rate =
Number of TTI containing at least one scheduled UE * duration of a TTI (s) / observation period (s)
3-51
September, 20063-51HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Adaptive Modulation and Coding
3-52
September, 20063-52HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
CQI Reporting Principles
-15-14-13-12-11-10-9-8-7-6-5-4-3-2-1000000000000000
∆∆∆∆
33195283319527331952633195253319524331952333195223319521331952033195193319518
33195303319529
33195173319516331951525834142279413174231214833111262310931297922865027461163771531714233131731213711
out of range0TBSOVSFCQI
P-CPICH
HS-DPCCH
Target BLER ≤ 10%
PHS-PDSCH
=PP-CPICH + Γ + ∆
2ms
The procedure to allocate power to the HSDPA traffic channel described in the standard is mainly based on terminal measurements and reporting.
In this procedure the UE monitors continuously (i.e. every 2 ms) CPICH received power (i.e. EcNo and RSCP) and derives the next CQI value to be sent to BTS based on some mapping tables CPICH EcNo (or RSCP) vs. CQI (UE implementation dependent). These mapping tables assume a BLER = 10% on the first transmission of HS-PDSCH (quality requirement ). However the mapping tables are based on off-line simulations and therefore they do not account for the actual RF conditions. Due to the variability of RF environment, it is possible that BLER on HS-PDSCH is larger than target of 10% leading to lower than expected throughput.
HS-PDSCH power estimates are based on the UE measurement of the power of the Primary Common Pilot CHannel (P-CPICH) (see formula in the above slide). Γ is the Measurement Power Offset, provided by the RNC to the NodeB via NBAP signaling and to the UE via RRC signaling. This is a fixed offset relatively to the power of the P-CPICH. ∆ is the Reference Power Adjustment, which depends on the CQI value reported by the UE and on the category of the UE (CQI mapping tables).
UE sends the CQI back to the NodeB onto the HS-DPCCH.
3-53
September, 20063-53HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
CQI Modification Principles
Scheduler
HS-DPCCH demodulation
CQI Averaging
CQI adjustment based on BLER and DTX
CQI update due to:• Power limitation• Codes limitation• MAC-hs buffer occupancy • MAC-d PDU size
UL Synchronization failure detection
CQIreported
CQIaveraged
CQIprocessed
CQIapplied
Between the decoded CQI and the applied CQI, many transformations are processed.
First level of CQI modifications is performed to take into account possible RL synchronization loss detections, CQI average over successive TTIs and the CQI defense mechanisms to handle DTX and BLER problems.
Second level of CQI modifications is performed by the NodeB Scheduler. It aims at dynamically aligning the Transport Format with the current resources availability.
Transport formats always remain based on the CQI mapping tables. Two different CQI correspond to different transport formats with the same power to reach the same performance level, but could also correspond to two different powers with the same transport format. A step of 1dB is considered to go from one CQI to the next one.
The transport format is determined according to the processed CQI, CQIprocessed. In case of a lack of resources (codes or power), the applied CQI, CQIapplied, is then modified according to the previous rule to take this into account. It is done in four steps:
• power limitation management,
• codes limitation management,
• lack of MAC-d PDU in buffer,
• optimization of CQI according to MAC-d PDU size.
3-54
September, 20063-54HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
HSDPA specific traffic metrics DL HSDPA radio traffic
> It is based on the counter
> This metric is at cell level and its unit is in Kbit
New 4.2
#10809 VS.HsdpaTxDataBitsSchedTotal
This measurement provides the total 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.
3-55
September, 20063-55HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
HSDPA specific traffic metric MAC-HS throughput and Cell throughput
Mac-HS throughput (useful throughput)=
Number of bits transmitted for the first time by the node B / Time of transmission ( number of TTI * 2 ms)
500*(VS.HsdpaTxDataBitsMAChs.Cum / VS.HsdpaTTIsUsed )
Cell throughput =
Number of bits transmitted /Time of transmission
500*(VS.HsdpaTxDataBitsSchedTotal / VS.HsdpaTTIsUsed )
New 4.2
Throughput from Node B or cell perspective are based on the total number of data bits (transport block size) first transmitted or withretransmission by the MAC-hs divided by the number of TTI scheduling UE
It is based on counters#10808 VS.HsdpaTxDataBitsMAChs : number of bits transmitted at
Mac-Hs level ( without repetitions)or
#10809 VS.HsdpaTxDataBitsSchedTotal :number of bits transmitted at Mac-Hs level ( with retransmissions)
#10818 VS.HsdpaTTIsUsed : number of TTI which have scheduled at least one UE
3-56
September, 20063-56HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Mac-d Throughput per cell
Rate of Mac-d PDUs successfully transmitted (i.e. which has received an ACK) compared the number of TTI (kbit/s) per cell
• #10806 VS.HsdpaMACdPDUAckBits• #10818 VS.HsdpaTTIsUsed
Mac-d Throughput per cell =
500*(VS.HsdpaMACdPDUAckBits.Cum / VS.HsdpaTTIsUsed )
New 4.2
3-57
September, 20063-57HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Quality
3-58
September, 20063-58HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
MCPAPower
HSDPA Power Management Principles
UE selected
Ptemp = PHSDPA – PHS-SCCH
Ptemp > 0?
UE not scheduled
Yes
No
Go to Next Step
CmCH
DCH margin
PHSDPA
DCH
HS-DSCH
HS-SCCH
HSDPA power management is based on the principle that HSDPA channels can use all the remaining power left by dedicated and common channels. In order to compensate the DCH power fluctuation mainly due to power control, a margin is considered (dchPowerMargin).
The total available power for HSDPA corresponds to the difference between the maximum available power in the cell and the power for R99 channels plus margin.
A UE is scheduled only if there remains enough power to transmit at least the HS-SCCH. Otherwise the NodeB try to schedule another UE in the TTI. If all UEs require power for HS-SSCCH higher than what is available at NodeB level, none of them is scheduled.
3-59
September, 20063-59HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
First Tx Power Allocation Principles
PHS-DSCH = PP-CPICH + ΓΓΓΓ + ∆∆∆∆(CQI)
PHS-DSCH < Ptemp?P’HS-DSCH = PP-CPICH + ΓΓΓΓ
∆∆∆∆RP = round(10.log(P temp / P’HS-DSCH))
CQIRP = CQI + ∆∆∆∆RP
∆∆∆∆RP = 0
CQIRP = CQI
CQIRP > 0?ncodes = f(CQIRP)
UE not scheduled
UE selected (Ptemp > 0)
Yes
No
YesNo
Go to Next Step
In case there doesn’t remain enough power to transmit data corresponding to the processed CQI to a selected UE, the transport format is modified in order to reduce its power.
The excess power, corresponding to the total needed power minus the maximum allowed power, is computed. This value, expressed in dB, then directly indicates the number of CQI levels one should decrease in order to remain at the same level of performances. In case the resulting value is not valid CQI (≤0), the UE is not scheduled.
If such a modification is not possible, the UE is not scheduled.
3-60
September, 20063-60HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Retransmission Principles
Yes
UE selected (retransmission nb > 0)
1st Tx Power<
Remaining Power?
No
UE scheduledTransmitted Pwr = 1st Tx power
Another UE scheduled in TTI?
UE scheduledTransmitted Pwr = Remaining power
UE not scheduled
Yes
No
In case of retransmissions, the HS-SCCH power must be based on the current CQI and not on the first transmission one.
Nevertheless, for retransmissions, there is no modification of the Transport Format used for the first transmission. Meaning that the NodeB tries to re-allocated exactly the same power as the one used for the first transmission.
3-61
September, 20063-61HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
HSDPA Retransmission rate
(#10809 - #10808) / #10808
This metric allows to compute the rate of retransmissions.
It characterizes the quality of the transmission.
It is based on counters
#10808 VS.HsdpaTxDataBitsMAChs : number of bits transmitted at MacHS level for the first time
#10809 VS.HsdpaTxDataBitsSchedTotal : number of bits scheduled ( including repetitions)
3-62
September, 20063-62HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Iub Bandwidth Limitation
Baseline : no congestion management => poor Iub link utilization
0100020003000400050006000700080009000
10000
14:0
3:30
14:0
4:04
14:0
4:38
14:0
5:13
14:0
5:47
14:0
6:21
14:0
6:55
14:0
7:29
14:0
8:03
14:0
8:37
14:0
9:11
14:0
9:45
14:1
0:19
14:1
0:53
14:1
1:27
14:1
2:01
14:1
2:34
14:1
3:08
14:1
3:39
Time
cells
/sec
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
16:53
:54
16:54
:14
16:54
:34
16:54
:54
16:55
:14
16:55
:35
16:55
:55
16:56
:15
16:56
:35
16:56
:55
16:57
:15
16:57
:35
16:57
:55
16:59
:26
16:59
:46
17:00
:06
17:00
:26
17:00
:46
17:01
:06
17:01
:26
17:01
:46
17:02
:06
17:02
:26
17:02
:47
17:03
:08
17:03
:28
17:03
:48
17:04
:08
17:04
:28
17:04
:48
17:05
:08
17:05
:29
17:05
:49
17:06
:09
17:06
:30
17:06
:50
17:07
:10
17:07
:30
17:07
:50
17:08
:10
17:08
:30
17:08
:50
17:09
:10
Time
cells/sec
Iub limitation handling : 100% Iub efficiency
Voice Video-telephony : QoS 0
Data (R99) : QoS 1
Data (HSDPA) : QoS 2
Aggregate Iub Throughput
FEATURE BENEFITS
This feature will improve Iub bandwidth utilization when HSDPA is activated, by allowing provisioning Iub with less bandwidth than what would be required in theory to carry the traffic generated by the NodeB in worst case scenarios.
With HSDPA, the effective throughput per UE is quite variable. A flow control mechanism has been introduced between the Mac-d (RNC) and the MAC-hs(NodeB) entities in order to fill the NodeB buffers with sufficient data to provide for the UEs and be quite reactive to throughput variations.
This flow control is based on three main procedures:
• The Capacity Request procedure that provides means for the CRNC to indicate for each session of each UE its buffer occupancy (at MAC-d level).
• The Capacity Allocation procedure generated by the NodeB to indicate to the RNC how many MAC-d PDUs are required for the desired session and the interval in which these data should be sent, based on the estimated throughput for this session and the number of remaining MAC-d PDUs in NodeBtransmission buffer.
• The HS-DSCH data transfer procedure in which the RNC sends the MAC-d PDUsgrouped in FP frames (1 to 255 PDUs per FP frame). The updated buffer occupancy is also given. The RNC may choose to send all the required MAC-d PDUs in a single FP frame, or to space out (within the notified interval) the transmission in several FPs.
3-63
Control of Iub Bandwidth at ATM level is not efficie nt
ATM Discard is not efficient (corrupted FP frame waste bandwith)
ATM Discard doesn’t take into account Diversity Traffic (Soft HO)
HSDPA Traffic has very little timing constraint
Due to MAC-hs flow control, HSDPA Traffic on Iub can be very bursty
Iub Bandwidth Limitation is moved to Packet Converte r (from ATM):
PC monitors the available bandwidth on Iub
PC monitors the amount of data to transmit on Iub link
For NDS and HSDPA Traffic, if a threshold is exceeded, the PC sends some control frames to the PMC RAB that are generating some HSDPA traffic (i.e. FP Frame) to stop Frame Processing: this is called back-pressure mechanism
Iub Bandwith limitation is not applicable on Iur as th e PC (for Iub) and the PMC RAB are not in the same RNC !
September, 20063-63HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Iub Bandwidth Limitation - Principle
> Control of Iub Bandwidth at ATM level is not efficient
> Iub Bandwidth Limitation is moved to Packet Converter (from ATM):
> Iub Bandwith limitation is not applicable on Iur as the PC (for Iub) and the PMC RAB are not in the same RNC !
3-64
September, 20063-64HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Iub Bandwidth Limitation – F. A.
> Using WIPS, to activate the feature, you need to:• Under Interface Node, RncIn, fc (FlowControl)
• Set iubFlowControlActivation to discardAndBackPressure• Set qosBackPressureThreshold and qosDiscardThreshold to the
recommended values
> qosDiscardThreshold defines the thresholds before starting to discard FP Frames in the Packet Converter: the discard should not happens if the threshold are correctly set.
> qosBackPressureThreshold defines the thresholds (relative to the ones above) before starting to back-pressure in PMC RAB
> First value of qosBackPressureThreshold and qosDiscardThreshold must be 0 (DS Traffic)
> Second value of each set affects NDS Traffic
> Third value of each set affects HSDPA Traffic
3-65
September, 20063-65HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Downlink BLER PS
BLER PS = BLER PS = #1462.[0,3,7,8,9,10,13,14,16]
#1461.[0,3,7,8,9,10,13,14,16]
BLER PSat 64kbps
BLER PSat 64kbps
# 1462.[0,7,8]
# 1461.[0,7,8]=
BLER PSat 128kbps
BLER PSat 128kbps
# 1462.[10]
# 1461.[10]=
BLER PSat 8kbps
BLER PSat 8kbps
# 1462.[9,13,14]
# 1461.[9,13,14]=
BLER PSat 32kbps
BLER PSat 32kbps
# 1462.[3,16]
# 1461.[3,16]=
The CS metric is not significant because speech is made of a lot of blanks, and those blanks have good CRC! It misleads the results.
In the downlink case a drive test is necessary. Indeed there is no counters and no mobile does the measurement.
For better analysis and correlation DL and UL measurement are necessary at the same time.
#1461: This measurement provides the number of downlink RLC PDU emitted on dedicated channels on the reference cell.
#1462: This measurement provides the number of downlink RLC PDU retransmitted on dedicated channels on the reference cell. This counter is only pegged for RLC AM bearer (so only for PS). This is incremented for the Current RAB and any RLC PDU (Q01371476). screenings 1, 2, 3, 4 are always zero because RLC cannot provide TM mode (Q01262533).
3-66
September, 20063-66HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Uplink BLER PS
BLER PS = BLER PS = #1444.[0,3,7,8,9,10,13,14,16]
#1451+1444.[0,3,7,8,9,10,13,14,16]
This metric must be computed by RB..
#1444 This measurement provides the number of Uplink RLC PDU received on dedicated channels. This is incremented for the Current RAB and any RLC PDU received (Q01371476). Notes: in cases where data is transmitted on coordinatedtransport channels, the frames of each subflow are not counted independently. The PDU and SDU counters are incremented only once for each set of frames receivedor sent. An RLC PDU is a frame sent (see TS 25.322) from the RLC to the MAC (or vice versa). For CS voice, counting occurs for data frame, SID frame and emptyframe. Empty frames are being counted for BLER reason (Q01168175). For bearerswhere RLC is in transparent mode, this counter also includes received frames thatcontain no payload.
#1451 This measurement provides the total number of Transport Blocks received with CRCi = 1 (transport block contains errors) on a CS or PS bearer (this does not include SRBs). For voice, CRCi only applies to Class A bits.
3-67
Student notes
3-68
September, 20063-68HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Congestion
3-69
September, 20063-69HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
HS-SCCH Power Control Activation
P-CPICH
HS-SCCH
-8 dB13 – 30
-5 dB10 – 12
-3 dB8 – 9
0 dB1 – 7
Power OffsetCQI
distance
HS-SCCH to P-CPICHPower Offset
hsscchPcOffset (HsdpaConf)
BTSCell
BTSEquipment
HsdpaConf
There is no true power control mechanism on HS-SCCH and a CQI-based power control procedure is implemented instead.
A direct relation between the quality of DL radio conditions and the amount of power to be allocated to the HS-SCCH is used. The worst the DL radio conditions, the smallest the CQI and the greatest the power to be allocated to the HS-SCCH. The principle then consist in associating a power offset (relative to P-CPICH power) to the HS-SCCH depending on the reported CQI value. The power allocated for HS-SCCH is derived from the CQI reported by the mobile in order to adapt the transmission power to radio conditions.
HS-SCCH Power Control is configured through a table that gives a power offset relative to P-CPICH for each CQI value (hsscchPcOffset parameter in HsdpaConfobject). If all the 30 values of this table are set to the same exact value, then the HS-SCCH Power Control is disabled, otherwise it is activated. The value of power offsets shown in the above table are the current recommended values.
3-70
September, 20063-70HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Congestion
#10817 VS.HsdpaPAOverload
PA overload
This counter gives the number of periods for which the total transmitted power for HSDPA exceeded 90% of the maximum cell power configured.
It allows to identify the cells overloaded
3-71
September, 20063-71HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Always On for HSDPA
3-72
September, 20063-72HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Principles
CELL_DCHCELL_DCH(DCH/HS(DCH/HS--DSCHDSCH))
CELL_FACHCELL_FACH(RACH/FACH)(RACH/FACH)
PMMPMM--idleidle
UL and DL Low Usage(HSDPA T1 expiry)
UL or DL Traffic
UL or DL
High Usage
UL and DL Inactivity(TRB on CELL_FACH T2 expiry)
UL and DL Low Usage(HSDPA T2 expiry)
For each user mapped on HSDPA, the RNC monitors the traffic in UL and DL.
DOWNSIZING STEP 1
• If UL and DL user traffic falls below the configured throughput threshold during timerT1ForHsdpa, the UE is moved to CELL_FACH.
DOWNSIZING STEP 2
• If UL and DL user traffic equal to zero during timerT2ForHsdpa, the RRC connection is released and the UE is moved to Idle Mode (PDP context is kept).
UPSIZING
• When in CELL_FACH, upsizing (back to CELL_DCH) is triggered as soon as UL or DL DCH buffer is above configured thresholds.
Always-On step 1 (downgrade) is supported but only towards Cell_FACH, using an asynchronous RB Reconfiguration. Once the reconfiguration has been performed, all RLs are deleted. If there is a CAC failure on FACH then the call is released.
Always-On upgrade is supported, coming from Cell_FACH. The RL is allocated first on the BTS. The RB is then reconfigured to HSDPA (if the cell supports HSDPA, else it is reconfigured to DCH) using an asynchronous RB Reconfiguration. If there is a CAC failure on HSDPA then the call is released.
3-73
September, 20063-73HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Activation
timerT1ForHsdpa
timerT2ForHsdpa
isAlwaysOnAllowed
preferredTransportTypeForAlwaysOn
RNC
DlRbSetConf UlRbSetConfDlUserService UlUserService AlwaysOnConf
AlwaysOnTimer
isAlwaysOnAllowed isAlwaysOnAllowed
disabled ����
degraded2AlwaysOnOnly ����
releaseOnly ����
true ����false ����
As in R99 isAlwaysOnAllowed must be set to TRUE so that AO is enabled At RNS level. For HSDPA the only supported mode for AO Step 1 is CELL_FACH. Consequently the parameter preferredTransportTypeForAlwaysOn has to be set to FACH when AO Step 1 and 2 are to be used for HSDPA. Otherwise, when HSDPA is configured to run on Release Only mode, FACH or DCH are both acceptable values.
The list of user services that are eligible to AO is given through the parameter isAlwaysOnAllowed in DlUserService and UlUserService objects. For the HSDPA DlUserService this parameter should be set to TRUE.
The parameter isAlwaysOnAllowed in DlRbSetConf and UlRbSetConf objects determines the behavior of each Radio Bearer when the always on downsize is triggered. It can take the following values:
• degraded2AlwaysOnOnly means that the downsize is allowed.
• ReleaseOnly means that there is no intermediate downsize.
• Disabled means that the Always On feature is disabled for this Radio Bearer.
For the HSDPA DlRbSetConf the parameter isAlwaysOnAllowed should be set to degraded2AlwaysOnOnly.
The recommended values for the parameters timerT1ForHsdpa and timerT2ForHsdpa are of 10s and 60s respectively.
3-74
September, 20063-74HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Always – On metrics
Downsizing step 2 vs downsizing step 1 (Source DlAsConfId) =
(# 1105 + #1106) / (#1101 +#1102)
Upsizing attempt (Target DlAsConfId) vs. downsizing step 1 (source DLAsconfid) =
(#1107 +#1108+ #1109 +#1110 ) / (#1101 +#1102)Available for HSDPA
Update since 4.1 : new screenings
Impacted by HSDPA
Included in global metric
Always-On feature allows to reduces or release the allocated resources when timeractivity expires
Metrics monitoring always-on are based on the following counters :• number of downsizing step 1 successes (#1101 for SRNC, #1102 for DRNC)
• number of downsizing step 1 unsuccesses (#1103 for SRNC, #1104 for DRNC)
• number of downsizing step 2 successes (#1105 for SRNC, #1106 for DRNC)
• number of upsize successes (#1107 for SRNC, #1108 for DRNC)
• number of upsize unsuccesses (#1109 for SRNC, #1110 for DRNC)
The metrics can be computed at RNC or cell level and are screened per DlAsConfId
3-75
September, 20063-75HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
HSDPA and Multi-Service
3-76
September, 20063-76HSDPA Performance Management
3FL12855AAAAWBZZA Ed 2
Principles
PS I/BPS I/BHSHS--DSCHDSCH
PS I/B + PS I/BPS I/B + PS I/BDCHDCH
CS + PS I/BCS + PS I/BDCHDCH
IDLEIDLEFACHFACH
CS setupPS setup
AO downgrade PS releasePS setupAO upgrade
PS release CS release
Multi-service (CS+PS or PS+PS or CS+PS+PS) is not served using HSDPA. There is an automatic switching to DCH (on the same cell).
Prior to the switching, CAC on DCH is performed as usual and if it is not possible to allocate the necessary resources on DCH, the incoming RAB is rejected.
When one of the RAB is released, the call is switched to HSDPA if only one PS I/B RAB remains. Prior to the switching, CAC on HSDPA is performed and the call is released if the CAC fails.
Transition to HSDPA is only applicable to the case where the primary cell of the active set supports HSDPA. If it does not support HSDPA, the call is mapped on DCH.
The call release is initiated either by the mobile or the network through a PDP context de-activation procedure, or by the RNC (Always-On step 2).
Always-On step 1 (downgrade) is supported but only towards Cell_FACH.
Always-On upgrade is supported, coming from Cell_FACH.
3-77
Student notes
3-78
Student notes
3-79
Student notes