120
HSDPA Performance Management - Page 1 All Rights Reserved © 2007, Alcatel-Lucent All rights reserved © 2007, Alcatel-Lucent Alcatel-Lucent W-CDMA - HSDPA Performance Management Alcatel-Lucent W-CDMA HSDPA Performance Management TRAINING MANUAL 3FL12855AAAAWBZZA Edition 2 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

HSDPA Performance Management

Embed Size (px)

Citation preview

Page 1: HSDPA Performance Management

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

All rights reserved © 2007, Alcatel-Lucent

Alcatel-Lucent W-CDMA - HSDPA Performance Management

Alcatel-Lucent W-CDMAHSDPA Performance

Management

TRAINING MANUAL

3FL12855AAAAWBZZAEdition 2

Copyright © 2007 by Alcatel-Lucent - All rights reservedPassing on and copying of this document, use and

communication of its contents not permitted without written authorization from Alcatel-Lucent

Page 2: HSDPA Performance Management

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

All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA

HSDPA Performance Management

2

Legal Notice

� Switch to notes view!Safety Warning

Both lethal and dangerous voltages are present within the equipment. Do not wear conductive jewelry

while working on the equipment. Always observe all safety precautions and do not work on the

equipment alone.

Caution

The equipment used during this course is electrostatic sensitive. Please observe correct anti-static

precautions.

Trade Marks

Alcatel and MainStreet are trademarks of Alcatel.

All other trademarks, service marks and logos (“Marks”) are the property of their respective holders

including Alcatel-Lucent. Users are not permitted to use these Marks without the prior consent of Alcatel

or such third party owning the Mark. The absence of a Mark identifier is not a representation that a

particular product or service name is not a Mark.

Copyright

This document contains information that is proprietary to Alcatel-Lucent and may be used for training

purposes only. No other use or transmission of all or any part of this document is permitted without

Alcatel-Lucent’s written permission, and must include all copyright and other proprietary notices. No

other use or transmission of all or any part of its contents may be used, copied, disclosed or conveyed to

any party in any manner whatsoever without prior written permission from Alcatel-Lucent.

Use or transmission of all or any part of this document in violation of any applicable Canadian or other

legislation is hereby expressly prohibited.

User obtains no rights in the information or in any product, process, technology or trademark which it

includes or describes, and is expressly prohibited from modifying the information or creating derivative

works without the express written consent of Alcatel-Lucent.

Alcatel-Lucent, The Alcatel-Lucent logo, MainStreet and Newbridge are registered trademarks of Alcatel-

Lucent. All other trademarks are the property of their respective owners. Alcatel-Lucent assumes no

responsibility for the accuracy of the information presented, which is subject to change without notice.

© 2007 Alcatel-Lucent. All rights reserved.

Disclaimer

In no event will Alcatel-Lucent be liable for any direct, indirect, special, incidental or consequential

damages, including lost profits, lost business or lost data, resulting from the use of or reliance upon the

information, whether or not Alcatel has been advised of the possibility of such damages.

Mention of non-Alcatel-Lucent products or services is for information purposes only and constitutes

neither an endorsement nor a recommendation.

Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-

Lucent equipment and its operation.

Page 3: HSDPA Performance Management

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

All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA

HSDPA Performance Management

3

Table of Contents

� Switch to notes view! Page

Section 1: Introduction

Section 2: Performance Management: Definitions and MethodologySummary 7Counters 8Counters: Definition 9Types of Counters and Period of Time 10Counter Specification: Collection Method 11Exercise 12Counter Locations: FddCell & RNC Counters 13Counter Locations: Reference FddCell Counters 14Counter Locations: Neighboring RNC Counters 15Counter Screening 16Counter Example: Number of RRC Connection Requests 17

Metrics 18Metrics: Definition 19Metric Format 20Example: RRC Connection Success 21Example: RRC Connection Success 22Page with Lines for “Student Notes” 23

Reports 24Report Definition 25Process 26Performance Management Process 27Page with Lines for “Student Notes” 28

Section 3: HSDPA KPIsRadio Resource Allocation 7HSDPA Channel Operation 8HSDPA Channel Configuration 9OVSF Code Tree Reservation 10NodeB Role 11Interface Configuration 12ATM VCC numbering 13UE Categories 14UE Capabilities and Max Bit Rates 15Activation Flags 16Main Parameters 17Accessibility Flow Diagrams 19Principles 20HSDPA CAC success rate 21RAB Assignment Flow 22RAB Assignment Success Rate 23HSDPA Case 24RB Set-up success rate 25Traffic Segmentation 26Procedure description 27Parameters 28Accessibility 29Network Retainability Performance 31Total number of RABs 32Abnormal Release Caused by RL Failure 33Call Abnormal Release 34Call Drop Rate at RNC Level 35Call Drop Rate per RAB established 37Call drop rate per released calls - cell level 38Number of drops per minute of RAB 39Average Number of calls 41Uplink/ Downlink PS Traffic 42

Page 4: HSDPA Performance Management

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

All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA

HSDPA Performance Management

4

Table of Contents [cont.]

� Switch to notes view!

Page

Section 3: HSDPA KPIs [con’t]

Throughput DL per Combined DL/UL max bit rate at RNC level 43HSDPA DL Kbytes ( SDU payload) 44First Stage Principles 46Second Stage Principles 47SPI Configuration 48Traffic 49CQI Reporting Principles 52CQI Modification Principles 53DL HSDPA radio traffic 54MAC-HS throughput and Cell throughput 55Mac-d Throughput per cell 56HSDPA Power Management Principles 58First Tx Power Allocation Principles 59Retransmission Principles 60HSDPA Retransmission rate 61

Page 5: HSDPA Performance Management

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

All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA

HSDPA Performance Management

5

Course Objectives

� Switch to notes view!

Welcome to HSDPA Performance Management

After successful completion of this course, you should understand :

� Define the counters, the metrics and explain how to use the metrics

� Describe HSDPA main metrics:

• Describe HSDPA Power Control Metrics

• Explain Always On KPIs for HSDPA

• Understand the main HSDPA accessibility, Traffic and mobility metrics.

Page 6: HSDPA Performance Management

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

All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA

HSDPA Performance Management

6

Course Objectives [cont.]

� Switch to notes view!

This page is left blank intentionally

Page 7: HSDPA Performance Management

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

All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA

HSDPA Performance Management

7

About this Student Guide

� Switch to notes view!Conventions used in this guide

Where you can get further information

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

� Technical Practices for the specific product

� Technical support page on the Alcatel website: http://www.alcatel-lucent.com

Note

Provides you with additional information about the topic being discussed.

Although this information is not required knowledge, you might find it useful

or interesting.

Technical Reference (1) 24.348.98 – Points you to the exact section of Alcatel-Lucent Technical

Practices where you can find more information on the topic being discussed.

WarningAlerts you to instances where non-compliance could result in equipment

damage or personal injury.

Page 8: HSDPA Performance Management

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

All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA

HSDPA Performance Management

8

About this Student Guide [cont.]

� Switch to notes view!

This page is left blank intentionally

Page 9: HSDPA Performance Management

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

All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA

HSDPA Performance Management

9

Self-Assessment of Objectives

� At the end of each section you will be asked to fill this questionnaire

� Please, return this sheet to the trainer at the end of the training

Switch to notes view!

Instructional objectives Yes (or globally yes)

No (or globally no)

Comments

1 To be able to define the counters, the

metrics and explain how to use the metrics

2 To be able to describe HSDPA main metrics:

•Describe HSDPA Power Control Metrics •Explain Always On KPIs for HSDPA •Understand the main HSDPA accessibility, Traffic and mobility metrics.

Contract number :

Course title :

Client (Company, Center) :

Language : Dates from : to :

Number of trainees : Location :

Surname, First name :

Did you meet the following objectives ?

Tick the corresponding box

Please, return this sheet to the trainer at the end of the training

����

Page 10: HSDPA Performance Management

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

All Rights Reserved © Alcatel-Lucent 2007Alcatel-Lucent W-CDMA

HSDPA Performance Management

10

Self-Assessment of Objectives [cont.]

� Switch to notes view!

Thank you for your answers to this questionnaire

Other comments

����

Page 11: HSDPA Performance Management

2-1

HSDPA Performance Management3FL12855AAAAWBZZA Ed 2 September, 2006

Performance Management: Definitions and Methodology

Section 2

Page 12: HSDPA Performance Management

2-2

September, 20062-2HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Objectives

After this course, you will be able to

> Define the counters• Define counters• Describe the counter format• Define subcounters and screening

• Relate subcounters to RAB, RRC, and interfaces

> Define the metrics• Define the metrics• Describe the metric format

• Define the metrics families

> Explain how to use the metrics• List Alcatel-Lucent reports• Describe a performance management process

Page 13: HSDPA Performance Management

2-3

September, 20062-3HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Content

Counters> Counters: Definition> Types of Counters and Period of Time> Counter Specification: Collection Method> Counter Locations: FddCell & RNC Counters> Counter Locations: Reference FddCell Counters> Counter Locations: Neighboring RNC Counters> Counter Families> Counter Screening> Counter Example: Number of RRC Connection RequestsMetrics> Metrics: Definition> Metric Format> Example: RRC Connection SuccessReports> Report DefinitionProcess> Performance Management Process

Page 14: HSDPA Performance Management

2-4

Student notes

Page 15: HSDPA Performance Management

2-5

September, 20062-5HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Page

Summary 7Counters 8Counters: Definition 9Types of Counters and Period of Time 10Counter Specification: Collection Method 11Exercise 12Counter Locations: FddCell & RNC Counters 13Counter Locations: Reference FddCell Counters 14Counter Locations: Neighboring RNC Counters 15Counter Screening 16Counter Example: Number of RRC Connection Requests 17Metrics 18Metrics: Definition 19Metric Format 20Example: RRC Connection Success 21Example: RRC Connection Success 22Page with Lines for “Student Notes” 23Reports 24Report Definition 25Process 26Performance Management Process 27Page with Lines for “Student Notes” 28End of Module 29

Page 16: HSDPA Performance Management

2-6

September, 20062-6HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Table of Contents [cont.]

> The subscriber evaluates the performance/quality of service of the network through 4 criteria.

4. Call Drop

3. Quality

2. Successful Call Set Up Rate

1. Extend of coverage

Criteria

> Can be assessed by the system through monitoring.

> Can be assessed by BLER (CS and PS) measurements.

> Can be assessed by air interface measurements.

> Can be approached by system monitoring.

> Can be assessed by the system through monitoring.

> Cannot be assessed by the system.

> Can be assessed by:• Air interface measurements,

• Subscriber complaints.

Possible assessment / monitoring

This page is left blank intentionally

Page 17: HSDPA Performance Management

2-7

September, 20062-7HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Summary

To measure and analyze the performance of a network one needs:

4. Call Drop

3. Voice Quality

2. Call Set Up

1. Coverage

Criteria

>Can be assessed by the system through monitoring.

>Can be assessed by air interface measurements.

>Can be approached by system monitoring.

>Can be assessed by voice quality analyzers.

>Can be assessed by the system through monitoring.

>Cannot be assessed by the system.

>Can be assessed by:— Air interface measurements,— Subscriber complaints.

Possible assessment / monitoring

���!

1. Data collection:1. Counters2. Metrics:> {counter1, counter2, …}

> f(counter1, counter2, …)

> …

3. Measurements

4. Reports

2. Process and methodology

3. … And experience!

Page 18: HSDPA Performance Management

2-8

HSDPA Performance Management3FL12855AAAAWBZZA Ed 2 September, 2006

Counters

Page 19: HSDPA Performance Management

2-9

September, 20062-9HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Counters: Definition

• Counters measure a number of specific events (occurring in an entity of the UTRAN), during a period.

• These counter values are stored in the performance server.

The wording “counter and “measurement” are often equally used in the documentation for identifying the same concept.

Usually, Alcatel-Lucent prefers to use the term “counter” to distinguish a counter from a “(radio) measurement”. A counter is periodically elaborated on periods expressed in minutes or hours, e.g. 30 min, while a measurement is elaborated on periods expressed in milliseconds, e.g. 500 ms.

3GPP Performance Management specifications preferably considers “measurements”. When the context refers to 3GPP specifications “measurement” is used, while “counter” is used is more Alcatel-Lucent specific part, but both wordings are equivalent.

Periods of counter

It is the duration of the events counting in the selected entity of the network. It can be modified. The QoS monitoring daily and hourly periods are used.

• Busy hour corresponds to the hour of the day when the traffic is the highest. It allows to analyze performances of the cells, when the traffic is higher. It is really important for congestion/capacity analysis and also forecasting.

