HSDPA Performance Management

Alcatel-Lucent W-CDMA HSDPA Performance Management
3FL12855AAAAWBZZA Edition 2
TRAINING MANUAL
Alcatel-Lucent W-CDMA - HSDPA Performance Management

All rights reserved 2007, Alcatel-Lucent
Copyright 2007 by Alcatel-Lucent - All rights reserved Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent
All Rights Reserved 2007, Alcatel-Lucent HSDPA Performance Management - Page 1
Legal Notice
2
Switch Safety Warning
to notes view!
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-Lucents written permission, and must include all copyright and other proprietary notices. No Alcatel-Lucent W-CDMA All Rights Reserved Alcatel-Lucent 2007 other use Performance Management all or any part of its contents may be used, copied, disclosed or conveyed to HSDPA or transmission of 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 AlcatelLucent. 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 AlcatelLucent equipment and its operation.
Table of Contents
3
Switch to notes view!

Section 1: Introduction Section 2: Performance Management: Definitions and Methodology Summary Counters Counters: Definition Types of Counters and Period of Time Counter Specification: Collection Method Exercise Counter Locations: FddCell & RNC Counters Counter Locations: Reference FddCell Counters Counter Locations: Neighboring RNC Counters Counter Screening Counter Example: Number of RRC Connection Requests Metrics Metrics: Definition Metric Format Example: RRC Connection Success Example: RRC Connection Success Page with Lines for Student Notes Reports Report Definition Process Performance Management Process Page with Lines for Student Notes
Alcatel-Lucent W-CDMA Section 3: Management HSDPA PerformanceHSDPA KPIs
All Rights Reserved Alcatel-Lucent 2007
Page
7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
Radio Resource Allocation HSDPA Channel Operation HSDPA Channel Configuration OVSF Code Tree Reservation NodeB Role Interface Configuration ATM VCC numbering UE Categories UE Capabilities and Max Bit Rates 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 Procedure description Parameters Accessibility Network Retainability Performance Total number of RABs Abnormal Release Caused by RL Failure Call Abnormal Release Call Drop Rate at RNC Level Call Drop Rate per RAB established Call drop rate per released calls - cell level Number of drops per minute of RAB Average Number of calls Uplink/ Downlink PS Traffic
7 8 9 10 11 12 13 14 15 16 17 19 20 21 22 23 24 25 26 27 28 29 31 32 33 34 35 37 38 39 41 42
Table of Contents [cont.]

4
Page Section to notes [cont] Switch 3: HSDPA KPIsview! Throughput DL per Combined DL/UL max bit rate at RNC level HSDPA DL Kbytes ( SDU payload) First Stage Principles Second Stage Principles SPI Configuration Traffic CQI Reporting Principles CQI Modification Principles DL HSDPA radio traffic MAC-HS throughput and Cell throughput Mac-d Throughput per cell HSDPA Power Management Principles First Tx Power Allocation Principles Retransmission Principles HSDPA Retransmission rate 43 44 46 47 48 49 52 53 54 55 56 58 59 60 61
Course Objectives
5
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.
Course Objectives [cont.]

6
This page is left blank intentionally
About this Student Guide

7
Conventions used in Switch to notes view! this guide

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

If you want further information you can refer to the following: Technical Practices for the specific product Technical support page on the Alcatel website: http://www.alcatel-lucent.com
About this Student Guide [cont.]

8
Self-Assessment of Objectives
9
Contract number : Course title :
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 to notes view!
Dates from : Location : to :
Client (Company, Center) : Language : Switch
Number of trainees : Surname, First name :
Did you meet the following objectives ? Tick the corresponding box Please, return this sheet to the trainer at the end of the training
Yes (or globally yes) No (or globally no)
Instructional objectives 1 To be able to define the counters, the metrics and explain how to use the metrics 2
Comments
To be able to describe HSDPA main metrics: Describe HSDPA Power Control Metrics Alcatel-Lucent W-CDMA All Explain Always On KPIs for HSDPA Rights Reserved Alcatel-Lucent 2007 HSDPA Performance Management Understand the main HSDPA accessibility, Traffic and mobility metrics.
Self-Assessment of Objectives [cont.]

10
Other comments
Thank you for your answers to this questionnaire
Performance Management: Definitions and Methodology

Section 2
3FL12855AAAAWBZZA Ed 2 HSDPA Performance Management
September, 2006
2-1
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-2
September, 2006
2-2
Content
Counters
> > > > > > > > > > > > > >
2-3
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 Requests Metrics: Definition Metric Format Example: RRC Connection Success Report Definition Performance Management Process
3FL12855AAAAWBZZA Ed 2 HSDPA Performance Management September, 2006
Metrics
Reports Process
2-3
Student notes
2-4
Page Summary Counters Counters: Definition Types of Counters and Period of Time Counter Specification: Collection Method Exercise Counter Locations: FddCell & RNC Counters Counter Locations: Reference FddCell Counters Counter Locations: Neighboring RNC Counters Counter Screening Counter Example: Number of RRC Connection Requests Metrics Metrics: Definition Metric Format Example: RRC Connection Success Example: RRC Connection Success Page with Lines for Student Notes Reports Report Definition Process Performance Management Process Page with Lines for Student Notes End of Module
2-5 3FL12855AAAAWBZZA Ed 2 HSDPA Performance Management
7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
September, 2006
2-5

