CEM Optimization

FSD_123827_PQ3 load reduction on xCEM and eCEM

FSD-123827_PQ3 load reduction on xCEM and eCEM (Step1)Document Number: UMT/SYS/APR/XXXXDocument Issue: 01.02 / ENDocument Status: DraftDate: 01/April/2011 Alcatel-Lucent - Internal - Proprietary - Use pursuant to Company instructionCopyright 2010 Alcatel-Lucent, All Rights Reserved

UNCONTROLLED COPY:

The master of this document is stored on an electronic database and is write protected; it may be altered only by authorized persons. While copies may be printed, it is not recommended. Viewing of the master electronically ensures access to the current issue. Any hardcopies taken must be regarded as uncontrolled copies.

ALCATEL-LUCENT CONFIDENTIAL:

The information contained in this document is the property of Alcatel-Lucent. Except as expressly authorized in writing by Alcatel-Lucent, the holder shall keep all information contained herein confidential, shall disclose the information only to its employees with a need to know, and shall protect the information from disclosure and dissemination to third parties. Except as expressly authorized in writing by Alcatel-Lucent, the holder is granted no rights to use the information contained herein. If you have received this document in error, please notify the sender and destroy it immediately.

Contents dOCUMENT iNFORMATION61Introduction61.1Object61.2Scope of this Document61.3Audience for this Document61.4Waivers and Exceptions62RELATED DOCUMENTATION62.1Applicable Documents62.2Applicable Standards62.3Reference Documents6Customer Requirements and Market Information73FEATURE Information73.1Impacted Network Element(s)73.2Feature Order Type:73.3Internal / External Feature73.4Requested Releases73.5Feature Overview73.5.1Feature Description73.5.2Market Information73.5.3FEATURE BENEFITS73.6Customer Scenarios73.7Customer Requirements73.7.1Customer Requirements List73.7.2Customer Specific Requirements10Feature Technical Description114Feature Definition114.1Principles / Reference Architecture114.2Assumptions114.3Solution Options114.3.1Selected Option114.3.2Alternative Options114.4Feature Dependencies114.4.1Features dependent on this feature114.4.2Features this Feature is dependent on114.4.3Peer to Peer Dependency / Interactions114.4.4Impact on SDS Document114.5Use Cases / Scenarios124.6Requirements134.7Inter Sub-System Functional Distribution134.7.1Sub System Impacts134.8Performance Impacts134.8.1System Performance134.8.2Dimensioning134.8.3Capacity134.8.4Dependability, Availability and Reliability134.8.5End User Performance144.8.6Core KPI Assessment144.9Security144.10Environmental Impacts144.11Standards (Compliance and Support)144.12Licensing and Billing System Impact144.13Upgrade Requirements144.13.1Pre-Checks144.13.2Functionality Change due to Upgrade145Interface Requirements145.1UMTS Interfaces145.1.1Uu Interface155.1.2Iu Interface155.1.3Iur Interface155.1.4Iub Interface155.2OAM Interfaces155.2.13GPP OAM INTERFACES155.2.2External ALU OAM Interfaces155.3Transmission Network Interfaces155.3.1Physical Layer155.3.2Ethernet155.3.3ATM155.3.4IP156OAM Impacts156.1OAM MODEL DESCRIPTION156.1.1Configuration Management156.1.2Fault Management176.1.3Performance Management216.2OAM PROCEDURES256.2.1Upgrades256.2.2Installation and Commissioning Procedures266.2.3Maintenance266.2.4Feature Activation266.3OAM Call Trace267Architectural Impacts268FIELD INTRODUCTION268.1Hardware Constraints268.2Spare Parts Constraints268.3Inter RNS Version Interworking268.4Core Network Interworking268.5Backwards Compatibilities269FUTURE EVOLUTION2610Open Issues2611TOOLS IMPACTS26Definitions and Appendices2812ABBREVIATIONS AND DEFINITIONS28

Publication History

Author(s) should complete Publication History, Introduction, and Related Documents as required by the WCDMA Document Control Procedure (SQ/GEN/APP/000011). This template has been developed with UMTS items, for other technologies the UMTS references to equivalents for that technology. The following sections: - Publication History, Introduction, Related Documents, Function Overview, Benefits and Definition, Requirements Compliance and Abbreviations should always be utilised. If appropriate the author may decide not to complete other sections, or to add sections if needed.All Guidelines as denoted by italic text and the guide / start end markers should be deleted from the document when completedIssue Numbers start at 01.01 and the table should be filled in reverse chronological order

The document is split into section, the first and last sections are general sections, the second section is customer requirements owned by PLM, the third section is system requirements owned by system or subsystem team.

DateModificationsIssueCR Number

01/April/2011creation01.01/EN123827

15/August/2011Feature split: this FSD will describe step1 of PQ3 load reduction. Step 2 will be described in FSD 125408.01.02/EN

dOCUMENT iNFORMATION1 Introduction

1.1 Object

The primary objective of the FSD is to provide a feature definition containing initially PLM requirements and then R&D add detail to technically describe how Alcatel-Lucent solutions will satisfy the customer needs, and to facilitate R&D commitment to deliver the feature. The FSD provides requirements, which form the basis for subsequent lower-detailed definition. The FSD replaces the combination of FRS and FTS documents1.2 Scope of this Document

This document covers.....

1.3 Audience for this Document

PLM, System Design, Subsystem Architecture and Design, Integration and Validation Teams.....

1.4 Waivers and Exceptions

2 RELATED DOCUMENTATION

2.1 Applicable Documents

2.2 Applicable Standards

Add any applicable standards identified during feature analysis2.3 Reference Documents

Customer Requirements and Market Information

3 FEATURE Information3.1 Impacted Network Element(s)

NodeB3.2 Feature Order Type:

Base line3.3 Internal / External Feature

Internal feature3.4 Requested Releases

UA 08.13.5 Feature Overview

The target of this request is to improve CPU usage in order to reduce CPU load on PQ3 of xCEM(-u) and eCEM(-u). This should allow higher capacity and performance in loaded situations, as well as better stability in such situations.Overload situations on the modems should occur less frequently, as the overload thresholds are reached only with higher load.3.5.1 Feature Description