• Daily period gives global information on the day. To compare busy hour and daily data, is necessary to check the influence of the traffic.

• Weekly period

• Monthly period

• RNC counters are uploaded every 15 min.

• BTS counters are uploaded every hour (minimum).

Page 20: HSDPA Performance Management

2-10

September, 20062-10HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Types of Counters and Period of Time

X2X1 X3 X4 X5 Xi Xn

Granularity Period

Initiation

Avg

Min

Max

NbEvt

Cumul

The default granularity period are 60 minutes for BTS and 15 min for RNC. They are configurable. The following rules shall be followed for temporal aggregation.

Rtotal applies to CC counters

X.cum = X1.cum + X2.cum + …+ Xn.cum

Rload / Rval applies to some LOAD and VAL counters

X.cum = X1.cum + … + Xn.cum

X.nbevt = X1.nbevt + … + Xn.nbevt

X.avg = (X1.cum + .. + Xn.cum) / (X1.nbevt + .. +X2.nbevt)

X.min = min (X1.min, .., Xn.min)X.max = max (X1.max, .., Xn.max)

Rload applies to some LOAD counters

Same result as previous Rload but resulting X.cum has no “physical” meaning due to the nature of the measurement (like percents..) and shall not be interpreted but is necessary for intermediate computations.

Page 21: HSDPA Performance Management

2-11

September, 20062-11HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Counter Specification: Collection Method

Counter type

Cumulative

Value

Load

Collection method

CC

GAUGE

DER

SI

Collection Method

•CC (Cumulative Counter);

•GAUGE (dynamic variable), used when data being measured can vary up or down during the period of measurement;

•DER (Discrete Event Registration), when data related to a particular event are captured every nth event is registered, where n can be 1 or larger;

•SI (Status Inspection).

Page 22: HSDPA Performance Management

2-12

September, 20062-12HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Exercise

#660 indicates an average of the number of “RABs*” established per RNC, based on time average over collection period.

It is load counter i.e is incremented by a value sampled on the sampling event occurrence (100ms) and gives 5 information:

• Cumulated value• Number of events• Minimum value• Maximum value• Averaged value = Cumulated value / Number of events

Based on this counter propose a “formula” to calculate the Time of RAB allocation

* number of DlAsConfIds established per RNC

Time of RAB allocation =

Page 23: HSDPA Performance Management

2-13

September, 20062-13HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Counter Locations: FddCell & RNC Counters

> FddCell counter• A “FddCell” counter is incremented for each FddCell of the serving RNC on

which the mobile is connected to when the event occurs (ex.: RL counters).

> RNC counter• A “RNC” counter is incremented when an event occurs on the serving RNC of

a connection (ex: Iu connection counters, traffic counters).

ServingRNC

DriftRNC

Iur

IuCore

Page 24: HSDPA Performance Management

2-14

September, 20062-14HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Counter Locations: Reference FddCellCounters

> Reference FddCell counter• A “Reference FddCell” counter is incremented only for the FddCell identified

as the reference FddCell of the connection when the event occurs (ex: Radio Bearer counters).

• Such a counter is only incremented if the reference FddCell belongs to the serving RNC on the connection.

• (Reference FddCell: FddCell with the best Ec/No).

ServingRNC

DriftRNC

Iur

IuCore

Page 25: HSDPA Performance Management

2-15

September, 20062-15HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Counter Locations: Neighboring RNC Counters

> Neighboring RNC counter• A “Neighboring RNC” counter is incremented for events:

• occurred on a neighboring RNC (ex: Iur connection counters),• related to FddCells that belong to the neighboring RNC (ex: RB setup

counters).

ServingRNC

DriftRNC

Iur

IuCore

Page 26: HSDPA Performance Management

2-16

September, 20062-16HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Counter Screening

> Screening refers to subcounters.> Screening are given in the counter definition. See example on the following page.

> The most common screenings are the following:• DlRbConf: Downlink (DL) Radio bearer (RB) set configurations (conf) made of RB

types:• Conversation, interactive/background, or streaming

• UlAsConf and DlAsConf: Uplink (UL) and DL Access Stratum (AS) configurations (conf). Can be filtered per:

• Containing CS, PS, or speech• Pure CS, PS, or SRB• Multi-service (PS+CS)

• RabConf Radio Access Bearer (RAB) configurations (conf) made of RAB type:• Traffic class• UL and DL bitrate

• RRC connection establishment causes includes:• Originating and terminating calls (conversational, streaming, interactive, background)• Emergency call• Registration• Detach• Originating and terminating signaling• Call re-establishment

> Some counters have their own and specific screenings.

See appendix of this course and the counter document referenced for detailed information.

Page 27: HSDPA Performance Management

2-17

September, 20062-17HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Counter Example: Number of RRC Connection RequestsA. This measurement provides the number of RRC connection requests screened by

establishment cause.

B. CC

C. Reception by the RNC of a RRC CONNECTION REQUEST message.

D. An integer value for each establishment cause.Screening: Sub-counter # i --> Establishment cause # i as in TS 25.331 (c.f. Annex)

E. RRC.AttConnEstab.<0..31>

F. FDDCell

G. Valid for circuit switched and packet switched traffic.

H. 3GPP specified counterAlcatel-Lucent #0409Counter introduced in V 2.0e

I. Message flowUE UTRAN

RRC Connection Establishment, network accepts RRC connection

RRC connection request

RRC connection setup

RRC connection setup complete

When vendor specific, the ‘VS’ prefix is addede.g. VS.RadioLinkSetupSuccess

The counters are specified according the “Measurement definition template” defined in the 3GPP specification.

C.x.y. Measurement Name (section header): descriptive name of the measurement type.A. Description contains an explanation of the measurement operation.B. Collection Method contains the form in which this measurement data is obtained.C. Condition contains the condition which causes the measurement result data to be updated. It is

defined by identifying protocol related trigger events for starting and stopping measurement processes, or updating the current measurement result value. Where no precise condition is available the conditional circumstances leading to the update are stated.

D. Measurement Result (measured value(s), Units) contains a description of expected result value(s).

E. Measurement Type contains a short form of the measurement name specified in the header, which is used to identify the measurement type in the result files (XML) on the Inteface-N. When vendor specific (VS) a counter starts with “VS.”, e.g. VS.RadioLink SetupSuccess.

F. Measurement Object Instance: the “measObjInstId” field identifies the measured object class and its instance, e.g. trunk1 means object class is trunk and instance #1 is being measured. The object class and instance values used for this purpose shall be in accordance with 3GPP TS 32.106 [3], i.e. the NE/resource object model (defined in the Basic CM IRP Information Model -3GPP TS 32.106-5) and naming conventions (defined in the Name Convention for Managed Objects - 3GPP TS 32.106-8). This parameter, if applicable, shall be provided in the measurement job.

G. Switching Technology contains the Switching domain(s) this measurement is applicable to (CS or PS).

H. 3GPP compliance states on the compliance of the Alcatel-Lucent measurement with the 3GPP specification (“3GPP specified counter” or “Alcatel-Lucent specified counter”). When not fully compliant with the 3GPP, the section explains how the counter is not fully compliant and the reason why.

Are provided: Alcatel-Lucent internal number, software version (the counter introduced s/w version).I. Comments: optional section provides additional information when necessary e.g. message flows

when counters are attached to protocol messages.

Page 28: HSDPA Performance Management

2-18

HSDPA Performance Management3FL12855AAAAWBZZA Ed 2 September, 2006

Metrics

Page 29: HSDPA Performance Management

2-19

September, 20062-19HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Metrics: Definition

Metric ={counter1, counter2, …}

Metric = f (counter1, counter2, …)

Composed of one or several counters

A formula composed of one or several counters.

For instance: ∑ RRC.SuccConnEstab [RRC screenings]

• Metric definitions may include counter screening such as voice, video, or data.• Some counters screened by As Conf Id (DL or UL), or RRC establishment causes.• Other counters are provided with screening details.

To interpret data coming from the counters, it is necessary to define some metrics.

A metric is composed of one or several counters.

These counters can be screened for some specific metrics:

• Counters screened by As Conf Id (DL or UL), or RRC establishment causes.The screening is detailed in the annexes.

• Other counters with screening details.The screening value used in the metric is directly set with the counter.

Note that if no screening details are given (no brackets), all screenings of the counter must be used for the metric.

The screening is identified as followed:

• Downlink As Conf Id = DL_AsConfId_Screenings (screened by SRB, CS, PS, Combined, PS 8, PS 32, PS 64, PS 128, PS 256, PS 384, CS 14.4, CS 57.6, CS 64, Voice)

• Uplink As Conf Id = UL_AsConfId_Screenings

• RRC release = RRC_Release_Screenings (specific screening for RRC Failures)

• RRC establishment causes = RRC_Screenings (screened by Call, CS, PS, Identification)

• RAB = RAB_Screenings (screened by CS, PS)

Page 30: HSDPA Performance Management

2-20

September, 20062-20HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Metric Format

Optional: Comment or monitoring recommendation Comment

Counter: #Counter Id = Name of the counter [all possible screenings]

Associated counters

Metric formula with counter name, or metric id with specific screenings used

Metric formula

����

NetworkRNCGroup of

cellsCell

NC

ApplicabilityMetric

history

Metric NameMetric Id

Metric Id allows to identify the metric. It is expressed as Subfamily-xxx where:

• subfamily is the family of the counters composing the metrics (RRC, Iu, RL…),

• xxx is the number of the metric inside the subfamily.

Metric history can be either

• NEW, the metric has been created for the given release,

• UPDATE, the metric existed in the previous release but counters have been modified,

• NC, No change, the metric existed in the previous release and stays as it is in the current one.

Applicability: Level at which the metric can be computed.

Metric formula is expressed with counter external names.

When it is composed of the sum of all the screenings of one counter it will be expressed as the following example:

∑Counter_name [List_screenings]

Ex.: Total number of RRC attempts = ∑(VS.RRC.AttConnEstab [RRC screenings])

The list of the RRC screenings can be found in the appendix of the document.

• When the metric is composed of the sum of some screenings of one counter but not of the entire list it will be expressed as follow:

Counter_name [screening1 + screening3 + screening 8]

Ex.1: Number of RRC attempts for CS calls = VS.RRC.AttConnEstab[0 + 1 + 5 + 6 + 9]

Ex.2: Average Iu SCCP established = VS.IuAvgNbrSccpCnx [WithCoreNetworkCs.Avg+WithCoreNetworkPs.Avg]

Page 31: HSDPA Performance Management

2-21

September, 20062-21HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Example: RRC Connection Success

Necessary for the calculation of RRC Connection success rate, this metric allows also to see the call distribution in terms ofsuccess of the request.

Indeed, this metric can be computed per RRC establishment cause:• Calls: RRC call screenings• CS calls: RRC CS call screenings• PS calls: RRC PS call screenings• Registration: RRC identification screenings

Monitoring recommendation

#0403 RRC.SuccConnEstab (RRC establishment causes )Associated Counters

∑ (RRC.SuccConnEstab [RRC screenings] )Metric formula

Number of RRC connection success (sum of all causes)Meaning

����

NetworkRNCGroup of cellsCellNC

ApplicabilityMetric history

RRC connection success RRC001

The first phase of a call establishment (speech or data) is the RRC connection. One RRC connection can lead to:

• several Iu SCCP connections ( multi service CS+PS, simultaneous CS + PS attach/detach, CS location update during a PS call)

• no RAB in case of signaling connections

• 1 (or several RAB) in case of one call (multi service).

Page 32: HSDPA Performance Management

2-22

September, 20062-22HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Security mode command success

BLER PSQuality

BLER CS

Mean RB Blocking rateCongestion

DL PS Traffic per RNC

Traffic

RAB establishment success rate

UL PS Traffic per RNC

Average number of Video calls per day

Average number of Voice calls per day

3G-2G HHO CS execution failure rate (3G side)

3G-2G HHO CS execution failure rate (2G side)

3G-2G HHO CS preparation success rate

Global 3G-2G CS HHO success rate

3G-2G HHO PS execution failure rate (2G)

Voice Call Drop rate at RNC

Video Call Drop rate at RNC

Mean Sector Per User

Mobility

PS call drop rate at RNC

Retainability

SCCP connection success rate

RRC connection success rate (calls only)

UTRAN Call set up success indicator

Accessibility

RNC PanelUTRAN metric families

This report, named RNC Panel, is built using high level metrics, in order to give an overview of the performance of the network. These metrics are associated to the main phases of a call:

• RRC connections setup• IU SCCP connections setup• Radio Access Bearers establishment• Call Drops• Mobility efficiency• Congestion detection• Quality of the bearer• Traffic