> The subscriber evaluates the performance/quality of service of the network through 4 criteria.
Criteria 1. Extend of coverage Possible assessment / monitoring > Cannot be assessed by the system. > Can be assessed by: Air interface measurements, Subscriber complaints. > 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. 4. Call Drop > Can be assessed by the system through monitoring.
2. Successful Call Set Up Rate
3. Quality
2-6
September, 2006
2-6
Summary
!
To measure and analyze the performance of a network one needs: 1. Data collection:
1. Counters 2. Metrics:
Criteria Possible assessment / monitoring > Cannot be assessed by the system. 1. Coverage > Can be assessed by: Air interface measurements, Subscriber complaints. > 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. 4. Call Drop 2-7 > Can be assessed by the system through monitoring. 3FL12855AAAAWBZZA Ed 2 HSDPA Performance Management September, 2006
> {counter1, counter2, }
> f(counter1, counter2, )

>
2. Call Set Up
3. Measurements 4. Reports
3. Voice Quality
2. Process and methodology 3. And experience!
2-7
Counters
September, 2006
2-8
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.
2-9
September, 2006
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-9
Types of Counters and Period of Time

Granularity Period
Initiation
X1
X2
X3
X4
X5
Xi
Xn
Avg Min Max NbEvt Cumul

2-10 3FL12855AAAAWBZZA Ed 2 HSDPA Performance Management September, 2006
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-10
Counter Specification: Collection Method
Counter type Cumulative Value Load
Collection method CC GAUGE DER SI
2-11
September, 2006
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-11
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
2-12
September, 2006
Time of RAB allocation =
2-12
Counter Locations: FddCell & RNC Counters Core

Iu Serving RNC Iur Drift RNC
> 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).
2-13
September, 2006
2-13
Counter Locations: Reference FddCell Counters Core

Iu Serving RNC Iur Drift RNC
> 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).
2-14
Counter Locations: Neighboring RNC Counters

Core
Iur Iu Serving RNC Drift RNC
> 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).
2-15
September, 2006
2-15
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-16
Counter Example: Number of RRC Connection Requests

A. B. C. D. E. F. G. H. This measurement provides the number of RRC connection requests screened by establishment cause. CC Reception by the RNC of a RRC CONNECTION REQUEST message. An integer value for each establishment cause. Screening: Sub-counter # i --> Establishment cause # i as in TS 25.331 (c.f. Annex) RRC.AttConnEstab.<0..31> FDDCell When vendor specific, the VS prefix is added e.g. VS.RadioLinkSetupSuccess
Valid for circuit switched and packet switched traffic. 3GPP specified counter Alcatel-Lucent #0409 Counter introduced in V 2.0e Message flow UE RRC connection request RRC connection setup RRC connection setup complete RRC Connection Establishment, network accepts RRC connection
I.
UTRAN
2-17
September, 2006
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-17
Metrics
September, 2006
2-18
Metrics: Definition
Composed of one or several counters
Metric ={counter1, counter2, } Metric = f (counter1, counter2, )

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-19
Metric Format
Metric Id Metric history Cell NC Metric Name Applicability Group of cells RNC Network
Metric formula
Metric formula with counter name, or metric id with specific screenings used Counter: #Counter Id = Name of the counter [all possible screenings]
Associated counters
Comment
Optional: Comment or monitoring recommendation
2-20
September, 2006
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-20
Example: RRC Connection Success

RRC001 Metric history Cell NC RRC connection success Applicability Group of cells RNC Network
Meaning Metric formula Associated Counters
Number of RRC connection success (sum of all causes)
(RRC.SuccConnEstab [RRC screenings] )

#0403 RRC.SuccConnEstab (RRC establishment causes ) Necessary for the calculation of RRC Connection success rate, this metric allows also to see the call distribution in terms of success 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
2-21
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-21
UTRAN metric families
RNC Panel
UTRAN Call set up success indicator RRC connection success rate (calls only)
Accessibility
SCCP connection success rate Security mode command success RAB establishment success rate Voice Call Drop rate at RNC
Retainability
Video Call Drop rate at RNC PS call drop rate at RNC Global 3G-2G CS HHO success rate 3G-2G HHO CS preparation success rate 3G-2G HHO CS execution failure rate (2G side) 3G-2G HHO CS execution failure rate (3G side) 3G-2G HHO PS execution failure rate (2G) Mean Sector Per User
Mobility
Congestion Quality
Mean RB Blocking rate BLER PS BLER CS Average number of Voice calls per day Average number of Video calls per day UL PS Traffic per RNC DL PS Traffic per RNC
Traffic
2-22
September, 2006
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-22
Student notes
2-23
Reports
September, 2006
2-24
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 specific e.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
2-25
September, 2006
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 its 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-25
Process
September, 2006
2-26
Performance Management Process

