Nortel - KPI Formula's Desc Detail

3G 1xRTT Nortel Operational Measurements

Prepared by Core RF Engineering 04/22/02
Your input is important. If you have questions, comments, or suggestions
regarding this document, contact the person listed above by e-mail or phone. You may also contact Standards Development. (Address your e-mail message to Standards Development or check the Standards Development web page under TS&NO on Connected.) Your knowledge and insight are invaluable resources for improving Sprint PCS documentation.
Sprint PCS
Proprietary & Confidential
04/22/02
Page 1
Table of Contents
1. Introduction 2. Overview of 3G Voice and Data in Nortel Implementation 5 6
3. Performance Formulas 10 3.1. Performance Formulas for 3G Voice 10 3.1.1. 3G Voice Call Success .................................................................................... 10 3.1.2. 3G Voice Total Blocks.................................................................................... 12 3.1.2.1. Detailed 3G Voice Blocks......................................................................... 14 3.1.3. 3G Voice Access Failures ............................................................................... 19 3.1.3.1. Detailed 3G Voice Access Failures........................................................... 21 3.1.4. 3G Voice Drop Calls ....................................................................................... 22 3.1.4.1. Detailed 3G Voice Drops .......................................................................... 24 3.1.5. 3G Voice Pre-MCTA Frequency Selection Failures....................................... 25 3.1.6. 3G Voice Pre-MCTA Resource Allocation Failures (per frequency) ............. 27 3.1.6.1. Detailed 3G Voice Pre-MCTA Resource Allocation Failures (per frequency).................................................................................................. 29 3.1.7. 3G Voice Post-MCTA Traffic Distribution (per frequency)........................... 32 3.1.8. 3G Voice Post-MCTA Call Success (per frequency)...................................... 34 3.1.9. 3G Voice Post-MCTA Call Blocks (per frequency) ....................................... 35 3.1.9.1. Detailed 3G Voice Post-MCTA Call Blocks (per frequency)................... 37 3.1.10. 3G Voice Post-MCTA Access Failures (per frequency) ................................. 39 3.1.10.1. Detailed 3G Voice Post-MCTA Access Failures (per frequency) ............ 41 3.1.11. 3G Voice Post-MCTA RF related Drop Calls (per frequency) ....................... 43 3.2. Performance Formulas for 3G Fundamental Channel Data 44 3.2.1. 3G Packet Data Call Success .......................................................................... 44 3.2.2. 3G Packet Data Total Blocks .......................................................................... 46 3.2.2.1. Detailed 3G Packet Data Blocks ............................................................... 47 3.2.3. 3G Packet Data Access Failure ....................................................................... 53 3.2.3.1. Detailed 3G Packet Data Access Failures ................................................. 55 3.2.4. 3G Packet Data Drop Calls ............................................................................. 56 3.2.4.1. Detailed 3G Packet Data Drop Calls......................................................... 57 3.2.5. 3G Packet Data Calls Dormant to Active Transition Average Rate ............... 59 3.2.6. 3G Data Pre-MCTA Frequency Selection Failures......................................... 60 3.2.7. 3G Data Pre-MCTA Resource Allocation Failures (per frequency) ............... 62 3.2.7.1. Detailed 3G Data Pre-MCTA Resource Allocation Failures (per frequency).................................................................................................. 64 3.2.8. 3G Data Post-MCTA Traffic Distribution (per frequency)............................. 67 3.2.9. 3G Data Post-MCTA Call Success (per frequency)........................................ 69
Sprint PCS
04/22/02
Page 2
3.2.10. 3G Data Post-MCTA Call Blocks (per frequency) ......................................... 70 3.2.10.1. Detailed 3G Data Post-MCTA Call Blocks (per frequency)..................... 72 3.2.11. 3G Data Post-MCTA Access Failures (per frequency) ................................... 74 3.2.11.1. Detailed 3G Data Post-MCTA Access Failures (per frequency) .............. 76 3.2.12. 3G Data Post-MCTA RF related Drop Calls (per frequency) ......................... 78 3.2.13. PCU MO: 3G Data R-P Interface Packet Sessions ......................................... 79 3.2.13.1. 3G Data R-P Interface Packet Session Successes ..................................... 80 3.2.13.2. 3G Data R-P Interface Packet Session Failures ........................................ 81 3.2.13.3. 3G Data R-P Interface Performance Formulas.......................................... 82 3.2.14. ESEL MO: 3G Data RLP Sessions ................................................................. 83 3.2.14.1. 3G Data RLP Session Successes ............................................................... 84 3.2.14.2. 3G Data RLP Session Failures .................................................................. 84 3.3. Performance Formulas for 3G Forward Supplemental Channel Data (ESEL MO) 85 3.3.1. Forward Burst Setup Success .......................................................................... 85 3.3.2. Forward Burst Setup Failures.......................................................................... 86 3.3.3. Forward SCH Blocks ...................................................................................... 87 3.3.3.1. Detailed Forward SCH Blocks .................................................................. 87 3.3.4. Forward SCH Access Failures ........................................................................ 89 3.3.5. Forward SCH Time Out .................................................................................. 90 3.3.6. Forward SCH Data Rate Downgrades............................................................. 90 3.4. Performance Formulas for 3G Reverse Supplemental Channel Data (ESEL MO) 91 3.4.1. Reverse Burst Setup Success........................................................................... 91 3.4.2. Reverse Burst Setup Failures .......................................................................... 92 3.4.3. Reverse SCH Blocks ....................................................................................... 93 3.4.3.1. Detailed Reverse SCH Blocks................................................................... 93 3.4.4. Reverse SCH Access Failures ......................................................................... 95 3.4.5. Reverse SCH Time Out................................................................................... 95 3.4.6. Reverse SCH Data Rate Downgrades ............................................................. 96 3.5. Performance Formulas for BTS Managed Objects (MOs) 97 3.5.1. Advanced Sector 3G Fundamental Channel Formulas ................................... 97 3.5.1.1. 3G FCH Originations ................................................................................ 97 3.5.1.2. 3G FCH Soft Handoff Blocks ................................................................. 100 3.5.1.3. 3G Average number of FCH Handoff Links ........................................... 103 3.5.2. Advanced Sector 3G Supplemental Channel Formulas ................................ 104 3.5.2.1. 3G SCH Burst 105 3.5.2.2. 3G SCH Handoff Blocks 107 3.5.2.3. 3G Average number of SCH Handoff Links 109 3.5.3. Advanced Frequency Assignment (FA) Managed Object Formulas............. 110 4. Field Results Analysis 113
Sprint PCS
04/22/02
Page 3
4.1.
Access Failures 113 4.1.1. Access failures during originations and terminations: (CAUERLFL) .......... 115 4.1.2. Access failures during hard handoffs: (CAUHRLFL) .................................. 115 4.2. Blocks 116 4.2.1. Blocking due to lack of BTS channel elements: (CAUNOTCE).................. 117 4.2.2. Blocking due to lack of Walsh codes: (CAUNOWCD)................................ 117 4.2.3. Blocking due to lack of forward capacity: (CAUFWCAP)........................... 118 4.2.4. Blocking due to lack of reverse capacity: (CAURECAP)............................. 118 4.2.5. Blocking due to lack of physical resources: .................................................. 119 4.2.6. Blocking due to no frame offset availability: (CAUNOFOF)....................... 119 4.2.7. Blocking due to BTS time-outs:.................................................................... 120 4.2.8. Blocking due to BSC time-outs and software faults: .................................... 120 4.3. Drops 121 4.3.1. Drops due to RF-related reasons: (CAUDROPR)......................................... 122 4.3.2. Drops due to network-related reasons: (CAUDROPN) ................................ 122 5. New Operational Measurements in 3G 1xRTT 5.1. OM Groups: CAUSCT3V, CAUSCT3D 5.2. OM Groups: CAURFQ3V, CAUFRQ3D 5.3. OM Group: CAUDAT3G 5.4. OM Group: RMU3G (RMU OMs for 3G calls) 5.5. OM Group: CDMAPDOM (CDMA Packet Data) 5.6. OM Group: CDMAPDSO (CDMA Packet Data Service Option) 5.7. OM Group: CAURM 5.8. OM Group: CAUCPSYS 5.9. OM Group: CDMAPGZN 5.10. OM Group: PCU 5.11. OM Group: ESEL 5.12. OM Group: BTSCallProcessing MO 5.13. OM Group: Advanced Frequency Assignment (FA) MO 5.14. OM Group: Advanced Sector MO 6. List Of Operational Measurements (OMs) Requested By Sprint From Nortel And Other Vendors 7. References 124 124 128 131 132 133 134 135 136 136 137 139 141 142 143
148 165
Sprint PCS
04/22/02
Page 4
1. Introduction
1xRTT, also known as cdma2000, is a wideband, spread-spectrum radio interface that uses code division multiple access (CDMA) technology to satisfy the needs of third-generation (3G) wireless communication systems. The four main benefits offered by 1xRTT are:

Higher Capacity Longer Mobile Battery Life in standby mode High-speed packet data Backward compatibility
The purpose of this document is to provide information about Nortels new 3G 1xRTT Operational Measurements and related 3G 1xRTT Performance Formulas that should be monitored in the field. The audience for this document is RF engineers that are working with the Nortel equipment. In Section 5 all new 3G Operational Measurements are explained. Performance formulas that can be used on daily basis and related OMs are explained in Section 3. Nortel plans to add more Operational Measurements in the future and for that reason this document will need to be updated. List of all requested Operational Measurements as well as current Operational Measurements availability for all vendors can be found in Section 6 Operational Measurements (OMs) are counts of call processing events that provide the operating company with performance data for the DMS-MTX system. System engineers use OM records to ensure that the DMS-MTX switch operates efficiently. OMs provide information regarding system performance, grade of service being offered, connecting facilities, performance, and traffic levels of various elements internal to and connected to the system. This document is based on Nortel Networks documentation (see references in Section 7), 3G FMA test results and 2G experience. It is assumed that the reader has basic technical knowledge of 1xRTT standard and 2G Operational Measurements experience.
Sprint PCS
04/22/02
Page 5
2. Overview of 3G Voice and Data in Nortel Implementation

The following table provides the list of additional hardware and software that is required for the 1xRTT networks: Table 2-1: 1xRTT Hardware/Software Requirements
Device BTS BSC Hardware XCEM SCI-S ESEL MSC PC MTX10 CDF Editor v1.1 Software NBSS10.1.x NBSS10.1.x
MTX10/NBSS10.1.x is the baseline software that is used to provide the 3G capability in the existing 2G networks. There are many new parameters that are added in this software release; however, we will concentrate our efforts on the RF related parameters. More specifically, we will limit our discussion to the 3G related operational measurements (OMs) that are utilized for the 3G voice and data implementation. Many new OMs are introduced in 1xRTT in order to provide performance data specific to the 3G calls. Additionally, some existing OMs are enhanced to capture the 3G call-related events. The detailed description of all the 3G OMs is provided in Section 5 of this document. Nortel OMs are categorized based on the location where these OMs are getting pegged, as follows:
MSC OMs:
Eight new OM groups have been added in the MSC that are pegged at the CM and CAU and/or RMU, as follows:

CAUSCT3V (CAU SeCTor based OMs for 3G Voice calls) CAUSCT3D (CAU SeCTor based OMs for 3G Data calls) CAUFRQ3V (CAU FReQuency based OMs for 3G Voice calls) CAUFRQ3D (CAU FReQuency based OMs for 3G Data calls) CAUDAT3G (CAU sector based OMs for short DATa bursts initiated by 3G mobiles) RMU3G (RMU OMs for 3G calls) CDMAPDOM (CDMA Packet Data OMs) CDMAPDSO (CDMA Packet Data Service Option OMs)
Sprint PCS
04/22/02
Page 6
In addition to the above OM groups, the following OM groups have been modified for 1xRTT in the MSC:
CAUCPSCT (CAU SeCTor based OMs for Call Processing) Enhanced to capture additional BTS resource allocation failures. CAUCPFRQ (CAU FReQuency based OMs for Call Processing) Enhanced to capture additional BTS resource allocation failures. CAURM (CAU OMs relating to the resource manager) Enhanced to contain both 2G call information and 3G information. This is done by indexing the current OM structure by way of a new key field CDMA_CALLTYPE. Three new registers are also added to CAURM OM group (listed in Section 5). CDMAPGZN (CM OMs relating to the page zone events) Enhanced to capture network-initiated Short Data Burst (SDB) related events. CAUCPSYS (CAU OMs relating to the Call Processing System) Enhanced to capture network-initiated Short Data Burst (SDB) related events.
OM3G Boolean field: A new Boolean field OM3G is created in the CDMAPART table to indicate whether the OMs for 3G voice calls and 3G data calls are to be kept separate from the OMs for 2G calls. The new OM groups CAUSCT3V, CAUSCT3D, CAUFRQ3V, CAUFRQ3D maintain 3G voice and 3G data OM counts for a particular sector only if OM3G Bool is set to Y. If a particular sector is 3G capable but OM3G is set to N, then the 3G voice and 3G data OM counts are lumped together with the 2G OMs in the CAUCPSCT and CAUCPFRQ OM groups. The following table can be used to understand the functionality of the OM3G Bool: NOTE: SPCS Core RF recommended value for OM3G is Y. Table 2-2: OM3G Bool
OM3G Impact on CAUCPSCT and Bool CAUCPFRQ OM groups Y Impact on CAUSCT3V and CAUFRQ3V OM groups Impact on CAUSCT3D and CAUFRQ3D OM groups
The registers in these two OM The registers in these two OM The registers in these two OM groups get pegged only for events groups get pegged only for events groups get pegged only for events related to 2G calls related to 3G Voice calls related to 3G Data calls The registers in these two OM The registers in these two OM groups get pegged only for all call- groups do not get pegged. The related 3G voice call-specific related events (3G Voice, 3G events will be captured in Data, and 2G calls) CAUCPSCT and CAUCPFRQ OM groups along with 3G Data and 2G call-related events The registers in these two OM groups do not get pegged. The related 3G Data call-specific events will be captured in CAUCPSCT and CAUCPFRQ OM groups along with 3G voice and 2G call-related events
Sprint PCS
04/22/02
Page 7
MCTA OMs: The MSC has another set of OMs available under the MCTA reports. The MCTA performance reflects how well the system is allocating resources across multiple frequencies for new originations, terminations, and hard handoff attempts from other CDMA cells. The performance is determined on a per frequency basis. MCTA OMs do not replace the normal call processing OMs but are pegged in addition to the normal call processing OMs. Consequently there is some duplicate information.
BSC OMs:
BSC OMs are collected by the following two managed objects (MOs):
The Packet Control Unit (PCU)
PCU OMs help in evaluating the R-P link between the SBS and the PDSN and in the setup of packet data sessions over the L2TP tunnel.
The Enhanced Selector Card (ESEL)
ESEL OMs help in evaluating the performance of the RLP, the setup of supplemental channels, and the setup of data session elements on the selector card. Both of these MOs are new for 1xRTT; and are collected in the subsystems and forwarded to the base station subsystem manager (BSSM) every 30 minutes in the form of a ConsolidatedOM Event Report, using the mechanism developed for the CDMA-LTX product.
BTS OMs:
The RF-related BTS OMs are collected by the following five managed objects (MOs):
BTSCallProcessing
These OMs are pegged on a per-BTS basis. Each of these pegs is the sum of all events in every frequency and every sector hosted by the BTS.
Advanced FA MO
Advanced Frequency Assignment (FA) OMs deal with the status of XCEM resources on the fundamental as well as the supplemental channels.
CBCM MO
The CBCM provides management of the entire MCBTS, communications over the T1/E1 and to the mate DCG. The CBCM hardware is composed of the BTS controller and the BTS Interface.
Power Management MO
These are pegged on a per CDMA frequency, per-sector basis for all the supported frequencies.
Sprint PCS
04/22/02
Page 8
Advanced Sector MO
These are pegged on a per-sector basis for all of the supported frequencies. Events pegged in these OMs include BTS resource allocations, call attempts blocks and handoff blocks.
Sprint PCS
04/22/02
Page 9
3. Performance Formulas
This section lists the 1xRTT performance formulas for 3G voice, 3G data, and 3G forward and reverse supplemental channel data. Field results presented in this section are four-days results from Kansas City market, specifically the K1B1 and K2B2 test clusters which include 30 sites. Please note that there are three different sets of formulas as follows: 1. Formulas currently supported by the ePerformance tool: These are the formulas that are currently being used on a daily basis for performance monitoring. For these formulas, we have the field data available. 2. Formulas for which no reports are available in the ePerformance tool: These are detailed formulas with specific information. For example, 3G voice call blocks due to lack of Walsh codes. For this type of formulas, no reports or plots are currently provided in the tool. However, the OMs relating to these formulas are pegged; and are available in the raw format. The field result values for these can be calculated by post processing the raw data. 3. Formulas not supported by the ePerformance tool: For these formulas, the relevant OMs are not currently pegged. In this section, all of the above mentioned formula types along with their OMs are listed. Please note that the results for 3G Data calls are outside the desired ranges for many performance formulas. This is because the data calls are mostly collected from a very small set of sectors. Additionally, the number of data users (data call attempts) are not sufficient to validate test results. Therefore, it is not possible to provide field result ranges that are statistically valid at this point in time. However, as more field results become available from several different markets, this document will be updated to reflect those results.
3.1. Performance Formulas for 3G Voice