3.5.2 Market Information

3.5.2.1 Applicable Market

Global market, main target EMEA market3.5.2.2 Technology

UMTS

3.5.3 FEATURE BENEFITS

3.5.3.1 Customer/Service Provider Benefits

Better capacity, performance and stability of modems in loaded situations.3.5.3.2 End-User / Subscriber Benefits

Improved QoS in loaded cells.3.6 Customer Scenarios

The Customer Scenarios sections contain a short set of high level, descriptive scenarios that the customer needs the feature to perform3.7 Customer RequirementsThe Customer Requirements section is a list of statements of customer need, additional tables should be added if needed to emphasize items such as security or environmental requirement sets. The section should not contain detailed system function / requirements i.e it should define what is needed not how it may be delivered3.7.1 Customer Requirements List

This is an ALU internal requirement.Req. #General RequirementsR&D Response

R1 Improve CPU load by code optimization of PQ3 on xCEM and eCEM.This request does not cover optimizations on PQ2 (no issue identified today) or of DSP( to be covered by separate FRS, if necessary).

R2 Target is to reduce the PQ3 CPU load by at least 15% in highly loaded situations.

R&D to suggest the reference situations that is considered for load reduction benchmarking.measurements should be done with the following configuration:

128 R99 UE (modem R99 throughput : UL: 1Mbits/s DL: 1 Mbits/s)

128 HSDPA UE (modem HSDPA throughput = 35 Mbits/s)

R3 Global SW architecture must be optimized. Objective is to reduce nb of tasks of VxWorks in order to reduce the task switches that deteriorate CPU performances.

R4 Improvements to be implemented on both xCEM(-u) and eCEM(-u): CPLD access time reduction and number of access reduction

Merge R99 tasks

IWANT processing

Change GCC compilation options: -O2 and -finline-funtions

Expected CPU load reduction for these 4 items: 14% in loaded situation

R5 No regression on KPIs allowed.

For each optimization, KPI impacts are the same. In fact, this ensures that the modem can support the current capacity and new HSxPA.features (because each optimization will free some CPU that could be used by new features).

R6 Non-regression testing should be done in very early development steps and throughout integration cycle in order to anticipate any issue with the implemented solution.

R7 Load testing should be possible already in early development stages in order to validate the improvements and quantify the reached gains.

R8 Side impacts on L1 and modem /NodeB architecture to be assessed.

R9 Interaction with overload management on modem and NodeB (FRS 119644 and 121543) must be verified. Overload thresholds should be reached later with an increased user plane and/or control plane traffic.

No dependencies are expected.

R10 The stabililty in highly loaded situations should be improved.

Req. #Performance / Capacity / Reliability RequirementsR&D Response

RP1Modem availability should be improved, as overload is reached less frequently.

Req. #Configuration Management and Parameter RequirementsR&D Response

RC1 N/A

Req. #Counter RequirementsR&D Response

RCT1 N/A

RCT2

Req. #Fault Management and Alarm RequirementsR&D Response

RF 1. N/A

Req. #Billing and Licensing RequirementsR&D Response

N/A

Req. #Serviceability RequirementsR&D Response

N/A

Req. #Specific Documentation RequirementsR&D Response

N/A

3.7.2 Customer Specific Requirements

N/AFeature Technical Description

4 Feature DefinitionFor information in a first step: Paper from Bernard Brouazin

This chapter is thoroughly studying the functional details of the feature.It should contain a complete feature description:

Scenarios,

New or modified mechanism or algorithm

Activation mode description (mandatory Boolean) Hardware impacts

Performance impacts etc4.1 Principles / Reference Architecture define the principles and reference architecture used in the solution proposal4.2 Assumptions

define assumptions made within the solution proposal4.3 Solution Options

define alternative options to solving the FRS Requirements and explain why a particular solution may be preferable

4.3.1 Selected Option

4.3.2 Alternative Options4.4 Feature DependenciesThis Chapter describes the dependencies of this function on other functions within the system, or to describes features / functions that are mutually exclusive with this feature/function.

4.4.1 Features dependent on this feature4.4.2 Features this Feature is dependent on4.4.3 Peer to Peer Dependency / Interactions4.4.4 Impact on SDS Document

For WDCMA SDT, this section shall contain the impact on all the SDS documents (existing or new if required).

UTRAN Traffic Management

PS Call Management

UTRAN Mobility

UTRAN Power Management

Intelligent RAB mapping

Preemption

Call Admission Control

HSDPA System Specification

E-DCH System Specification

SRNS Relocation

RNC overload

Radio Bearer Configuration Parameters

UE Dedicated Scenario

Network Setup Scenario

UTRAN architecture and transmission management

Bandwidth Pool Management

IP in UTRAN

UTRAN sharing

MOCN

UE periodic measurement for performance

OCNS for R99 and HSDPA

AMR CS Speech Services

F-DPCH and SRB over HSPA - CPC

Location Services - Cell coverage positioning

Location Services - GPS based UE positioning

Location Services - UE positioning solution for UMTS

Location - enhanced cell coverage positioning

Multimedia Broadcast Multicast Services

Cell Broadcast Service

Micro/Pico Node B

4.5 Use Cases / ScenariosThis chapter offers a set of relevant scenarios that will help in the global understanding of the specification, and the definition of the test paths. Consideration should be given to System behaviour, and NE behaviours within the system.For example it can show a successful communication scenario, with the complete data flow chain (with and without the activation flag set). This has to be defined at the functional level.Remember to include the typical error and feature activation cases particularly when facing nodes with another functional level (inter-release compatibility).The use cases should mention for each scenario which counters and timers should be incremented, if the scenario triggers emission of a state change or of an alarm, where a trace point should be placed.

4.6 Requirements

This chapter offers a set of clear, atomic, verifiable, requirements that will help in the global understanding of the specification this may include hardware and software requirements. Supporting text is used to provide context to the requirements. A requirement object should be tagged with Object Type / Product Elements / Feature Number / Review Status, all other objects do not need to have these fields populated. Requirements are not limited to this section, where requirements fit in other sections of the document they may do so, this means that this section wll only contain general requirements while other areas contain content appropriate to them. Requirements any where in the document should have the attributes noted above completedSupporting text here that gives context etc.