This report has to be used at network level or RNC level => easy to geographically investigate an area when there is an issue.It reflect the quality of actual network.It leads to deeper investigations with additional metrics.

The Network Accessibility analysis aims at evaluating the accessibility performance results at network level and at RNC level and is based on the accessibility metrics belonging to the RNC PANEL report In case of degradation of CSSR (Call Setup Success Rate) then identify the accessibility bottlenecks by correlating with the other accessibility metrics:

• RRC Connection success rate• Iu SCCP Connection success rate• RAB Assignment success rate

Page 33: HSDPA Performance Management

2-23

Student notes

Page 34: HSDPA Performance Management

2-24

HSDPA Performance Management3FL12855AAAAWBZZA Ed 2 September, 2006

Reports

Page 35: HSDPA Performance Management

2-25

September, 20062-25HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Report Definition

> A report is a set of metrics.• Report can be from high level to a low level to help

investigate/analyze from general to specifice.g. network level report -> RNC level report -> FddCell level report

• Some reports are pre-defined, others are created/customized by the user.

> Types of reports:• Evolution report• Top N report

• Alarm detection report

> Alcatel-Lucent proposes pre-defined reports

A report consists of a set of metrics going from a high level view to a low level (from a network view to a network element view, i.e. Network -> RNC -> Fddcell):

• Set of reports at executive level.

• Detailed reports (evolution and top N reports).

• Reports based on alarm generation.

The format of the report is a graph or a table.

In order to be efficient it’s recommendable to name the reports with prefixes that indicates what level they are referring to (RNC, fddcell) followed by the report name.

Several types of reports can be used:

• Evolution report: the objective of the evolution reports is to show and compare the statistics related to a set of NEs, over a period of time.

• Top N report: the objective of top N reports is to filter the N worst (or best) NEs according to a specific criterion. Such reports are run over a set of NEs and for a single date.

• Alarm detection report: every report can be complemented with reports coming from alarm detection based on thresholds.

Page 36: HSDPA Performance Management

2-26

HSDPA Performance Management3FL12855AAAAWBZZA Ed 2 September, 2006

Process

Page 37: HSDPA Performance Management

2-27

September, 20062-27HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Performance Management ProcessData retrieving

definition

Criteriadefinition

Observation

!Analysis

Correction

Validation

Engineering

O&M

O&M

Mon

itorin

g se

tup

Mon

itorin

g pr

oces

s• Counters• Metrics• Reports

• Hourly / busy hours, daily, weekly• Alarm detection• NEs (RNCs, FddCell, …)

Tools(PrOptima, scripts…)

The basic method for monitoring is based on a detection method: a problem or a need of improvement is detected when, part of the network doesn’t fit the “required performances” e.g.:

• Performances not in accordance with the operator’s needs or expectations,

• Difference of performances with the rest of the network,

• Sudden degradation of performances.

Performances could be defined as rates of operations completion or usage of the resources.

Network monitoring process is based on:

Network observation Analysis of the problem

Correction proposal Verification

It means that the operator has to "translate" the subscriber feeling of the quality in a mathematics formula based on indicators. These indicators are obtained from:

Interfaces measurements NE counters

Subscriber complaints

And they are collected and showed out using:

Protocol analyzers Trace functions

Optimization and monitoring tools

Page 38: HSDPA Performance Management

2-28

Student notes

Page 39: HSDPA Performance Management

2-29

September, 20062-29HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

End of Module

Page 40: HSDPA Performance Management
Page 41: HSDPA Performance Management

3-1

September, 2006HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

HSDPA KPIs

Section 3

Page 42: HSDPA Performance Management

3-2

September, 20063-2HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Objectives

After this section, you will be able to

> Describe HSDPA main metrics

> Describe HSDPA Power Control Metrics

> Explain Always On KPIs for HSDPA

> Understand the main HSDPA accessibility, Traffic and mobility metrics.

Page 43: HSDPA Performance Management

3-3

September, 20063-3HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Contents> Introduction> What’s HSDPA?> Radio Resource Allocation> HSDPA Channel Operation> HSDPA Channel Configuration> OVSF Code Tree Reservation> NodeB Role > Interface Configuration> ATM VCC numbering> UE Categorieses> Activation Flags> Main Parameters> Accessibility Flow Diagrams> Principles> HSDPA CAC success rate > RAB Assignment Flow> RAB Assignment Success Rate> HSDPA Case> RB Set-up success rate> Traffic Segmentation> Multi-carrier HSDPA traffic segmentation> Accessibility> Call Drop Rate at RNC Level> Call Abnormal Release> Call Drop Rate at RNC Level

> Call Drop Rate at RNC Level> Call drop rate per released calls - cell level> Number of drops per minute of RAB> Uplink/ Downlink PS Traffic> Throughput DL per Combined DL/UL max bit rate at

RNC level> Traffic> SPI Configuration> Traffic> CQI Reporting Principles> CQI Modification Principles> HSDPA specific traffic metrics > HSDPA Power Management Principles> First Tx Power Allocation Principles> Retransmission Principles> HSDPA Retransmission rate> Iub Bandwidth Limitation> Downlink BLER PS> Uplink BLER PS> Congestion> Principles> Always – On metrics> Multiservices

Page 44: HSDPA Performance Management

3-4

Student notes

Page 45: HSDPA Performance Management

3-5

September, 20063-5HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Page 46: HSDPA Performance Management

3-6

September, 2006HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Table of Contents [cont.]

What’s HSDPA?

Page

Iub Bandwidth Limitation 62Iub Bandwidth Limitation - Principle 63Iub Bandwidth Limitation – F. A. 64Downlink BLER PS 65Uplink BLER PS 66Uplink BLER PS 67Uplink BLER PS 68HS-SCCH Power Control Activation 69Congestion 70Congestion 71Principles 72Activation 73Always – On metrics 74Always – On metrics 75Principles 76Principles 77Principles 78Principles 79

Page 47: HSDPA Performance Management

3-7

September, 20063-7HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Radio Resource Allocation

Shared Channel

Dedicated Channel

Dedicated Channel

Dedicated Channel

UMTS R4

HSDPA

The WCDMA system normally carries user data over dedicated transport channels, or DCHs, which brings maximum system performance with continuous user data. The DCHs are code multiplexed onto one RF carrier. In the future, user applications are likely to involve the transport of large volumes of data that will be bursty in nature and require high bit rates.

HSDPA introduces a new transport channel type, High Speed Downlink Shared Channel (HS-DSCH) that makes efficient use of valuable radio frequency resources and takes into account packet data services burstiness.

This new transport channel shares multiple access codes, transmission power and use of infrastructure hardware between several users. The radio network resources can be used efficiently to serve a large number of users who are accessing bursty data. To illustrate this, when one user has sent a data packet over the network, another user gets access to the resources and so forth. In other words, several users can be time multiplexed so that during silent periods, the resources are available to other users.

Page 48: HSDPA Performance Management

3-8

September, 20063-8HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

HSDPA Channel Operation

HS-SCCHDownlink Transfer Information(UEid, OVSF,...)

HS-PDSCHData Transfer

(PS I/B)

DPCHUpper Layer Signaling

2ms

UE #1UE #2UE #3UE #4UE #5

OVSFcodes

HS-DPCCH Feedback Information

(ACK/NACK, CQI)

DPCHUpper Layer Signaling

HS-DPCCH Feedback Information(ACK/NACK, CQI)

HSDPA operation requires three new physical channels to be introduced:

• The HS-PDSCH (DL) on which is mapped the HS-DSCH. It carries only the data payload. The SF is equal to 16 and up to 15 codes can be reserved to HS-PDSCH per cell. One HS-DSCH can be mapped onto one or several HS-PDSCH (the maximum number of codes is given by UE capabilities).

• The HS-SCCH (DL) that carries the HS-PDSCH associated signaling. The SF is fixed to 128. It indicates to which UE data is intended to, on which codes and with which parameters. There are as many HS-SCCH transmitted during a TTI as scheduled user number.

• The HS-DPCCH (UL) that carries feedback information (ACK/NACK/CQI) to handle retransmissions (SF=256).

HSDPA operation also requires to use already existing R4 physical channels:

• The DPCH (UL/DL) is needed to carry the higher layers signaling. Dedicated physical channel is also required in UL to carry the corresponding user data (PS I/B) as HS-PDSCH is DL only.

Page 49: HSDPA Performance Management

3-9

September, 20063-9HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

HSDPA Channel Configuration

Layer 1

HS-SCCH HS-DPCCH

TransportChannels

LogicalChannels

PhysicalChannels

DCCH

DCH

DPCH

DTCH

HS-DSCH

HS-PDSCH

DTCH

DCH

DPCCH

DCCH

DCH

DPDCH

From a Radio Bearer perspective, a HSDPA data session implies:

• A HS-DSCH transport channel supported by a variable number of HS-PDSCH SF16 physical channels. The HS-DSCH transport channel is used to transport the downlink data packets between UE and UTRAN, i.e. packets associated to the DTCH logical channel

• An associated DCH. This dedicated transport channel is used to transport the signalling messages, including the signalling exchanged at the RRC level and the signalling exchanged between the UE and the Core Network (e.g. all SM and GMM layer messages). The associated DCH also transports the packet data in the uplink direction.

HS-SCCH and HS-DPCCH physical channels only exist for the Layer 1 of the radio interface. They have the following purpose:

• HS-SCCH (SF128) is used for UE addressing (i.e. indicating a specific UE that data packets are being sent on the HS-PDSCH), and provides the UE with necessary information to decode the data packets (UE id, modulation scheme, HS-PDSCH code set, redundancy version attributes). There are as many HS-SCCH transmitted during a TTI as scheduled user number.

• The HS-DPCCH (SF256) is used to carry UE feedback information used for link adaptation (CQI) and HARQ process (ACK/NACK).

Page 50: HSDPA Performance Management

3-10

September, 20063-10HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

OVSF Code Tree Reservation

SF4

SF8

SF16

SF32

SF64

SF128

SF256

cmCH

. . .

HS-PDSCH

HS-SCCH

. . .

. . .

. . .

SF4

SF8

SF16

SF32

SF64

SF128

HS-PDSCH

HS-SCCH

HSDPA + R4HSDPA + R4

HSDPAHSDPA

The configuration of the OVSF code tree can provide up to 15 SF16 codes allocated to HS-PDSCH and up to 4 SF128 codes for HS-SCCH.

All the R4 common channels (CPICH, P-CCPCH, S-CCPCH) are allocated in the top of the tree and take the equivalent of a SF32 code. All remaining OVSF codes can be used for non-HSDPA services (speech, multi-RABs...)

In Alcatel-Lucent implementation, the HS-PDSCH SF16 codes are allocated and reserved by the RNC at the bottom of the tree. Immediately above, the HS-SCCH SF128 codes are allocated. These codes are allocated at cell setup and cannot be used or preempted for other services.

All the remaining codes are therefore contiguous and left for further DCH allocations. This includes associated DCH as well as any other calls mapped on DCH (e.g. speech calls, streaming, etc).

Note that the maximum configuration (15 HS-PDSCH codes and 4 HS-SCCH codes) leaves no room in the OVSF tree for DCH (due to common channels occupancy) so it is not even possible to allocate associated SRB for HSDPA calls.

Page 51: HSDPA Performance Management

3-11

September, 20063-11HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

NodeB Role

SchedulerFills the TTIs with one or more users based on their

priority and feedback information

HARQ ProcessesRetransmissions handling, TFRC selection, AMC…

Queue IDs

Radio TransmissionFeedback Reception

Capacity Request

Control FP

Capacity AllocationControl FP

Data FP

Flow ControlDynamically fills the Queues of each

UE

RNC

The main architectural shift with respect to R4 is the introduction of an ARQ scheme for error recovery at the physical layer (which exists independently of the ARQ scheme at the RLC layer). This fast retransmission scheme is of paramount importance for TCP as generally TCP has not performed well in a wireless environment.

This architectural evolution gives a new importance to the role of the NodeB in the UTRAN. It then necessarily goes together with the introduction of some new functions managed by the NodeB among which:

- Flow Control: new control frames are exchanged in the user plane between NodeB and RNC to manage the data frames sent by the RNC,

- Scheduler: it determines for each TTI which users are going to be served and how many data bits they are going to receive,

- Hybrid Automatic Repeat Query: retransmissions management,

- Adaptive Modulation and Coding: new channel coding stages and radio modulations schemes are introduced to provide data throughput flexibility,

- Feedback demodulation and decoding in UL..

Page 52: HSDPA Performance Management

3-12

September, 20063-12HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Interface Configuration

AAL2

� DS� NDS� HSDPA

PCM

ATM

AAL5

� OAM� CP� CCP

INVccGroup

VCC OAM

VCC DS traffic