3.1.1. 3G Voice Call Success Formula Call Succ% = [Number of successful calls / Total calls Attempted] * 100
Sprint PCS
04/22/02
Page 10
Number of successful calls = CAUSCT3V.CAUOSUCC + CAUSCT3V.CAUTSUCC + CAUSCT3V.CAUHSUCC Total calls Attempted = CAUSCT3V.CAUOATTS + CAUSCT3V.CAUPGRES + CAUSCT3V.CAUHATTS FchOriginationNonBlocking3GDowngrade2G NOTE: Currently the ePerformance tool does not take into account 3G call attempts downgraded to 2G. The FchOriginationNonBlocking3Gdowngrade2G is a BTS OM which is pegged when the BTS runs out of XCEM resources but still has CEM resources and all other needed resources to be set up for the call as a 2G voice call rather than a 3G voice call as requested. OMs CAU Origination SUCCess CAUOSUCC Pegged when a mobile-originated call successfully arrives on the traffic channel. This includes all originations placed on the traffic channel to receive treatment. CAU Termination SUCCess CAUTSUCC Pegged when a mobile-terminated call successfully arrives on the traffic channel. CAU hard Handoff SUCCess CAUHSUCC Pegged when a mobile, attempting a hard handoff, successfully arrives on the traffic channel in the target sector. CAU Origination ATTemptS CAUOATTS Pegged when the CAU receives an origination message from the BTS. Test call originations are pegged in a separate OM. CAU PaGe RESponse CAUPGRES For mobile-terminated calls, attempts are recorded in CAUPGRES, which indicates that a page response was received from a CDMA sector in response to a page request (irrespective of whether it was in response to an initial page request or a retry by the CM).
Sprint PCS
04/22/02
Page 11
CAU hard Handoff ATTemptS CAUHATTS Pegged when the CAU receives a ReadyNewCell message from the CM, indicating that a hard handoff attempt sequence in a (CDMA) target sector should begin. FchOriginationNonBlocking3GDowngrade2G Number of successful BTS resource allocations for fundamental channel 2G calls which were downgraded from 3G calls attempts. This metric does not include non-reference pilot links setup for CASHO. 2G links, other than the reference pilots link, setup for CASHO are pegged under FchHandoffNonBlocking2G. Field Results Day 1: 92.28 % Day 2: 91.95 % Day 3: 92.09 % Day 4: 94.49 %
Expected Formula Range: It should match the 2G Voice Call Success. 3.1.2. 3G Voice Total Blocks Please note that currently the total blocks percentage given by the ePerformance tool does not take into account 3G call attempts downgraded to 2G. The FchOriginationNonBlocking3Gdowngrade2G is a BTS OM which is pegged when the BTS runs out of XCEM resources but still has CEM resources and all other needed resources to be set up for the call as a 2G voice call rather than a 3G voice call as requested. Formula Total Blocks% = [Total number of blocked calls / Total calls attempted] * 100 Total number of blocked calls = CAUSCT3V.CAUOBLKS + CAUSCT3V.CAUTBLKS +
Sprint PCS
04/22/02
Page 12
CAUSCT3V.CAUHBLKS Total calls attempted CAUSCT3V.CAUOATTS + CAUSCT3V.CAUPGRES + CAUSCT3V.CAUHATTS FchOriginationNonBlocking3GDowngrade2G OMs CAU Origination BLocKS CAUOBLKS Pegged any time a mobile-originated call setup fails due to resource shortage. It represents the total number of origination setup failures in a sector, regardless of resource. The same failure reasons that are pegged for CAUTBLKS can be pegged in conjunction with CAUOBLKS. CAU Termination BLocKS CAUTBLKS Pegged any time a mobile-terminated call setup fails due to resource shortage. It represents all of the termination setup failures in a sector, regardless of resource. One or more of the following call setup failure reasons is pegged in conjunction with CAUTBLKS: RMNORREQ, RMSRMNAK, RMSRMTO, CAUERSFL, CAUNOTCE, CAUNOWCD, CAUNOFOF, CAUFWCAP, CAURECAP and CAUESWFL. CAU hard Handoff BLocKS CAUHBLKS Pegged any time a CDMA-to-CDMA hard handoff setup fails due to resource shortage. It represents all of the hard handoff setup failures into a sector, regardless of resource. This OM is pegged for both inter- and intra-system hard handoff attempts. CAUHBLKS is not the number of dropped hard handoffs, it merely represents the number of times that a hard handoff could not be completed due to resource shortages in the target cell/sectorthe call in the source cell is still up. The same failure reasons that are pegged for CAUOBLKS (see previous page) can be pegged in conjunction with CAUHBLKS. CAU Origination ATTemptS CAUOATTS Pegged when the CAU receives an origination message from the BTS. Test call originations are pegged in a separate OM. CAU PaGe RESponse CAUPGRES
Sprint PCS
04/22/02
Page 13
For mobile-terminated calls, attempts are recorded in CAUPGRES, which indicates that a page response was received from a CDMA sector in response to a page request (irrespective of whether it was in response to an initial page request or a retry by the CM). CAU hard Handoff ATTemptS CAUHATTS Pegged when the CAU receives a ReadyNewCell message from the CM, indicating that a hard handoff attempt sequence in a (CDMA) target sector should begin. FchOriginationNonBlocking3GDowngrade2G Number of successful BTS resource allocations for fundamental channel 2G calls which were downgraded from 3G calls attempts. This metric does not include non-reference pilot links setup for CASHO. 2G links, other than the reference pilots link, setup for CASHO are pegged under FchHandoffNonBlocking2G. Field Results Day 1: 0.02 % Day 2: 0.01 % Day 3: 0.07 % Day 4: 0.13 %
Expected Formula Range: It should match the 2G Voice Call Blocks. 3.1.2.1. Detailed 3G Voice Blocks The following formulas are currently not supported by the ePerformance tool. For frequency level information, please refer Section 3.1.9.1. Formulas Blocks due to lack of traffic channel elements: TCE% = [CAUSCT3V.CAUNOTCE / (CAUSCT3V.CAUOATTS + CAUSCT3V.CAUPGRES +
Sprint PCS
04/22/02
Page 14
CAUSCT3V.CAUHATTS FchOriginationNonBlocking3GDowngrade2G)] * 100 Blocks due to lack of walsh codes: WCD% = [CAUSCT3V.CAUNOWCD / (CAUSCT3V.CAUOATTS + CAUSCT3V.CAUPGRES + CAUSCT3V.CAUHATTS FchOriginationNonBlocking3GDowngrade2G)] * 100 Blocks due to no frame offset availability: Frame Offset% = [CAUSCT3V.CAUNOFOF / (CAUSCT3V.CAUOATTS + CAUSCT3V.CAUPGRES + CAUSCT3V.CAUHATTS FchOriginationNonBlocking3GDowngrade2G)] * 100 Blocks due to lack of forward capacity: FWDCAP% = [CAUSCT3V.CAUFWCAP / (CAUSCT3V.CAUOATTS + CAUSCT3V.CAUPGRES + CAUSCT3V.CAUHATTS FchOriginationNonBlocking3GDowngrade2G)] * 100 Blocks due to lack of reverse capacity: REVCAP% = [CAUSCT3V.CAURECAP / (CAUSCT3V.CAUOATTS + CAUSCT3V.CAUPGRES + CAUSCT3V.CAUHATTS FchOriginationNonBlocking3GDowngrade2G)] * 100 Blocks due to lack of physical resources: Physical Resources% = [(CAURM.RMNORREQ + CAUSCT3V.CAUERSFL) / (CAUSCT3V.CAUOATTS + CAUSCT3V.CAUPGRES + CAUSCT3V.CAUHATTS FchOriginationNonBlocking3GDowngrade2G)] * 100 Blocks due to BTS time-outs: BTS Time-outs% = [(CAUSCT3V.CAUERSFL
Sprint PCS
04/22/02
Page 15
CAUSCT3V.CAUNOTCE CAUSCT3V.CAUNOWCD CAUSCT3V.CAUFWCAP CAUSCT3V.CAUNOFOF CAUSCT3V.CAURECAP CAUSCT3V.MCTAREQF CAUSCT3V.MCTAHRQF BlockedFchOrigination3Gvoice[6]) / (CAUSCT3V.CAUOATTS + CAUSCT3V.CAUPGRES + CAUSCT3V.CAUHATTS FchOriginationNonBlocking3GDowngrade2G)] * 100 Blocks due to BCS time-outs and software faults: BSC Time-outs% = [(CAURM.RMSRMTO + CAURM.RMSRMNAK + CAUSCT3V.CAUESWFL) / (CAUSCT3V.CAUOATTS + CAUSCT3V.CAUPGRES + CAUSCT3V.CAUHATTS FchOriginationNonBlocking3GDowngrade2G)] * 100 OMs CAU NO Traffic Channel Element CAUNOTCE Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports no traffic channel element via NOIS messages, regardless of origination, termination or hard handoff. CAU NO Walsh Code CAUNOWCD Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports no walsh code via NOIS messages, regardless of origination, termination or hard handoff. CAU NO Frame Offset CAUNOFOF Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS cannot allocate resources due to some CSM 5000 hardware limitation. The CSM 5000 is limited in how much traffic it can support on its reverse link because
Sprint PCS
04/22/02
Page 16
of the limitation on the number of decoding units (both Viterbi and Turbo) that an be active on a frame offset (and adjacent frame offsets). CAU ForWard CAPacity full CAUFWCAP Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports forward capacity full via NOIS messages, regardless of origination, termination or hard handoff. CAU REverse CAPacity full CAURECAP Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports reverse capacity full via NOIS messages, regardless of origination, termination or hard handoff. However, currently there is no reliable mechanism for estimating reverse link capacity and so this response is disabled on the BTS. Consequently, this OM is never pegged. Resource Manager NO Resources for REQuest RMNORREQ Pegged, along with the appropriate CAU*BLKS OM, when Resource Manager (RM) has no available resources to allocate for a call. In this case, the RM does not message to any of its SBSs to determine availability, only internal data structures are checked. CAU Error case, Radio Setup FaiLure CAUERSFL Pegged, along with the appropriate CAU*BLKS OM, whenever a call setup fails due to the fact that some BTS resource is not available. This OM is also pegged when the BTS does not respond to resource requests. It is also pegged when the Carrier Determination Algorithm (CDA) fails to select a carrier in an MCTA enabled sector (that is, no available capacity on all co-located carriers). MCTA REQuest Failure MCTAREQF Pegged, along with CAUERSFL, when NO frequency was successfully selected by MCTA for origination or termination call setup. It is pegged on a per-sector basis. The failure reasons are pegged by MCTAMIXF, MCTALLTO or MCTALLFU. MCTA Handoff ReQuest Failure MCTAHRQF Pegged, along with CAUERSFL, when NO frequency was successfully selected by MCTA for a hard handoff call setup. It is pegged on a per-sector basis on the
Sprint PCS
04/22/02
Page 17
target side. The failure reasons are pegged by MCTAMIXF, MCTALLTO or MCTALLFU. RM SRM Time-Out RMSRMTO Pegged, along with the appropriate CAU*BLKS OM, when the Resource Manager times out waiting on a request for call resources from the SRM. RM Service Resource Manager Negative AcK RMSRMNAK Pegged, along with the appropriate CAU*BLKS OM, when the Resource Manager (RM) receives a resource allocation failure indication from SRMs. This is an error condition, indicating mismatches between the RM and the SBS SRM. BlockedFchOriginations 3Gvoice Array indicating the number of 3G voice call attempts blocked on the fundamental channel. Each array element corresponds to a different blocking reason. CAU Error case, SoftWare FauLt CAUESWFL Pegged, along with the appropriate CAU*BLKS OM, whenever a call setup fails due to time outs between software entities that should not occur (for example, no response from the CM, failure message received from SBS, etc.). CAU Origination ATTemptS CAUOATTS Pegged when the CAU receives an origination message from the BTS. Test call originations are pegged in a separate OM. CAU PaGe RESponse CAUPGRES For mobile-terminated calls, attempts are recorded in CAUPGRES, which indicates that a page response was received from a CDMA sector in response to a page request (irrespective of whether it was in response to an initial page request or a retry by the CM). CAU hard Handoff ATTemptS CAUHATTS Pegged when the CAU receives a ReadyNewCell message from the CM, indicating that a hard handoff attempt sequence in a (CDMA) target sector should begin.
Sprint PCS
04/22/02
Page 18
FchOriginationNonBlocking3GDowngrade2G Number of successful BTS resource allocations for fundamental channel 2G calls which were downgraded from 3G calls attempts. This metric does not include non-reference pilot links setup for CASHO. 2G links, other than the reference pilots link, setup for CASHO are pegged under FchHandoffNonBlocking2G. Field Results: TCE Day 1: Day 2: Day 3: Day 4: WalshC NframO FwdC RevC PhyR BTSt-o BSCt-o
example example example example
Expected Formula Range: N/A (min and max will be defined where applicable) 3.1.3. 3G Voice Access Failures Please note that currently the access failure percentage given by the ePerformance tool does not take into account 3G call attempts downgraded to 2G. The FchOriginationNonBlocking3Gdowngrade2G is a BTS OM which is pegged when the BTS runs out of XCEM resources but still has CEM resources and all other needed resources to be set up for the call as a 2G voice call rather than a 3G voice call as requested. Formula Acc Fails% = [Number of access failures / Total calls attempted] * 100 Number of access failures = CAUSCT3V.CAUERLFL + CAUSCT3V.CAUHRLFL Total calls attempted = CAUSCT3V.CAUOATTS + CAUSCT3V.CAUPGRES + CAUSCT3V.CAUHATTS FchOriginationNonBlocking3GDowngrade2G
Sprint PCS
04/22/02
Page 19
OMs CAU Error Radio Link FaiLure CAUERLFL Pegged if the origination or termination fails because the mobile never arrived on the traffic channel (similar to SAT timeout). CAUERLFL is not pegged in cases where the CAUOBLKS or CAUTBLKS OMs are pegged. CAU hard Handoff Radio Link FaiLure CAUHRLFL Pegged if the hard handoff attempt fails because the mobile never arrived on the target sectors traffic channel (similar to SAT timeout). CAUHRLFL is not pegged in cases where CAUHBLKS is pegged. CAU Origination ATTemptS CAUOATTS Pegged when the CAU receives an origination message from the BTS. Test call originations are pegged in a separate OM. CAU PaGe RESponse CAUPGRES For mobile-terminated calls, attempts are recorded in CAUPGRES, which indicates that a page response was received from a CDMA sector in response to a page request (irrespective of whether it was in response to an initial page request or a retry by the CM). CAU hard Handoff ATTemptS CAUHATTS Pegged when the CAU receives a ReadyNewCell message from the CM, indicating that a hard handoff attempt sequence in a (CDMA) target sector should begin. FchOriginationNonBlocking3GDowngrade2G Number of successful BTS resource allocations for fundamental channel 2G calls which were downgraded from 3G calls attempts. This metric does not include non-reference pilot links setup for CASHO. 2G links, other than the reference pilots link, setup for CASHO are pegged under FchHandoffNonBlocking2G. Field Results Day 1: 2.17 % Day 2: 2.26 %
Sprint PCS
04/22/02
Page 20
Day 3: 2.07 % Day 4: 1.97 %
Expected Formula Range: It should match the 2G Voice Access Failures. 3.1.3.1. Detailed 3G Voice Access Failures The following formulas are currently not supported by the ePerformance tool. For frequency level information, please refer Section 3.1.10.1. Formulas Access failures during originations or terminations: Orig & Term% = [CAUSCT3V.CAUERLFL / (CAUSCT3V.CAUOATTS + CAUSCT3V.CAUPGRES FchOriginationNonBlocking3GDowngrade2G)] * 100 Access failures during hard handoffs: Handoff% = [CAUSCT3V.CAUHRLFL / CAUSCT3V.CAUHATTS] *100 OMs CAU Error Radio Link FaiLure CAUERLFL Pegged if the origination or termination fails because the mobile never arrived on the traffic channel (similar to SAT timeout). CAUERLFL is not pegged in cases where the CAUOBLKS or CAUTBLKS OMs are pegged. CAU hard Handoff Radio Link FaiLure CAUHRLFL Pegged if the hard handoff attempt fails because the mobile never arrived on the target sectors traffic channel (similar to SAT timeout). CAUHRLFL is not pegged in cases where CAUHBLKS is pegged. CAU Origination ATTemptS CAUOATTS Pegged when the CAU receives an origination message from the BTS. Test call originations are pegged in a separate OM.
Sprint PCS Proprietary & Confidential 04/22/02 Page 21
CAU PaGe RESponse CAUPGRES For mobile-terminated calls, attempts are recorded in CAUPGRES, which indicates that a page response was received from a CDMA sector in response to a page request (irrespective of whether it was in response to an initial page request or a retry by the CM). CAU hard Handoff ATTemptS CAUHATTS Pegged when the CAU receives a ReadyNewCell message from the CM, indicating that a hard handoff attempt sequence in a (CDMA) target sector should begin. FchOriginationNonBlocking3GDowngrade2G Number of successful BTS resource allocations for fundamental channel 2G calls which were downgraded from 3G calls attempts. This metric does not include non-reference pilot links setup for CASHO. 2G links, other than the reference pilots link, setup for CASHO are pegged under FchHandoffNonBlocking2G. Field Results: Day 1: Day 2: Day 3: Day 4: Orig&Term example example example example Hard Handoff
Expected Formula Range: N/A (min and max will be defined where applicable) 3.1.4. 3G Voice Drop Calls Formula Drop Call% = [Number of drop calls / Number of successful calls] * 100
Sprint PCS
04/22/02
Page 22
Number of drop calls = CAUSCT3V.CAUDROPR + CAUSCT3V.CAUDROPN Number of successful calls = CAUSCT3V.CAUOSUCC + CAUSCT3V.CAUTSUCC + CAUSCT3V.CAUHSUCC OMs CAU DROPped call Rf CAUDROPR Pegged by the CAU against the reference pilot when a call is dropped by the SBS due to loss of traffic or due to HCM (handoff completion message) timeout for soft or softer handoff. These are RF-related call failures as detected by the SBS. CAU DROPped call Network CAUDROPN Pegged by the CAU when any of the other (non-RF) drop indication reasons are sent from the SBS in the radio link drop indication message. CAU Origination SUCCess CAUOSUCC Pegged when a mobile-originated call successfully arrives on the traffic channel. This includes all originations placed on the traffic channel to receive treatment. CAU Termination SUCCess CAUTSUCC Pegged when a mobile-terminated call successfully arrives on the traffic channel. CAU hard Handoff SUCCess CAUHSUCC Pegged when a mobile, attempting a hard handoff, successfully arrives on the traffic channel in the target sector. Field Results Day 1: 2.05 % Day 2: 2.29 % Day 3: 1.91 %
Sprint PCS
04/22/02
Page 23
Day 4: 1.84 %
Expected Formula Range: It should match the 2G Voice Access Failures. 3.1.4.1. Detailed 3G Voice Drops (These formulas are not currently supported by the ePerformance tool) Formulas Drops due to RF-related reasons: RF% = [CAUSCT3V.CAUDROPR / (CAUSCT3V.CAUOSUCC + CAUSCT3V.CAUTSUCC + CAUSCT3V.CAUHSUCC)] * 100 Drops due to network-related reasons: Ntwk% = [CAUSCT3V.CAUDROPN / (CAUSCT3V.CAUOSUCC + CAUSCT3V.CAUTSUCC + CAUSCT3V.CAUHSUCC)] * 100 OMs CAU DROPped call Rf CAUDROPR Pegged by the CAU against the reference pilot when a call is dropped by the SBS due to loss of traffic or due to HCM (handoff completion message) timeout for soft or softer handoff. These are RF-related call failures as detected by the SBS. CAU DROPped call Network CAUDROPN Pegged by the CAU when any of the other (non-RF) drop indication reasons are sent from the SBS in the radio link drop indication message. CAU Origination SUCCess CAUOSUCC Pegged when a mobile-originated call successfully arrives on the traffic channel. This includes all originations placed on the traffic channel to receive treatment.
Sprint PCS
04/22/02
Page 24
CAU Termination SUCCess CAUTSUCC Pegged when a mobile-terminated call successfully arrives on the traffic channel. CAU hard Handoff SUCCess CAUHSUCC Pegged when a mobile, attempting a hard handoff, successfully arrives on the traffic channel in the target sector. Field Results: Day 1: Day 2: Day 3: Day 4: RF-related example example example example Network-related
Expected Formula Range: N/A (min and max will be defined where applicable) 3.1.5. 3G Voice Pre-MCTA Frequency Selection Failures This section deals with failures that occur before the Carrier Determination Algorithm (CDA) has selected a frequency. The following formula captures call failures due to failure to select a frequency: Formula Freq. Sel. Fail% = [No. of Freq. Sel. Fail / Total calls attempts for all freqs] * 100 No. of Freq. Sel. Fail. = CAUSCT3V.MCTAREQF + CAUSCT3V.MCTAHRQF Total calls attempts for all freqs = CAUFRQ3V.MCTORIGS + CAUFRQ3V.MCTPGRES + CAUFRQ3V.MCTHCATT
Sprint PCS
04/22/02
Page 25
NOTE: CAUFRQ3V refers to the sum of the register for all frequencies on the sector. OMs MCTA REQuest Failure MCTAREQF Pegged, along with CAUERSFL, when NO frequency was successfully selected by MCTA for origination or termination call setup. It is pegged on a per-sector basis. The failure reasons are pegged by MCTAMIXF, MCTALLTO or MCTALLFU. MCTA Handoff ReQuest Failure MCTAHRQF Pegged, along with CAUERSFL, when NO frequency was successfully selected by MCTA for a hard handoff call setup. It is pegged on a per-sector basis on the target side. The failure reasons are pegged by MCTAMIXF, MCTALLTO or MCTALLFU. MCTA ORIGination MCTAORIG Pegged, along with CAUOATTS, when the CAU receives an origination message from a sector that has MCTA enabled. It is pegged against the originating frequency. Test call originations are pegged in a separate OM. MCTA PaGe RESponse MCTAPGRES For mobile-terminated calls, attempts are recorded in MCTPGRES, which indicates that a page response was received from an MCTA enabled CDMA sector in response to a page request. This OM is pegged irrespective of whether it was the first or the second attempt to page the mobile. CAUPGRES is also pegged whenever MCTPGRES is pegged. MCTA Handoff Call ATTempts MCTHCATT Pegged, along with CAUHATTS, when the CAU receives a message from the CM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMA target sector should begin. Field Results Day 1: 0.97 %
Sprint PCS
04/22/02
Page 26
Day 2: 0.97 % Day 3: 1.28 % Day 4: 0.98 %
Expected Formula Range: It should match the 2G Voice Pre-MCTA Frequency Selection Failures 3.1.6. 3G Voice Pre-MCTA Resource Allocation Failures (per frequency) This section deals with the events where a particular frequency responds with a resource full response or times out in response to a capacity query request before the Carrier Determination Algorithm (CDA) is executed. Note that this event may or may not lead to overall MCTA frequency selection failure depending on whether all other frequencies respond with a similar response or not. If at least one frequency responds with a resource available response then the CDA will successfully select a carrier for the call attempt. Formula MCTA frequency resource allocation failures (per frequency) % = [No. of MCTA freq rsrc alloc failures / Total MCTA calls attempted] * 100 No. of MCTA freq resource allocation failures = CAUSCT3V.MCTAREQF + CAUSCT3V.MCTAHRQF + CAUFRQ3V.MCTAREQN + CAUFRQ3V.MCTAREQT Total MCTA calls attempted = CAUFRQ3V.MCTORIGS + CAUFRQ3V.MCTPGRES + CAUFRQ3V.MCTHCATT OMs MCTA REQuest Failure MCTAREQF Pegged, along with CAUERSFL, when NO frequency was successfully selected by MCTA for origination or termination call setup. It is pegged on a per-sector
Sprint PCS
04/22/02
Page 27
basis. The failure reasons are pegged by MCTAMIXF, MCTALLTO or MCTALLFU. MCTA Handoff ReQuest Failure MCTAHRQF Pegged, along with CAUERSFL, when NO frequency was successfully selected by MCTA for a hard handoff call setup. It is pegged on a per-sector basis on the target side. The failure reasons are pegged by MCTAMIXF, MCTALLTO or MCTALLFU. MCTA REQuest response full or Not available MCTAREQN Pegged when a frequency was successfully selected by MCTA but one or more of the BTSs responded with a resource full or not available response. MCTAREQN is pegged against the carrier(s) that respond with a resource full or not available response. MCTAREQN may not always be pegged under low load conditions. MCTA REQuest Timeout MCTAREQT Pegged when a frequency was successfully selected by MCTA but one or more of the BTSs never responded to a capacity request. MCTAREQT is pegged against the carrier(s) that did not respond to the capacity request. MCTAREQT may not always be pegged under low traffic load conditions. MCTA ORIGination MCTAORIG Pegged, along with CAUOATTS, when the CAU receives an origination message from a sector that has MCTA enabled. It is pegged against the originating frequency. Test call originations are pegged in a separate OM. MCTA PaGe RESponse MCTAPGRES For mobile-terminated calls, attempts are recorded in MCTPGRES, which indicates that a page response was received from an MCTA enabled CDMA sector in response to a page request. This OM is pegged irrespective of whether it was the first or the second attempt to page the mobile. CAUPGRES is also pegged whenever MCTPGRES is pegged. MCTA Handoff Call ATTempts MCTHCATT
Sprint PCS
04/22/02
Page 28
Pegged, along with CAUHATTS, when the CAU receives a message from the CM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMA target sector should begin. Field Results Day 1: 0.00 % Day 2: 0.00 % Day 3: 0.00 % Day 4: 0.00 %
Expected Formula Range: It should match the 2G Voice Pre-MCTA Resource Allocation Failures.
3.1.6.1. Detailed 3G Voice Pre-MCTA Resource Allocation Failures (per frequency) Formulas The following set of formulas deal with the percentage of MCTA frequency resource allocation failures resulting due to lack of physical resources before the Carrier Determination Algorithm CDA is executed. Resource Allocation Failures (per freq) due to lack of physical resources: No Rsrc% = [(CAUSCT3V.MCTALLFU + CAURFQ3V.MCTARQFN + CAUFRQ3V.MCTAREQN) / (CAUFRQ3V.MCTORIGS + CAUFRQ3V.MCTPGRES + CAUFRQ3V.MCTHCATT)] * 100 Case 1: Failures leading to overall MCTA frequency selection failure (BLOCK) No Rsrc% = [(CAUSCT3V.MCTALLFU + CAURFQ3V.MCTARQFN) / (CAUFRQ3V.MCTORIGS + CAUFRQ3V.MCTPGRES +
Sprint PCS
04/22/02
Page 29
CAUFRQ3V.MCTHCATT)] * 100 Case 2: Failures NOT leading to overall MCTA frequency selection failure No Rsrc% = [CAURFQ3V.MCTAREQN / (CAUFRQ3V.MCTORIGS + CAUFRQ3V.MCTPGRES + CAUFRQ3V.MCTHCATT)] * 100 The following set of formulas deal with the percentage of MCTA frequency resource allocation failures resulting due to time-outs before the Carrier Determination Algorithm CDA is executed. Resource Allocation Failures (per freq) due to time-outs: Time Out% = [(CAUSCT3V.MCTALLTO + (CAUSCT3V.MCTAMIXF CAURFQ3V.MCTARQFN) + CAUFRQ3V.MCTAREQT) / (CAUFRQ3V.MCTORIGS + CAUFRQ3V.MCTPGRES + CAUFRQ3V.MCTHCATT)] * 100
Case 1: Failures leading to overall MCTA frequency selection failure (BLOCK) Time Out% = [(CAUSCT3V.MCTALLTO + (CAUSCT3V.MCTAMIXF CAURFQ3V.MCTARQFN) / (CAUFRQ3V.MCTORIGS + CAUFRQ3V.MCTPGRES + CAUFRQ3V.MCTHCATT)] * 100 Case 2: Failures NOT leading to overall MCTA frequency selection failure Time Out% = [CAUFRQ3V.MCTAREQT / (CAUFRQ3V.MCTORIGS + CAUFRQ3V.MCTPGRES + CAUFRQ3V.MCTHCATT)] * 100 OMs MCTA REQuest response full or Not available MCTAREQN Pegged when a frequency was successfully selected by MCTA but one or more of the BTSs responded with a resource full or not available response. MCTAREQN
is pegged against the carrier(s) that respond with a resource full or not available response. MCTAREQN may not always be pegged under low load conditions. MCTA REQuest Timeout MCTAREQT Pegged when a frequency was successfully selected by MCTA but one or more of the BTSs never responded to a capacity request. MCTAREQT is pegged against the carrier(s) that did not respond to the capacity request. MCTAREQT may not always be pegged under low traffic load conditions. MCTA All frequencies Full MCTALLFU Pegged, along with CAUERSFL and (MCTAREQF or MCTAHRQF), when NO frequency was successfully selected by MCTA because none of the BTSs had resources available. It is pegged on a per-sector basis. MCTA ReQuest response Failed (full or Not available) MCTARQFN Pegged, along with CAUERSFL and MCTAMIXF and (MCTAREQF or MCTAHRQF), when no frequency was successfully selected by MCTA because some BTSs timed out, while some responded with a resource full or not available response. MCTARQFN is pegged against the carrier(s) that respond with a resource full or not available response. MCTA ALL frequencies Timed-Out MCTALLTO Pegged, along with CAUERSFL and (MCTAREQF or MCTAHRQF), when NO frequency was successfully selected by MCTA because none of the BTSs responded to the capacity request query. It is pegged on a per-sector basis. MCTA MIXed Failure MCTAMIXF Pegged, along with CAUERSFL and MCTARQFN and (MCTAREQF or MCTAHRQF), when NO frequency was successfully selected by MCTA because some BTSs timed-out while some responded with a resource full or not available response. It is pegged on a per-sector basis. MCTA ORIGination MCTORIGS Pegged, along with CAUOATTS, when the CAU receives an origination message from a sector that has MCTA enabled. It is pegged against the originating frequency. Test call originations are pegged in a separate OM.
Sprint PCS
04/22/02
Page 31
MCTA PaGe RESponse MCTPGRES For mobile-terminated calls, attempts are recorded in MCTPGRES, which indicates that a page response was received from an MCTA enabled CDMA sector in response to a page request. This OM is pegged irrespective of whether it was the first or the second attempt to page the mobile. CAUPGRES is also pegged whenever MCTPGRES is pegged. MCTA Handoff Call ATTempts MCTHCATT Pegged, along with CAUHATTS, when the CAU receives a message from the CM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMA target sector should begin Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Expected Formula Range: N/A (min and max will be defined where applicable) 3.1.7. 3G Voice Post-MCTA Traffic Distribution (per frequency) This is the percentage of traffic carried on a particular frequency on a sector when compared to the other frequencies on that sector. Formula Traf Dist% = [Calls continued on the given freq / Total number of calls on all freqs] * 100 Calls continued on the given frequency = CAUFRQ3V.MCTOATTS + CAUFRQ3V.MCTTATTS + CAUFRQ3V.MCTHATTS
Sprint PCS
04/22/02
Page 32
Total number of calls on all freqs = CAUFRQ3V.MCTOATTS + CAUFRQ3V.MCTTATTS + CAUFRQ3V.MCTHATTS NOTE: CAUFRQ3V refers to the sum of the register for all frequencies on the sector. OMs MCTA Origination ATTemptS MCTOATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile origination in a sector with MCTA enabled. Please note that the MCTA frequency for MCTOATTS may be different from the MCTA frequency on which the call originated (MCTORIGS). MCTA Termination ATTemptS MCTTATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile termination in a sector with MCTA enabled. MCTA Handoff ATTemptS MCTHATTS Pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile hard handoff attempt into a target sector with MCTA enabled. Field Results: Day 1: Day 2: Day 3: Day 4: Freq1 44 % 44 % 37 % 40 % Freq2 38 % 59 % 50 % 42 % Freq3 17 % 15% 13 % 17 %
Expected Formula Range: It should match the 2G Voice Post-MCTA Traffic Distribution.
Sprint PCS
04/22/02
Page 33
3.1.8. 3G Voice Post-MCTA Call Success (per frequency) This is the percentage of calls that successfully arrived on the traffic channel for a particular frequency. Formula Succ% = [No. of successful calls / Total calls attempted] * 100 No. of successful calls = CAUFRQ3V.MCTOSUCC + CAUFRQ3V.MCTTSUCC + CAUFRQ3V.MCTHSUCC Total calls attempted = CAUFRQ3V.MCTOATTS + CAUFRQ3V.MCTTATTS + CAUFRQ3V.MCTHATTS OMs MCTA Origination SUCCess MCTOSUCC Pegged, along with CAUOSUCC, when a mobile-originated call successfully arrives on the traffic channel. This includes all originations placed on the traffic channel to receive treatment. MCTA Termination SUCCess MCTTSUCC Pegged, along with CAUTSUCC, when a mobile-terminated call successfully arrives on the traffic channel. MCTA Hard-handoff SUCCess MCTHSUCC Pegged, along with CAUHSUCC, when a mobile successfully arrives on the traffic channel after a hard handoff. MCTA Origination ATTemptS MCTOATTS Pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile origination in a sector with MCTA enabled. Please note that the MCTA frequency for MCTOATTS may be different from the MCTA frequency on which the call originated (MCTORIGS).
Sprint PCS
04/22/02
Page 34
MCTA Termination ATTemptS MCTTATTS Pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile termination in a sector with MCTA enabled. MCTA Handoff ATTemptS MCTHATTS Pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile hard handoff attempt into a target sector with MCTA enabled. Field Results: Day 1: Day 2: Day 3: Day 4: Freq1 95 % 94.48 % 94.49 % 94.00 % Freq2 93 % 94.57 % 94.67 % 95.00 % Freq3 96 % 94.75 % 95.33 % 94.50 %
Expected Formula Range: It should match the 2G Voice Post-MCTA Call Success
3.1.9. 3G Voice Post-MCTA Call Blocks (per frequency) This is the percentage of calls blocked after the MCTA frequency has been selected and the call setup is attempted on the selected frequency. Formula Total Blocks% = [Total no. of calls blocked / Total calls attempted] * 100 Total no. of calls blocked = CAUFRQ3V.MCTERSFL Total calls attempted = CAUFRQ3V.MCTOATTS + CAUFRQ3V.MCTTATTS + CAUFRQ3V.MCTHATTS
Sprint PCS
04/22/02
Page 35
OMs MCTA Error case Radio link Setup FaiLure MCTERSFL Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, whenever a call setup fails due to the fact that the BTS could not allocate resources due to any of the BTS failure reasons. This OM is also pegged when the BTS does not respond at all to resource requests. MCTERSFL is pegged only after an MCTA frequency is selected. MCTERSFL is pegged against the selected frequency. MCTA Origination ATTemptS MCTOATTS Pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile origination in a sector with MCTA enabled. Please note that the MCTA frequency for MCTOATTS may be different from the MCTA frequency on which the call originated (MCTORIGS). MCTA Termination ATTemptS MCTTATTS Pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile termination in a sector with MCTA enabled. MCTA Handoff ATTemptS MCTHATTS Pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile hard handoff attempt into a target sector with MCTA enabled. Field Results: Day 1: Day 2: Day 3: Day 4: Freq1 0.00 % 0.00 % 0.00 % 0.00 % Freq2 0.00 % 0.00 % 0.00 % 0.00 % Freq3 0.00 % 0.00 % 0.00 % 0.00 %
Expected Formula Range:
Sprint PCS
04/22/02
Page 36
It should match the 2G Voice Post-MCTA Call Blocks 3.1.9.1. Detailed 3G Voice Post-MCTA Call Blocks (per frequency) The following formulas deal with those calls that are blocked after the MCTA frequency has been selected and the call setup is attempted on the selected frequency. Formulas Blocks due to lack of traffic channel elements: TCE% = [CAUFRQ3V.MCTNOTCE / (CAUFRQ3V.MCTOATTS + CAUFRQ3V.MCTTATTS + CAUFRQ3V.MCTHATTS)] * 100 Blocks due to lack of Walsh codes: WCD% = [CAUFRQ3V.MCTNOWCD / (CAUFRQ3V.MCTOATTS + CAUFRQ3V.MCTTATTS + CAUFRQ3V.MCTHATTS)] * 100 Blocks due to no frame offset availability: Frame Offset% = [CAUFRQ3V.MCTNOFOF / (CAUFRQ3V.MCTOATTS + CAUFRQ3V.MCTTATTS + CAUFRQ3V.MCTHATTS)] * 100 Blocks due to lack of forward capacity: FWDCAP% = [CAUFRQ3V.MCTFWCAP / (CAUFRQ3V.MCTOATTS + CAUFRQ3V.MCTTATTS + CAUFRQ3V.MCTHATTS)] * 100 Blocks due to lack of reverse capacity: REVCAP% = [CAUFRQ3V.MCTRECAP / (CAUFRQ3V.MCTOATTS + CAUFRQ3V.MCTTATTS + CAUFRQ3V.MCTHATTS)] * 100 OMs
Sprint PCS
04/22/02
Page 37
MCTA NO Traffic Channel Element MCTNOTCE Pegged, along with MCTERSFL and CAUNOTCE and CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports no traffic channel element via NOIS messages, regardless of origination, termination or hard handoff. MCTNOTCE is pegged only after an MCTA frequency is selected. MCTNOTCE is pegged against the selected frequency. MCTA NO Walsh Code MCTNOWCD Pegged, along with MCTERSFL and CAUNOWCD and CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports no walsh code via NOIS messages, regardless of origination, termination or hard handoff. MCTNOWCD is pegged only after an MCTA frequency is selected. MCTNOWCD is pegged against the selected frequency. MCTA NO Frame Offset MCTNOFOF Pegged, along with MCTERSFL and CAUNOFOF and CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS cannot allocate resources due to some CSM 5000 hardware limitation. The CSM 5000 is limited in how much traffic it can support on its reverse link because of the limitation on the number of decoding units (both Viterbi and Turbo) that can be active on a frame offset (and adjacent frame offsets). MCTNOFOF is pegged only after an MCTA frequency is selected. MCTNOFOF is pegged against the selected frequency MCTA ForWard CAPacity full MCTFWCAP Pegged, along with MCTERSFL and CAUFWCAP and CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports forward capacity full via NOIS messages, regardless of origination, termination or hard handoff. MCTFWCAP is pegged only after an MCTA frequency is selected. MCTFWCAP is pegged against the selected frequency. MCTA REverse CAPacity full MCTRECAP Pegged, along with MCTERSFL and CAURECAP and CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports reverse capacity full via NOIS messages, regardless of origination, termination or hard handoff. However, currently there is no reliable mechanism for estimating reverse link capacity. Consequently, this OM should never be pegged. MCTA Origination ATTemptS MCTOATTS
Sprint PCS
04/22/02
Page 38
Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile origination in a sector with MCTA enabled. Please note that the MCTA frequency for MCTOATTS may be different from the MCTA frequency on which the call originated (MCTORIGS). MCTA Termination ATTemptS MCTTATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile termination in a sector with MCTA enabled. MCTA Handoff ATTemptS MCTHATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile hard handoff attempt into a target sector with MCTA enabled. Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Expected Formula Range: N/A (min and max will be defined where applicable)
3.1.10. 3G Voice Post-MCTA Access Failures (per frequency) This is the percentage of access failures after the MCTA frequency has been selected and resources are successfully setup on the selected frequency. Formula Acc Fails% = [Number of MCTA access failures / Total calls attempted] * 100
Sprint PCS
04/22/02
Page 39
Number of MCTA access failures = CAURFQ3V.MCTERLFL + CAUFRQ3V.MCTHRLFL Total calls attempted = CAUFRQ3V.MCTOATTS + CAUFRQ3V.MCTTATTS + CAUFRQ3V.MCTHATTS OMs MCTA Error case, Radio Link FaiLure MCTERLFL Pegged, along with CAUERLFL, if the origination or termination fails because the mobile never arrived on the traffic channel (similar to SAT timeout). MCTERLFL is not pegged in cases where the CAUOBLKS or CAUTBLKS OMs are pegged. MCTA hard Handoff Radio Link FaiLure MCTHRLFL Pegged, along with CAUHRLFL, if the hard handoff attempt fails because the mobile never arrived on the target sectors traffic channel (similar to SAT timeout). MCTHRLFL is not pegged in cases where the CAUHBLKS OM is pegged. MCTA Origination ATTemptS MCTOATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile origination in a sector with MCTA enabled. Please note that the MCTA frequency for MCTOATTS may be different from the MCTA frequency on which the call originated (MCTORIGS). MCTA Termination ATTemptS MCTTATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile termination in a sector with MCTA enabled. MCTA Handoff ATTemptS MCTHATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile hard handoff attempt into a target sector with MCTA enabled.
Sprint PCS
04/22/02
Page 40
Field Results: Day 1: Day 2: Day 3: Day 4:
Freq1 1.44 % 1.84 % 1.78 % 1.53 %
Freq2 2.71 % 2.50 % 1.95 % 1.74 %
Freq3 1.39 % 2.12 % 2.33 % 1.85 %
Expected Formula Range: It should match the 2G Voice Post-MCTA Access Failures 3.1.10.1. Detailed 3G Voice Post-MCTA Access Failures (per frequency) The following formulas deal with those access failures that take place after the MCTA frequency has been selected and resources are successfully setup on the selected frequency. Formulas Access failures during originations or terminations: Orig & Term% = [CAURFQ3V.MCTERLFL / (CAUFRQ3V.MCTOATTS + CAUFRQ3V.MCTTATTS)] * 100 Access failures during hard handoffs: Handoff% = [CAURFQ3V.MCTHRLFL / CAUFRQ3V.MCTHATTS] *100 OMs MCTA Error case, Radio Link FaiLure MCTERLFL Pegged, along with CAUERLFL, if the origination or termination fails because the mobile never arrived on the traffic channel (similar to SAT timeout). MCTERLFL is not pegged in cases where the CAUOBLKS or CAUTBLKS OMs are pegged. MCTA hard Handoff Radio Link FaiLure MCTHRLFL
Pegged, along with CAUHRLFL, if the hard handoff attempt fails because the mobile never arrived on the target sectors traffic channel (similar to SAT timeout). MCTHRLFL is not pegged in cases where the CAUHBLKS OM is pegged. MCTA Origination ATTemptS MCTOATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile origination in a sector with MCTA enabled. Please note that the MCTA frequency for MCTOATTS may be different from the MCTA frequency on which the call originated (MCTORIGS). MCTA Termination ATTemptS MCTTATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile termination in a sector with MCTA enabled. MCTA Handoff ATTemptS MCTHATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile hard handoff attempt into a target sector with MCTA enabled. Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Sprint PCS
04/22/02
Page 42
3.1.11. 3G Voice frequency)
Post-MCTA
RF
related
Drop
Calls
(per
This is the percentage of established calls on each frequency in MCTA enabled sectors that are dropped due to RF related issues. Formula Drop Call% = [Number of RF related drop calls / Number of successful calls] * 100 Number of RF related drop calls = CAUFRQ3V.MCTDROPR Number of successful calls = CAUFRQ3V.MCTOSUCC + CAUFRQ3V.MCTTSUCC + CAUFRQ3V.MCTHSUCC OMs MCTA DROPped call Rf MCTDROPR Pegged, along with CAUDROPR, when a call is dropped by the SBS due to loss of traffic or due to HCM (handoff completion message) timeout for soft or softer handoff. These are RF-related call failures as detected by the SBS. CAU DROPped call Network CAUDROPN Pegged by the CAU when any of the other (non-RF) drop indication reasons are sent from the SBS in the radio link drop indication message. MCTA Origination SUCCess MCTOSUCC Pegged, along with CAUOSUCC, when a mobile-originated call successfully arrives on the traffic channel. This includes all originations placed on the traffic channel to receive treatment. MCTA Termination SUCCess MCTTSUCC Pegged, along with CAUTSUCC, when a mobile-terminated call successfully arrives on the traffic channel. MCTA Hard-handoff SUCCess
Sprint PCS
04/22/02
Page 43
MCTHSUCC Pegged, along with CAUHSUCC, when a mobile successfully arrives on the traffic channel after a hard handoff. Field Results: Day 1: Day 2: Day 3: Day 4: Freq1 2.98 % 3.24 % 2.87 % 2.01 % Freq2 1.49 % 1.43 % 1.21 % 1.34 % Freq3 1.03 % 1.31 % 1.08 % 1.03 %
Expected Formula Range: It should match the 2G Voice Post-MCTA RF related Drop Calls
3.2. Performance Formulas for 3G Fundamental Channel Data

3.2.1. 3G Packet Data Call Success Formula Call Succ% = [Number of successful calls / Total calls Attempted] * 100 Number of successful calls = CAUSCT3D.CAUOSUCC + CAUSCT3D.CAUTSUCC + CAUSCT3D.CAUHSUCC Total calls Attempted = CAUSCT3D.CAUOATTS + CAUSCT3D.CAUPGRES + CAUSCT3D.CAUHATTS OMs CAU Origination SUCCess CAUOSUCC Pegged when a mobile-originated call successfully arrives on the traffic channel. This includes all originations placed on the traffic channel to receive treatment.
Sprint PCS
04/22/02
Page 44
CAU Termination SUCCess CAUTSUCC Pegged when a mobile-terminated call successfully arrives on the traffic channel. CAU hard Handoff SUCCess CAUHSUCC Pegged when a mobile, attempting a hard handoff, successfully arrives on the traffic channel in the target sector. CAU Origination ATTemptS CAUOATTS Pegged when the CAU receives an origination message from the BTS. Test call originations are pegged in a separate OM. CAU PaGe RESponse CAUPGRES For mobile-terminated calls, attempts are recorded in CAUPGRES, which indicates that a page response was received from a CDMA sector in response to a page request (irrespective of whether it was in response to an initial page request or a retry by the CM). CAU hard Handoff ATTemptS CAUHATTS Pegged when the CAU receives a ReadyNewCell message from the CM, indicating that a hard handoff attempt sequence in a (CDMA) target sector should begin. Field Results Day 1: 81.87 % Day 2: 70.09 % Day 3: 84.01 % Day 4: 82.78 %
Expected Formula Range: It should match the 3G Voice Call Success.
Sprint PCS
04/22/02
Page 45
3.2.2. 3G Packet Data Total Blocks Formula Total Blocks% = [Total number of blocked calls / Total calls attempted] * 100 Total number of blocked calls = CAUSCT3D.CAUOBLKS + CAUSCT3D.CAUTBLKS + CAUSCT3D.CAUHBLKS Total calls attempted CAUSCT3D.CAUOATTS + CAUSCT3D.CAUPGRES + CAUSCT3D.CAUHATTS OMs CAU Origination BLocKS CAUOBLKS Pegged any time a mobile-originated call setup fails due to resource shortage. It represents the total number of origination setup failures in a sector, regardless of resource. The same failure reasons that are pegged for CAUTBLKS can be pegged in conjunction with CAUOBLKS. CAU Termination BLocKS CAUTBLKS Pegged any time a mobile-terminated call setup fails due to resource shortage. It represents all of the termination setup failures in a sector, regardless of resource. One or more of the following call setup failure reasons is pegged in conjunction with CAUTBLKS: RMNORREQ, RMSRMNAK, RMSRMTO, CAUERSFL, CAUNOTCE, CAUNOWCD, CAUNOFOF, CAUFWCAP, CAURECAP and CAUESWFL. CAU hard Handoff BLocKS CAUHBLKS Pegged any time a CDMA-to-CDMA hard handoff setup fails due to resource shortage. It represents all of the hard handoff setup failures into a sector, regardless of resource. This OM is pegged for both inter- and intra-system hard handoff attempts. CAUHBLKS is not the number of dropped hard handoffs, it merely represents the number of times that a hard handoff could not be completed due to resource shortages in the target cell/sectorthe call in the source cell is
Sprint PCS
04/22/02
Page 46
still up. The same failure reasons that are pegged for CAUOBLKS (see previous page) can be pegged in conjunction with CAUHBLKS. CAU Origination ATTemptS CAUOATTS Pegged when the CAU receives an origination message from the BTS. Test call originations are pegged in a separate OM. CAU PaGe RESponse CAUPGRES For mobile-terminated calls, attempts are recorded in CAUPGRES, which indicates that a page response was received from a CDMA sector in response to a page request (irrespective of whether it was in response to an initial page request or a retry by the CM). CAU hard Handoff ATTemptS CAUHATTS Pegged when the CAU receives a ReadyNewCell message from the CM, indicating that a hard handoff attempt sequence in a (CDMA) target sector should begin. Field Results Day 1: 3.72 % Day 2: 0.00 % Day 3: 0.08 % Day 4: 0.00 %
Expected Formula Range: It should match the 3G Voice Total Blocks. 3.2.2.1. Detailed 3G Packet Data Blocks The following formulas are currently not supported by the ePerformance tool. For frequency level information, please refer Section 3.2.10.1 Formulas
Sprint PCS
04/22/02
Page 47
Blocks due to origination setup failures: Orig% = [CAUSCT3D.CAUOBLKS / CAUSCT3D.CAUOATTS] * 100 Blocks due to termination setup failures: Term% = [CAUSCT3D.CAUTBLKS / CAUSCT3D.CAUPGRES] * 100 Blocks due to hard handoff setup failures: Handoff% = [CAUSCT3D.CAUHBLKS / CAUSCT3D.CAUHATTS] * 100 Blocks due to lack of traffic channel elements: TCE% = [CAUSCT3D.CAUNOTCE / (CAUSCT3D.CAUOATTS + CAUSCT3D.CAUPGRES + CAUSCT3D.CAUHATTS)] * 100 Blocks due to lack of walsh codes: WCD% = [CAUSCT3D.CAUNOWCD / (CAUSCT3D.CAUOATTS + CAUSCT3D.CAUPGRES + CAUSCT3D.CAUHATTS)] * 100 Blocks due to no frame offset availability: Frame Offset% = [CAUSCT3D.CAUNOFOF / (CAUSCT3D.CAUOATTS + CAUSCT3D.CAUPGRES + CAUSCT3D.CAUHATTS)] * 100 Blocks due to lack of forward capacity: FWDCAP% = [CAUSCT3D.CAUFWCAP / (CAUSCT3D.CAUOATTS + CAUSCT3D.CAUPGRES + CAUSCT3D.CAUHATTS)] * 100 Blocks due to lack of reverse capacity: REVCAP% = [CAUSCT3D.CAURECAP / (CAUSCT3D.CAUOATTS + CAUSCT3D.CAUPGRES + CAUSCT3D.CAUHATTS)] * 100
Sprint PCS
04/22/02
Page 48
Blocks due to lack of physical resources: Physical Resources% = [(CAURM.NORREQ3D + CAUSCT3D.CAUERSFL) / (CAUSCT3D.CAUOATTS + CAUSCT3D.CAUPGRES + CAUSCT3D.CAUHATTS)] * 100 Blocks due to BTS time-outs: BTS Time-outs% = [(CAUSCT3D.CAUERSFL CAUSCT3D.CAUNOTCE CAUSCT3D.CAUNOWCD CAUSCT3D.CAUFWCAP CAUSCT3D.CAUNOFOF CAUSCT3D.CAURECAP CAUSCT3D.MCTAREQF CAUSCT3D.MCTAHRQF BlockedFchOriginations3Gdata[6]) / (CAUSCT3D.CAUOATTS + CAUSCT3D.CAUPGRES + CAUSCT3D.CAUHATTS)] * 100 Blocks due to BCS time-outs and software faults: BSC Time-outs% = [(CAURM.SRMTO3D + CAURM.SRMNAK3D + CAUSCT3D.CAUESWFL) / (CAUSCT3D.CAUOATTS + CAUSCT3D.CAUPGRES + CAUSCT3D.CAUHATTS)] * 100 OMs CAU Origination BLocKS CAUOBLKS Pegged any time a mobile-originated call setup fails due to resource shortage. It represents the total number of origination setup failures in a sector, regardless of resource. The same failure reasons that are pegged for CAUTBLKS can be pegged in conjunction with CAUOBLKS. CAU Termination BLocKS CAUTBLKS
Sprint PCS
04/22/02
Page 49
Pegged any time a mobile-terminated call setup fails due to resource shortage. It represents all of the termination setup failures in a sector, regardless of resource. One or more of the following call setup failure reasons is pegged in conjunction with CAUTBLKS: RMNORREQ, RMSRMNAK, RMSRMTO, CAUERSFL, CAUNOTCE, CAUNOWCD, CAUNOFOF, CAUFWCAP, CAURECAP and CAUESWFL. CAU hard Handoff BLocKS CAUHBLKS Pegged any time a CDMA-to-CDMA hard handoff setup fails due to resource shortage. It represents all of the hard handoff setup failures into a sector, regardless of resource. This OM is pegged for both inter- and intra-system hard handoff attempts. CAUHBLKS is not the number of dropped hard handoffs, it merely represents the number of times that a hard handoff could not be completed due to resource shortages in the target cell/sectorthe call in the source cell is still up. The same failure reasons that are pegged for CAUOBLKS (see previous page) can be pegged in conjunction with CAUHBLKS. CAU NO Traffic Channel Element CAUNOTCE Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports no traffic channel element via NOIS messages, regardless of origination, termination or hard handoff. CAU NO Walsh Code CAUNOWCD Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports no walsh code via NOIS messages, regardless of origination, termination or hard handoff. CAU NO Frame Offset CAUNOFOF Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS cannot allocate resources due to some CSM 5000 hardware limitation. The CSM 5000 is limited in how much traffic it can support on its reverse link because of the limitation on the number of decoding units (both Viterbi and Turbo) that an be active on a frame offset (and adjacent frame offsets). CAU ForWard CAPacity full CAUFWCAP Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports forward capacity full via NOIS messages, regardless of origination, termination or hard handoff.
CAU REverse CAPacity full CAURECAP Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports reverse capacity full via NOIS messages, regardless of origination, termination or hard handoff. However, currently there is no reliable mechanism for estimating reverse link capacity and so this response is disabled on the BTS. Consequently, this OM is never pegged. NO Resources for REQuest for 3G Data calls NORREQ3D Pegged only in cases of 3G Packet Data calls. NORREQ3D is pegged, along with the appropriate CAU*BLKS OM, when Resource Manager (RM) has no available resources to allocate for a call. In this case, the RM does not message to any of its SBSs to determine availability, only internal data structures are checked. CAU Error case, Radio Setup FaiLure CAUERSFL Pegged, along with the appropriate CAU*BLKS OM, whenever a call setup fails due to the fact that some BTS resource is not available. This OM is also pegged when the BTS does not respond to resource requests. It is also pegged when the Carrier Determination Algorithm (CDA) fails to select a carrier in an MCTA enabled sector (that is, no available capacity on all co-located carriers). MCTA REQuest Failure MCTAREQF Pegged, along with CAUERSFL, when NO frequency was successfully selected by MCTA for origination or termination call setup. It is pegged on a per-sector basis. The failure reasons are pegged by MCTAMIXF, MCTALLTO or MCTALLFU. MCTA Handoff ReQuest Failure MCTAHRQF Pegged, along with CAUERSFL, when NO frequency was successfully selected by MCTA for a hard handoff call setup. It is pegged on a per-sector basis on the target side. The failure reasons are pegged by MCTAMIXF, MCTALLTO or MCTALLFU. Blocked Fch Originations 3G Data BlockedFchOriginations3GData Array indicating the number of 3G data sessions blocked on the fundamental channel. Each array element corresponds to a different blocking reason.
Sprint PCS
04/22/02
Page 51
SRM Time-Out for 3G Data calls SRMTO3D Pegged only in cases of 3G Packet Data calls. SRMTO3D is pegged, along with the appropriate CAU*BLKS OM, when Resource Manager times out waiting on a request for call resources from the SRM. Service Resource Manager Negative AcK for 3G Data calls SRMNAK3D Pegged only in cases of 3G Packet Data calls. SRMNAK3D is pegged, along with the appropriate CAU*BLKS OM, when Resource Manager (RM) receives a resource allocation failure indication from SRMs. This is an error condition, indicating mismatches between the RM and the SBS SRM. CAU Error case, SoftWare FauLt CAUESWFL Pegged, along with the appropriate CAU*BLKS OM, whenever a call setup fails due to time outs between software entities that should not occur (for example, no response from the CM, failure message received from SBS, etc.). CAU Origination ATTemptS CAUOATTS Pegged when the CAU receives an origination message from the BTS. Test call originations are pegged in a separate OM. CAU PaGe RESponse CAUPGRES For mobile-terminated calls, attempts are recorded in CAUPGRES, which indicates that a page response was received from a CDMA sector in response to a page request (irrespective of whether it was in response to an initial page request or a retry by the CM). CAU hard Handoff ATTemptS CAUHATTS Pegged when the CAU receives a ReadyNewCell message from the CM, indicating that a hard handoff attempt sequence in a (CDMA) target sector should begin. Field Results: Orig Day 1: Day 2: Term HandO TCE WalshC NframO FwdC
example example
Sprint PCS
04/22/02
Page 52
Day 3: Day 4:
example example
Field Results: RevC PhyR Day 1: Day 2: Day 3: Day 4: example example example example
BTSt-o
BSCt-o
Expected Formula Range: N/A (min and max will be defined where applicable) 3.2.3. 3G Packet Data Access Failure Formula Acc Fails% = [Number of access failures / Total calls attempted] * 100 Number of access failures = CAUSCT3D.CAUERLFL + CAUSCT3D.CAUHRLFL Total calls attempted = CAUSCT3D.CAUOATTS + CAUSCT3D.CAUPGRES + CAUSCT3D.CAUHATTS NOTE: The attempt to set up the R-P packet session is done after the mobile arrives on the traffic channel but before sending the service connect message out to the mobile. Thus if the R-P packet session setup fails, it will still be pegged as an access failure. The TotalSessionSetupFailures (Number of failed packet session setups) count can be subtracted from the numerator in the above formula when measuring the RF Access Failure rate on a system wide basis. OMs
Sprint PCS
04/22/02
Page 53
CAU Error Radio Link FaiLure CAUERLFL Pegged if the origination or termination fails because the mobile never arrived on the traffic channel (similar to SAT timeout). CAUERLFL is not pegged in cases where the CAUOBLKS or CAUTBLKS OMs are pegged. CAU hard Handoff Radio Link FaiLure CAUHRLFL Pegged if the hard handoff attempt fails because the mobile never arrived on the target sectors traffic channel (similar to SAT timeout). CAUHRLFL is not pegged in cases where CAUHBLKS is pegged. CAU Origination ATTemptS CAUOATTS Pegged when the CAU receives an origination message from the BTS. Test call originations are pegged in a separate OM. CAU PaGe RESponse CAUPGRES For mobile-terminated calls, attempts are recorded in CAUPGRES, which indicates that a page response was received from a CDMA sector in response to a page request (irrespective of whether it was in response to an initial page request or a retry by the CM). CAU hard Handoff ATTemptS CAUHATTS Pegged when the CAU receives a ReadyNewCell message from the CM, indicating that a hard handoff attempt sequence in a (CDMA) target sector should begin. Field Results Day 1: 3.19 % Day 2: 6.49 % Day 3: 3.57 % Day 4: 3.39 %
Sprint PCS
04/22/02
Page 54
It should match the 3G Voice Access Failures. 3.2.3.1. Detailed 3G Packet Data Access Failures The following formulas are currently not supported by the ePerformance tool. For frequency level information, please refer Section 3.2.11.1. Formulas Access failures during originations or terminations: Orig & Term% = [CAUSCT3D.CAUERLFL / (CAUSCT3D.CAUOATTS + CAUSCT3D.CAUPGRES)] * 100 Access failures during hard handoffs: Handoff% = [CAUSCT3D.CAUHRLFL / CAUSCT3D.CAUHATTS)] * 100 OMs CAU Error Radio Link FaiLure CAUERLFL Pegged if the origination or termination fails because the mobile never arrived on the traffic channel (similar to SAT timeout). CAUERLFL is not pegged in cases where the CAUOBLKS or CAUTBLKS OMs are pegged. CAU hard Handoff Radio Link FaiLure CAUHRLFL Pegged if the hard handoff attempt fails because the mobile never arrived on the target sectors traffic channel (similar to SAT timeout). CAUHRLFL is not pegged in cases where CAUHBLKS is pegged. CAU Origination ATTemptS CAUOATTS Pegged when the CAU receives an origination message from the BTS. Test call originations are pegged in a separate OM. CAU PaGe RESponse CAUPGRES For mobile-terminated calls, attempts are recorded in CAUPGRES, which indicates that a page response was received from a CDMA sector in response to a page request (irrespective of whether it was in response to an initial page request or a retry by the CM).
Sprint PCS
04/22/02
Page 55
CAU hard Handoff ATTemptS CAUHATTS Pegged when the CAU receives a ReadyNewCell message from the CM, indicating that a hard handoff attempt sequence in a (CDMA) target sector should begin. Field Results: Orig&Term Day 1: example Day 2: example Day 3: example Day 4: example Hard Handoff
Expected Formula Range: N/A (min and max will be defined where applicable) 3.2.4. 3G Packet Data Drop Calls Formula Drop Call% = [Number of drop calls / Number of successful calls] * 100 Number of drop calls = CAUSCT3D.CAUDROPR + CAUSCT3D.CAUDROPN Number of successful calls = CAUSCT3D.CAUOSUCC + CAUSCT3D.CAUTSUCC + CAUSCT3D.CAUHSUCC OMs CAU DROPped call Rf CAUDROPR Pegged by the CAU against the reference pilot when a call is dropped by the SBS due to loss of traffic or due to HCM (handoff completion message) timeout
Sprint PCS
04/22/02
Page 56
for soft or softer handoff. These are RF-related call failures as detected by the SBS. CAU DROPped call Network CAUDROPN Pegged by the CAU when any of the other (non-RF) drop indication reasons are sent from the SBS in the radio link drop indication message. CAU Origination SUCCess CAUOSUCC Pegged when a mobile-originated call successfully arrives on the traffic channel. This includes all originations placed on the traffic channel to receive treatment. CAU Termination SUCCess CAUTSUCC Pegged when a mobile-terminated call successfully arrives on the traffic channel. CAU hard Handoff SUCCess CAUHSUCC Pegged when a mobile, attempting a hard handoff, successfully arrives on the traffic channel in the target sector. Field Results Day 1: 3.24 % Day 2: 1.35 % Day 3: 2.89 % Day 4: 1.21 %
Expected Formula Range: It should match 3G Voice Drops Calls 3.2.4.1. Detailed 3G Packet Data Drop Calls (These formulas are not currently supported by the ePerformance tool) Formulas Drops due to RF-related reasons:
Sprint PCS
04/22/02
Page 57
RF% = [CAUSCT3D.CAUDROPR / (CAUSCT3D.CAUOSUCC + CAUSCT3D.CAUTSUCC + CAUSCT3D.CAUHSUCC)] * 100 Drops due to network-related reasons: Ntwk% = [CAUSCT3D.CAUDROPN / (CAUSCT3D.CAUOSUCC + CAUSCT3D.CAUTSUCC + CAUSCT3D.CAUHSUCC)] * 100 OMs CAU DROPped call Rf CAUDROPR Pegged by the CAU against the reference pilot when a call is dropped by the SBS due to loss of traffic or due to HCM (handoff completion message) timeout for soft or softer handoff. These are RF-related call failures as detected by the SBS. CAU DROPped call Network CAUDROPN Pegged by the CAU when any of the other (non-RF) drop indication reasons are sent from the SBS in the radio link drop indication message. CAU Origination SUCCess CAUOSUCC Pegged when a mobile-originated call successfully arrives on the traffic channel. This includes all originations placed on the traffic channel to receive treatment. CAU Termination SUCCess CAUTSUCC Pegged when a mobile-terminated call successfully arrives on the traffic channel. CAU hard Handoff SUCCess CAUHSUCC Pegged when a mobile, attempting a hard handoff, successfully arrives on the traffic channel in the target sector. Field Results: RF-related Day 1: example Network-related
Sprint PCS
04/22/02
Page 58
Day 2: example Day 3: example Day 4: example
Expected Formula Range: N/A (min and max will be defined where applicable) 3.2.5. 3G Packet Data Average Rate Formula Dormant to Active Transition% = [No. of dormant to active transition / Total original 3G packet data call attempts] * 100 No. of dormant to active transition = CDMAPDOM.MIDTOAAT + CDMAPDOM.NIDTOAAT Total original 3G packet data call attempts = CAUSCT3D.CAUOATTS + CAUSCT3D.CAUPGRES + CAUSCT3D.CAUHATTS OMs Mobile-Initiated Dormant To Active ATtempts MIDTOAAT Pegged when the MSC receives an origination message from a mobile which is in a dormant data call state. Network-Initiated Dormant To Active ATtempts NIDTOAAT Pegged when the MSC receives a PCU_Page_Request after the network DCR PLICF decides to make the transition to active state. CAU Origination ATTemptS CAUOATTS Calls Dormant to Active Transition
Sprint PCS
04/22/02
Page 59
Pegged when the CAU receives an origination message from the BTS. Test call originations are pegged in a separate OM. CAU PaGe RESponse CAUPGRES For mobile-terminated calls, attempts are recorded in CAUPGRES, which indicates that a page response was received from a CDMA sector in response to a page request (irrespective of whether it was in response to an initial page request or a retry by the CM). CAU hard Handoff ATTemptS CAUHATTS Pegged when the CAU receives a ReadyNewCell message from the CM, indicating that a hard handoff attempt sequence in a (CDMA) target sector should begin. Field Results Day 1: 36.56 % Day 2: 13.33 % Day 3: 51.95 % Day 4: 42.23 %
Expected Formula Range: N/A 3.2.6. 3G Data Pre-MCTA Frequency Selection Failures This section deals with failures that occur before the Carrier Determination Algorithm (CDA) has selected a frequency. The following formula captures call failures due to failure to select a frequency: Formula Freq. Sel. Fail% = [No. of Freq. Sel. Fail / Total calls attempts for all freqs] * 100 No. of Freq. Sel. Fail. = CAUSCT3D.MCTAREQF +
Sprint PCS
04/22/02
Page 60
CAUSCT3D.MCTAHRQF Total calls attempts for all freqs = CAUFRQ3D.MCTORIGS + CAUFRQ3D.MCTPGRES + CAUFRQ3D.MCTHCATT NOTE: CAUFRQ3D refers to the sum of the register for all frequencies on the sector. OMs MCTA REQuest Failure MCTAREQF Pegged, along with CAUERSFL, when NO frequency was successfully selected by MCTA for origination or termination call setup. It is pegged on a per-sector basis. The failure reasons are pegged by MCTAMIXF, MCTALLTO or MCTALLFU. MCTA Handoff ReQuest Failure MCTAHRQF Pegged, along with CAUERSFL, when NO frequency was successfully selected by MCTA for a hard handoff call setup. It is pegged on a per-sector basis on the target side. The failure reasons are pegged by MCTAMIXF, MCTALLTO or MCTALLFU. MCTA ORIGination MCTAORIG Pegged, along with CAUOATTS, when the CAU receives an origination message from a sector that has MCTA enabled. It is pegged against the originating frequency. Test call originations are pegged in a separate OM. MCTA PaGe RESponse MCTAPGRES For mobile-terminated calls, attempts are recorded in MCTPGRES, which indicates that a page response was received from an MCTA enabled CDMA sector in response to a page request. This OM is pegged irrespective of whether it was the first or the second attempt to page the mobile. CAUPGRES is also pegged whenever MCTPGRES is pegged. MCTA Handoff Call ATTempts MCTHCATT
Sprint PCS
04/22/02
Page 61
Pegged, along with CAUHATTS, when the CAU receives a message from the CM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMA target sector should begin. Field Results Day 1: 1.98 % Day 2: 0.98 % Day 3: 0.72 % Day 4: 1.03 %
Expected Formula Range: It should match the 3G Voice Pre-MCTA Frequency Selection Failures 3.2.7. 3G Data Pre-MCTA Resource Allocation Failures (per frequency) This section deals with the events where a particular frequency responds with a resource full response or times out in response to a capacity query request before the Carrier Determination Algorithm (CDA) is executed. Note that this event may or may not lead to overall MCTA frequency selection failure depending on whether all other frequencies respond with a similar response or not. If at least one frequency responds with a resource available response then the CDA will successfully select a carrier for the call attempt. Formula MCTA frequency resource allocation failures (per frequency) % = [No. of MCTA freq rsrc alloc failures / Total MCTA calls attempted] * 100 No. of MCTA freq resource allocation failures = CAUSCT3D.MCTAREQF + CAUSCT3D.MCTAHRQF + CAUFRQ3D.MCTAREQN + CAUFRQ3D.MCTAREQT Total MCTA calls attempted = CAUFRQ3D.MCTORIGS + CAUFRQ3D.MCTPGRES +
Sprint PCS
04/22/02
Page 62
CAUFRQ3D.MCTHCATT OMs MCTA REQuest Failure MCTAREQF Pegged, along with CAUERSFL, when NO frequency was successfully selected by MCTA for origination or termination call setup. It is pegged on a per-sector basis. The failure reasons are pegged by MCTAMIXF, MCTALLTO or MCTALLFU. MCTA Handoff ReQuest Failure MCTAHRQF Pegged, along with CAUERSFL, when NO frequency was successfully selected by MCTA for a hard handoff call setup. It is pegged on a per-sector basis on the target side. The failure reasons are pegged by MCTAMIXF, MCTALLTO or MCTALLFU. MCTA REQuest response full or Not available MCTAREQN Pegged when a frequency was successfully selected by MCTA but one or more of the BTSs responded with a resource full or not available response. MCTAREQN is pegged against the carrier(s) that respond with a resource full or not available response. MCTAREQN may not always be pegged under low load conditions. MCTA REQuest Timeout MCTAREQT Pegged when a frequency was successfully selected by MCTA but one or more of the BTSs never responded to a capacity request. MCTAREQT is pegged against the carrier(s) that did not respond to the capacity request. MCTAREQT may not always be pegged under low traffic load conditions. MCTA ORIGination MCTAORIG Pegged, along with CAUOATTS, when the CAU receives an origination message from a sector that has MCTA enabled. It is pegged against the originating frequency. Test call originations are pegged in a separate OM. MCTA PaGe RESponse MCTAPGRES For mobile-terminated calls, attempts are recorded in MCTPGRES, which indicates that a page response was received from an MCTA enabled CDMA sector in response to a page request. This OM is pegged irrespective of whether it
was the first or the second attempt to page the mobile. CAUPGRES is also pegged whenever MCTPGRES is pegged. MCTA Handoff Call ATTempts MCTHCATT Pegged, along with CAUHATTS, when the CAU receives a message from the CM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMA target sector should begin. Field Results Day 1: 0.00 % Day 2: 0.00 % Day 3: 0.00 % Day 4: 0.00 %
Expected Formula Range: It should match the 3G Voice Pre-MCTA Resource Allocation Failures 3.2.7.1. Detailed 3G Data Pre-MCTA Resource Allocation Failures (per frequency) Formulas The following set of formulas deal with the percentage of MCTA frequency resource allocation failures resulting due to lack of physical resources before the Carrier Determination Algorithm CDA is executed. Resource Allocation Failures (per freq) due to lack of physical resources: No Rsrc% = [(CAUSCT3D.MCTALLFU + CAURFQ3D.MCTARQFN + CAUFRQ3D.MCTAREQN) / (CAUFRQ3D.MCTORIGS + CAUFRQ3D.MCTPGRES + CAUFRQ3D.MCTHCATT)] * 100 Case 1: Failures leading to overall MCTA frequency selection failure (BLOCK)
Sprint PCS
04/22/02
Page 64
No Rsrc% = [(CAUSCT3D.MCTALLFU + CAURFQ3D.MCTARQFN) / (CAUFRQ3D.MCTORIGS + CAUFRQ3D.MCTPGRES + CAUFRQ3D.MCTHCATT)] * 100 Case 2: Failures NOT leading to overall MCTA frequency selection failure No Rsrc% = [CAURFQ3D.MCTAREQN / (CAUFRQ3D.MCTORIGS + CAUFRQ3D.MCTPGRES + CAUFRQ3D.MCTHCATT)] * 100 The following set of formulas deal with the percentage of MCTA frequency resource allocation failures resulting due to time-outs before the Carrier Determination Algorithm CDA is executed. Resource Allocation Failures (per freq) due to time-outs: Time Out% = [(CAUSCT3D.MCTALLTO + (CAUSCT3D.MCTAMIXF CAURFQ3D.MCTARQFN) + CAUFRQ3D.MCTAREQT) / (CAUFRQ3D.MCTORIGS + CAUFRQ3D.MCTPGRES + CAUFRQ3D.MCTHCATT)] * 100
Case 1: Failures leading to overall MCTA frequency selection failure (BLOCK) Time Out% = [(CAUSCT3D.MCTALLTO + (CAUSCT3D.MCTAMIXF CAURFQ3D.MCTARQFN) / (CAUFRQ3D.MCTORIGS + CAUFRQ3D.MCTPGRES + CAUFRQ3D.MCTHCATT)] * 100 Case 2: Failures NOT leading to overall MCTA frequency selection failure Time Out% = [CAUFRQ3D.MCTAREQT / (CAUFRQ3D.MCTORIGS + CAUFRQ3D.MCTPGRES + CAUFRQ3D.MCTHCATT)] * 100
Sprint PCS
04/22/02
Page 65
OMs MCTA REQuest response full or Not available MCTAREQN Pegged when a frequency was successfully selected by MCTA but one or more of the BTSs responded with a resource full or not available response. MCTAREQN is pegged against the carrier(s) that respond with a resource full or not available response. MCTAREQN may not always be pegged under low load conditions. MCTA REQuest Timeout MCTAREQT Pegged when a frequency was successfully selected by MCTA but one or more of the BTSs never responded to a capacity request. MCTAREQT is pegged against the carrier(s) that did not respond to the capacity request. MCTAREQT may not always be pegged under low traffic load conditions. MCTA All frequencies Full MCTALLFU Pegged, along with CAUERSFL and (MCTAREQF or MCTAHRQF), when NO frequency was successfully selected by MCTA because none of the BTSs had resources available. It is pegged on a per-sector basis. MCTA ReQuest response Failed (full or Not available) MCTARQFN Pegged, along with CAUERSFL and MCTAMIXF and (MCTAREQF or MCTAHRQF), when no frequency was successfully selected by MCTA because some BTSs timed out, while some responded with a resource full or not available response. MCTARQFN is pegged against the carrier(s) that respond with a resource full or not available response. MCTA ALL frequencies Timed-Out MCTALLTO Pegged, along with CAUERSFL and (MCTAREQF or MCTAHRQF), when NO frequency was successfully selected by MCTA because none of the BTSs responded to the capacity request query. It is pegged on a per-sector basis. MCTA MIXed Failure MCTAMIXF Pegged, along with CAUERSFL and MCTARQFN and (MCTAREQF or MCTAHRQF), when NO frequency was successfully selected by MCTA because some BTSs timed-out while some responded with a resource full or not available response. It is pegged on a per-sector basis. MCTA ORIGination
Sprint PCS
04/22/02
Page 66
MCTORIGS Pegged, along with CAUOATTS, when the CAU receives an origination message from a sector that has MCTA enabled. It is pegged against the originating frequency. Test call originations are pegged in a separate OM. MCTA PaGe RESponse MCTPGRES For mobile-terminated calls, attempts are recorded in MCTPGRES, which indicates that a page response was received from an MCTA enabled CDMA sector in response to a page request. This OM is pegged irrespective of whether it was the first or the second attempt to page the mobile. CAUPGRES is also pegged whenever MCTPGRES is pegged. MCTA Handoff Call ATTempts MCTHCATT Pegged, along with CAUHATTS, when the CAU receives a message from the CM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMA target sector should begin Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Expected Formula Range: N/A (min and max will be defined where applicable) 3.2.8. 3G Data Post-MCTA Traffic Distribution (per frequency) This is the percentage of traffic carried on a particular frequency on a sector when compared to the other frequencies on that sector. Formula Traf Dist% = [Calls continued on the given freq / Total number of calls on all freqs] * 100
Sprint PCS
04/22/02
Page 67
Calls continued on the given frequency = CAUFRQ3D.MCTOATTS + CAUFRQ3D.MCTTATTS + CAUFRQ3D.MCTHATTS Total number of calls on all freqs = CAUFRQ3D.MCTOATTS + CAUFRQ3D.MCTTATTS + CAUFRQ3D.MCTHATTS NOTE: CAUFRQ3D refers to the sum of the register for all frequencies on the sector. OMs MCTA Origination ATTemptS MCTOATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile origination in a sector with MCTA enabled. Please note that the MCTA frequency for MCTOATTS may be different from the MCTA frequency on which the call originated (MCTORIGS). MCTA Termination ATTemptS MCTTATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile termination in a sector with MCTA enabled. MCTA Handoff ATTemptS MCTHATTS Pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile hard handoff attempt into a target sector with MCTA enabled. Field Results: Day 1: Day 2: Day 3: Day 4: Freq1 35.14 % 26.52 % 39.03 % 36.00 % Freq2 36.82 % 43.86 % 31.59 % 38.00 % Freq3 28.04 % 32.43 % 29.38 % 24.00 %
Sprint PCS
04/22/02
Page 68
Expected Formula Range: It should match the 3G Voice Post-MCTA Traffic Distribution.
3.2.9. 3G Data Post-MCTA Call Success (per frequency) This is the percentage of calls that successfully arrived on the traffic channel for a particular frequency. Formula Succ% = [No. of successful calls / Total calls attempted] * 100 No. of successful calls = CAUFRQ3D.MCTOSUCC + CAUFRQ3D.MCTTSUCC + CAUFRQ3D.MCTHSUCC Total calls attempted = CAUFRQ3D.MCTOATTS + CAUFRQ3D.MCTTATTS + CAUFRQ3D.MCTHATTS OMs MCTA Origination SUCCess MCTOSUCC Pegged, along with CAUOSUCC, when a mobile-originated call successfully arrives on the traffic channel. This includes all originations placed on the traffic channel to receive treatment. MCTA Termination SUCCess MCTTSUCC Pegged, along with CAUTSUCC, when a mobile-terminated call successfully arrives on the traffic channel. MCTA Hard-handoff SUCCess MCTHSUCC Pegged, along with CAUHSUCC, when a mobile successfully arrives on the traffic channel after a hard handoff. MCTA Origination ATTemptS MCTOATTS
Sprint PCS
04/22/02
Page 69
Pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile origination in a sector with MCTA enabled. Please note that the MCTA frequency for MCTOATTS may be different from the MCTA frequency on which the call originated (MCTORIGS). MCTA Termination ATTemptS MCTTATTS Pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile termination in a sector with MCTA enabled. MCTA Handoff ATTemptS MCTHATTS Pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile hard handoff attempt into a target sector with MCTA enabled. Field Results: Day 1: Day 2: Day 3: Day 4: Freq1 93.82 % 98.09 % 96.94 % 97.25 % Freq2 94.37 % 97.94 % 96.76 % 96.25 % Freq3 92.96 % 77.08 % 91.86 % 92.37 %
Expected Formula Range: It should match the 3G Voice Post-MCTA Call Success
3.2.10. 3G Data Post-MCTA Call Blocks (per frequency) This is the percentage of calls blocked after the MCTA frequency has been selected and the call setup is attempted on the selected frequency. Formula Total Blocks% = [Total no. of calls blocked / Total calls attempted] * 100 Total no. of calls blocked =
Sprint PCS
04/22/02
Page 70
CAUFRQ3D.MCTERSFL Total calls attempted = CAUFRQ3D.MCTOATTS + CAUFRQ3D.MCTTATTS + CAUFRQ3D.MCTHATTS OMs MCTA Error case Radio link Setup FaiLure MCTERSFL Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, whenever a call setup fails due to the fact that the BTS could not allocate resources due to any of the BTS failure reasons. This OM is also pegged when the BTS does not respond at all to resource requests. MCTERSFL is pegged only after an MCTA frequency is selected. MCTERSFL is pegged against the selected frequency. MCTA Origination ATTemptS MCTOATTS Pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile origination in a sector with MCTA enabled. Please note that the MCTA frequency for MCTOATTS may be different from the MCTA frequency on which the call originated (MCTORIGS). MCTA Termination ATTemptS MCTTATTS Pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile termination in a sector with MCTA enabled. MCTA Handoff ATTemptS MCTHATTS Pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile hard handoff attempt into a target sector with MCTA enabled. Field Results: Day 1: Day 2: Day 3: Freq1 0.00 % 0.00 % 0.00 % Freq2 0.00 % 0.00 % 0.00 % Freq3 0.00 % 0.00 % 0.00 %
Sprint PCS
04/22/02
Page 71
Day 4:
0.00 %
0.00 %
0.00 %
Expected Formula Range: It should match the 3G Voice Post-MCTA Call Blocks 3.2.10.1. Detailed 3G Data Post-MCTA Call Blocks (per frequency) The following formulas deal with those calls that are blocked after the MCTA frequency has been selected and the call setup is attempted on the selected frequency. Formulas Blocks due to lack of traffic channel elements: TCE% = [CAUFRQ3D.MCTNOTCE / (CAUFRQ3D.MCTOATTS + CAUFRQ3D.MCTTATTS + CAUFRQ3D.MCTHATTS)] * 100 Blocks due to lack of walsh codes: WCD% = [CAUFRQ3D.MCTNOWCD / (CAUFRQ3D.MCTOATTS + CAUFRQ3D.MCTTATTS + CAUFRQ3D.MCTHATTS)] * 100 Blocks due to no frame offset availability: Frame Offset% = [CAUFRQ3D.MCTNOFOF / (CAUFRQ3D.MCTOATTS + CAUFRQ3D.MCTTATTS + CAUFRQ3D.MCTHATTS)] * 100 Blocks due to lack of forward capacity: FWDCAP% = [CAUFRQ3D.MCTFWCAP / (CAUFRQ3D.MCTOATTS + CAUFRQ3D.MCTTATTS + CAUFRQ3D.MCTHATTS)] * 100 Blocks due to lack of reverse capacity: REVCAP% = [CAUFRQ3D.MCTRECAP / (CAUFRQ3D.MCTOATTS + CAUFRQ3D.MCTTATTS +
Sprint PCS
04/22/02
Page 72
CAUFRQ3D.MCTHATTS)] * 100 OMs MCTA NO Traffic Channel Element MCTNOTCE Pegged, along with MCTERSFL and CAUNOTCE and CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports no traffic channel element via NOIS messages, regardless of origination, termination or hard handoff. MCTNOTCE is pegged only after an MCTA frequency is selected. MCTNOTCE is pegged against the selected frequency. MCTA NO Walsh Code MCTNOWCD Pegged, along with MCTERSFL and CAUNOWCD and CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports no walsh code via NOIS messages, regardless of origination, termination or hard handoff. MCTNOWCD is pegged only after an MCTA frequency is selected. MCTNOWCD is pegged against the selected frequency. MCTA NO Frame Offset MCTNOFOF Pegged, along with MCTERSFL and CAUNOFOF and CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS cannot allocate resources due to some CSM 5000 hardware limitation. The CSM 5000 is limited in how much traffic it can support on its reverse link because of the limitation on the number of decoding units (both Viterbi and Turbo) that can be active on a frame offset (and adjacent frame offsets). MCTNOFOF is pegged only after an MCTA frequency is selected. MCTNOFOF is pegged against the selected frequency MCTA ForWard CAPacity full MCTFWCAP Pegged, along with MCTERSFL and CAUFWCAP and CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports forward capacity full via NOIS messages, regardless of origination, termination or hard handoff. MCTFWCAP is pegged only after an MCTA frequency is selected. MCTFWCAP is pegged against the selected frequency. MCTA REverse CAPacity full MCTRECAP Pegged, along with MCTERSFL and CAURECAP and CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports reverse capacity full via NOIS messages, regardless of origination, termination or hard handoff. However,
Sprint PCS
04/22/02
Page 73
currently there is no reliable mechanism for estimating reverse link capacity. Consequently, this OM should never be pegged. MCTA Origination ATTemptS MCTOATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile origination in a sector with MCTA enabled. Please note that the MCTA frequency for MCTOATTS may be different from the MCTA frequency on which the call originated (MCTORIGS). MCTA Termination ATTemptS MCTTATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile termination in a sector with MCTA enabled. MCTA Handoff ATTemptS MCTHATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile hard handoff attempt into a target sector with MCTA enabled. Field Results Day 1: example Day 2: example Day 3: example Day 4: example
3.2.11. 3G Data Post-MCTA Access Failures (per frequency) This is the percentage of access failures after the MCTA frequency has been selected and resources are successfully setup on the selected frequency.
Sprint PCS
04/22/02
Page 74
Formula Acc Fails% = [Number of MCTA access failures / Total calls attempted] * 100 Number of MCTA access failures = CAURFQ3D.MCTERLFL + CAUFRQ3D.MCTHRLFL Total calls attempted = CAUFRQ3D.MCTOATTS + CAUFRQ3D.MCTTATTS + CAUFRQ3D.MCTHATTS OMs MCTA Error case, Radio Link FaiLure MCTERLFL Pegged, along with CAUERLFL, if the origination or termination fails because the mobile never arrived on the traffic channel (similar to SAT timeout). MCTERLFL is not pegged in cases where the CAUOBLKS or CAUTBLKS OMs are pegged. MCTA hard Handoff Radio Link FaiLure MCTHRLFL Pegged, along with CAUHRLFL, if the hard handoff attempt fails because the mobile never arrived on the target sectors traffic channel (similar to SAT timeout). MCTHRLFL is not pegged in cases where the CAUHBLKS OM is pegged. MCTA Origination ATTemptS MCTOATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile origination in a sector with MCTA enabled. Please note that the MCTA frequency for MCTOATTS may be different from the MCTA frequency on which the call originated (MCTORIGS). MCTA Termination ATTemptS MCTTATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile termination in a sector with MCTA enabled. MCTA Handoff ATTemptS
Sprint PCS
04/22/02
Page 75
MCTHATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile hard handoff attempt into a target sector with MCTA enabled. Field Results: Day 1: Day 2: Day 3: Day 4: Freq1 3.93 % 1.91 % 1.94 % 1.89 % Freq2 2.14 % 1.65 % 1.68 % 1.75 % Freq3 N/A % N/A % N/A % N/A %
Expected Formula Range: It should match the 3G Voice Post-MCTA Access Failures 3.2.11.1. Detailed 3G Data Post-MCTA Access Failures (per frequency) The following formulas deal with those access failures that take place after the MCTA frequency has been selected and resources are successfully setup on the selected frequency. Formulas Access failures during originations or terminations: Orig & Term% = [CAURFQ3D.MCTERLFL / (CAUFRQ3D.MCTOATTS + CAUFRQ3D.MCTTATTS)] * 100 Access failures during hard handoffs: Handoff% = [CAURFQ3D.MCTHRLFL / CAUFRQ3D.MCTHATTS] *100 OMs MCTA Error case, Radio Link FaiLure MCTERLFL Pegged, along with CAUERLFL, if the origination or termination fails because the mobile never arrived on the traffic channel (similar to SAT timeout).
MCTERLFL is not pegged in cases where the CAUOBLKS or CAUTBLKS OMs are pegged. MCTA hard Handoff Radio Link FaiLure MCTHRLFL Pegged, along with CAUHRLFL, if the hard handoff attempt fails because the mobile never arrived on the target sectors traffic channel (similar to SAT timeout). MCTHRLFL is not pegged in cases where the CAUHBLKS OM is pegged. MCTA Origination ATTemptS MCTOATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile origination in a sector with MCTA enabled. Please note that the MCTA frequency for MCTOATTS may be different from the MCTA frequency on which the call originated (MCTORIGS). MCTA Termination ATTemptS MCTTATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile termination in a sector with MCTA enabled. MCTA Handoff ATTemptS MCTHATTS Pegged when a MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile hard handoff attempt into a target sector with MCTA enabled. Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Expected Formula Range: N/A
Sprint PCS
04/22/02
Page 77
(min and max will be defined where applicable) 3.2.12. 3G Data Post-MCTA RF related Drop Calls (per frequency) This is the percentage of established calls on each frequency in MCTA enabled sectors that are dropped due to RF related issues. Formula Drop Call% = [Number of RF related drop calls / Number of successful calls] * 100 Number of RF related drop calls = CAUFRQ3D.MCTDROPR Number of successful calls = CAUFRQ3D.MCTOSUCC + CAUFRQ3D.MCTTSUCC + CAUFRQ3D.MCTHSUCC OMs MCTA DROPped call Rf MCTDROPR Pegged, along with CAUDROPR, when a call is dropped by the SBS due to loss of traffic or due to HCM (handoff completion message) timeout for soft or softer handoff. These are RF-related call failures as detected by the SBS. CAU DROPped call Network CAUDROPN Pegged by the CAU when any of the other (non-RF) drop indication reasons are sent from the SBS in the radio link drop indication message. MCTA Origination SUCCess MCTOSUCC Pegged, along with CAUOSUCC, when a mobile-originated call successfully arrives on the traffic channel. This includes all originations placed on the traffic channel to receive treatment. MCTA Termination SUCCess MCTTSUCC Pegged, along with CAUTSUCC, when a mobile-terminated call successfully arrives on the traffic channel.
Sprint PCS
04/22/02
Page 78
MCTA Hard-handoff SUCCess MCTHSUCC Pegged, along with CAUHSUCC, when a mobile successfully arrives on the traffic channel after a hard handoff. Field Results: Day 1: Day 2: Day 3: Day 4: Freq1 5.09 % 1.95 % 2.71 % 1.89 % Freq2 4.83 % 1.26 % 3.91 % 2.06 % Freq3 0.38 % 0.68 % 1.27 % 0.97 %
Expected Formula Range: It should match the 3G Voice Post-MCTA RF related Drop Calls 3.2.13. PCU MO: 3G Data R-P Interface Packet Sessions The Formulas and OMs discussed in this section relate to the Packet Control Unit (PCU) Managed Object at the BSC level. The R-P interface between a PCU and a PDSN was designed to include the L2TP and PPP processing. L2TP is an Internet protocol defined in RFC 2661 that provides a method of encapsulating PPP packets so that they can be transported across an intervening IP network. This tunneling of PPP is transparent to endusers and applications. The purpose of the protocol is to allow the layer 2 endpoint and the PPP endpoint to be located on separate devices that are connected by an IP network. Packets are sent over the R-P Interface using either reliable or unreliable transmission, the difference being that reliable packets are acknowledged, where as unreliable are not. Reliable packets are used for establishment and control of the L2TP tunnel and of the packet sessions established within that tunnel. The bearer data packets that are sent during the session are sent using unreliable transmission, the quality of service responsibility having been passed to upper layer protocols (for example, TCP). For 3G packet data calls, even after the SBS and BTS resources are successfully setup for the call, and even after the mobile successfully arrives on the traffic channel, the call can still fail (that is, no data transfer would take place) due to a
Page 79
Sprint PCS
04/22/02
failure to set up the R-P packet session or a failure to establish the RLP session. The attempt to set up the R-P packet session is only done after the mobile arrives on the traffic channel. The attempt to establish the RLP is only done after the R-P packet session is successfully set up. 3.2.13.1. 3G Data R-P Interface Packet Session Successes This Formula relates to the Packet Control Unit (PCU) Managed Object at the BSC level. This is the percentage of R-P interface packet session setup successes including both initial and reconnect setups. Formula % Setup Succ = [TotalSessionSetupSuccess / (TotalSessionSetupInitialAttempts TotalSessionSetupReconnectAttempts)] * 100
OMs TotalSessionSetupSuccess Number of successful packet session setups, either by initial or reconnect attempts TotalSessionSetupInitialAttempts Number of packet session setups attempted during initial session setup. TotalSessionSetupReconnectAttempts Number of packet session setups attempted when reconnecting to an existing PPP session Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Sprint PCS
04/22/02
Page 80
N/A (min and max will be defined where applicable) 3.2.13.2. 3G Data R-P Interface Packet Session Failures This Formula relates to the Packet Control Unit (PCU) Managed Object at the BSC level. This is the percentage of R-P interface packet session setup failures including both initial and reconnect setups. Formula % Setup Failures = [TotalSessionSetupFailures / (TotalSessionSetupInitialAttempts TotalSessionSetupReconnectAttempts)] * 100 OMs TotalSessionSetupFailures Number of failed packet session setups. TotalSessionSetupInitialAttempts Number of packet session setups attempted during initial session setup. TotalSessionSetupReconnectAttempts Number of packet session setups attempted when reconnecting to an existing PPP session Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Sprint PCS
04/22/02
Page 81
3.2.13.3. 3G Data R-P Interface Performance Formulas These Formulas relates to the Packet Control Unit (PCU) Managed Object at the BSC level. Formulas: Tunnel Failures = NumberOfTunnelFailures
Unreliable Bytes Tx = (TotalUnreliableBytesTransmittedOverflow * 65535) + TotalUnreliableBytesTransmitted Unreliable Bytes Rx = (TotalUnreliableBytesReceivedOverflow * 65535) + TotalUnreliableBytesReceived Fwd Packets Dropped = TotalFwdPacketsDropped Rev Packets Dropped = TotalRevPacketsDropped DCR Overflow RR Overflow StopTxMsgsSent = DCRBufferOverflows = RRBufferOverflows = DCR_NumOfStopTransmitMsgsSent
OMs NumberOfTunnelFailures Counts the number of times a L2TP tunnel was torn down due to failure of reliable packet transmission per L2TP tunnel TotalUnreliableBytesTransmitted Counts the cumulative number of bytes each session in the PCU transmitted to PDSN per L2TP tunnel TotalUnreliableBytesTransmittedOverflow Register allows values greater than 65535 for TotalUnreliableBytesTransmitted. TotalUnreliableBytesReceived Counts the cumulative number of bytes each session in the PCU received from PDSN per L2TP tunnel
Sprint PCS
04/22/02
Page 82
TotalUnreliableBytesReceivedOverflow Register allows values greater than 65535 for TotalUnreliableBytesReceived. TotalFwdPacketsDropped Number of PPP packets dropped in the forward direction per PCU TotalRevPacketsDropped Number of PPP packets dropped in the reverse direction per PCU DCRBufferOverflows Number of DCR buffer overflows per PCU RRBufferOverflows Number of RR buffer overflows StopTxMsgsSent Number of Stop Transmit messages sent from RLPQ per PCU Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Expected Formula Range: N/A (min and max will be defined where applicable) 3.2.14. ESEL MO: 3G Data RLP Sessions The Formulas and OMs discussed in this section relate to the EselectorCard (ESEL) Managed Object at the BSC level. For 3G packet data calls, even after the SBS and BTS resources are successfully setup for the call, and even after the mobile successfully arrives on the traffic channel, the call can still fail (that is, no data transfer would take place) due to a failure to set up the R-P packet session or a failure to establish the RLP session.
The attempt to set up the R-P packet session is only done after the mobile arrives on the traffic channel. The attempt to establish the RLP is only done after the R-P packet session is successfully set up. 3.2.14.1. 3G Data RLP Session Successes The following formula gives us the percentage of RLP session setup successes. Formula RLP % Succ = [RLPSetupSuccesses / RLPSetupAttempts)] * 100 OMs RLPSetupSuccesses Number of successful RLP setups. RLPSetupAttempts Number of RLP setups attempted. Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Expected Formula Range: N/A (min and max will be defined where applicable) 3.2.14.2. 3G Data RLP Session Failures The following formula gives us the percentage of RLP session setup failures. Formula RLP % Fail = [RLPSetupFailures / RLPSetupAttempts)] * 100
Sprint PCS
04/22/02
Page 84
OMs RLPSetupFailures Number of failed RLP setups RLPSetupAttempts Number of RLP setups attempted. Field Results Day 1: example Day 2: example Day 3: example Day 4: example
3.3. Performance Formulas for 3G Forward Supplemental Channel Data (ESEL MO)
The OMs used in the following formulas are collected by the Enhanced Selector Card (ESEL) Managed Object at the BSC level. 3.3.1. Forward Burst Setup Success Formula F-SCH Burst %Succ = [FwdBurstSetupSuccesses / FwdBurstSetupAttemps] * 100 OMs FwdBurstSetupSuccesses Pegged when a forward data burst is successfully set up FwdBurstSetupAttempts
Sprint PCS
04/22/02
Page 85
Pegged when a forward data burst needs to be set up Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Expected Formula Range: N/A (min and max will be defined where applicable) 3.3.2. Forward Burst Setup Failures Formula F-SCH Burst %Fail = [FwdBurstSetupFailures / FwdBurstSetupAttemps] * 100 OMs FwdBurstSetupFailures Pegged when a forward data burst could not be set up FwdBurstSetupAttempts Pegged when a forward data burst needs to be set up Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Sprint PCS
04/22/02
Page 86
Expected Formula Range: N/A (min and max will be defined where applicable) 3.3.3. Forward SCH Blocks Formula F-SCH %Blocks = [FSCHLinkSetupBlock / FSCHLinkSetupAttempts] * 100 OMs FSCHLinkSetupBlock Number of FSCH setup attempts that are blocked for lack of resources FSCHLinkSetupAttempts Number of forward supplemental channel (FSCH) setup attempts Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Expected Formula Range: N/A (min and max will be defined where applicable) 3.3.3.1. Detailed Forward SCH Blocks Formula Blocks due to lack of Forward Power: F-SCH %Block NoFwdPwr = [FSCHNoFwdPower / FSCHLinkSetupAttempts] * 100 Blocks due to lack of Walsh Codes:
Sprint PCS
04/22/02
Page 87
F-SCH %Block NoWalshCode = [FSCHNoWalshCode/ FSCHLinkSetupAttempts] * 100 Blocks due to lack of No Physical Resources: F-SCH %Block NoPhysicalResources = [FSCHNoPhyRes / FSCHLinkSetupAttempts] * 100 Blocks due to lack of No Frame Offset availability: F-SCH %Block NoFrameOffset = [FSCHNoFrameOffset / FSCHLinkSetupAttempts] * 100 Blocks due to CFDS Configuration: F-SCH %Block CFDSConfig = [FSCHCFDSRadioConfig / FSCHLinkSetupAttempts] * 100 OMs FSCHNoFwdPower Pegged if the FSCHBlock reason indicates a lack of available forward power FSCHNoWalshCode Pegged if the FSCHBlock reason indicates a lack of available Walsh codes FSCHNoPhysRes Pegged if the FSCHBlock reason indicates there are no available channel elements FSCHNoFrameOffset Pegged if the FSCHBlock reason indicates there is no available frame offset FSCHCFDSRadioConfig Pegged if the FSCHBlock reason indicates SCH burst functionality has not been enabled through CFDS FSCHLinkSetupAttempts Number of forward supplemental channel (FSCH) setup attempts Field Results Day 1: example Day 2: example Day 3: example
Sprint PCS
04/22/02
Page 88
Day 4: example
Expected Formula Range: N/A (min and max will be defined where applicable) 3.3.4. Forward SCH Access Failures Formula F-SCH %Access Failures = [FSCHRadioLinkAccessFailure / FSCHLinkSetupAttempts] * 100 OMs FSCHRadioLinkAccessFailure This OM is pegged in the event the resources for the FSCH are set up successfully, but the mobile does not arrive on the FSCH. It is pegged against each link in the SCH active set. FSCHLinkSetupAttempts Number of forward supplemental channel (FSCH) setup attempts Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Sprint PCS
04/22/02
Page 89
3.3.5. Forward SCH Time Out Formula F-SCH %TimeOuts = [FSCHTimeout / FSCHLinkSetupAttempts] * 100 OMs FSCHTimeout Pegged if a response to the BTS resource request is never received. FSCHLinkSetupAttempts Number of forward supplemental channel (FSCH) setup attempts Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Expected Formula Range: N/A (min and max will be defined where applicable) 3.3.6. Forward SCH Data Rate Downgrades Formula F-SCH %Downgrades = [FSCHLinkDowngrade / FSCHLinkSetupAttempts] * 100 OMs FSCHLinkDowngrade Number of FSCH setup attempts that are not granted the requested data rate due to lack of resources, but are granted a lower data rate. Pegged against the primary pilot in the SCH active set.
Sprint PCS
04/22/02
Page 90
FSCHLinkSetupAttempts Number of forward supplemental channel (FSCH) setup attempts Field Results Day 1: example Day 2: example Day 3: example Day 4: example
3.4. Performance Formulas for 3G Reverse Supplemental Channel Data (ESEL MO)
The OMs used in the following formulas are collected by the Enhanced Selector Card (ESEL) Managed Object at the BSC level 3.4.1. Reverse Burst Setup Success Formula R-SCH Burst %Succ = [RevBurstSetupSuccesses / RevBurstSetupAttemps] * 100 OMs RevBurstSetupSuccesses Pegged when a Reverse data burst is successfully set up RevBurstSetupAttempts Pegged when a Reverse data burst needs to be set up Field Results
Sprint PCS
04/22/02
Page 91
Day 1: example Day 2: example Day 3: example Day 4: example
Expected Formula Range: N/A (min and max will be defined where applicable) 3.4.2. Reverse Burst Setup Failures Formula R-SCH Burst %Rail = [RevBurstSetupFailures / RevBurstSetupAttemps] * 100 OMs RevBurstSetupFailures Pegged when a Reverse data burst could not be set up RevBurstSetupAttempts Pegged when a Reverse data burst needs to be set up Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Sprint PCS
04/22/02
Page 92
3.4.3. Reverse SCH Blocks Formula R-SCH %Blocks = [RSCHLinkSetupBlock / RSCHLinkSetupAttempts] * 100 OMs RSCHLinkSetupBlock Number of RSCH setup attempts that are blocked for lack of resources RSCHLinkSetupAttempts Number of Reverse supplemental channel (RSCH) setup attempts Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Expected Formula Range: N/A (min and max will be defined where applicable) 3.4.3.1. Detailed Reverse SCH Blocks Formula Blocks due to lack of No Physical Resources: R-SCH %Block NoPhysicalResources = [RSCHNoPhyRes / RSCHLinkSetupAttempts] * 100 Blocks due to lack of No Frame Offset availability: R-SCH %Block NoFrameOffset = [RSCHNoFrameOffset / RSCHLinkSetupAttempts] * 100 Blocks due to CFDS Configuration:
Sprint PCS
04/22/02
Page 93
R-SCH %Block CFDSConfig = [RSCHCFDSRadioConfig / RSCHLinkSetupAttempts] * 100 Blocks due to Reverse High Speed CFDS Configuration: R-SCH %Block HighSpeedCFDSConfig = [RSCHCFDSHighSpeed / RSCHLinkSetupAttempts] * 100 OMs RSCHNoPhysRes Pegged if the RSCHBlock reason indicates there are no available channel elements RSCHNoFrameOffset Pegged if the RSCHBlock reason indicates there is no available frame offset RSCHCFDSRadioConfig Pegged if the RSCHBlock reason indicates SCH burst functionality has not been enabled through CFDS RSCHCFDSHighSpeed Pegged if the RSCHBlock reason indicates high speed RSCH has not been enabled through CFDS RSCHLinkSetupAttempts Number of Reverse supplemental channel (RSCH) setup attempts Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Sprint PCS
04/22/02
Page 94
3.4.4. Reverse SCH Access Failures Formula R-SCH %Access Failures = [RSCHRadioLinkAccessFailure / RSCHLinkSetupAttempts] * 100 OMs RSCHRadioLinkAccessFailure This OM is pegged in the event the resources for the RSCH are set up successfully, but the mobile does not arrive on the RSCH. It is pegged against each link in the SCH active set. RSCHLinkSetupAttempts Number of Reverse supplemental channel (RSCH) setup attempts Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Expected Formula Range: N/A (min and max will be defined where applicable) 3.4.5. Reverse SCH Time Out Formula R-SCH %TimeOuts = [RSCHTimeout / RSCHLinkSetupAttempts] * 100 OMs RSCHTimeout Pegged if a response to the BTS resource request is never received.
Sprint PCS
04/22/02
Page 95
RSCHLinkSetupAttempts Number of Reverse supplemental channel (RSCH) setup attempts Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Expected Formula Range: N/A (min and max will be defined where applicable) 3.4.6. Reverse SCH Data Rate Downgrades Formula R-SCH %Downgrades = [RSCHLinkDowngrade / RSCHLinkSetupAttempts] * 100 OMs RSCHLinkDowngrade Number of RSCH setup attempts that are not granted the requested data rate due to lack of resources, but are granted a lower data rate. Pegged against the primary pilot in the SCH active set. RSCHLinkSetupAttempts Number of Reverse supplemental channel (RSCH) setup attempts Field Results Day 1: example Day 2: example
Sprint PCS
04/22/02
Page 96
Day 3: example Day 4: example
3.5. Performance Formulas for BTS Managed Objects (MOs)