The system / box shall......

Product Elements:

4.7 Inter Sub-System Functional Distribution

This chapter describes the inter subsystems distribution across network elements and relations of the function4.7.1 Sub System Impacts

This section should be used to provide a reference to how individual customer needs are supported by different subsystems so that in the event of customer need being descoped the impacts can be easily identified. Use subheadings relating to each subsystem impacted such as BTS Impacts or RNC Impacts. Rename the sample below if appropriate. A requirements object should be tagged with Object Type / Product Elements / Feature Number / Review Status, all other objects do not need to have these fields populated.4.7.1.1 BTS Impacts

4.8 Performance Impacts

This chapter describes the impacts of the function on performance aspects of the system4.8.1 System Performance

4.8.2 Dimensioning

4.8.3 Capacity

4.8.4 Dependability, Availability and Reliability

4.8.5 End User Performance

4.8.6 Core KPI Assessment

Core KPIs are KPIs focusing on those aspects of the UTRAN product that are the most critical for the current and future success of the product. Core KPIs should be assessed (or updated) in each FSD Target is defined as one of No Impact or Improve or Deteriorate or Dont KnowCore KPITarget

Accessibility

Retainability

Mobility

Throughput

4.9 Security

Description of the security requirements impacts when products, systems, services and/or platforms are introduced into the Wireless Network Services environment4.10 Environmental Impacts

This chapter defines if there are any environmental impacts from adding this function to the system4.11 Standards (Compliance and Support)

4.12 Licensing and Billing System Impact

4.13 Upgrade Requirements

This chapter defines system requirements and impacts on the system during upgrade related to the feature defined in this FSD. OAM upgrade routines are defined insection 8.14.13.1 Pre-Checks

Define any checks that should be made before applying the Features defined in this FSD 4.13.2 Functionality Change due to Upgrade

Define changes in system functionality when this feature is applied in particular any items that are degraded or removed should be detailed

5 Interface RequirementsDescription of the new or modified procedures and messages taken into account.If a chapter is not relevant (or respectively remains unchanging) indicate "not applicable" (or respectively "no modification"). Interfaces listed here are for the UMTS Product Stream, Adjust the headings as appropriate for interface sets for other product streams when required5.1 UMTS Interfaces

The system / box shall......

Product Elements:

5.1.1 Uu Interface

5.1.2 Iu Interface

5.1.3 Iur Interface

5.1.4 Iub Interface

5.2 OAM Interfaces

5.2.1 3GPP OAM INTERFACES

5.2.2 External ALU OAM Interfaces

5.3 Transmission Network Interfaces

5.3.1 Physical Layer

5.3.2 Ethernet

5.3.3 ATM

5.3.4 IP

6 OAM Impacts6.1 OAM MODEL DESCRIPTION

This chapter describes any changes or updates to the information models, note the data format shown is yet to be finalised.6.1.1 Configuration Management

Description of the new or modified (or deleted) configuration objects / parameters. An object class template is shown below delete the red guidelines and replace with supporting comment for the object

ObjectPropertyComments

PathRNC radioAccessServices This part contains the hierarchical path of the MO

RNC

HYPERLINK "file:///D:\\Profiles\\COUAILLE\\My%20Documents\\Corporate%20Critical%20Files\\umts_parameter\\UA04.2\\RMD_CM_OAM5%5b1%5d.0_W41_(Latest)\\RMD\\Content\\Parameters\\V4.2\\RNC\\CNode\\NodeB.html" NodeB

HYPERLINK "file:///D:\\Profiles\\COUAILLE\\My%20Documents\\Corporate%20Critical%20Files\\umts_parameter\\UA04.2\\RMD_CM_OAM5%5b1%5d.0_W41_(Latest)\\RMD\\Content\\Parameters\\V4.2\\RNC\\CNode\\FDDCell.html" FDDCell

ChildrenThis part contains the list of the children for this MO

HsdpaResource

Link(s)This part contains the list of the various references from this MO to others

RNC

HYPERLINK "file:///D:\\Profiles\\COUAILLE\\My%20Documents\\Corporate%20Critical%20Files\\umts_parameter\\UA04.2\\RMD_CM_OAM5%5b1%5d.0_W41_(Latest)\\RMD\\Content\\Parameters\\V4.2\\RNC\\CNode\\RadioAccessService.html" RadioAccessService

HYPERLINK "file:///D:\\Profiles\\COUAILLE\\My%20Documents\\Corporate%20Critical%20Files\\umts_parameter\\UA04.2\\RMD_CM_OAM5%5b1%5d.0_W41_(Latest)\\RMD\\Content\\Parameters\\V4.2\\RNC\\CNode\\DedicatedConf.html" DedicatedConf

HYPERLINK "file:///D:\\Profiles\\COUAILLE\\My%20Documents\\Corporate%20Critical%20Files\\umts_parameter\\UA04.2\\RMD_CM_OAM5%5b1%5d.0_W41_(Latest)\\RMD\\Content\\Parameters\\V4.2\\RNC\\CNode\\CacConfClass.html" CacConfClass

Identifier(s)primary / secondaryThis part contains the list of the various identifications for this MO.

Cardinalityindicate minimum and maximum number of MO instances

Create (off-line)Yes/noDefault value: Yes. Creation constraints if No

Create on-lineYes/noCreation constraints.

Delete on-line Yes/noDeletion constraints.

MO presenceMandatory/Optional

Object to lockyes / noif yes, indicate which object must be locked; in operations above (delete or create), indicate lock details

6.1.1.1 CM Parameters

Generic CM parameter example is included below. This should define how parameters are to be added or adjusted and the parameter fully defined in the appropriate parameter modelling database Do not forget the feature activation flag (mandatory Boolean) as "isFeatureAllowed.sourcecreation/modification

domainOAM/RNC/BTS

object nameRAN Managed Object

parameter name32 characters max

definitionDetailed description for external customer documentation purpose

activationFlagNo / optional feature / upgrade iso-functional / IOT issue

OptionalYes/No

categorystandard/reserve/ states & status/dynamic data/ installationAndCommisioning/system constant

