Post on 14-Jan-2016
description
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
FieldDescriptionExample
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
FieldDescriptionExample
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
To be analysed by archi and documented
Deactivate 2ms Interrupt
tbd
JMC
Opened
Create CR
To be documented and delivered on MS
Remove CRC16 processing
tbd
BB
Opened
To be analysed by archi and documented
Enhance data packet transmission towards FPGA-A
tbd
BB
Opened
To be analysed by archi and documented
Enhance the ranking algorithm
tbd
BB
Opened
To be analysed by archi and documented
Object creation/deletion
tbd
JMC
Opened
Create CR
Implement a solution
HSUPA
-
-
-
-
-
R99
Merge all task per R99 flow
tbd
JMC
Opened
Create CR
Implement a solution
IWant processing optimization
tbd
JMC
Opened
Create CR
Implement a solution
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 (