Monitoring setup
Data retrieving definition Engineering Criteria definition
Counters Metrics Reports Hourly / busy hours, daily, weekly Alarm detection NEs (RNCs, FddCell, )
Tools (PrOptima, scripts)
Observation
Monitoring process
!
Analysis Correction Validation O&M O&M
2-27
September, 2006
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 doesnt fit the required performances e.g.: Performances not in accordance with the operators 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 Correction proposal Analysis of the problem 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 Subscriber complaints And they are collected and showed out using: Protocol analyzers Optimization and monitoring tools Trace functions NE counters
2-27
Student notes
2-28
End of Module
2-29
September, 2006
2-29
HSDPA KPIs
Section 3
September, 2006
3-1
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-2
September, 2006
3-2
Contents
> > > > > > > > > > > > > > > > > > > > > > > > >
3-3
Introduction Whats 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
September, 2006
3-3
Student notes
3-4
3-5
September, 2006
3-5
Page Iub Bandwidth Limitation Iub Bandwidth Limitation - Principle Iub Bandwidth Limitation F. A. Downlink BLER PS Uplink BLER PS Uplink BLER PS Uplink BLER PS HS-SCCH Power Control Activation Congestion Congestion Principles Activation Always On metrics Always On metrics Principles Principles Principles Principles 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79

Whats HSDPA?
September, 2006
3-6
Radio Resource Allocation

TS UM R4
Dedicated Channel Dedicated Channel Dedicated Channel
A DP HS
Shared Channel
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-7
HSDPA Channel Operation

OVSF codes UE #1 UE #2 UE #3 UE #4 UE #5 2ms
HS-PDSCH
Data Transfer (PS I/B)
HS-SCCH
Downlink Transfer Information (UEid, OVSF,...)
DPCH
Upper Layer Signaling
DPCH
Upper Layer Signaling
HS-DPCCH
Feedback Information (ACK/NACK, CQI)
HS-DPCCH
Feedback Information (ACK/NACK, CQI)
September, 2006
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-8
HSDPA Channel Configuration

DTCH
Logical Channels
DCCH
DCCH
DTCH
Transport Channels
DCH DCH DCH HS-DSCH
Layer 1
Physical Channels
DPCH
DPDCH
DPCCH
HS-PDSCH HS-SCCH HS-DPCCH
3-9
September, 2006
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-9
OVSF Code Tree Reservation

SF4 SF8 SF16 SF32 SF64 HS-SCCH SF128 HS-PDSCH
HSDPA
SF4 SF8 SF16 SF32 SF64 SF128 SF256

3-10
HSDPA + R4
HS-PDSCH
... ... ...

cmCH
HS-SCCH
...
September, 2006
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-10
NodeB Role
RNC Capacity Request Control FP Capacity Allocation Control FP Data FP
Flow Control
Dynamically fills the Queues of each UE
Queue IDs
Scheduler
Fills the TTIs with one or more users based on their priority and feedback information
HARQ Processes
Retransmissions handling, TFRC selection, AMC
Feedback Reception
Radio Transmission
3-11
September, 2006
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-11
Interface Configuration
INVccGroup
VCC OAM VCC NodeBCP VCC CCP VCC DS traffic VCC NDS traffic VCC HSDPA traffic VPi/VCi VPi/VCi VPi/VCi
RNC
VPi/VCi/PathId/QoSId VPi/VCi/PathId/QoSId VPi/VCi/PathId/QoSId
OAM CP CCP AAL5 ATM PCM
DS NDS HSDPA AAL2
New VCC New ATM Profile New QoSId
PCM link (1 up to 8 with IMA)
3-12
September, 2006
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-12
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-13
September, 2006
3-13
UE Categories
HS-DSCH Category Category 1 Category 2 Category 3 Category 4 Category 5 Category 6 Category 7 Category 8 Category 9 Category 10 Category 11 Category 12 HS-PDSCH Max Number 5 5 5 5 5 5 10 10 15 15 5 5 Inter-TTI Min Interval 3 3 2 2 1 1 1 1 1 1 2 1 Modulation QPSK & 16-QAM QPSK & 16-QAM QPSK & 16-QAM QPSK & 16-QAM QPSK & 16-QAM QPSK & 16-QAM QPSK & 16-QAM QPSK & 16-QAM QPSK & 16-QAM QPSK & 16-QAM QPSK only QPSK only Max Peak Rate 1.2 Mbps 1.2 Mbps 1.8 Mbps 1.8 Mbps 3.6 Mbps 3.6 Mbps 7.3 Mbps 7.3 Mbps 10.2 Mbps 14.4 Mbps 0.9 Mbps 1.8 Mbps
QPSK mandatory for HSDPA capable UE 16-QAM optional