VCC NodeBCP

VCC CCP

VCC NDS traffic

VPi/VCi

VPi/VCi

VPi/VCi

VPi/VCi/PathId/QoSId

VPi/VCi/PathId/QoSId

RNC

VCC HSDPA traffic VPi/VCi/PathId/QoSId

• New VCC• New ATM Profile• New QoSId

PCM link (1 up to 8 with IMA)

As HSDPA is a system evolution limited to UTRAN, HSDPA activation have no impact beyond the RNC.

As HSDPA is not supported over Iur interface, the only interface modifications are related to Iub.

HSDPA activation does not impact UTRAN interfaces Control Plane configuration. As mentioned earlier there is just a moderate evolution of the NBAP messaging. Evolution of RRC messaging does not impact the interface configuration needs for DS VCC.

In fact the major evolution triggered by HSDPA introduction is the definition of a new type of VCC dedicated to HS-DSCH operation.

There is just one HSDPA VCC per Iub, the configuration of this new VCC requires the definition of a dedicated ATM Profile together with the intriduction of a new AAL2 QoS.

The support of IMA with multi-PCM is necessary in order to be able to provide high user data rates, otherwise this may constitute the first bottleneck. Up to 8 PCM links can be managed by a single NodeB.

Page 53: HSDPA Performance Management

3-13

September, 20063-13HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

ATM VCC numbering

> 0.32

> x.34

> x.35 – x.40

> x.41 – x.48

> x.49 – x.55

> x.56

OAM

CP

CCP

DS

NDS

HSDPA

Page 54: HSDPA Performance Management

3-14

September, 20063-14HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

UE Categories

• QPSK mandatory for HSDPA capable UE

• 16-QAM optional

1.8 MbpsQPSK only15Category 12

0.9 MbpsQPSK only25Category 11

14.4 MbpsQPSK & 16-QAM115Category 10

10.2 MbpsQPSK & 16-QAM115Category 9

7.3 MbpsQPSK & 16-QAM110Category 8

7.3 MbpsQPSK & 16-QAM110Category 7

3.6 MbpsQPSK & 16-QAM15Category 6

3.6 MbpsQPSK & 16-QAM15Category 5

1.8 MbpsQPSK & 16-QAM25Category 4

1.8 MbpsQPSK & 16-QAM25Category 3

1.2 MbpsQPSK & 16-QAM35Category 2

1.2 MbpsQPSK & 16-QAM35Category 1

Max Peak RateModulationInter-TTI Min IntervalHS-PDSCH Max NumberHS-DSCH Category

Twelve new categories have been specified by Release 5 for HSDPA UEs according to the value of several parameters among which are the following:

• Maximum number of HS-DSCH codes that the UE can simultaneously receive (5, 10 or 15).

• Minimum inter-TTI interval, which defines the minimum time between the beginning of two consecutive transmissions to this UE. If the inter-TTI interval is one, this means that the UE can receive HS-DSCH packets during consecutive TTIs, i.e. every 2 ms. If the inter-TTI interval is two, the scheduler needs to skip one TTI between consecutive transmissions to this UE.

• Supported modulations (QPSK only or both QPSK and 16QAM),

• Maximum peak data rates at the physical layer (number of HS-DSCH codes x number of bits per HS-DSCH / Inter-TTI interval).

These twelve categories provide a much more coherent set of capabilities as compared to R4 which gives UE manufacturers freedom to use completely atypical combinations.

Page 55: HSDPA Performance Management

3-15

September, 20063-15HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

UE Capabilities and Max Bit Rates

-10 -8 -6 -4 -2 0 2 4 6 8 1010

15

20

25

C/I (dB)

softCQI

S oft CQI vs C/I - Pedes trian_a 1 RX

Category 6 UE CQI Mapping Table

16-QAM3024 kbps530

16-QAM3024 kbps529

............

16-QAM1440 kbps516

QPSK1296 kbps515

QPSK1008 kbps414

QPSK864 kbps413

QPSK720 kbps312

QPSK576 kbps311

QPSK432 kbps310

QPSK288 kbps29

QPSK288 kbps28

QPSK144 kbps27

QPSK144 kbps16

QPSK144 kbps15

QPSK0 kbps14

QPSK0 kbps13

QPSK0 kbps12

QPSK0 kbps11

out of range0

ModulationRLC Throughput

HS-PDSCH Number

CQI Value

Target BLER ≤ 10%

The maximum achievable data rate depends on the UE category but also on the instantaneous

radio conditions it is exposed to. Each UE category has therefore a reference table specifying the supported combinations between the reported CQI values, the number of codes and the radio modulation (QPSK or 16-QAM).

Instantaneous radio channel conditions are known at the UTRAN level thanks to the periodical decoding of the Channel Quality Indicator sent by the UE to the NodeB onto the HS-DPCCH. The UE first estimates the Carrier over Interference ratio (C/I). From this estimate the UE then determines a CQI (with a maximum HS-DSCH BLER target of 10%) and then it sends this indication back to the NodeB. The NodeB takes this input into consideration in order to adapt the throughput to the UE.

Note: a UE reporting a CQI value of 0 is not scheduled by the NodeB.

Page 56: HSDPA Performance Management

3-16

September, 20063-16HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Activation Flags

RNC/RadioAccessService� isHsdpaAllowed (TRUE, FALSE)

RNC/NodeB/FDDCell� hsdpaActivation (TRUE, FALSE)

BTSEquipment/BTSCell� hsdpaResourceActivation

(TRUE, FALSE)

RNC

NodeB

FDDCell

0..200

1..6

0..*

RadioAccessService

1..1

BTSEquipment

BTSCell1..12

0..3000

The parameters involved in HSDPA activation at RNC side are:isHsdpaAllowed: Customer Class 3, rec. = TRUE,

hsdpaActivation: Customer Class 3 , rec. = TRUE.

The parameter involved in HSDPA activation at BTSEquipment side are:

hsdpaResourceActivation: Customer Class 0 , rec. = TRUE.

HSDPA activation main switch is located at RNC level, under the Radio Access Service subtree. If the value of isHsdpaAllowed is set to TRUE, then all the new MOIsrequired for HSDPA operation should be defined in the RNC configuration.

Activation consists in:

• at BTS level, set hsdpaResourceActivation to TRUE.• at RNC level, set isHsdpaAllowed to TRUE and then hsdpaActivation to TRUE.

Note that HSDPA needs to be activated at BTS level first, and that prior to the activation on a BTS, a new VCC shall be created on the corresponding Iub link to carry HSDPA traffic.

Deactivation can be performed at two levels:

• deactivation at RNC level: setting isHsdpaAllowed to FALSE deactivates HSDPA and leaves the HSDPA dedicated resources preserved,

• deactivation at cell level: setting hsdpaActivation and hsdpaResourceActivation to FALSE completely deactivates HSDPA.

Page 57: HSDPA Performance Management

3-17

September, 20063-17HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Main Parameters

RNC/RadioAccessService/HsdpaCellClass� maximunNumberOfUsers [0..50]

� numberOfHsPdschCodes [0..15]

� numberOfHsScchCodes [0..4]

� minimumPowerForHsdpa [0..50]

BTSEquipment/BTSCell/HsdpaConf� dchPowerMargin [0..100]

� harqType (mirType, pirType, ccType)

� harqNbMaxRetransmissions [0..31]

� hsdpaResourceId [0..5]

. . .

HS-PDSCH

HS-SCCH

. . .

. . .

. . .

cmCHs

HS-PDSCHHS-SCCH

DPCH

SHO

MCPAPower

Below are some of parameters controlling the behavior of the main HSDPA aspects illustrated in this course.

RNC/RadioAccessService/HsdpaCellClass parameters.

maximunNumberOfUsers: Customer Class 0, rec. = 20.

numberOfHsPdschCodes: Customer Class 0, rec. = 10.

numberOfHsScchCodes: Customer Class 0, rec. = 2.

minimumPowerForHsdpa: Customer Class 0, rec. = 0dB.

BTSEquipment/BTSCell/HsdpaConf.

dchPowerMargin: Customer Class 3, rec. = 20%.

harqType: Manufacturer Class 3, value = mirType.

harqNbMaxRetransmissions: Customer Class 3, rec. = 15

hsdpaResourceId: Customer Class 0.

Page 58: HSDPA Performance Management

3-18

September, 20063-18HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Accessibility KPIs

Page 59: HSDPA Performance Management

3-19

September, 20063-19HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Accessibility Flow DiagramsUE

RRC Connection Request

RRC Connection CompleteRRC Connection Setup

Radio Link Setup RequestRadio Link Setup Response

Measurement ControlInit Direct Transfer

RNCNode B SGSN

SCCP connection confirm

SCCP connection req.

Security mode command

Security mode complete

Security mode command

Security mode completeCommand id

RAB assignment req.

Radio Bearer SetupRadio Bearer Setup Complete

RAB assignment resp.

S.R.L.R. Procedure

RR

C c

onne

ctio

nS

CC

Pco

nn.

Sec

urity

mod

eR

AB

esta

blsh

t

Page 60: HSDPA Performance Management

3-20

September, 20063-20HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Principles

HSDPA RAB

Traffic Class = I/B?

Multi-Service?

R99 RAB

YES

NO

YES

RAB Request

NO

YES

NO

RNCRNC

HSDPA UE?

Primary Cell = HSDPA Cell?

YES

NO

maximunNumberOfUsers (HsdpaCellClass )

RadioAccessService

RNC

HsdpaCellClass

hsdpaMaxNumberUser (BTSEquipment )

hsdpaMaxUserPerNodeB (BTSEquipment )

Any PS RAB request with Interactive or Background traffic class is matched to the HSDPA Radio Bearer configuration if the mobile is HSDPA capable and the primary cell of the active set supports HSDPA. If it is not the case, the request is mapped on DCH as usual (iRM CAC is performed).

In this implementation, the admission process in the RNC for HSDPA admits any I/B RAB request on HSDPA until the maximum number of simultaneous users allowed on HSDPA is reached (maximumNumberOfUsers). In this version there is no other admission criteria.

The BTS will limit the number of simultaneous HS-DSCH radio-links because of limited processing capacity. If the limit is reached, the radio-link setup/reconfiguration is rejected. This leads to a RAB reject by the RNC.

hsdpaMaxNumberUser represents the maximum number of HSDPA user (logical channel) allowed per hsdpaResource (H-BBU) 0 meaning maximum user allowed by software and hardware Default value = 0 (no limit except software and hardware limit).

Page 61: HSDPA Performance Management

3-21

September, 20063-21HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

HSDPA CAC success rate

#0957 / (#0957 + #0958 )

This metric characterizes the success of HSDPA Call Admission Control during call establishment or mobility.

It is based on counters

• VS.HsdpaCACSuccess: Number of HSDPA CAC (Successful access to the cell for an HSDPA call during mobility or establishment procedure)

• VS.HsdpaCACUnccessful: Number of HSDPA CAC failures(Unsuccessful access to the cell for an HSDPA call during mobility or establishment procedure)

This metric is at cell level

Page 62: HSDPA Performance Management

3-22

September, 20063-22HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

RAB Assignment Flow

UE Node B RNC CN

RAB assignment req.

SRLR procedure

Radio Bearer Setup

Radio Bearer Setup Complete

RAB assignment resp.

#0622 RAB assignment success per req RAB type#0623 RAB assignment success per granted RAB type

#0621 RAB assignment request (UA04.0)

Internal RRM decision to assign

resources

#0601 RB setup success#0602 RB setup unsuccess

RA

Bes

tabl

sht

#0631 RB Establishment Unsuccess

#xxx ?

#601: Number of successful Radio-bearer establishme nts per cell. This measurement provides the number of successful radio bearer establishment procedures, for each cell controlled by the RNC which is the reference cell. Screening: DlAsConf Id

#602: Number of failed Radio-bearer Establishments per cell. This measurement provides the number of RB establishment procedures failures, screened by establishment failure cause, for each cell controlled by the RNC which is the primary cell.During such a procedure, the measurement attached to a given cell is incremented if the cell is in the primary cell of the active set of the involved UE. Screening:

• #0 ---> Time-out expired without reception of a RADIO BEARER SETUP COMPLETE message or a RADIO BEARER SETUP FAILURE message.

• #1 ---> Reception of a RRC RADIO BEARER SETUP FAILURE message

#603: Number of refused Radio-bearer Establishments per cell. This measurement provides the number of RB establishment refusals before any sending of RRC RADIO BEARER SETUP, screened by establishment refusal cause, for each cell controlled by the RNC which is the reference cell. Screening:

• #0 --> Invalid RB parameter value #1 --> Unavailable downlink code resources

• #2 --> Unavailable downlink power resources #3 --> Unspecified