3.5.1. Advanced Sector 3G Fundamental Channel Formulas The OMs used in the following formulas are pegged on a per-sector basis for all of the supported frequencies. NOTE: indicates summing the pegs for the time period appropriate for the report under discussion. 3.5.1.1. 3G FCH Originations Formulas
3G call attempts downgraded to 2G 3G ->2G (Downgrade) = ADV_SEC[112] = (FchOriginationNonBlocking3GDowngrade2G)
Voice Blocks
Non Blocking = ADV_SEC[110] = (FchOriginationNonBlocking3GVoice) = ADV_SEC[119][0] = (BlockedFchOriginations3GVoice) (due to no physical resources) = ADV_SEC[119][3] = (BlockedFchOriginations3GVoice)
Block FCH No TCE
Block FCH No WC
Sprint PCS
04/22/02
Page 97
(due to no Walsh code) Block FCH No Fwd Power = ADV_SEC[119][1] = (BlockedFchOriginations3GVoice) (due to no forward power) = ADV_SEC[119][4] = (BlockedFchOriginations3GVoice) (due to no frame offset)
Block FCH No Frame Offset
Block CFDS Radio Config State = ADV_SEC[119][6] = (BlockedFchOriginations3GVoice) (due to CFDS radio config state)
Data Blocks
Non Blocking = ADV_SEC[111] = (FchOriginationNonBlocking3GData) = ADV_SEC[120][0] = (BlockedFchOriginations3GData) (due to no physical resources) = ADV_SEC[120][3] = (BlockedFchOriginations3GData) (due to no Walsh code) = ADV_SEC[120][1] = (BlockedFchOriginations3GData) (due to no forward power) = ADV_SEC[120][4] = (BlockedFchOriginations3GData) (due to no frame offset)
Block FCH No TCE
Block FCH No WC
Block FCH No Fwd Power
Block CFDS Radio Config State = ADV_SEC[120][6] = (BlockedFchOriginations3GData) (due to CFDS radio config state)
Blocking Reasons
Sprint PCS
04/22/02
Page 98
No Physical Resources In this case, the CCEMs and XCEMs in the sector could not support additional calls. More CCEMs or XCEMs may be needed. No Walsh Code Blocking occurred because all Walsh codes had been allocated. This includes scenarios where Walsh codes are regulated by MaxVoiceResources (or voice calls) or MaxDataResources (for data calls). If this blocking reason is consistently higher than No forward capacity, the system may be Walsh code limited. In that case, the operator should consider setting RC4_Preferred to increase Walsh code availability at the expense of forward power. No Forward Capacity The BTS forward power level surpassed the level defined by the call blocking threshold or MaxVoiceResources (for voice calls) or MaxDataResources (for data calls). No Frame Offset The XCEM supports a fixed number of calls per frame offset. This metric corresponds to blocks that were a result of an XCEMs inability to support the needed frame offset. This metric is not applicable to CCEMs. No CFDS Radio Config State Blocking occurred because the CFDS RadioConfigState attribute is configured in such a way that does not allow the specific type of call requested to be setup. Reconfiguration of this attribute may be needed. OMs FchOriginationNonBlocking3GDowngrade2G Number of successful BTS resource allocations for fundamental channel 2G calls which were downgraded from 3G calls attempts. This metric does not include non-reference pilot links setup for CASHO. 2G links, other than the reference pilots link, setup for CASHO are pegged under FchHandoffNonBlocking2G. FchOriginationNonBlocking3GVoice Number of successful BTS resource allocations for 3G voice calls on the fundamental channel. This is not an indication of successful call attempts. This metric does not include non-reference pilot links setup for CASHO. 3G voice links, other than the reference pilots link, setup for CASHO are pegged under FchHandoffNonBlocking3GVoice. BlockedFchOriginations3GVoice
Sprint PCS
04/22/02
Page 99
Array indicating the number of 3G voice call attempts blocked on the fundamental channel. Each array element corresponds to a different blocking reason as explained above. FchOriginationNonBlocking3GData Number of successful BTS resource allocations for 3G data calls on the fundamental channel. This is not an indication of successful call attempts. This metric does not include non-reference pilot links setup for CASHO. 3G data links, other than the reference pilots link, setup for CASHO are pegged under FchHandoffNonBlocking3GData. BlockedFchOriginations3GData Array indicating the number of 3G data sessions blocked on the fundamental channel. Each array element corresponds to a different blocking reason as explained above. Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Expected Formula Range: N/A 3.5.1.2. 3G FCH Soft Handoff Blocks Formulas
Voice Blocks
Non Blocking = ADV_SEC[113] = (FchHandoffNonBlocking3GVoice) = ADV_SEC[121][0] = (BlockedFchHandoffs3GVoice)
Block FCH No TCE
Sprint PCS
04/22/02
Page 100
(due to no physical resources) Block FCH No WC = ADV_SEC[121][3] = (BlockedFchHandoffs3GVoice) (due to no Walsh code) = ADV_SEC[121][1] = (BlockedFchHandoffs3GVoice) (due to no forward power) = ADV_SEC[121][4] = (BlockedFchHandoffs3GVoice) (due to no frame offset)
Block CFDS Radio Config State = ADV_SEC[121][6] = (BlockedFchHandoffs3GVoice) (due to CFDS radio config state)
Data Blocks
Non Blocking = ADV_SEC[114] = (FchHandoffNonBlocking3GData) = ADV_SEC[122][0] = (BlockedFchHandoffs3GData) (due to no physical resources) = ADV_SEC[122][3] = (BlockedFchHandoffs3GData) (due to no Walsh code) = ADV_SEC[122][1] = (BlockedFchHandoffs3GData) (due to no forward power) = ADV_SEC[122][4] = (BlockedFchHandoffs3GData) (due to no frame offset)
Block FCH No TCE
Block FCH No WC
Block CFDS Radio Config State = ADV_SEC[122][6] = (BlockedFchHandoffs3GData)
Sprint PCS
04/22/02
Page 101
(due to CFDS radio config state)
Blocking Reasons
No Physical Resources In this case, the CCEMs and XCEMs in the sector could not support additional calls. More CCEMs or XCEMs may be needed. No Walsh Code Blocking occurred because all Walsh codes had been allocated. This includes scenarios where Walsh codes are regulated by MaxVoiceResources (or voice calls) or MaxDataResources (for data calls). If this blocking reason is consistently higher than No forward capacity, the system may be Walsh code limited. In that case, the operator should consider setting RC4_Preferred to increase Walsh code availability at the expense of forward power. No Forward Capacity The BTS forward power level surpassed the level defined by the call blocking threshold or MaxVoiceResources (for voice calls) or MaxDataResources (for data calls). No Frame Offset The XCEM supports a fixed number of calls per frame offset. This metric corresponds to blocks that were a result of an XCEMs inability to support the needed frame offset. This metric is not applicable to CCEMs. No CFDS Radio Config State Blocking occurred because the CFDS RadioConfigState attribute is configured in such a way that does not allow the specific type of call requested to be setup. Reconfiguration of this attribute may be needed. OMs FchHandoffNonBlocking3GVoice Number of successful BTS resource allocations for 3G voice handoffs on the fundamental channel. Note that this is not an indication of successful handoffs. BlockedFchHandoffs3GVoice Array indicating the number of 3G voice handoffs blocked on the fundamental channel. Each array element corresponds to a different blocking reason as explained above. FchHandoffNonBlocking3GData
Sprint PCS
04/22/02
Page 102
Number of successful BTS resource allocations for 3G data handoffs on the fundamental channel. Note that this is not an indication of successful handoffs. BlockedFchHandoffs3GData Array indicating the number of 3G data handoffs blocked on the fundamental channel. Each array element corresponds to a different blocking reason as explained above. Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Expected Formula Range: N/A 3.5.1.3. 3G Average number of FCH Handoff Links The following average numbers can also be calculated for a particular cluster of sectors or for the whole system by simply replacing each OM below with the sum of the same OM over all sectors in the cluster or in the whole system. Formulas Average number of FCH softer handoff links The average number of softer handoff links for the FCH in any sector in particular can be expressed by the following ratio: (FrameCntFCH / CEFrameCntFCH) Average number of FCH soft handoff links (no including softer) The average number of soft handoff links for the FCH in any sector in particular can be expressed by the following ratio: (CEFrameCntFCH / PrimaryFrameCntFCH) Average number of FCH handoff links (including both soft and softer)
Sprint PCS
04/22/02
Page 103
The average number of all handoff links for the FCH in any sector in particular can be expressed by the following ratio: (FrameCntFCH / PrimaryFrameCntFCH) OMs FrameCntFCH Array indicating the total number of frames sent on the forward link for every user on the fundamental channel. Each element in the array represents one radio configuration from RC1 through RC5. The array begins with RC1. CEFrameCntFCH Equivalent to FrameCntFCH with each frame being divided by the number of softer handoff links. PrimaryFrameCntFCH Equivalent to FrameCntFCH with each frame being divided by the product of the number of softer handoff links and the number of soft handoff links.
Field Results Day 1: example Day 2: example Day 3: example Day 4: example
Expected Formula Range: N/A 3.5.2. Advanced Sector 3G Supplemental Channel Formulas The OMs used in the following formulas are pegged on a per-sector basis for all of the supported frequencies. NOTE: indicates summing the pegs for the time period appropriate for the report under discussion.
Sprint PCS
04/22/02
Page 104
3.5.2.1. 3G SCH Burst Formulas Non Blocking = ADV_SEC[115] = (SchBurstNonBlocking3G) = ADV_SEC[123][0] = (BlockedSchBursts) (due to no physical resources) = ADV_SEC[123][3] = (BlockedSchBursts) (due to no Walsh code) = ADV_SEC[123][1] = (BlockedSchBursts) (due to no forward power) = ADV_SEC[123][4] = (BlockedSchBursts) (due to no frame offset) = ADV_SEC[123][6] = (BlockedSchBursts) (due to CFDS radio config state) = ADV_SEC[123][7] = (BlockedSchBursts) (due to CFDS HS RSCH)
Block SCH No TCE
Block SCH No WC
Block SCH No Fwd Power
Block SCH No Frame Offset
Blocked Radio Config State
Screened
Blocking Reasons
No Physical Resources In this case, the CCEMs and XCEMs in the sector could not support additional calls. More CCEMs or XCEMs may be needed. No Walsh Code Blocking occurred because all Walsh codes had been allocated. This includes scenarios where Walsh codes are regulated by MaxVoiceResources (or voice calls) or MaxDataResources (for data calls). If this blocking reason is consistently higher than No forward capacity, the system may be Walsh code limited. In that
Sprint PCS
04/22/02
Page 105
case, the operator should consider setting RC4_Preferred to increase Walsh code availability at the expense of forward power. No Forward Capacity The BTS forward power level surpassed the level defined by the call blocking threshold or MaxVoiceResources (for voice calls) or MaxDataResources (for data calls). No Frame Offset The XCEM supports a fixed number of calls per frame offset. This metric corresponds to blocks that were a result of an XCEMs inability to support the needed frame offset. This metric is not applicable to CCEMs. No CFDS Radio Config State Blocking occurred because the CFDS RadioConfigState attribute is configured in such a way that does not allow the specific type of call requested to be setup. Reconfiguration of this attribute may be needed. No CFDS HS RSCH This element in the array is valid only for BlockedSchBursts and BlockedSchHandoffs. It is pegged when the EnableHSReverseSchFeature attribute is set to FALSE. This attribute is used to screen for high data rate R-SCH bursts (i.e. when set to FALSE, only data rates of 9600 bps are allowed). Reconfiguration of this attribute may need to be considered. OMs SchBurstNonBlocking3G Number of successful BTS resource allocations for 3G data bursts on the supplemental channel. This is not an indication of successful data bursts. BlockedSchBursts Array indicating the number of 3G data bursts blocked on the supplemental channel. Each array element corresponds to a different blocking reason as explained above.
Field Results Day 1: example Day 2: example
Sprint PCS
04/22/02
Page 106
Day 3: example Day 4: example
N/A 3.5.2.2. 3G SCH Handoff Blocks Formulas Non Blocking = ADV_SEC[116] = (SchHandoffNonBlocking3G) = ADV_SEC[124][0] = (BlockedSchHandoffs) (due to no physical resources) = ADV_SEC[124][3] = (BlockedSchHandoffs) (due to no Walsh code) = ADV_SEC[124][1] = (BlockedSchHandoffs) (due to no forward power) = ADV_SEC[124][4] = (BlockedSchHandoffs) (due to no frame offset) = ADV_SEC[124][6] = (BlockedSchHandoffs) (due to CFDS radio config state) = ADV_SEC[124][7] = (BlockedSchHandoffs) (due to CFDS HS RSCH)
Block SCH No TCE
Block SCH No WC
Block SCH No Fwd Power
Block SCH No Frame Offset
Blocked Radio Config State
Screened
Blocking Reasons
Sprint PCS
04/22/02
Page 107
No Physical Resources In this case, the CCEMs and XCEMs in the sector could not support additional calls. More CCEMs or XCEMs may be needed. No Walsh Code Blocking occurred because all Walsh codes had been allocated. This includes scenarios where Walsh codes are regulated by MaxVoiceResources (or voice calls) or MaxDataResources (for data calls). If this blocking reason is consistently higher than No forward capacity, the system may be Walsh code limited. In that case, the operator should consider setting RC4_Preferred to increase Walsh code availability at the expense of forward power. No Forward Capacity The BTS forward power level surpassed the level defined by the call blocking threshold or MaxVoiceResources (for voice calls) or MaxDataResources (for data calls). No Frame Offset The XCEM supports a fixed number of calls per frame offset. This metric corresponds to blocks that were a result of an XCEMs inability to support the needed frame offset. This metric is not applicable to CCEMs. No CFDS Radio Config State Blocking occurred because the CFDS RadioConfigState attribute is configured in such a way that does not allow the specific type of call requested to be setup. Reconfiguration of this attribute may be needed. No CFDS HS RSCH This element in the array is valid only for BlockedSchBursts and BlockedSchHandoffs. It is pegged when the EnableHSReverseSchFeature attribute is set to FALSE. This attribute is used to screen for high data rate R-SCH bursts (i.e. when set to FALSE, only data rates of 9600 bps are allowed). Reconfiguration of this attribute may need to be considered. OMs SchHandoffNonBlocking3G Number of successful BTS resource allocations for 3G data handoffs on the supplemental channel. Note that This is not an indication of successful handoffs. BlockedSchHandoffs Array indicating the number of 3G data handoffs blocked on the supplemental channel. Each array element corresponds to a different blocking reason as explained above.
N/A 3.5.2.3. 3G Average number of SCH Handoff Links The following average numbers can also be calculated for a particular cluster of sectors or for the whole system by simply replacing each OM below with the sum of the same OM over all sectors in the cluster or in the whole system. Formulas Average number of SCH softer handoff links The average number of softer handoff links for the SCH in any sector in particular can be expressed by the following ratio: (FrameCntSCH / CEFrameCntSCH) Average number of SCH soft handoff links (no including softer) The average number of soft handoff links for the SCH in any sector in particular can be expressed by the following ratio: (CEFrameCntSCH / PrimaryFrameCntSCH) Average number of SCH handoff links (including both soft and softer) The average number of all handoff links for the SCH in any sector in particular can be expressed by the following ratio: (FrameCntSCH / PrimaryFrameCntSCH) OMs FrameCntSCH
Sprint PCS
04/22/02
Page 109
Array indicating the total number of forward frames for every user on the supplemental channel. Each element in the array represents one radio configuration from RC3 through RC5. The array begins with RC3. CEFrameCntSCH Equivalent to FrameCntSCH with each frame being divided by the number of softer handoff links. PrimaryFrameCntSCH Equivalent to FrameCntSCH with each frame being divided by the product of the number of softer handoff links and the number of soft handoff links.
3.5.3. Advanced Frequency Assignment (FA) Managed Object Formulas Advanced Frequency Assignment (FA) formulas deal with the status of XCEM resources on the fundamental as well as the supplemental channels. Formulas Forward Total = ADV_FA[72] Total ForwardPhysicalResources = ADV_FA[74] SchMaximumForwardPhysicalResourcesUsed
Max SCH Forward
Sprint PCS
04/22/02
Page 110
Max 3G FCH Forward = ADV_FA[76] Fch3GMaximumForwardPhysicalResourcesUsed Reverse Total = ADV_FA[77] TotalReversePhysicalResources = ADV_FA[24] TCEUtilMaximum = ADV_FA[23] NumOfTCAvailable
Max TCE
TCE Available
OMs Total ForwardPhysicalResources The number of 3G XCEM resources provisioned for the BTSs forward link. This excludes all CCEM resources and faulty XCEM resources. This OM is a snapshot taken at the time of reporting. It does not represent how many resources are actually in use. SchMaximumForwardPhysicalResourcesUsed This OM is a high water mark for the number of XCEM resources being used for the forward supplemental channel at any time during the reporting period. Fch3GMaximumForwardPhysicalResourcesUsed This OM is a high water mark for the number of XCEM resources being used for 3G calls on the forward fundamental channel at any time during the reporting period. TotalReversePhysicalResources The number of 3G XCEM resources provisioned for the BTSs reverse link. This excludes all CCEM resources and faulty XCEM resources. This OM is a snapshot taken at the time of reporting. It does not represent how many resources are actually in use. TCEUtilMaximum The peak number of channel elements in use, simultaneously, during a given time. NumOfTCAvailable Total number of channel elements available for traffic across all channel cards after overhead channels have been subtracted
Sprint PCS
04/22/02
Page 111
Sprint PCS
04/22/02
Page 112
4. Field Results Analysis

