Core & Radio Network KPIs
Purpose
The purpose of these KPIs is to assist Core & Radio Network staff and management optimise throughput thereby helping reduce costs, and maximise profit.
They provide pointers at the operational performance of the business, both as a single network entity and broken down into specific, relevant elements.
KPIs use either a single parameter or a combination of parameters, often generated automatically by 'counters' whereby the output is a comprehensive performance indicator in itself.
These counters can be built into the network elements, the element management systems or programmed individually to suit local requirements.
Scope
The scope of these Key Performance Indicators is limited to activities, as defined by the organisation, to lie inder the relevant business area.
However the data used by and/or collected by the counters and measurement tools could originate from anywhere within - or without - the business.
Each individual KPI is reviewed to assess it's "
fitness for purpose" on a periodic basis as defined by the KPI owner.
This is a temporary message - once each individual 'scope" document is written, it will be replaced within the coding that produced this KPI document.
Definitions
Each KPI is described by the following items:
- KPI ID Number: contains the full name of the KPI.
- Target Value: contains the max or min threshold
- Frequency: describes the type of measurement i.e. daily, weekly, or monthly.
- Description: this item provides short explanation of the KPI.
- Formula: this item contains the formula composed by the counters for the KPI.
- Counters: this item contains counters used for calculation and described how they are triggered.
- Object Class: this item shows from which element the measurement statistical data are taken.
- Tools: this item shows which tool is used to calculate the KPI.
- Trigger: the event that starts the KPI measurement.
- Terminator: the event that stops the KPI measurement.
- Parameter: the limiting factor in a performance measurement
- Unit Range: this items shows the unit range value of the KPI.
- Review Period: this defines the aging process of the KPI. It helps management ensure it's use is relevant.
- Owner: this item reflects who has the authority to adjust the KPI paramaters and to whom any queries should be addressed concerning the measurements.
- Remark: this item is sometimes added to write notes and additional information.
- Process: the process or processes (or work instruction/procedure) to which this KPI is applicable. Please note that any links shown are under development and not yet functional
A measurement type can have several sub-counters; therefore the used sub-counters are listed in brackets with following meanings as examples:
- [3]: sub-counter 3 has to be taken.
- [1,2,4]: sub-counters 1, 2 and 4 have to be added.
- [1 - 4, 7 - 10]: sub-counters 1, 2, 3, 4, 7, 8, 9 and 10 have to be added.
- [all]: all sub-counters have to be added.
Not all Definitions apply to every KPI. Where an element has no value in the database, it is not displayed.
Note that when the average of a series of inputs is calculated, this is taken to be the arithmetic MEDIAN.
Measurables
Click on a button for more details of the KPI.
| KPI CRN1 |
Mean RXLEV |
| Target Value |
>-104 dBm |
| Frequency |
Monthly |
| Description |
These indicators give the mean RXLEV on busy TCH. Two indicators distinguish between uplink and downlink. |
| Formula |
Mean RXLEV DL = ?(i * PWRUPDW[72+i] / PWRUPDW[73..136])
Mean RXLEV UL = ?(i * PWRUPDW[i] / PWRUPDW[1…64])
Where i = 1…64 |
| Counter Descriptions |
PWRUPDW[1-64,73-136]: The BTSE updates the counters according to the information retrieved from:
The MEASUREMENT REPORTS (MS ? BTS) (downlink measurements),
BTS internal measurements (uplink measurements)
|
| Object Class |
TRX |
| Unit Range |
% |
| Process |
| |
| KPI CRN2 |
Call Setup Success Rate |
| Target Value |
>98% |
| Frequency |
Weekly |
| Description |
This indicator will give the Call Setup Success Rate at the BSS to setup up a Radio connection in formula (a) and at the MSC an end to end connection in formula (b) from the MS point of view, if the mobile station sends an assignment complete to the BSC and the BSC informs the MSC with an assignment complete message. |
| Formula |
a- BSS Call Setup Success Rate = 100 * (NSUCCHPC/(ATIMASCA–ImmAssNoSeiz)) * (1 - NRCLRREQ / NSUCCHPC) * (ASSSUCC + TASSFAIL) / TASSATT,, b- E2E CSSR = 100 * NSUCCHPC / ATIMASCA * (1 – NRCLRREQ / NSUCCHPC - VC!SSSProcFailCS) * (ASSSUCC + TASSFAIL) / TASSATT = 100 * (ASSSUCC + TASSFAIL) / ATIMASCA[1-4] |
| Counter Descriptions |
NSUCCHPC[1-6]: Receipt of a valid ESTABLISHMENT INDICATION (BTS --> BSC).
ATIMASCA[1-6]: This measurement is triggered by the receipt of a valid CHANNEL REQUIRED (BTS --> BSC).
ImmAssNoSeiz: The main reasons for this behaviour are Phantom RACHs, messages not foreseen for the observed cell. Other reasons are not received SABM messages due to air interface problems.
NRCLRREQ[19-26]: This measurement is triggered by a clear request message sent from the BSC to MSC with the specified causes.
ASSSUCC = TASSSUCC[2] + SINTHINT[7] + SUINBHDO[7] + SUOISHDO[7]: These indicators will give you the number of successful completed assignment procedures. Successful completed assignment procedures are incremented even with successful outgoing directed retry.
TASSSUCC[2]: This measurement is triggered by the transmission of an ASSIGNMENT COMPLETE (BSC --> MSC).
Successful Intra Cell Intra BSC SINTHINT[7]: The measurement is triggered by the receipt of a valid HANDOVER COMPLETE (MS --> BSC) cause DR.
Successful Inter Cell Inter BSC SUINBHDO[7]: This measurement is triggered by the receipt of a valid CLEAR COMMAND (MSC --> BSC) with cause “handover successful” cause direct retry.
SUOISHDO[7]: This measurement is triggered by the receipt of a CLEAR COMMAND message (3G MSC --> BSC) related to an intersystem handover DR.
TASSFAIL[8]: The measurement is triggered by the transmission of an ASSIGNMENT FAILURE (BSC --> MSC) with cause No radio resource available.
TASSATT[2]: This measurement is triggered by the receipt of a valid ASSIGNMENT REQUEST (MSC --> BSC).
VC!SSSProcFailCS: ImmAssSuccCS[1-4] - AssAtt – SDCCHDropCS = NSUCCHPC(CS) - AssAtt – SDCCHDropCS.
|
| Object Class |
BTS |
| Unit Range |
% |
| Process |
| |
| KPI CRN3 |
Call Setup Success Rate 3G |
| Target Value |
>98% |
| Frequency |
Weekly |
| Description |
This indicator will give the Call Setup Success Rate at the RNC to setup up an end to end connection. |
| Formula |
((rrcEstabSucc / rrcEstabAtt) * (rabEstabTypeSucc / rabEstabTypeAtt)) * 100 |
| Counter Descriptions |
rrcEstabSucc[1-10,15,17,18,20]: Receipt of an RRC CONNECTION SETUP COMPLETE message sent by the UE to the UTRAN.
RrcEstabAtt[1-10,15,17,18,20]: Receipt of an RRC CONNECTION REQUEST message sent by the UE to the UTRAN.
RabEstabTypeSucc[all]: Transmission of a RANAP-message RAB ASSIGNMENT RESPONSE sent by the UTRAN to the CN, with a “RAB to be set up” or when an active link set already exists.
RabEstabTypeAtt[all]: Receipt of a RANAP-message RAB ASSIGNMENT REQUEST sent by the CN to the UTRAN, with a “RAB to be set up” or when an active link set already exists. When RANAP RAB ASSIGNMENT REQUEST (SETUP) is received.
|
| Object Class |
UCELL |
| Unit Range |
% |
| Remarks & Comment |
Only UTRAN failures are taken into account; UTRAN can’t know the failure in the NAS procedures if the MSC rejects the establishment request due to an internal check. |
| Process |
| |
| KPI CRN4 |
Paging Success Rate SSS Measurements 2G & 3G |
| Target Value |
>95% |
| Frequency |
Weekly |
| Description |
This KPI indicates the number of successful received paging response for MTER related to total number of paging attempts. |
| Formula |
(RECEIVED_PAG_RESP / STARTED_PAGING_PROC) * 100 |
| Counter Descriptions |
RECEIVED_PAG_RESP: Each time PAGING RESPONSE is received from the BSC.
STARTED_PAGING_PROC: Each time PAGING is sent.
|
| Object Class |
LOC AREA |
| Unit Range |
% |
| Remarks & Comment |
Contains all 2G and 3G transactions. |
| Process |
| |
| KPI CRN5 |
Call Loss Rate 2G |
| Target Value |
<0.5% |
| Frequency |
Weekly |
| Description |
This indicator provides the rate of calls meeting blocking state because all the traffic channels were occupied and busy. This indicator will give you the TCH seizure blocked rate by meaning the rate where new TCH Seizure Attempts could not be handled meeting blocking state by the observed cell, because all traffic channels were occupied / blocked. TCH seizure attempts for HO and Directed Retry are included in the formulas. |
| Formula |
(ATCHSMBS / ATTCHSEI) * 100 |
| Counter Descriptions |
ATCHSMBS[1,3]: Triggered by the following messages:
Receipt of a valid ASSIGNMENT REQUEST (MSC --> BSC)
Receipt of a valid CHANNEL REQUIRED (BTS --> BSC)
Receipt of a valid HANDOVER REQUEST (MSC --> BSC) (external / MSC controlled incoming handovers)
Receipt of a valid INTERCELL HANDOVER CONDITION INDICATION (BTS --> BSC) BSC controlled intercell handovers)
Receipt of a valid INTRACELL HANDOVER CONDITION INDICATION (BTS --> BSC) BSC controlled intracell handovers)
ATTCHSEI: Triggered by the following messages:
Receipt of a valid ASSIGNMENT REQUEST (MSC --> BSC)
Receipt of a valid HANDOVER REQUEST (MSC --> BSC) (external / MSC controlled incoming handovers)
Receipt of a valid INTERCELL HANDOVER CONDITION INDICATION (BTS --> BSC) (BSC controlled intercell handovers)
Receipt of a valid INTRACELL HANDOVER CONDITION INDICATION (BTS --> BSC) (BSC controlled intracell handovers)
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Process |
| |
| KPI CRN6 |
Drop Call Rate 2G |
| Target Value |
<2% |
| Frequency |
Weekly |
| Description |
This indicator provides the number of abnormal clear request related to the total number of clear command except the reason of successful handover issued by the MSC; this measurement is from the MS point of view. |
| Formula |
(NRCLRREQ[1-3,5-12,14-18] / (NRCLRCMD - NRCLRREQ[4,13] – TASSFAIL–SUIISHDO)) * 100 |
| Counter Descriptions |
NRCLRREQ[1-18]: This measurement is triggered by a clear request message sent from the BSC to MSC with the specified causes.
NRCLRCMD[1,2, 4-8,10-12]: This measurement is triggered by a CLEAR COMMAND message sent from the MSC to BSC with the specified causes.
TASSFAIL[6-8]: The measurement is triggered by the transmission of an ASSIGNMENT FAILURE (BSC ? MSC). The counters are updated dependent on the failure cause and the channel type which was requested.
SUIISHDO[1]: This measurement is triggered by the transmission of a HANDOVER COMPLETE message related to an intersystem handover (BSC? 3G MSC).
|
| Object Class |
BTS |
| Unit Range |
% |
| Remarks & Comment |
This measurement is not quite accurate since when the BSC sends release request it doesn’t distinguish between the normal assigned TCH and TCH that has been assigned due to Inter-System Handover RAT, for this reason we can’t subtract the abnormal releases in the nominator if some abnormal releases exist for the RATs TCH, while in the dominator the successful incoming Inter-System Handovers RAT have been eliminated by subtracting them from release commands because they shouldn’t be counted for this specific measurement. |
| Process |
| |
| KPI CRN7 |
Drop Call Rate 3G |
| Target Value |
<2% |
| Frequency |
Weekly |
| Description |
This KPI describes the ratio of abnormal RAB releases related to the total number of RAB release CN originating after subtracting calls assigned from Inter RAT system, then the Call Drop Rate considers excluding incoming handovers Inter RAT system only from the dominator. |
| Formula |
?rabrelUtranOrigin
Drop call rate = Cell_________________________ *100
?rabRelCnOrigin –(interRatHoSuccInc+rrcEstabSucc)
Cell |
| Counter Descriptions |
rabrelUtranOrigin[2-7,10,12-14,16-17,19-21,24,26-28]: This counter provides the number of abnormal UTRAN initiated RAB releases for each cell which is based on transmission of a RANAP message IU RELEASE REQUEST or RAB RELEASE REQUEST sent by the UTRAN to the CN involving release of RABs.
rabRelCnOrigin[all]:
Receipt of a RANAP RAB ASSIGNMENT REQUEST message sent by the CN to the UTRAN, with “RABs to release”.
Receipt of a RANAP: IU RELEASE COMMAND message sent by the CN to the UTRAN involving release of RABs.
InterRatHoSuccInc[1]: It’s a successful incoming CS inter RAT handover, triggered by Receipt of an RRC HANDOVER TO UTRAN COMPLETE message sent from the UE to the target RNC.
RrcEstabSucc[12]: It’s the number of successful RRC connection establishment of Inter-RAT Cell change order and it’s triggered by Receipt of an RRC as RRC CONNECTION SETUP COMPLETE message sent by the UE to the UTRAN.
|
| Object Class |
RNC |
| Unit Range |
% |
| Remarks & Comment |
As RAB release may be counted in a different cell as the RAB establishment due to handover procedures, the determination of the Call Drop Rate is per RNC related not per cell related. It does not make sense to use it for a single cell because this can lead to results greater than 100%. This measurement is not quite accurate since the RNC sends release request doesn’t distinguish between the normal assigned RAB and RABs those have been assigned due to Inter-System Handover RAT, for this reason we couldn’t subtract the abnormal releases of these RABs assigned by RAT in the nominator while if some releases exist since in the dominator the successful incoming Inter-System Handovers RAT have been eliminated by subtracting them from Total Calls. Note that the UE is still reachable via a RRC connection but it loses the assigned service. |
| Process |
| |
| KPI CRN8 |
Handover Success Rate |
| Target Value |
>97% |
| Frequency |
Daily |
| Description |
These indicators will give rate of successful Intracell, Intercell Intra-BSC and Intercell Inter-BSC Handovers, from TCH to another within the same cell, where the target cell has to be controlled by the same BSC and where neighbouring cells controlled by a different BSC when the mobile station sends to the BSC handover or assignment complete message depending to the type of Handovers. |
| Formula |
((SINTHITA + SOUINIRH + SUINBHDO) / (ATINHIAC + AOUINIRH + ATINBHDO)) * 100 |
| Counter Descriptions |
SINTHITA [all]: Receipt of a valid ASSIGNMENT COMPLETE (MS --> BSC).
ATINHIAC[all]: Receipt of INTRA-CELL HANDOVER CONDITION INDICATION message (BTS --> BSC).
SOUINIRH[all]: Receipt of a valid HANDOVER COMPLETE (target cell --> BSC).
AOUINIRH[all]: Transmissions of a HANDOVER command (BSC --> observed BTS).
SUINBHDO[all]: This measurement is triggered by the receipt of a valid CLEAR COMMAND (MSC --> BSC) with cause “handover successful”.
ATINBHDO[all]: This measurement is triggered by the receipt of a HANDOVER COMMAND (MSC --> BSC) containing the BCCH frequency and BSIC of an external neighbour cell.
|
| Object Class |
BTS |
| Unit Range |
% |
| Process |
| |
| KPI CRN9 |
Hard Handover Success Rate 3G |
| Target Value |
>97% |
| Frequency |
Daily |
| Description |
This KPI provides the ratio between successful outgoing circuit switched Intra-Node B, Intra RNC and Inter RNC hard handover with additional to hard handover interruptions caused by hard handovers fails not affected by handovers procedures related to the attempted outgoing circuit switched hard handover. |
| Formula |
((hhoAllOutSucc1 + hhoAllOutSucc2 + hhoAllOutSucc3 + hhoAllOutSucc4 + hhoAllOutFail1 + hhoAllOutFail2 + hhoAllOutFail3 + hhoAllOutFail4) / (hhoAllOutAtt1 + hhoAllOutAtt2 + hhoAllOutAtt3 + hhoAllOutAtt4)) * 100 |
| Counter Descriptions |
hhoAllOutSucc(1-3)[1]: This counter provides the number of successful Intra Node B, Intra RNC, Inter RNC outgoing hard handovers with separately of hard handover type for each cell. Triggered by Receipt of an RRC message PHYSICAL CHANNEL RECONFIGURATION COMPLETE sent from the UE to the UTRAN, indicating the successful inter-frequency handover.
hhoAllOutFail(1-3)[4,5,9]: Handovers which have not successfully been completed due to reasons not related to the hard handover procedure by receiving NBAP RL FAILURE INDICATION message or by RRC with cause CELL UPDATE and RNSAP UPLINK SIGNALING TRANSFER message.
hhoAllOutSucc4[0-1]: Triggered by the following types.
Receipt of a RANAP IU RELEASE COMMAND message, sent by the CN to the serving RNC, indicating a successful inter RAT handover. This trigger condition includes counting of CS single calls and CS/PS multi calls.
Receipt of a RANAP IU RELEASE COMMAND message (for DCH:PS Single calls), sent by the PS CN to the serving RNC, indicating a successful outgoing UTRAN controlled PS inter RAT handover.
hhoAllOutFail4[1,2,6,7]: Triggered by the following types.
Receipt of an RRC: HANDOVER FROM UTRAN FAILURE message sent from the UE to the UTRAN, indicating a failed inter-frequency inter system handover (DCH: CS single or DCH: CS/PS multi).
Receipt of the RRC: CELL CHANGE ORDER FROM UTRAN FAILURE message sent from the UE to the serving RNC, indicating an unsuccessful PS inter RAT handover (DCH: PS single).
hhoAllOutAtt(1-3): This counter provides the number of attempted Intra Node B, Intra RNC and Inter RNC outgoing hard handovers for each cell. Triggered by transmission of an RRC message PHYSICAL CHANNEL RECONFIGURATION sent from the UTRAN to the UE, indicating the attempt of inter-frequency handover.
hhoAllOutAtt4: Transmission of an RRC: HANDOVER FROM UTRAN COMMAND message sent from the UTRAN to the UE, indicating the attempt of CS inter-system handover. This trigger condition includes counting of CS single calls and CS/PS multi calls.
Transmission of an RRC: CELL CHANGE ORDER FROM UTRAN message sent from the serving RNC to the UE, indicating an attempted outgoing PS inter RAT handover (UTRAN controlled).
|
| Object Class |
UCELL |
| Unit Range |
% |
| Process |
| |
| KPI CRN10 |
3G to 2G Inter-System Handover Success Rate |
| Target Value |
>97% |
| Frequency |
Daily |
| Description |
These indicators will give the rate of successful outgoing Inter System Handovers of multi calls with additional to hard handover interruptions caused by hard handovers fails not affected by handovers procedures. |
| Formula |
((hhoAllOutSucc4 + hhoAllOutFail4) / hhoAllOutAtt4) * 100 |
| Counter Descriptions |
hhoAllOutSucc4[1,2]: Triggered on the following different types.
Receipt of a RANAP message by IU RELEASE COMMAND, sent by the CN to the serving RNC, indicating a successful inter RAThandover. This trigger condition includes counting of CS single calls and CS/PS multi calls.
Receipt of a RANAP: IU RELEASE COMMAND message (for DCH:PS Single calls), sent by the PS CN to the serving RNC, indicating a successful outgoing UTRAN controlled PS inter RAT handover.’ hhoAllOutFail4[1,2,6,7]: Triggered by the following different types.
Receipt of an RRC: HANDOVER FROM UTRAN FAILURE message sent from the UE to the UTRAN, indicating a failed inter-frequency inter system handover (DCH: CS single or DCH: CS/PS multi).
Receipt of the RRC: CELL CHANGE ORDER FROM UTRAN FAILURE message sent from the UE to the serving RNC, indicating an unsuccessful PS inter RAT handover (DCH: PS single).
hhoAllOutAtt4[1,2]: Triggered by the following different types.
Transmission of an RRC: HANDOVER FROM UTRAN COMMAND message sent from the UTRAN to the UE, indicating the attempt of CS inter-system handover. This trigger condition includes counting of CS single calls and CS/PS multi calls.
Transmission of an RRC: CELL CHANGE ORDER FROM UTRAN message sent from the serving RNC to the UE, indicating an attempted outgoing PS inter RAT handover (UTRAN controlled).
|
| Object Class |
UCELL |
| Unit Range |
% |
| Process |
| |
| KPI CRN11 |
3G to 2G Inter-System Handover Failure Rate |
| Target Value |
<3% |
| Frequency |
Daily |
| Description |
This KPI provides the outgoing inter RAT handover failure rate with reconnecting to the originating cell. |
| Formula |
(hhoAllOutFail4 / hhoAllOutAtt4) * 100 |
| Counter Descriptions |
hhoAllOutFail4[3-5,8-9]: Triggered by the following different types.
Receipt of an RRC: HANDOVER FROM UTRAN FAILURE message sent from the UE to the UTRAN, indicating a failed inter-frequency inter system handover (DCH: CS single or DCH: CS/PS multi).
Receipt of the RRC: CELL CHANGE ORDER FROM UTRAN FAILURE message sent from the UE to the serving RNC, indicating an unsuccessful PS inter RAT handover (DCH: PS single).
hhoAllOutAtt4[1,2]: Triggered by the following different types.
Transmission of an RRC: HANDOVER FROM UTRAN COMMAND message sent from the UTRAN to the UE, indicating the attempt of CS inter-system handover. This trigger condition includes counting of CS single calls and CS/PS multi calls.
Transmission of an RRC: CELL CHANGE ORDER FROM UTRAN message sent from the serving RNC to the UE, indicating an attempted outgoing PS inter RAT handover (UTRAN controlled).
|
| Object Class |
UCELL |
| Unit Range |
% |
| Remarks & Comment |
The counter hhoAllOutFail4 of 3G system doesn’t have the sub-counter “No Reply” like hhoAllOutFail1, 2, 3. For this reason we don’t have Intersystem Handover Drop Rate measurement. |
| Process |
| |
| KPI CRN12 |
Core Network Availability |
| Target Value |
>99.99% |
| Frequency |
Weekly |
| Description |
This method will give the Core Network availability in a Granularity period. |
| Formula |
(1 – (Time OOS / Granularity)) * 100 |
| Counter Descriptions |
Time OOS: Triggered once the system goes down until last transition, collected from the NOC Unit, value in minutes.
Granularity: Time of interval period, in minutes.
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Remarks & Comment |
MSC 2G is integrated to the CN then availability includes both of 2G and 3G. |
| Process |
| |
| KPI CRN13 |
Signalling Success Rate |
| Target Value |
>99% |
| Frequency |
Weekly |
| Description |
This KPI indicates the rate of successful calls that haven’t been terminated due to failure/congestion/overload on associated CCS7 signaling system links for MORTR, MICTR. |
| Formula |
(1– ((UNS_LINK_FAIL(MORTR) + UNS_LINK_FAIL(MICTR)) / (CALL_ATTEMPTS(MORTR) + CALL_ATTEMPTS(MICTR)))) * 100 |
| Counter Descriptions |
UNS_LINK_FAIL: Each time a call is released due to CCS7 failure (e.g., on receipt of “STOP TRAFFIC”).
CALL_ATTEMPTS: On receipt of each CM SERVICE REQUEST with SERVICE TYPE = mobile originating call or establishment of all emergency call attempts.
MICTR each time IAM is received (all call attempts).
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Process |
| |
| KPI CRN14 |
Call Processor Load (switching) |
| Target Value |
<70% |
| Frequency |
Weekly |
| Description |
This KPI indicates the rate of Call Processor Load producing by the switching procedure. |
| Formula |
?(Carried_Traffic)*100/Xn |
| Counter Descriptions |
Carried_Traffic: A measurement interval takes 15 minutes (900 seconds) for Call Processors loads CALLPLOAD, the counters for traffic measurement are constantly updated in a 4 second cycle.
Xn: Maximum Capacity Load of the CAPs, this value depends on the number of used Call Processors in the Exchange.
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Remarks & Comment |
The processor load handles the 2G and 3G systems. |
| Process |
| |
| KPI CRN15 |
Call Processor Load (SGSN) |
| Target Value |
<70% |
| Frequency |
Weekly |
| Description |
This KPI indicates the rate of Call Processor Load producing by the SGSN procedure with total average load equal to 1000mErl. |
| Formula |
CallProcessingLoad / 10 |
| Counter Descriptions |
CallProcessingLoad = vcpu00mpTotalAverageLoad: Indicates the mean load (in mErl) of all VCPUs of a given MP.
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Remarks & Comment |
The processor load handles the 2G and 3G systems. |
| Process |
| |
| KPI CRN16 |
Call Completion Rate (2G & 3G) |
| Target Value |
>97% |
| Frequency |
Weekly |
| Description |
This indicator will give the performance of the network with the impact of the radio part that affects the call in abnormal release. |
| Formula |
(SPEECH_CALLS_WITH_ANSWER(MOUT_PLMN) + SPEECH_CALLS_WITH_ANSWER (MTER) + SPEECH_CALLS_WITH_ANSWER(MOUT_NOT_PLMN) – (BS_REL_WITH_ANSWER(MOUT_PLMN) + BS_REL_WITH_ANSWER(MTER) + BS_REL_WITH_ANSWER(MOUT_NOT_PLMN))) / (SPEECH_CALLS_WITH_ANSWER(MOUT_PLMN) + SPEECH_CALLS_WITH_ANSWER(MTER) + SPEECH_CALLS_WITH_ANSWER(MOUT_NOT_PLMN) + (BS_REL_WITH_ANSWER(MOUT_PLMN) + BS_REL_WITH_ANSWER(MTER) + BS_REL_WITH_ANSWER(MOUT_NOT_PLMN))) * 100 |
| Counter Descriptions |
SPEECH_CALLS_WITH_ANSWER: Each time the connection has actually been released in response to the receipt of the respective message for:
MTER: CONNECT
MOUT_PLMN, MOUT_NOT_PLMN: ANM
BS_REL_WITH_ANSWER: each time CONNECT ACK is received when SUBSYSTEM PROHIBITED, RESET,RESET CIRCUIT, RELEASE COMPLETE/CLEAR REQ for particular reason(s) were received for a call of MTER, MOUT_PLMN, MOUT_NOT_PLMN.
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Remarks & Comment |
This measurement includes transactions both of 2G and 3G. |
| Process |
| |
| KPI CRN17 |
Call Completion Rate (3G) |
| Target Value |
>97% |
| Frequency |
Weekly |
| Description |
Call Completion Rate (3G Systems Only) |
| Formula |
(U_SPEECH_CALLS_WITH_ANSWER (MOUT_PLMN) + U_SPEECH_CALLS_WITH_ANSWER (MTER) + U_SPEECH_CALLS_WITH_ANSWER (MOUT_NOT_PLMN) – (U_ BS_REL_WITH_ANSWER (MOUT_PLMN) + U_BS_REL_WITH_ANSWER (MTER) + U_BS_REL_WITH_ANSWER(MOUT_NOT_PLMN))] / [U_SPEECH_CALLS_WITH_ANSWER (MOUT_PLMN) + U_SPEECH_CALLS_WITH_ANSWER (MTER) + U_SPEECH_CALLS_WITH_ANSWER (MOUT_NOT_PLMN) + (U_BS_REL_WITH_ANSWER (MOUT_PLMN) + U_BS_REL_WITH_ANSWER (MTER) + U_BS_REL_WITH_ANSWER (MOUT_NOT_PLMN))) * 100 |
| Counter Descriptions |
SPEECH_CALLS_WITH_ANSWER: Each time the connection has actually been released in response to the receipt of the respective message for:
MTER: CONNECT
MOUT_PLMN, MOUT_NOT_PLMN: ANM
BS_REL_WITH_ANSWER: each time CONNECT ACK is received when SUBSYSTEM PROHIBITED, RESET,RESET CIRCUIT, RELEASE COMPLETE/CLEAR REQ for particular reason(s) were received for a call of MTER, MOUT_PLMN, MOUT_NOT_PLMN.
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Process |
| |
| KPI CRN18 |
Location Update Success Rate |
| Target Value |
>99% |
| Frequency |
Weekly |
| Description |
This KPI indicates the number of successful requests for location updating (normal, periodic attach, IMSI attach) per number of attempts. |
| Formula |
((SUCC_LOCUPD_WITH_IMSI_ATTACH + SUCC_REQUESTS_LOCUPD + INTW_BSS_PLMN_NOT_ALLOWED) / (REQUESTS_LOCUPD)) * 100 |
| Counter Descriptions |
SUCC_LOCUPD_WITH_IMSI_ATTACH: Each time LOCATION UPDATE ACCEPT containing “IMSI attach” is sent to the BSS.
SUCC_REQUESTS_LOCUPD: Each time LOCATION UPDATE ACCEPT is received for normal and periodic location update.
INTW_BSS_PLMN_NOT_ALLOWED: Each time LOCATION UPDATE REJECT indicating PLMN not allowed is sent to the MS.
REQUESTS_LOCUPD: Each time LOCATION UPDATE REQUEST is received.
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Remarks & Comment |
The counters include all transactions of 2G and 3G. INTW_BSS_PLMN_NOT_ALLOWED is temporarily added to the formulas until a critical numbers of subscribers are connected.
|
| Process |
| |
| KPI CRN19 |
Inter MSCA Handover Success Rate (2G & 3G) |
| Target Value |
>97% |
| Frequency |
Weekly |
| Description |
This indicator will give success rate of outgoing Inter MSC Handover attempts due to the mobility of the subscriber between two MSCs which reflects the performance and the coverage of the radio. |
| Formula |
(SUCC_MSC_MSC_HO_MSCA / (HANDOVER_MSC_MSC_OG_ATTEMPTS + SUBSEQ_MSC_MSC_HO_MSCA) ) * 100 |
| Counter Descriptions |
SUCC_MSC_MSC_HO_MSCA: Indicates the number of successful inter-MSC handovers where the home MSC acts as MSC-A. Trigger: each time HANDOVER COMPLETE is received for handover back to MSC-A and each time SEND END SIGNAL is received from MSC-B for handover to MSC-B.
HANDOVER_MSC_MSC_OG_ATTEMPTS: Indicates the number of outgoing requests for inter-MSC handover (home MSC = MSCA). Trigger: each time PERFORM HANDOVER is sent to MSC-B.
SUBSEQ_MSC_MSC_HO_MSCA: Each time PERFORM SUBSEQUENT HANDOVER is received from MSC-B.
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Process |
| |
| KPI CRN20 |
Inter MSCA Handover Success Rate (3G) |
| Target Value |
>97% |
| Frequency |
Weekly |
| Description |
This indicator will give success rate of outgoing Inter MSC Handover attempts due to the mobility of the subscriber between two MSCs which reflects the performance and the coverage of the radio. |
| Formula |
(SUCC_MSC_MSC_HO_MSCA / (HANDOVER_MSC_MSC_OG_ATTEMPTS + SUBSEQ_MSC_MSC_HO_MSCA) ) * 100 |
| Counter Descriptions |
U_SUCC_MSC_MSC_HO_MSCA: Each time HANDOVER COMPLETE is received for handover back to the MSCA, and each time SEND END SIGNAL is received from the MSC-B for handover to the MSC-B, both with radio source indicator set to UMTS.
U_HANDOVER_MSC_MSC_OG_ATTEMPTS: Each time PERFORM HANDOVER is sent to the MSC-B, with radio source indicator set to UMTS.
U_SUBSEQ_MSC_MSC_HO_MSCA: Each time PERFORM SUBSEQUENT HANDOVER is received from the MSCB, with target source indicator set to UMTS.
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Process |
| |
| KPI CRN21 |
Echo Cancellation Mechanism Failure Rate |
| Target Value |
<0.01% |
| Frequency |
Weekly |
| Description |
This method will give the Echo Hardware failure rate in a granularity period. |
| Formula |
(Time OOS / (granularity * 60)) * 100 |
| Counter Descriptions |
Time OOS: Triggered once the hardware device goes down out of service until last transition collected from the NOC Unit, value in minutes.
Granularity: Time of interval period, in minutes.
|
| Object Class |
MSC |
| Tools |
NOC |
| Unit Range |
% |
| Process |
| |
| KPI CRN22 |
Authentication Success Rate |
| Target Value |
>98% |
| Frequency |
Weekly |
| Description |
This KPI indicates the number of successful legal authentication per attempts. |
| Formula |
((AUTH_REQ+AUTH_REQ_WITH_AUTN – AUTH_WITH_ILLEGAL_SUB – AUTH_SYNCHRON_FAIL_RECEIVED) / (AUTH_REQ + AUTH_REQ_WITH_AUTN – AUTH_WITH_ILLEGAL_SUB)) * 100 |
| Counter Descriptions |
AUTH_REQ: Each time AUTHENTICATION REQUEST is sent to the MS.
AUTH_REQ_WITH_AUTN: Each time AUTHENTICATION REQUEST containing AUTN is sent to the UMTS subscriber.
AUTH_WITH_ILLEGAL_SUB: Each time AUTHENTICATION REJECT indicating illegal MS is sent to BSC/MS.
AUTH_SYNCHRON_FAIL_RECEIVED: Each time AUTHENTICATION FAILURE with synchronization failure indication is received from the UMTS subscriber.
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Remarks & Comment |
The counters include all transactions of 2G and 3G. |
| Process |
| |
| KPI CRN23 |
IMSI Attach Success Rate |
| Target Value |
>99% |
| Frequency |
Weekly |
| Description |
This measurement provides the successful rate of location update requests for an IMSI attach. |
| Formula |
(SUCC_LOCUPD_WITH_IMSI_ATTACH / REQUESTS_LOCUPD_WITH_IMSI_ATT) * 100 |
| Counter Descriptions |
SUCC _LOCUPD_WITH_IMSI_ATTACH: Each time LOCATION UPDATE ACCEPT containing “IMSI attach” is sent to the BSS.
REQUESTS_LOCUPD_WITH_IMSI_ATT: Each time LOCATION UPDATE REQUEST containing type “IMSI attach” is received.
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Remarks & Comment |
The counters include all transactions of 2G and 3G. |
| Process |
| |
| KPI CRN24 |
BSC Availability |
| Target Value |
>99.999% |
| Frequency |
Weekly |
| Description |
This method will give the BSC availability in an interval period. |
| Formula |
(1 – (Time OOS / granularity)) * 100 |
| Counter Descriptions |
Time OOS: Triggered once the system goes down until last transition, collected from the NOC Unit, value in minutes.
Granularity: Time of interval period, in minutes.
|
| Object Class |
BSC |
| Unit Range |
% |
| Process |
| |
| KPI CRN25 |
Transceiver Availability |
| Target Value |
>99.98% |
| Frequency |
Weekly |
| Description |
This indicator will give the TRX availability. |
| Formula |
(TRANAVTI[1] / (granularity * 60)) * 100 |
| Counter Descriptions |
TRANAVTI[1]: All time intervals in which a TRX has been available are recorded.
Granularity: Time of interval period, in minutes.
|
| Object Class |
TRX |
| Unit Range |
% |
| Process |
| |
| KPI CRN26 |
Call Setup Success Rate |
| Target Value |
>98% |
| Frequency |
Weekly |
| Description |
This indicator will give the Call Setup Success Rate at the BSS to setup up an end to end connection from the BSS point of view, if the mobile station sends an assignment complete to the BSC and the BSC informs the MSC with an assignment complete message. |
| Formula |
(NSUCCHPC / (ATIMASCA – ImmAssNoSeiz)) * (1 – NRCLRREQ / NSUCCHPC) * (ASSSUCC / TASSATT) |
| Counter Descriptions |
NSUCCHPC[1-6]: Receipt of a valid ESTABLISHMENT INDICATION (BTS --> BSC).
ATIMASCA[1-6]: This measurement is triggered by the receipt of a valid CHANNEL REQUIRED (BTS --> BSC).
ImmAssNoSeiz: The main reasons for this behaviour are Phantom RACHs, messages not foreseen for the observed cell. Other reasons are not received SABM messages due to air interface problems.
NRCLRREQ[19-26]: This measurement is triggered by a clear request message sent from the BSC to MSC with the specified causes.
ASSSUCC = TASSSUCC[2] + SINTHINT[7] + SUINBHDO[7] + SUOISHDO[7]: These indicators will give you the number of successful completed Assignment procedures. Successful completed Assignment procedures are incremented even with successful outgoing directed retry.
TASSSUCC[2]: This measurement is triggered by the transmission of an ASSIGNMENT COMPLETE (BSC --> MSC).
Successful Intra Cell Intra BSC SINTHINT[7]: The measurement is triggered by the receipt of a valid HANDOVER COMPLETE (MS --> BSC) cause DR.
Successful Inter Cell Inter BSC SUINBHDO[7]: This measurement is triggered by the receipt of a valid CLEAR COMMAND (MSC --> BSC) with cause “handover successful” cause direct retry.
SUOISHDO[7]: This measurement is triggered by the receipt of a CLEAR COMMAND message (3G MSC --> BSC) related to an intersystem handover DR.
TASSATT[2]: This measurement is triggered by the receipt of a valid ASSIGNMENT REQUEST (MSC --> BSC).
|
| Object Class |
BTS |
| Unit Range |
% |
| Process |
| |
| KPI CRN27 |
SDCCH Mean Holding Time |
| Target Value |
<0.5Sec |
| Frequency |
Weekly |
| Description |
This indicator will give the mean holding time in seconds for occupied SDCCH in a cell. |
| Formula |
(MBUSYSDC * granularity * 60) / NSUCCHPC |
| Counter Descriptions |
MBUSYSDC[1]: This measurement determines in intervals of 500 ms the number of SDCCHs currently busy. At the end of the granularity period the arithmetic mean value of the samples is calculated. This measurement keeps track of each assignment due to normal SDCCH assignments or due to SDCCH-SDCCH handovers and release of an SDCCH. An internal counter is updated at the point of time the BSC assigns (SDCCH is then busy) or releases an SDCCH (SDCCH is then idle again). This internal counter is polled every 500 ms.
Granularity: Time of interval period, in minutes.
NSUCCHPC[1-6]: Receipt of a valid ESTABLISHMENT INDICATION (BTS --> BSC).
|
| Object Class |
BTS |
| Unit Range |
Seconds |
| Process |
| |
| KPI CRN28 |
Immediate Assignment Success Rate |
| Target Value |
>99% |
| Frequency |
Weekly |
| Description |
These indicators will give the immediate assignment success rate from a mobile station point of view when the BTS sends an establishment indication message to the BSC indicates the mobile station accessed to create a signalling connection with the network. |
| Formula |
(NSUCCHPC / (ATIMASCA – ImmAssNoSeiz)) * 100 |
| Counter Descriptions |
NSUCCHPC[1-8]: Receipt of a valid ESTABLISHMENT INDICATION (BTS --> BSC).
ATIMASCA[1-6]: This measurement is triggered by the receipt of a valid CHANNEL REQUIRED (BTS --> BSC).
ImmAssNoSeiz: The main reasons for this behaviour are Phantom RACHs, messages not foreseen for the observed cell. Other reasons are not received SABM messages due to air interface problems.
|
| Object Class |
BTS |
| Unit Range |
% |
| Process |
| |
| KPI CRN29 |
BSC MPCC, TDPC, PCU Processors load |
| Target Value |
<70% |
| Frequency |
Weekly |
| Description |
These indicators provide the mean processor load at the BSC for the MPCC (Operational and Administrative Processor), TDPC (Telephony Processor) and the processors for the Packet Control Units PCU0. |
| Formula |
BSC MPCC Processor load = BSCPRCLD[2], BSC TDPC Processor load = BSCPRCLD[5], BSC PCU Processor load = BSCPRCLD[8] |
| Counter Descriptions |
BSCPRCLD[2, 5, 8]: Are measured periodically for each processor of the RNC, at the end of the granularity period, the mean values are provided.
|
| Object Class |
BSC |
| Unit Range |
% |
| Remarks & Comment |
In order to have system-internally only integer values and to increase the accuracy, the actual value of the mean value shall be multiplied by 100 for an appropriate display with 2 digits after the decimal point. |
| Process |
| |
| KPI CRN30 |
SDCCH Blocking Rate |
| Target Value |
<0.5% |
| Frequency |
Weekly |
| Description |
This indicator will give the SDCCH Blocking Rate by meaning the time rate all SDCCH were occupied within the granularity period. |
| Formula |
(ASDCALTI[1] / (granularity * 60)) * 100 |
| Counter Descriptions |
ASDCALTI [1]: Detecting the start of a new interval which coincides with the assignment of the last available SDCCH or reduction of available SDCCH to the number of assigned SDCCH (e.g. an SDCCH becomes unavailable or if a TCH/SD timeslot (pooltype = TCH_SD_POOL) is seized as TCH)).
Detecting the end of an interval which coincides with the release of an SDCCH in the situation in which all available SDCCHs are allocated or increase of available SDCCH, when the last available SDCCH has been busy before (e.g. SDCCH becomes available again or if a TCH/SD timeslot with pooltype “TCH_POOL” TCH is released).
Granularity: Time of interval period, in minutes.
|
| Object Class |
BTS |
| Unit Range |
% |
| Process |
| |
| KPI CRN31 |
TCH Blocking Rate |
| Target Value |
<0.5% |
| Frequency |
Weekly |
| Description |
This indicator will give the TCH Blocking Rate by meaning the time rate where all TCH were occupied within the granularity period. |
| Formula |
(AALTCHTI / (granularity * 60s)) * 100 |
| Counter Descriptions |
AALTCHTI[1]: Detecting the start and the end of a new interval which coincides with the assignment of the last available TCH.
Granularity: Time of interval period, in minutes.
|
| Object Class |
BTS |
| Unit Range |
% |
| Process |
| |
| KPI CRN32 |
Traffic Lost |
| Target Value |
1.5% cells of the network within 5% GOS Erlangs |
| Frequency |
Weekly |
| Description |
This indicator will give you the amount of circuit switched traffic (measured in Erlangs), which was lost for a cell due to lack of TCH resources. The indicators may be used for radio network capacity planning taking in consideration the GOS level. |
| Formula |
TCHTrafOffFR – TCHTrafCarrFR = (MEBUSTCH / (1 – (ATCHSMBS/ATTCHSEI))) – MEBUSTCH |
| Counter Descriptions |
MEBUSTCH[1]: This measurement determines in intervals of 500 ms the number of TCHs (TCH and TCH/SD in TCH_Pool resp. TCH/SD in TCH_SD_POOL) currently busy. At the end of the granularity period the arithmetic mean value of the samples is calculated.
ATCHSMBS[1]: The counters are updated at the point of time the BSC detects that an incoming TCH assignment request can not be served because no suitable TCH (TCH, TCH/SD in TCH_Pool ) is free.
Receipt of a valid ASSIGNMENT REQUEST (MSC --> BSC)
Receipt of a valid CHANNEL REQUIRED (BTS --> BSC) (related to the very early TCH assignment)
Receipt of a valid HANDOVER REQUEST (MSC --> BSC) (external / MSC-controlled incoming handovers)
Receipt of a valid INTERCELL HANDOVER CONDITION INDICATION
(BTS --> BSC) BSC controlled intercell handovers)
Receipt of a valid INTRACELL HANDOVER CONDITION INDICATION (BTS --> BSC) BSC controlled intracell handovers)
Receipt of a valid VGCS/VBS ASSIGNMENT REQUEST message (MSC --> BSC)
Congestion of the Abis pool
Receipt of a valid DTM REQUEST (BTS --> BSC)
Receipt of a valid DL UNITDATA (SGSN --> BSC) (mobile CS connected and DTM supported)
Receipt of a valid CREATE BSS PFC (SGSN --> BSC) (mobile CS connected, DTM supported, and real time PFC)
Receipt of a valid PACKET CS COMMAND (BTS --> BSC) (mobile engaged in PS session and enhanced DTM supported)
Receipt of a valid PAGING (CS) (MSC/SGSN --> BSC) (mobile engaged in PS session and enhanced DTM supported)
All the reconfiguration of PS part that require a reallocation of the CS part of a DTM configuration.
ATTCHSEI[1]: This measurement is triggered by all kinds of procedures used to request a TCH:
Receipt of a valid ASSIGNMENT REQUEST (MSC --> BSC)
Receipt of a valid CHANNEL REQUIRED (BTS --> BSC) (related to the very early TCH assignment)
Receipt of a valid HANDOVER REQUEST (MSC --> BSC) (external / MSC-controlled incoming handovers)
Receipt of a valid INTERCELL HANDOVER CONDITION INDICATION (BTS --> BSC) BSC controlled intercell handovers)
Receipt of a valid INTRACELL HANDOVER CONDITION INDICATION (BTS --> BSC) BSC controlled intracell handovers)
Receipt of a valid VGCS/VBS ASSIGNMENT REQUEST message (MSC --> BSC)
Receipt of a valid DTM REQUEST (BTS --> BSC) (mobile CS connected, DTM supported, and the PS requirements require a CS reallocation)
Receipt of a valid DL UNITDATA (SGSN --> BSC) (mobile CS connected, DTM supported, and the PS requirements require a CS reallocation)
Receipt of a valid CREATE BSS PFC (SGSN --> BSC) (mobile CS connected, DTM supported, and real time PFC and the PS requirements require a CS reallocation)
Receipt of a valid (EGPRS) PACKET DOWNLINK ACK/NACK (mobile in DTM and the PS requirements require a CS reallocation).
|
| Object Class |
BTS |
| Unit Range |
Erlangs |
| Process |
| |
| KPI CRN33 |
TCH Drop Rate |
| Target Value |
<2% |
| Frequency |
Weekly |
| Description |
This indicator will give you the rate of all drops of TCH connections, drops comprise all BSC caused terminations of TCH connection. |
| Formula |
(NRCLRREQ / SUCTCHSE) * 100 |
| Counter Descriptions |
NRCLRREQ[1-3,5-12,14-18]: This measurement is triggered by a clear request message sent from the BSC to MSC with the specified causes.
SUCTCHSE[1]: Triggered by the following:
Transmission of an ASSIGNMENT COMPLETE (BSC --> MSC)
Transmission of a HANDOVER PERFORMED (BSC --> MSC)
Transmission of a HANDOVER COMPLETE (BSC --> MSC) by meaning (external / MSC controlled incoming handovers).
Receipt of a valid ESTABLISHMENT INDICATION message (BTS --> BSC) (related to a very early TCH assignment) of a VGCS/VBS ASSIGNMENT RESULT message (BSC --> MSC)
Transmission of a VGCS/VBS ASSIGNMENT RESULT message (BSC --> MSC).
|
| Object Class |
BTS |
| Unit Range |
% |
| Process |
| |
| KPI CRN34 |
Inter BSC Handover Success Rate |
| Target Value |
>97% |
| Frequency |
Weekly |
| Description |
These indicators will give rate of successful Inter-BSC handovers of cells controlled by a different BSC, successful when the mobile station sends handover complete message to the BSC, the BSC forwards the message to the MSC. |
| Formula |
(SUINBHDO / ATINBHDO) * 100 |
| Counter Descriptions |
SUINBHDO[all]: This measurement is triggered by the receipt of a valid CLEAR COMMAND (MSC --> BSC) with cause “handover successful”.
ATINBHDO[all]: This measurement is triggered by the receipt of a HANDOVER COMMAND (MSC --> BSC) containing the BCCH frequency and BSIC of an external neighbour cell.
|
| Object Class |
BTS |
| Unit Range |
% |
| Process |
| |
| KPI CRN35 |
Mean RXQUAL DL/UL |
| Target Value |
>85% |
| Frequency |
Weekly |
| Description |
These indicators will give you the mean RXQUAL on busy TCH. Two indicators distinguish between uplink and downlink. |
| Formula |
Mean RXQUAL UL = ?(i * PWRUPDW[64+i] / PWRUPDW[65…72]), Mean RXLEV DL= ?(i * PWRUPDW[136+i] / PWRUPDW[137…144]), Where i = 1…8 |
| Counter Descriptions |
PWRUPDW[65-72, 137-144]: The BTSE updates the counters according to the information retrieved from:
The MEASUREMENT REPORTS (MS --> BTS) (downlink measurements).
BTS internal measurements (uplink measurements).
|
| Object Class |
TRX |
| Unit Range |
% |
| Process |
| |
| KPI CRN36 |
Adaptive Multirate Average Frame Erasure Rate DL/UL |
| Target Value |
<1% |
| Frequency |
Weekly |
| Description |
These indicators provide the Adaptive Multirate True Frame Erasure Rate FER as well for each channel type for the uplink separately. |
| Formula |
Adaptive Multirate Average Frame Erasure Rate DL = 100 * (num_of_erroneous_speech_frames / (num_of_erroneous_speech_frames + num_of_correct_speech_frames)) = 100 * AMRFRMDL[2] / AMRFRMDL[1,2]
Adaptive Multirate Average Frame Erasure Rate UL = AMRCHDIS[n ] * AMRFRMUL[14-26] / (AMRFRMUL[14-26] + AMRFRMUL[1-13]) |
| Counter Descriptions |
AMRCHDIS[1-13]: Receipt of AMR speech frames on the air interface. Transmission of AMR speech frames on the air interface.
AMRFRMDL[1,2]: This measurement is triggered as follows:
The number of sent speech frames is incremented every sent speech frame.
The num_of_correct_speech_frames is updated every measurement period (480ms) when an ENHANCED MEASUREMENT REPORT is received, by accumulating the value reported by the parameter NBR_RCVD_BLOCKS.
AMRFRMUL[all]: This measurement is triggered by the receipt of speech frames in the following types.
The num_of_correct_speech_frames is incremented after every correctly received speech frame.
The num_of_erroneous_speech_frames is incremented after every erroneous received speech frame, missing speech frames increment this counting, too.
|
| Object Class |
BTS |
| Unit Range |
% |
| Remarks & Comment |
For AMR the half rate is activated. |
| Process |
| |
| KPI CRN37 |
RNC Availability |
| Target Value |
>99.999% |
| Frequency |
Weekly |
| Description |
This method will give the BSC availability in a granularity period |
| Formula |
(Time OOS /granularity)) * 100 |
| Counter Descriptions |
Time OOS: Triggered once the system goes down until last transition, collected from the NOC Unit.
Granularity: Time of interval measurement period, Granularity in minutes.
|
| Object Class |
RNC |
| Tools |
NOC |
| Unit Range |
% |
| Process |
| |
| KPI CRN38 |
Transceiver Availability |
| Target Value |
>99.98% |
| Frequency |
Weekly |
| Description |
N/A |
| Formula |
The NOC should log the times of CHC Cards being OOS |
| Counter Descriptions |
No counters are created in the RNC scanner database.
|
| Object Class |
Node B |
| Tools |
NOC |
| Unit Range |
% |
| Process |
| |
| KPI CRN39 |
Call Setup Success Rate |
| Target Value |
>98% |
| Frequency |
Weekly |
| Description |
This indicator will give the Call Setup Success Rate at the RNC to setup up an end to end connection. |
| Formula |
((rrcEstabSucc / rrcEstabAtt) * (rabEstabTypeSucc / rabEstabTypeAtt)) * 100 |
| Counter Descriptions |
rrcEstabSucc[1-10,15,17,18,20]: Receipt of an RRC CONNECTION SETUP COMPLETE message sent by the UE to the UTRAN.
rrcEstabAtt[1-10,15,17,18,20]: Receipt of an RRC CONNECTION REQUEST message sent by the UE to the UTRAN.
rabEstabTypeSucc[all]: Transmission of a RANAP-message RAB ASSIGNMENT RESPONSE sent by the UTRAN to the CN, with a “RAB to be set up” or when an active link set already exists.
rabEstabTypeAtt[all]: Receipt of a RANAP-message RAB ASSIGNMENT REQUEST sent by the CN to the UTRAN, with a “RAB to be set up” or when an active link set already exists.
When RANAP RAB ASSIGNMENT REQUEST (SETUP) is received.
|
| Object Class |
UCELL |
| Unit Range |
% |
| Process |
| |
| KPI CRN40 |
DCH Mean Holding Time |
| Target Value |
<0.5Sec |
| Frequency |
Weekly |
| Description |
This indicator will give you the mean holding Time in seconds for occupied DCH in the dedicated transport channel in a cell as UE is in a Cell_DCH state (more efficient in driving test). |
| Formula |
(bearServiceperCell * granularity * 60) / RabEstabTypeSucc |
| Counter Descriptions |
bearServiceperCell [3-36]: When a bearer service is set up, which means the RANAP message RAB ASSIGNMENT RESPONSE was sent toward CN. Update of the counter shall be related to the assigned bearer service, not to the required service.
When a bearer service was released triggered by the RANAP: RAB ASSIGNMENT REQUEST messages indicating RABs to be released was received from CN or when RANAP: RAB RELEASE REQUEST message was sent toward CN. Remark, that all cells of the active link set have to be considered. The same applies if the RAB is released per RANAP: IU RELEASE COMMAND/REQUEST message.
In case of Branch addition the bearer service shall be considered within the added cell.
In case of successful hard handover the corresponding counter shall be decremented within the originating cell(s) and incremented within the target cell(s). Of course only the counter in the originating cell or the target cell is considered in case of outgoing respectively incoming inter-system handovers.
In case of channel type switching an existing bearer type is decremented and the counter corresponding to the new bearer type is incremented.
In case of Bit Rate Adaptations.
Granularity: Time of interval measurement period, Granularity in minutes.
rabEstabTypeSucc[all]: Transmission of a RANAP-message RAB ASSIGNMENT RESPONSE sent by the UTRAN to the CN, with a “RAB to be set up” or when an active link set already exists.
|
| Object Class |
UCELL |
| Unit Range |
Seconds |
| Process |
| |
| KPI CRN41 |
RRC Connection Establishment Success Rate |
| Target Value |
>99% |
| Frequency |
Weekly |
| Description |
This KPI describes the ratio of successful RRC connection establishments of UE in CELL_DCH connected mode related to the total number of RRC connection establishment attempts. |
| Formula |
(rrcEstabSucc / rrcEstabAtt) * 100 |
| Counter Descriptions |
rrcEstabSucc[all]: Receipt of an RRC CONNECTION SETUP COMPLETE message sent by the UE to the UTRAN.
rrcEstabAtt[all]: Receipt of an RRC CONNECTION REQUEST message sent by the UE to the UTRAN.
|
| Object Class |
UCELL |
| Unit Range |
% |
| Process |
| |
| KPI CRN42 |
RNC Processor Load |
| Target Value |
<70% |
| Frequency |
Weekly |
| Description |
This measurement provides the mean load of the RNC processor during the complete granularity period for Operation and Administration (AP). |
| Formula |
rncUsageRatio[0] |
| Counter Descriptions |
rncUsageRatio[0]: AP usage ratio is measured periodically every 10 seconds for each processor of the RNC, at the end of the granularity period, the mean values are provided.
|
| Object Class |
RNC |
| Unit Range |
% |
| Process |
| |
| KPI CRN43 |
DCH Loss Rate |
| Target Value |
<0.5% |
| Frequency |
Weekly |
| Description |
This KPI describes the ratio of loss rate of unsuccessful RRC connection establishments due to no radio resources available (congestion). |
| Formula |
(rrcEstabFail / rrcEstabAtt) * 100 |
| Counter Descriptions |
rrcEstabFail[1]: The counter counts the number of RRC establishment attempts which have not evolved into an RRC establishment, establishment failure causes are the rejection causes of RRC CONNECTION REJECT When RRC CONNECTION REJECT is sent from the RNC to the UE.
rrcEstabAtt[all]: Receipt of an RRC CONNECTION REQUEST message sent by the UE to the UTRAN.
|
| Object Class |
UCELL |
| Unit Range |
% |
| Remarks & Comment |
There is no counter in time but this is an equivalent as a loss rate. |
| Process |
| |
| KPI CRN44 |
DHT & PRLC Blocking Rates |
| Target Value |
<0.5% |
| Frequency |
Weekly |
| Description |
This indicator provides the rate of time all DHTs and PRLC for CS and PS are busy (allocated) related to the measurement period. |
| Formula |
DHT Blocking Rate = (dhtBusyTime / (granularity * 60)) * 100, PRLC Blocking Rate = (prlcBusyTime / (granularity * 60)) * 100 |
| Counter Descriptions |
dhtBusyTime: The usage of DHTs and is measured every 10 seconds. Every time the amount of available resources is smaller than the resource that would be required for a further maximum-size bearer, the counter is increased by the length of the interval. When the number of used DHTs is equal to the number of existing DHTs, the 10 seconds are counted as DHT busy time.
prlcBusyTime: Same trigger to DHT measurement method.
Granularity: Time of interval period, in minutes.
|
| Object Class |
RNC |
| Unit Range |
% |
| Remarks & Comment |
DHT Card for User Plane CS resources and PRLC card for User Plane PS resources. |
| Process |
| |
| KPI CRN45 |
Traffic Lost |
| Target Value |
<5% GOS of Erlangs |
| Frequency |
Weekly |
| Description |
This indicator will give you the amount of lost traffic load, which was lost for a cell due to different rejection causes, a separate subcounter is defined. |
| Formula |
TCHTrafOffFR – TCHTrafCarrFR = (bearServiceperCell / 1 – rabEstabTypeFail / rabEstabTypeAtt) – bearServiceperCell |
| Counter Descriptions |
bearServiceperCell [3-36]: When a bearer service is set up, which means the RANAP message RAB ASSIGNMENT RESPONSE was sent toward CN. Update of the counter shall be related to the assigned bearer service, not to the required service.
When a bearer service was released triggered by the RANAP: RAB ASSIGNMENT REQUEST messages indicating RABs to be released was received from CN or when RANAP: RAB RELEASE REQUEST message was sent toward CN. Remark, that all cells of the active link set have to be considered. The same applies if the RAB is released per RANAP: IU RELEASE COMMAND/REQUEST message. In case of Branch addition the bearer service shall be considered within the added cell.
In case of successful hard handover the corresponding counter shall be decremented within the originating cell(s) and incremented within the target cell(s). Of course only the counter in the originating cell or the target cell is considered in case of outgoing respectively incoming inter-system handovers.
In case of channel type switching an existing bearer type is decremented and the counter corresponding to the new bearer type is incremented.
In case of Bit Rate Adaptations.
rabEstabTypeFail [23,48]: Transmission of a RANAP: RAB ASSIGNMENT RESPONSE message sent by the UTRAN to the CN, with “RAB failed to set up.” For the RAB, which could not be established, the relevant counter is increased according to the failure cause. In case the RANAP: RAB ASSIGNMENT RESPONSE message is transmitted when an active link set already exists, the newest cell approach shall apply.
rabEstabTypeAtt[all]: Receipt of a RANAP-message RAB ASSIGNMENT REQUEST sent by the CN to the UTRAN, with a “RAB to be set up” or when an active link set already exists.
When RANAP RAB ASSIGNMENT REQUEST (SETUP) is Received.
|
| Object Class |
UCELL |
| Unit Range |
Erlangs |
| Process |
| |
| KPI CRN46 |
Soft Handover Success Rate |
| Target Value |
>97% |
| Frequency |
Monthly |
| Description |
This KPI describes the ratio of successful branch additions of Intracell, Intercell Intra RNC and Intercell Inter RNC Handovers related to the total number of branch addition attempts, with additions of soft handover interruptions those consider all branch additions which have not successfully been completed due to reasons not related to the soft handover procedure. |
| Formula |
((shoAddIntraNodeBSucc + shoAddIntraRncSucc + shoAddInterRncSucc + shoAddIntraNodeBFail + shoAddIntraRncFail + shoAddInterRncFail) / (shoAddIntraNodeBAtt + shoAddIntraRncAtt + shoAddInterRncAtt)) * 100 |
| Counter Descriptions |
shoAddIntraNodeBSucc[all]: Receipt of an RRC-message ACTIVE SET UPDATE COMPLETE sent from the UE to the UTRAN, indicating the success of an intra Node B branch addition procedure.
ShoAddIntraNodeBFail[11,18,31]: This counter is incremented when RRC ACTIVE SET UPDATE FAILURE message is received in case of Branch Addition at handover.
shoAddIntraNodeBAtt[all]: This counter provides the number of attempted intra Node B radio link additions for each cell. Decision in the RNC to add a new diversity branch (intra Node B) for a UE for handover reasons. The appropriate counter is increased for the cell, which shall be added to the active link set.
shoAddIntraRncSucc[all]: Receipt of an RRC-message ACTIVE SET UPDATE COMPLETE sent from the UE to the UTRAN, indicating the success of an intra RNC branch addition procedure.
shoAddIntraRncFail[11,18,31]: This counter is incremented when RRC ACTIVE SET UPDATE FAILURE message is received in case of Branch Addition at handover.
shoAddIntraRncAtt[all]: This counter provides the number of attempted intra RNC radio link additions for each cell. Decision in the RNC to add a new diversity branch (intra RNC) for a UE for handover reasons. The appropriate counter is increased for the cell, which shall be added to the active link set.
shoAddInterRncSucc[all]: Receipt of an RRC-message ACTIVE SET UPDATE COMPLETE sent from the UE to the UTRAN, indicating the success of an inter RNC branch addition procedure.
shoAddInterRncFail[11,18,31]: This counter is incremented when RRC ACTIVE SET UPDATE FAILURE message is received in case of Branch Addition at handover.
shoAddInterRncAtt[all]: This counter provides the number of attempted inter RNC radio link additions for each cell. Decision in the RNC to add a new diversity branch (inter RNC) for a UE for handover reasons. The appropriate counter is increased for the cell, which shall be added to the active link set.
|
| Object Class |
UCELL |
| Unit Range |
% |
| Process |
| |
| KPI CRN47 |
Dropped Call Rate |
| Target Value |
<2% |
| Frequency |
Weekly |
| Description |
This KPI describes the ratio of abnormal RAB releases related to the total number of successful RAB establishments, the call drop rate does consider call drops occurring in a RNC area since the call establishment has been counted, but the Call Drop Rate does not consider outgoing or incoming handovers. Note that the UE is still reachable via a RRC connection but it lost the assigned service. |
| Formula |
?rabrelUtranOrigin
Drop call rate = Cell_________________________ * 100
? rabEstabTypeSucc
Cell |
| Counter Descriptions |
rabrelUtranOrigin[2-7,10,12-14,16-17,19-21,24,26-28]: This counter provides the number of abnormal UTRAN initiated RAB releases for each cell which is based on transmission of a RANAP message RAB RELEASE REQUEST or IU RELEASE REQUEST sent by the UTRAN to the CN involving release of RABs.
rabEstabTypeSucc[all]: This counter provides the number of successful RAB establishments for each cell. Triggered by transmission of a RANAP-message RAB ASSIGNMENT RESPONSE sent by the UTRAN to the CN, with a “RAB to be setup” or when an active link set already exists.
|
| Object Class |
RNC |
| Unit Range |
% |
| Remarks & Comment |
As RAB Release may be counted in a different cell as the RAB establishment due to handover procedures, the determination of the Call Drop Rate is per RNC related not per cell related. It does not make sense to use it for a single cell because this can lead to results greater than 100%. |
| Process |
| |
| KPI CRN48 |
LU Connection Drop Rate |
| Target Value |
<2% |
| Frequency |
Weekly |
| Description |
This KPI describes the ratio of abnormal UTRAN initiated Iu connection releases related to the total number of CN initiated connection releases. The IU RELEASE REQUEST message is used in case the UE is lost at the air interface. |
| Formula |
(iuRelReq / iuRelCmd) * 100 |
| Counter Descriptions |
iuRelReq[2-6,9-11,13-14,16-17,20-22]: This counter provides the number of abnormal UTRAN-initiated IU connection releases for each cell. Triggered by transmission of a RANAP-message IU RELEASE REQUEST sent by the UTRAN to the CN.
iuRelCmd[all]: This counter provides the number of CN-initiated Iu connection releases for each cell by receipt of a RANAP-message IU RELEASE COMMAND sent by the CN to the UTRAN.
|
| Object Class |
UCELL |
| Unit Range |
% |
| Process |
| |
| KPI CRN49 |
Inter RNC Hard Handover Success Rate |
| Target Value |
>97% |
| Frequency |
Weekly |
| Description |
These indicators will give rate of successful Inter RNC Handovers of cells controlled by a different BSC, successful when the mobile station sends handover complete message to the BSC, the RNC forwards the message to the CN. |
| Formula |
((hhoAllOutSucc3 + hhoAllOutFail3) / hhoAllOutAtt3) * 100 |
| Counter Descriptions |
hhoAllOutSucc3[1]: This counter provides the number of successful Inter RNC outgoing hard handovers with separately of hard handover type for each cell. Triggered by Receipt of an RRC message PHYSICAL CHANNEL RECONFIGURATION COMPLETE sent from the UE to the UTRAN, indicating the successful inter-frequency handover.
hhoAllOutFail3[4,5,9]: Handovers which have not successfully been completed due to reasons not related to the hard handover procedure by receiving NBAP RL FAILURE INDICATION message or by RRC with cause CELL UPDATE and RNSAP UPLINK SIGNALING TRANSFER message.
hhoAllOutAtt3[1]: This counter provides the number of attempted Inter RNC outgoing hard handovers for each cell. Triggered by transmission of an RRC message PHYSICAL CHANNEL RECONFIGURATION sent from the UTRAN to the UE, indicating the attempt of inter-frequency handover.
|
| Object Class |
UCELL |
| Unit Range |
% |
| Process |
| |
| KPI CRN50 |
Mean RXQUAL DL/UL |
| Target Value |
>85% |
| Description |
There is no counter for RXQUAL in 3G. |
| Unit Range |
% |
| Process |
| |
| KPI CRN51 |
HEC Error Ratio |
| Target Value |
<5% |
| Frequency |
Weekly |
| Description |
This measurement provides the ratio of lost ATM cells received from RNC because of HEC (Header Error Control) error or BER in the header of ATM Cells. |
| Formula |
((E1 + E2 +...+ En) / (T1 + T2 +...+ Tn)) * 100 |
| Counter Descriptions |
hecErrorRatio: The scanner obtains the total number of receiving cells (Tn) and the number of HEC error cells (En) for a specific measurement period from “physLine” per 10 seconds and accumulates the obtained values after the GP the result is obtained.
|
| Object Class |
Node B Line OC |
| Unit Range |
% |
| Remarks & Comment |
This measurement is in the lub interface and not uu interface, to see the loss of ATM Cells which couldn’t protect the header of the ATM Cells from the BER. This measurement is for Node B PF1 only. |
| Process |
| |
| KPI CRN52 |
SGSN Availability 2G & 3G |
| Target Value |
>99.99% |
| Frequency |
Weekly |
| Description |
This method will give the SGSN availability in a Granularity period |
| Formula |
(1 – (Time OOS / granularity)) * 100 |
| Counter Descriptions |
Time OOS: Triggered once the system goes down until last transition collected from the NOC. Unit value in minutes.
Granularity: Time of interval period, in minutes.
|
| Object Class |
SGSN |
| Unit Range |
% |
| Process |
| |
| KPI CRN53 |
2G Packet Switch Attach Success Rate |
| Target Value |
>98% |
| Frequency |
Weekly |
| Description |
This indicator provides the success rate of successful attach procedure that has been done by the mobile to register for GPRS services related to total number of attempts. |
| Formula |
(succGprsAttach / attGprsAttach) * 100 |
| Counter Descriptions |
succGprsAttach: Each time an appropriate ATTACH ACCEPT is sent to an MS, indicating a GPRS only attach.
attGprsAttach: Each time an ATTACH REQUEST is received from an MS, indicating a GPRS attach.
|
| Object Class |
ROUTING AREA |
| Unit Range |
% |
| Remarks & Comment |
2G SGSN Counters are same as 3G but in measurement we can differentiate between them in header of each counter i.e. For 2G RA2GMMAF: succGprsAttach and for 3G as RA3GMMAF: succGprsAttach. These counters are dealt in same method for 2G & 3G SGSN for all the measurements types. |
| Process |
| |
| KPI CRN54 |
3G Packet Switch Attach Success Rate |
| Target Value |
>98% |
| Frequency |
Weekly |
| Description |
This indicator provides the success rate of successful attach procedure that has been done by the Mobile to register for GPRS services initiated within this SGSN RA related to total number of attempts. |
| Formula |
(succGprsAttach / attGprsAttach) * 100 |
| Counter Descriptions |
succGprsAttach: Each time an appropriate ATTACH ACCEPT is sent to an MS, indicating a GPRS only attach.
attGprsAttach: Each time an ATTACH REQUEST is received from an MS, indicating a GPRS attach.
|
| Object Class |
ROUTING AREA |
| Unit Range |
% |
| Remarks & Comment |
3G SGSN Counters are same as 2G but in measurement we can differentiate between them in header of each counter i.e. For 3G RA3GMMAF: succGprsAttach and for 2G as RA2GMMAF: succGprsAttach. These counters are dealt in same method for 2G & 3G SGSN for all the measurements types. |
| Process |
| |
| KPI CRN55 |
2G Packet Data Protocol Activation Success Rate |
| Target Value |
>98% |
| Frequency |
Weekly |
| Description |
This indicator provides the success rate per total number of attempts of PDP context to activate and establish logical connection between a mobile and the network for GPRS applications, with case of repetitions that some mobiles repeat the identical requests in very short intervals then each request will be counted as single attempt. |
| Formula |
((succActPdpContextHighPriority + succActPdpContextLowPriority + succActSecondPdpContext) / (attActPdpContext + attActSecondPdpContext)) * 100 |
| Counter Descriptions |
succActPdpContextHighPriority:
Each time an ACTIVATE PDP CONTEXT ACCEPT with internal high priority is sent to the MS.
SuccActPdpContextLowPriority: Each time an ACTIVATE PDP CONTEXT ACCEPT with internal low priority is sent to the MS.
succActSecondPdpContext: Each time an ACTIVATE SECONDARY PDP CONTEXT ACCEPT is transmitted to the MS.
AttActPdpContext: Each time the SGSN receives an ACTIVATE PDP CONTEXT ACCEPT or ACTIVATE PDP CONTEXT REJECT from an MS.
attActSecondPdpContext: Each time an ACTIVATE SECONDARY PDP CONTEXT REQUEST is received from the MS.
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Remarks & Comment |
2G SGSN Counters are same as 3G but in measurement we can differentiate between them in header of each counter i.e 2G as SGSN2GSM: succActPdpContextLowPriority and 3G as SGSN3GSM: succActPdpContextLowPriority. |
| Process |
| |
| KPI CRN56 |
3G Packet Data Protocol Activation Success Rate |
| Target Value |
>98% |
| Frequency |
Weekly |
| Description |
This indicator provides the success rate per total number of attempts of PDP context to activate and establish logical connection between a mobile and the network for GPRS applications, with case of repetitions that some mobiles repeat the identical requests in very short intervals then each request will be counted as single attempt. |
| Formula |
((succActPdpContextHighPriority + succActPdpContextLowPriority + succActSecondPdpContext) / (attActPdpContext + attActSecondPdpContext)) * 100 |
| Counter Descriptions |
succActPdpContextHighPriority:
Each time an ACTIVATE PDP CONTEXT ACCEPT with internal high priority is sent to the MS.
SuccActPdpContextLowPriority: Each time an ACTIVATE PDP CONTEXT ACCEPT with internal low priority is sent to the MS.
succActSecondPdpContext: Each time an ACTIVATE SECONDARY PDP CONTEXT ACCEPT is transmitted to the MS.
AttActPdpContext: Each time the SGSN receives an ACTIVATE PDP CONTEXT ACCEPT or ACTIVATE PDP CONTEXT REJECT from an MS.
attActSecondPdpContext: Each time an ACTIVATE SECONDARY PDP CONTEXT REQUEST is received from the MS.
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Remarks & Comment |
3G SGSN Counters are same as 2G but in measurement we can differentiate between them in header of each counter i.e 3G as SGSN3GSM: succActPdpContextLowPriority and 2G as SGSN2GSM: succActPdpContextLowPriority. |
| Process |
| |
| KPI CRN57 |
RAB Establishment Failure Rate for CS Conversation |
| Target Value |
<2.5% |
| Frequency |
Weekly |
| Description |
This KPI describes the ratio of unsuccessful RAB establishments for CS Conversation related to the total number of Conversation CS RAB establishment attempts. |
| Formula |
(1- (rabEstabTypeSucc / rabEstabTypeAtt)) * 100 |
| Counter Descriptions |
rabEstabTypeSucc[3-5]: Transmission of a RANAP RAB ASSIGNMENT RESPONSE message sent by the UTRAN to the CN, with a “RAB to be set up.” For the successfully established RAB, the relevant counter is increased. In case the RANAP: RAB ASSIGNMENT RESPONSE message is transmitted when an active link set already exists, the newest cell approach shall apply.
RabEstabTypeAtt[3-5]: Receipt of a RANAP-message RAB ASSIGNMENT REQUEST sent by the CN to the UTRAN, with a “RAB to be set up” and as well where already an active link set exists.
|
| Object Class |
UCELL |
| Unit Range |
% |
| Process |
| |
| KPI CRN58 |
RAB Drop Rate For CS |
| Target Value |
<1.3% |
| Frequency |
Weekly |
| Description |
This KPI describes the ratio of abnormal UTRAN initiated RAB releases for CS related to the total number of CN initiated RAB releases of CS. |
| Formula |
(rabrelUtranOrigin / rabRelCNOrigin) * 100 |
| Counter Descriptions |
rabrelUtranOrigin[2-7,10,12-14]: Triggered on the following different types:
Transmission of a RANAP message RAB RELEASE REQUEST sent by the UTRAN to the CN, with “RABs to be released”.
Transmission of a RANAP message IU RELEASE REQUEST sent by the UTRAN to the CN involving release of RABs.
RabRelCNOrigin[1-14]: The measurement is based on two different events.
Receipt of a RANAP message RAB ASSIGNMENT REQUEST sent by the CN to the UTRAN, with “RABs to release”.
Receipt of a RANAP message IU RELEASE COMMAND sent by the CN to the UTRAN involving release of RABs.
|
| Object Class |
UCELL |
| Unit Range |
% |
| Process |
| |
| KPI CRN59 |
RAB Establishment Failure Rate For PS Background |
| Target Value |
<2.3% |
| Frequency |
Weekly |
| Description |
This KPI describes the ratio of unsuccessful RAB establishments of PS background related to the total number of RAB establishment attempts per PS background. |
| Formula |
(1 – (rabEstabTypeSucc / rabEstabTypeAtt)) * 100 |
| Counter Descriptions |
rabEstabTypeSucc[16-22]: Transmission of a RANAP RAB ASSIGNMENT RESPONSE message sent by the UTRAN to the CN, with a “RAB to be set up.” For the successfully established RAB, the relevant counter is increased. In case the RANAP: RAB ASSIGNMENT RESPONSE message is transmitted when an active link set already exists, the newest cell approach shall apply.
RabEstabTypeAtt[16-22]: Receipt of a RANAP-message RAB ASSIGNMENT REQUEST sent by the CN to the UTRAN, with a “RAB to be set up” and where already an active link set exist.
|
| Object Class |
UCELL |
| Unit Range |
% |
| Process |
| |
| KPI CRN60 |
RAB Drop Rate For PS |
| Target Value |
<10% |
| Frequency |
Weekly |
| Description |
This KPI describes the ratio of abnormal UTRAN initiated RAB releases for PS related to the total number of CN initiated RAB releases of PSs. |
| Formula |
(rabrelUtranOrigin / rab RelCNOrigin) * 100 |
| Counter Descriptions |
rabrelUtranOrigin[16-17,19-21,24,26-28]: Triggered on the following different types:
Transmission of a RANAP message RAB RELEASE REQUEST sent by the UTRAN to the CN, with “RABs to be released”.
Transmission of a RANAP message IU RELEASE REQUEST sent by the UTRAN to the CN involving release of RABs.
RabRelCNOrigin[15-28]: The measurement is based on two different events.
Receipt of a RANAP message RAB ASSIGNMENT REQUEST sent by the CN to the UTRAN, with “RABs to release”.
Receipt of a RANAP message IU RELEASE COMMAND sent by the CN to the UTRAN involving release of RABs.
|
| Object Class |
UCELL |
| Unit Range |
% |
| Process |
| |
| KPI CRN61 |
Data Session Setup Success Rate |
| Target Value |
>98% |
| Frequency |
Weekly |
| Description |
This indicator provides the success rate of how many sessions are currently active in real time (RT) and non-real time (NRT) related to the total number of establishment including the rejected sessions. |
| Formula |
(tspcSuccessfulSessions / (tspcSuccessfulSessions + tspcRefusedSessions)) * 100 |
| Counter Descriptions |
tspcSuccessfulSessions: Each time a session is established successfully.
TspcRefusedSessions: Each time a session is refused.
|
| Object Class |
CARDOC |
| Unit Range |
% |
| Process |
| |
| KPI CRN62 |
PDCH Loss Rate |
| Target Value |
<0.5% |
| Frequency |
Weekly |
| Description |
This indicator provides the TBF establishment failure rate per cause considering uplink and downlink directions due to no radio resources available related to total number of TBF attempts. |
| Formula |
(REJPDASS/NUACATCL) * 100 |
| Counter Descriptions |
REJPDASS[1-4]: [1] is triggered due to no radio resource available for an uplink TBF:
[2] IMMEDIATE ASSIGNMENT REJECT: As response to a “Channel Request” for an uplink TBF via CCCH.
PACKET ACCESS REJECT (PAR) as response to a “Packet Channel Request” for an uplink TBF via PCCCH.
As response to a (E)PDAN including channel request description sent on PACCH.
As response to a PACKET RESOURCE REQUEST (PRR) sent on PACCH.
DTM REJECT as response to a DTM REQUEST for an uplink TBF via main-DCCH.
[3, 4] for an uplink TBF: Any other causes not to assign uplink radio resources, e.g. internal events (too many requests in parallel, requests for non existing BVCI, etc.). The DTM REJECT, caused by other causes then uplink radio resources (as DTM allocation procedure already running or insufficient information for DTM), are not counted (as they are sent autonomously by TDPC). No radio resource available for a downlink TBF:
STATUS message (STAT) with cause “cell traffic congestion” sent on Gb.
LLC DISCARDED message (LLCD) sent after the reception of a downlink.
UNITDATA for a mobile already involved in an uplink TBF.
Others for a downlink TBF:
Any other causes not to assign downlink radio resources, e.g. internal events (too many requests in parallel; requests for non existing BVCI, etc).
NUACATCL[1,2]: This measurement is based on UL/DL.
Uplink:
Reception of a valid PACKET CHANNEL REQUEST on PRACH.
Reception of a valid CHANNEL REQUIRED for GPRS on RACH.
Reception of a PACKET DOWNLINK ACK/NACK with a channel request description included.
Reception of a valid DTM REQUEST on main-DCCH: The DTM REQUEST rejected or discarded for other causes than uplink radio resources (as DTM allocation procedure already running or insufficient information for DTM), is not counted (as they are sent autonomously by TDPC).
Downlink:
Reception of a LLC DL-UNITDATA PDU referring to a TLLI (current and old if the second is present) not involved in any downlink TBF.
|
| Object Class |
BTS |
| Unit Range |
% |
| Process |
| |
| KPI CRN63 |
Reselection Success Rate From 3G To 2G |
| Target Value |
>95% |
| Description |
This indicator provides the success rate reselection transition of Cell Change Order from 3G to 2G during data transfer. |
| Formula |
((hhoAllOutSucc4 + hhoAllOutFail4) / hhoAllOutAtt4) * 100 |
| Counter Descriptions |
hhoAllOutSucc4[2]: Receipt of a RANAP: IU RELEASE COMMAND message (for DCH:PS Single calls), sent by the PS CN to the serving RNC, indicating a successful outgoing UTRAN controlled PS inter RAT handover.
hhoAllOutFail4[6,7]: Receipt of the RRC: CELL CHANGE ORDER FROM UTRAN FAILURE message sent from the UE to the serving RNC, indicating an unsuccessful PS inter RAT handover (DCH: PS single).
hhoAllOutAtt4[2]: Transmission of an RRC HANDOVER FROM UTRAN COMMAND message sent from the UTRAN to the UE, indicating the attempt of CS inter-system handover. This trigger condition includes counting of CS single calls and CS/PS multi calls.
|
| Object Class |
UCELL |
| Unit Range |
% |
| Remarks & Comment |
Transmission of an RRC CELL CHANGE ORDER FROM UTRAN message sent from the serving RNC to the UE, indicating an attempted outgoing PS inter RAT handover (UTRAN controlled). |
| Process |
| |
| KPI CRN64 |
2G Routing Area Update Success Rate |
| Target Value |
>95% |
| Frequency |
Weekly |
| Description |
This measurement indicates the success rate of a total RA Update in associating successful performing intra SGSN ROUTING AREA update performed within the serving SGSN and inter SGSN due to MS mobility. |
| Formula |
((succInterSgsnRaUpdate + succIntraSgsnRaUpdate) / (attInterSgsnRaUpdate + attIntraSgsnRaUpdate)) * 100 |
| Counter Descriptions |
succInterSgsnRaUpdate: Each time a ROUTING AREA UPDATE COMPLETE message is received from the MS.
succIntraSgsnRaUpdate: Each time an appropriate ROUTING AREA UPDATE ACCEPT is sent to the MS.
attInterSgsnRaUpdate: Each time a ROUTING AREA UPDATE REQUEST is received from the MS, indicating an RA update in which the ROUTING AREA is served by another SGSN.
attIntraSgsnRaUpdate: Each time a ROUTING AREA UPDATE REQUEST is received from an MS, indicating an RA update in which the old RA and the new RA are served by this SGSN.
|
| Object Class |
ROUTING AREA |
| Unit Range |
% |
| Remarks & Comment |
2G SGSN Counters are same as 3G but in measurement we can differentiate between them in header of each counter i.e. For 3G RA3GMMAF:succInterSgsnRaUpdate and for 2G, RA2GMMAF:succInterSgsnRaUpdate. |
| Process |
| |
| KPI CRN65 |
3G Routing Area Update Success Rate |
| Target Value |
>95% |
| Frequency |
Weekly |
| Description |
This measurement indicates the success rate of a total RA Update in associating successful performing intra SGSN ROUTING AREA update performed within the serving SGSN and inter SGSN due to MS mobility. |
| Formula |
((succInterSgsnRaUpdate + succIntraSgsnRaUpdate) / (attInterSgsnRaUpdate + attIntraSgsnRaUpdate)) * 100 |
| Counter Descriptions |
succInterSgsnRaUpdate: Each time a ROUTING AREA UPDATE COMPLETE message is received from the MS.
succIntraSgsnRaUpdate: Each time an appropriate ROUTING AREA UPDATE ACCEPT is sent to the MS.
attInterSgsnRaUpdate: Each time a ROUTING AREA UPDATE REQUEST is received from the MS, indicating an RA update in which the ROUTING AREA is served by another SGSN.
attIntraSgsnRaUpdate: Each time a ROUTING AREA UPDATE REQUEST is received from an MS, indicating an RA update in which the old RA and the new RA are served by this SGSN.
|
| Object Class |
ROUTING AREA |
| Unit Range |
% |
| Remarks & Comment |
3G SGSN Counters are same as 2G but in measurement we can differentiate between them in header of each counter i.e. For 3G RA3GMMAF:succInterSgsnRaUpdate and for 2G, RA2GMMAF:succInterSgsnRaUpdate. |
| Process |
| |
| KPI CRN66 |
2G DNS Query Success Rate |
| Target Value |
>99.95% |
| Frequency |
Weekly |
| Description |
This KPI indicates the rate of successful DNS Query of 2G system that haven’t been terminated within the SGSN area due to addressing problems by MS or network, MS addresses Problems with missing/unknown APN or unknown PDP Address and type. |
| Formula |
(1 - (rejActPdpCtxtAddrProblem / attActPdpContext)) * 100 |
| Counter Descriptions |
rejActPdpCtxtAddrProblem: Each time an ACTIVATE SECONDARY PDP CONTEXT REJECT is transmitted to the MS with cause 27 (missing or unknown APN) or with cause 28 (unknown PDP address or PDP type).
AttActPdpContext: Each time the SGSN receives an ACTIVATE PDP CONTEXT ACCEPT or ACTIVATE PDP CONTEXT REJECT from an MS.
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Remarks & Comment |
2G SGSN Counters are same as 3G but in measurement we can differentiate between them in header of each counter i.e. SGSN3GSM : AttActPdpContext for 3G and for 2G, SGSN2GSM:AttActPdpContext. |
| Process |
| |
| KPI CRN67 |
3G DNS Query Success Rate |
| Target Value |
>99.95% |
| Frequency |
Weekly |
| Description |
This KPI indicates the rate of successful DNS Query of 3G system that haven’t been terminated within the SGSN area due to addressing problems by MS or network, MS addresses problems with missing/unknown APN or unknown PDP Address and type. |
| Formula |
(1 - (rejActPdpCtxtAddrProblem / attActPdpContext)) * 100 |
| Counter Descriptions |
rejActPdpCtxtAddrProblem: Each time an ACTIVATE SECONDARY PDP CONTEXT REJECT is transmitted to the MS with cause 27 (missing or unknown APN) or with cause 28 (unknown PDP address or PDP type).
AttActPdpContext: Each time the SGSN receives an ACTIVATE PDP CONTEXT ACCEPT or ACTIVATE PDP CONTEXT REJECT from an MS.
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Remarks & Comment |
3G SGSN Counters are same as 2G but in measurement we can differentiate between them in header of each counter i.e. SGSN3GSM : AttActPdpContext for 3G and for 2G, SGSN2GSM:AttActPdpContext. |
| Process |
| |
| KPI CRN68 |
2G Packet Data Protocol Update Success Rate |
| Target Value |
>98% |
| Frequency |
Weekly |
| Description |
Indicates how many SGSN-initiated PDP context update procedures were handled successfully related to total number of attempts where already the PDP are activated. This measurement provides the number of attempted SGSN-Initiated PDP context update procedures. An Update PDP Context Request message shall be sent from a SGSN to a GGSN as part of the GPRS Inter SGSN Routing Update procedure or the PDP Context Modification procedure or to redistribute contexts due to load sharing. It shall be used to change the QoS and the path. The message shall be sent by the new SGSN at the Inter SGSN Routing Update procedure. |
| Formula |
(succUpdPdpContextSgsn / attUpdPdpContextSgsn) * 100 |
| Counter Descriptions |
succUpdPdpContextSgsn: Each time an UPDATE PDP CONTEXT RESPONSE is transmitted to the GGSN.
attUpdPdpContextSgsn: Each time an UPDATE PDP CONTEXT REQUEST is received from the GGSN.
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Remarks & Comment |
2G SGSN Counters are the same as 3G but in measurement we can differentiate between them in header of each counter i.e SGSN3GSM:succUpdPdpContextGgsn for 3G and for 2G, SGSN2GSM:succUpdPdpContextGgsn |
| Process |
| |
| KPI CRN69 |
3G Packet Data Protocol Update Success Rate |
| Target Value |
>98% |
| Frequency |
Weekly |
| Description |
Indicates how many SGSN-initiated PDP context update procedures were handled successfully related to total number of attempts where already the PDP are activated. This measurement provides the number of attempted SGSN-Initiated PDP context update procedures. An Update PDP Context Request message shall be sent from a SGSN to a GGSN as part of the GPRS Inter SGSN Routing Update procedure or the PDP Context Modification procedure or to redistribute contexts due to load sharing. It shall be used to change the QoS and the path. The message shall be sent by the new SGSN at the Inter SGSN Routing Update procedure. |
| Formula |
(succUpdPdpContextSgsn / attUpdPdpContextSgsn) * 100 |
| Counter Descriptions |
succUpdPdpContextSgsn: Each time an UPDATE PDP CONTEXT RESPONSE is transmitted to the GGSN.
attUpdPdpContextSgsn: Each time an UPDATE PDP CONTEXT REQUEST is received from the GGSN.
|
| Object Class |
EXCHANGE |
| Unit Range |
% |
| Remarks & Comment |
3G SGSN Counters are the same as 2G but in measurement we can differentiate between them in header of each counter i.e SGSN3GSM:succUpdPdpContextGgsn for 3G and for 2G, SGSN2GSM:succUpdPdpContextGgsn |
| Process |
| |
| KPI CRN70 |
RAB Establishment Success Rate for PS |
| Target Value |
>99% |
| Frequency |
Weekly |
| Description |
This KPI describes the ratio of successful PS RAB establishments related to the total number of PS RAB establishment attempts. |
| Formula |
(rabEstabTypeSucc / rabEstabTypeAtt) * 100 |
| Counter Descriptions |
rabEstabTypeSucc [6,7,11-23]: Transmission of a RANAP-message RAB ASSIGNMENT RESPONSE sent by the UTRAN to the CN, with a “RAB to be setup.” For the successfully established RAB, the relevant counter is increased as well where an active link set already exists.
rabEstabTypeAtt[6,7,11-23]: Receipt of a RANAP-message RAB ASSIGNMENT REQUEST sent by the CN to the UTRAN, with a “RAB to be set up” and where as well an active link set already exists.
|
| Object Class |
UCELL |
| Unit Range |
% |
| Process |
| |