class0 /1/2/3-a1/3-a2/3-b/READ ONLY

Associated Event for 3-a2 only

Range

unitdB / dBm / s /..

Initial valuesUsed when upgrade is achieved for iso-functionality purpose:

if ActivationFlag: set to "false",

else "recommended value"

Recommended valueRef [A2] UPUG

MonitoringList of impacted KPIs, metrics and counters when the value is changed

Upgrade ruleNo/Yes (to be described in Error! Reference source not found. Error! Reference source not found.)/No

Feature lockingNo/Yes (to be described in Error! Reference source not found. Error! Reference source not found.)

Check ruleNo/Yes (to be described in Error! Reference source not found. Error! Reference source not found.)

6.1.1.2 Control Rules

6.1.2 Fault Management

Description of the new or modified (or deleted) alarm notifications 6.1.2.1 Alarms

6.1.2.1.1 CNode, BTS and OAM Alarm Notifications

Description of the new or modified (or deleted) alarm notifications A CODANO (or SPECIFIC PROBLEM field ) value is used as an identifier of an alarm notification. For that reason, at one triplet (Managed Object type, Alarm type aka X733 Event Type, Probable cause), a CODANO is associated. On the other hand, the same CODANO can be used by several Managed Objects but the notification identity shall be different thanks to the Managed Object type identification.

Identifier

FieldDescriptionExample

Managed Object TypeManaged Object name. CsCoreNetworkAccess

X733 EventTypecommunications alarm/ quality of service alarm/ processing error alarm/ equipment alarm/ environmental alarm [R15]quality of service alarm

ProbableCauseCompliant with [R15] congestion (8)

Description

codanoaka FaultCode. 3010

Managed Object idManaged Object identification. 29713

Notification idCodano_Managed Object Type id3010_29713

Begin PerceivedSeverityCritical/Major/Minor/warning [R15]. Major

End PerceivedSeverityEmpty/Cleared [R15]. Cleard

SpecificProblem_causeAka Label for customer documentation index presentation purpose. ANO RNC NOTIFY CORENETWORK CS DOMAIN OVERLOAD

FamilyListApplicable to RNC and BTS. RNC1000/RNC1500

CommonData significant or the PLMN Operator to identify the reason of the alarm. Only used by the RNC1000 family.

additionalInfoPLMNOData significant for the PLMN Operator which are taken in account by maintenance people in order to correct hardware faults..

Manufacter_infoData significant for the manufacturer contain debugging information in order to correct software faults

Correlated notificationnot used

Begin criteriaDetailed definition for customer documentation purpose

End criteriaDetailed definition for customer documentation purpose

ImpactConsequences description for customer documentation purpose

Remedial ActionMaintenance action for customer documentation purpose

6.1.2.1.2 INode Alarm Notifications

Description of the new or modified (or deleted) alarm notifications.

Identifier


component nameThe full name of the component needing repair, or detecting the fault. The component name can be used for hierarchically clearing alarms for its subcomponents (since the subcomponent name is derived from the componentname).LP/9 Ap/3

Alarm indexThe Alarm index consists of eight BCD digits. The first four digits are collectively known as the IndexGroup and the remaining four digits are known as the SubIndex. 70701005

Description


status Indicates the status of an alarm. The possible values for this field include message (MSG), set (SET) or clear (CLR).SET

severity Indicates the severity of the alarm. The value will be one of, critical, major, minor, warning, indeterminate, cleared.

For further details, refer to [R15]major

typeThis is a general explanation of why the alarm was generated. Possible values for this field include communications, quality of service, processing, equipment, or environmental, security, operator, debug, or unknown.

For further details, refer to [R15]equipment

cause This provides another level of detail of why the alarm was generated. It is information given in addition to the general explanation given in the Type field.

For further details, refer to [R15]processorProblem

Rel A list of known related components. Usually it is only the supporting hardware name that the affected component resides on.. LP/8

Com

Comment data is additional data in ASCII format. It provides the operator with extra information in the form of a comment. The text appearing in this field is self explanatory.AP failure detected

Op.Operator data is hex-format data that an operator can use for additional information596F7572206E616

IntInternal data is additional information in Hex-format that can be used by internal support personnel. Contained within this field are the processId (Pid), filename, linenumber and

version0/0/0/114;

apcsApcMgr.cc;

1706;

IRNC60.1

DetailDetailed definition for customer documentation purposeThe LP has lost communications with the AP

Remedial ActionMaintenance action for customer documentation purposeThe affected internal bus has been reset and no further action is required from the operator...

6.1.2.1.3 State Changes

Description of the new or modified (or deleted) state changes.

TitleFor customer documentation purpose

Managed Object TypeManaged Object name. For example: CsCoreNetworkAccess

New operational statedisable/enable Compliant with [R14]

New availability statusfailed/dependency/degraded/not installed/Compliant with [R14]

New standby statushot standby/cold standby/providing service Compliant with [R14]

New upgrade statusNot used

Source Indicatorresource operation/management operation/unknown Compliant with [R14]

Correlated notificationfor example: time stamp

ReasonDetailed definition for customer documentation purpose

ImpactConsequences description for customer documentation purpose

6.1.2.2 Diagnostics

6.1.2.3 Trouble Shooting

6.1.2.4 Failure Recovery

6.1.3 Performance Management

Description of the new or modified (or deleted) performance indicators and counters 6.1.3.1 Indicators

Description of the metric(s) in a written textual format.

This section should specify the motivation behind the measurement.

It details an underlying rationale, which is used for justifying the measurement data collection and for guiding the measurement data analysis and interpretation. (high-level requirements specified by a FSD prime)

Example: RAB establishment success rate

The RAB establishment success rate is used to evaluate the service accessibility across UTRAN.

It describes the ratio of all successful RAB establishments to RAB establishment attempts.

6.1.3.2 Indicator Details

This section should contain the indicator formula / method / details using counters.(low-level requirements specified by a system counter prime)6.1.3.3 GQM plans

One or several GQM plans can be associated to a feature. A GQM plan is an explicitly documented rationale used to justify the performance measurement and to guide the performance data analysis and interpretation.