This section discusses various approaches that can be considered by the RF engineers while analyzing the field results. The performance formulas discussed in this section are provided on a as-needed basis. For a complete list of performance formulas, please refer Section 3 of this document. We can categorize call failures into the following three types: 1. Before the resources are allocated (Access Failures) 2. When the mobile is moving from the paging/access channel to the traffic channel (Blocks) 3. After the mobile is on the traffic channel (Drops) Ideally, our goal is to bring the above failure rates down to zero. However, failure percentages in the range of 1 to 2 percent are pretty typical for a given network. If the network statistics reflect a failure trend that is exceeding the desired range then the following procedures can be considered to troubleshoot the problem. It is important to verify that the field results in hand are reflecting a relatively large number of users before proceeding with the analysis. These procedures apply to both 3G voice and 3G data calls. For 3G voice calls, the OMs are taken from the appropriate voice OM groups, such as CAUSCT3V, CAUFRQ3V. Similarly, for 3G data calls, the OMs are taken from the appropriate data OM groups, such as CAUSCT3D, CAUFRQ3D.
4.1. Access Failures

The percentage of access failures is expressed by the following relation: Acc Fails% = [Number of access failures / Total calls attempted] * 100 The number of access failures is calculated by adding the following OMs counts: CAUERLFL + CAUHRLFL Please note that for 3G Packet data calls, the attempt to set up the R-P packet session is done after the mobile arrives on the traffic channel but before sending the service connect message out to the mobile. Thus if the R-P packet session setup fails, it will still be pegged as an access failure. The TotalSessionSetupFailures count can be subtracted from the above sum when measuring the RF Access Failure rate on a system wide basis.
Sprint PCS
04/22/02
Page 113
Figure 4-1A: 3G Voice Access Failures Percentage

