INFORMATION_x000D_ALU WRAN KPI Library - UA7 release 1 (76) Prepared: Inmaculada Serrano, Augusto Sanchez Date: 2012-03-02 Sheet: Title Ericsson Internal _x000D_Rev: PA1 ALU WCDMA SWAP KPI LIBRARY Table of Contents NOTE : This information is for ALU WCDMA UA7 KPIBASEDACCEPTANCE Introduction How to use the KPI Library Fields Description Recommended KPIs Optional KPIs Not Recommended KPIs
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
KPIs in the library are divided according to the Ericsson KPI handling strategy mapped on ITU-T and ETSI specifications:
Contractual KPIs are classified into:Recommended (QoS – most used services)Optional (QoS - most used services)Not Recommended (Network Performance PIs, other QoS services)In this document main focus will be a detailed description of Recommended and Optional KPIs.
Availablity Performance
Quality of ServiceQuality of Service(QoS)(QoS)
Service Integrity
Service Retainability
Service Accessibilty
QoSQoS
Network PerformanceNetwork Performance
Resources & Facilities
ReliabilityPerformance
MaintainabiltyPerformance
MaintenanceSupport
PerformanceTransmissionPerformance
Design&Dimensioning
Features & Functionalities
PerformanceMonitoring
(Nodes, System)
O&M(Node, system
Availability)SLAs
Interfaces, Transmission and Transport
The purpose of this document is to provide a smooth way of working with Network Performance KPIs during ALU-Ericsson RAN swap activities. It is intended not only for RAN engineers but also sales persons to better understand the KPI approach and minimize the risks. Two key parts have been identified in any swap out acceptance:• Understand the performance of the existing network before swap and how it is measured (KPIs, formulas, counters)• Understand the level of the required targets. Can they be reached and how much effort is needed to reach them? Each of these KPI “tricky” targets can increase financial risk significantly. That’s why we have to approach the KPI issue with extreme caution and always bear in mind potential financial implications.Comparing KPIs between different vendors is not always like for like. Each vendor has its own way of measuring the performance and building the KPI formulas. Also, the counters that make up the formulas may be triggered differently or refer to different points into the connection sequence. Therefore understanding the meaning of other vendors KPIs is vital when agreeing on targets. One way to handle unknown other vendors KPIs is by use of drive test to get the level of performance rather than relying on the other suppliers stats.If the number of KPIs, or the scope of measurement (method, area, success criteria) is large, the collection and post processing of data, can be time and resource consuming. On the other hand, KPI targets are sometimes so high that they are almost impossible to achieve. Furthermore, if the acceptance and exclusion criteria are not well defined, a lot of effort will need to be put into the tuning and optimization activities in order to bring the network to an acceptable condition. This document lists RAN KPIs and how they should be treated in another vendor environment; the way that they should be measured and the commercial impact of this. If the customer is asking for an alternative KPI, the arguments against the alternative and potential risk analysis will also be found in this document. Special attention has been paid to the calculation of the number of samples needed to reach certain KPI Confidence levels. The number of samples directly affects the measurement time and the number of resources involved; hence it also affects the cost of the acceptance procedure.These variables will dictate the types of services that are necessary to perform, and the amount of time and effort needed to collect the data necessary to achieve the targets.
The purpose of this document is to provide a smooth way of working with Network Performance KPIs during ALU-Ericsson RAN swap activities. It is intended not only for RAN engineers but also sales persons to better understand the KPI approach and minimize the risks. Two key parts have been identified in any swap out acceptance:• Understand the performance of the existing network before swap and how it is measured (KPIs, formulas, counters)• Understand the level of the required targets. Can they be reached and how much effort is needed to reach them? Each of these KPI “tricky” targets can increase financial risk significantly. That’s why we have to approach the KPI issue with extreme caution and always bear in mind potential financial implications.Comparing KPIs between different vendors is not always like for like. Each vendor has its own way of measuring the performance and building the KPI formulas. Also, the counters that make up the formulas may be triggered differently or refer to different points into the connection sequence. Therefore understanding the meaning of other vendors KPIs is vital when agreeing on targets. One way to handle unknown other vendors KPIs is by use of drive test to get the level of performance rather than relying on the other suppliers stats.If the number of KPIs, or the scope of measurement (method, area, success criteria) is large, the collection and post processing of data, can be time and resource consuming. On the other hand, KPI targets are sometimes so high that they are almost impossible to achieve. Furthermore, if the acceptance and exclusion criteria are not well defined, a lot of effort will need to be put into the tuning and optimization activities in order to bring the network to an acceptable condition. This document lists RAN KPIs and how they should be treated in another vendor environment; the way that they should be measured and the commercial impact of this. If the customer is asking for an alternative KPI, the arguments against the alternative and potential risk analysis will also be found in this document. Special attention has been paid to the calculation of the number of samples needed to reach certain KPI Confidence levels. The number of samples directly affects the measurement time and the number of resources involved; hence it also affects the cost of the acceptance procedure.These variables will dictate the types of services that are necessary to perform, and the amount of time and effort needed to collect the data necessary to achieve the targets.
This document describes the ALU recommended, optional RAN KPI’s. Please also check the appropriate vendor Tips & tricks document, embedded.The document can be used during the entire sales process. Before the actual contract negotiation, the document is valuable for understanding the ALU KPI and acceptance approach. During this phase, it is possible to influence the customer to adopt the Ericsson way of thinking.When the customer’s acceptance proposal is on the table, the document can be used as a reference, in order to assess the differences between the methodologies and to assess the risks. If the risks are too big to accept, the document offers argumentation why another set of KPIs, or measurement areas, or exclusion criteria should be used.During RAN swap out preparatory activities, it is strongly recommended to have an overall check of ALU RAN health in terms of end-user perceived performances. That should be useful in order to set up KPI targets in a simpler and efficient way, plus make sure that the KPIs before and after change out are comparable (or that the differences are understood and communicated to the customer).It is of utmost importance to understand that KPI values (targets) and questions like “can we achieve 99%” should not be considered as simple “yes or no” type of technical question. Pure values (targets) are just one of the variables in Ericsson’s strategy and approach in how to handle KPIs in a structured way. The KPI Library contains very sensitive internal information and none of its contents should be open to customers.
For detailed KPI formulas with counters, please refer to the link:
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Fields DescriptionEricsson Internal
_x000D_Rev: PA1
Fields DescriptionField Name Description Range/Value
KPI
Number Structured No of KPI (a.b.c)
a: Recommendation
b: User Impact
c: Area
Area
1)Completion
2)Accessibility
3)Retainability
4)Integrity
5)Mobility
6)Others
Name KPI Name
SW Release Applicable SW release i.e. WCDMA R11.0
Recommendation
Recommended;
Optional;
Not Recommended
GENERAL
Definition
Formula Drive Test (general) formula
Alternative Formula
CONTRACTUAL INFORMATION
User Impact High; Medium; Low
Contractual Information
MEASUREMENT
Method Drive Test; Counters
Measurement Area Golden Cluster; All Cluster;
KPI Domain QoS; Network Performance/(sub levels)
Measurement Execution
Entry and Exit Criteria
TARGETS AND IMPLICATIONS
Design; Initial Tuning; Optimization..
Lowest in Class
Average
Best in Class
The main six areas for performance monitoring
Contractual classification of the KPI according to the Ericsson KPI strategy and ITU-T / ETSI specification.
Description of the meaning of the KPI and how the formula is built; Description of all the counters included in the formula and their triggering conditions; Eventual comments or notes about KPI inconsistency or statistical limit. Some tips about aggregation method.
High level formula used for statistics (Counter based)
Defines relevance of the KPI to the end user experience (i.e. Drop call – high)
Important contractual implications linked to the specific KPI, like what network elements are impacting the KPIs or if KPI can replace other KPI(s).
Description on how to perform the measurement
Defines applicable Acceptance measurement area for the KPI
Defines KPI Domains as per KPI strategy and ITU-T and ETSI specifications
Details on measurement execution (call sequences, start stop triggers..) for Drive tests and Statistics.
Pre requisites to start the measurement like Known limitations and data exclusion (number of samples, confidence intervals..)
Conditions/Commercial Implication
Verbal argumentation to support Sales in the commercial phase handling risk.
Required Services/Prerequisites
Required design and performance improvement services needed for specific KPI contractual commitment.
Here are presented the ranges for the KPI. Note that the Best In Class is more than an optimized network value. It depends on the level of the operator processes and ways of working, features installed and layout in the network, maturity, etc.
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Fields DescriptionEricsson Internal
_x000D_Rev: PA1
TIPS AND TRICKS
Here are presented the ranges for the KPI. Note that the Best In Class is more than an optimized network value. It depends on the level of the operator processes and ways of working, features installed and layout in the network, maturity, etc.
Pre-Launch / Initial Tunning (no data, Huawei recommended value)
Possible comments or notes about KPI inconsistency or statistical limit. Some tips about aggregation method.
MTM calls to be avoided - to exclude faults and radio environment impact from the terminating party 2) Initial Tuning
STATISTICS : 3) Troubleshooting
4) Optimization (Statistics)
Lowest in Class
For up to date after swap KPI values please check the latest Ericsson system release KPI Library!
Average
Best In Class
Pre-Launch / Initial Tunning
The Call Completion Success Rate Speech (CCSR Speech) is defined as the ratio of successful normal call disconnections, divided by the total number of call setup attempts for speech calls. It is the probability of successfully initiating, holding and then terminating a speech call from an end user perspective. This KPI can be measured by Drive test and also Statistics function of RAN system. It presents proportion of speech calls which are successfully setup, held and released by the initiating party.
Calculated with Counter Statistics, CCSR Speech is a product of Accessibility [Call Setup Success Rate (CSSR) Speech] and Retainability [1 - Drop Call Rate (DCR) Speech] within a cell or RNC.
Note 1: For RRC setup counters distinguish QoS conversational but it is not possible to split among AMR and CS64, so this term is commonNote 2: For RAB success rate only speech counters are consideredNote 3: DCR: Denominator includes every possible CS release cause -apart from normal-, including relocations Note 4: DCR: While there are specific counters to distinguish speech from video, denominator is common and includes every CS release cause, so resulting DCR Speech and resulting DCR video might not range 0-100 even if every speech call drops. DCR can range from 0 to 100 when all CS RAB types are considered in the numerator.
Reference ALU Counter Level Formula (Follow the link)
1) High Level KPI : Call Completion Success Rate Speech (CCSR Speech) [%] = (Call Setup Success Ratio (CSSR) Speech) * (1- Call Drop Rate (CDR) Speech) 2) Speech CCSR : Conversational RRC Setup Succ Rate (%) * Speech NAS Signalling Succ Rate (%) * Speech RAB Setup Succ Rate (%) 3) Speech RRC Setup Succ Rate (%) = (RRC Req Succ) / (RRC Req Att - Load Sharing RRC Connections) (all for Speech) 4) Speech NAS Signnaling Succ Rate (%) = (NAS Normal Release) / (NAS Normal Release + NAS System Release [Abnormal]) (all for Speech) 4.1 NAS = None Access Stratum Signalling 5) Speech RAB Setup Succ Rate (%) = (RAB Req Succ) / (RAB Req Att - Directed Retry Att) (all for Speech) 5.1 Direct Retry = Redirected calls to GSM due to Capacity reasons in UMTS. 6) Speech DCR (%) = (System RAB Releases [Abnormal]) / (Normal RAB Release + System RAB Release) (all for Speech)
Note1: (Speech RRC Setup Suuc Rate) Load Sharing -> Attemps rejected due movement to other Frequency due to Load Sharing Features Note2: (Speech RAB Setup Succ Rate) Directed Retry -> GSM HOs due to Capacity Reasons Note3: (Speech DCR) Normal RAB Release includes following Releases reasons: Normals, Succ Relocations, Resource Optimization Relocation, User Inactivity, UE Suggested Release Note4: (Speech DCR) It is assumed that Releases due to HOs are included in the Succ Relocations Note5: Ericsson Speech counters includes all AMR ( Single Mode, MultiMode & Wireless Priority Service)
Reference Ericsson Counter Level Formula (Follow the link)
Alternative ALU Counter Level Formula (Follow the link)
High value warning: To reach CCSR of 99% CSSR should be 99.5% and DCR 0.5%
High value warning: To reach CCSR of 98% CSSR should be 99% and DCR 1%. 4) Optimization (Statistics)
Network traffic is traditionally low for this KPI and statistical performance fluctuates.
Lowest in Class
Average
Best In Class
Pre-Launch / Initial Tunning
Call Completion Success Rate CS64 (CCSR Video)
The Call Completion Success Rate CS64 (CCSR CS64) defined as the ratio of successful normal call disconnections, divided by the total number of call setup attempts for video calls. It is the probability of successfully initiating, holding and then terminating a video call from an end user perspective. This KPI can be measured by Drive test and also Statistics function of RAN system.
Calculated with Counter Statistics, CCSR Video is a product of Accessibility [Call Setup Success Rate (CSSR) Video] and Retainability [1 - Drop Call Rate (CDR) Video] within a cell or RNC.
1) High Level KPI : Call Completion Success Rate Video (CCSR Video [%] = (Call Setup Success Ratio (CSSR) Video) * (1- Call Drop Rate (CDR) Video) 2) CCSR Video = Conversational RRC Setup Succ Rate (%) * Video RAB Setup Succ Rate (%) 3) Conversational RRC Setup Succ Rate (%) = RRC Setup Success / RRC Setup ATT (see note 1) 4) Video RAB Setup Succ Rate (%) = Video RAB Success / Video RAB Attemps 5) Video DCR = RAB Drops CS Video Release / (Total CS Releases)
Note 1: For RRC setup counters distinguish QoS conversational is not possible to split among AMR and CS64, so this term is commonNote 2: For RAB success rate it is possible to split AMR and CS64, or consider them togetherNote 3: DCR: Denominator includes every possible CS release cause -apart from normal-, including relocations Note 4: DCR: While there are specific counters to distinguish speech from video, denominator is common and includes every CS release cause, so resulting DCR Speech and resulting DCR video might not range 0-100 even if every speech call drops. DCR can range from 0 to 100 when all CS RAB types are considered in the numerator.
Reference ALU Counter Level Formula (Follow the link)
1) In Ericsson: CS 57 = Streaming , CS 64 is conversational (Video Call) 2) High Level KPI : Call Completion Success Rate CS 64 (CCSR CS 64) [%] = (Call Setup Success Ratio (CSSR) CS 64) * (1- Call Drop Rate (CDR) CS 64) 3) CS 64 CCSR : RRC Setup Succ Rate (%) * NAS Signalling Succ Rate (%) * RAB Setup Succ Rate (%) (all for CS 64) 4) CS 64 RRC Setup Succ Rate (%) = (RRC Req Succ) / (RRC Req Att - Load Sharing RRC Connections) (all for CS 64) 4.1 NAS = None Access Stratum Signalling 5) CS 64 NAS Signnaling Succ Rate (%) = (NAS Normal Release) / (NAS Normal Release + NAS System Release [Abnormal]) (all for CS 64) 6) CS 64 RAB Setup Succ Rate (%) = (RAB Req Succ) / (RAB Req Att - Directed Retry Att) (all for CS 64) 5.1 Direct Retry = Redirected calls to GSM due to Capacity reasons in UMTS. 7) CS 64 DCR (%) = ( System RAB Releases [Abnormal]) / (Normal RAB Release + System RAB Release) (all for CS 64)
Note1: (CS 64 RRC Setup Suuc Rate) Load Sharing -> Attemps rejected due movement to other Frequency due to Load Sharing Features Note2: (CS 64 RAB Setup Succ Rate) Directed Retry -> GSM HOs due to Capacity Reasons Note3: (CS 64 DCR) Normal RAB Release includes following Releases reasons: Normals, Succ Relocations, Resource Optimization Relocation, User Inactivity, UE Suggested Release Note4: (CS 64 DCR) It is assumed that Releases due to HOs are included in the Succ Relocations
Reference Ericsson Counter Level Formula (Follow the link)
Alternative ALU Counter Level Formula (Follow the link)
KPI REDUCTION: Can replace Accessibility (CSSR Video) and Retainability (1-CDR Video) KPIs.
KPI Impacted by Radio Env RAN nodes, CS Core nodes.NOTE: As in ERICSSON, ALU can not distinguish between the RRC Connection triggered by Speech and Video Call.
Start Trigger: Call Attempt or first RRC Connection Request Stop Trigger: Disconnect UL (normal call clearing)
STATISTICS:
Counters for Speech Accessibility and Speech Retainability aggregated on Cell or RNC level.For detailed formulas with counters, please refer to the links above
Impacts on the drive test route as Video Calls are unable to perform a IRAT handover to a GSM network and abnormal releases may occur on the cluster edges.
COUNTER STATISTICS :
For up to date after swap KPI values please check the latest Ericsson system release KPI Library!
Calls to internet servers be avoided – many components can be outside E/// responsibility. 2) Initial Tuning
STATISTICS : 3) Troubleshooting (E2E)
High value warning: To reach CCSR of 99% CSSR should be 99.5% and DCR 0.5%. 4) Optimization (Statistics)
Lowest in Class
Average
Best In Class
Pre-Launch / Initial Tunning
Call Completion Success Rate PS (CCSR PS)
The Call Completion Success Rate PS (CCSR PS) is defined as the ratio of successful normal call disconnections, divided by the total number of call setup attempts for packet calls. It is the probability of successfully initiating, holding and then terminating a packet connection from an end user perspective.
CCSR PS measured by Drive tests presents proportion of sessions which are successfully setup, held and released by the initiating party.
Calculated with Counter Statistics, CCSR PS is a product of Accessibility [Call Setup Success Rate (CSSR) PS] and Retainability [1 - Drop Call Rate (CDR) PS] within a cell or RNC.
Note 1: RRC Setup Counters include interactive and background QoS classes, and also High Priority SignallingNote 2: PS RAB: Counters are specific per transport channel formatNote 3: PS DCR: HSDPA drops are also included. Note 4: PS DCR denominator also includes relocations.
Reference ALU Counter Level Formula (Follow the link)
1) In Ericsson this formula just includes PS Interactive 2) High Level KPI : Call Completion Success Rate PS Interactive (CCSR PS Interactive) [%] = (Call Setup Success Ratio (CSSR) PS Interactive) * (1- Call Drop Rate (CDR) PS Interactive) 3) PS Interactive CCSR : RRC Setup Succ Rate (%) * NAS Signalling Succ Rate (%) * RAB Setup Succ Rate (%) (all for PS Interactive) 4) PS Interactive RRC Setup Succ Rate (%) = (RRC Req Succ) / (RRC Req Att - Load Sharing RRC Connections) (all for PS Interactive) 4.1 NAS = None Access Stratum Signalling 5) PS Interactive NAS Signnaling Succ Rate (%) = (NAS Normal Release) / (NAS Normal Release + NAS System Release [Abnormal]) (all for PS Interactive) 6) PS Interactive RAB Setup Succ Rate (%) = (RAB Req Succ) / (RAB Req Att - Directed Retry Att) (all for PS Interactive) 5.1 Direct Retry = Redirected calls to GSM due to Capacity reasons in UMTS. 7) PS Interactive DCR (%) = ( System RAB Releases [Abnormal] - System RAB Releases in URA_PCH - (Failed Downswitches from FACH to URA) / (Normal RAB Release - Normal RAB Release in URA + System RAB Release - System RAB Release in URA + Succ Downswitches from FACH to URA + Succ Downswitches from DCH to URA + Succ Downswitches from HS to URA ) (all for PS Interactive)
Note1: (PS Interactive RRC Setup Suuc Rate) Load Sharing -> Attemps rejected due movement to other Frequency due to Load Sharing Features Note2: (PS Interactive RRC Setup Suuc Rate) It includes Just interactive ps calls Note3: (PS Interactive RAB Setup Succ Rate) Directed Retry -> GSM HOs due to Capacity Reasons Note4: (PS InteractiveDCR) Normal RAB Release includes following Releases reasons: Normals, Succ Relocations, Resource Optimization Relocation, User Inactivity, UE Suggested Release Note5: (PS Interactive DCR) It is assumed that Releases due to HOs are included in the Succ Relocations Note6: (PS Interactive DCR) Events in URA_PCH state are discarded. Note7: (PS Interactive DCR) Denom includes Downswitches from FACH to URA ( this can decrease the KPI value)
Reference Ericsson Counter Level Formula (Follow the link)
Alternative ALU Counter Level Formula (Follow the link)
KPI REDUCTION: Can replace Accessibility (CSSR PS) and Retainability (1- CDR PS) KPIs. Merges all PS Services for Call Completion together, including CCSR PS (R99), CCSR PS (HSDPA) and CCSR PS (HSUPA).
KPI Impacted by Radio, Transmission and Core; many factors outside E/// control. For detailed formulas with counters, please refer to the links above.
Start Trigger: Call Attempt or first RRC Connection Request Stop Trigger: Deactivate PDP Context UL (normal packet clearing)
DRIVE TESTS:
STATISTICS:
DRIVE TESTS:
For up to date after swap KPI values please check the latest Ericsson system release KPI Library!
PS Interactive R99 User Throughput DL (User Throughput R99 DL)
The Packet-Switched Interactive R99 User Throughput (User Throughput R99) is the average user throughput for PS Data in Downlink evaluation (kbps) on a R99 DCH/FACH Radio Bearer.
Note 1: Measured at RLC levelNote 2: Interactive and background classes includedNote 3: It is possible to get detailed counters with throughput distribution where bins can be defined using corresponding CM attributesNote 4: It is not explicitly stated whether retransmissions, headers, etc are included in numerator, it could be assumed they are excluded as it mentions "RLC payload data".Note 5: For the calculation the RNC accumulates the RLC payload data which has been acknowledged by the UE while the UE has been in CELL_DCH state using a R99 DL DCH and the duration of the data transfer.
Reference ALU Counter Level Formula
The formula evaluates the average user throughput for PS Data in DL (kbps). It includes user data, excluding retransmissions, padding bits, data PDU headers and RLC control PDU’s. Measured in the best cell in the active set. DL RLC throughput for PS Interactive on R99 DCH, including user data only.
Reference Ericsson Counter Level Formula
KPI REDUCTION: None
KPI Impacted by Radio Env. RAN nodes, PS Core nodes; big variations between Drive test and Statistics measurement.
Golden Cluster/All Clusters
DRIVE TESTS:
Drive test with call sequences downloading a huge file (100MB or 500MB) set up from idle mode. The terminating party is ideally a UDP server attached to the GGSN within the operator domain.
Start Trigger: Time for Session Start for the download Stop Trigger: Time for Session End for the downloadNo IP losses shall exist. Tested by conducting at least 1000 ping commands from the UE to the test server, where all shall be successful. There are no Transmission or Core limitations to maximum user throughput.
STATISTICS: Different counters can be used to obtain the throughput in the RNC level (RNC counters).
Big deviations between Drive test results (mostly high speeds) and Statistics (low speeds in average)!!
As many operators have HS enabled Statistics (average throughput) goes down!!
DRIVE TESTS:
Usually FTP big files in tuned areas (mostly on 384 RAB) achieving speeds above 250 kbps
Averaged, mostly HTTP where there is no need for high speeds (internet site downloaded before switching to 384) and also transitions from HS to 64.
For up to date after swap KPI values please check the latest Ericsson system release KPI Library!
PS Interactive HSDPA User Throughput (User Throughput HSDPA)
The PS Interactive HSDPA User Throughput (User Throughput HSDPA) is the average user throughput for PS Data in Downlink on a HSDPA Radio Bearer. It includes user data but excluding retransmissions, padding bits, data PDU headers and RLC control PDU's.
Note 1: Measured at RLC levelNote 2: Interactive and background classes includedNote 3: It is possible to get detailed counters with throughput distribution where bins can be defined using corresponding CM attributesNote 4: It is not explicitly stated whether retransmissions, headers, etc are included in numerator, it could be assumed they are excluded as it mentions "RLC payload data"
Reference ALU Counter Level Formula (Follow the link)
1) This formula is defined as the total bits transmitted (and acknowledged by the UE) divided by a estimation of the average number of simultaneous users. 2)The counter pmSumAckedBitsSpiXX, XX=[0..15] defines the number of Media Access Control high-speed (MAC-hs) bits received and acknowledged by the UE. Each whole MAC-hs kilobit received and acknowledged by the UE increases the count by 1. 3)The counter pmSumNonEmptyUserBufferSpiXX, XX=[0..15] is the number of user buffers containing high-speed data. Every 2 ms the number of user buffers containing data is sampled.
Note 1:This value is net, so no payload or retransmissions are included and it is calculated in Mac-HS level Note 2: This formula takes into account TTIs where no user bits are transmitted, although data is already in buffers
Reference Ericsson Counter Level Formula
Alternative ALU Counter Level Formula (Follow the link)
KPI REDUCTION: None
KPI Impacted by Radio, Transport and PS Core nodes, RBS Hardware; big variations between Drive test and Statistics measurement. Feature dependent (e.g. Dynamic Code allocation).
Golden Cluster/All Clusters
Drive test with call sequences downloading a file (50MB) set up from idle mode. The terminating party is ideally a UDP server attached to the GGSN within the operator domain. Tests have to be executed in unloaded network.
Start Trigger: Time for Session Start for the download Stop Trigger: Time for Session End for the download
STATISTICS: ALU provides specific counters to measure HSDPA user throughput
Using counter statistics, the user throughput is dependant on the file sizes being downloaded by all end users in the network. Smaller file size downloads would result in lower counter statistic throughputs, and therefore network counters could reflect an inaccurate perception of the network.
No IP losses shall exist. Tested by conducting at least 1000 ping commands from the UE to the test server, where all shall be successful. There are no Transmission or Core limitations to maximum user throughput.
Big deviations between Drive test results (mostly high speeds achieved) and Statistics (low speeds in average)!! HSDPA UE Category and cells HSDPA+ dependency affects the maximum end user throughput . Load will also impact.
Handover attempts to 2G cells are to be avoided or mitigated in the KPI Analysis as the throughput will be degraded.
For up to date after swap KPI values please check the latest Ericsson system release KPI Library!
The Call Setup Success Rate Speech (CCSR Speech) is defined as the ratio of successful call setups, divided by the total number of call setup attempts for speech calls. It is the probability of successfully initiating a speech call from an end user perspective.
Calculated with Counter Statistics, CSSR Speech is a product of the RRC Setup Success Rate and the RAB Setup Success Rate for Speech within a cell or RNC.
Note 1: For RRC setup counters distinguish QoS conversational but it is not possible to split among AMR and CS64, so this term is commonNote 2: For RAB success rate only speech counters are considered
Reference ALU Counter Level Formula (Follow the link)
1) High Level KPI : Speech CSSR : RRC Setup Succ Rate (%) * NAS Signalling Succ Rate (%) * RAB Setup Succ Rate (%) (all for Speech) 2) Speech RRC Setup Succ Rate (%) = (RRC Req Succ) / (RRC Req Att - Load Sharing RRC Connections) (all for Speech) 3) Speech NAS Signnaling Succ Rate (%) = (NAS Normal Release) / (NAS Normal Release + NAS System Release [Abnormal]) (all for Speech) 3.1 NAS = None Access Stratum Signalling 4) Speech RAB Setup Succ Rate (%) = (RAB Req Succ) / (RAB Req Att - Directed Retry Att) (all for Speech) 4.1 Direct Retry = Redirected calls to GSM due to Capacity reasons in UMTS.
Note 1: (Speech RRC Setup Suuc Rate) Load Sharing -> Attemps rejected due movement to other Frequency due to Load Sharing Features Note 2: (Speech RAB Setup Succ Rate) Directed Retry -> GSM HOs due to Capacity Reasons Note 3: Ericsson Speech counters includes all AMR ( Single Mode, MultiMode & Wireless Priority Service)
Reference Ericsson Counter Level Formula (Follow the link)
Alternative ALU Counter Level Formula (Follow the link)
KPI REDUCTION: Can replace RRC Accessibility CS and RAB Accessibility Speech KPIs.
Start Trigger: Call Attempt or first RRC Connection Request UL Stop Trigger: Alerting DL
STATISTICS:
MTM calls to be avoided - to exclude faults and radio environment impact from the terminating party
High value warning: To reach CSSR of 99%, RRC Setup Success should be 99.5% and RAB Setup Success should be 99.5%
For up to date after swap KPI values please check the latest Ericsson system release KPI Library!
The Drop Call Rate Speech (DCR Speech) is defined as the ratio of abnormal call disconnections, divided by the total number of successful call setups for speech calls. It is the probability of successfully holding and terminating a call once it has been successfully initiated.
Calculated with Counter Statistics, DCR Speech is the ratio of abnormally released calls divided by the sum of the abnormally and normal released Speech RABs within a cell or RNC.
1) High Level KPI : Voice DCR = RAB Drops CS AMR Release / (Total CS Releases)
Note 1: DCR: Denominator includes every possible CS release cause -apart from normal-, including relocations Note 2: DCR: While there are specific counters to distinguish speech from video, denominator is common and includes every CS release cause, so resulting DCR Speech and resulting DCR video might not range 0-100 even if every speech call drops. DCR can range from 0 to 100 when all CS RAB types are considered in the numerator.
Reference ALU Counter Level Formula (Follow the link)
Note1: (Speech DCR) Normal RAB Release includes following Releases reasons: Normals, Succ Relocations, Resource Optimization Relocation, User Inactivity, UE Suggested Release Note2: (Speech DCR) It is assumed that Releases due to HOs are included in the Succ Relocations Note3: Ericsson Speech counters includes all AMR ( Single Mode, MultiMode & Wireless Priority Service)
Reference Ericsson Counter Level Formula (Follow the link)
Alternative ALU Counter Level Formula (Follow the link)
Calls to internet servers be avoided – many components can be outside E/// responsibility 2) Initial Tuning
STATISTICS : 3) Troubleshooting (E2E)
4) Optimization (Statistics)
Lowest in Class
Average
Best In Class
Pre-Launch / Initial Tunning
Call Setup Success Rate PS (CSSR PS)
The Call Setup Success Rate PS (CSSR PS) is defined as the ratio of successful call setups, divided by the total number of call setup attempts for packet calls. It is the probability of successfully initiating a packet connection from an end user perspective and includes the PDP context activation and bearer setup for the R99 service.
Calculated with Counter Statistics, CSSR PS is a product of RRC Accessibility PS and RAB Accessibility PS within a cell or RNC.
Reference ALU Counter Level Formula (Follow the link)
1) In Ericsson this formula just includes PS Interactive 2) High Level KPI : Call Completion Success Rate PS Interactive (CCSR PS Interactive) [%] = (Call Setup Success Ratio (CSSR) PS Interactive) 3) PS Interactive CCSR : RRC Setup Succ Rate (%) * NAS Signalling Succ Rate (%) * RAB Setup Succ Rate (%) (all for PS Interactive) 4) PS Interactive RRC Setup Succ Rate (%) = (RRC Req Succ) / (RRC Req Att - Load Sharing RRC Connections) (all for PS Interactive) 4.1 NAS = None Access Stratum Signalling 5) PS Interactive NAS Signnaling Succ Rate (%) = (NAS Normal Release) / (NAS Normal Release + NAS System Release [Abnormal]) (all for PS Interactive) 6) PS Interactive RAB Setup Succ Rate (%) = (RAB Req Succ) / (RAB Req Att - Directed Retry Att) (all for PS Interactive) 5.1 Direct Retry = Redirected calls to GSM due to Capacity reasons in UMTS.
Note1: (PS Interactive RRC Setup Suuc Rate) Load Sharing -> Attemps rejected due movement to other Frequency due to Load Sharing Features Note2: (PS Interactive RRC Setup Suuc Rate) It includes Just interactive ps calls Note3: (PS Interactive RAB Setup Succ Rate) Directed Retry -> GSM HOs due to Capacity Reasons
Reference Ericsson Counter Level Formula (Follow the link)
Alternative ALU Counter Level Formula (Follow the link)
KPI REDUCTION: Can replace RRC Accessibility PS and RAB Accessibility PS KPIs. Merges all PS Services for Call Setup Success Rate together, including CSSR PS (R99), CSSR PS (HSDPA) and CSSR PS (HSUPA)
Drive test downloading a 1MB file (FTP). If a single drive test is used to measure a Throughput KPI and CSSR PS, DCR PS then a larger file should be downloaded, e.g. 5MB or 10MB. The terminating party is a FTP server attached to the GGSN.
Start Trigger: Call Attempt or first RRC Connection Request Stop Trigger: Activate PDP Accept DL
DRIVE TESTS:
To reach Confidence Interval +/- 1% - 400 samples needed - 5.6 h of DT measurements (R99; avg throughput 200kbps downloading a 1MB file) with a target of 99%
To reach Confidence Interval +/- 1% - 400 samples needed - 2.2 h of DT measurements (HS; throughput 1.5Mbps downloading a 1MB file) with a target of 99%
STATISTICS:
DRIVE TESTS:
High value warning: To reach CSSR of 99%, RRC Accessibility PS should be 99.5% and RAB Accessibility PS should be 99.5%
For up to date after swap KPI values please check the latest Ericsson system release KPI Library!
Calls to internet servers be avoided – many components can be outside E/// responsibility 2) Initial Tuning
STATISTICS : 3) Troubleshooting (E2E)
4) Optimization (Statistics)
Lowest in Class
Average
Best In Class
Pre-Launch / Initial Tunning
The Drop Call Rate PS (DCR PS) is defined as the ratio of abnormal call disconnections, divided by the total number of successful call setups for packet connections. It is the probability of successfully holding and then terminating a packet connection from an end user perspective.
DCR PS measured by Drive tests, presents the proportion of PS radio bearers which are held and normally released by the initiating party.
Calculated with Counter Statistics, DCR PS is the ratio of abnormally released calls divided by the sum of the abnormally released and normal released for Packet RABs within a cell or RNC.
1) High Level KPI : PS DCR = PS Drop Release / (Total PS Releases) (PS)
Note 1: PS DCR: HSDPA drops are also included. Note 2: PS DCR denominator also includes relocations.
Reference ALU Counter Level Formula (Follow the link)
1) In Ericsson this formula just includes PS Interactive 2) High Level KPI : PS Interactive DCR (%) = ( System RAB Releases [Abnormal] - System RAB Releases in URA_PCH - (Failed Downswitches from FACH to URA) / (Normal RAB Release - Normal RAB Release in URA + System RAB Release - System RAB Release in URA + Succ Downswitches from FACH to URA + Succ Downswitches from DCH to URA + Succ Downswitches from HS to URA ) (all for PS Interactive)
Note 1: (PS InteractiveDCR) Normal RAB Release includes following Releases reasons: Normals, Succ Relocations, Resource Optimization Relocation, User Inactivity, UE Suggested Release Note 2: (PS Interactive DCR) It is assumed that Releases due to HOs are included in the Succ Relocations Note 3: (PS Interactive DCR) Events in URA_PCH state are discarded. Note 4: (PS Interactive DCR) Denom includes Downswitches from FACH to URA ( this can decrease the KPI value)
Reference Ericsson Counter Level Formula (Follow the link)
Alternative ALU Counter Level Formula (Follow the link)
KPI REDUCTION: Merges all PS Services for Drop Rate together, including DCR PS (R99), DCR PS (HSDPA) and DCR PS (HSUPA)
To reach Confidence Interval +/- 1% - 400 samples needed - 23 h of DT measurements (R99; avg throughput 200kbps) for a 5MB file and a target of 1%
STATISTICS:
DRIVE TESTS:
Transitions between channel states make a high target difficult to obtain. Different UE’s and behaviour impact heavily on the network counters and perceived performance
For up to date after swap KPI values please check the latest Ericsson system release KPI Library!
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
1) In Ericsson: CS 57 = Streaming , CS 64 is conversational (Video Call) 2) High Level KPI : Call Completion Success Rate CS 64 (CCSR CS 64) [%] = (Call Setup Success Ratio (CSSR) CS 64) * (1- Call Drop Rate (CDR) CS 64) 3) CS 64 CCSR : RRC Setup Succ Rate (%) * NAS Signalling Succ Rate (%) * RAB Setup Succ Rate (%) (all for CS 64) 4) CS 64 RRC Setup Succ Rate (%) = (RRC Req Succ) / (RRC Req Att - Load Sharing RRC Connections) (all for CS 64) 4.1 NAS = None Access Stratum Signalling 5) CS 64 NAS Signnaling Succ Rate (%) = (NAS Normal Release) / (NAS Normal Release + NAS System Release [Abnormal]) (all for CS 64) 6) CS 64 RAB Setup Succ Rate (%) = (RAB Req Succ) / (RAB Req Att - Directed Retry Att) (all for CS 64) 5.1 Direct Retry = Redirected calls to GSM due to Capacity reasons in UMTS. 7) CS 64 DCR (%) = ( System RAB Releases [Abnormal]) / (Normal RAB Release + System RAB Release) (all for CS 64)
1) In Ericsson this formula just includes PS Interactive 2) High Level KPI : Call Completion Success Rate PS Interactive (CCSR PS Interactive) [%] = (Call Setup Success Ratio (CSSR) PS Interactive) * (1- Call Drop Rate (CDR) PS Interactive) 3) PS Interactive CCSR : RRC Setup Succ Rate (%) * NAS Signalling Succ Rate (%) * RAB Setup Succ Rate (%) (all for PS Interactive) 4) PS Interactive RRC Setup Succ Rate (%) = (RRC Req Succ) / (RRC Req Att - Load Sharing RRC Connections) (all for PS Interactive) 4.1 NAS = None Access Stratum Signalling 5) PS Interactive NAS Signnaling Succ Rate (%) = (NAS Normal Release) / (NAS Normal Release + NAS System Release [Abnormal]) (all for PS Interactive) 6) PS Interactive RAB Setup Succ Rate (%) = (RAB Req Succ) / (RAB Req Att - Directed Retry Att) (all for PS Interactive) 5.1 Direct Retry = Redirected calls to GSM due to Capacity reasons in UMTS. 7) PS Interactive DCR (%) = ( System RAB Releases [Abnormal] - System RAB Releases in URA_PCH - (Failed Downswitches from FACH to URA) / (Normal RAB Release - Normal RAB Release in URA + System RAB Release - System RAB Release in URA + Succ Downswitches from FACH to URA + Succ Downswitches from DCH to URA + Succ Downswitches from HS to URA ) (all for PS Interactive)
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
The formula evaluates the average user throughput for PS Data in DL (kbps). It includes user data, excluding retransmissions, padding bits, data PDU headers and RLC control PDU’s. Measured in the best cell in the active set. DL RLC throughput for PS Interactive on R99 DCH, including user data only.
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
1) This formula is defined as the total bits transmitted (and acknowledged by the UE) divided by a estimation of the average number of simultaneous users. 2)The counter pmSumAckedBitsSpiXX, XX=[0..15] defines the number of Media Access Control high-speed (MAC-hs) bits received and acknowledged by the UE. Each whole MAC-hs kilobit received and acknowledged by the UE increases the count by 1. 3)The counter pmSumNonEmptyUserBufferSpiXX, XX=[0..15] is the number of user buffers containing high-speed data. Every 2 ms the number of user buffers containing data is sampled.
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
1) Speech DCR (%) = (System RAB Releases [Abnormal]) / (Normal RAB Release + System RAB Release) (all for Speech)
1) In Ericsson this formula just includes PS Interactive 2) High Level KPI : PS Interactive DCR (%) = ( System RAB Releases [Abnormal] - System RAB Releases in URA_PCH - (Failed Downswitches from FACH to URA) / (Normal RAB Release - Normal RAB Release in URA + System RAB Release - System RAB Release in URA + Succ Downswitches from FACH to URA + Succ Downswitches from DCH to URA + Succ Downswitches from HS to URA ) (all for PS Interactive)
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
Ericsson KPIsComments
Note1: (Speech RRC Setup Suuc Rate) Load Sharing -> Attemps rejected due movement to other Frequency due to Load Sharing Features Note2: (Speech RAB Setup Succ Rate) Directed Retry -> GSM HOs due to Capacity Reasons Note3: (Speech DCR) Normal RAB Release includes following Releases reasons: Normals, Succ Relocations, Resource Optimization Relocation, User Inactivity, UE Suggested Release Note4: (Speech DCR) It is assumed that Releases due to HOs are included in the Succ Relocations Note5: Ericsson Speech counters includes all AMR ( Single Mode, MultiMode & Wireless Priority Service)
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
Note1: (CS 64 RRC Setup Suuc Rate) Load Sharing -> Attemps rejected due movement to other Frequency due to Load Sharing Features Note2: (CS 64 RAB Setup Succ Rate) Directed Retry -> GSM HOs due to Capacity Reasons Note3: (CS 64 DCR) Normal RAB Release includes following Releases reasons: Normals, Succ Relocations, Resource Optimization Relocation, User Inactivity, UE Suggested Release Note4: (CS 64 DCR) It is assumed that Releases due to HOs are included in the Succ Relocations
Note1: (PS Interactive RRC Setup Suuc Rate) Load Sharing -> Attemps rejected due movement to other Frequency due to Load Sharing Features Note2: (PS Interactive RRC Setup Suuc Rate) It includes Just interactive ps calls Note3: (PS Interactive RAB Setup Succ Rate) Directed Retry -> GSM HOs due to Capacity Reasons Note4: (PS InteractiveDCR) Normal RAB Release includes following Releases reasons: Normals, Succ Relocations, Resource Optimization Relocation, User Inactivity, UE Suggested Release Note5: (PS Interactive DCR) It is assumed that Releases due to HOs are included in the Succ Relocations Note6: (PS Interactive DCR) Events in URA_PCH state are discarded. Note7: (PS Interactive DCR) Denom includes Downswitches from FACH to URA ( this can decrease the KPI value)
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
Note 1:This value is net, so no payload or retransmissions are included and it is calculated in Mac-HS level Note 2: This formula takes into account TTIs where no user bits are transmitted, although data is already in buffers
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
Note 1: (Speech RRC Setup Suuc Rate) Load Sharing -> Attemps rejected due movement to other Frequency due to Load Sharing Features Note 2: (Speech RAB Setup Succ Rate) Directed Retry -> GSM HOs due to Capacity Reasons Note 3: Ericsson Speech counters includes all AMR ( Single Mode, MultiMode & Wireless Priority Service)
Note1: (PS Interactive RRC Setup Suuc Rate) Load Sharing -> Attemps rejected due movement to other Frequency due to Load Sharing Features Note2: (PS Interactive RRC Setup Suuc Rate) It includes Just interactive ps calls Note3: (PS Interactive RAB Setup Succ Rate) Directed Retry -> GSM HOs due to Capacity Reasons
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
Note1: (Speech DCR) Normal RAB Release includes following Releases reasons: Normals, Succ Relocations, Resource Optimization Relocation, User Inactivity, UE Suggested Release Note2: (Speech DCR) It is assumed that Releases due to HOs are included in the Succ Relocations Note3: Ericsson Speech counters includes all AMR ( Single Mode, MultiMode & Wireless Priority Service)
Note 1: (PS InteractiveDCR) Normal RAB Release includes following Releases reasons: Normals, Succ Relocations, Resource Optimization Relocation, User Inactivity, UE Suggested Release Note 2: (PS Interactive DCR) It is assumed that Releases due to HOs are included in the Succ Relocations Note 3: (PS Interactive DCR) Events in URA_PCH state are discarded. Note 4: (PS Interactive DCR) Denom includes Downswitches from FACH to URA ( this can decrease the KPI value)
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
Average bit rate of MAC-d data flows that the NodeB receives successfully from all users over the time when data is transferred during a measurement period.
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
ALU KPIsComments
Note 1: For RRC setup counters distinguish QoS conversational but it is not possible to split among AMR and CS64, so this term is commonNote 2: For RAB success rate only speech counters are consideredNote 3: DCR: Denominator includes every possible CS release cause -apart from normal-, including relocations Note 4: DCR: While there are specific counters to distinguish speech from video, denominator is common and includes every CS release cause, so resulting DCR Speech and resulting DCR video might not range 0-100 even if every speech call drops. DCR can range from 0 to 100 when all CS RAB types are considered in the numerator.
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
Note 1: For RRC setup counters distinguish QoS conversational is not possible to split among AMR and CS64, so this term is commonNote 2: For RAB success rate it is possible to split AMR and CS64, or consider them togetherNote 3: DCR: Denominator includes every possible CS release cause -apart from normal-, including relocations Note 4: DCR: While there are specific counters to distinguish speech from video, denominator is common and includes every CS release cause, so resulting DCR Speech and resulting DCR video might not range 0-100 even if every speech call drops. DCR can range from 0 to 100 when all CS RAB types are considered in the numerator.
Note 1: RRC Setup Counters include interactive and background QoS classes, and also High Priority SignallingNote 2: PS RAB: Counters are specific per transport channel formatNote 3: PS DCR: HSDPA drops are also included. Note 4: PS DCR denominator also includes relocations.
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
Note 1: Measured at RLC levelNote 2: Interactive and background classes includedNote 3: It is possible to get detailed counters with throughput distribution where bins can be defined using corresponding CM attributesNote 4: It is not explicitly stated whether retransmissions, headers, etc are included in numerator, it could be assumed they are excluded as it mentions "RLC payload data".Note 5: For the calculation the RNC accumulates the RLC payload data which has been acknowledged by the UE while the UE has been in CELL_DCH state using a R99 DL DCH and the duration of the data transfer.
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
Note 1: Measured at RLC levelNote 2: Interactive and background classes includedNote 3: It is possible to get detailed counters with throughput distribution where bins can be defined using corresponding CM attributesNote 4: It is not explicitly stated whether retransmissions, headers, etc are included in numerator, it could be assumed they are excluded as it mentions "RLC payload data"
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
Note 1: RRC Setup Counters include interactive and background QoS classes, and also High Priority Signalling
Note 1: For RRC setup counters distinguish QoS conversational but it is not possible to split among AMR and CS64, so this term is commonNote 2: For RAB success rate only speech counters are considered
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
Note 1: DCR: Denominator includes every possible CS release cause -apart from normal-, including relocations Note 2: DCR: While there are specific counters to distinguish speech from video, denominator is common and includes every CS release cause, so resulting DCR Speech and resulting DCR video might not range 0-100 even if every speech call drops. DCR can range from 0 to 100 when all CS RAB types are considered in the numerator.
Note 1: PS DCR: HSDPA drops are also included. Note 2: PS DCR denominator also includes relocations.
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
ALU KPI vs. Ericsson KPI
Comments on KPI Comparison
Note1: (CS RRC Setup Succ Rate) Both are including Conversational Originating, Terminanting and Emergency Calls Note2: (CS RRC Setup Succ Rate) Ericsson substracts Load Sharing from overall attemps. Note3: Ericsson includes in the formula NAS signalling Succ rate.. this mighe be skipped to have comparable formulas Note4: (CS RRC Setup Succ Rate) ALU has specific counters for first RRC connection request (denominator). Ericsson should work the same as it specifies in documentation the following note: "The counter does not count repeated RRC connection requests" Note5: (CS RRC Setup Success Rate) As in ERICSSON, ALU can not distinguish between the RRC Connection triggered by Speech and Video Call. Note6: (CS RAB Setup Succ Rate) Both are based on AMR only Note7: (CS RAB Setup Succ Rate) Ericsson discards RABs ATT redirected to GSM due to Direct Retry (capacity reasons) Note8: (CS DCR) Ericcsson includes also MultiMode Note9: (CS DCR) ALU DCR should be calculated adding in numerator drops for any CS RAB service to range from 0 to 100. If only AMR drops are considered in the numerator, but denominator includes all CS RAB normal releases (not allowing the split among speech and video) then result will be lower than an ordinary CS DCR Speech
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
Note1: (Video Call Conversational RRC Setup Succ Rate) Both are including Conversational Originating, Terminanting Note2: (Video Call Conversational RRC Setup Succ Rate) Ericsson substracts Load Sharing from overall attemps Note3: Ericsson includes in the formula NAS signalling Succ rate.. this might be skipped to have comparable formulas Note4: (Video Call Conversational RRC Setup Succ Rate) ALU has specific counters for first RRC connection request (denominator). Ericsson should work the same as it specifies in documentation the following note: "The counter does not count repeated RRC connection requests" Note5: (Video Call Conversationa RRC Setup Success Rate) As in ERICSSON, ALU can not distinguish between the RRC Connection triggered by Speech and Video Call. Note5: (Video Call Conversational RAB Setup Succ Rate) Both are based on CSConv64 (ALU) and CS 64 (Ericsson), that are the counters for Video Calls Note6: (Video Call Conversational RAB Setup Succ Rate) Ericsson discards RABs ATT redirected to GSM due to Direct Retry (capacity reasons) Note7: (Video Call DCR): ALU DCR should be calculated adding in numerator drops for any CS RAB service to range from 0 to 100. If only VIDEO drops are considered in the numerator, but denominator includes all CS RAB normal releases (not allowing the split among speech and video) then result will be lower than an ordinary CS DCR Speech
Note1: (PS RRC Setup Succ Rate) ALU includes interactive, background and high priority signalling while Ericsson only includes interactive (others could be removed to make the terms more comparable) Note2: (PS RRC Setup Succ Rate) Ericsson excludes re-transmissions. (ALU does not specify it) Note3: (PS RRC Setup Succ Rate) Ericsson substracts Load Sharing from overall attemps. Note4: Ericsson includes in the formula NAS signalling Succ rate (this mighe be skipped to have comparable formulas) Note5: (PS RAB Setup Succ Rate) ALU counters are specific per transport channel format Note6: (PS RAB Setup Succ Rate) Ericsson discards RABs ATT redirected to GSM due to Direct Retry (capacity reasons) Note7: (PS Drop Call Rate) Ericsson discards URA PCH . Not clear in ALU Note8: (PS Drop Call Rate) Ericsson formula includes in the denom Downswitching from FACH to URA. Not clear in ALU Note9: (PS Drop Call Rate) Both include relocations
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
Note 1: Both are measured at RLC levelNote 2: ALU does not specify whether retransmissions are include, but seems like not and both try to include only "payload" (user data not counting protocol header, padding bits…)Note 3: ALU allows the possibility to get a throughput distribution, which settings can be modified by corresponding CM attributes
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
Note1: (CS RRC Setup Succ Rate) Both are including Conversational Originating, Terminanting and Emergency Calls Note2: (CS RRC Setup Succ Rate) Ericsson substracts Load Sharing from overall attemps. Note3: Ericsson includes in the formula NAS signalling Succ rate.. this mighe be skipped to have comparable formulas Note4: (CS RRC Setup Succ Rate) ALU has specific counters for first RRC connection request (denominator). Ericsson should work the same as it specifies in documentation the following note: "The counter does not count repeated RRC connection requests" Note5: (CS RRC Setup Success Rate) As in ERICSSON, ALU can not distinguish between the RRC Connection triggered by Speech and Video Call. Note6: (CS RAB Setup Succ Rate) Both are based on AMR only Note7: (CS RAB Setup Succ Rate) Ericsson discards RABs ATT redirected to GSM due to Direct Retry (capacity reasons)
Note1: (PS RRC Setup Succ Rate) ALU includes interactive, background and high priority signalling while Ericsson only includes interactive (others could be removed to make the terms more comparable) Note2: (PS RRC Setup Succ Rate) Ericsson excludes re-transmissions. (ALU does not specify it) Note3: (PS RRC Setup Succ Rate) Ericsson substracts Load Sharing from overall attemps. Note4: Ericsson includes in the formula NAS signalling Succ rate (this mighe be skipped to have comparable formulas) Note5: (PS RAB Setup Succ Rate) ALU counters are specific per transport channel format Note6: (PS RAB Setup Succ Rate) Ericsson discards RABs ATT redirected to GSM due to Direct Retry (capacity reasons)
Prepared: Inmaculada Serrano, Augusto SanchezDate: 2012-03-02
Sheet: Counter Level KPIsEricsson Internal
_x000D_Rev: PA1
Note1: (CS DCR) Ericcsson includes also MultiMode Note2: (CS DCR) ALU DCR should be calculated adding in numerator drops for any CS RAB service to range from 0 to 100. If only AMR drops are considered in the numerator, but denominator includes all CS RAB normal releases (not allowing the split among speech and video) then result will be lower than an ordinary CS DCR Speech
Note1: (PS Drop Call Rate) Ericsson discards URA PCH . Not clear in ALU Note2: (PS Drop Call Rate) Ericsson formula includes in the denom Downswitching from FACH to URA. Not clear in ALU Note3: (PS Drop Call Rate) Both include relocations