A GQM plan consists of a set of a single goal plus a series of questions and metrics needed to provide an operational definition of that goal of performance measurement.Replace red text with appropriate content

Goal G1

Purpose Specifies the motivation behind the measurement of the object. Examples of purpose are evaluate, understand, control, assess, compare, predict, improve, reduce, etc.

IssueSpecifies the quality attribute or the aspect of interest of the object under measurement. Examples of issue are accessibility, retainability, mobility, congestion, traffic, quality, etc.

ObjectSpecifies the subject of measurement. Examples of object are network, network element, feature, sub feature, etc.

ViewpointSpecifies the people who are interested in this measurement: network operators staff or equipment vendors staff. Examples of the network operators staff are the business community, the maintenance community, the traffic engineering community or the customer care community. Examples of the equipment vendors staff are the performance modeling community or the development engineering community [3GPP TS 32.403].

EnvironmentSpecifies the context of the measurement

The measurement goal has to be refined into a series of questions, whose answers will tell if the goal has been achieved.

In order to answer these questions, measurement attributes or metrics are generated from each question.

Question Q1Specifies the question that shall be defined to support the data interpretation towards the measurement goal. Examples of question are :

What are the measurement properties or attributes of the object under measurement?

Which factors expected to have an impact on the measurement properties?

Metric M1.1 Specifies the metric that shall provide the quantitative information to answer the question.

Metric M1.2Idem

6.1.3.4 Counters

This section should contain counter descriptions.(high-level requirements specified by an FSD prime)6.1.3.5 Counter DefinitionsExample Performance Counter is included below.

Field ValueNE XML tag

Counter IDCounter identifier - New, modified counter ID or deleted counter IDcounter id

NameInternal counter namename

NE locationNE measured object classneLocation

Reference cellOptional "Y" - Only filled when the NE location is a reference cellisRef

RAN locationUTRAN system location or OMC-R NE measured object classRANLocation

3GPP location3GPP measured object classnorthboundLocation

FamilyFamily counterfamily

Screening referenceNo screening or screening referencescreeningRef id

3GPP name3GPP counter name, or northbound counter namename3GPP

TypeCollection method - Cum, Val or Loadtype

Scanner typeScanner counter type - Legacy counter, real-time counter or bothscannerType

Trigger eventTrigger event descriptiontriggeringEvent

RangeMeasurement result rangerange

UnitMeasurement result unitunit

DescriptionDescription of the measurement operationdescription

Aggregation ruleAggregation rule to be performed by PM process - Add, Avg, Min, Max, Val, Load or NoneSysaggregationRule

GQM metricIdentifier of the related GQM metricGQM metric

DomainCounter domain - CS, PS or bothsysDomain

ReleaseCounter entity system releaserelease

ModificationCounter modification (cf. "XML counter definitions - Modified rules")sysModification

Modification - RuleCounter modification rule modificationRule

Modification - Modified counterModified countermodifiedCounterId

Modification - Modified screening counterModified screening countermodifiedScreeningCounterId

Modification - Modified expanded counterModifed expanded countermodifiedExpandedCounterId

Modification - Modified expanded screening counterModified expanded screeningmodifiedExpandedScreeningCounterId

Modification - Modified measured object classModified measured object classmeasuredObject

FRS / FSDRelated FSDsysFRS

ProductRelated product - Global market or Koreaproduct

PriorityPriority of a RNC counter to be preserved in case of a RNC overloadpriority

NotesNotesnotes

Screening referenceScreening entity referencescreening id

CriteriaCriteria of screeningcriteria

Screening ID (i) with i= 1, .., nScreening IDscrid id

Screening description (i)Screening descriptionscrid name

Screening release (i)Screening entity system releasescrid firstRel

3GPP screening name (i)3GPP screening namescrid suffix3GPP

Modification - Rule (i)Screening modification rule scrid mod

Modification - Modified screening (i)Modified screeningscrid mSId

Modification - Modified counter (i)Modified counterscrid mCId

Modification - Modified screening counter (i)Modified screening counterscrid mSCId

Modification - Modified expanded counter (i)Modifed expanded countermodifiedECId

Modification - Modified expanded screening counter (i)Modified expanded screening countermodifiedESCId

Modification - Modified measured object class (i)Modified measured object classmObj

Measurement Name

A DescriptionThis subclause contains an explanation of the measurement operation

B Collection MethodCC GAUGEDER SI

C Condition This subclause contains the condition which causes the measurement result data to be updated;This will be defined by identifying protocol related trigger events for starting and stopping measurement processes, or updating the current measurement result value. Where it is not possible to give a precise condition, then the conditional circumstances leading to the update are stated.

D Measurement ResultThis subclause contains a description of expected result value(s) (e.g. a single integer value).

E Measurement TypeThis subclause contains a short form of the measurement name The vendor-specific measurement names will all begin with the VS prefix. For exemple:

VS.RrcTransitionCellDchToCellFach

F Measurement Object InstanceThis subclause describes the measured object class

cell, rnc, neighbouring..

G Switching TechnologyCircuit Switched and/or Packet Switched: CS, PS, CS+PS or PS+PS.

3GPP compliance

comments

Observation typeGPO: RNC/NodeB/Passport

RTO: RNC/NodeB/Passport

objectivescall traffic reporting/ Call profile reporting/ Call failures reporting/ QoS reporting/ Resources status reporting/ Trouble detection related to calls, but not trouble investigation (see Definitions)

Temporal aggregation rule

GQM metricIdentifier of the related GQM metric

6.1.3.6 Traces

6.2 OAM PROCEDURES

6.2.1 Upgrades

Mainly focused to Compliance between releases this chapter defines OAM upgrade routines and methods6.2.1.1 OAM Platform Upgrade

Description of the upgrade constraints. OAM parameter values6.2.1.2 RNC & BTS Upgrade

Description of the upgrade and how performance is maintained over the upgrade period

6.2.2 Installation and Commissioning Procedures

Description of the feature impact on I&C procedures6.2.3 Maintenance

Description of the feature impact on standard maintenance procedures6.2.4 Feature Activation

Description of the feature impact on standard operation proceduresGeneral description of the Feature Activation procedures concerning the feature activation and deactivation mode