20000 18000 16000 14000 12000 10000 8000 6000 4000 2000 0
02 2 02 2 2 10 /0 2 11 /0 13 /0 12 /0 14 /0 8/ 9/ 2
10 9 8 7 6 5 4 3 2 1 0
Number of attempts
Attempts %_AF
4/
4/
4/
4/
4/
Date
Figure 4-1B: 3G Data Access Failures Percentage

1400 Number of Attempts 1200 1000 800 600 400 200 0
02 02 2 2 2 2 10 /0 11 /0 12 /0 13 /0 14 /0 8/ 9/ 2
4/
4/
10 9 8 7 6 5 4 3 2 1 0
Attempts %_AF
4/
4/
4/
4/
Data
Figures 4-1A and 4-1B above show 3G voice and 3G data access failures percentages respectively. This data is collected from test calls performed in the Kansas City market, specifically the K1B1 and K2B2 test clusters that include 30 sites. Please note that the access failure rate is much higher in the case of 3G data calls. However, this high failure rate does not reflect a typical network behavior because: 1) the number of attempts is significantly less for the data calls as compared to the voice call attempts. 2) Approximately 90% of data calls were attempted from only two sectors out of a total of about 90 sectors.
4/
4/
4/
Sprint PCS
04/22/02
Page 114
For a more detailed analysis, we can break this information down into specific areas, as follows: 4.1.1. Access failures during originations and terminations: (CAUERLFL)
A higher count on this peg reflects that the number of access failures taking place
during originations or terminations is high.