3-14
September, 2006
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-14
UE Capabilities and Max Bit Rates

Category 6 UE CQI Mapping Table
CQI Value 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ... 29 30 3-15 1 1 1 1 1 1 2 2 2 3 3 3 4 4 5 5 ... 5 5 HS-PDSCH Number RLC Throughput out of range 0 kbps 0 kbps 0 kbps 0 kbps 144 kbps 144 kbps 144 kbps 288 kbps 288 kbps 432 kbps 576 kbps 720 kbps 864 kbps 1008 kbps 1296 kbps 1440 kbps ... 3024 kbps 3024 kbps QPSK QPSK QPSK QPSK QPSK QPSK
s oftCQI 20 25 S oft CQI vs C/I - P e des trian_a 1 RX
Modulation
QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK 16-QAM ... 16-QAM 16-QAM
15
10 -10
-8
-6
-4
-2
0 C/I (dB)
10
Target BLER 10%

September, 2006
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-15
Activation Flags
RNC/RadioAccessService
isHsdpaAllowed (TRUE, FALSE)
RNC/NodeB/FDDCell
hsdpaActivation (TRUE, FALSE)
0..* 0..3000
RNC
BTSEquipment/BTSCell
hsdpaResourceActivation (TRUE, FALSE)
BTSEquipment
0..200
1..1
1..12
NodeB
RadioAccessService
BTSCell
1..6
FDDCell
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 MOIs required 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-16
Main Parameters
MCPA Power
... ... ...
RNC/RadioAccessService/HsdpaCellClass
SHO maximunNumberOfUsers [0..50] numberOfHsPdschCodes [0..15] numberOfHsScchCodes [0..4] DPCH minimumPowerForHsdpa [0..50]
HS-SCCH
BTSEquipment/BTSCell/HsdpaConf
HS-PDSCH HS-SCCH cmCHs dchPowerMargin [0..100] harqType (mirType, pirType, ccType) harqNbMaxRetransmissions [0..31] hsdpaResourceId [0..5]
HS-PDSCH
3-17
September, 2006
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-17
...
Accessibility KPIs
3-18
September, 2006
3-18
Accessibility Flow Diagrams

UE RRC connection Node B RNC SGSN RRC Connection Request Radio Link Setup Request Radio Link Setup Response RRC Connection Setup RRC Connection Complete Measurement Control Init Direct Transfer SCCP connection req. SCCP connection confirm Security mode command Command id Security mode complete RAB assignment req. RAB establsht S.R.L.R. Procedure Radio Bearer Setup Radio Bearer Setup Complete
SCCP conn.
Security mode
Security mode command Security mode complete
RAB assignment resp.

September, 2006
3-19
3-19
Principles
RAB Request
RNC
NO
Traffic Class = I/B?
YES
hsdpaMaxNumberUser (BTSEquipment ) hsdpaMaxUserPerNodeB (BTSEquipment )
Multi-Service?
YES
NO
RNC
HSDPA UE?
NO
RadioAccessService
YES
HsdpaCellClass
Primary Cell = HSDPA Cell?
NO
YES
maximunNumberOfUsers (HsdpaCellClass )
HSDPA RAB
3-20
R99 RAB
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-20
HSDPA CAC success rate
#0957 / (#0957 + #0958 )
3-21
September, 2006
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-21
RAB Assignment Flow

#0621 RAB assignment request (UA04.0)
UE
Node B
RNC
CN
#xxx ? RAB assignment req. #0631 RB Establishment Unsuccess
SRLR procedure RAB establsht Radio Bearer Setup Radio Bearer Setup Complete
Internal RRM decision to assign resources #0622 RAB assignment success per req RAB type #0623 RAB assignment success per granted RAB type
September, 2006
RAB assignment resp. #0601 RB setup success #0602 RB setup unsuccess

#601: Number of successful Radio-bearer establishments 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-22
RAB Assignment Success Rate