6.3 OAM Call Trace

7 Architectural Impacts

Description of high level architectural impacts of the feature8 FIELD INTRODUCTION

Description of how the feature is introduced into the field8.1 Hardware Constraints

HW/feature compatibility and degraded modeHW interworking policy8.2 Spare Parts Constraints

Retrofit HW.Version compatibility matrix.8.3 Inter RNS Version Interworking

UTRAN version interworking policy (for example: criticality)Feature activation strategy must be well described, in particular partial introduction of a feature in a live network:8.4 Core Network Interworking

UTRAN/CN interworking policy 8.5 Backwards Compatibilities

Backwards compatibility issues and strategy9 FUTURE EVOLUTION

Optional - Describe any possible identified evolution paths for the Feature

10 Open Issues

11 TOOLS IMPACTS

Describe impact of the function on system tools (maintenance, engineering, validation tools etc)

Definitions and Appendices

12 ABBREVIATIONS AND DEFINITIONS

add and remove acronyms as required3GPP3rd Generation Partnership Project

ALCAPAccess Link Control Application Part

ALTPAlcatel-Lucent Technical Publication

DR1Level of feature maturity allowing a code start (note: not the DR1 for the global program)

FRSFeature Requirement Specification, usually created by PLM and capturing "business level" requirements

FSDFeature Specification Document replacement document that combines the FRS and FTS documents into one.

FTSFeature Technical Specification, technical counterpart of the FRS produced by Systems Engineering / Design or Feature Architecture Prime

)

.

_1363161953.doc

114374 Modem PQ3 & L2 Performance

Scheduler Optimization

Document number:UMT/BTS/DD/Document issue:01.01/ENDocument status:DraftDate:xx/xxx/2010

Internal document - Not to be circulated outside Alcatel-Lucent Networks