The next step would be go to the MCTA report and figure out which carrier(s) is
experiencing access failures. To do this, we will check the count for MCTERLFL for all carriers, and identify the carrier(s) that has high number of access failures. NOTE: It is possible that more than one carrier is facing high access failure rate. Recommendations:
The information available under this OM does not help us significantly to pin
point the problem. The best option for such failure is to send a drive test team out to try to duplicate failed origination/termination attempts, and analyze the drive test data to identify the problem. Also, cell trouble logs can be printed in conjunction with the drive test results to provide information about the mobile whose call attempt was unsuccessful. The following can be a reason for this count:
The Mobile cannot hear the BTS acknowledgment, chances are that the Ec/Io is
low. 1. 2. 3.
Low Ec/Io could be because of: Poor coverage, received signal strength is low. Pilot pollution, many available pilots with no dominant server. Fading problem, if the Ec/Io dropped down for a very short period of time and then came back. 4. Hardware faults, such failures are mostly on a per sector basis. 5. RF environment changes, such as addition of new sites in the area.
4.1.2. Access failures during hard handoffs: (CAUHRLFL)

A higher count on this peg reflects that the number of access failures taking place
during hard handoffs is high. The next step would be go to the MCTA report and figure out which carrier(s) at the target sector is experiencing access failures. To do this, we will check the count for MCTHRLFL for all carriers, and identify the carrier(s) that has high number of access failures. NOTE: It is possible that more than one carrier is facing high access failure rate.
Sprint PCS
04/22/02
Page 115
Recommendations:
This count is similar to the CAUERLFL count as discussed above in section 4.1.1.
The only difference is that in the case of a hard handoff the access failure is taking place at the target sector.
4.2. Blocks
The percentage of total blocks is expressed by the following relation: Total Blocks % = [Number of call setup failures / Total number of call attempts] * 100
Figure 4-2A: 3G Voice Total Blocks Percentage
20000 18000 16000 14000 12000 10000 8000 6000 4000 2000 0
2 2 10 /0 2 11 /0 2 12 /0 2 13 /0 2 4/ 9/ 0 4/ 8/ 0 14 /0 2
10 9 8 7 6 5 4 3 2 1 0
Number of Attempts
Attempts %_T_BLK
4/
4/
4/
Date
Figure 4-2B: 3G Data Total Blocks Percentage

1400 Number of Attempts 1200 1000 800 600 400 200 0
4/ 8/ 02 4/ 9/ 02 2 2 2 2 10 /0 11 /0 12 /0 13 /0 14 /0 2
4/
4/
10 9 8 7 6 5 4 3 2 1 0
Attempts %_T_BLK
4/
4/
4/
Date
4/
4/
Sprint PCS
04/22/02
Page 116
Figures 4-2A and 4-2B above show 3G voice and 3G data total blocks percentages respectively. This data is collected from test calls performed in the Kansas City market, specifically the K1B1 and K2B2 test clusters that include 30 sites. Please note that the blocking rate is relatively higher in the case of 3G data calls. However, this high failure rate does not reflect a typical network behavior because: 1) the number of attempts is significantly less for the data calls as compared to the voice call attempts. 2) Approximately 90% of data calls were attempted from only two sectors out of a total of about 90 sectors. The total number of call blocks or call setup failures is calculated by adding the following OMs counts: CAUOBLKS + CAUTBLKS + CAUHBLKS For a more detailed analysis, we can break this information down into specific areas, as follows: 4.2.1. Blocking due to lack of BTS channel elements: (CAUNOTCE)
A higher count on this peg reflects that blocking due to lack of BTS channel
elements (TCEs) on a particular sector is high. The next step would be go to the MCTA report and figure out which carrier(s) on this sector is running out of TCEs. To do this, we will check the count for MCTNOTCE for all carriers, and identify the carrier(s) that is lacking channel elements. NOTE: It is possible that more than one carrier is facing the channel elements limitation. Verify the TCE limitation by comparing the number of TCEs in use with the total number of TCEs provisioned for this carrier(s) at the BTS. Recommendations:
Provision additional TCE at the BTS. More TCEs can be added as required until
the available power is exhausted.

After power exhaustion, deployment of an additional carrier is recommended.
4.2.2. Blocking due to lack of Walsh codes: (CAUNOWCD)

A higher count on this peg reflects that blocking due to lack of Walsh codes on a
particular sector is high.

The next step would be go to the MCTA report and figure out which carrier(s) on
this sector is running out of Walsh codes. To do this, we will check the count for MCTNOWCD for all carriers, and identify the carrier(s) that is lacking Walsh
Sprint PCS
04/22/02
Page 117
codes. NOTE: It is possible that more than one carrier is facing the Walsh codes limitation. Recommendations:
Addition of a new site is recommended once the Walsh codes have reached the
limit. NOTE: Data users with higher traffic rates would be the major contributors for such failures. 4.2.3. Blocking due to lack of forward capacity: (CAUFWCAP)
A higher count on this peg reflects that the sector is running out of capacity on the
forward link. The next step would be go to the MCTA report and figure out which carrier(s) on this sector is running out of forward capacity. To do this, we will check the count for MCTFWCAP for all carriers, and identify the carrier(s) that is lacking forward capacity. NOTE: It is possible that more than one carrier is facing the forward capacity limitation. Recommendations:
Deployment of an additional carrier is recommended for such blocks. If adding a carrier is not an option then additional site would be required.
4.2.4. Blocking due to lack of reverse capacity: (CAURECAP)

A higher count on this peg reflects that the sector is running out of capacity on the
reverse link.
this sector is running out of reverse capacity. To do this, we will check the count for MCTRECAP for all carriers, and identify the carrier(s) that is lacking reverse capacity. NOTE: It is possible that more than one carrier is facing the reverse capacity limitation. Recommendations:
A drive test would be required to analyze blocks that are possibly resulting due to
the reverse link capacity.
Sprint PCS
04/22/02
Page 118
4.2.5. Blocking due to lack of physical resources: This type of blocks is given by the sum of following two OMs: RMNORREQ A higher count on this peg reflects that the Resource Manager (RM) has no available resources to allocate for a call. Recommendations: These are network-related call setup failures. They result due to SBS shortage problem. Typically, more SBS selector elements are needed to be provisioned in such cases. It is also possible that one or more selector elements are out-of-service. In either case, an investigation should be done in coordination with switch/network team to pin point the problem. CAUERSFL A higher count on this peg reflects that some BTS resource is not available. This OM is also pegged if any of the software entities on the BTS do not respond to resource requests during call setup Recommendations:
Depending on which resource is not available at the BTS, the following
information might be of help: 1. 2. 3. 4. 5. 6. No channel elements (CAUNOTCE): refer section 4.1.1 No Walsh codes (CAUNOWCD): refer section 4.1.2 No forward capacity (CAUFWCAP): refer section 4.1.3 No reverse capacity (CAURECAP): refer section 4.1.4 BTS does not respond at all. Failed to select a carrier: This reflects no available capacity on any of the carriers. In this case, the failure reasons are pegged by MCTAMIXF, MCTALLTO or MCTALLFU.
Addition of a new carrier is recommended for such failures.
4.2.6. Blocking due to no frame offset availability: (CAUNOFOF)

A higher count on this peg reflects that no frame offset is available at the given
sector.
this sector has no frame offset availability. To do this, we will check the count for
Sprint PCS
04/22/02
Page 119
MCTNOFOF for all carriers, and identify the carrier(s) that has no frame offset availability. NOTE: It is possible that more than one carrier is facing the frame offset availability limitation. Recommendations: This type of failures reflects software or hardware limitations; and are not because of RF-related failures. 4.2.7. Blocking due to BTS time-outs: Blocking resulting due to BTS time-outs is given by the following relation: = [Blocking due to (Radio link setup error No channel elements No Walsh codes No forward capacity No reverse capacity No frame offset availability No frequency selected for origination or termination No frequency selected for hard handoff) / Total calls attempted] * 100 Recommendations: These are hardware/software related problems, reasons to be investigated. 4.2.8. Blocking due to BSC time-outs and software faults: This type of blocks is given by the sum of following OMs:
RMSRMTO -
RM SRM Time-Out RMSRMNAK - RM Service Resource Manager Negative AcK CAUESWFL - CAU Error case, SoftWare FauLt
Recommendations: These are hardware/software related problems, reasons to be investigated.
Sprint PCS
04/22/02
Page 120
4.3. Drops
The percentage of total drops is expressed by the following relation: Drop Call% = [Number of drop calls / Number of successful calls] * 100
Figure 4-3A: 3G Voice Call Drops Percentage
20000 18000 16000 14000 12000 10000 8000 6000 4000 2000 0
2 2 10 /0 2 11 /0 2 12 /0 2 13 /0 2 4/ 9/ 0 4/ 8/ 0 14 /0 2
10 9 8 7 6 5 4 3 2 1 0
Number of Attempts
Attempts %_Drop
4/
4/
4/
Date
Figure 4-3B: 3G Data Call Drops Percentage

1400 Number of Attempts 1200 1000 800 600 400 200 0 10 9 8 7 6 5 4 3 2 1 0
4/
4/
Attempts %_Drop
4/ 8/ 0
4/ 9/ 0
11 /0 2
10 /0 2
12 /0 2
13 /0 2 4/
4/
4/
Date
Figures 4-3A and 4-3B above show 3G voice and 3G data call drops percentages respectively. This data is collected from test calls performed in the Kansas City market, specifically the K1B1 and K2B2 test clusters that include 30 sites. Please note that the call drop rate is relatively higher in the case of 3G data calls. However, this high failure rate does not reflect a typical network behavior because: 1) the number of attempts is
Page 121
Sprint PCS
4/
4/
14 /0 2
04/22/02
significantly less for the data calls as compared to the voice call attempts. 2) Approximately 90% of data calls were attempted from only two sectors out of a total of about 90 sectors. The total number of call drops is calculated by adding the following OMs counts: CAUDROPR + CAUDROPN For a more detailed analysis, we can break this information down into specific areas, as follows: 4.3.1. Drops due to RF-related reasons: (CAUDROPR)
A higher count on this peg reflects that the number of calls dropped due to loss of
traffic or due to HCM (handoff completion message) timeout on a particular sector is high. The next step would be go to the MCTA report and figure out which carrier(s) on this sector is dropping calls. To do this, we will check the count for MCTDROPR for all carriers, and identify the carrier(s) that is facing a high number of drop calls due to RF-related reasons. NOTE: It is possible that more than one carrier is experiencing such drops. Recommendations:
As mentioned above this count includes failures resulting during soft and softer
handoffs as well. Therefore, the first step is to identify the exact reason for this count. This task can be accomplished by organizing a drive test to capture these drops, and then analyze the layer 3 messages. The main reason for RF-related drop calls is higher values of FER, i.e., when the FER is above the threshold. Factors contributing in bringing the FER high include high noise, weak signal, pilot pollution. In some cases, intermittent hardware problems have also resulted in such drops. Drops occurring due to poor coverage conditions would require additional sites. For handoff related drops, it is important to verify that all the neighbor lists are correct.
4.3.2. Drops due to network-related reasons: (CAUDROPN)

A higher count on this peg reflects that the number of calls dropped due to any
other, non-RF, reason on a particular sector is high. The next step would be go to the MCTA report and figure out which carrier(s) on this sector is dropping calls. To do this, we will check the count for MCTDROPN for all carriers, and identify the carrier(s) that is facing a high number of drop calls
Sprint PCS
04/22/02
Page 122
due to non RF-related reasons. NOTE: It is possible that more than one carrier is experiencing such drops. Recommendations:
These are not RF-related failures.
Sprint PCS
04/22/02
Page 123
5. New Operational Measurements in 3G 1xRTT

This section outlines the new OMs available in 3G 1xRTT. These OMs are listed in tables that are divided on a per OM group basis.
5.1. OM Groups: CAUSCT3V, CAUSCT3D

CAUSCT3V (CAU SeCTor based OMs for 3G Voice calls) CAUSCT3D (CAU SeCTor based OMs for 3G Data calls)
Table 5-1: OM Groups: CAUSCT3V, CAUSCT3D

OM Full Name CAU PaGe RESponse OM Register (Name) Description MSC / BSC V/D Basis / BTS
CAUPGRES For mobile-terminated calls, attempts are recorded MSC V+D perin CAUPGRES, which indicates that a page sector response was received from a CDMA sector in basis response to a page request (irrespective of whether it was in response to an initial page request or a retry by the CM). MSC V+D persector basis
CAU Termination CAUTSUCC Pegged when a mobile-terminated call successfully SUCCess arrives on the traffic channel.
CAU Termination CAUTBLKS Pegged any time a mobile-terminated call setup fails MSC V+D perBLocKS due to resource shortage. It represents all of the sector termination setup failures in a sector, regardless of basis resource. One or more of the following call setup failure reasons is pegged in conjunction with CAUTBLKS: RMNORREQ, RMSRMNAK, RMSRMTO, CAUERSFL, CAUNOTCE, CAUNOWCD, CAUNOFOF, CAUFWCAP, CAURECAP and CAUESWFL. CAU Error case, Dropped due to Loss Of Traffic CAUEDLOT Pegged when the mobile drops off the traffic channel MSC V+D perafter the Radio Link Setup Rsp message is sector received but before the Service Connect Rsp basis message is received. This scenario is considered an access failure. The register CAUERLFL is also pegged in conjunction with this register. Pegged when a mobile-terminated call is released before the mobile arrives on the traffic channel. It should be noted that this OM will only get pegged if the originating party disconnects between the time that the terminating mobiles page response has been received by the CM and before the mobile actually arrives on the traffic channel. MSC V+D persector basis
CAU Termination CAUTRLS ReLeaSed
Sprint PCS
04/22/02
Page 124

OM Full Name CAU Origination ATTemptS CAU Origination SUCCess OM Register (Name) Description MSC / BSC V/D Basis / BTS MSC V+D persector basis MSC V+D persector basis
CAUOATTS Pegged when the CAU receives an origination message from the BTS. Test call originations are pegged in a separate OM. CAUOSUCC Pegged when a mobile-originated call successfully arrives on the traffic channel. This includes all originations placed on the traffic channel to receive treatment.
CAU Origination BLocKS
CAUOBLKS Pegged any time a mobile-originated call setup fails MSC V+D perdue to resource shortage. It represents the total sector number of origination setup failures in a sector, basis regardless of resource. The same failure reasons that are pegged for CAUTBLKS can be pegged in conjunction with CAUOBLKS. CAUORODR The CM can send reorder commands to the mobile MSC V+D peroriginators whose calls will not be set up. These sector situations can occur by datafilling a treatment with basis the MOBRODR or MOBICPT CLLI instead of an announcement or tone CLLI in table TMTCNTL. CAUORODR is pegged when the CAU receives a reorder or intercept message from the CM indicating that the origination is intentionally stopped without putting the mobile on the traffic channel. CAUORLS Pegged when a mobile-originated call is released by MSC V+D perthe mobile station or the CM before the mobile sector sends a service completion message. basis
CAU Origination ReOrDeR
CAU Origination ReLeaSed CAU Error case, Radio Setup FaiLure
CAUERSFL Pegged, along with the appropriate CAU*BLKS OM, MSC V+D perwhenever a call setup fails due to the fact that some sector BTS resource is not available. This OM is also basis pegged when the BTS does not respond to resource requests. It is also pegged when the Carrier Determination Algorithm (CDA) fails to select a carrier in an MCTA enabled sector (that is, no available capacity on all co-located carriers). Pegged if the origination or termination fails because MSC V+D perthe mobile never arrived on the traffic channel sector (similar to SAT timeout). CAUERLFL is not pegged basis in cases where the CAUOBLKS or CAUTBLKS OMs are pegged. MSC V+D persector basis
CAU Error Radio CAUERLFL Link FaiLure
SLoTted mode SLTPGRES This OM is the equivalent of CAUPGRES, except PaGe RESponse that it is pegged by the CAU only in response to a slotted mode page request. Slotted mode paging is measured separately so that performance differences can be determined. SLTPGRES is a subset of the CAUPGRES.
Sprint PCS
04/22/02
Page 125

OM Full Name CAU hard Handoff ATTemptS OM Register (Name) Description MSC / BSC V/D Basis / BTS
CAUHATTS Pegged when the CAU receives a ReadyNewCell MSC V+D permessage from the CM, indicating that a hard handoff sector attempt sequence in a (CDMA) target sector should basis begin.
CAU hard CAUHBLKS Pegged any time a CDMA-to-CDMA hard handoff MSC V+D perHandoff BLocKS setup fails due to resource shortage. It represents all sector of the hard handoff setup failures into a sector, basis regardless of resource. This OM is pegged for both inter- and intra-system hard handoff attempts. CAUHBLKS is not the number of dropped hard handoffs, it merely represents the number of times that a hard handoff could not be completed due to resource shortages in the target cell/sectorthe call in the source cell is still up. The same failure reasons that are pegged for CAUOBLKS (see previous page) can be pegged in conjunction with CAUHBLKS. CAU hard Handoff SUCCess CAU hard Handoff ReLeaSed CAU hard Handoff Radio Link FaiLure CAUHSUCC Pegged when a mobile, attempting a hard handoff, successfully arrives on the traffic channel in the target sector. CAUHRLS MSC V+D persector basis
Pegged when a call setup in a target cell is released MSC V+D perby the source system before the mobile arrives on sector the traffic channel. basis
CAUHRLFL Pegged if the hard handoff attempt fails because the MSC V+D permobile never arrived on the target sectors traffic sector channel (similar to SAT timeout). CAUHRLFL basis is not pegged in cases where CAUHBLKS is pegged.
CAU DROPped call Rf
CAUDROPR Pegged by the CAU against the reference pilot when MSC V+D pera call is dropped by the SBS due to loss of traffic or sector due to HCM (handoff completion message) timeout basis for soft or softer handoff. These are RF-related call failures as detected by the SBS. CAUDROPN Pegged by the CAU when any of the other (non-RF) MSC V+D perdrop indication reasons are sent from the SBS in the sector radio link drop indication message. basis CAUESWFL Pegged, along with the appropriate CAU*BLKS OM, MSC V+D perwhenever a call setup fails due to time outs between sector software entities that should not occur (for example, basis no response from the CM, failure message received from SBS, etc.).
CAU DROPped call Network CAU Error case, SoftWare FauLt
CAU NO Traffic CAUNOTCE Pegged, along with CAUERSFL and the appropriate MSC V+D perChannel Element CAU*BLKS OM, any time a BTS reports no traffic sector channel element via NOIS messages, regardless of basis
Sprint PCS
04/22/02
Page 126

OM Full Name OM Register (Name) Description origination, termination or hard handoff. MSC / BSC V/D Basis / BTS
CAU NO Walsh Code
CAUNOWC Pegged, along with CAUERSFL and the appropriate MSC V+D perD CAU*BLKS OM, any time a BTS reports no walsh sector code via NOIS messages, regardless of origination, basis termination or hard handoff. CAUNOFOF Pegged, along with CAUERSFL and the appropriate MSC V+D perCAU*BLKS OM, any time a BTS cannot allocate sector resources due to some CSM 5000 hardware basis limitation. The CSM 5000 is limited in how much traffic it can support on its reverse link because of the limitation on the number of decoding units (both Viterbi and Turbo) that can be active on a frame offset (and adjacent frame offsets). CAUFWCAP Pegged, along with CAUERSFL and the appropriate MSC V+D perCAU*BLKS OM, any time a BTS reports forward sector capacity full via NOIS messages, regardless of basis origination, termination or hard handoff. CAURECAP Pegged, along with CAUERSFL and the appropriate MSC V+D perCAU*BLKS OM, any time a BTS reports reverse sector capacity full via NOIS messages, regardless of basis origination, termination or hard handoff. However, currently there is no reliable mechanism for estimating reverse link capacity and so this response is disabled on the BTS. Consequently, this OM is never pegged. MCTAHRQF Pegged, along with CAUERSFL, when NO MSC V+D perfrequency was successfully selected by MCTA for a sector hard handoff call setup. It is pegged on a per-sector basis basis on the target side. The failure reasons are pegged by MCTAMIXF, MCTALLTO or MCTALLFU. MCTAREQF Pegged, along with CAUERSFL, when NO MSC V+D perfrequency was successfully selected by MCTA for sector origination or termination call setup. It is pegged on basis a per-sector basis. The failure reasons are pegged by MCTAMIXF, MCTALLTO or MCTALLFU. MCTALLFU Pegged, along with CAUERSFL and (MCTAREQF MSC V+D peror MCTAHRQF), when NO frequency was sector successfully selected by MCTA because none of the basis BTSs had resources available. It is pegged on a persector basis.
CAU NO Frame OFfset
CAU ForWard CAPacity full
CAU REverse CAPacity full
MCTA Handoff ReQuest Failure
MCTA REQuest Failure
MCTA All frequencies FUll
Sprint PCS
04/22/02
Page 127

OM Full Name MCTA ALL frequencies Timed-Out OM Register (Name) Description MSC / BSC V/D Basis / BTS
MCTALLTO Pegged, along with CAUERSFL and (MCTAREQF MSC V+D peror MCTAHRQF), when NO frequency was sector successfully selected by MCTA because none of the basis BTSs responded to the capacity request query. It is pegged on a per-sector basis.
MCTA MIXed Failure
MCTAMIXF
Pegged, along with CAUERSFL and MCTARQFN and (MCTAREQF or MCTAHRQF), when NO frequency was successfully selected by MCTA because some BTSs timed-out while some responded with a resource full or not available response. It is pegged on a per-sector basis.
MSC V+D persector basis
5.2. OM Groups: CAURFQ3V, CAUFRQ3D

CAUFRQ3V (CAU FReQuency based OMs for 3G Voice calls) CAUFRQ3D (CAU FReQuency based OMs for 3G Data calls)
Table 5-2: OM Groups: CAURFQ3V, CAUFRQ3D

OM Full Name MCTA ORIGination OM Register (Name) Description MSC / BSC V/D Basis / BTS MSC V+D perfreq basis
MCTORIGS Pegged, along with CAUOATTS, when the CAU receives an origination message from a sector that has MCTA enabled. It is pegged against the originating frequency. Test call originations are pegged in a separate OM.
MCTA Origination MCTOATTS Pegged when an MCTA frequency is successfully MSC V+D perATTemptS selected by the Carrier Determination Algorithm freq (CDA) for a mobile origination in a sector with MCTA basis enabled. Please note that the MCTA frequency for MCTOATTS may be different from the MCTA frequency on which the call originated (MCTORIGS). MCTA Origination MCTOSUCC Pegged, along with CAUOSUCC, when a mobileMSC V+D perSUCCess originated call successfully arrives on the traffic freq channel. This includes all originations placed on the basis traffic channel to receive treatment.
Sprint PCS
04/22/02
Page 128