Voice RAB Voice RAB Assignment = Assignment = success rate success rate Video RAB Video RAB Assignment = Assignment = success rate success rate
(#0622.[1]) //(#0621.[1]) (#0622.[1]) (#0621.[1])
(#0622.[2]) //(#0621.[2]) (#0622.[2]) (#0621.[2])
PS RAB PS RAB Assignment = (#0622.[0, 5-42]) // (#0621.[0, 5-42]) Assignment = (#0622.[0, 5-42]) (#0621.[0, 5-42]) success rate success rate
3-23
September, 2006
This metric is Impacted by HSDPA but can not be computed for HSDPA as HSDPA RAB is not requested by the Core Network .
3-23
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])
3-24
September, 2006
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-24
RB Set-up success rate

RB Setup success rate = RB setup success / RB set up 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]
3-25
September, 2006
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-25
Traffic Segmentation
RNC
RRC Connection Request (AS release indicator = R4 or absent)
HSDPA cell
RRC Connection Setup (Redirection to F2)
HSDPA cell
RRC Connection Setup (Redirection to F1)
R4 cell
R4 cell
RRC Connection Request (AS release indicator = R5)
3-26
September, 2006
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-26
Establishment Cause
Suitable layer DCH DCH HSDPA HSDPA HSDPA DCH DCH HSDPA HSDPA DCH or HSDPA (i.e. no re-direction) DCH or HSDPA (i.e. no re-direction) DCH or HSDPA (i.e. no re-direction) HSDPA DCH or HSDPA (i.e. no re-direction) HSDPA DCH or HSDPA (i.e. no re-direction) DCH or HSDPA (i.e. no re-direction) DCH or HSDPA (i.e. no re-direction) DCH or HSDPA (i.e. no re-direction) DCH or HSDPA (i.e. no re-direction) DCH or HSDPA (i.e. no re-direction)
Multi-carrier HSDPA traffic segmentation Procedure description
Originating Conversational Call Originating Streaming Call Originating Interactive Call Originating Background Call Originating Subscribed traffic Call Terminating Conversational Call Terminating Streaming Call Terminating Interactive Call Terminating Background Call Emergency Call Inter-RAT cell re-selection Inter-RAT cell change order Registration Detach Originating High Priority Signalling Originating Low Priority Signalling Call re-establishment CS case Call re-establishment PS case Terminating High Priority Signalling Terminating Low Priority Signalling Terminating cause unknown
3-27
September, 2006
Static mapping perfomed by the RNC between the Establishment Cause and the suitable layer (DCH or HSDPA):
3-27
Multi-carrier HSDPA traffic segmentation Parameters

Parameter (Object) Class Range & Unit Value
isRedirectionForTrafficSegmentation (FddCell.InterFreqHho)
C3
Boolean
True
isRedirectionBasedOnEstablishmentC ause (FddCell.InterFreqHho)
C3
Boolean
False
3-28
September, 2006
*The twin cell is considered HSDPA if declared such as the parameter under FddCell hsdpaActivation is equal to True. **The value of isRedirectionBasedOnEstablishmentCause is taken into account only if isRedirectionForTrafficSegmentation is set to true.
3-28
Accessibility
Number of R5 mobiles outgoing redirections toward a HSDPA layer 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
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 nonHSDPA 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-29
Retainability
3-30
September, 2006
3-30
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-31
September, 2006
3-31
Total number of RABs

bearer ccess a re Radio ent procedu m assign
UE Node B RNC MSC RANAP/RAB assigt req () () RRC Connection Setup RRC Connection Complete #0622 RAB establisht success RAB assigt resp*
*RANAP/RAB assigt resp.: can be several responses. Ed 2 3FL12855AAAAWBZZA

3-32 HSDPA Performance Management
September, 2006
#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 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). Screening by RAB Type. Screening: by requested RAB Type.
3-32
Abnormal Release Caused by RL Failure

#0533 Iu abnormal release request CS #0534 Iu abnormal release request PS
Node B
RNC
CN
Radio Link Failure Indication
Iu Release Req Iu Release Command
Radio Link Deletion Req Radio Link Deletion Resp
#0505 Iu release command CS #0506 Iu release command PS #0013 Dropped Last Radio Links Iu Release Complete
3-33
September, 2006
#0013: Number of dropped calls on last radio-link release. 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-33
Call Abnormal Release
Node B
RNC
CN #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)
Issue detected
Iu Release Request Iu Release Command Radio Link Deletion Request
Radio Link Deletion Response
Iu Release Complete
#0505 Iu release command CS #0506 Iu release command PS
3-34
New counter Counters screenings updated No change
#0544 Iu release complete CS #0545 Iu release complete PS 3FL12855AAAAWBZZA Ed 2 HSDPA Performance Management September, 2006
#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 Iu release 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-34
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-35
September, 2006
3-35
Call Drop Rate at RNC Level

#0533.[1,5,9,10,15,16,17,18] Voice call drop rate = Voice call drop rate =
#0622.[1]
#0533.[0]
Video call drop rate = Video call drop rate =
#0622.[2]
Data call Data call = drop rate* drop rate*

*RAB drop rate
3-36
#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]
#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 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-36
Update since 4.1 : new screenings
Call Drop Rate per RAB established

Call drop Rate = Number of drops / Number of RAB success 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,550])
HSDPA Call drop rate = (#0547[27] / (#0623 .[43-50]
3-37
September, 2006
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 conditions : O&M intervention Repeated integrity check failure Radio connection lost Relocation timeout (corresponding to TrelocoverallExpiry and TrelocCompleteExpiry) Unspecified failure timeout of
3-37
Call drop rate per released calls - cell level

Call drop rate per released calls = Number of drops / (Number of normaly and 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 requests PS + Downsizing Step 2 ( PS Dl ASConfid) + Radio Bearer release success ( PS + FACH) ) = #0547 ( PS Dl Asconfid) / ( #0547 ( PS DlAsConfId) + #1105 ( PS DlAsConfId) + #0608 ( PS + Fach) )
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-38
Number of drops per minute of RAB

Number of drops per mn of RAB = Iu abnormal release requests / Allocation time of the RAB 60*10* ( VS.IuAbnormalReleaseRequestCs/PS [CS/PS DlAsConfId screenings] / VS.DlAsConfIdAvgNbrEstablished.CUM [CS/PS DlAsConfId screenings])
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 is based on #0546 / #0547 Iu abnormal release requests CS/ PS at reference cell level #0660 VS.DlAsConfIdAvgNbrEstablished: Average number of DlAsConfIds established per iRNC at reference cell level
3-39
Traffic
3-40
September, 2006
3-40
Average Number of calls
Update since 4.1 : new screenings, new counter at cell level
> 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

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]
Average number of HSDPA calls = #0627.Avg[43-50]
> 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 = #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 = #0660.Avg[27]