Copyright( 2010 Alcatel-Lucent, All Rights Reserved

UNCONTROLLED COPY: The master of this document is stored on an electronic database and is write protected; it may be altered only by authorized persons. While copies may be printed, it is not recommended. Viewing of the master electronically ensures access to the current issue. Any hardcopies taken must be regarded as uncontrolled copies.

ALCATEL-LUCENT CONFIDENTIAL: The information contained in this document is the property of Alcatel-Lucent. Except as expressly authorized in writing by Alcatel-Lucent, the holder shall keep all information contained herein confidential, shall disclose the information only to its employees with a need to know, and shall protect the information from disclosure and dissemination to third parties. Except as expressly authorized in writing by Alcatel-Lucent, the holder is granted no rights to use the information contained herein. If you have received this document in error, please notify the sender and destroy it immediately.

publication history

30/03/2010

Creation: 30 March 2010

Author names:

PQ3 Team

14/01/2011

Ed3: Update after PQ3 team dedicated meeting

Author names:

PQ3 Team

25/01/2011

Ed4: Update chapter Exit the loop when not enough available bits

Author names:

Collet Mickal

contents

31 INTRODUCTION

32 Related documents

32.1 Applicable documents

32.2 Reference documents

33 Status summary

34 HSDPA Scheduler Optimization

34.1 Performance Measurements

34.1.1 Deactivate the HSDPA overload handler

34.2 Reduce access time to CPLD and FPGA registers

34.3 Reduce number of CPLD and FPGA access

34.4 Dynamic Deadline calculation

34.5 Schedule cells not served during last TTI

34.6 Exit the loop when not enough available bits

34.7 Merge ACK/NACK, CQI and HSDPA Handler into one task

34.8 Deactivate 2ms Interrupt

34.9 Remove CRC16 processing

34.10 Enhance data packet transmission towards FPGA-A

34.11 Enhance the ranking algorithm

34.12 Object creation/deletion

35 HSUPA Scheduler Optimization

36 R99 Optimisation

36.1 Merge all task per R99 flow

36.2 IWant processing optimization

37 Overall Optimisation

37.1 Use GCC4.4 compiler instead of GCC3.3

37.2 Change optimization options for gcc compiler

37.3 Use likely and unlikely GCC macros

37.4 Optimize data structure to decrease cache miss ratio

37.5 SCL Optimisations

1 INTRODUCTION

2 Related documents

2.1 Applicable documents

2.2 Reference documents

3 Status summary

Item

CR#

Owner

Status

Comment

HSDPA

Reduce access time to CPLD and FPGA registers

tbd

JMC

Opened

Create CR

Implement a solution

Reduce number of CPLD and FPGA access

299119

JMC

Opened

Code: avail. in UA8

Tests: eCEM OK/xCEM NOK

To be delivered on MS

Dynamic Deadline calculation

???

Nash

Closed

CR# to be retrieved

Schedule cells not served during last TTI

tbd

BB

Opened

To be analysed by archi and documented

Exit the loop when not enough available bits

358115

MC

Opened

Implemented

To be documented and delivered on MS

Merge ACK/NACK, CQI and HSDPA Handler into one task

tbd

BB

Opened


Deactivate 2ms Interrupt

tbd

JMC

Opened

Create CR

To be documented and delivered on MS

Remove CRC16 processing

tbd

BB

Opened


Enhance data packet transmission towards FPGA-A

tbd

BB

Opened


Enhance the ranking algorithm

tbd

BB

Opened


Object creation/deletion

tbd

JMC

Opened

Create CR


HSUPA

-

-

-

-

-

R99

Merge all task per R99 flow

tbd

JMC

Opened

Create CR


IWant processing optimization

tbd

JMC

Opened

Create CR


Overall

Use GCC4.4 compiler instead of GCC3.3

422934

VB

Wait

CR transmitted to build team

Waiting for new build chain installation

Change optimization options for gcc compiler

421267

VB

Closed

CR transmitted to build team

Use likely and unlikely GCC macros

none

VB

Closed

Coding rules introduced into this document. To be applied as coding rule

Optimize data structure to decrease cache miss ratio

tbd

JMC

Opened

To be documented and applied as coding rule

SCL Optimisations

tbd

VB

Opened

To be tested on x/eCEM then delivered on MS

4 HSDPA Scheduler Optimization

4.1 Performance Measurements

4.1.1 Deactivate the HSDPA overload handler

Since V7.1.3, a specific mechanism has been implemented to reduce the CPU load and is activated by default. It allows deactivating some part of the CeCtl application and is based on CPU load thresholds (minimum, medium and maximum thresholds).

This mechanism must be disabled for any CPU performance measurement of the CeCtl application. All thresholds must be set to 100% of CPU using following commands (either into the startup script or on the CeCtl terminal):

machs_overloadSetThreshold(0,100) : seuil min set to 100%

machs_overloadSetThreshold(1,100) : seuil med set to 100%

machs_overloadSetThreshold(2,100) : seuil max set to 100%

These new threshold values can be checked using:

machs_overloadStatus

4.2 Reduce access time to CPLD and FPGA registers

Problem:

UMTS time is read by accessing to CPLD or FPGA A. The access to these components is programmed in PQ3 as a multiple of bus clock, so for instance 450ns to access to FPGA A registers. This will decrease CPU load for many tasks, as it is used by multiple tasks (FP, HSDPA, R99)

Solution:

It seems the access time can be reduced to 8 for FPGA, and 4 to CPLD, after having loaded FPGAs and DSP.

4.3 Reduce number of CPLD and FPGA access

Problem:

Many software parts are accessing to UMTS time (SFN/CFN) by reading HW registers. Even when reducing the time to access to this hardware, 200ns is far greater than CPU speed (on eCEM, PQ3 could process up to 2 instructions per cycle 0,7ns)

Solution:

The tested solution was to read during 2ms interrupt (ack/nack) a register in the FPGA A and a register in CPLD, and also the DEC value from the PQ3 core Based on these 3 figures, it has been possible to derive all the subsequent reads by simply reading the current DEC value, at a price of only 4 cycles, so 3ns The impacts are mainly located in the plat form.

Drawbacks:

We must be sure that OCP is always started, as this code uses the ack/nack interrupt

With BCEM and 8 Cpu cores, a new study must be done as there will be one DEC by core. How to find the correct one?

Test Results:

The following table provides the results with Decrementer register implementation compared to the existing CLPD access.

TESTBENCH 69

HsDataHdl Task

MAC-HS

32 UE

64 UE

128 UE

V7(CPLD)

13,23

18,7

30,92

V7 - timer DEC

12,02

16,55

26,88

TESTBENCH 69

HsDataHdl Task

MAC-EHS

32 UE

64 UE

128 UE

V7(CPLD)

15,48

20,27

29,44

V7 - timer DEC

14,3

19,25

28,9

4.4 Dynamic Deadline calculation

Problem:

HS-SCCH+ packets have a deadline for arrival into FPGA A. HS-PDSCH packets have a deadline that is later than the HS-SCCH+ deadline.

At present time, the dead line to send HSDPA data and control (CE driver writes HS-SCCH+ and HS-PDSCH+ packets into FPGA-A dedicated downlink traffic buffer) is calculated as follows:

During ACK/NACK interrupt, current time in term of chip number is stored by CE driver, by reading HW register.

From time to time, HSDPA scheduler checks if deadline is reached by calling timer function owned by CE driver. This timer function reads the HW registers, and gives back the chip number (plus 38400, number of chips in 10ms, if counter wrapped around) to caller. The scheduler checks if deadline, hard coded to 1500ms in chip number is reached or not.

This implementation has some drawbacks:

Ack/Nack interrupt occurrence depends on cell radius and some other parameters. This interrupt occurs after up to 600s after TTI starts.

The sum (600s+1500ms) may lead to a deadline after TTI end or after real HW deadline.

The latency for taking into account the interrupt is unknown (depends on masked section and other interrupts (abacab) pending, etc).

Many HW counters accesses tend to degrade performances and precision.

Solution:

A solution has been implemented by NASH in UA7.1.3.

The original solution proposed internally by ALU PQ3 was:

The idea is to compute the deadline in DEC value unit (DEC is the decrementer used into the PPC core to compute real time clock with a precision of 15ns) and to take into account the UMTS time when interrupt occurs. This could result in sending data and control before the HW deadline.

For that purpose, chip time (from CPLD), BFN (from FPGA) and DEC time (PPC core) are read during interrupt.

They are afterwards elaborated during Ack/Nack handling in CE driver task to compute the deadline in DEC value (DECDeadLine). By the way, with these reading, we can elaborate all the other UMTS counters with a greater precision than before: BFN, SFN, 125s, 666s, chip number.

A new function is proposed to HSDPA scheduler, instead of using timer from CE driver. This function reads the DEC counter and checks if it is still greater than DECDeadLine (taking into account eventual wrap around) and return TRUE or FALSE.

With that new implementation, hardware accesses have been drastically optimised at two levels:

External accesses to CPLD from 450ns to 150ns and to FPGA from 450ns to 240ns

Numerous external accesses replaced by DEC register accesses in 3,2ns

Moreover, instead of checking (chips time at interrupt + fixed delay) with the risk to exceed the hardware deadline, the exact date in UMTS time is available.

However, there is still a problem to solve in HSDPA scheduler. It does not send immediately the data+control to OCP+, because it may continue to check other cells.

So another improvement would be to stop immediately scanning other cells and next TTI to start scanning these cells.

This will give more fair between cells, compared to present behaviour.

4.5 Schedule cells not served during last TTI

Problem: The HSDPA scheduler processes the cells sequentially and starts from the beginning of the cell list at each TTI. In some conditions, the deadline can be reached without having processed all cells of the list. Since the scheduler will start from the beginning of the list at the next TTI, some cells may not be treated during consecutive TTIs.

Solution: Architecture solution to be proposed

4.6 Exit the loop when not enough available bits

Problem:

In scheduleCell() method, under specific scenario, there is not enough available bits left in the tti after having scheduled 1 or 2 UE (hs_scheduling_resources.number_of_bits_left_in_this_tti ) to send 1 MAC-HS PDU, but still pdsch codes, scch codes and power are available. In that case, we will end up going through entire scheduling list and perform various functions (calculate hs-scch power, hs-dsch power, get tfrc, etc) for each UE context unnecessarily.

Solution:

The check for number of available bits to be sent can be done in the scheduleCell function (as checkHsSchedulingResources). If the number of available bits are less than min pdu size(336 or 656 bits), continue without TFRC selection to search for a Mac-ehs UE.

Procs:

By exiting the loop much early, there will be good performance gain.

The following test results dont show a significant improvement because the specific scenario (not enough bit to send one PDU) is difficult to reproduce.

Configuration:

128 HSD UEs:

64 Mac-Hs: category 15 to 20

64 Mac-Ehs: 64 QAM capable, category 15 to 20

HSDPA data rate: 36 Mbits/s

CPU %

PQ3

HsDataHdl

HsRanker

Without optimization

77

31,9

10,4

With optimization

76,7

31,5

10,4

Cons:

By ignoring these excess bits at each tti, there would be a loss of max 168/328 kbps per cell. This would be more if we calculate at the board level

4.7 Merge ACK/NACK, CQI and HSDPA Handler into one task

Problem: The current implementation of the HSDPA scheduler is based on three tasks:

OcpUl0_NACK: Uplink treatment for ack/nack messages

OcpUl0_CQI: Uplink treatment for CQI messages

HsDataHdl: Scheduler

It is functionally not needed and a split a these three tasks into one could save CPU (task switch, )

Solution: Architecture feasibility to be asserted

4.8 Deactivate 2ms Interrupt

Problem: The 2ms HSDPA scheduler interrupt seems to be unused.

Solution: Disable this interrupt

4.9 Remove CRC16 processing

Problem: The CRC16 processing has been removed for R99 traffic. It is proposed to remove it also for HSDPA to save CPU since it seems not necessary.

Solution: Architecture study needed to check if this CRC is really not needed.

4.10 Enhance data packet transmission towards FPGA-A

Problem: The buffer management for MAC-hs/ehs data to be sent to FPGA-A is not efficient. It is proposed to either modify the clone method of the SCL buffers or make copy.

Solution: Architecture study needed

4.11 Enhance the ranking algorithm

Problem: The ranking process, based on the heap method seems to be not efficient.

Solution: Architecture study needed

4.12 Object creation/deletion

Problem:

Some objects are created/deleted at each cell scheduler start (hsScchAndPdschCodeDistribution for instance)

Solution:

If possible, try to use a local structure.

5 HSUPA Scheduler Optimization

6 R99 Optimisation

6.1 Merge all task per R99 flow

Problem:

At present time, there are up to 4 tasks per OneChip created to handle 4 different functions:

one for Iwant handling for downlink data path

one for upward control handling

one for upward data path

one for errors handling

On BCEM, there will be 8 equivalents OC, so up to 32 tasks for R99! This leads to unnecessary CPU consumption. This costs as well some task switch for HSDPA for instance, as R99 tasks have higher priorities

Solution:

It is proposed to have only one task per traffic type to avoid unnecessary context switch, and to save memory.

6.2 IWant processing optimization

Problem:

At present time, Iwant is treated in the so called CE client level. This means that downlink data have to pass many levels before being effectively sent to OC.

This is the main real time constraint with Level 1.

This means also that even HSDPA ack/nack for instance are tested on their way to scheduler, to see if it is an Iwant packet!

Solution:

It is proposed to have directly read in the Iwant task the queues associated to the IuUb, to save some CPU processing and to hurry up the overall Iwant process. Moreover, direct C calls will be done to send data towards Ethernet driver, to avoid double indirection each time. To do that, OC number is stored inside the USL buffer, in attribute section.

7 Overall Optimisation

7.1 Use GCC4.4 compiler instead of GCC3.3

The expected performance improvement on PQ3 when using the compiler gcc-4.4 is from 15% to 20%. The optimization program on XCEM and ECEM needs this improvement.

Install cross compiler gcc-4.4 for VX-Works and adapt the build chain so we can choose between the current release gcc-3.3 and the new release 4.4. The default value should be gcc-3.3. The derived objects should be placed in different directories.

7.2 Change optimization options for gcc compiler

Currently, the NodeB is built using the optimization option -O1. We have verified on the PQ3 team that moving to "-O2 -finline-functions", the load tests have been improved by a factor > 5.5%.

Hereafter some figures with a ECEM load of 128 R99 and 64 HSDPA UEs

OPT

BUSY_MEAN

MEAN_GAIN

-O1

71.3290%

0,00%

-O2 -finline-functions

67.1367%

5.88%

Hereafter some figures with a XCEM load of 32 R99 and 32 HSDPA UEs

OPT

BUSY_MEAN

MEAN_GAIN

-O1

71.5938%

0,00%

-O2 -finline-functions

67.0583%

6.34%

In order to do that we have just added USE_OPTIMIZE='"-O2 -finline-functions"' to the build command line.

It is asked to change the buildchain only for PQ3 to avoid any additional tests on PQ2.

7.3 Use likely and unlikely GCC macros

The __builtin_expect macros are GCC specific macros that use the branch prediction; they tell the processor whether a condition is likely to be true, so that the processor can prefetch instructions on the correct "side" of the branch.

Builtins as __built_expect should be encapsulated in a specific macro so we can make the code portable. Here it is the recommended way to achieve it

#if defined(__GNUC__) && defined(SCL_USE_BUILTIN_EXPECT)

# define SCL_LIKELY(x) __builtin_expect((x),1)

# define SCL_UNLIKELY(x) __builtin_expect((x),0)

#else

# define SCL_LIKELY(x)(x)

# define SCL_UNLIKELY(x) (x)

#endif

The use of these macros is simple: You need just to include the file

#include

if (SCL_LIKELY(cnd)) {

// code that will be executed most of the time

} else {

// code that will be executed rarely

}

A typical case of unlikely could be the error management

if (SCL_UNLIKELY(error_cnd)) {

// code that will be executed rarely as the error conditions are unlikely to occur

} else {

// normal case

}

7.4 Optimize data structure to decrease cache miss ratio

7.5 SCL Optimisations

SCL optimisations presentation and results:

https://wcdma-ll.app.alcatel-lucent.com/livelink/livelink.exe?func=ll&objId=64060340&objAction=browse&sort=name&viewType=1

( End of DOCUMENT (

CEM Optimization

Documents

Transcript of CEM Optimization