OM Full Name MCTA PaGe RESponse OM Register (Name) Description MSC / BSC V/D Basis / BTS
MCTPGRES For mobile-terminated calls, attempts are recorded MSC V+D perin MCTPGRES, which indicates that a page freq response was received from an MCTA enabled basis CDMA sector in response to a page request. This OM is pegged irrespective of whether it was the first or the second attempt to page the mobile. CAUPGRES is also pegged whenever MCTPGRES is pegged. MCTTATTS Pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile termination in a sector with MCTA enabled. MCTTSUCC Pegged, along with CAUTSUCC, when a mobileterminated call successfully arrives on the traffic channel. MSC V+D perfreq basis MSC V+D perfreq basis
MCTA Termination ATTemptS MCTA Termination SUCCess MCTA Handoff Call ATTempts
MCTHCATT Pegged, along with CAUHATTS, when the CAU MSC V+D perreceives a message from the CM, indicating that a freq hard handoff attempt sequence in an MCTA enabled basis CDMA target sector should begin. MCTHATTS Pegged when an MCTA frequency is successfully MSC V+D perselected by the Carrier Determination Algorithm freq (CDA) for a mobile hard handoff attempt into a target basis sector with MCTA enabled. MCTHSUCC Pegged, along with CAUHSUCC, when a mobile successfully arrives on the traffic channel after a hard handoff. MCTHRLFL Pegged, along with CAUHRLFL, if the hard handoff attempt fails because the mobile never arrived on the target sectors traffic channel (similar to SAT timeout). MCTHRLFL is not pegged in cases where the CAUHBLKS OM is pegged. MSC V+D perfreq basis MSC V+D perfreq basis
MCTA Handoff ATTemptS
MCTA Hardhandoff SUCCess MCTA Handoff Radio Link FaiLure
MCTA Error case MCTERSFL Pegged, along with CAUERSFL and the appropriate MSC V+D perRadio link Setup CAU*BLKS OM, whenever a call setup fails due to freq FaiLure the fact that the BTS could not allocate basis resources due to any of the BTS failure reasons. This OM is also pegged when the BTS does not respond at all to resource requests. MCTERSFL is pegged only after an MCTA frequency is selected. MCTERSFL is pegged against the selected frequency.
Sprint PCS
04/22/02
Page 129

OM Full Name OM Register (Name) Description MSC / BSC V/D Basis / BTS MSC V+D perfreq basis
MCTA NO Traffic MCTNOTCE Pegged, along with MCTERSFL and CAUNOTCE Channel Element and CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports no traffic channel element via NOIS messages, regardless of origination, termination or hard handoff. MCTNOTCE is pegged only after an MCTA frequency is selected. MCTNOTCE is pegged against the selected frequency.
MCTA NO Walsh MCTNOWC Pegged, along with MCTERSFL and CAUNOWCD MSC V+D perCode D and CAUERSFL and the appropriate CAU*BLKS freq OM, any time a BTS reports no walsh code via NOIS basis messages, regardless of origination, termination or hard handoff. MCTNOWCD is pegged only after an MCTA frequency is selected. MCTNOWCD is pegged against the selected frequency. MCTA NO Frame MCTNOFOF Pegged, along with MCTERSFL and CAUNOFOF MSC V+D perOFfset and CAUERSFL and the appropriate CAU*BLKS freq OM, any time a BTS cannot allocate resources due basis to some CSM 5000 hardware limitation. The CSM 5000 is limited in how much traffic it can support on its reverse link because of the limitation on the number of decoding units (both Viterbi and Turbo) that can be active on a frame offset (and adjacent frame offsets). MCTNOFOF is pegged only after an MCTA frequency is selected. MCTNOFOF is pegged against the selected frequency MCTA ForWard CAPacity full MCTFWCAP Pegged, along with MCTERSFL and CAUFWCAP MSC V+D perand CAUERSFL and the appropriate CAU*BLKS freq OM, any time a BTS reports forward capacity full via basis NOIS messages, regardless of origination, termination or hard handoff. MCTFWCAP is pegged only after an MCTA frequency is selected. MCTFWCAP is pegged against the selected frequency. MCTA REverse CAPacity full MCTRECAP Pegged, along with MCTERSFL and CAURECAP MSC V+D perand CAUERSFL and the appropriate CAU*BLKS freq OM, any time a BTS reports reverse capacity full via basis NOIS messages, regardless of origination, termination or hard handoff. However, currently there is no reliable mechanism for estimating reverse link capacity. Consequently, this OM should never be pegged.
Sprint PCS
04/22/02
Page 130

OM Full Name OM Register (Name) Description MSC / BSC V/D Basis / BTS
MCTA Error MCTERLFL Pegged, along with CAUERLFL, if the origination or MSC V+D percase, Radio Link termination fails because the mobile never arrived freq FaiLure on the traffic channel (similar to SAT timeout). basis MCTERLFL is not pegged in cases where the CAUOBLKS or CAUTBLKS OMs are pegged. MCTA REQuest Timeout MCTAREQT pegged when a frequency was successfully selected MSC V+D perby MCTA but one or more of the BTSs never freq responded to a capacity request. MCTAREQT is basis pegged against the carrier(s) that did not respond to the capacity request. MCTAREQT may not always be pegged under low traffic load conditions. MCTAREQN Pegged when a frequency was successfully selected MSC V+D perby MCTA but one or more of the BTSs responded freq with a resource full or not available response. basis MCTAREQN is pegged against the carrier(s) that respond with a resource full or not available response. MCTAREQN may not always be pegged under low load conditions. MCTARQFN Pegged, along with CAUERSFL and MCTAMIXF and (MCTAREQF or MCTAHRQF), when no frequency was successfully selected by MCTA because some BTSs timed out, while some responded with a resource full or not available response. MCTARQFN is pegged against the carrier(s) that respond with a resource full or not available response. MSC V+D perfreq basis
MCTA REQuest response full or Not available
MCTA ReQuest response Failed (full or Not available)
MCTA DROPped MCTDROPR Pegged, along with CAUDROPR, when a call is MSC V+D perRadio link dropped by the SBS due to loss of traffic or due to freq HCM (handoff completion message) timeout for basis soft or softer handoff. These are RF-related call failures as detected by the SBS.
5.3. OM Group: CAUDAT3G

CAU sector based OMs for short DATa bursts initiated by 3G mobiles
Table 5-3: OM Group: CAUDAT3G

OM Full Name OM Register (Name) Description MSC / BSC V/D Basis / BTS
Sprint PCS
04/22/02
Page 131
Short Data burst PCU LooKup Requests
SDPCULKR Pegged when the CAU receives a Short Data Burst MSC D message from the mobile in a dormant data call. SDB is being considered for future release, and thus this register will not get pegged in the initial release of 1XRTT. SDPCULKF Pegged when the CAU does not get the address of MSC D the PCU to forward the SDB message (this is due to a PCU address lookup failure at the MU). SDB is being considered for future release, and thus this register will not get pegged in the initial release of 1XRTT.
persector basis
Short Data burst PCU LooKup Failures
persector basis
5.4. OM Group: RMU3G (RMU OMs for 3G calls)
Table 5-4: OM Group: RMU3G

OM Full Name Request for 3G Voice call SUCcess for 3G Voice call OM Register (Name) REQ3GV Description MSC / BSC V/D Basis / BTS
Pegged when there is an attempt made by RMU to MSC V+D perallocate resources for a 3G Voice call attempt based RMU on a resource request from CAU. basis Pegged when the RMU successfully allocates resources for a 3G Voice call based on a resource request from CAU. MSC V+D perRMU basis
SUC3GV
NO ReSource for NORS3GV 3G Voice call Request for 153K REQ153K data rate data-call SUCcess for 153K data rate data-call SUC153K
Pegged when the RMU fails to allocate resources for MSC V+D pera 3G Voice call based on a resource request from RMU CAU. basis Pegged when there is an attempt made by RMU to allocate resources for a 153K data rate data-call attempt based on a resource request from CAU. Pegged when the RMU successfully allocates resources for a 153K data rate data-call attempt based on a resource request from CAU. MSC V+D perRMU basis MSC V+D perRMU basis
NO ReSource for NORS153K 153K data rate data-call Request for 76K REQ76K data rate data-call
Pegged when the RMU fails to allocate resources for MSC V+D pera 153K data rate data-call attempt based on a RMU resource request from CAU. basis Pegged when there is an attempt made by the RMU MSC V+D perto allocate resources for a 76K data rate data-call RMU attempt based on a resource request from CAU. basis Note that rate data-call attempt based on a resource request from CAU. Note that REQ76K counts include downgraded attempts from 153K to 76K due to no resources available for the 153K attempts. The downgraded attempts (from 153K to 76K) count is equal to NORS153K.
Sprint PCS
04/22/02
Page 132
Table 5-4: OM Group: RMU3G

OM Full Name OM Register (Name) Description Pegged when the RMU successfully allocates resources for a 76K data rate data-call attempt based on a resource request from CAU. MSC / BSC V/D Basis / BTS MSC V+D perRMU basis
SUCcess for 76K SUC76K data rate data-call NO ReSource for NORS76K 76K data rate data-call Request for 38K REQ38K data rate data-call
Pegged when the RMU fails to allocate resources for MSC V+D pera 76K data rate data-call attempt based on a RMU resource request from CAU. basis Pegged when there is an attempt made by the RMU MSC V+D perto allocate resources for a 38K data rate data-call RMU attempt based on a resource request from CAU. basis Note that internally, the RMU does not make a distinction between the 38K and the 76K data rates, and therefore a 76K data rate call attempt can never be downgraded to a 38K data rate call attempt. Thus REQ38K counts do not include any downgraded attempts from a higher data rate to 38K data rate. Pegged when the RMU successfully allocates resources for a 38K data rate data-call attempt based on a resource request from the CAU. MSC V+D perRMU basis
SUCcess for 38K SUC38K data rate data-call NO ReSource for NORS38K 38K data rate data-call Request for 19K REQ19K data rate data-call
Pegged when the RMU fails to allocate resources for MSC V+D pera 38K data rate data-call attempt based on a RMU resource request from the CAU. basis Pegged when there is an attempt made by the RMU MSC V+D perto allocate resources for a 19K data rate data-call RMU attempt based on a resource request from the CAU. basis Note that REQ19K counts include downgraded attempts from 76K to 19K and downgraded attempts from 38K to 19K due to no resources available for the 76K and 38K data rates attempts. The downgraded attempts (from 76K to 19K) count is equal to NORS76K and the downgraded attempts (from 38K to 19K) count is equal to NORS38K. Pegged when the RMU successfully allocates resources for a 19K data rate data-call attempt based on a resource request from the CAU. MSC V+D perRMU basis
SUCcess for 19K SUC19K data rate data-call NO ReSource for NORS19K 19K data rate data-call
Pegged when the RMU fails to allocate resources for MSC V+D pera 19K data rate data-call attempt based on a RMU resource request from the CAU. basis
5.5. OM Group: CDMAPDOM (CDMA Packet Data)
Table 5-5: OM Group: CDMAPDOM
Sprint PCS
04/22/02
Page 133
OM Full Name
OM Register (Name)
Description Pegged when the MSC receives an origination message from a mobile which is in a dormant data call state.
MSC / BSC V/D Basis / BTS MSC D syste mwide basis syste mwide basis syste mwide basis syste mwide basis syste mwide basis syste mwide basis
Mobile-Initiated MIDTOAAT Dormant To Active ATtempts Mobile-Initiated Dormant To Active SUccess Mobile-Initiated Dormant To Active FaiLures
MIDTOASU Pegged when the mobile-initiated dormant to active MSC D transition is successful mobile arrives on the traffic channel. MIDTOAFL Pegged when the mobile-initiated dormant to active MSC D transition fails due to lack of resources or the mobile fail to arrive on the traffic channel. Pegged when the MSC receives a PCU_Page_Request after the network DCR PLICF decides to make the transition to active state. MSC D
Network-Initiated NIDTOAAT Dormant To Active ATtempts Network-Initiated NIDTOASU Dormant To Active SUccess Network-Initiated NIDTOAFL Dormant To Active FaiLures
Pegged when the network-initiated dormant to active MSC D transition is successful mobile arrives on the traffic channel. Pegged when the network-initiated dormant to active MSC D transition fails due to lack of resources or the mobile fail to arrive on the traffic channel.
5.6. OM Group: CDMAPDSO (CDMA Packet Data Service Option)
Table 5-6: OM Group: CDMAPDSO

OM Full Name Resource Allocation Attempts for CDMA2000 INternet PPP Data service option OM Register (Name) ATINPPP Description MSC / BSC V/D Basis / BTS perRMU basis
Pegged when there is an attempt made by the RMU MSC D for a resource request from the CAU to allocate a resource for a CDMA2000_INT_PPP_DATA service option.
Sprint PCS
04/22/02
Page 134
Table 5-6: OM Group: CDMAPDSO

OM Full Name SUccessful resource allocation for CDMA2000 INternet PPP Data service option Hop Count for CDMA2000 INternet PPP Data service option Resource allocation FaiLures for CDMA2000 INternet PPP Data service option OM Register (Name) SUINPPP Description MSC / BSC V/D Basis / BTS perRMU basis
Pegged when a resource for a MSC D CDMA2000_INT_PPP_DATA service option request has been successfully allocated.
HCINPPP
Pegged for each pool, including the first pool, the MSC D RMU searches through from the list to find a resource for a CDMA2000_INT_PPP_DATA service option. Pegged when an attempt to allocate resource for a MSC D CDMA2000_INT_PPP_DATA service option fails. It is due to no resources available in any pool from the list
perRMU basis
FLINPPP
perRMU basis
5.7. OM Group: CAURM

Three new OMs are added in this group for 1XRTT.
Table 5-7: OM Group: CAURM

OM Full Name OM Register (Name) Description MSC / BSC V/D Basis / BTS pegge d by the RMU
Service Resource SRMNAK3D pegged only in cases of 3G Packet Data calls. MSC D Manager SRMNAK3D is pegged, along with the appropriate Negative AcK for CAU*BLKS OM, when Resource Manager (RM) 3G Data calls receives a resource allocation failure indication from SRMs. This is an error condition, indicating mismatches between the RM and the SBS SRM. SRM Time-Out SRMTO3D for 3G Data calls pegged only in cases of 3G Packet Data calls. MSC D SRMTO3D is pegged, along with the appropriate CAU*BLKS OM, when Resource Manager times out waiting on a request for call resources from the SRM.
pegge d by the RMU
Sprint PCS
04/22/02
Page 135
Table 5-7: OM Group: CAURM

OM Full Name NO Resources for REQuest for 3G Data calls OM Register (Name) Description MSC / BSC V/D Basis / BTS pegge d by the RMU
NORREQ3D pegged only in cases of 3G Packet Data calls. MSC D NORREQ3D is pegged, along with the appropriate CAU*BLKS OM, when Resource Manager (RM) has no available resources to allocate for a call. In this case, the RM does not message to any of its SBSs to determine availability, only internal data structures are checked.
5.8. OM Group: CAUCPSYS

Three new OMs are added in this group for1XRTT.
Table 5-8: OM Group: CAUCPSYS

OM Full Name OM Register (Name) Description Pegged when the CAU receives a Short Data Burst message from the PCU to send to the mobile. SDB is being considered for future release, and thus this register will not get pegged in the initial release of 1XRTT. MSC / BSC V/D Basis / BTS MSC V+D
Network-Initiated NISDBATT Short Data Burst ATTempts
Network-Initiated NISDBSC Short Data Burst SuCcess Network-Initiated NISDBFL Short Data Burst FaiLure
Pegged when the CAU receives a response from the MSC V+D mobile to the SDB message sent. SDB is being considered for future release, and thus this register will not get pegged in the initial release of 1XRTT. Pegged when the CAU times out waiting for a MSC V+D response from the mobile to the SDB message sent. SDB is being considered for future release, and thus this register will not get pegged in the initial release of 1XRTT.
5.9. OM Group: CDMAPGZN

One new OM is added in this group for 1XRTT.
Table 5-9: OM Group: CDMAPGZN
Sprint PCS
04/22/02
Page 136
OM Full Name OM Register (Name)
Description
MSC / BSC V/D Basis / BTS MSC D per pagin g zone
Paging Zone PGZSDB3G pegged when the MSC receives a Short Data Burst network-initiated delivery message from the CAU. PGZSDB3G is Short Data Burst found in the CDMAPGZN group. SDB is being attempts during a considered for future release, and thus this register 3G dormant data will not get pegged in the initial release of 1XRTT. call
5.10. OM Group: PCU
Table 5-10: OM Group: PCU

OM Full Name OM Register (Name) Reliable Packet Sent Success Reliable Packet ReTransmitted Reliable Packet Received Number Of Tunnel Failures Total Unreliable Bytes Transmitted Total Unreliable Bytes Received Description MSC / V/D Basis BSC / BTS BSC D pernode basis pernode basis pernode basis pernode basis pernode basis pernode basis percall basis percall basis
ReliablePack Counts the number of ACKs received as a result of etSentSucce reliable packets being sent to any given PDSN. ss
ReliablePack Counts the number of reliable packets that had to be BSC etReTransmi retransmitted because no ACK was received. tted ReliablePack Counts the number of messages the PCU received etReceived with reliable delivery acknowledgement requested per L2TP tunnel BSC
NumberOfTu Counts the number of times a L2TP tunnel was torn BSC nnelFailures down due to failure of reliable packet transmission per L2TP tunnel TotalUnrelia Counts the cumulative number of bytes each bleBytesTran session in the PCU transmitted to PDSN per L2TP smitted tunnel TotalUnrelia Counts the cumulative number of bytes each bleBytesRec session in the PCU received from PDSN per L2TP eived tunnel BSC
BSC
Total Fwd TotalFwdPac Number of PPP packets dropped in the forward Packets Dropped ketsDropped direction per PCU Total Rev TotalRevPac Number of PPP packets dropped in the reverse Packets Dropped ketsDropped direction per PCU
BSC
BSC
Sprint PCS
04/22/02
Page 137
Table 5-10: OM Group: PCU

OM Full Name OM Register (Name) DCR Buffer Overflows RR Buffer Overflows Total Session Setup Initial Attempts Description MSC / V/D Basis BSC / BTS BSC D percall basis percall basis percall basis percall basis percall basis percall basis pernode basis pernode basis pernode basis pernode basis pernode basis percall basis percall basis
DCRBufferO Number of DCR buffer overflows per PCU verflows RRBufferOv Number of RR buffer overflows erflows TotalSession Number of packet session setups attempted during SetupInitialAt initial session setup tempts
BSC
BSC
Total Session TotalSession Number of packet session setups attempted when Setup Reconnect SetupRecon reconnecting to an existing PPP session Attempts nectAttempts Total Session Setup Success Total Session Setup Failures Reliable Packet Sent Success Overflow Reliable Packet ReTransmitted Overflow Reliable Packet Received Overflow Total Unreliable Bytes Transmitted Overflow Total Unreliable Bytes Received Overflow
BSC
TotalSession Number of successful packet session setups, either BSC SetupSucces by initial or reconnect attempts s TotalSession Number of failed packet session setups SetupFailure s ReliablePack Register allows values greater than 65535 for etSentSucce ReliablePacketSentSuccess. ssOverflow ReliablePack Register allows values greater than 65535 for etReTransmi ReliablePacketReTransmitted. ttedOverflow ReliablePack Register allows values greater than 65535 for etReceivedO ReliablePacketReceived. verflow TotalUnrelia Register allows values greater than 65535 for bleBytesTran TotalUnreliableBytesTransmitted. smittedOverfl ow TotalUnrelia Register allows values greater than 65535 for bleBytesRec TotalUnreliableBytesReceived. eivedOverflo w BSC
BSC
BSC
BSC
BSC
BSC
Total Fwd TotalFwdPac Register allows values greater than 65535 for Packets Dropped ketsDropped TotalFwdPacketsDropped. Overflow Overflow Total Rev TotalRevPac Register allows values greater than 65535 for Packets Dropped ketsDropped TotalRevPacketsDropped. Overflow Overflow
BSC
BSC
Sprint PCS
04/22/02
Page 138
5.11. OM Group: ESEL
Table 5-11: OM Group: ESEL

OM Full Name RLP Setup Attempts OM Register (Name) Description MSC / BSC V/D Basis / BTS BSC D RLP perfor manc e RLP perfor manc e RLP perfor manc e data sessi on setup data sessi on setup data sessi on setup data sessi on setup data sessi on setup
RLPSetupAtt Number of RLP setups attempted empts
RLP Setup Successes
RLPSetupSu Number of successful RLP setups ccesses
BSC
RLP Setup Failures
RLPSetupFai Number of failed RLP setups lures
BSC
Fwd Burst Setup FwdBurstSet Pegged when a forward data burst needs to be set Attempts upAttempts up
BSC
Fwd Burst Setup FwdBurstSet Pegged when a forward data burst is successfully Successes upSuccesse set up s Fwd Burst Setup FwdBurstSet Pegged when a forward data burst could not be set Failures upFailures up
BSC
BSC
Rev Burst Setup Attempts
RevBurstSet Pegged when a reverse data burst needs to be set upAttempts up
BSC
Rev Burst Setup Successes
RevBurstSet Pegged when a reverse data burst is successfully upSuccesse set up s
BSC
Sprint PCS
04/22/02
Page 139

OM Full Name Rev Burst Setup Failures OM Register (Name) Description MSC / BSC V/D Basis / BTS BSC D data sessi on setup SCH setup SCH setup SCH setup
RevBurstSet Pegged when a reverse data burst could not be set upFailures up
FSCH Link Setup FSCHLinkSe Number of forward supplemental channel (FSCH) Attempts tupAttempts setup attempts
BSC
D D D
FSCH Link Setup FSCHLinkSe Number of FSCH setup attempts that are blocked BSC Block tupBlock for lack of resources (reason Oms are given below) FSCH Link Downgrade FSCHLinkDo Number of FSCH setup attempts that are not wngrade granted the requested data rate due to lack of resources, but are granted a lower data rate. Pegged against the primary pilot in the SCH active set. BSC
FSCH Link Setup FSCHLinkSe Number of FSCH setup successes Success tupSuccess
BSC
D D
SCH setup SCH setup
FSCH Radio Link FSCHRadioL This OM is pegged in the event the resources for the BSC Access Failure inkAccessFai FSCH are set up successfully, but the mobile does lure not arrive on the FSCH. It is pegged against each link in the SCH active set. FSCH No Fwd Power FSCHNoFwd Pegged if the FSCHBlock reason indicates a lack of BSC Power available forward power
D D D D D
SCH setup SCH setup SCH setup SCH setup SCH setup SCH setup SCH setup SCH setup SCH setup
FSCH No Walsh FSCHNoWal Pegged if the FSCHBlock reason indicates a lack of BSC Code shCode available Walsh codes FSCH No Phys Res FSCHNoPhy Pegged if the FSCHBlock reason indicates there are BSC sRes no available channel elements BSC BSC
FSCH No Frame FSCHNoFra Pegged if the FSCHBlock reason indicates there is Offset meOffset no available frame offset FSCH CFDS Radio Config FSCH Timeout FSCHCFDS Pegged if the FSCHBlock reason indicates SCH RadioConfig burst functionality has not been enabled through CFDS
FSCHTimeo Pegged if a response to the BTS resource request is BSC ut never received BSC
D D D D
RSCH Link Setup RSCHLinkSe Number of reverse supplemental channel (RSCH) Attempt tupAttempt setup attempts
RSCHLinkSetupB RSCHLinkSe Number of RSCH setup attempts that are blocked BSC lock tupBlock for lack of resources (reason Oms are given below) RSCH Link Downgrade RSCHLinkD Number of RSCH setup attempts that are not owngrade granted the requested data rate due to lack of resources, but are granted a lower data rate. Pegged against the primary pilot in the SCH active set. BSC
Sprint PCS
04/22/02
Page 140

OM Full Name OM Register (Name) Description MSC / BSC V/D Basis / BTS BSC D D SCH setup SCH setup
RSCH Link Setup RSCHLinkSe Number of RSCH setup successes Success tupSuccess
RSCH Radio Link RSCHRadio This OM is pegged in the event the resources for the BSC Access Failure LinkAccessF RSCH are setup successfully, but the mobile does ailure not arrive on the RSCH. It is pegged against each linkin the SCH active set. RSCH No Phys Res RSCHNoPhy Pegged if the RSCHBlock reason indicates there are BSC sRes no available channel elements BSC BSC BSC
D D D D D D
SCH setup SCH setup SCH setup SCH setup SCH setup SCH setup
RSCHNoFrameO RSCHNoFra Pegged if the RSCHBlock reason indicates there is ffset meOffset no available frame offset RSCH CFDS Radio Config RSCH CFDS High Speed RSCH Timeout SCHDrop RSCHCFDS Pegged if the RSCHBlock reason indicates SCH RadioConfig functionality has not been enabled through CFDS RSCHCFDS Pegged if the RSCHBlock reason indicates high HighSpeed speed RSCH has not been enabled through CFDS
RSCHTimeo Pegged if a response to the BTS resource request is BSC ut never received SCHDrop Pegged if the forward or reverse supplemental channel gets abnormally dropped. This OM is pegged against every pilot in the SCH active set. BSC
5.12. OM Group: BTSCallProcessing MO
Table 5-12: OM Group: BTSCallProcessing MO

OM Full Name Paging Channel Message Count Paging Channel Messages Dropped OM Register (Name) Description MSC / BSC V/D Basis / BTS BTS V+D perBTS basis V+D perBTS basis
PagingChan Number of paging channel messages sent to the nelMessage BTS by the PAM in the CAU. This includes pages, Count repages, SMS, etc. PagingChan Number of paging channel messages dropped by nelMessages the BTSC due to BTSC CPU overload. Dropped
BTS
Sprint PCS
04/22/02
Page 141
5.13. OM Group: Advanced Frequency Assignment (FA) MO
Table 5-13: OM Group: Advanced Frequency Assignment (FA) MO

OM Full Name OM Register (Name) Num Of TC Available TCE Util Maximum Total Forward Physical Resources Description MSC / V/D Basis BSC / BTS BTS V+D perfreq basis
NumOfTCAv Total number of channel elements available for ailable traffic across all channel cards after overhead channels have been subtracted. TCEUtilMaxi The peak number of channel elements in use, mum simultaneously, during a given time.
BTS
V+D perfreq basis V+D perfreq basis
TotalForward The number of 3G XCEM resources provisioned for BTS PhysicalRes the BTSs forward link. This excludes all CCEM ources resources and faulty XCEM resources. This OM is a snapshot taken at the time of reporting. It does not represent how many resources are actually in use. SchForward PhysicalRes ourcesReser ved This OM is a subset of BTS TotalForwardPhysicalResources. SchForwardPhysicalResourcesReserved represents the number of XCEM resources which are preallocated to the forward supplemental channel. This includes resources for active and idle supplemental channels. Since a short setup time for data calls is crucial, resources for the supplemental channel are pre-allocated instead of being allocated at call setup.
Sch Forward Physical Resources Reserved
Perfreq basis
Sch Maximum SchMaximu This OM is a high water mark for the number of Forward Physical mForwardPh XCEM resources being used for the forward Resources Used ysicalResour supplemental channel at any time during the cesUsed reporting period.
BTS
perfreq basis
Fch 3G Maximum Fch3GMaxi This OM is a high water mark for the number of BTS Forward Physical mumForward XCEM resources being used for 3G calls on the Resources Used PhysicalRes forward fundamental channel at any time during the ourcesUsed reporting period. Total Reverse Physical Resources TotalRevers The number of 3G XCEM resources provisioned for BTS ePhysicalRe the BTSs reverse link. This excludes all CCEM sources resources and faulty XCEM resources. This OM is a snapshot taken at the time of reporting. It does not represent how many resources are actually in use.
V+D perfreq basis V+D perfreq basis
Sprint PCS
04/22/02
Page 142
Table 5-13: OM Group: Advanced Frequency Assignment (FA) MO