3-41
Uplink/ Downlink PS Traffic
Available for HSDPA 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]
3-42
September, 2006
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-42
Throughput DL per Combined DL/UL max bit rate at RNC level
Available for HSDPA
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)]
3-43
September, 2006
Throughput metrics are necessary to assess the quality of the network and can be correlated to congestion results These 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-43
HSDPA DL Kbytes ( SDU payload)
1459.RabPsIBHsdpa_32U+ 1459.RabPsIBHsdpa_64U+ 1459.RabPsIBHsdpa_128U+ 1459.RabPsIBHsdpa_384U
3-44
September, 2006
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-44
NodeB Scheduler
3-45
September, 2006
3-45
First Stage Principles

Credits Computation QId0 QId1 QIdN QId0 QId1 QIdN Function of: QIds number PQ weight (priority) number of active PQs total bandwidth
PQ0
PQ15
Cost Function Evaluation already transmitted bits credits
PQ0 COST
PQ15 COST
COST =
Lowest Cost PQ Selection
3-46
September, 2006
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-46
Second Stage Principles

UE Capabilities Available Power & Codes ACK/NACK/CQI Previously Transmitted PDUs
Retransmissions First QId0 New Transmissions QId1 QIdN
Round Robin
Fair
CQI
Proportional Fair
UE #0 power codes number of bits

3-47
UE #1 power codes number of bits

UE #N power codes number of bits

September, 2006
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-47
SPI Configuration
RNC
QId0 QId1
QIdN
QId0 QId1
QIdN
RadioAccessService
Second Stage
HsdpaRncConf
PQ0
PQ15
First Stage
SpiConfiguration SpiConfiguration SpiConfiguration
NodeB Scheduler
UMTS TRAFFIC CLASS OLS Background Interactive gold silver bronze
3-48
priorityLevel (SpiConfiguration) backgroundSpi (SpiConfiguration) interactiveSpi (SpiConfiguration)
15 7 0
15 7
September, 2006
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-48
Traffic
Average number of scheduled UE
#10804.CUM / #10818
3-49
September, 2006
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-49
Traffic
HSDPA activity rate
During one hour (VS.HsdpaTTIsUsed*0.0020) / 3600.0)
3-50
September, 2006
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-50
Adaptive Modulation and Coding
3-51
September, 2006
3-51
CQI Reporting Principles

P-CP I HS-D PCC H
CQI 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 OVSF 1 1 1 1 1 1 2 2 2 3 3 3 4 4 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 TBS out of range 137 173 233 317 377 461 650 792 931 1262 1483 1742 2279 2583 3319 3319 3319 3319 3319 3319 3319 3319 3319 3319 3319 3319 3319 3319 3319 3319 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11 -12 -13 -14 -15
CH
PHS-PDSCH = PP-CPICH + +
2ms
Target BLER 10%
3-52
September, 2006
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 PCPICH. 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-52
CQI Modification Principles

HS-DPCCH demodulation UL Synchronization failure detection
CQIreported CQI Averaging CQIaveraged
CQI adjustment based on BLER and DTX CQIprocessed Scheduler CQI update due to: Power limitation Codes limitation MAC-hs buffer occupancy MAC-d PDU size CQIapplied
3-53
September, 2006
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-53
HSDPA specific traffic metrics DL HSDPA radio traffic

> It is based on the counter
#10809 VS.HsdpaTxDataBitsSchedTotal
New 4.2
> This metric is at cell level and its unit is in Kbit
3-54
September, 2006
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-54
HSDPA specific traffic metric MAC-HS throughput and Cell throughput
New 4.2
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)
3-55
September, 2006
Throughput from Node B or cell perspective are based on the total number of data bits (transport block size) first transmitted or with retransmission 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-55
Mac-d Throughput per cell
New 4.2
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)
3-56
September, 2006
3-56
Quality
3-57
September, 2006
3-57
HSDPA Power Management Principles

MCPA Power UE selected PHSDPA Ptemp = PHSDPA PHS-SCCH HS-SCCH DCH margin DCH No Ptemp > 0?
HS-DSCH
CmCH
Yes Go to Next Step UE not scheduled

3-58
September, 2006
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 HSSCCH. 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-58
First Tx Power Allocation Principles