#604: Number of successful RAB establishments. This measurement provides the number of successful Radio Access Bearer establishments, screened by traffic class. Screening:

• #0 --> Traffic Class 0, i.e. Conversational #1 --> Traffic Class 1, i.e. Streaming

• #2 --> Traffic Class 2, i.e. Interactive #3 --> Traffic Class 3, i.e. Background

#605: Number of failed RAB establishments. This measurement provides the nb of unsuccessful Radio Access Bearer establishments, screened by traffic class. Screening: same as #604.

#621: Number of RAB Establishments Requests per RAB type. This measurement provides the number of RAB establishment attempts. Screening: by requested RAB Type (Traffic Class, UL bitrate, DL bitrate).

#0622: Number of RAB establishments success per requested RAB type. This measurement provides the number of successful RAB establishment, screened per requested RAB type (requested should be understood to be after RAB matching).

Page 63: HSDPA Performance Management

3-23

September, 20063-23HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

RAB Assignment Success Rate

Voice RAB Assignment = (#0622.[1]) / (#0621.[1])success rate

Voice RAB Assignment = (#0622.[1]) / (#0621.[1])success rate

Video RAB Assignment = (#0622.[2]) / (#0621.[2])success rate

Video RAB Assignment = (#0622.[2]) / (#0621.[2])success rate

PS RAB Assignment = (#0622.[0, 5-42]) / (#0621.[0, 5-42] )success rate

PS RAB Assignment = (#0622.[0, 5-42]) / (#0621.[0, 5-42] )success rate

This metric is Impacted by HSDPA but can not be computed for HSDPA as HSDPA RAB is not requested by the Core Network .

Page 64: HSDPA Performance Management

3-24

September, 20063-24HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

HSDPA Case

> For HSDPA we will use RB setup success rate instead or the volume of RAB granted:

HSDPA RAB assignment success per granted HSDPA RAB = (∑#0623[43- 50])

VS.RabEstablishmentSuccessPerGrantedRabType - #623

This measurement provides the number of successful RAB establishment, screened per granted RAB type. Granted should be understood as after RNC CAC (iRM..).

Page 65: HSDPA Performance Management

3-25

September, 20063-25HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

RB Set-up success rate

RB Setup success rate = RB setup success / RB set u p request

Pure Voice RB Setup success rate success rate = (# 0601.[2]) / (#0625.[2]) Pure Video RB Setup success rate success rate = (# 0601.[1]) / (#0625.[1]) Pure PS RB Setup success rate success rate = (∑#0601.[2,4,6,7,11,12,23,24,25]) / (∑#0625 .[2,4,6,7,11,12,23,24,25]) Combined RB Setup success rate success rate = (∑#0601.[9,10,15,16,17,18,21,22,26,28,29,30]) / (∑#0625 .[9,10,15,16,17,18,21,22,26,28,29,30]

HSDPA RB setup success rate = #0601.[27] / #0625 .[ 27]

This metric is the counterpart of RAB assignment success rate but at cell level

It is based on counters

• #0601 VS.RadioBearerSetupSuccess : Number of Radio Bearers successfully setup

• #0625 VS.RadioBearerSetupRequest : Number of Radio bearer setup decisions by the RNC (leading or not to a RB SETUP, ie. even if Call Admission Control rejects the setup)

Page 66: HSDPA Performance Management

3-26

September, 20063-26HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Traffic Segmentation

R4 cell R4 cell

RRC Connection Setup(Redirection to F1)

HSDPA cell

RNC

RRC Connection Setup(Redirection to F2)

RRC Connection Request(AS release indicator = R4 or absent)

RRC Connection Request(AS release indicator = R5)

HSDPA cell

Traffic Segmentation feature allows to deal with a multi-layer scenario where HSDPA is available in only one of the layers.

Mobiles are redirected to the right layer at RRC connection establishment in order that mobiles that are eligible to HSDPA are directed towards the HSDPA layer and that the other ones are directed towards the non-HSDPA layer. The redirection is based on the twin-cell configuration. The call flow is not modified compared to a normal call setup, the redirection only consists in indicating a target frequency in the RRC Connection Setup message (frequency info IE).

Mobiles in idle mode will select a layer according to radio conditions criteria. The cell selection/reselection algorithm is not governed by HSDPA availability so it is not possible to guarantee that an HSDPA mobile will select the HSDPA layer (and vice versa a non-HSDPA mobile will select the non-HSDPA layer).

Segmentation is done by the RNC when a mobile tries to establish a RRC connection. It is based on the Access Stratum Release Indicator IE present in RRC Connection Request, knowing that R4 mobiles do not support HSDPA. If a R4 mobile sends its connection request in the HSDPA layer, it is redirected to the non-HSPDA layer in the RRC Connection Setup message. If a R5 (or later release) mobile sends its connection request in the non-HSDPA layer, it is redirected to the HSDPA layer.

Page 67: HSDPA Performance Management

3-27

September, 20063-27HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

DCH or HSDPA(i.e. no re-direction)Terminating – cause unknown

DCH or HSDPA(i.e. no re-direction)Terminating Low Priority Signalling

DCH or HSDPA(i.e. no re-direction)Terminating High Priority Signalling

DCH or HSDPA(i.e. no re-direction)Call re-establishment – PS case

DCH or HSDPA(i.e. no re-direction)Call re-establishment – CS case

DCH or HSDPA(i.e. no re-direction)Originating Low Priority Signalling

HSDPAOriginating High Priority Signalling

DCH or HSDPA(i.e. no re-direction)Detach

HSDPARegistration

DCH or HSDPA(i.e. no re-direction)Inter-RAT cell change order

DCH or HSDPA(i.e. no re-direction)Inter-RAT cell re-selection

DCH or HSDPA(i.e. no re-direction)Emergency Call

HSDPATerminating Background Call

HSDPATerminating Interactive Call

DCHTerminating Streaming Call

DCHTerminating Conversational Call

HSDPAOriginating Subscribed traffic Call

HSDPAOriginating Background Call

HSDPAOriginating Interactive Call

DCHOriginating Streaming Call

DCHOriginating Conversational Call

Suitable layerSuitable layerSuitable layerSuitable layerEstablishment CauseEstablishment CauseEstablishment CauseEstablishment Cause

Multi-carrier HSDPA traffic segmentationProcedure description

Static mapping perfomed by the RNC between the Establishment Cause and the suitable layer (DCH or HSDPA):

Page 68: HSDPA Performance Management

3-28

September, 20063-28HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Multi-carrier HSDPA traffic segmentation Parameters

FalseBooleanC3isRedirectionBasedOnEstablishmentCause

(FddCell.InterFreqHho)

TrueBooleanC3isRedirectionForTrafficSegmentation(FddCell.InterFreqHho)

ValueRange & UnitClassParameter

(Object)

*The twin cell is considered HSDPA if declared such as the parameter under FddCellhsdpaActivation is equal to True.

**The value of isRedirectionBasedOnEstablishmentCause is taken into account only if isRedirectionForTrafficSegmentation is set to true.

Page 69: HSDPA Performance Management

3-29

September, 20063-29HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Accessibility

On the source cell:

#0138 VS.IntraRncOutInterFreqHoAttempt

screening R5 mobile to HSDPA layer

On the target cell:

#0140 VS.IntraRncIncInterFreqHoAttempt

screening R5 mobile to HSDPA layer

Number of R5 mobiles outgoing redirections toward a HSDPA layer

This metric gives the number of R5 mobiles (supporting HSDPA) that were redirected toward a HSDPA layer during the RRC connection establishment.

By choosing others screenings we can monitor also

• the number of R5 mobiles (supporting HSDPA) that were redirected toward a non-HSDPA layer during the RRC connection establishment. This case occurs when a R5 mobile tries to establish a RRC connection for non PS traffic purpose on a HSDPA layer and that traffic segmentation is activated.

• the number of non-R5 mobiles (not supporting HSDPA) that were redirected toward a non-HSDPA layer during the RRC connection establishment. This case occurs when a non- R5 mobile tries to establish a RRC connection on a HSDPA layer and that traffic segmentation is activated.

Page 70: HSDPA Performance Management

3-30

September, 20063-30HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Retainability

Page 71: HSDPA Performance Management

3-31

September, 20063-31HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Network Retainability Performance

> The objective of the retainability metrics is to evaluate the ability of the network to provide reliable service to the end user.

> If and only if a call is dropped , the RNC sends the RANAP Iu Release Request message with the field abnormal reasons.

> A good part of the calls dropped are originated by a Radio Link Failure Indication message (this is not the case for the calls dropped after a RLC reset).

Page 72: HSDPA Performance Management

3-32

September, 20063-32HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Total number of RABs

UE

RAB assigt resp*

(…)

(…)

RNCNode B

RRC Connection Setup

MSC

RANAP/RAB assigt req

RRC Connection Complete

#0622 RAB establishtsuccess

*RANAP/RAB assigt resp.: can be several responses.

Radio access bearer

assignment procedure

#0533: Number of Abnormal RELEASE Requests on Iu CS. This measurement represents the number of Iu CS release requests due to abnormal conditions. Screening: by DLAsConf.

Condition = on RNC requests Iu CS release due to abnormal conditions:

• O&M intervention

• Repeated integrity check failure

• Radio connection lost

• Relocation timeout (corresponding to timeout of TrelocoverallExpiry and TrelocCompleteExpiry)

• Unspecified failure

#0622: Number of RAB Establishments SUccess Per Requ ested RAB type. This measurement provides the number of successful RAB establishment, screened per requested RAB type (requested should be understood to be after RAB matching). Screening by RAB Type. Screening: by requested RAB Type.

Page 73: HSDPA Performance Management

3-33

September, 20063-33HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Abnormal Release Caused by RL Failure

Node B RNC CN

Radio Link Failure Indication

Radio Link Deletion Resp

Iu Release Req

#0533 Iu abnormal release request CS#0534 Iu abnormal release request PS

#0505 Iu release command CS#0506 Iu release command PS

#0013 Dropped Last Radio Links

Iu Release Command

Radio Link Deletion Req

Iu Release Complete

#0013: Number of dropped calls on last radio-link r elease. This measurement provides the number of dropped calls (on last radio-link release), for each cell controlled by the RNC. Screening: by DlAsConf.#0505: Number of RELEASE COMMANDs on Iu CS. This measurement provides the number of RANAP IU RELEASE COMMAND messages received by the RNC on Iu CS.#0506: Number of RELEASE COMMANDs on Iu PS. This measurement provides the number of RANAP “IU RELEASE COMMAND” messages received by the RNC on Iu PS.#505 & #506 screening:

• #0 --> Normal end of communication

• #1 --> Successful 3G/2G or 3G/3G relocation (3GPP RANAP cause 11)• #2 --> UTRAN generated reason (3GPP RANAP cause 15) or Iu_release_request sent by RNC

before

• #3 --> Other cause (all other 3GPP RANAP causes)

• #4 --> Relocation Cancelled (3GPP RANAP cause 10)

• #5 --> O&M Intervention (3GPP RANAP cause 113)

• #6 --> Unspecified Failure (3GPP RANAP cause 115)• #7 --> User Inactivity (3GPP RANAP cause 16)

• #8 --> No Remaining RAB (3GPP RANAP cause 31)#0533: Number of Abnormal RELEASE Requests on Iu CS. This measurement represents the number of Iu CS release requests due to abnormal conditions. Screening by DlAsConf (DL AS configuration). Screening: by DlAsConf.#0534: Number of Abnormal RELEASE Requests on Iu PS. This measurement represents the number of Iu PS release requests due to abnormal conditions. Screening by DlAsConf (DL AS configuration). Screening: by DlAsConf.

Page 74: HSDPA Performance Management

3-34

September, 20063-34HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Call Abnormal Release

#0540 Iu release request CS (cell)#0541 Iu release request PS (cell)#0546 Iu abnormal release request CS (cell)#0547 Iu abnormal release request PS (cell)

#0505 Iu release command CS#0506 Iu release command PS

Node B RNC CN

Radio Link Deletion Response

Iu Release Request

Iu Release Command

Radio Link Deletion Request

Iu Release Complete

#0544 Iu release complete CS#0545 Iu release complete PS

Issue detected

New counterCounters screenings updatedNo change

#540 (#541): This measurement provides the number of RANAP IU_RELEASE_REQUEST sent by RNC to Core Network CS (PS).

• Sub-Counter #0 : Release due to OAM intervention

• Sub-Counter #1 : Iu User-plane failure

• Sub-Counter #2 : Unspecified failure

• Sub-Counter #3 : Repeated Integrity protection check failure

• Sub-Counter #4 : Release due to UE

• Sub-Counter #5 : Radio connection lost with UE

• Sub-Counter #6 : Relocation too long (timer on relocation expiry).

• Sub-Counter #8 : DL RLC error on SRB

• Sub-Counter #9 : UL RLC error on SRB

• Sub-Counter #10 : DL RLC error on TRB

• Sub-Counter #11 : UL RLC error on TRB

#546 (#547): Number of Iu abnormal release request that increments whenever RNC requests Iurelease due to abnormal conditions to CS (PS) CN. Instance FDDCell / DlAsConf (Reference).

Dropped call KPIs will only be calculated on calls with an AsConfId (Q01158696-01). Some counters already exist for IU release requests: counters 540 and 541 (VS.IuReleaseRequestCs. And VS.IuReleaseRequestPs.) These ones are incremented for all cases (normal or abnormal); the normal cases are: - release due to UE generated signnaling connection relaese (abnormal TBC) - user inactivity (in case of always on) - Last remaining RAB all other cases are considred as abnormal. The abnormal cases currently covered are the following ones: - OandM intervention - Repeated integrity check failure -Radio connection lost - Relocation timeout (corresponding to timeout of TrelocoverallExpiry and TrelocCompleteExpiry) - Unspecified failure

Page 75: HSDPA Performance Management

3-35

September, 20063-35HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Call Drop Rate at RNC Level

> Separation of services (voice, video and data calls) => to facilitate the troubleshooting based on user behavior.

> Signaling is not considered anymore.

> The metric available in UA4.0 as defined is useful at RNC level or at network level but not at cell level.

> The main retainability issues detected by this issue: DL/ UL RF conditions, HW instability at PCM level and at RNC level.

Page 76: HSDPA Performance Management

3-36

September, 20063-36HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Call Drop Rate at RNC Level

Voice call drop rate = Voice call drop rate = ∑ #0533.[1,5,9,10,15,16,17,18]

∑ #0622.[1]

Video call drop rate = Video call drop rate = ∑ #0533.[0]

∑ #0622.[2]

Data ‘call’drop rate*

Data ‘call’drop rate*

∑ #0534.[2,4,6,7,9,10,11,12,15,16,17,18]

∑ #0622.[5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25]

=

*RAB drop rate

#0533: Number of Abnormal RELEASE Requests on Iu CS. This measurement represents the number of Iu CS release requests due to abnormal conditions by DL Access Stratum Configuration.

Screening: Downlink Access Stratum configurations:

• Containing CS: As Conf Id = {0, 1, 5, 8, 9, 10, 14, 15, 16, 17, 18}

• Containing PS: As Conf Id = {2, 4, 6, 7, 9, 10, 11, 12, 15, 16, 17, 18, 19, 20}

• Containing Speech: As Conf Id = {1, 5, 9, 10, 15, 16, 17 ,18}

• Pure CS: As Conf Id ={ 0, 1, 5, 8, 14 }

• Pure PS: As Conf Id ={ 2, 4, 6, 7, 11,12, 19, 20 }

• Multi-service (PS+CS): As Conf Id = {9, 10, 15, 16, 17, 18}

• Pure SRB: As Conf Id = {3, 13}

Note

While ‘containing PS’ includes screening [19] & [20], they are not in the data call drop rate because [19] = cellFACH and [20] =interworking V2.

#0622: Number of RAB Establishments Success Per Req uested RAB type. This measurement provides the number of successful RAB establishment, screened per requested RAB type (requested should be understood to be after RAB matching).

Page 77: HSDPA Performance Management

3-37

For CS domain: separation of voice and video results to easily identify the CS service the most impacted

For PS domain: the PS Retainability results are dependant on the number of PS RAB and so the results could be impacted by changing the Always-On Parameters

On RNC requests Iu CS release due to abnormal condit ions :

• O&M intervention

• Repeated integrity check failure

• Radio connection lost

• Relocation timeout (corresponding to timeout of TrelocoverallExpiry and TrelocCompleteExpiry)

• Unspecified failure

September, 20063-37HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Call Drop Rate per RAB established

Call drop Rate = Number of drops / Number of RAB su ccess per granted RAB type CS CDR = (∑#0546.[0,1,5,9,10,15,16,17,18,21,22,26,28,29,30])/∑#0623.[1,4]) Voice CDR = (∑#0546.[1,5,9,10,15,16,17,18,22,26,28])/∑#0623.[1]) Video CDR = (∑#0546.[0,21,29,30])/∑#0623.[2]) PS RAB Drop Rate = (#0547.[2,4,6,7,8,9,10,11,12,14,15,16,17,18,21,22,23,24,26,27,28,29,30])/(∑#0623.[0,5-50])

Update since 4.1 : new screenings

HSDPA Call drop rate = ( ∑#0547[27] / (∑#0623 .[43-50]

Page 78: HSDPA Performance Management

3-38

September, 20063-38HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Call drop rate per released calls - celllevel

Call drop rate per released calls = Number of drops / (Number of normalyand abnormaly terminated calls)

CS Call drop rate at cell level =Iu abnormal release requests CS / Iu release complete CS= ∑#0546 ( CS DlAsConfid) / ∑#0544 ( CS Dl AsConfid)

PS Call drop rate at cell level =Iu abnormal release request PS / (Iu abnormal release r equests PS + Downsizing Step 2 ( PS Dl ASConfid) + Radio Bearer re lease success ( PS + FACH) )

= ∑ #0547 ( PS Dl Asconfid) / ( ∑ #0547 ( PS DlAsConfId) + ∑ #1105 ( PS DlAsConfId) + ∑ #0608 ( PS + Fach) )

Update since 4.1 : new screenings

Impacted by HSDPA

Included in PS metric

Top N worst cells can be evaluated with the number of call dropped at cell level building on the counter

Number of Iu CS/PS release requests due to abnormal conditions (#0546/0547)

Page 79: HSDPA Performance Management

3-39

September, 20063-39HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Number of drops per minute of RAB

Number of drops per mn of RAB =

Iu abnormal release requests / Allocation time of the RAB60*10* (∑∑∑∑ VS.IuAbnormalReleaseRequestCs /PS [CS/PS DlAsConfIdscreenings] / ∑∑∑∑ VS.DlAsConfIdAvgNbrEstablished. CUM [CS/PS DlAsConfIdscreenings])

Number of drops per mn of HSDPA Call = 600*#0547[27] / #0660.Cum [27]

Update since 4.1 : new counter

This metric allows to count the number of drops versus the duration of the RAB. It isbased on

• #0546 / #0547 Iu abnormal release requests CS/ PS at reference cell level

• #0660 VS.DlAsConfIdAvgNbrEstablished: Average number of DlAsConfIdsestablished per iRNC at reference cell level

Page 80: HSDPA Performance Management

3-40

September, 20063-40HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Traffic

Page 81: HSDPA Performance Management

3-41

September, 20063-41HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Average Number of calls

> The average number of calls is based on the counter: • average number of established RAB in the RNS, per TC+UL/DL Bit rate, during a

reporting period. (#0627)

• This metric can only be monitored at RNC level

> At Cell Level the metric is based on• Average number of DlAsConfId (#0660 in DL, #0661 in UL ) and is screened per

AsConfId

Average number of Voice calls = #0627. Avg[1] Average number of video calls = #0627.Avg[2] Average number of PS calls = #0627.Avg[0,5-42]

Update since 4.1 : new screenings, new counter at cell level

Average number of Voice calls = #0660. Avg[ 1,5,9,10,15,16,17,18,22,26,28] Average number of video calls = #0660.Avg[ 0,21,29,30] Average number of pure PS calls =#0660.Avg [2,4,6,7,8,9,10,11,12,14,15,16,17,18,21,22,23,24,26,28,29,30]

Average number of HSDPA calls = #0627.Avg[43-50]

Average number of HSDPA calls = #0660.Avg[27]

Page 82: HSDPA Performance Management

3-42

September, 20063-42HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Uplink/ Downlink PS Traffic

DL PS Traffic per RNC = ∑#1443.[0,5,6,7,8,9,10,11,12,13,15,16,17,18,19,20]

UL PS Traffic per RNC = ∑#1442.[0,5,6,7,8,9,10,11,12,13,15,16,17,18,19,20]DL PS Traffic per reference cell = ∑#1459.[0,5,6,7,8,9,10,11,12,13,15,16,17,18,19,20]UL PS Traffic per reference cell = ∑#1458.[0,5,6,7,8,9,10,11,12,13,15,16,17,18,19,20]

Update since 4.1 : new screenings

Available for HSDPA

The Downlink PS Traffic metric and Uplink PS Traffic metric aim at providing the amount of data traffic

This global information is interesting to correlate with eventual decrease of network performance results (e.g. congestion)

These metrics are based on the following counters :the number of downlink/uplink RLC payload in kbytes on dedicated channels at RNC level (#1443/ #1442)

the total count of downlink/uplink RLC payload in kbytes on dedicated channels at reference cell level (#1459/ #1458)

the total count of downlink/uplink RLC payload in kbytes on dedicated channels for each cell of the active set (#1457/ #1456)

The amount of traffic can be monitored per UL/DL Bit rate and so identify the main bearers which convey the main traffic

Page 83: HSDPA Performance Management

3-43

September, 20063-43HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Throughput DL per Combined DL/UL max bit rate at RNC level

Troughput DL /UL per Combined DL/ UL max bit rate at RNC level (Kb/s)=8*1.024*10* [ ΣΣΣΣ VS.DedicatedDown /UplinkKbytesRlc( UL/DL Bit rate) / ΣΣΣΣVS.NumberOfRabEstablished.Rab. Cum (UL/DL Rab type)]

Update since 4.1 : new screenings

Available for HSDPA

Throughput metrics are necessary to assess the quality of the network and can becorrelated to congestion resultsThese metrics are based on the following counters

Number of Kbytes of SDU payload received/sent on dedicated uplink/downlink RLCs (#1442 / #1443 )Time that CS/PS RAB is allocated (#0627 * observation time)

Throughput can be monitored per UL/DL Bit rate at RNC level

Page 84: HSDPA Performance Management

3-44

September, 20063-44HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

HSDPA DL Kbytes ( SDU payload)

1459.RabPsIBHsdpa_32U+1459.RabPsIBHsdpa_64U+1459.RabPsIBHsdpa_128U+1459.RabPsIBHsdpa_384U

The HSDPA traffic carried from a RNC perspective on the primary cell can be monitor with the counter

#1459 VS.DedicatedDownlinkKbytesRlcReferenceCell

The retransmissions are not counted

Page 85: HSDPA Performance Management

3-45

September, 20063-45HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

NodeB Scheduler

Page 86: HSDPA Performance Management

3-46

September, 20063-46HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

First Stage Principles

Credits Computation

Cost Function Evaluation

PQ0 PQ15

QId0 QId1 QIdN QId0 QId1 QIdN

PQ0 COST PQ15 COST

Lowest Cost PQ Selection

already transmitted bitscreditsCOST =

Function of:• QIds number• PQ weight (priority)• number of active PQs• total bandwidth

The aim of the scheduler is to dynamically share available DL bandwidth among users, in order to optimize the overall throughput, and fulfill network and UE criteria. In order to separately manage the two aspects, the scheduler is divided into two stages:

The first stage deals with priorities (CmCH-PI) assigned by higher layers on the different queues for choosing queues which will be served in the coming transmission interval.

The selection and change of priority queue is based on a cost function for each priority queue. These cost functions will determine what is the queue to be serviced first in the next TTI. The queue with the lowest cost function is selected. Cost functions simply rely on two parameters, the credits of the queue and the total number of PDUs already transmitted during past rounds.

Page 87: HSDPA Performance Management

3-47

September, 20063-47HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Second Stage Principles

QId0 QId1 QIdN

Retransmissions First

New Transmissions

Round Robin Fair CQI Proportional Fair

UE Capabilities Available Power & Codes ACK/NACK/CQI Previously Transmitted PDUs

UE #0• power• codes• number of bits

UE #1• power• codes• number of bits

UE #N• power• codes• number of bits

The second stage takes care of radio conditions and UE capabilities to determined what users belonging to the selected queue will get access to radio resources in the coming transmission interval.

A preliminary allocation phase consists in scheduling retransmissions before allocating resources to new transmissions. In case retransmissions are scheduled in the coming TTI, the amount of power available for transmissions of new transport blocks is reduced accordingly.

For new transmissions, the decision of the scheduler is based on a cost function. UE selection is a tradeoff between the throughput optimization and the equity among UEs.

Page 88: HSDPA Performance Management

3-48

September, 20063-48HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

SPI Configuration

priorityLevel (SpiConfiguration)

backgroundSpi (SpiConfiguration)

interactiveSpi (SpiConfiguration)

RadioAccessService

RNC

HsdpaRncConf

SpiConfiguration

SpiConfiguration

SpiConfiguration

PQ0 PQ15

QId0 QId1 QIdN QId0 QId1 QIdN

SecondStage

FirstStage

NodeB Scheduler

Background Interactive

gold 15 15

silver 7 7

bronze 0 0

OLSUMTS TRAFFIC CLASS

Before entering the scheduler, the Mac-d PDUs for each queue of each user are classified according to their corresponding priority (CmCH-PI). Every TTI, the scheduler is launched in order to efficiently assign the available resources (number of codes and remaining power) to the different users.

The selection of a priority queue is based on a cost function that takes into account credits assigned to each priority queue and the number of Mac-d PDUs already transmitted in the last TTI for these queues.

The aim is to provide some throughput per queue according to its priority (SPI): the higher the priority (the higher the SPI), the higher the allocated bandwidth.

Page 89: HSDPA Performance Management

3-49

September, 20063-49HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Traffic

#10804.CUM / #10818

Average number of scheduled UE

The average number of scheduled UE is based on the counters

• #10804 VS.HsdpaHSSCCHCodesPerTTI : Number of HS-SCCH codes used per TTI ( then gives the number of UEs in the TTI)

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

Page 90: HSDPA Performance Management

3-50

September, 20063-50HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Traffic

During one hour

(VS.HsdpaTTIsUsed*0.0020) / 3600.0)

HSDPA activity rate

The HSDPA activity rate allows to compute the rate of TTI containing at least one scheduled UE.

This metric is used to see the rate of usage of HSDPA resources on the node B.

This metric is based on counter

#10818 VS.HsdpaTTIsUsed : number of TTI which have scheduled at least one UE

HSDPA activity rate =

Number of TTI containing at least one scheduled UE * duration of a TTI (s) / observation period (s)

Page 91: HSDPA Performance Management

3-51

September, 20063-51HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Adaptive Modulation and Coding

Page 92: HSDPA Performance Management

3-52

September, 20063-52HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

CQI Reporting Principles

-15-14-13-12-11-10-9-8-7-6-5-4-3-2-1000000000000000

∆∆∆∆

33195283319527331952633195253319524331952333195223319521331952033195193319518

33195303319529

33195173319516331951525834142279413174231214833111262310931297922865027461163771531714233131731213711

out of range0TBSOVSFCQI

P-CPICH

HS-DPCCH

Target BLER ≤ 10%

PHS-PDSCH

=PP-CPICH + Γ + ∆

2ms

The procedure to allocate power to the HSDPA traffic channel described in the standard is mainly based on terminal measurements and reporting.

In this procedure the UE monitors continuously (i.e. every 2 ms) CPICH received power (i.e. EcNo and RSCP) and derives the next CQI value to be sent to BTS based on some mapping tables CPICH EcNo (or RSCP) vs. CQI (UE implementation dependent). These mapping tables assume a BLER = 10% on the first transmission of HS-PDSCH (quality requirement ). However the mapping tables are based on off-line simulations and therefore they do not account for the actual RF conditions. Due to the variability of RF environment, it is possible that BLER on HS-PDSCH is larger than target of 10% leading to lower than expected throughput.

HS-PDSCH power estimates are based on the UE measurement of the power of the Primary Common Pilot CHannel (P-CPICH) (see formula in the above slide). Γ is the Measurement Power Offset, provided by the RNC to the NodeB via NBAP signaling and to the UE via RRC signaling. This is a fixed offset relatively to the power of the P-CPICH. ∆ is the Reference Power Adjustment, which depends on the CQI value reported by the UE and on the category of the UE (CQI mapping tables).

UE sends the CQI back to the NodeB onto the HS-DPCCH.

Page 93: HSDPA Performance Management

3-53

September, 20063-53HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

CQI Modification Principles

Scheduler

HS-DPCCH demodulation

CQI Averaging

CQI adjustment based on BLER and DTX

CQI update due to:• Power limitation• Codes limitation• MAC-hs buffer occupancy • MAC-d PDU size

UL Synchronization failure detection

CQIreported

CQIaveraged

CQIprocessed

CQIapplied

Between the decoded CQI and the applied CQI, many transformations are processed.

First level of CQI modifications is performed to take into account possible RL synchronization loss detections, CQI average over successive TTIs and the CQI defense mechanisms to handle DTX and BLER problems.

Second level of CQI modifications is performed by the NodeB Scheduler. It aims at dynamically aligning the Transport Format with the current resources availability.

Transport formats always remain based on the CQI mapping tables. Two different CQI correspond to different transport formats with the same power to reach the same performance level, but could also correspond to two different powers with the same transport format. A step of 1dB is considered to go from one CQI to the next one.

The transport format is determined according to the processed CQI, CQIprocessed. In case of a lack of resources (codes or power), the applied CQI, CQIapplied, is then modified according to the previous rule to take this into account. It is done in four steps:

• power limitation management,

• codes limitation management,

• lack of MAC-d PDU in buffer,

• optimization of CQI according to MAC-d PDU size.

Page 94: HSDPA Performance Management

3-54

September, 20063-54HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

HSDPA specific traffic metrics DL HSDPA radio traffic

> It is based on the counter

> This metric is at cell level and its unit is in Kbit

New 4.2

#10809 VS.HsdpaTxDataBitsSchedTotal

This measurement provides the total number of data bits (transport block size) scheduled any TTI, taking into account the retransmissions. Any time a block is retransmitted, its bits are added.

Page 95: HSDPA Performance Management

3-55

September, 20063-55HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

HSDPA specific traffic metric MAC-HS throughput and Cell throughput

Mac-HS throughput (useful throughput)=

Number of bits transmitted for the first time by the node B / Time of transmission ( number of TTI * 2 ms)

500*(VS.HsdpaTxDataBitsMAChs.Cum / VS.HsdpaTTIsUsed )

Cell throughput =

Number of bits transmitted /Time of transmission

500*(VS.HsdpaTxDataBitsSchedTotal / VS.HsdpaTTIsUsed )

New 4.2

Throughput from Node B or cell perspective are based on the total number of data bits (transport block size) first transmitted or withretransmission by the MAC-hs divided by the number of TTI scheduling UE

It is based on counters#10808 VS.HsdpaTxDataBitsMAChs : number of bits transmitted at

Mac-Hs level ( without repetitions)or

#10809 VS.HsdpaTxDataBitsSchedTotal :number of bits transmitted at Mac-Hs level ( with retransmissions)

#10818 VS.HsdpaTTIsUsed : number of TTI which have scheduled at least one UE

Page 96: HSDPA Performance Management

3-56

September, 20063-56HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Mac-d Throughput per cell

Rate of Mac-d PDUs successfully transmitted (i.e. which has received an ACK) compared the number of TTI (kbit/s) per cell

• #10806 VS.HsdpaMACdPDUAckBits• #10818 VS.HsdpaTTIsUsed

Mac-d Throughput per cell =

500*(VS.HsdpaMACdPDUAckBits.Cum / VS.HsdpaTTIsUsed )

New 4.2

Page 97: HSDPA Performance Management

3-57

September, 20063-57HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Quality

Page 98: HSDPA Performance Management

3-58

September, 20063-58HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

MCPAPower

HSDPA Power Management Principles

UE selected

Ptemp = PHSDPA – PHS-SCCH

Ptemp > 0?

UE not scheduled

Yes

No

Go to Next Step

CmCH

DCH margin

PHSDPA

DCH

HS-DSCH

HS-SCCH

HSDPA power management is based on the principle that HSDPA channels can use all the remaining power left by dedicated and common channels. In order to compensate the DCH power fluctuation mainly due to power control, a margin is considered (dchPowerMargin).

The total available power for HSDPA corresponds to the difference between the maximum available power in the cell and the power for R99 channels plus margin.

A UE is scheduled only if there remains enough power to transmit at least the HS-SCCH. Otherwise the NodeB try to schedule another UE in the TTI. If all UEs require power for HS-SSCCH higher than what is available at NodeB level, none of them is scheduled.

Page 99: HSDPA Performance Management

3-59

September, 20063-59HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

First Tx Power Allocation Principles

PHS-DSCH = PP-CPICH + ΓΓΓΓ + ∆∆∆∆(CQI)

PHS-DSCH < Ptemp?P’HS-DSCH = PP-CPICH + ΓΓΓΓ

∆∆∆∆RP = round(10.log(P temp / P’HS-DSCH))

CQIRP = CQI + ∆∆∆∆RP

∆∆∆∆RP = 0

CQIRP = CQI

CQIRP > 0?ncodes = f(CQIRP)

UE not scheduled

UE selected (Ptemp > 0)

Yes

No

YesNo

Go to Next Step

In case there doesn’t remain enough power to transmit data corresponding to the processed CQI to a selected UE, the transport format is modified in order to reduce its power.

The excess power, corresponding to the total needed power minus the maximum allowed power, is computed. This value, expressed in dB, then directly indicates the number of CQI levels one should decrease in order to remain at the same level of performances. In case the resulting value is not valid CQI (≤0), the UE is not scheduled.

If such a modification is not possible, the UE is not scheduled.

Page 100: HSDPA Performance Management

3-60

September, 20063-60HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Retransmission Principles

Yes

UE selected (retransmission nb > 0)

1st Tx Power<

Remaining Power?

No

UE scheduledTransmitted Pwr = 1st Tx power

Another UE scheduled in TTI?

UE scheduledTransmitted Pwr = Remaining power

UE not scheduled

Yes

No

In case of retransmissions, the HS-SCCH power must be based on the current CQI and not on the first transmission one.

Nevertheless, for retransmissions, there is no modification of the Transport Format used for the first transmission. Meaning that the NodeB tries to re-allocated exactly the same power as the one used for the first transmission.

Page 101: HSDPA Performance Management

3-61

September, 20063-61HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

HSDPA Retransmission rate

(#10809 - #10808) / #10808

This metric allows to compute the rate of retransmissions.

It characterizes the quality of the transmission.

It is based on counters

#10808 VS.HsdpaTxDataBitsMAChs : number of bits transmitted at MacHS level for the first time

#10809 VS.HsdpaTxDataBitsSchedTotal : number of bits scheduled ( including repetitions)

Page 102: HSDPA Performance Management

3-62

September, 20063-62HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Iub Bandwidth Limitation

Baseline : no congestion management => poor Iub link utilization

0100020003000400050006000700080009000

10000

14:0

3:30

14:0

4:04

14:0

4:38

14:0

5:13

14:0

5:47

14:0

6:21

14:0

6:55

14:0

7:29

14:0

8:03

14:0

8:37

14:0

9:11

14:0

9:45

14:1

0:19

14:1

0:53

14:1

1:27

14:1

2:01

14:1

2:34

14:1

3:08

14:1

3:39

Time

cells

/sec

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

16:53

:54

16:54

:14

16:54

:34

16:54

:54

16:55

:14

16:55

:35

16:55

:55

16:56

:15

16:56

:35

16:56

:55

16:57

:15

16:57

:35

16:57

:55

16:59

:26

16:59

:46

17:00

:06

17:00

:26

17:00

:46

17:01

:06

17:01

:26

17:01

:46

17:02

:06

17:02

:26

17:02

:47

17:03

:08

17:03

:28

17:03

:48

17:04

:08

17:04

:28

17:04

:48

17:05

:08

17:05

:29

17:05

:49

17:06

:09

17:06

:30

17:06

:50

17:07

:10

17:07

:30

17:07

:50

17:08

:10

17:08

:30

17:08

:50

17:09

:10

Time

cells/sec

Iub limitation handling : 100% Iub efficiency

Voice Video-telephony : QoS 0

Data (R99) : QoS 1

Data (HSDPA) : QoS 2

Aggregate Iub Throughput

FEATURE BENEFITS

This feature will improve Iub bandwidth utilization when HSDPA is activated, by allowing provisioning Iub with less bandwidth than what would be required in theory to carry the traffic generated by the NodeB in worst case scenarios.

With HSDPA, the effective throughput per UE is quite variable. A flow control mechanism has been introduced between the Mac-d (RNC) and the MAC-hs(NodeB) entities in order to fill the NodeB buffers with sufficient data to provide for the UEs and be quite reactive to throughput variations.

This flow control is based on three main procedures:

• The Capacity Request procedure that provides means for the CRNC to indicate for each session of each UE its buffer occupancy (at MAC-d level).

• The Capacity Allocation procedure generated by the NodeB to indicate to the RNC how many MAC-d PDUs are required for the desired session and the interval in which these data should be sent, based on the estimated throughput for this session and the number of remaining MAC-d PDUs in NodeBtransmission buffer.

• The HS-DSCH data transfer procedure in which the RNC sends the MAC-d PDUsgrouped in FP frames (1 to 255 PDUs per FP frame). The updated buffer occupancy is also given. The RNC may choose to send all the required MAC-d PDUs in a single FP frame, or to space out (within the notified interval) the transmission in several FPs.

Page 103: HSDPA Performance Management

3-63

Control of Iub Bandwidth at ATM level is not efficie nt

ATM Discard is not efficient (corrupted FP frame waste bandwith)

ATM Discard doesn’t take into account Diversity Traffic (Soft HO)

HSDPA Traffic has very little timing constraint

Due to MAC-hs flow control, HSDPA Traffic on Iub can be very bursty

Iub Bandwidth Limitation is moved to Packet Converte r (from ATM):

PC monitors the available bandwidth on Iub

PC monitors the amount of data to transmit on Iub link

For NDS and HSDPA Traffic, if a threshold is exceeded, the PC sends some control frames to the PMC RAB that are generating some HSDPA traffic (i.e. FP Frame) to stop Frame Processing: this is called back-pressure mechanism

Iub Bandwith limitation is not applicable on Iur as th e PC (for Iub) and the PMC RAB are not in the same RNC !

September, 20063-63HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Iub Bandwidth Limitation - Principle

> Control of Iub Bandwidth at ATM level is not efficient

> Iub Bandwidth Limitation is moved to Packet Converter (from ATM):

> Iub Bandwith limitation is not applicable on Iur as the PC (for Iub) and the PMC RAB are not in the same RNC !

Page 104: HSDPA Performance Management

3-64

September, 20063-64HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Iub Bandwidth Limitation – F. A.

> Using WIPS, to activate the feature, you need to:• Under Interface Node, RncIn, fc (FlowControl)

• Set iubFlowControlActivation to discardAndBackPressure• Set qosBackPressureThreshold and qosDiscardThreshold to the

recommended values

> qosDiscardThreshold defines the thresholds before starting to discard FP Frames in the Packet Converter: the discard should not happens if the threshold are correctly set.

> qosBackPressureThreshold defines the thresholds (relative to the ones above) before starting to back-pressure in PMC RAB

> First value of qosBackPressureThreshold and qosDiscardThreshold must be 0 (DS Traffic)

> Second value of each set affects NDS Traffic

> Third value of each set affects HSDPA Traffic

Page 105: HSDPA Performance Management

3-65

September, 20063-65HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Downlink BLER PS

BLER PS = BLER PS = #1462.[0,3,7,8,9,10,13,14,16]

#1461.[0,3,7,8,9,10,13,14,16]

BLER PSat 64kbps

BLER PSat 64kbps

# 1462.[0,7,8]

# 1461.[0,7,8]=

BLER PSat 128kbps

BLER PSat 128kbps

# 1462.[10]

# 1461.[10]=

BLER PSat 8kbps

BLER PSat 8kbps

# 1462.[9,13,14]

# 1461.[9,13,14]=

BLER PSat 32kbps

BLER PSat 32kbps

# 1462.[3,16]

# 1461.[3,16]=

The CS metric is not significant because speech is made of a lot of blanks, and those blanks have good CRC! It misleads the results.

In the downlink case a drive test is necessary. Indeed there is no counters and no mobile does the measurement.

For better analysis and correlation DL and UL measurement are necessary at the same time.

#1461: This measurement provides the number of downlink RLC PDU emitted on dedicated channels on the reference cell.

#1462: This measurement provides the number of downlink RLC PDU retransmitted on dedicated channels on the reference cell. This counter is only pegged for RLC AM bearer (so only for PS). This is incremented for the Current RAB and any RLC PDU (Q01371476). screenings 1, 2, 3, 4 are always zero because RLC cannot provide TM mode (Q01262533).

Page 106: HSDPA Performance Management

3-66

September, 20063-66HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Uplink BLER PS

BLER PS = BLER PS = #1444.[0,3,7,8,9,10,13,14,16]

#1451+1444.[0,3,7,8,9,10,13,14,16]

This metric must be computed by RB..

#1444 This measurement provides the number of Uplink RLC PDU received on dedicated channels. This is incremented for the Current RAB and any RLC PDU received (Q01371476). Notes: in cases where data is transmitted on coordinatedtransport channels, the frames of each subflow are not counted independently. The PDU and SDU counters are incremented only once for each set of frames receivedor sent. An RLC PDU is a frame sent (see TS 25.322) from the RLC to the MAC (or vice versa). For CS voice, counting occurs for data frame, SID frame and emptyframe. Empty frames are being counted for BLER reason (Q01168175). For bearerswhere RLC is in transparent mode, this counter also includes received frames thatcontain no payload.

#1451 This measurement provides the total number of Transport Blocks received with CRCi = 1 (transport block contains errors) on a CS or PS bearer (this does not include SRBs). For voice, CRCi only applies to Class A bits.

Page 107: HSDPA Performance Management

3-67

Student notes

Page 108: HSDPA Performance Management

3-68

September, 20063-68HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Congestion

Page 109: HSDPA Performance Management

3-69

September, 20063-69HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

HS-SCCH Power Control Activation

P-CPICH

HS-SCCH

-8 dB13 – 30

-5 dB10 – 12

-3 dB8 – 9

0 dB1 – 7

Power OffsetCQI

distance

HS-SCCH to P-CPICHPower Offset

hsscchPcOffset (HsdpaConf)

BTSCell

BTSEquipment

HsdpaConf

There is no true power control mechanism on HS-SCCH and a CQI-based power control procedure is implemented instead.

A direct relation between the quality of DL radio conditions and the amount of power to be allocated to the HS-SCCH is used. The worst the DL radio conditions, the smallest the CQI and the greatest the power to be allocated to the HS-SCCH. The principle then consist in associating a power offset (relative to P-CPICH power) to the HS-SCCH depending on the reported CQI value. The power allocated for HS-SCCH is derived from the CQI reported by the mobile in order to adapt the transmission power to radio conditions.

HS-SCCH Power Control is configured through a table that gives a power offset relative to P-CPICH for each CQI value (hsscchPcOffset parameter in HsdpaConfobject). If all the 30 values of this table are set to the same exact value, then the HS-SCCH Power Control is disabled, otherwise it is activated. The value of power offsets shown in the above table are the current recommended values.

Page 110: HSDPA Performance Management

3-70

September, 20063-70HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Congestion

#10817 VS.HsdpaPAOverload

PA overload

This counter gives the number of periods for which the total transmitted power for HSDPA exceeded 90% of the maximum cell power configured.

It allows to identify the cells overloaded

Page 111: HSDPA Performance Management

3-71

September, 20063-71HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Always On for HSDPA

Page 112: HSDPA Performance Management

3-72

September, 20063-72HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Principles

CELL_DCHCELL_DCH(DCH/HS(DCH/HS--DSCHDSCH))

CELL_FACHCELL_FACH(RACH/FACH)(RACH/FACH)

PMMPMM--idleidle

UL and DL Low Usage(HSDPA T1 expiry)

UL or DL Traffic

UL or DL

High Usage

UL and DL Inactivity(TRB on CELL_FACH T2 expiry)

UL and DL Low Usage(HSDPA T2 expiry)

For each user mapped on HSDPA, the RNC monitors the traffic in UL and DL.

DOWNSIZING STEP 1

• If UL and DL user traffic falls below the configured throughput threshold during timerT1ForHsdpa, the UE is moved to CELL_FACH.

DOWNSIZING STEP 2

• If UL and DL user traffic equal to zero during timerT2ForHsdpa, the RRC connection is released and the UE is moved to Idle Mode (PDP context is kept).

UPSIZING

• When in CELL_FACH, upsizing (back to CELL_DCH) is triggered as soon as UL or DL DCH buffer is above configured thresholds.

Always-On step 1 (downgrade) is supported but only towards Cell_FACH, using an asynchronous RB Reconfiguration. Once the reconfiguration has been performed, all RLs are deleted. If there is a CAC failure on FACH then the call is released.

Always-On upgrade is supported, coming from Cell_FACH. The RL is allocated first on the BTS. The RB is then reconfigured to HSDPA (if the cell supports HSDPA, else it is reconfigured to DCH) using an asynchronous RB Reconfiguration. If there is a CAC failure on HSDPA then the call is released.

Page 113: HSDPA Performance Management

3-73

September, 20063-73HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Activation

timerT1ForHsdpa

timerT2ForHsdpa

isAlwaysOnAllowed

preferredTransportTypeForAlwaysOn

RNC

DlRbSetConf UlRbSetConfDlUserService UlUserService AlwaysOnConf

AlwaysOnTimer

isAlwaysOnAllowed isAlwaysOnAllowed

disabled ����

degraded2AlwaysOnOnly ����

releaseOnly ����

true ����false ����

As in R99 isAlwaysOnAllowed must be set to TRUE so that AO is enabled At RNS level. For HSDPA the only supported mode for AO Step 1 is CELL_FACH. Consequently the parameter preferredTransportTypeForAlwaysOn has to be set to FACH when AO Step 1 and 2 are to be used for HSDPA. Otherwise, when HSDPA is configured to run on Release Only mode, FACH or DCH are both acceptable values.

The list of user services that are eligible to AO is given through the parameter isAlwaysOnAllowed in DlUserService and UlUserService objects. For the HSDPA DlUserService this parameter should be set to TRUE.

The parameter isAlwaysOnAllowed in DlRbSetConf and UlRbSetConf objects determines the behavior of each Radio Bearer when the always on downsize is triggered. It can take the following values:

• degraded2AlwaysOnOnly means that the downsize is allowed.

• ReleaseOnly means that there is no intermediate downsize.

• Disabled means that the Always On feature is disabled for this Radio Bearer.

For the HSDPA DlRbSetConf the parameter isAlwaysOnAllowed should be set to degraded2AlwaysOnOnly.

The recommended values for the parameters timerT1ForHsdpa and timerT2ForHsdpa are of 10s and 60s respectively.

Page 114: HSDPA Performance Management

3-74

September, 20063-74HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Always – On metrics

Downsizing step 2 vs downsizing step 1 (Source DlAsConfId) =

(# 1105 + #1106) / (#1101 +#1102)

Upsizing attempt (Target DlAsConfId) vs. downsizing step 1 (source DLAsconfid) =

(#1107 +#1108+ #1109 +#1110 ) / (#1101 +#1102)Available for HSDPA

Update since 4.1 : new screenings

Impacted by HSDPA

Included in global metric

Always-On feature allows to reduces or release the allocated resources when timeractivity expires

Metrics monitoring always-on are based on the following counters :• number of downsizing step 1 successes (#1101 for SRNC, #1102 for DRNC)

• number of downsizing step 1 unsuccesses (#1103 for SRNC, #1104 for DRNC)

• number of downsizing step 2 successes (#1105 for SRNC, #1106 for DRNC)

• number of upsize successes (#1107 for SRNC, #1108 for DRNC)

• number of upsize unsuccesses (#1109 for SRNC, #1110 for DRNC)

The metrics can be computed at RNC or cell level and are screened per DlAsConfId

Page 115: HSDPA Performance Management

3-75

September, 20063-75HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

HSDPA and Multi-Service

Page 116: HSDPA Performance Management

3-76

September, 20063-76HSDPA Performance Management

3FL12855AAAAWBZZA Ed 2

Principles

PS I/BPS I/BHSHS--DSCHDSCH

PS I/B + PS I/BPS I/B + PS I/BDCHDCH

CS + PS I/BCS + PS I/BDCHDCH

IDLEIDLEFACHFACH

CS setupPS setup

AO downgrade PS releasePS setupAO upgrade

PS release CS release

Multi-service (CS+PS or PS+PS or CS+PS+PS) is not served using HSDPA. There is an automatic switching to DCH (on the same cell).

Prior to the switching, CAC on DCH is performed as usual and if it is not possible to allocate the necessary resources on DCH, the incoming RAB is rejected.

When one of the RAB is released, the call is switched to HSDPA if only one PS I/B RAB remains. Prior to the switching, CAC on HSDPA is performed and the call is released if the CAC fails.

Transition to HSDPA is only applicable to the case where the primary cell of the active set supports HSDPA. If it does not support HSDPA, the call is mapped on DCH.

The call release is initiated either by the mobile or the network through a PDP context de-activation procedure, or by the RNC (Always-On step 2).

Always-On step 1 (downgrade) is supported but only towards Cell_FACH.

Always-On upgrade is supported, coming from Cell_FACH.

Page 117: HSDPA Performance Management

3-77

Student notes

Page 118: HSDPA Performance Management

3-78

Student notes

Page 119: HSDPA Performance Management

3-79

Student notes

Page 120: HSDPA Performance Management