OM Full Name OM Register (Name) Sch Reverse Physical Resource Reserved SchReverse PhysicalRes ourceReserv ed Description MSC / V/D Basis BSC / BTS D perfreq basis
This OM is a subset of BTS TotalReversePhysicalResources. SchReversePhysicalResourcesReserved represents the number of XCEM resources which are preallocated to the reverse supplemental channel. This includes resources for active and idle supplemental channels. Since a short setup time for data calls is crucial, resources for the supplemental channel are pre-allocated instead of being allocated at call setup.
Sch Maximum SchMaximu This OM is a high water mark for the number of Reverse Physical mReversePh XCEM resources being used for the reverse Resources Used ysicalResour supplemental channel at any time during the cesUsed reporting period. Fch 3G Maximum Fch3GMaxi Reverse Physical mumRevers Resources Used ePhysicalRe sourcesUsed
BTS
perfreq basis
This OM is a high water mark for the number of BTS XCEM resources being used for 3G calls on the reverse fundamental channel at any time during the reporting period.
V+D perfreq basis
5.14. OM Group: Advanced Sector MO
Table 5-14: OM Group: Advanced Sector MO

OM Full Name OM Register (Name) Description MSC / V/D Basis BSC / BTS BTS V persector basis
Voice Fch VoiceFchFor Array containing the average forward power (i.e. Forward Link Util wardLinkUtil average of sum of digital gain squared) used by Average Average RCs supporting voice or circuit-switched data calls on the fundamental channel. Each element corresponds to a different RC. The first element is for RC1 and the last element is for RC5. This information is useful in evaluating time impact of voice, data, and various radio configurations on system resources.
Sprint PCS
04/22/02
Page 143

OM Full Name OM Register (Name) Description MSC / V/D Basis BSC / BTS D persector basis
Data Fch DataFchFor Array containing the average forward power (i.e. BTS Forward Link Util wardLinkUtil average of sum of digital gain squared) used by Average Average RCs supporting packet data sessions on the fundamental channel. Each element corresponds to a different RC. The first element is for RC3 and the last element is for RC5. This information is useful in evaluating time impact of voice, data, and various radio configurations on system resources. Sch Forward Link SchForward Array containing the average forward power (i.e. BTS Util Average LinkUtilAvera average of sum of digital gain squared) used by ge RCs supporting packet data sessions on the supplemental channel. Each element corresponds to a different RC. The first element is for RC3 and the last element is for RC5. This information is useful in evaluating time impact of voice, data, and various radio configurations on system resources. Percent Time Above Fwd Data Call Blocking Threshold Configured Fwd Data Call Blocking Threshold PercentTime AboveFwdD ataCallBlocki ngThreshold This represents the percentage of time during the 2- BTS second measurement interval that data calls would be blocked based on the MaxDataResources and MaxDataFCHResources attributes in the AdvancedSector MO. BTS
persector basis
persector basis
ConfiguredF This metric represents the amount of power wdDataCallB available for data originations, terminations, and lockingThres handoffs into the BTS. hold
persector basis persector basis
Fch Origination FchOriginati Number of successful BTS resource allocations for BTS Non Blocking 2G onNonBlocki 2G calls. This is not an indication of successful call ng2G attempts. This metric does not include calls that were allocated for 2G after being downgraded from 3G. This metric also does not include non- reference pilot links setup for CASHO. 2G links, other than the reference pilots link, setup for CASHO are pegged under FchHandoffNonBlocking2G.
Sprint PCS
04/22/02
Page 144

OM Full Name OM Register (Name) Description MSC / V/D Basis BSC / BTS V persector basis
Fch Handoff Non FchHandoffN Array of 2 elements indicating the number of BTS Blocking 2G onBlocking2 successful BTS resource allocations for 2G G handoffs. The first element in the array (i.e. FchHandoffNonBlocking2G[0]) represents the number of successful BTS resource allocations for a 2G non VPN-based soft handoff. The second element in the array (i.e. FchHandoffNonBlocking2G[1]) represents the number of successful BTS resource allocations for a 2G VPN-based soft handoffs. Note: This OM is not an indication of successful handoffs. Note that this metric also includes nonreference pilot links setup for CASHO. Fch Origination FchOriginati Number of successful BTS resource allocations for Non Blocking 3G onNonBlocki 3G voice calls on the fundamental channel. This is Voice ng3GVoice not an indication of successful call attempts. This metric does not include non-reference pilot links setup for CASHO. 3G voice links, other than the reference pilots link, setup for CASHO are pegged under FchHandoffNonBlocking3GVoice. Fch Origination FchOriginati Number of successful BTS resource allocations for Non Blocking 3G onNonBlocki 3G data calls on the fundamental channel. This is Data ng3GData not an indication of successful call attempts. This metric does not include non-reference pilot links setup for CASHO. 3G data links, other than the reference pilots link, setup for CASHO are pegged under FchHandoffNonBlocking3GData. Fch Origination FchOriginati Number of successful BTS resource allocations for Non Blocking 3G onNonBlocki fundamental channel 2G calls which were Downgrade 2G ng3GDowngr downgraded from 3G calls attempts. This metric ade2G does not include non-reference pilot links setup for CASHO. 2G links, other than the reference pilots link, setup for CASHO are pegged under FchHandoffNonBlocking2G. Fch Handoff Non FchHandoffN Number of successful BTS resource allocations for BTS Blocking 3G onBlocking3 3G voice handoffs on the fundamental channel. Note Voice GVoice that This is not an indication of successful handoffs. Fch Handoff Non FchHandoffN Number of successful BTS resource allocations for BTS Blocking 3G Data onBlocking3 3G data handoffs on the fundamental channel. Note GData that This is not an indication of successful handoffs. Sch Burst Non Blocking 3G SchBurstNon Number of successful BTS resource allocations for BTS Blocking3G 3G data bursts on the supplemental channel. This is not an indication of successful data bursts. BTS BTS
persector basis
BTS
persector basis
persector basis
persector basis persector basis persector basis
Sprint PCS
04/22/02
Page 145

OM Full Name OM Register (Name) Description MSC / V/D Basis BSC / BTS D persector basis persector basis persector basis persector basis persector basis persector basis persector basis persector basis persector basis
Sch Handoff Non SchHandoff Number of successful BTS resource allocations for BTS Blocking 3G NonBlocking 3G data handoffs on the supplemental channel. Note 3G that This is not an indication of successful handoffs. Blocked Fch Originations 2G Blocked Fch Handoffs 2G Blocked Fch Originations 3G Voice Blocked Fch Originations 3G Data Blocked Fch Handoffs 3G Voice Blocked Fch Handoffs 3G Data Blocked Sch Bursts Blocked Sch Handoffs Frame Cnt FCH BlockedFch Array indicating the number of 2G call attempts BTS Originations2 blocked on the fundamental channel. Each array G element corresponds to a different blocking reason. BlockedFch Array indicating the number of 2G handoffs blocked BTS Handoffs2G on the fundamental channel. Each array element corresponds to a different blocking reason. BlockedFch Array indicating the number of 3G voice call BTS Originations3 attempts blocked on the fundamental channel. Each GVoice array element corresponds to a different blocking reason. BlockedFch Array indicating the number of 3G data sessions BTS Originations3 blocked on the fundamental channel. Each array GData element corresponds to a different blocking reason. BlockedFch Array indicating the number of 3G voice handoffs BTS Handoffs3G blocked on the fundamental channel. Each array Voice element corresponds to a different blocking reason. BlockedFch Array indicating the number of 3G data handoffs BTS Handoffs3G blocked on the fundamental channel. Each array Data element corresponds to a different blocking reason. BlockedSch Array indicating the number of 3G data bursts BTS Bursts blocked on the supplemental channel. Each array element corresponds to a different blocking reason. BlockedSch Array indicating the number of 3G data handoffs BTS Handoffs blocked on the supplemental channel. Each array element corresponds to a different blocking reason. FrameCntFC Array indicating the total number of frames sent on H the forward link for every user on the fundamental channel. Each element in the array represents one radio configuration from RC1 through RC5. The array begins with RC1. FrameCntSC Array indicating the total number of forward frames H for every user on the supplemental channel. Each element in the array represents one radio configuration from RC3 through RC5. The array begins with RC3. CEFrameCnt Equivalent to FrameCntFCH with each frame being FCH divided by the number of softer handoff links. BTS
V+D persector basis
Frame Cnt SCH
BTS
persector basis
CE Frame Cnt FCH
BTS
V+D persector basis
Sprint PCS
04/22/02
Page 146

OM Full Name OM Register (Name) CE Frame Cnt SCH Primary Frame Cnt FCH Primary Frame SCH Description MSC / V/D Basis BSC / BTS BTS D persector basis
CEFrameCnt Equivalent to FrameCntSCH with each frame being SCH divided by the number of softer handoff links. PrimaryFram Equivalent to FrameCntFCH with each frame being eCntFCH divided by the product of the number of softer handoff links and the number of soft handoff links. PrimaryFram Equivalent to FrameCntSCH with each frame being eSCH divided by the product of the number of softer handoff links and the number of soft handoff links.
BTS
V+D persector basis D persector basis
BTS
Sprint PCS
04/22/02
Page 147
6. List Of Operational Measurements (OMs) Requested By Sprint From Nortel And Other Vendors
Table 6 lists all requested Operational Measurements in FRD (highlighted in gray) which was sent to all vendors as well as current Operational Measurements availability for all vendors. Here is the explanation of the symbols in the table: L = Provided by Lucent N = Provided by Nortel M = Provided by Motorola S = Provided by Samsung l = Not Applicable for Lucent n = Not Applicable for Nortel m = Not Applicable for Motorola s = Not Applicable for Samsung From Table 6 it can be seen that each vendor currently falls significantly short of providing all the requested OMs. Risks associated with lack of OMs include: Inability to monitor Paging and Access channel occupancy and success as well as Quick Paging Channel performance Inability to monitor 3G Voice and Data performance, capacity, data rates, and service option specific impacts and contributions Inability to identify potential misconfigurations, failing network elements or required optimization Very few tools for network monitoring and trouble shooting Will rely on customer complaints for network information.
Sprint PCS
04/22/02
Page 148
To compensate for the lack of OMs, significant amount of drive testing can be required to provide daily network performance information. Core RF has estimated that this could require millions of dollars. Vendors plan to add more Operational Measurements in the future and for that reason Table 6 and the whole document will need to be updated. Here is the comparison of current vendor OM capabilities divided by OM groups: 1. Paging Channel Just Lucent and Samsung have some OMs. Average Paging Channel Occupancy Used to Support Packet Data Calls is not available from any vendor. 2. Quick Paging Channel Neither vendor has OMs. 3. Access Channel - Just Lucent and Samsung have some OMs. 4. Registration Just Lucent and Motorola has some OMs. Time Based Registration, Zone Based Registration, Distance Based Registration and Forced Based Registration OMs are not available from any vendor. 5. Short Message Service Nortel doesnt have any OMs in that group. Motorola has just SMS Received on Access Channel. Lucent and Samsung have some OMs. Average Paging Channel SMS Size, Average Forward Traffic Channel SMS Size, Average Access Channel SMS Size and Average Reverse Traffic Channel Size OMs are not available from any vendor. 6. Backhaul Nortel doesnt have any OMs in that group. Motorola is the only vendor with available Peak Backhaul Occupancy. 7. Originations All vendors are supporting some OMs in that group with Lucent having the best granularity. Lucent is the only vendor that has Silent Reorigination available. Origination Total # of 3G Data Unique Users is not available from any vendor. Some requirements in that group are not applicable for Samsung since all Samsung channel resources are capable of 3G. 8. Terminations - All vendors are supporting some OMs in that group with Lucent having the best granularity. Motorola is the only vendor that has Termination No Response from Mobile available. Some requirements in that group are not applicable for Samsung since all Samsung channel resources are capable of 3G. 9. IS-95B Features Neither vendor has any Access Handoff, Access Entry Handoff and Access Probe Handoff OMs available. Only Lucent has some Channel Assignment Into Soft Handoff OMs available.
Sprint PCS
04/22/02
Page 149
10. Active Mode Voice Call - All vendors are supporting some OMs in that group. Nortel is the only vendor that has Average Channel Elements per call available. Samsung is the only vendor that has Hard Handoff Request and Hard Handoff Denied available. Motorola is the only vendor that has Hard Handoff Failure available and Lucent is the only vendor that has Average Long Term Power Required available. 11. Dedicated Control Channel - Neither vendor has OMs. 12. Forward Fundamental Channel Packet Data Call Samsung doesnt have any OMs in that group. Lucent doesnt have any Soft Handoff OMs in that group. Neither vendor has Average Soft Handoff Percentage Per Call. Neither vendor has any Hard Handoff OMs in that group but some of Hard Handoff OMs are not applicable for Motorola and Lucent. The only Forward Fundamental Channel Data Burst OM that Motorola has is Forward Fundamental Channel Assignment. 13. Reverse Fundamental Channel Packet Data Call Neither vendor has OMs. 14. Forward Supplemental Channel Packet Data Call Motorola doesnt have any Soft Handoff OMs in that group and requirement for Soft Handoff OMs in that group is not applicable for Samsung. Forward Supplemental Channel RLP Frames Sent, Forward Supplemental Channel RLP Retransmissions and Average Short Term Power Required OMs are not available from any vendor. Lucent has only one OM available in that group (Forward Supplemental Channel Data Burst Assignment). Motorola is the only vendor that has Forward Supplemental Channel Bursts Interrupted available. 15. Reverse Supplemental Channel Packet Data Call - Neither vendor has any Soft Handoff OMs in that group but some of Soft Handoff OMs are not applicable for Motorola and Lucent. Reverse Supplemental Channel RLP Retransmissions and Average Retransmissions Per Data Burst OMs are not available from any vendor. Motorola is the only vendor that has Reverse Supplemental Channel Burst Interrupted available. Lucent is the only vendor that has Reverse Supplemental Channel RLP Frames Received available but that is the only available Lucent OM in that group. 16. Active Mode Circuit Data Call - All vendors are supporting some OMs in that group with Nortel having the best granularity. Nortel is the only vendor that has Average Soft Handoff Percentage Per Call, Average Channel Elements Per Call and Average Walsh Code Links Per Call OMs available. The only vendor that has some Hard Handoff OMs in that group is also Nortel. Some Hard Handoff OMs are not applicable to Motorola since Hard Handoff does not exist for circuit data call in Motorola system. 17. Packet Data Session - All vendors except Samsung are supporting some OMs in that group with Motorola having the best granularity. Nortel is very similar to Motorola and Lucent
Sprint PCS
04/22/02
Page 150
supports just couple of OMs in that group. Neither vendor supports Total # 3G Data Fundamental Channel Releases. 18. Circuit Data Session Samsung doesnt support any OMs in that group. Nortel only supports Forward Power Overload. Lucent and Motorola are only supporting Forward Power Overload and Reverse Power Overload. Neither vendor supports peak Data Throughput, Average Data Throughput, Peak Duration and Buffer Overflow OMs. 19. Channel Element Usage - All vendors are supporting some OMs in that group with Lucent having the best granularity (Lucent supports all requested OMs in that group). 20. Walsh Code Usage Samsung and Nortel do not support any OMs in that group. Lucent supports all requested OMs in that group. 21. Data Throughput Only Motorola has some requested OMs. 22. BSC-PCF Metrics Nortel supports almost all requested OMs in that group. Most of the OMs in that group doesnt have to be supported by Lucent, Motorola or Samsung.
Table 6 : List of Operational Measurements requested by Sprint

Supported OMs RF system zone/MM site sector SO carrier channel type link Data Add'l Info
Operational Measurement Description Paging Channel Peak Paging Channel Occupancy Average Paging Channel Occupancy Average Paging Channel Occupancy Used to Support Packet Data Calls Quick Paging Channel Peak Quick Paging Channel Occupancy Average Quick Paging Channel Occupancy L L L L S S L L S
Sprint PCS
call session rate usage-state duration PDSN/IWU/IWF HO State Reason source type PCU/PCF
04/22/02 Page 151
RC

Operational Measurement Description Access Channel Peak Access Channel Occupancy Average Access Channel Occupancy Average Access Channel Occupancy Used to Support Packet Data Calls Registrations Time Based Registration Zone Based Registration Distance Based Registration Power Up Registration Power Down Registration Parameter Based Registration Forced Registration Short Message Service Paging Channel Delivery SMS Deliveries Over Paging Channel Average Paging Channel SMS Size Forward Traffic Channel Delivery SMS Deliveries Over Forward Traffic Channel Average Forward Traffic Channel SMS Size Access Channel Reception SMS Received on Access Channel L L MM S S L M S L L S S L S L L S S L S L L MM L L MM MM M M M L L S S L L
Average Access Channel SMS Size
Sprint PCS
04/22/02 Page 152
RC

Operational Measurement Description Reverse Traffic Channel Reception SMS Received on Reverse Traffic Channel Average Reverse Traffic Channel Size Backhaul Peak Backhaul Occupancy Average Backhaul Occupancy M L M S M L M S L L S S L S
Originations Origination Attempts L L L MM M L S S S N N N L L L MM L S S S N N N L L L L L L M L M L N N N s L L M L M L N N N s N M N N MM S S N N N L M L M S N
Origination Blocks
Silent Reorigination 3G Origination Assigned 2G Resources
L L
2G Origination Assigned 3G Resources
L L
3G Origination Assigned Lower Data Rate Origination Cross Carrier Assignments
Origination Total # of 3G Data Unique Users
Sprint PCS
call session rate usage-state duration PDSN/IWU/IWF HO State Reason source type PCU/PCF L L
04/22/02 Page 153
RC

Operational Measurement Description Total # 3G data call blocks (BSC element) Terminations Termination Attempts L L N NMM S S L L MM S S N N L M S L M S M M S
Termination Blocks
3G Termination Assigned 2G Resources
L L M L M L N N N s L M L L L s N L L L M L N N N MM S S MM S
2G Termination Assigned 3G Resources
3G Terminations Assigned Lower Data Rate
Termination Cross Carrier Assignments Termination No Response from Mobile IS-95B Features Access Handoff Access Handoff Original Sector Access Handoff Target Sector Access Entry Handoff Access Entry Handoff Original Sector Access Entry Handoff Target Sector Access Probe Handoff Access Probe Handoff Original Sector
m m
m m
Sprint PCS
call session rate usage-state duration PDSN/IWU/IWF HO State Reason source type PCU/PCF L L L L
04/22/02 Page 154
RC

Operational Measurement Description Access Probe Handoff Target Sector Channel Assignment Into Soft Handoff CAMSHO Request CAMSHO Denied CAMSHO Origination Assignment CAMSHO Termination Assignment CAMSHO Origination Blocks CAMSHO Termination Blocks Active Mode Voice Call Dropped Calls L L L L MM M M M N N N M L L L L L L L L L L L L
L M
Soft Handoff Soft Handoff Request L L L M L M M S L L L M L M M S L L L M L M M S L N N N N MM N N S S N N S N N N N M L
Soft Handoff Denied
Soft Handoff Failures
Average Soft Handoff Percentage Per Call Average Channel Elements Per Call Average Code Links Per Call
Hard Handoff Hard Handoff Request Hard Handoff Denied S S
Sprint PCS
call session rate usage-state duration PDSN/IWU/IWF HO State Reason source type PCU/PCF L L M L
04/22/02 Page 155
RC

Operational Measurement Description Hard Handoff Failure Average Long Term Power Required Dedicated Control Channel Dropped Calls Soft Handoff Soft Handoff Request Soft Handoff Denied Soft Handoff Failure Average Soft Handoff Percentage Per Call Average Channel Elements Per Call Average Walsh Code Links Per Call Hard Handoff Hard Handoff Request Hard Handoff Denied Hard Handoff Failure Average Long Term Power Required Forward Fundamental Channel Packet Data Call Dropped Calls L M MM N N M N MM L L L
M L
L M
Soft Handoff Soft Handoff Request Soft Handoff Denied Soft Handoff Failures Average Soft Handoff Percentage Per Call Average Channel Element Per Call Average Walsh Code Links Per Call M N M N N M N M MMM MMM MMM M M M
Sprint PCS
call session rate usage-state duration PDSN/IWU/IWF HO State Reason source type PCU/PCF ML
04/22/02 Page 156
RC

Operational Measurement Description Hard Handoff Hard Handoff Request m l Hard Handoff Denied m l Hard Handoff Failure m l Average Long Term Power Required Forward Fundamental Channel Data Burst Forward Fundamental Channel Assignments Forward Fundamental Channel RLP Frames Sent Forward Fundamental Channel RLP Retransmissions Average Short Term Power Required Forward Fundamental Channel Data Burst Denied Reverse Fundamental Channel Packet Data Call Reverse Fundamental Channel Data Burst Reverse Fundamental Channel RLP Frames Received Reverse Fundamental Channel RLP Retransmissions Average RLP Retransmissions Required Per Data Burst Forward Supplemental Channel Packet Data Call Soft Handoff L L N N L L L L L L N N L L N N L N L L L N L N
Sprint PCS
call session rate usage-state duration PDSN/IWU/IWF HO State Reason source type PCU/PCF N
04/22/02 Page 157
RC

Operational Measurement Description Average Soft handoff Percentage Per Call N s N l N N s s N N
Average Channel Elements Per Call Average Walsh Code Links Per Call Forward Supplemental Channel Data Burst Forward Supplemental Channel Data Burst Assignment
L L L M M LM S N N N
L M
Forward Supplemental Channel RLP Frames Sent Forward Supplemental Channel RLP Retransmissions Forward Supplemental Channel Bursts Interrupted Average Short Term Power Required Forward Supplemental Channel Data Burst Denied Forward Supplemental Data Burst Assigned a Lower Rate Reverse Supplemental Channel Packet Data Call Soft Handoff Soft Handoff Request l m Soft Handoff Request Denied l m Soft Handoff Failure l m M M S N N M N N M N N M M M M
Sprint PCS
call session rate usage-state duration PDSN/IWU/IWF HO State Reason source type PCU/PCF L M L M L M
04/22/02 Page 158
RC

Operational Measurement Description Average Soft Handoff Percentage Per Call Average Channel Elements Per Call Supplemental Channel Data Burst Reverse Supplemental Channel Assignments M M S N N M N l
MM
Reverse Supplemental Channel RLP Frames Received Reverse Supplemental Channel RLP Retransmissions Average Retransmissions Per Data Burst Reverse Supplemental Channel Burst Interrupted Supplemental Channel Data Burst Denied
L L L L
M M M S N N M N
Active Mode Circuit Data Call Dropped Calls L L L L MM M M M N N N M L M L L M
Soft Handoff Soft Handoff Request Soft Handoff Denied Soft Handoff Failure Average Soft Handoff Percentage Per Call Average Channel Elements Per Call Average Walsh Code Links Per Call Hard Handoff Hard Handoff Request m M M M S M S
MM N N N N N N N N N N N N
Sprint PCS
call session rate usage-state duration PDSN/IWU/IWF HO State Reason source type PCU/PCF M M L L L M M M
04/22/02 Page 159
RC

Operational Measurement Description Hard Handoff Denied Hard Handoff Failure Average Long Term Power Required Packet Data Session Peak Data Throughput Average Data Throughput Peak Duration Average Duration Buffer Overflow Total Dormant to Active Transitions Average Dormant to Active Transitions Total # 3G Data Fundamental Channel Releases Circuit Data Session Peak Data Throughput Average Data Throughput Peak Duration Average Duration Buffer Overflow Forward Power Overload L M M N N L M M M N M m m N N N N N N
N NM
Reverse Power Overload
Sprint PCS
call session rate usage-state duration PDSN/IWU/IWF HO State Reason source type PCU/PCF N M N M N M N M L M L M M L N L m M
04/22/02 Page 160
RC

Operational Measurement Description Channel Element Usage Peak Channel Element Usage Average Channel Element Usage L N L M S L N L
L L M N M
Walsh Code Usage Peak Walsh Code Usage Average Walsh Code Usage Data Throughput Forward Link Peak Data Throughput Reverse Link Peak Data Throughput Forward Link Average Data Throughput Reverse Link Average Data Throughput Forward Link Peak Data Load Reverse Link Peak Data Load Forward Link Average Data Load Reverse Link Average Data Load Forward Link Peak Data Delay Reverse Link Peak Data Delay Forward Link Average Data Delay Reverse Link Average Data Delay BSC - PCF Metrics Reliable Packets Sent Success N l m s N M M M M M M L L L L MM L L M
Sprint PCS
04/22/02 Page 161
RC

Operational Measurement Description Packet Success L N m s l m s l m s N l m s Reliable Packets Re-Transmitted Overflow N l m s Reliable Packets Received m s N l m s N l m s Total Unreliable Bytes Transmitted Overflow l m s
Packet Submits
Reliable Packets Sent Success Overflow
Reliable Packets Re-Transmitted
Reliable Packets Received Overflow
Total Unreliable Bytes Transmitted
Sprint PCS
call session rate usage-state duration PDSN/IWU/IWF HO State Reason source type PCU/PCF L N N N N N N N N N
04/22/02 Page 162
RC

Operational Measurement Description Total Unreliable Bytes Received N l m s Total Unreliable Bytes Received Overflow L m s S N l m Total Fwd Packets Dropped Overflow s L M M N Total Rev Packets Dropped l m s l m s l m s l m s l m s s N m s
Total Fwd Packets Dropped
Total Rev Packets Dropped Overflow
DCR Buffer Overflows
DCR_NumOStop Transmit Msgs Sent
RRBuffer Overflows
Total Session Setup Initial Attempts Total Session Setup Reconnect Attempts
Sprint PCS
call session rate usage-state duration PDSN/IWU/IWF HO State Reason source type PCU/PCF N N S N L M N N N N N N N N
04/22/02 Page 163
RC

Operational Measurement Description N Total Session Setup Successes m L M N m L N m L N m S N m S N m S N
Total Session Setup Failures
R-P interface
User Information
Tunnels
Tunnel Failures
Sprint PCS
call session rate usage-state duration PDSN/IWU/IWF HO State Reason source type PCU/PCF L N L N L N S N S N S N
04/22/02 Page 164
RC
7. References
1. 3G Data and Capacity Solutions Operational Measurements, 411-2133-320, Nortel Networks, Standard 01.03, June 2001 2. Wireless ePerformance CDMA Report Specifications for MTX10 Priority 1, Preliminary draft, Nortel Networks 3. Wireless ePerformance CDMA Report Specifications for MTX10 Priority 2, Preliminary draft, Nortel Networks 4. Bret Vondemkamp, MTX10/NBSS10.x Deployment Guideline, Sprint PCS, March 2002 5. CDMA-NBSS Operational Measurements, 411-2133-535, Nortel Networks, Standard 07.07, February 2002
Sprint PCS
04/22/02
Page 165

Nortel - KPI Formula's Desc Detail

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Nortel - KPI Formula's Desc Detail

Enviado por

Direitos autorais:

Formatos disponíveis

3G 1xRTT Nortel Operational Measurements

3G 1xRTT Nortel Operational Measurements

Your input is important. If you have questions, comments, or suggestions

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

2. Overview of 3G Voice and Data in Nortel Implementation

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

3.1. Performance Formulas for 3G Voice

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

example example example example

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Day 3: 2.07 % Day 4: 1.97 %

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Day 2: 0.97 % Day 3: 1.28 % Day 4: 0.98 %

Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Proprietary & Confidential