UE selected (Ptemp > 0)
PHS-DSCH = PP-CPICH + + (CQI)
PHS-DSCH < Ptemp? Yes RP = 0 CQIRP = CQI
PHS-DSCH = PP-CPICH + No RP = round(10.log(Ptemp / PHS-DSCH)) CQIRP = CQI + RP
ncodes = f(CQIRP)
Yes
CQIRP > 0?
No
UE not scheduled Go to Next Step

In case there doesnt 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-59
Retransmission Principles
UE selected (retransmission nb > 0)
1st Tx Power < Remaining Power?
No
No Yes UE scheduled Transmitted Pwr = 1st Tx power Another UE scheduled in TTI?
Yes UE not scheduled
UE scheduled Transmitted Pwr = Remaining power

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-60
HSDPA Retransmission rate
(#10809 - #10808) / #10808
3-61
September, 2006
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-61
Iub Bandwidth Limitation

Baseline : no congestion management => poor Iub link utilization
Aggregate Iub Throughput
3-62
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 NodeB transmission buffer. The HS-DSCH data transfer procedure in which the RNC sends the MAC-d PDUs grouped 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.
16 16:53 : 16:54 54 : 16:54 14 :5 :34 16 4 : 16:55 54 : 16:55 14 :5 :35 16 5 : 16:56 55 : 16:56 15 : 16:56 35 : 16:57 55 : 16:57 15 : 16:57 35 :5 :55 16 9 : 17:59 26 : 17:00 46 :0 :06 17 0 : 17:00 26 : 17:01 46 : 17:01 06 : 17:01 26 : 17:02 46 : 17:02 06 :0 :26 17 2 : 17:03 47 : 17:03 08 :0 :28 17 3 : 17:04 48 : 17:04 08 : 17:04 28 : 17:05 48 : 17:05 08 : 17:05 29 : 17:06 49 : 17:06 09 : 17:06 30 : 17:07 50 : 17:07 10 :0 :30 17 7 : 17:08 50 : 17:08 10 :0 :30 17 8 :0 :50 9: 10
14:03:30 14:04:04 14:04:38 14:05:13 14:05:47 14:06:21 14:06:55 14:07:29 14:08:03 14:08:37 14:09:11 14:09:45 14:10:19 14:10:53 14:11:27 14:12:01 14:12:34 14:13:08 14:13:39
10000 9000 8000 7000 6000 5000 4000 3000 2000 1000 0
cells/sec
Iub limitation handling : 100% Iub efficiency

cells/sec 10000 9000 8000 7000 6000 5000
Time
Voice Video-telephony : QoS 0 Data (R99) : QoS 1 Data (HSDPA) : QoS 2
4000 3000 2000 1000 0
Time
September, 2006
3-62
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-63
September, 2006
Control of Iub Bandwidth at ATM level is not efficient ATM Discard is not efficient (corrupted FP frame waste bandwith) ATM Discard doesnt 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 Converter (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 the PC (for Iub) and the PMC RAB are not in the same RNC !
3-63
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-64
Downlink BLER PS
#1462.[0,3,7,8,9,10,13,14,16] BLER PS = BLER PS = #1461.[0,3,7,8,9,10,13,14,16]
BLER PS BLER PS at 8kbps at 8kbps
# 1462.[9,13,14]
# 1461.[9,13,14]
# 1462.[0,7,8]
# 1461.[0,7,8]
# 1462.[3,16]
# 1461.[3,16]
# 1462.[10]
# 1461.[10]
3-65
September, 2006
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-65
Uplink BLER PS
#1444.[0,3,7,8,9,10,13,14,16] BLER PS = BLER PS = #1451+1444.[0,3,7,8,9,10,13,14,16]
3-66
September, 2006
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 coordinated transport channels, the frames of each subflow are not counted independently. The PDU and SDU counters are incremented only once for each set of frames received or 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 empty frame. Empty frames are being counted for BLER reason (Q01168175). For bearers where RLC is in transparent mode, this counter also includes received frames that contain 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-66
Student notes
3-67
Congestion
3-68
September, 2006
3-68
HS-SCCH Power Control Activation
P-CP I HS-S CC H
CH
CQI 17 89 10 12 13 30
Power Offset 0 dB -3 dB -5 dB -8 dB
BTSEquipment
distance BTSCell
HS-SCCH to P-CPICH Power Offset
HsdpaConf
hsscchPcOffset (HsdpaConf)
3-69
September, 2006
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 HsdpaConf object). If all the 30 values of this table are set to the same exact value, then the HSSCCH Power Control is disabled, otherwise it is activated. The value of power offsets shown in the above table are the current recommended values.
3-69
Congestion
PA overload
#10817 VS.HsdpaPAOverload
3-70
September, 2006
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-70
Always On for HSDPA
3-71
September, 2006
3-71
Principles
UL and DL Low Usage (HSDPA T1 expiry) UL and DL Inactivity (TRB on CELL_FACH T2 expiry)
CELL_DCH
(DCH/HS-DSCH) (DCH/HS-
UL or DL High Usage
CELL_FACH
(RACH/FACH)
PMM-idle PMM-
UL and DL Low Usage (HSDPA T2 expiry) UL or DL Traffic
3-72
September, 2006
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-72
Activation
RNC
DlUserService
UlUserService
DlRbSetConf
UlRbSetConf
AlwaysOnConf isAlwaysOnAllowed preferredTransportTypeForAlwaysOn
isAlwaysOnAllowed
isAlwaysOnAllowed
true false
disabled degraded2AlwaysOnOnly releaseOnly AlwaysOnTimer timerT1ForHsdpa timerT2ForHsdpa
3-73
September, 2006
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-73
Always On metrics
Downsizing step 2 vs downsizing step 1 (Source DlAsConfId) = (# 1105 + #1106) / (#1101 +#1102)
Impacted by HSDPA Included in global metric
Upsizing attempt (Target DlAsConfId) vs. downsizing step 1 (source DLAsconfid) = (#1107 +#1108+ #1109 +#1110 ) / (#1101 +#1102)
Available for HSDPA
3-74
September, 2006
Always-On feature allows to reduces or release the allocated resources when timer activity 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-74
HSDPA and Multi-Service
3-75
September, 2006
3-75
Principles
PS I/B + PS I/B DCH
CS + PS I/B DCH
PS setup
PS release
CS release
CS setup
PS I/B HS-DSCH HS-
AO downgrade
AO upgrade
PS setup
PS release
FACH
IDLE
3-76
September, 2006
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-76
Student notes
3-77
Student notes
3-78
Student notes
3-79

HSDPA Performance Management

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

HSDPA Performance Management

Hochgeladen von

Copyright:

Verfügbare Formate

Alcatel-Lucent W-CDMA HSDPA Performance Management

Alcatel-Lucent W-CDMA - HSDPA Performance Management

Switch Safety Warning

All Rights Reserved 2007, Alcatel-Lucent HSDPA Performance Management - Page 2

Switch to notes view!

All Rights Reserved 2007, Alcatel-Lucent HSDPA Performance Management - Page 3

Table of Contents [cont.]

Alcatel-Lucent W-CDMA HSDPA Performance Management

All Rights Reserved Alcatel-Lucent 2007

All Rights Reserved 2007, Alcatel-Lucent HSDPA Performance Management - Page 4

Switch to notes view!

Welcome to HSDPA Performance Management

After successful completion of this course, you should understand :

Alcatel-Lucent W-CDMA HSDPA Performance Management

All Rights Reserved Alcatel-Lucent 2007

All Rights Reserved 2007, Alcatel-Lucent HSDPA Performance Management - Page 5

Course Objectives [cont.]

Switch to notes view!

Alcatel-Lucent W-CDMA HSDPA Performance Management

All Rights Reserved Alcatel-Lucent 2007

This page is left blank intentionally

All Rights Reserved 2007, Alcatel-Lucent HSDPA Performance Management - Page 6

About this Student Guide

Conventions used in Switch to notes view! this guide

Alcatel-Lucent W-CDMA HSDPA Performance Management

All Rights Reserved Alcatel-Lucent 2007

Where you can get further information

All Rights Reserved 2007, Alcatel-Lucent HSDPA Performance Management - Page 7

About this Student Guide [cont.]

Switch to notes view!

Alcatel-Lucent W-CDMA HSDPA Performance Management

All Rights Reserved Alcatel-Lucent 2007

This page is left blank intentionally

All Rights Reserved 2007, Alcatel-Lucent HSDPA Performance Management - Page 8

Contract number : Course title :

Client (Company, Center) : Language : Switch

Number of trainees : Surname, First name :

All Rights Reserved 2007, Alcatel-Lucent HSDPA Performance Management - Page 9

Self-Assessment of Objectives [cont.]

Switch to notes view!

Alcatel-Lucent W-CDMA HSDPA Performance Management

All Rights Reserved Alcatel-Lucent 2007

Thank you for your answers to this questionnaire

All Rights Reserved 2007, Alcatel-Lucent HSDPA Performance Management - Page 10

Performance Management: Definitions and Methodology

3FL12855AAAAWBZZA Ed 2 HSDPA Performance Management

> Define the metrics

> Explain how to use the metrics

Table of Contents [cont.]

2. Successful Call Set Up Rate

3FL12855AAAAWBZZA Ed 2 HSDPA Performance Management

This page is left blank intentionally

> {counter1, counter2, }

> f(counter1, counter2, )

2. Process and methodology 3. And experience!

3FL12855AAAAWBZZA Ed 2 HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2 HSDPA Performance Management

Types of Counters and Period of Time

Avg Min Max NbEvt Cumul

Counter Specification: Collection Method

Counter type Cumulative Value Load

Collection method CC GAUGE DER SI

3FL12855AAAAWBZZA Ed 2 HSDPA Performance Management